[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: language environment should not be derived from LC_C
Re: address@hidden: language environment should not be derived from LC_CTYPE]
Sat, 25 Nov 2006 11:49:07 +0100
Thunderbird 126.96.36.199 (X11/20061115)
Reiner Steib skrev:
> On Thu, Nov 23 2006, Chong Yidong wrote:
>> Reiner Steib wrote:
>>> $ env|grep -e LC_ -e LANG
>>> $ 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.