The "C" locale is useful for functions that talk to the OS. You need a
special locale for the OS as well as a user locale. You have to know if the
OS is ASCII or EBCDIC. It's code page and locale values that it uses for
strtol conversion. Internal date/time and time zone handling. Yes there is
a whole operating system locale issue but it is a separate issue. Ideally
we should separate the user from the OS locale. Each thread could operate
in a separate locale or a mix of locales.
From: David Starner [mailto:firstname.lastname@example.org]
Sent: Wednesday, September 20, 2000 9:47 AM
To: Unicode List
Subject: Re: New Locale Proposal
On Wed, Sep 20, 2000 at 07:53:20AM -0800, Carl W. Brown wrote:
> Firstly you need a locale system that is truly mapped to human cultures.
> None of this "C" locale or "MACINTOSH".
Why? They are useful for low level actions or as a default locale when
nothing else can be found or relied on (the C locale, for example,
can be used by a kernel during a panic, when only ASCII can be relied
on to be interpreted properly, and we can't access the disk for any
message catalogs or the like.) It's also a consistent, culture-netral
format for dates and numbers that probably won't be read by humans,
but need to be reliably read by machines. If you write out your spreadsheet
in an arbitrary locale, there's no plaintext (i.e. xml) character that
can be relied on to seperate the characters. The C locale has consistecy
and machine simplicty over culture, which is sometimes a worthwile or
even nessecary trade off.
No, the C locale is not acceptable for general use. But as a special purpose
locale, it has its uses.
-- David Starner - email@example.com http/ftp: dvdeug.dhis.org And crawling, on the planet's face, some insects called the human race. Lost in space, lost in time, and meaning. -- RHPS
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:13 EDT