Fallback error on t([]) #104

Closed
garrettlancaster opened this Issue Aug 2, 2011 · 7 comments

Comments

Projects
None yet
6 participants

Fallbacks are not working when fetching multiple strings.

Steps to reproduce:

  1. set up fallback to default language:
    • require "i18n/backend/fallbacks"
    • I18n::Backend::Simple.send(:include, I18n::Backend::Fallbacks)
  2. try to fetch multiple strings that are missing in the current locale, but present in the default locale:
    • I18n.t([:missing, :missing2])
Collaborator

knapo commented Aug 7, 2011

Related to discussion in: spastorino/i18n@3746542. Agree that it need to be consistient.

Collaborator

clemens commented May 25, 2012

What's the status of this issue?

I'm asking because @nulogy created a pull request for my delocalize gem yesterday (clemens/delocalize#44) that seems to be a result of this issue. I've just reproduced it in a vanilla Rails app with i18n 0.6.0 so I'm guessing it's still a problem? Can it be fixed in a sensible way?

If it's still open, I'd propose the solution that @svenfuchs suggested here: spastorino/i18n@3746542. So I18n.t(:specific_msg, default => [:general_msg, 'something']) should be resolved in the following order:

:specific_msg in :pl
:general_msg in :pl
:specific_msg in :en
:general_msg in :en
'something'

Anything else really doesn't make sense. The question would be how to handle values that are neither Symbol nor String – e.g. a Proc or even an Array or Hash. Does it make sense to treat everything that is not a Symbol as a literal and push it to the end of the lookup so that it gets looked up only if none of the symbolic keys matches in the locale or any of its fallbacks?

Owner

svenfuchs commented Jun 2, 2012

@clemens the status is that it's "open"

i agree the order you mention makes most sense, but i'd also like to hear @tigrish's opinion.

also ... pull requests welcome :)

Collaborator

tigrish commented Jun 5, 2012

I also agree with the order that @clemens is suggesting, that's the only one that makes any sense at all.

And yes, probably all non-symbol types can be pushed on to the end of the lookup imho since in practice they can be considered like static values.

I think this should include Nil since this is a valid value and one that you might want to pass in to a rails helper for example (I'm thinking number separators or something - sorry, I don't have a concrete example handy).

Procs on the other hand can be expected to do some computing or even some lookups of their own (ex: you might want to add defaults at run time based on the key name - actually, that sounds awesome... must have a play with that!).

So the following call

I18n.t :specific_msg, :default => [:generic_msg, Proc.new { :find_other_lookups }, 'something']

would look up in this order :

pl:
  specific_msg:
  general_msg:
  find_other_lookups:
en:
  specific_msg:
  general_msg:
  find_other_lookups:
'something'

Note how the Proc was called twice as opposed to having just been pushed to the back of the lookup.

Gotta scoot, honeymoon awaits! :)

Collaborator

clemens commented Jan 7, 2014

Guys, just wondering: What's the status here? :)

Collaborator

radar commented Nov 3, 2016

To confirm, the bug here is that when you do:

irb(main):004:0> I18n.t([:hello, :world])

It doesn't read the translations from the fallback locale, but instead outputs a message like:

=> "translation missing: pl.world"

Yeah?

@radar radar added the info-required label Nov 3, 2016

Collaborator

radar commented Nov 15, 2016

Should be fixed by #304.

@radar radar closed this Nov 15, 2016

@radar radar removed the info-required label Nov 15, 2016

@radar radar added this to the 0.8.0 milestone Nov 15, 2016

radar added a commit that referenced this issue Nov 15, 2016

Merge branch 'pr-304'
* pr-304:
  Fix fallbacks when translating key arrays

Fixes #304
Fixes #104
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment