Hi! On Thu, 2026-04-09 at 20:07:32 +0000, [email protected] wrote: > Am 09.04.2026 18:44 schrieb Guillem Jover: > > example /usr/share/i18n/SUPPORTED. The sr_Latn language is thus > > (AFAICS) > > invalid for gettext purposes, and it should not match any locale on the > > system, and would thus also not get used. > > That po file is working fine within my application ("backintime"). > It is Python3 using gettext in the background. Also my translation > toolchain, incl. Weblate, does recognize that language identifier.
Ah, briefly checking now backintime I see there's quite some code dedicated to massaging the locale to be able to load the .mo files. So I assume that explains why that language code works with this project? (I was wondering whether/why that would be the case.) For Weblate I just checked and it seems to have explicit support for those language code as documented in <https://github.com/WeblateOrg/weblate/blob/main/docs/faq.rst#why-does-weblate-use-language-codes-such-sr_latn-or-zh_hant> which I don't think might be common in other i18n toolchains though. While this might be necessary to integrate and tie together the i18n support from Qt, python and gettext (I don't know the former two). I find that a bit strange, as backintime seems to be the only package in Debian that uses that name for that locale (excluding php and other programming language ecosystems with their own i18n support). The way this usually works is that a user specifies their locale, either via the environment (LANG, LANGUAGE, LC_*, etc) or some GUI specific setting to the same effect. And this gets used automatically by the gettext system when it gets initialized. Then gettext knows which .mo file to load based directly from that locale, and where there is then (usually) no need to specify .mo directory or its pathname. (See man bindtextdomain(3) for example.) By using an unknown locale name in backintime, then you need to be explicit about which pathname to use. I assume that if you renamed the file, you might be able to get rid of some of the complexity and code surrounding this? And then any other i18n toolchain also needs to be able to map those unknown locale names to their known counterparts, as mentioned for example by Holger. > Didn't knew about the existence of /usr/share/i18n/SUPPORTED. > Is there any documentation about it or is it mentioned in the policy > somewhere? > How is it created? I think this is just a descriptive list of locales supported by glibc, where glibc itself does not use it. It is maintained in git as-is (see «glibc.git/localedata/SUPPORTED»). > > As long as glibc and its locale definitions do not get updated to be > > aware of any different aliases, these .po files are not getting used > > at all (AFAICT). > > As I said, gettext has no problem with that po file. As mentioned above, I think only because the code makes it work that way, I don't think the common pattern of: setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); textdomain(PACKAGE); would work out-of-the-box with that language code? > I won't ask GNU to move from one to another standard. But the > question is if the Debian toolchain need to "guess the language". I > see no value in it. And it is also still not clear how this > "guessing" is implemented. I am not able to reproduce the error > message on my system. See above, ISTM the guessing/mapping is done by backintime, so that gettext can work as expected. :) This still leaves the problem that the rest of the i18n toolchain (progress stats, automated retrieval of l10n data, etc) does not support that language code and cannot group it together where it belongs. Thanks, Guillem
