https://bugzilla.redhat.com/show_bug.cgi?id=1678787
Vladimír Slávik <vslavik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(mfabian(a)redhat.co |
|m) |
--- Comment #5 from Vladimír Slávik <vslavik(a)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.
--
You are receiving this mail because:
You are on the CC list for the bug.