Changing :activerecord to :models in Rails yml files

Hey folks,

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.

So, are you in?

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

On Mon, Jan 4, 2010 at 5:47 AM, Rodrigo Rosenfeld R.
[email protected]wrote:

José Valim escreveu:

Hey folks,

I want to propose changing the namespace in I18n files
from :activerecord to :models.

Agreed, but we probably need a fallback anyway — look in :models, than
in
:activerecord.


Yaroslav

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

José Valim escreveu:

    messages:

just one place:
use of symlinks:

I completely agree.

Rodrigo.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

+1 :slight_smile:

regarding bc - can we just link?

en:
models:
errors:
messages:
blank: “can’t be blank”
invalid: “invalid”

en:
activerecord:
errors: :“models.errors”

?

On Jan 4, 2010, at 9:00 AM, Yaroslav Markin wrote:


Yaroslav

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 at http://groups.google.com/group/rails-i18n?hl=en.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

We could link, but since people have ActiveRecord stuff in their yml
the link would be overwriten anyway, like in the simple example below:

en:
activerecord:
errors:
blank: “cannot be blank”

That’s why I think that we should just yell a warning if we find an
activerecord key.

By the way, Sam Ruby, pointed an issue, imagine the following
configuration below:

en:
models:
models:
admin: Admin
artist: Artist

  attributes:
    admin:
      name: Name

  errors:
    messages:
      blank: cannot be blank

“en.models.models.admin” is odd, maybe we should change the second
“models” for another key? If so, which one?

On Jan 4, 9:05 am, Sven F. [email protected] wrote:


Yaroslav

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

good idea! +1

On Jan 3, 11:59 pm, José Valim [email protected] wrote:

    messages:

just one place:
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.

So, are you in?

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Maybe use “names” instead of “models”? Or change the structure on a
larger scale? Like so:

en:
models:
admin:
name: Admin
attributes:
name: Name

etc.

On Jan 4, 9:27 am, José Valim [email protected] wrote:

    admin:
     blank: "can't be blank"

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://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?

On Jan 4, 10:13 am, Clemens K. [email protected] wrote:

etc.

    artist: Artist

“models” for another key? If so, which one?

   messages:

Yaroslav

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://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).

On Jan 4, 10:13 am, Clemens K. [email protected] wrote:

etc.

  errors:
  models:

models:


Yaroslav

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

also, what about full_messages per model or attribute? :slight_smile:

On Jan 4, 2010, at 11:20 AM, José Valim wrote:

 errors:

Feel free to fork it and propose other alternatives. Later I will

  name: Admin

the link would be overwriten anyway, like in the simple example below:
configuration below:

activerecord:

I want to propose changing the namespace in I18n files
To post to this group, send email to [email protected].

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

I think that feature is crucial. I can think of it being used with more
frequency than with a generic message.

Sven F. escreveu:

also, what about full_messages per model or attribute? :slight_smile:

On Jan 4, 2010, at 11:20 AM, José Valim wrote:

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Forked the gist and added 3.yml, which is Clemens’ proposal with some
more examples

Feedback please :slight_smile:

On Jan 4, 1:55 pm, José Valim [email protected] wrote:

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Yeah, we should definitely take this into account when working on this
new i18n yml format.

On Jan 4, 12:32 pm, Sven F. [email protected] wrote:

models:

Anyway, I put up a gist will a Rails 2.3 yml sample and current

larger scale? Like so:
On Jan 4, 9:27 am, José Valim [email protected] wrote:

activerecord key.
attributes:
On Jan 4, 9:05 am, Sven F. [email protected] wrote:

     invalid: "invalid"

José Valim escreveu:

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Nice! We should also try work with a real yml file, to see if it will
get more verbose or not with Iain proposal.

On Jan 4, 9:07 pm, iain hecker [email protected] wrote:

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Hey guys,

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:

en:
attributes:
updated_at: “Atualizado em”

Thanks again!

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:

Before: 899 lines, 33KB
After: 975 lines, 35KB

Not a big difference in verbosity.

The script is here: transform-activerecord-yml.rb · GitHub

I just placed it in the root of my rails app and ran it. Change the
locale if you want to try it.

On Jan 4, 11:12 pm, José Valim [email protected] wrote:

Feedback please :slight_smile:

On Jan 4, 2010, at 11:20 AM, José Valim wrote:

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.

You received this message because you are subscribed to the Google
Groups “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 at
http://groups.google.com/group/rails-i18n?hl=en.

Obviously I mean the most backward compatible possible. :wink:

I agree.

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.