Rails translation scope cleanup
iain
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
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
> grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
> d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)
I'll take that challenge. All for fame and glory, right?
Iain
Sven Fuchs
<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
> sven fuchs svenfu...@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)
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
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
Sven Fuchs
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
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
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.
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.
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
>> 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.
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
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.
>
> 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)?
>
> --