LANG and LANGUAGE environment variable in Debian based systems

Question

It seems both the LANG and LANGUAGE environment variable are used by some programs to determine their user interface language.

What are the exact semantics of these variables and where can I read about their correct usage? The manpage for locale(1) only mentions the LC_* family of environment variables. Additionally there is also an LC_ALL variable commonly in place which isn't described there either.

Solution 1

LANG contain the setting for all categories that are not directly set by a LC_* variable.

LC_ALL is used to override every LC_* and LANG and LANGUAGE. It should not be set in a normal user environment, but can be useful when you are writing a script that depend on the precise output of an internationalized command.

LANGUAGE is used to set messages languages (as LC_MESSAGES) to a multi-valued value, e.g., setting it to fr:de:en will use French messages where they exist; if not, it will use German messages, and will fall back to English if neither German nor French messages are available.

Solution 2

Have a look at the manpage locale(7): it describes that LANG is a fallback setting, while LC_ALL overrides all separate LC_* settings.

Solution 3

For reference, the locale system is GNU GetText, which has its full documentation available in the gettext-doc package (Debian/Ubuntu).

Alternatively, there is an online manual with authoritative and elaborate documentation of the LANG and LANGUAGE environment variables.

Comments

[aef]

Where can I find documentation about LANGUAGE? Is it mutually exclusive to LC_MESSAGES?

[Rémi]

Everything is in the locale(7) manpage. LC_MESSAGES changes the language messages are displayed in and what an affirmative or negative answer looks like. The GNU C-library contains the gettext(3), ngettext(3), and rpmatch(3) functions to ease the use of these information. 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".

[Édouard Lopez]

@Rémi can you elaborate on why LC_ALL should not be used?

[Rémi]

Not much to say. You have more flexibility if you set LANG than if you set LC_ALL: you can set LANG to something and LC_COLLATE to some other thing. If you set LC_ALL, every other configuration are hidden.

[Smile4ever]

man 7 locale is the command

[Murmel]

I don't think LC_ALL overrides LANGUAGE: 1. they have different meanings (order [e.g.: fr:de:en] vs. characteristics[e.g.: fr_FR])

[Murmel]

2. The GNU getText documentation's chapter Specifying a Priority List of Languages states: gettext gives preference to LANGUAGE over LC_ALL and LANG. Additionally, the chapter Locale Environment Variables states: 1. LANGUAGE 2. LC_ALL [...]

[Bachsau]

$LANGUAGE is not part of the C locales, but specific to GNU gettext. If set it is given precedence over anything else. I'm using it my own applications to avoid mixed languages when using gettext based libraries.

[Admin]

@Bachsau @Murmel Clarifying point: that GNU getText documentation states the LANGUAGE is given precedence over LC_ALL and LANG for the purpose of message handling, and then only if LANG (or LC_ALL) is set to something other than 'C'.

[Admin]

@SpinUp Of course, because C is the fallback used when no LC_* or LANG variables are set. It disables all handling of locales and encoding, using only raw binary data. Even if LANGUAGE is set, gettext still uses the current locale to determine encoding. If there is none, there's nothing to encode to.

[Admin]

@Bachsau The most important point which is not clear in your comment or the one above it is that LANGUAGE only overrides LC_MESSAGES, having no effect on the other LC* variables.

[Admin]

@SpinUp Regarding your LC_MESSAGES comment, I thought that to be self-explaining, as gettext is only engaged in handling messages.