The problem is that I18n can’t choose anything, because when the file
is read, the second one overwrites the first one. This is done outside
I18n.
It’s logical too, because you’re actually saying something like this:
{ :foo => 1, :foo => 2 } which will always result in { :foo => 2 }.
Gem authors should put their locales in front of the load_paths, so
that the locales from gems are overwritten by your own locales.
I guess you misunderstood what is happening here… But you are right
that I18n can give better hints instead of failing that way.
The key is not defined twice, I guess. I would guess that I18n searchs
for a translation of a key with the name of the route (or are you using
some plugin that does translate the route?). If it is a common behavior
of I18n, it could be written to verify if the value is a String before
calling gsub. It could assume the default (not translating the key)
otherwise.
I’ll take a look at the documentation to see how I18n behaves about
route translations.
The key is not defined twice, I guess. I would guess that I18n searchs
for a translation of a key with the name of the route (or are you using
some plugin that does translate the route?).
I am a colossal ass. I am using the translate_routes plugin and
completely forgot. That’ll be the source of all of these problems,
nothing to do with I18n. I’m going to go and punch myself in the balls
a few times.
Sorry for all the confusion guys, and thanks again for your help.
I am a colossal ass. I am using the translate_routes plugin and
completely forgot. That’ll be the source of all of these problems,
nothing to do with I18n. I’m going to go and punch myself in the balls
a few times.
Sorry for all the confusion guys, and thanks again for your help.
Don’t torture yourself. Do something more useful instead: fill an issue
in their github Issues page stating this problem. They could improve
their plugin for not breaking the application on these cases… Or you
could save your energy avoiding puching your balls and try to write some
patch to the plugin that verify if the translation is a string before
using it…
Best regards,
Rodrigo.
thanks rodrigo, that does sound like a better use of my time and energy.
I am a colossal ass. I am using the translate_routes plugin and
completely forgot. That’ll be the source of all of these problems,
nothing to do with I18n. I’m going to go and punch myself in the balls
a few times.
Sorry for all the confusion guys, and thanks again for your help.
Don’t torture yourself. Do something more useful instead: fill an issue
in their github Issues page stating this problem. They could improve
their plugin for not breaking the application on these cases… Or you
could save your energy avoiding puching your balls and try to write some
patch to the plugin that verify if the translation is a string before
using it…