I want to propose changing the namespace in I18n files
from :activerecord to :models. The reason is to be more agnostic since
with ActiveModel it will appear several plugins that are similar to
ActiveRecord and this would mean in a lot of duplication:
en:
activerecord:
errors:
messages:
blank: “can’t be blank”
invalid: “invalid”
anotherlib:
errors:
messages:
blank: "can't be blank"
invalid: "invalid"
Moving to more agnostic name means that we could have such messages in
just one place:
en:
models:
errors:
messages:
blank: “can’t be blank”
invalid: “invalid”
This is a topic I already discussed with Sven, and just brought the to
mailing list now. Backward compatibility would be possible with the
use of symlinks:
en:
activerecord: :models
But this could become expensive if people forget to change it. So I
would prefer to check if the yaml file has an :activerecord key and
tell people to update it.
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
But this could become expensive if people forget to change it. So I
would prefer to check if the yaml file has an :activerecord key and
tell people to update it.
On Mon, Jan 4, 2010 at 5:47 AM, Rodrigo Rosenfeld R. [email protected] wrote:
–
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
I find Clemens’ solution the most elegant I’ve read so far. It keeps
all the translations of a model together, instead of splitting them
into two separate scopes. I do miss the global error message
translations.
About the transition, we could also make a configuration option,
making it possible to switch between old-style and new-style, but I
don’t like the extra code that requires in AR. Also, a small script
that rewrites your yml? Wouldn’t be that difficult.
On a side note:
Last few projects I’ve done, I found that I didn’t want to put all
translations into one scope at all. All this nesting can be difficult
to maintain. Couldn’t we just get rid of the ‘models’-scope?
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
Good proposal Clemens! But would be odd to have “admin” and “errors”
sharing the same keys level:
en:
models:
admin:
name: Admin
attributes:
name: Name
errors:
messages:
blank: "can't be blank"
Unless we make errors a root key as well:
en:
errors:
messages:
blank: “cannot be blank”
models:
admin:
name: Admin
attributes:
Anyway, I put up a gist will a Rails 2.3 yml sample and current
proposals:
Feel free to fork it and propose other alternatives. Later I will
gather different proposals and sum them up here, so we can discuss
them (including backward compatibility).
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
sharing the same keys level:
blank: “can’t be blank”
name: Admin
blank: "cannot be blank"
admin: Admin
“en.models.models.admin” is odd, maybe we should change the second
errors:
On Jan 4, 2010, at 9:00 AM, Yaroslav Markin wrote:
–
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
sharing the same keys level:
blank: “can’t be blank”
name: Admin
blank: "cannot be blank"
admin: Admin
“en.models.models.admin” is odd, maybe we should change the second
errors:
On Jan 4, 2010, at 9:00 AM, Yaroslav Markin wrote:
–
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
Thanks for the attention. I personally liked the direction token by
Clemens and Iain, but the change should be the smallest backward
compatible as possible. And the simplest way to achieve it is to
move :activerecord.errors to simply :errors.
Anyway, I will try to implement default attributes as Iain proposed,
as something like this:
I’ve hacked together a small script to convert the current situation
to my proposed situation and tested it out on one of the bigger
projects I did recently. The results are:
Feel free to fork it and propose other alternatives. Later I will
name: Admin
en:
en:
messages:
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
–
You received this message because you are subscribed to the Google G. “rails-i18n” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group athttp://groups.google.com/group/rails-i18n?hl=en.
But … IMO that’s another good argument to make things more pluggable.
One could easily imagine having the defaults/scopes generation in a
central method that could be overwritten by custom implementations.
I believe at some point we even have to have better support for that
unless we want to be forced to work around BC forever.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.