https://bugzilla.redhat.com/show_bug.cgi?id=1678787
Vladimír Slávik <vslavik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|anaconda-maint-list@redhat. |vslavik(a)redhat.com
|com |
Flags| |needinfo?(mfabian(a)redhat.co
| |m)
--- Comment #4 from Vladimír Slávik <vslavik(a)redhat.com> ---
It's probably worth considering why this works for everything else. I think
somewhere in the whole works there's a fallback to the language's default
locale-translation in case the selected locale is not translated. (See below
why this should be the case.) But why does this not work for zh_SG in
particular? Mike, could you please check langtable's data if there is anything
special for this case? It might be that there's a default missing, impossible,
or something along these lines.
----
Notes to self...
The offending item as of now is zh_SG it seems.
It might be we keep shooting ourselves in foot, as far localization is
concerned. In LangLocaleHandler.initialize() we first list languages with
translations, then we put these on a list and add locales to these. Except
translations are for the "locales", not languages. My terminology might be
wrong here, so an example - we detect files for zh_CN and say we have zh. So
the whole premise of get_available_translations() might be wrong. It gives us
languages (zh), but these are not actually a correct representation of what is
available, it's locales (zh_CN) that get translations. Then later we try to
rectify that by adding the actual locales to the second list, as sub-items for
the languages. That itself is correct, but not enough. We depend on langtable
to give us the locales via get_language_locales(), and disregard the
earlier-found (non)presence of translations.
That adds a dilemma, as LangLocaleHandler is a mixin used in both the welcome
spoke and language/localization spoke. The former should filter by available
translations (see this bug), the latter most probably not. One way might be to
have some sort of filter on WelcomeLanguageSpoke._add_locale(). That might need
memoizing as the locales are apparently re-listed on every language change on
that spoke.
While at it, it might be beneficial to rethink this whole "store stuff in gtk
container instead of a python structure" approach. But it might grow the scope
too much, too.
Regardless of all that, a langtable-only fix can not be ruled out, per the
first paragraph.
--
You are receiving this mail because:
You are on the CC list for the bug.