Re: Possible 0.12.1 bug with LANG/LANGUAGE handling

[Bruno Haible]

Nick Lindridge wrote:
> If we
> set LANG to just en, then our program operates in English and the setting
> of LANGUAGE is ignored.

You shouldn't do this. The current ABOUT-NLS says:

   In the `LANGUAGE' environment variable, but not in the `LANG'
   environment variable, `LL_CC' combinations can be abbreviated as `LL'
   to denote the language's main dialect.

Why is LANG=en not allowed? Because LANG is a setting for the entire
locale, including monetary information, and this depends on the contry:
en_GB, en_AU, en_ZA all have different currencies.

> The following steps illustrate this. As gettext is fairly mature we've
> probably missed something but I don't know what. In this it can be seen
> that the getopt library continues to report errors in German whereas our
> application drops back to English once LANG has been set to en, even
> though LANGUAGE is still set as de
>
> address@hidden:/tmp > setenv LANG en_GB
> address@hidden:/tmp > unsetenv LANGUAGE
> address@hidden:/tmp > gtest --xx
> gtest: unrecognized option `--xx'
>
> Error: Please check the user guide for help

This is correct. When LANGUAGE is not set, the value of LANG matters.
But no translator has bothered to translate "unrecognized" to "unrecognised"
for en_GB, maybe because both spellings are valid in British English.

> address@hidden:/tmp > setenv LANGUAGE de
> address@hidden:/tmp > gtest --xx
> gtest: Unbekannte Option »--xx«
>
> Fehler: Um Hilfe zu erhalten, sehen Sie bitte im Benutzerhandbuch nach.

This is correct. LANGUAGE overrides LANG.

> address@hidden:/tmp > setenv LANG en
> address@hidden:/tmp > gtest --xx
> gtest: Unbekannte Option »--xx«
>
> Error: Please check the user guide for help

As mentioned above, LANG=en results in undefined behaviour.

Bruno