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:
i18n/test/locale/fallbacks_test.rb
Lines 127 to 130 in cb4a4be
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?
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
?
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 inzh-CN
and then rely on the standard fallback for bothzh-CN
andzh-hans
to bezh
?
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.