Rails translation scope cleanup

103 views
Skip to first unread message

iain

unread,
Aug 10, 2008, 7:14:05 PM8/10/08
to rails-i18n
Hi all,

While defining the list of available translations[1] I found some
stuff that doesn't add up in the active_record scope.

Right now it's like this:

active_record:
error:
header_message:
message:
post: "Post"

human_attribute_names:
post:
title: "Title"

error_messages:
inclusion: "is not included in the list"
# etc

custom:
post:
title:
inclusion: "is not included in the list"
# etc...

I suggest this structure:


active_record:
models:
post:
one: "Post"
many: "Posts"

attribute_names:
post:
title:
one: "Title"
many: "Titles"

errors:
header_message: "Foo"
message: "Bar"
error_messages:
inclusion: "is not included in the list"
# etc

custom:
post:
# include error messages here for the whole model, not just
per attribute
inclusion: "is not..."
title:
inclusion: "is not included in the list"
# etc...

And while on this point, wouldn't it be nice if we had interpolation
on the error messages? It is sometimes difficult to make a proper
sentence when the attribute name is always at the start.

blank: "{{attribute}} can't be blank"

Furthermore, why aren't all the other modules in their proper scope?
Why isn't number in the action_pack scope and date in the
active_support scope? Same goes for date/time.

Should we be having those underscores even there? I thought DHH's
preference was without underscores?

Give me your thoughts (and I promise I'll take good care of them ;) )

Yours truly, as always,

Iain

[1] http://rails-i18n.org/wiki/pages/translations-available-in-rails

Sven Fuchs

unread,
Aug 11, 2008, 4:50:30 AM8/11/08
to rails...@googlegroups.com
Hey Iain,

it's a good idea to revisit that structure before Rails 2.2 gets
released and people start relying on it.

I'd prefer to keep the keys as short as possible (they're already
scoped, so clashes are no problem). E.g.

models.attributes instead of models.attribute_names
errors.messages instead of errors. error_messages

How about

errors.message.header and
errors.message.body

instead of

errors.message.header_message and
errors.message


Or maybe it even should be

errors.template.header and
errors.template.body


> And while on this point, wouldn't it be nice if we had interpolation
> on the error messages? It is sometimes difficult to make a proper
> sentence when the attribute name is always at the start.
>
> blank: "{{attribute}} can't be blank"

You can now do that with the custom messages. Oh! No, the attribute
name is not passed, right? I agree that would be useful.

I'd not change the default error messages for this Rails version though.

Another thought: It would be awesome if on your translations list
there would be the variables listed that are available for the
translations even when they're not used in the default translations.
Some get a :count option passed, some :count and :value. I'm not
really sure these are done in a consistent either, too.

> Furthermore, why aren't all the other modules in their proper scope?
> Why isn't number in the action_pack scope and date in the
> active_support scope? Same goes for date/time.

I just picked them this way because I thought even though date formats
etc. are added from actionpack and activesupport these are kind of
crosscutting things, not specific to these libraries. While
ActiveRecord error messages certainly are.

I don't feel strong about this at all.

Any other opinions?

> Should we be having those underscores even there? I thought DHH's
> preference was without underscores?

Hu? Eh. Yo ... didn't know about that. Yeah, maybe it's nicer without
them.

> Give me your thoughts (and I promise I'll take good care of them ;) )

Great :)

Can you manage this task? So that we'd have consistent and useful keys
when Rails 2.2 gets out of the door?

I'm a bit swamped these days ...


--
sven fuchs sven...@artweb-design.de
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)


iain

unread,
Aug 12, 2008, 2:54:01 PM8/12/08
to rails-i18n
> sven fuchs              svenfu...@artweb-design.de
> artweb design          http://www.artweb-design.de
> grünberger 65          + 49 (0) 30 - 47 98 69 96 (phone)
> d-10245 berlin          + 49 (0) 171 - 35 20 38 4 (mobile)

Sven,

I'll take that challenge. All for fame and glory, right?

Iain

Sven Fuchs

unread,
Aug 12, 2008, 3:16:20 PM8/12/08
to rails...@googlegroups.com
On 12.08.2008, at 20:54, iain wrote:

<snip>

>>> blank: "{{attribute}} can't be blank"
>> You can now do that with the custom messages. Oh! No, the attribute
>> name is not passed, right? I agree that would be useful.
>>
>> I'd not change the default error messages for this Rails version
>> though.
>>
>> Another thought: It would be awesome if on your translations list
>> there would be the variables listed that are available for the
>> translations even when they're not used in the default translations.
>> Some get a :count option passed, some :count and :value. I'm not
>> really sure these are done in a consistent either, too.

<snap>

> I'll take that challenge.

Awesome!

> All for fame and glory, right?


Sure :)

"Planets devastated
Mankinds on its knees
A saviour comes from out the skies
In answer to their pleas"

Hmmm ... as you'd touch Rails (right?) it most probably would make
sense if you'd work on this branch:

http://github.com/svenfuchs/rails/tree/i18n

... cause I've already done some work on the yaml part. No actual yaml
files, yet, though iirc.

Btw do you have an IM account? Might be useful for quick questions?
Mine is sven...@jabber.org

Also I've started hanging out on #rails-i18n on irc.freenode.net


--
sven fuchs sven...@artweb-design.de

iain

unread,
Aug 14, 2008, 2:50:18 PM8/14/08
to rails-i18n
> Mine is svenfu...@jabber.org
>
> Also I've started hanging out on #rails-i18n on irc.freenode.net
>
> --
> sven fuchs              svenfu...@artweb-design.de
> artweb design          http://www.artweb-design.de
> grünberger 65          + 49 (0) 30 - 47 98 69 96 (phone)
> d-10245 berlin          + 49 (0) 171 - 35 20 38 4 (mobile)



Hi all,

An important message!

I've done the first update, in cleaning up the scope for ActiveRecord.
Although I'll be adding more translation functions later, I did manage
to convert all old usage.

Short list of changes in scope:
- main scope was active_record, it is activerecord now.
- anything related to error messages is in activerecord.errors scope
- the header messages for the helper method error_messages_for() is in
activerecord.errors.template.header and .body
- all messages are in activerecord.errors.messages
- override default messages for a specific model:
activerecord.errors.messages.custom.MODELNAME
- override default messages for a specific attribute:
activerecord.errors.messages.custom.MODELNAME.ATTRIBUTE
Not really error related, but used by error messages:
- Translations of your model should go in
activerecord.models.MODELNAME
- translations of your model should go in
activerecord.attributes.MODELNAME.ATTRIBUTE

Some extra functionality:
- all error messages have can interpolate {{model}} and {{attribute}}
if you'd like
- get the translation of your attribute easily with the
human_attribute_name method:
MyModel.human_attribute_name("attribute_name")
- single table inheritance is available for attribute names. when you
have class Admin < User, translation of attribute names are first
sought in activerecord.attributes.admin.title and if that wasn't there
in activerecord.attributes.user.title.
- same goes for error messages. in order of key lookups (with the
blank error message):
activerecord.errors.messages.custom.admin.title.blank,
activerecord.errors.messages.custom.admin.blank,
activerecord.errors.messages.custom.user.title.blank,
activerecord.errors.messages.custom.user.blank,
activerecord.errors.messages.blank

See my commit at http://github.com/svenfuchs/rails/commit/ffeab4e0c171aecced4ddbe29b82aed064be9bdb
See the yaml form of the activerecord scope, fully filled in, with
comments: http://pastie.org/253107

Still to be done:
- Some general way to get model translations, like Model.human_name or
something
- Providing yaml files for activerecord itself, defaults will be
loaded from it (now it's still ruby hashes)

Install procedure for now:
- cd RAILS_ROOT/vendor
- git clone git://github.com/svenfuchs/rails.git
- cd rails
- git branch clean-scopes origin/clean-scopes
- git checkout clean-scopes

Please have a look and give some feedback!

Regards,
Iain

iain

unread,
Aug 16, 2008, 11:25:16 AM8/16/08
to rails-i18n
I seem to have overlooked that custom error messages scope might run
into problems when you have attributes with the same name as error
messages.

activerecord.errors.messages.custom.topic.invalid

is that an error message or an attribute?

so I was thinking:

activerecord.errors.models and activerecord.errors.attributes

it shortens up the scope, and it's quite obvious as far as I'm
concerned. Any objections for this method?

Iain
> See my commit athttp://github.com/svenfuchs/rails/commit/ffeab4e0c171aecced4ddbe29b82...

Sven Fuchs

unread,
Aug 19, 2008, 4:23:19 AM8/19/08
to rails...@googlegroups.com
So for example, we'd check

activerecord.errors.attributes.topic.invalid
activerecord.errors.models.post.invalid

in this order? One thing I don't particulary like about it is that the
translations are then spread across different scopes.

Would it make sense to check

activerecord.errors.models.post.attributes.topic.invalid
activerecord.errors.models.post.invalid

in this order instead?

I'm not sure in what cases it is sane to use

activerecord.errors.attributes.topic.invalid

at all ... it smells a bit like reusing keys to me, which imo is an
antipattern in most situations.
--
sven fuchs sven...@artweb-design.de

iain

unread,
Aug 19, 2008, 5:06:36 PM8/19/08
to rails-i18n
I wasn't really clear on what I meant. What I suggested was:

activerecord.errors.attributes.topic.title.invalid
activerecord.errors.models.topic.invalid
activerecord.errors.messages.invalid

although the one you suggested is also okay, I guess:

activerecord.errors.models.post.attributes.topic.invalid
activerecord.errors.models.post.invalid
activerecord.errors.messages.invalid

I don't feel comfortable making this decision.

Besides, I'm running into some problem in turning the en-US.rb file
into a yaml file for actionpack. The other modules (activerecord and
activesupport) all work, but when I change it in actionpack, the test
break, and the number_to_* all seem to return the number
unformatted... I'll split it into two separate patches and tickets in
lighthouse.

Sven Fuchs

unread,
Aug 20, 2008, 11:29:25 AM8/20/08
to rails...@googlegroups.com
Hi Iain,

On 19.08.2008, at 23:06, iain wrote:
> I wasn't really clear on what I meant. What I suggested was:
>
> activerecord.errors.attributes.topic.title.invalid
> activerecord.errors.models.topic.invalid
> activerecord.errors.messages.invalid
>
> although the one you suggested is also okay, I guess:
>
> activerecord.errors.models.post.attributes.topic.invalid
> activerecord.errors.models.post.invalid
> activerecord.errors.messages.invalid
>
> I don't feel comfortable making this decision.

I'd go with the latter one because you have everything that belongs to
one model in one scope then.

IIRC we also support AR STI inheritance, so for a class Post < Content
we'd have

activerecord.errors.models.post.attributes.topic.invalid
activerecord.errors.models.post.invalid
activerecord.errors.models.content.attributes.topic.invalid
activerecord.errors.models.content.invalid
activerecord.errors.messages.invalid

?

Seems a bit fine-grained, but in the end it's just a convention and
hash lookups are fast so maybe it's ok to support all of these.

> Besides, I'm running into some problem in turning the en-US.rb file
> into a yaml file for actionpack. The other modules (activerecord and
> activesupport) all work, but when I change it in actionpack, the test
> break, and the number_to_* all seem to return the number
> unformatted... I'll split it into two separate patches and tickets in
> lighthouse.

What sort of problem is that?

I think we should get these things into core pretty soon so we have a
chance to test everything before RailsConf.
--
sven fuchs sven...@artweb-design.de

Sven Fuchs

unread,
Aug 20, 2008, 12:53:08 PM8/20/08
to rails...@googlegroups.com
>> Besides, I'm running into some problem in turning the en-US.rb file
>> into a yaml file for actionpack. The other modules (activerecord and
>> activesupport) all work, but when I change it in actionpack, the test
>> break, and the number_to_* all seem to return the number
>> unformatted... I'll split it into two separate patches and tickets in
>> lighthouse.
>
> What sort of problem is that?

Got it.

see http://i18n.lighthouseapp.com/projects/14948-rails-i18n/tickets/9-change-ruby-locales-to-yaml-locales#ticket-9-3

I applied all of your patches (including the actionpack translations,
that were just some minor typos etc) to my Rails branch:

http://github.com/svenfuchs/rails/commits/i18n/

> I think we should get these things into core pretty soon so we have a
> chance to test everything before RailsConf.

Iain, could you take care of the #generate_message and custom
activerecord messages part (i.e. the changed scopes we've discussed)?

iain

unread,
Aug 20, 2008, 2:18:53 PM8/20/08
to rails-i18n
Great news.

I will do the scope thingy and maybe have a look at the scaffolding
too.

On Aug 20, 6:53 pm, Sven Fuchs <svenfu...@artweb-design.de> wrote:
> >> Besides, I'm running into some problem in turning the en-US.rb file
> >> into a yaml file for actionpack. The other modules (activerecord and
> >> activesupport) all work, but when I change it in actionpack, the test
> >> break, and the number_to_* all seem to return the number
> >> unformatted... I'll split it into two separate patches and tickets in
> >> lighthouse.
>
> > What sort of problem is that?
>
> Got it.
>
> seehttp://i18n.lighthouseapp.com/projects/14948-rails-i18n/tickets/9-cha...
>
> I applied all of your patches (including the actionpack translations,  
> that were just some minor typos etc) to my Rails branch:
>
> http://github.com/svenfuchs/rails/commits/i18n/
>
> > I think we should get these things into core pretty soon so we have a
> > chance to test everything before RailsConf.
>
> Iain, could you take care of the #generate_message and custom  
> activerecord messages part (i.e. the changed scopes we've discussed)?
>
> --
> sven fuchs              svenfu...@artweb-design.de

iain

unread,
Aug 20, 2008, 5:50:25 PM8/20/08
to rails-i18n
The scope stuff is done. Patch is at lighthouse, as usual.
Reply all
Reply to author
Forward
0 new messages