[Top][All Lists]

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

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

From: Jan Djärv
Subject: Re: address@hidden: language environment should not be derived from LC_CTYPE]
Date: Sat, 25 Nov 2006 11:49:07 +0100
User-agent: Thunderbird (X11/20061115)

Reiner Steib skrev:
> On Thu, Nov 23 2006, Chong Yidong wrote:
>> Reiner Steib wrote:
>>> $ env|grep -e LC_ -e LANG
>>> LANG=en_US
>>> 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: ]
>>> |      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.

reply via email to

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