RE: locales

Tex,

In xIUA I use the following format:

     Format: (no spaces)
     ll[_CC ][.MM ][@VV][#TT]

     ll = lang, CC = ctry, MM = charmap, VV = Variant, TT = Time Zone

For example:

en_US.iso-5589-1#America/Los_Angeles

or

fr_FR.iso-5589-15@EURO#Europe/Paris

It works well with ICU.  The conversion both ways is very simple and
straight forward.

Carl


> -----Original Message-----
> From: Tex Texin [mailto:texin@progress.com]
> Sent: Wednesday, November 07, 2001 11:54 AM
> To: David_Possin@i2.com
> Cc: cbrown@xnetinc.com; www-international@w3.org;
> www-international-request@w3.org
> Subject: locales
>
>
> David,
>
> If you would set up an archived forum, that would be great. It will save
> me trying to identify which messages are relevant and saving them all on
> my drive.
>
> Mentioning time zones will, I am sure, insure a blast from Carl. (;-) I
> look forward to it.)
> One point is that a locale may include more than one zone (e.g. US goes
> from EST, CST PST) so is ambiguous, and we may go down the trail of the
> changes to daylight savings time may vary within a locale.
>
> A key question for me is which of the many variables for
> internationalization belong in a locale and which belong in some other
> structure?
>
> Maybe time and calendar should not be a function of locale...
> Maybe currency should not be.
>
> Which variables are best associated with the locale, which with the
> data, and which with the application?
> For example, since I develop database products, and I cannot have
> indexes changing on me, I always include the rules for sorting in the
> database, with the data.
>
> I don't generally worry about hyphenation, I would probably keep rules
> for that with the application (the choice being influenced but not
> defined by locale).
>
> tex
>
>
>
> David_Possin@i2.com wrote:
> >
> > I would propose to open a discussion forum for locales in the
> > yahoo.groups like many other globalization people have done for other
> > issues. It will be tough keeping up to date with all the threads
> > starting to pop up, and all are extremely important to me and my job.
> > Here are the issues I have been trying to monitor and even reply to,
> > adding my 2 cents:
> >
> >   1. Locale definition - what is a locale?
> >   2. Locale identification - how many parameters are needed for a
> >      default minimal locale description?
> >   3. Language identification - how can we identify languages that are
> >      not included in the ISO 639 language group standard? (Current
> >      locale identifiers use the 2-letter code, not the 3-letter code)
> >   4. Time zones - There is no standard, the tz database is as close as
> >      I can get to a standard and it is not officially tied to a
> >      locale. This only touches the need for a standard global time &
> >      date display.
> >   5. Currencies - Locales have only one currency tied to them, and
> >      European locales still all have their national currencies
> >      implied.
> >   6. Euro - The big problem is not the display, but how to use it. The
> >      EC has strict requirements on how to do currency triangulation
> >      with the euro. We discovered that rounding problems popped up
> >      everywhere, especially when using euro precision for calculation
> >      and had to display the value in a currency without decimals. It
> >      would be a dream to have this in ICU.
> >   7. Even when the euro becomes standard for a country, older
> >      transactions will still have to be working with old currencies
> >      and/or triangulation. We can't just convert them.
> >
> >      This only lists what has been mentioned in the last few days,
> >      there is much more to be mentioned. I am trying to make PMs,
> >      Devs, QA, etc globally aware here, but it is very hard to get
> >      official requirements written up when there are no standards I
> >      can show as reference.
> >
> >      And my biggest proposal is to break the tie between language and
> >      country when selecting a locale.
> >
> >      Dave
> >
> >       "Tex Texin" <texin@progress.com>
> >       Sent by:                                   To:        "Carl W.
> >       www-international-request@w3.org   Brown" <cbrown@xnetinc.com>
> >                                                  cc:
> >       11/07/01 12:15 PM                   www-international@w3.org
> >                                                  Subject:        Re:
> >                                          Euro mess (Was: valid
> >                                          locales ---> was  bilingual
> >                                          websites
> >
> >      Carl,
> >
> >      I hope the locales issue doesn't fan out into thousands of other
> >      threads, I won't be able to track them.
> >
> >      With respect to the Euro, there are several different issues.
> >
> >      a) Of course the Euro is important and having proper support for
> >      the
> >      Euro is required.
> >
> >      b) ISO 8859-15 does not seem to be getting much adoption, which
> >      is a
> >      good thing. Since 8859-15 and 8859-1 are incompatible, and if you
> >      adopt
> >      8859-15 you likely still need to interchange text with users of
> >      8859-1,
> >      (as they both support the same languages more or less), the world
> >      would
> >      be a very difficult if there was a lot of adoption of -15.
> >
> >      Anyone considering -15, should instead be considering Unicode.
> >
> >      And there are other alternatives if the only requirement is to
> >      support
> >      the Euro character and continue with a single byte codepage.
> >      Spelling out "Eur" or "Euro" is acceptable if there is space. And
> >      inventing mechanisms (e.g. escape sequences, or other specialized
> >      encodings) to print the Euro symbol are also possible.
> >
> >      c) The issue relative to locales, is there is no standard
> >      handling for
> >      the Euro. So my understanding is some software will change the
> >      currency
> >      of their European locales from native monetary units to Euro on
> >      Jan. 1.
> >      This may be useful for some, but will likely break many
> >      applications as
> >      well.
> >
> >      Others will create new locales specific to the Euro and/or
> >      specific to
> >      the old native currency. But which nomenclature you use when you
> >      are
> >      integrating software with different technologies and different
> >      locale
> >      naming conventions is a mystery to me.
> >
> >      So now if I say fr_fr I do not know which currency I get and it
> >      may
> >      change from Dec 31 2001 to Jan 1 2002.
> >      If I use an application that integrates technologies with
> >      different
> >      rules for locales, it could get very messy.
> >
> >      I presume reading monetary data created before 2002 may also be
> >      interpreted differently after 2002.
> >
> >      And minor upgrades of software may in fact invoke these locale
> >      changes,
> >      so what should be a minor patch may in fact be a large change to
> >      monetary handling.
> >
> >      d) I don't know why there isn't more of an outcry over this.
> >      Maybe there
> >      is a reason the problems I cite in (c) won't happen that I don't
> >      understand. (I am by no means an expert on the subject. Most of
> >      my own
> >      software has explicit regional settings and doesn't follow the
> >      locale
> >      model.) It will be interesting to know what people find if they
> >      change
> >      their system clock to 2002 and do some application testing.
> >
> >      hth
> >      tex
> >
> >      "Carl W. Brown" wrote:
> >      >
> >      > Tex,
> >      >
> >      > I wonder why no one seems to care about the Euro?  Are sites
> >      going to
> >      > continue to use iso-5589-1?  How many browsers and systems
> >      support
> >      > iso-5589-15?
> >      >
> >      > Carl
> >      >
> >      > > -----Original Message-----
> >      > > From: www-international-request@w3.org
> >      > > [mailto:www-international-request@w3.org]On Behalf Of Tex
> >      Texin
> >      > > Sent: Tuesday, November 06, 2001 7:42 PM
> >      > > To: Martin Duerst
> >      > > Cc: David_Possin@i2.com; Karl Ove Hufthammer;
> >      www-international@w3.org
> >      > > Subject: Re: valid locales ---> was Re: bilingual websites
> >      > >
> >      > >
> >      > > Martin,
> >      > >
> >      > > You mean I can't just grouse and take potshots from the
> >      sidelines? ;-)
> >      > >
> >      > > Well, I have not seen an alternative proposed and I don't
> >      have one at
> >      > > the ready, but I don't mind taking a shot at improving the
> >      current
> >      > > situation. However, I am crunching now thru the end of the
> >      year, so I
> >      > > will give it a go in the new year.
> >      > > In the meantime, I would be happy to collect both suggestions
> >      for
> >      > > requirements and suggestions for solutions on this list or
> >      privately.
> >      > >
> >      > > The new year should be interesting, as the switch to the new
> >      Euro
> >      > > currency will demonstrate some of the chaos with locales.
> >      > >
> >      > > tex
> >      > >
> >      > > Martin Duerst wrote:
> >      > > >
> >      > > > Tex - Could you write up (short), or point to, any proposal
> >      > > > for how to do better than currently?
> >      > > >
> >      > > > Regards,  Martin.
> >      > > >
> >      > > > At 14:57 01/10/31 -0500, Tex Texin wrote:
> >      > > > >David,
> >      > > > >
> >      > > > >FWIW, I thoroughly agree that locales as we currently
> >      define and
> >      > > > >implement them, do not work.
> >      > > > >As a naming convention it is inadequate, and when you
> >      select a
> >      > > name, you
> >      > > > >are not sure what behavior you will get.
> >      > > > >
> >      > > > >I have mentioned this before, and the response is always
> >      "Yes, it's
> >      > > > >broken, but it is the best we have at the moment.".
> >      > > > >
> >      > > > >It is rather unfortunate that we have this methodology
> >      therefore, and
> >      > > > >that it is accepted, since it won't be fixed as long as
> >      this response
> >      > > > >continues.
> >      > > > >
> >      > > > >tex
> >      > > > >
> >      > > > >--
> >      > > >
> >      >-------------------------------------------------------------
> >      > > > >Tex Texin                    Director, International
> >      Business
> >      > > > >mailto:Texin@Progress.com    Tel: +1-781-280-4271
> >      > > > >the Progress Company         Fax: +1-781-280-4655
> >      > > >
> >      >-------------------------------------------------------------
> >      > >
> >      > > --
> >      > > -------------------------------------------------------------
> >      > > Tex Texin                    Director, International Business
> >      > > mailto:Texin@Progress.com    Tel: +1-781-280-4271
> >      > > the Progress Company         Fax: +1-781-280-4655
> >      > > -------------------------------------------------------------
> >      > >
> >
> >      --
> >      -------------------------------------------------------------
> >      Tex Texin                    Director, International Business
> >      mailto:Texin@Progress.com    Tel: +1-781-280-4271
> >      the Progress Company         Fax: +1-781-280-4655
> >      -------------------------------------------------------------
>
> --
> -------------------------------------------------------------
> Tex Texin                    Director, International Business
> mailto:Texin@Progress.com    Tel: +1-781-280-4271
> the Progress Company         Fax: +1-781-280-4655
> -------------------------------------------------------------
> "When choosing between two evils, I always like to try the
> one I've never tried before."- -Mae West

Received on Wednesday, 7 November 2001 18:32:27 UTC