Re: address@hidden: language environment should not be derived from LC_CTYPE]

[Jan Djärv]

Reiner Steib skrev:
> On Thu, Nov 23 2006, Chong Yidong wrote:
> 
>> Reiner Steib wrote:
>>> $ env|grep -e LC_ -e LANG
>>> LANG=en_US
>>> LC_COLLATE=POSIX
>>> address@hidden
>>>
>>> $ emacs -Q
>>>
>>> `current-language-environment's value is "German" and I get the German
>>> tutorial.  I expected to see the English version and an English
>>> language environment:
>>>
>>> | `LC_CTYPE'
>>> |      This category applies to classification and conversion of
>>> |      characters, and to multibyte and wide characters
>>> |
> [ Quotation re-added: ]
>>> | `LC_MESSAGES'
>>> |      This category applies to selecting the language used in the user
>>> |      interface for message translation (*note The Uniforum approach::;
>>> |      *note Message catalogs a la X/Open::)  and contains regular
>>> |      expressions for affirmative and negative responses.
>>> | 
> [...]
>>> | `LANG'
>>> |      If this environment variable is defined, its value specifies the
>>> |      locale to use for all purposes except as overridden by the
>>> |      variables above.
>> >From lisp/international/mule-cmds.el:
>>
>> (defun set-locale-environment (&optional locale-name)
>>   "Set up multi-lingual environment for using LOCALE-NAME.
>> This sets the language environment, the coding system priority,
>> the default input method and sometimes other things.
>> ...
>> If LOCALE-NAME is nil, its value is taken from the environment
>> variables LC_ALL, LC_CTYPE and LANG (the first one that is set)."
>>
>> Both `set-locale-environment' and the glib documentation say that LANG
>> only takes effect LC_CTYPE is undefined.  
> 
> My understanding is that LC_CTYPE should be irrelevant with regards to
> the "language used in the user interface for message translation",
> because LC_MESSAGES is the relevant locale variable for this.  If
> LC_MESSAGES is undefined, LANG should be used.

But LC_ALL should be checked before LC_MESSAGES, as it says in the
documentation above, and finlly LANG.

> But as no-one has complained about this before such a situation
> (LC_MESSAGES != LC_CTYPE) might be rare, we might change this after
> the release (and put it into etc/TODO?).

I have it, but I haven't noticed this problem.

        Jan D.