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 13:52:49 UTC