* [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]
@ 2006-11-23 2:52 Richard Stallman
2006-11-23 20:20 ` Chong Yidong
0 siblings, 1 reply; 5+ messages in thread
From: Richard Stallman @ 2006-11-23 2:52 UTC (permalink / raw)
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 -------
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]
2006-11-23 2:52 [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE] Richard Stallman
@ 2006-11-23 20:20 ` Chong Yidong
2006-11-25 9:13 ` Reiner Steib
0 siblings, 1 reply; 5+ messages in thread
From: Chong Yidong @ 2006-11-23 20:20 UTC (permalink / raw)
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]
2006-11-23 20:20 ` Chong Yidong
@ 2006-11-25 9:13 ` Reiner Steib
2006-11-25 10:49 ` Jan Djärv
2006-11-25 10:57 ` Eli Zaretskii
0 siblings, 2 replies; 5+ messages in thread
From: Reiner Steib @ 2006-11-25 9:13 UTC (permalink / raw)
Cc: emacs-devel, rms, 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/
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]
2006-11-25 9:13 ` Reiner Steib
@ 2006-11-25 10:49 ` Jan Djärv
2006-11-25 10:57 ` Eli Zaretskii
1 sibling, 0 replies; 5+ messages in thread
From: Jan Djärv @ 2006-11-25 10:49 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE]
2006-11-25 9:13 ` Reiner Steib
2006-11-25 10:49 ` Jan Djärv
@ 2006-11-25 10:57 ` Eli Zaretskii
1 sibling, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2006-11-25 10:57 UTC (permalink / raw)
Cc: cyd, emacs-devel, reinersteib+gmane
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-11-25 10:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-23 2:52 [reinersteib+gmane@imap.cc: language environment should not be derived from LC_CTYPE] Richard Stallman
2006-11-23 20:20 ` Chong Yidong
2006-11-25 9:13 ` Reiner Steib
2006-11-25 10:49 ` Jan Djärv
2006-11-25 10:57 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).