https://bugzilla.redhat.com/show_bug.cgi?id=1678787
Vladimír Slávik vslavik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mfabian@redhat.co | |m) |
--- Comment #5 from Vladimír Slávik vslavik@redhat.com --- Got it now. The bug is actually quite fascinating. It can be interpreted in two ways:
- Anaconda should not show locales ("languages") that don't have a translation (see above) - The Chinese translation is laid out in a different manner than others and thus prevents successful fallbacks (see below)
----
How this works. Ultimately we try to set the locale specified by UI (whether translation exists or not), and it all bubbles down to setlocale(3). This somehow decides if a locale is valid or not. Then we try to load the translation for that, with gettext. What happens next is that gettext tries to fall back on simplified specifications of the locale (_nl_make_l10nflist, around line 300-ish).
What I *think* is the case -intentionally- is that these fallbacks built into gettext have been used in a clever way to make translations match-able to all locales - or rather most of them. For anaconda specifically, the cases are: - English is already the default, so nothing could be noticed without a deep inspection of the texts. - Many languages have precisely one locale so the distinction between the language and a language+territory is moot (Czech, Filipino...). - Some languages have tons of locales but provide translation only for the base language, so all of the locales fallback onto that if selected (eg. Spanish, French...). - Some languages have the bare language translation and then some of their locales have their specific translation too, so everything is translated. (Portuguese, Serbian...). - Some languages have translation per language, and their locales should differ significantly and do not because they all fall back onto the bare language (Punjabi?). - Some languages have only translations per locale, and not all locales are covered, so their fallbacks can't go anywhere (Chinese).
Arguably, having zh_CN translations as zh would fix the problem for us.
---
The code-based solution would be to add a check if translation for a particular locale exists, and use that when adding locales. The problem with that is that it would have to take into account gettext's fallback algorithm, and I'm not sure if that can be reused.