This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The C locale


2009/9/28 Corinna Vinschen
>> 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.

Hmm, there's much to be said for that.

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

How about an explicit "ANSI" charset that maps to GetACP()? And "OEM"
for GetOEMCP()? Those would make easy replacements for the
CYGWIN=codepage:[ansi|oem] option.

Andy

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]