[reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]

[reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: Reiner Steib <reinersteib+gmane@imap.cc>
To: emacs-pretest-bug@gnu.org
Organization: Dept. of Theoretical Physics, University of Ulm
Mail-Followup-To: emacs-pretest-bug@gnu.org
Date: Wed, 22 Nov 2006 09:36:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Subject: language environment should not be derived from LC_CTYPE
Reply-To: Reiner Steib <Reiner.Steib@gmx.de>
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

[ I already sent this yesterday (via Gmane), but apparently it didn't
  make it to the list (<v9lkm4cyqk.fsf@marauder.physik.uni-ulm.de>).
  Sorry if you get it twice. ]

`M-x report-emacs-bug' wrote:

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

I have the following locale settings [1]:

$ env|grep -e LC_ -e LANG
LANG=en_US
LC_COLLATE=POSIX
LC_CTYPE=de_DE@euro

$ 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:


,----[ (info "(libc)Locale Categories") ]
| `LC_CTYPE'
|      This category applies to classification and conversion of
|      characters, and to multibyte and wide characters; see *Note
|      Character Handling::, and *Note Character Set Handling::.
|
| [...]
|
| `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.
| 
| `LC_ALL'
|      This is not an environment variable; it is only a macro that you
|      can use with `setlocale' to set a single locale for all purposes.
|      Setting this environment variable overwrites all selections by the
|      other `LC_*' variables or `LANG'.
| 
| `LANG'
|      If this environment variable is defined, its value specifies the
|      locale to use for all purposes except as overridden by the
|      variables above.
`----

> In GNU Emacs 22.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3)
>  of 2006-11-21 on viandante
> X server distributor `The X.Org Foundation', version 11.0.60802000
> configured using `configure '--prefix=...' '--with-gtk' '--exec-prefix=...''

> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: POSIX
>   value of $LC_CTYPE: de_DE@euro
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: en_US
>   locale-coding-system: iso-8859-15
>   default-enable-multibyte-characters: t

Bye, Reiner.

[1] If you wonder why I use a mixture of de_DE and en_US locales: I
    want to display the ? in plain text files in xterm, but I prefer
    English program interfaces.  (Some of my systems offer
    en_US.iso885915, but IIRC not all.)
- -- 
       ,,,
      (o o)
- ---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]

[Chong Yidong]

> I have the following locale settings [1]:
>
> $ env|grep -e LC_ -e LANG
> LANG=en_US
> LC_COLLATE=POSIX
> LC_CTYPE=de_DE@euro
>
> $ 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
> |
> | `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.  I think the only thing for
this situation is for the user to set the language environment in the
.emacs file.

Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]

[Reiner Steib]

On Thu, Nov 23 2006, Chong Yidong wrote:

> Reiner Steib wrote:
>> $ env|grep -e LC_ -e LANG
>> LANG=en_US
>> LC_COLLATE=POSIX
>> LC_CTYPE=de_DE@euro
>>
>> $ 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.

E.g. in GNU coreutils:

$ /bin/ls --version
ls (GNU coreutils) 5.3.0
Written by Richard Stallman and David MacKenzie.
$ LC_MESSAGES=de_DE /bin/ls /foo-bar
/bin/ls: /foo-bar: Datei oder Verzeichnis nicht gefunden

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?).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [reinersteib+gmane@imap.cc: 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
>>> LC_CTYPE=de_DE@euro
>>>
>>> $ 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.

Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Date: Sat, 25 Nov 2006 10:13:29 +0100
> Cc: emacs-devel@gnu.org, rms@gnu.org, Reiner Steib <reinersteib+gmane@imap.cc>
> 
> 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.

The problem is, set-locale-environment is not used to display
``messages'', as in text-mode programs that use gettext facilities.
It is used to guess various locale-specific defaults.  So it is no
surprise that it doesn't follow to the letter the logic of other
programs.