ruby-i18n/i18n

Can't fallback to a locale with a common ancestor?

movermeyer opened this issue · 4 comments

What I tried to do

Due to a technical limitation, I need to support zh-CN as a locale fallback of zh-Hans.

I18n.fallbacks = I18n::Locale::Fallbacks.new(:root, "zh-Hans": :"zh-CN")
I18n.fallbacks[:"zh-Hans"]

What I expected to happen

[:"zh-Hans", :"zh-CN", :zh, :root]

What actually happened

[:"zh-Hans", :zh, :"zh-CN", :root]

Note that :"zh-CN" is added after zh, instead of before it, even though :"zh-CN" itself falls back to zh.

Versions of i18n, rails, and anything else you think is necessary

  • i18n: v1.8.11

This matches the behavior found in this test:

test "with a German mapping defined it returns [:de-AT, :de, :de-DE, :en-US] for de-AT" do
@fallbacks.map(:"de-AT" => :"de-DE")
assert_equal [:"de-AT", :de, :"de-DE", :"en-US", :en], @fallbacks[:"de-AT"]
end

But it's not clear to me why this is the expected behavior. I would have expected:

[:"de-AT", :"de-DE", :de, :"en-US", :en]

But I guess that depends on what you actually want to set up. The current behaviour suggests that:

  • German speakers in Austria know International German better than German from Germany

But if it were the other way around, how could you configure it?

radar commented

How it is performing now is correct. For instance, you might define en-GB to have a fallback to en-US, but both would (automatically) fallback to en, (see I18n::Locale::Fallbacks#compute for the code behind this).

Is there a reason why you couldn't define the translation strings you want in zh and not in zh-CN and then rely on the standard fallback for both zh-CN and zh-hans to be zh?

radar commented

I took a look at this code briefly this morning and I am not sure how to change it to support your usecase and to also maintain existing behaviour.

Thanks @radar, I spent a day playing with the code and came to the same conclusion: it can't be done in the current model / code.

I'll think more about how this feature might work, and if there are other use cases where this would be helpful.
If I come up with something, I'll open a feature request / PR.


Is there a reason why you couldn't define the translation strings you want in zh and not in zh-CN and then rely on the standard fallback for both zh-CN and zh-hans to be zh?

I don't have control over the translation files themselves. There may be workarounds I could do though. Another avenue to explore.


Thanks for your time. ❤️