RE: locales

IMHO a big problem with defining what a locale should be is the
lack of clarity of the underlying datatypes and the "normalized" format
of the data.  The easiest example is a floating point number.  The
normalized or internal form might be a 32-bit float.  It is easy
to understand that locale info (in this case decimal separator) is
used to parse a number entered by a user or to render that floating
point number.

But what about currency?  The rendering and parsing are different than
for floats.
For currency, you can let the user enter a number and get the
denomination
from the locale, but you must store both denomination and number.  When
rendering, you must use the stored denomination, you cannot just assume
the denomination from the locale.  And, as has already been pointed out,
the rendering algorithms are different for euros.  And can you store
currency with
a 32bit float?  or should you use some kind of BCD to guarantee exact
precision?

The standards have always shied away from this kind of detail.  The 
standard wants to say something like "display YY-MM-DD" and you figure
out how to
store it.  And therefore we get various internal formats such as 
"seconds since 1970".  And then due to the inadequacy of the internal
format, 
everybody invents their own and we have endless discussions about
timezones.

I don't think it is possible to divorce the discussion of locale from
the 
discussion of internal data format.  I don't think
anyone can say that a their idea for locale is complete unless they also
have a complete understanding of the "normalized" format of the
underlying
data.

Perhaps now with the standardization around XML and associated
"normalized" 
data formats - it is not so outrageous to suggest the same with regards
to
locale.  The idea that locale info might be stored in XML is excellent.

-Paul


Paul Deuter
Internationalization Manager
Plumtree Software
paul.deuter@plumtree.com 
 


-----Original Message-----
From: Mark Davis [mailto:mark@macchiato.com]
Sent: Thursday, November 08, 2001 9:00 AM
To: Suzanne M. Topping; www-international@w3.org; Nelocsig (E-mail)
Subject: Re: locales


I have some doubts as to this project along these lines. Currency and
Timezone are certainly orthogonal to what is currently thought of as a
locale. This does not mean that they are unimportant (in ICU we have
always
had timezone support, and looking at the currency issue for our next
release
(see http://oss.software.ibm.com/icu/ > Docs & Papers > design >
currency.html), but I have doubts as to one wants to call them part of a
"locale".

What some people appear to want is some structured way to indicate
and/or
communicate a raft of information about a client's preferences ("client"
in
a broad sense -- maybe "user" would be a better term). That would
presumably
include the traditional features of a locale, such as how dates are
formatted, but may also -- *depending on the application* -- include
currency, timezone, preferred character set, smoker/non-smoker,
vegetarian
or not, music preference, religion, party affiliation, favorite charity,
etc.

Some of these can be bundled up with a textual shorthand, such as USD
for US
dollar, or "en-US" for date/time/number/sorting conventions. Many
people,
however, customize their settings -- I don't use the standard US dates
on my
machines, I use the ISO 2001-12-31 style -- so the standard locales
don't
and cannot convey that information.

Rather than some ad-hoc extension to "en-US-CAD-PTZ" to try to capture
only
some clumsy fraction of this, what it really sounds like is desired is
an
XML format for interchange "user preferences". With that, one could
capture
things such as the fact that my normal date/time/number formats are
en-US,
but that I want "YYYY-MM-DD" for dates. I suspect a good deal of this is
going on already in the many groups looking at XML interchange of
business
data.

Mark

—————

Ὀλίγοι ἔµφονες πολλῶν ἀφρόνων φοßερώτεροι — Πλάτωνος
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com
----- Original Message -----
From: "Suzanne M. Topping" <stopping@bizwonk.com>
To: <www-international@w3.org>; "Nelocsig (E-mail)"
<nelocsig@yahoogroups.com>
Sent: Wednesday, November 07, 2001 07:23
Subject: RE: valid locales ---> was Re: bilingual websites


> Questions about this topic came up recently on another list, and
caused
> me to wonder if it might be "better" to offer user selectable options
> for various locale-related functions, rather than trying to devise
what
> individual preferences or requirements might be?
>
> For example, UIs could default to the language used by the operating
> system, and could start with "default" formatting etc. settings based
on
> the OS as well. But perhaps for optimal user satisfaction, we should
> offer dropdowns next to date, time, currency, address, title etc.
fields
> which would allow users to choose how they wanted data displayed, and
> have the formats changed on the fly.
>
> Thoughts?
>
> -----Original Message-----
> From: Peter_Constable@sil.org [mailto:Peter_Constable@sil.org]
> Sent: Wednesday, November 07, 2001 9:16 AM
> To: www-international@w3.org
> Subject: Re: valid locales ---> was Re: bilingual websites
>
>
>
> On 10/31/2001 12:47:09 PM David_Possin@i2.com wrote:
>
> >So far we have ISO codes for language (I prefer language group) and
for
> country
> >(I prefer region). But there is not standard definition that tells me
> which
> >combinations are valid. Therefore I assume that any combination is
> valid and
> >legal and can be used. WRONG!
>
> [snip]
>
> >Let me describe 2 simple workflows our customers require. A major
> online
> >bookseller wants to display the site in the user's language and the
> user's
> >currency... The bookseller wants to
> >offer Spanish titles with Mexican preferences in US dollars.
>
>
>

Received on Thursday, 8 November 2001 14:30:41 UTC