RE: valid locales ---> was Re: bilingual websites

David,

There has been some discussion of handling different currencies (Foreign
currency support) for locales in ICU.

I also agree that time zone is part of the locale.

I did some experimenting with various locale iteration schemes in ICU.
Things are too busy now but I will probably start a discussion on the
subject after ICU 2.0 is put to bed.  Much of the country settings are
independent of language.  Changing the iteration system could be also used
to reduce the size of the data by eliminating duplication.  If you do that
then es_US becomes a legitimate locale with no new coding.

The other technique is to use two locales if the one you want does not
exist.  You use "es" and if the resource is not found then use "en_US".
This however, does not work for internal functions that use a locale.

Carl
  -----Original Message-----
  From: www-international-request@w3.org
[mailto:www-international-request@w3.org]On Behalf Of David_Possin@i2.com
  Sent: Wednesday, October 31, 2001 2:42 PM
  To: Aruna_Goli@i2.com; markus.scherer@jtcsv.com
  Cc: www-international@w3.org; www-international-request@w3.org
  Subject: Re: valid locales ---> was Re: bilingual websites



  Aruna,

  I didn't include all the other i18n parameters because they are defined by
one of the four parameters I listed. Date, time, number, and currency
formats are set by the country, as are addresses, telephone numbers, and
much more. What I was going after is which parameters are required to
clearly identify the locale setting for all parameters of the session. I
mainly wanted to state that the current definition of a locale is useless
and it is a shame that every company has to write their own i18n libraries
to correct all the issues. Java is touted as the best programming language
for i18n in the world, our daily efforts prove it wrong.

  Could you point me to that article, please? I would like to read about
what is planned to correct the issues we are having. And this is not a Java
only issue, C++ needs the support as well. I do not see ICU improving
anything in locale definition, either, although it would be an ideal chance
to create a corrected library there. I doubt operating systems will pick up
on this anytime soon, there are too many compatibility issue tied to the
existing locale definition.

  A question for Markus Scherer: Is anything planned on improving locale
descriptions or has it been thought about for ICU?

  Thanks,
  David



       Aruna Goli
        10/31/01 04:18 PM


                To:        David_Possin@i2.com
                cc:        Karl Ove Hufthammer <huftis@bigfoot.com>,
www-international@w3.org, www-international-request@w3.org
                Subject:        Re: valid locales ---> was Re: bilingual
websitesLink




  There are several other aspects which also define a locale. In our
products we use more parameters to define what a locale
  might mean. And it has been working out well to handle all the situations
described below.
  In addition to this  language_country_timezone_base-currency, the date and
time formats and the formatting conventions
  for numbers and currencies also changes depending on the application.

  Recently there has been an article in Java Developer's Journal
highlighting the necessity to use this methodology. The general idea is that
we need not wait for the operating system or the programming languages to
provide this support but can implement this in our own internationalization
libraries.

  thanks
  Aruna



       David_Possin@i2.com
        Sent by: www-international-request@w3.org
        10/31/2001 10:47 AM

               To:        Karl Ove Hufthammer <huftis@bigfoot.com>
               cc:        www-international@w3.org,
www-international-request@w3.org
               Subject:        valid locales ---> was Re: bilingual websites





  2001-10-31 01:39:43, Yves Arrouye <yves@realnames.com>:

  > It is not obtained from Regional Settings. It is obtained from
  > an IE-specific setting located in Options > Languages...

  - Yes, I knew that. What I meant was if the default language for the
  - IE settings (dialogue) was retrieved from the Regional Settings.

  > Note
  > that with IE6, the script runonce.asp that is ran whenever you
  > update Windows (IE) will ask you for a country and a language,
  > and set the setting.

  - Hmm, I've never seen this. Does it only happen if *haven't* chosen
  - a language for 'Tools | Internet Options | Languages'?

  - --
  - Karl Ove Hufthammer

  On a fresh/clean install IE derives the default locale from the regional
settings. If IE is updated it uses what it finds in the Preferred Languages,
keeping the top one as the default. You always have at least language in the
Preferred Language settings, it defaults to what it determines during
install time. I do not understand why the runonce.asp asks for the language
after an upgrade, why would I want to change my existing preferences? Or
does it mean the language for the MSN homepage when you choose to use it?
This would make no sense, as it is country and not language dependent.

  Which leads me to my largest gripe and problem in globalization:

  What is a valid locale???????

  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!

  Depending on the operating system version, the browser version, the Java
VM version, their localization, and their manufacturers I get different
accepted pairs I can use to describe a locale. I cannot create any other
locales without crashing something or defaulting to something I do not want.
Sure I can use locale variants, but they are also not created and usable
equally for all platforms.

  We build ecommerce platforms here that are used by many multinational
corporations for b2b, b2b2c, and b2c applications in the SCM and CRM worlds.
We run on the major hardware platforms with all kinds of software
combinations = a mess! We need to run in multiple locales, be multilingual
on the same page, and be able to calculate and use any currency and/or
multiple currencies. The current usage of a locale identifier does not
support any of this.

  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. That means a Mexican living in the USA has either en_US or es_MX
setting - the es_US pair is invalid and fallback is to es_ES = Spain,
definitely not what the customer or the supplier wants. The bookseller wants
to offer Spanish titles with Mexican preferences in US dollars.

  The next workflow describes a manufacturer of heavy machinery in Russia.
The diesel motors come from various suppliers in Russia, Germany, China, and
USA. Each make their offer in their local currency, the conversion into
Rubel is done daily. 25 motors each come from each of the suppliers, so the
sum must reflect all involved currencies, plus triangulation of
DEM-EURO-Rubel. The offers and confirmations must be in the various
languages, some parts must be displayed at the same time, also using
different units.

  Therefore we had to ignore locale identifiers for our application, write
our own language, region, time zone, and currency APIs, and maintain all
ourselves. Even obvious "globalized" Java standards were useless, because
they were inconsistent between the platforms. Our locales are now defined
internally as
        language_country_timezone_base-currency

  Is there any way the forced pairing of locales in operating systems and
software can be ripped apart? Using International Win2000 and International
Solaris with all language packs installed I should be able to select any of
the listed identifiers independently and get the required results without
having to rewrite all myself. I cannot expect users to fine-tune their
regional settings for me.

  Sorry if this email is too long, but after listening to everybody else I
had to get to the core of the issues.

  David Possin

Received on Wednesday, 31 October 2001 21:36:14 UTC