[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accessing the environment's locale encoding settings
From: |
Bruno Haible |
Subject: |
Re: Accessing the environment's locale encoding settings |
Date: |
Sun, 20 Nov 2011 17:55:18 +0100 |
User-agent: |
KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; ) |
Ludovic Courtès wrote:
> It seems to me that the implicit call is often desirable, but at the
> same time, it imposes a policy on the application. In C, Guile, & co.,
> the application can choose to ignore the locale, or to just honor
> LC_CTYPE, or to set something different.
What it actually does, then, is that it uses a mix of the user-provided
locale (for some locale categories) and the "C" locale (for some other
locale categories. When the default category is the user-provided one,
rather than "C", it is still possible, it just needs different code to
do so.
Instead of
(setlocale LC_CTYPE "")
the user will now need to write
(setlocale LC_NUMERIC "C")
(setlocale LC_MONETARY "C")
(setlocale LC_COLLATE "C")
(setlocale LC_MESSAGES "C")
(setlocale LC_TIME "C")
> > So my suggestion is to do (setlocale LC_ALL "") as part of the Guile
> > initialization, very early. Yes, this might lead to some complexity
> > in the Guile implementation if you have the concept of locale also at
> > the Guile level and need to make sure that the locale at the C level and
> > the locale at the Guile level are consistent as soon as the latter is
> > defined. But this is manageable.
>
> Are you suggesting that we could arrange to have Guile’s ‘main’ call
> setlocale(LC_ALL, "") while still giving Scheme code the impression that
> it’s started under the C locale as is currently the case?
No, I'm suggesting to let the Scheme code know that is it using the user's
locale.
Yes, this is a backward-incompatible change, so probably you won't want to
do it on the guile 2.0.x branch, and you will want to advertise it in the
release notes or NEWS file.
> A reasonable option would be to setlocale(LC_CTYPE, "") from Guile’s
> ‘main’, so that scm_from_locale_string & co. would DTRT. But again that
> would change the value of %default-port-encoding, leading to potential
> application breakage.
In the long run, this would be more complex: users who see that LC_CTYPE
from the environment is respected would also expect that LC_COLLATE etc.
from the environment is respected.
I would just do the change and make it clear that old applications that
really want to stay in the C locale should call
(setlocale LC_ALL "C")
Bruno
--
In memoriam Kerem Yılmazer <http://en.wikipedia.org/wiki/Kerem_Yılmazer>
- Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/15
- Re: Accessing the environment's locale encoding settings, Bruno Haible, 2011/11/15
- Re: Accessing the environment's locale encoding settings,
Bruno Haible <=
- Re: Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/20
- Re: Accessing the environment's locale encoding settings, Mike Gran, 2011/11/20
- Re: Accessing the environment's locale encoding settings, Ludovic Courtès, 2011/11/23
- Re: Accessing the environment's locale encoding settings, Mike Gran, 2011/11/23
- Re: Accessing the environment's locale encoding settings, Peter Brett, 2011/11/24
- Re: Accessing the environment's locale encoding settings, Mark H Weaver, 2011/11/24
- Re: Accessing the environment's locale encoding settings, Bruno Haible, 2011/11/20