Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an easier way to translate validations #754

Closed
wout opened this issue Oct 25, 2021 · 4 comments
Closed

Provide an easier way to translate validations #754

wout opened this issue Oct 25, 2021 · 4 comments

Comments

@wout
Copy link
Contributor

wout commented Oct 25, 2021

As it is currently, validation error messages are hardcoded. The only way to translate them is through the message argument, which results in a lot of repetition:

validate_required email,
  message: r("lucky.validate.required").t
validate_uniqueness_of email,
  message: r("lucky.validate.uniqueness").t
validate_format_of email,
  with: /[^@]+@[^\.]+\..+/,
  message: r("lucky.validate.email_format").t
validate_required first_name,
  message: r("lucky.validate.required").t
validate_required last_name,
  message: r("lucky.validate.required").t
validate_inclusion_of language,
  in: Rosetta.available_locales.map(&.to_s),
  message: r("lucky.validate.inclusion").t
validate_inclusion_of theme,
  in: User::Theme.values,
  message: r("lucky.validate.inclusion").t

How about creating an adapter to allow i18n libraries to hook into and overwrite Avram's default values? It could be a simple as:

module Avram::I18nBackend
  macro get(key)
    {
       validate_required: "is required",
       validate_uniqueness_of: "is already taken",
       # ...
    }[{{key.id}}]
  end
end

And then allow the backend to be configured:

Avram.configure do |settings|
  settings.i18n_backend = Rosetta::LuckyI18nBackend
end

The above is all untested and from the top of my head. I'm open to suggestions. What do you guys think?

@jwoertink
Copy link
Member

I love the idea. I've thought about that too, and actually some of the validations are almost impossible to customize the error right now. Like

attribute.add_error(message || "is too short")
no_errors = false
end
if !max.nil? && size > max
attribute.add_error(message || "is too long")
where you can only customize one, but not both.

If you want to take a stab at a PR, that would be nice.

@wout
Copy link
Contributor Author

wout commented Oct 25, 2021

Great! Yeah, I'll see how far I get with minimal impact. And also think of a way to add some kind of interpolation with min/max and customizability with the combinations, like min alone, max alone and both together.

@jwoertink
Copy link
Member

I believe this is done now via #757 I'm going to close this, but if there's still more to do, we can re-open it.

@wout
Copy link
Contributor Author

wout commented Mar 17, 2024

Yes, that one is done. Still working on this, though: luckyframework/lucky#1773.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants