i18n view hints broken in error messages
Reported by Iain | March 2nd, 2010 @ 05:07 AM
I've just spend some time moving my old-style view-hints over to i18n, but now that I'm testing it, I've noticed that hobo isn't translating my field names inside the validation error messages.
For example, say I have a model:
Foo < ActiveRecord::Base
hobo_model
fields do
bar :string
end
validates_presence_of :bar
end
And a viewhint for this model in app.en.yml:
en:
foo:
bar: "Hello World"
Then if I try to create a Foo without specifying bar, the error message will say:
"Bar can't be blank"
whereas you'd expect it to say:
"Hello World can't be blank"
Comments and changes to this ticket
-
Domizio Demichelis May 8th, 2010 @ 12:43 AM
Errors messages get correct translation in the canonical-I18n fork
-
Matt Jones October 4th, 2010 @ 12:21 AM
Just ran across this helping Scorpio chase down some i18n misbehavior. The problem is that the error-messages tag calls human_attribute_name, which we have are intercepting to look up stuff in viewhints. BUT, we're only checking to see if the field is a key in field_names, not actually calling field_name (where the i18n hook is).
For the near term, setting attribute names in the AR standard place (activerecord.attributes.model_name.attribute_name) works, but it's not very DRY.
-
Domizio Demichelis October 4th, 2010 @ 02:51 PM
- State changed from “new” to “invalid”
- Assigned user set to “Domizio Demichelis”
What is not DRY IMHO is setting the view hint name under their own keywords and try to use that instead of using the canonical i18n AR namespace.
The general policy here is that we should try to use the canonical rails stuff as much as possible, and eventually add more feature for what is missing.
Following that policy, the view hints should be used only to give hints about HOW to display stuff (because rails does not supply such a mechanism), and stick to the "rails way" for data like attribute names which rails does handle.
Another important thing to notice here is that under the generic "attributes" keyword you can lookup fields names, association names, even method names, and add singular and plural translations when needed. In practice all that is referenced with record.<method> can be labeled, changed, translated, pluralized and interpolated by just adding <method> under the attributes key. That's very powerful, flexible, lite, easy, and is done by just using the human_attribute_name method.
And I wouldn't add any fallback to any non AR keys, because we should enforce the canonical way instead of reinventing the wheel.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Adam Hoscilo
Domizio Demichelis