LANGUAGE env Variable only works after "printenv" or "locale"

ivvixxivvi · 2024-11-23 00:23:14

Hello,
I installed arch in an VM on Ubuntu. In the Installation, I only set:

/etc/locale.conf

LANG=de_DE.UTF-8

I only have a root user and did nothing more than the installation.

Since I want English text instead of German, I changed my /etc/locale.conf to:

/etc/locale.conf

LANG=de_DE.UTF-8
LANGUAGE=en_US:en_GB:en:C:de

Then I rebooted.

Now, when I test it by writing a none existing command, the "command not found" text is in German.

When I do:

#printenv LANGUAGE
en_US:en_GB:en:C:de

Afterward, the "command not found" is in English.

How can I get LANGUAGE working at startup, please?

Further Information:

I can also use

 locale

instead of printenv for it to change the language. But locale is in the output missing the LANGUAGE entry, I'm not sure if this is normal.

Furthermore, did I notice when I use the help command after login, when the language is German, the result is German too. But help doesn't change its language to English after printenv/ locale, it just stays German.
However, when I use help after printenv/ locale, without using it when the system thought it should use German apparently, the result is in English.

Last edited by ivvixxivvi (2024-11-23 00:30:00)

Scimmia · 2024-11-23 00:27:26

If you want english, why didn't you change LANG? Why set LANGUAGE at all?

Thinking about it more, are you looking for LC_MESSAGES instead of LANGUAGE?

Last edited by Scimmia (2024-11-23 00:33:45)

ivvixxivvi · 2024-11-23 00:46:34

Scimmia wrote:

If you want english, why didn't you change LANG? Why set LANGUAGE at all?

I would like to use german date convetion for example. In the wiki it says:

Tip: Assume that you are an English user in Spain, and you want your programs to handle numbers and dates according to Spanish conventions, and only the messages should be in English. Then you could set the LANG variable to es_ES.UTF-8 and the LC_MESSAGES (user interface for message translation) variable to en_US.UTF-8.

which is kind of my usecase i think. And in locale(7) it says for

LC_MESSAGES
This category affects the language in which messages are displayed and what an affirmative or negative answer looks like. (...) The GNU gettext family of functions also obey the environment variable LANGUAGE (containing a colon-separated list of locales) if the category is set to a valid locale other than "C". (...)

So it should work with just the LANGUAGE option i think?

Rereading i just tried changing

/etc/locale.conf

LANG=de_DE.UTF-8
LANGUAGE=en_US:en_GB:en:C:de
LC_MESSAGES=en_US.UTF-8

The language is now at startup english as i want.

Scimmia wrote:

Thinking about it more, are you looking for LC_MESSAGES instead of LANGUAGE?

yes thanks, it works with this

however im still unsure if the LANGUAGE option is now working as it should?

edit:
gnu.org says for get text:

When a program looks up locale dependent values, it does this according to the following environment variables, in priority order:
LANGUAGE
LC_ALL
LC_xxx, according to selected locale category: LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, ...
LANG
Variables whose value is set but is empty are ignored in this lookup.
(...)
GNU gettext gives preference to LANGUAGE over LC_ALL and LANG for the purpose of message handling, but you still need to have LANG (or LC_ALL) set to the primary language; this is required by other parts of the system libraries. (..)

Last edited by ivvixxivvi (2024-11-23 01:29:50)

seth · 2024-11-23 13:41:22

LANGUAGE is relevant for fallback language selection - "LANGUAGE=en_US:en_GB:en:C:de" is nonsensical since there's always gonna be "C", de won't be reached.
Also it's not parsed by every last client (though by everything using gettext) and if you're running plasma, see https://wiki.archlinux.org/title/KDE#Pl … e_settings

LANG=de_DE.UTF-8
will automatically get you
LC_NUMERIC="de_DE.UTF-8"
LC_TIME=de_DE.UTF-8
LC_MONETARY="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
ie sane DIN and setting "LC_MESSAGES=C" will get you the untranslated messages

Idk how printing the environment could possibly alter anything about it, but if you end up setting something inside the shell, that doesn't affect the shell process itself.
Compare

printenv

and

tr '\0' '\n' < /proc/$$/environ

ivvixxivvi · 2024-11-23 18:16:46

seth wrote:

LANGUAGE is relevant for fallback language selection - "LANGUAGE=en_US:en_GB:en:C:de" is nonsensical since there's always gonna be "C", de won't be reached.

Oh alright thank you. In Arch wiki locale 3.2 , the example is similar so i thought there might be a reason, but i guess its just for clarification of the note.

seth wrote:

Idk how printing the environment could possibly alter anything about it, but if you end up setting something inside the shell, that doesn't affect the shell process itself.
Compare
printenv
and
tr '\0' '\n' < /proc/$$/environ

thanks, yes im now sure LANGUAGE is set correctly.

Furthermore its not just printenv, a lot of the coreutils functions influence the language apperantly. It also works after "cat" or "dd" for example.

It somehow dosent work after "echo" tho. I thought it might have something to do with the setlocale() call in these functions, but echo does too...

But I believe this is might either a Bug of the bash/sh shell or they dont follow the specification for some reason or i didnt understand the specs correctly..

seth · 2024-11-23 18:28:42

It somehow dosent work after "echo" tho

type -a echo

Does "/usr/bin/echo" behave different from "echo"?

I don't have much personal experience w/ the LANGUAGE variable, but the example links a kde bug from 2009 where the objection was that LANGUAGE=en_US:de_DE still got them german output (because many things will come w/o a specific english locale, but of course will have german one) and the desire to have german only as fallback if there's no english at all, so they came up w/ "en_US:C:de_DE" but that's a fallacy. "C" isn't english, it's "C" - the untranslated string.
If the code is in chinese, you'll either get an english locale or chinese - not german (even if there's a translation)

Do you get the same behavior on a shell for real men decadent hedonists like zsh?

ivvixxivvi · 2024-11-23 23:54:41

seth wrote:

It somehow dosent work after "echo" tho
type -a echo
Does "/usr/bin/echo" behave different from "echo"?

Yes it does, with bash/sh echo the languages doesnt change. With "/usr/bin/echo" it does. I think bash echo is not the coreutils echo, but a different builtin echo. Other built in commands like "cd" or "enable" also do not change the language.

seth wrote:

Do you get the same behavior on a shell for real men decadent hedonists like zsh?

no but i think the reason is, that zsh doesnt support another language. Or atleast i didnt yet find one that zsh supports. I tried german, spanish and chinese. (i mean the "command not found msg", other command output is in the correct language, like nano for example)

seth · 2024-11-24 19:53:32

bash echo is not the coreutils echo

This.

Is only the "command not found" token affected?
You're right, zsh doesn't localize that, but eg "cd gnarf" will get you "datei oder Verzeichnis nicht gefunden: gnarf"

Arch Linux

#1 2024-11-23 00:23:14

LANGUAGE env Variable only works after "printenv" or "locale"

#2 2024-11-23 00:27:26

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#3 2024-11-23 00:46:34

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#4 2024-11-23 13:41:22

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#5 2024-11-23 18:16:46

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#6 2024-11-23 18:28:42

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#7 2024-11-23 23:54:41

Re: LANGUAGE env Variable only works after "printenv" or "locale"

#8 2024-11-24 19:53:32

Re: LANGUAGE env Variable only works after "printenv" or "locale"

Board footer