search

ruby-i18n / i18n

Internationalization (i18n) library for Ruby
MIT License
986 stars 411 forks source link

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

Closed movermeyer closed 2 years ago

movermeyer commented 3 years ago

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

movermeyer commented 3 years ago

This matches the behavior found in this test:

https://github.com/ruby-i18n/i18n/blob/cb4a4be9a13ae03b7b6d0678a3ad00dd790ee240/test/locale/fallbacks_test.rb#L127-L130

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:

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

radar commented 3 years ago

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 3 years ago

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.

movermeyer commented 2 years ago

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. ❤️