W3C home > Mailing lists > Public > www-international@w3.org > October to December 2001

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

From: by way of Martin Duerst <Aruna_Goli@i2.com>
Date: Tue, 06 Nov 2001 03:20:27 +0900
Message-Id: <4.2.0.58.J.20011106032020.06e86e30@localhost>
To: www-international@w3.org

David,

Date, time, number, and currency formats are set by the country, true but 
any programming language like Java or others, t
specifying the country does not mean it will give you the required/correct 
format. Also depending on the type of application and  user the date 
pattern can be defined in two or three ways for any given country. Same 
goes for the other formats too. The reason we specify the currency pattern 
as part of the locale is to overcome any inconsistencies that might exist 
in the programming language for instance indian currency pattern is not 
supported in JDK 1.2.2 (though  ICU supports it now).

The article on Internationalization is in the JDJ october 2001 issue.

Thanks
Aruna



David Possin

10/31/2001 02:41 PM

      To:       Aruna Goli/AMER/i2Tech@i2Tech, markus.scherer@jtcsv.com
      cc:       www-international@w3.org, www-international-request@w3.org
      Subject:       Re: valid locales ---> was Re: bilingual 
websites<notes:///86256aaf0017a4c5/38d46bf5e8f08834852564b500129b2c/2130f634 
a6b1917f88256af6007973da>Link

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 
websites<notes:///86256984006ee88e/38d46bf5e8f08834852564b500129b2c/6e39b5e8 
3ac1122886256af6006b910f>Link



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 Monday, 5 November 2001 13:22:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:58 GMT