Hello Guillem,
thank you for asking back.
Am 10.04.2026 13:45 schrieb Guillem Jover:
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.
Yes, that is the case. But by default backintime will use the systems
local and also the systems local directory. There is now hacking around
that.
All language files installed in
/usr/share/locale/$lang/LC_MESSAGES/backintime.mo
e.g.
/usr/share/locale/sr_Latn/LC_MESSAGES/backintime.mo
So I assume that explains why that language code works with this
project? (I was wondering whether/why that would be the case.)
No. I just think that the gettext system doesn't care if the language
identifier makes sense or not. I could name it "foobar" or "gibberish"
I would like.
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).
The complexity comes from Qt and the feature to make the language
customizable by the user.
Again: BIT does not hack around the local directory or language
identifer.
It is used automatically by the gettext system.
By using an unknown locale name in backintime, then you need to be
explicit about which pathname to use.
See above. This is in my experience and understanding not the case.
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»).
But where does glibc get this list from? There need to be a standard
or some thing.
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?
Again, my BIT code does not "make it work". It works out of the box.
<https://github.com/bit-team/backintime/blob/250edd748ccaddc8130ed3b1f884f50209168413/common/tools.py#L200>
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.
The i18n toolchain does support it. Only this one language guessing step
is not able to handle it.
The problem is not that big.
IMHO the primary question is why the Debian toolchain does this language
guessing?
Is there a need for it? What does it prevent?
Again "sr_Latin" is a valid code in context of IETF standard.
Regards,
Christian
