On 16/02/2024 23:35, Franco Martelli wrote:
On 16/02/24 at 03:03, Max Nikulin wrote:
LC_ALL=C.UTF-8 LANGUAGE=it aptitude why firefox-esr
here seems to override, tested twice with "it" and "it_IT.UTF-8":
~# env LC_ALL=C LANGUAGE=it script -T ~/test.time -a ~/test.script
You tested with LC_ALL=C, not with LC_ALL=C.UTF-8. It has been discussed
that behavior of gettext in respect to LANGUAGE is different.
I am against "C" locale in Debian official docs since it may mangle
output. I have posted it already:
LC_ALL=C ls /tmp/it/
''$'\303\250'
LC_ALL=C.UTF-8 ls /tmp/it/
è
root@itek:~# env LC_ALL=C LANGUAGE=it_IT.UTF-8 script -T ~/test.time -a
~/test.script
Again, LANGUAGE value is a list of *languages*, not a locale like for
LANG or LC_*. LANGUAGE can be it:en_US:en, while this value is invalid
for LC_ALL. Do not confuse these variables.
Try to add "export LC_ALL=it_IT.UTF-8" to .bashrc and e.g."date" in
the script session.
Yes, the messages are localized to it_IT.UTF-8 into the "script"
session, however users that have set LC_ALL variable into .bashrc I
suppose already know what are they doing.
They just noticed that such variable exists and added to their configs.
My colleague was bitten by LC_ALL. Is was a surprise when a database
started to use "," instead of "." as decimal separator and it took
enough time to find what caused drastic lost of precision. LC_ALL was
set by the system administrator in ~/.bashrc.
I like the idea to *suggest* people to use English locale for upgrades
if they are comfortable with it. It will help for searching web and
during discussions. However I believe that a UTF-8 locale is safer and
better nowadays. I hope, there is no mistakes any more:
LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
or its equivalent for user shell executed inside "script" session. I am
unsure if locale of "script" command can be an issue.
