The C locale

[Thomas Wolff]

Corinna Vinschen wrote:
> On Sep 29 01:03, IWAMURO Motonori wrote:
>   
>> 2009/9/27 IWAMURO Motonori <deenheart@gmail.com>:
>>     
>>>> LANG="ja" -> EUCJP
>>>> LANG="ja_JP" -> EUCJP
>>>>         
>>> Hmmm, It is a difficult problem.
>>>
>>> I think selecting UTF-8 is good because eucJP is legacy.
>>>
>>> But, for interoperability with other UNIX-like system(*), I don't
>>> think selecting UTF-8 is good.
>>>
>>> * Solaris: ja, ja_JP -> eucJP
>>> * Linux (Debian): ja -> Unknown, ja_JP -> eucJP
>>>
>>> I need to think more...
>>>       
>> My conclusion is as follows as a result of hearing other Japanese
>> people's opinion:
>>
>> LANG=ja -> UTF-8
>> LANG=ja_JP -> UTF-8
>>
>> Because, we specify "eucJP" explicitly when we need it.
>>     
>
> Hmm.
>
> That's an interesting point.
>
> In theory this sounds like a good idea to be used for all locales which
> don't specify the charset explicitely, because that results in using the
> same charset, "UTF-8", for all such locales.  "C", "ja" or "en_US"
> would all default to UTF-8.
>   
The keyword here again should be compatibility. That means, 
unfortunately, that I do not think this is a good idea.
A number of locales have been established on common systems that do not 
specify their encoding explicitly (i.e. in their name).
Since there is now more or less a common set of such locales among 
various Linux and Unix systems, this seems to be
a de-facto standard although I am not aware of any more formal 
definition/listing/description of this.
On a modern Linux system, use the following command to get a list (not 
sure if it's appropriate to attach it here):
    for l in `locale -a`
    do      echo "$l        `LC_ALL=$l locale charmap`"
    done

I have also tried to incorporate a best guess assembly of mappings from 
modern systems in my editor mined so it can
derive the encoding from the locale name, so you could also take a 
working list from there.

I think this list should be used for reference to define the 
locale/encoding mapping, other choices may be more attractive
but only raise problems.

> The downside is that a user, who needs to work under the default ANSI
> codepage for some reason, has to know the name of the default ANSI
> codepage.  Right now any user who needs the default ANSI codepage can
> simply set LANG to some language code and go ahead, without having to
> know the number.  With your solution, that wouldn't be possible anymore
> and the user would have to figure out the default ANSI codepage on the
> system before being able to use it.
>
> I honestly don't know if that's really a problem, though.  But I don't
> want to take that feature away for now.  Anybody having a strong opinion
> on this issue?
>   
I wasn't quite aware that the old "codepage:oem" setting didn't strictly 
mean "CP850" or "CP437" but apparently the respective system locale.
If that is really needed, maybe the "C" locale should get you there, or 
some "OEM" as (I think) Andy proposed. If someone feels the need
to combine a specific language setting with the unspecific "system 
locale", well, maybe a pseudo encoding name could be invented to form
names like "en_GB.OEM". Just leaving out the encoding suffix should not 
have that effect as I argued above.

Kind regards,
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple