[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'LANG=' produces German output

From: Bruno Haible
Subject: Re: 'LANG=' produces German output
Date: Thu, 13 Feb 2020 19:19:18 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

[CCing bug-gettext]
[Replying to 
https://lists.macports.org/pipermail/macports-users/2020-February/048001.html ]

> It's seems to be a new feature of gettext 0.21, which comes with
> improved MacOS support.  In the NEWS file I read
>   * Runtime behaviour:
>     - The interpretation of the language preferences on macOS has been
>       improved, especially in the case where a system locale does not
>       exist for the combination of the selected primary language and
>       the selected territory.

and for 0.20:

  * Runtime behaviour:
    - The interpretation of the language preferences on macOS has been fixed.

> In my shell, `set` shows
>   LANG=en_US.UTF-8
> (and `LANGUAGE` is not set).
> Some test results:
>    LANG=C bison --help             English output

This is because in the "C" locale, gettext() does not do any message catalog
lookup. For some programs, POSIX prescribes the output in the "C" locale to
the letter; so, LC_ALL=C (or LANG=C, if you have no LC_* environment variable
set) produces untranslated output.

>    bison --help                    English output
>    LANGUAGE= bison --help          English output

In this case, LANG=en_US.UTF-8 instructs gettext() to produce the English
translation. For most translation domains, there is nothing to translate.

>    LANG= bison --help              German output

In this case - neither LANG nor any LC_* environment variable set - the
output is unspecified by the standards (see POSIX [1] "If the locale value
is not recognized by the implementation, the behavior is unspecified.").
On platforms which have a system preferences panel which does not translate
to environment variables - namely Windows and macOS -, gettext() obeys the
settings from this system preferences panel.

> I'm not sure whether I like this feature.  At least on the command
> line, I consider it surprising.

There is the opposite expectation: "I have set that I want the programs
to talk to me in German. Why do I need to specify it a second time, through
an environment variable, for the command-line programs?"


[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]