Hi!
On Fri, 2026-04-10 at 13:32:56 +0000, [email protected] wrote:
> 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
I just checked now and I can confirm what I initially suspected (but
where I was confused to think it might be worked around in the
backintime code) that this does not work. See below.
> > 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.
But gettext does really care, because the user can only use a locale
that the system has definitions for. These definitions describe how
the locale behaves (and how the code needs to handle data), such as
the collation, numbers, time, monetary, and all other i18n data (see
/usr/share/i18n/locales/* for all such definitions).
If a user specifies an invalid locale then the system will not know
how to handle that in the code, and will neither be able to find
translations for other components (such as error messages from
libraries the program is calling).
Precisely because there is no guessing (besides trying the support
variants from a known locale, for example for sr_RS@latin the system
will try variants like sr_RS.UTF-8@latin, sr_RS@latin, sr@latin, sr,
etc.), using invented locale names breaks the system.
I just tried now with backintime, and I can see that it indeed does
not work. In a sid chroot:
,---
$ sudo eatmydata apt install backintime-qt locales-all
$ LANG=sr_Latn locale | head -n2
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=sr_Latn
LANGUAGE=
LC_CTYPE="sr_Latn"
$ LANG=sr_RS@latin locale | head -n3
LANG=sr_RS@latin
LANGUAGE=
LC_CTYPE="sr_RS@latin"
$ LANG=sr_RS@latin strace -f backintime --help 2>&1 | grep 'backintime\.mo.*
= 0'
[pid 1569781] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
[pid 1569781] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
[pid 1569781] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
$ sudo cp /usr/share/locale/sr_Latn/LC_MESSAGES/backintime.mo \
/usr/share/locale/sr@latin/LC_MESSAGES/backintime.mo
$ LANG=sr_RS@latin strace -f backintime --help 2>&1 | grep 'backintime\.mo.*
= 0'
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr@latin/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=28261, ...}, 0) = 0
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr@latin/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=28261, ...}, 0) = 0
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr@latin/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=28261, ...}, 0) = 0
[pid 1570553] newfstatat(AT_FDCWD,
"/usr/share/locale/sr/LC_MESSAGES/backintime.mo", {st_mode=S_IFREG|0644,
st_size=37841, ...}, 0) = 0
`---
So as you can see, when using the supported locale ("sr_RS@latin"), it
will fallback to use only the messages for "sr" because it cannot find
the variant, and at no point it will try to use the sr_Latn messages.
When copying the file from the invented locale to the known one, then it
can load both the "sr@latin" as an overlay over the "sr" messages.
Thanks,
Guillem
