Re: locales

When I at one time told that I am looking at religions etc that was for 
global personalization. I am trying to determine what user data could be 
relevant in other locales that isn't even considered at all in US and/or 
European applications. This is very application dependent and should not 
be included in basic locale information. I agree, with XML we could easily 
mix locale identifiers with localized personalization data, as I have seen 
in the HR-XML mailing list.

For the bare minimum to identify a user's locale I am actually trying to 
use as few parameters as possible. I even consider language as a user's 
personal preference and not as part of a locale. The same goes for 
currency, most of the time global applications use their own rules and 
multiple currencies, not even to mention the euro issues.

I looked at the ICU link, but it doesn't include enough depth for 
commercial requirements (yet?). I do see a split in the requirements, the 
nitty-gritty calculations should not be part of ICU, but in a separate 
library, as Aruna recommended. ICU could cover the locale specific 
problems of formatting and displaying the currency values, currently a big 
problem in Java. I have to do more studies to give you more feedback on 
what I think about the ICU plans. Our team here pulled currency 
calculations out of the i18n requirements and put them into global US 
business requirements. Formatting and display remained part of i18n.


"Mark Davis" <>
11/08/01 10:16 PM

        To:     <>
        cc:     <>, <>, 
        Subject:        Re: locales

The problem is that one person's bare minimum is another persons wild 
extravagance (or privacy issue). For example, one of your examples was:
>Religions and Sub-Groups (like Protestant, Lutheran or Reformed) 
I don't think think of that at all as a bare minimum. The fact that I am a 
devout atheist is my own business -- not something for a "locale". In 
another example, currency is important to many applications, but 
completely irrelevent to others. With an XML format where all elements are optional, defined so that IF a 
tag is present, it has a particular interpretation, then that is about as 
good as it gets.
BTW, if you followed the link I sent, you'd see that we are looking at the 
Euro conversion in the next version of ICU.
Ὀλίγοι ἔμφονες πολλῶν ἀφρόνων φοβερώτεροι — Πλάτωνος
[For transliteration, see]

----- Original Message ----- 
To: Mark Davis 
Cc: ; ; ; 
Sent: Thursday, November 08, 2001 09:30
Subject: Re: locales

What I am trying to get out of this discussion is to be able to identify a 
user's locale, especially for an anonymous user without personalization, 
and the user's language. The coupling of language_region is useless for a 
global web application, I even doubt it makes much sense on a local 
operating system. Travelling globally with a notebook pc I might want to 
maintain my UI language, but change the locale depending on where I am. 

There is a fine line between a user's locale and a user's personalization. 
I am trying to identify the bare minimum locale without personalization, 
and language is a personal preference to me. Being bilingual I would like 
to be able to set my computer to de_US or en_DE sometimes .... 

I have created the Yahoo.Groups forum for locale discussions - please feel 
free to join, everybody: 

David Possin

"Mark Davis" <> 
Sent by: 
11/08/01 10:59 AM 
        To:        "Suzanne M. Topping" <>, 
<>, "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 
had timezone support, and looking at the currency issue for our next 
(see > Docs & Papers > design >
currency.html), but I have doubts as to one wants to call them part of a

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" 
a broad sense -- maybe "user" would be a better term). That would 
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,

Some of these can be bundled up with a textual shorthand, such as USD for 
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 
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 
some clumsy fraction of this, what it really sounds like is desired is an
XML format for interchange "user preferences". With that, one could 
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



Ὀλίγοι ἔμφονες πολλῶν ἀφρόνων φοβερώτεροι — Πλάτωνος
[For transliteration, see]

----- Original Message -----
From: "Suzanne M. Topping" <>
To: <>; "Nelocsig (E-mail)"
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: []
> Sent: Wednesday, November 07, 2001 9:16 AM
> To:
> Subject: Re: valid locales ---> was Re: bilingual websites
> On 10/31/2001 12:47:09 PM 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 Friday, 9 November 2001 17:20:46 UTC