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

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

From: <Peter_Constable@sil.org>
Date: Thu, 8 Nov 2001 07:33:44 -0600
To: www-international@w3.org
Message-ID: <OFB2551CFA.437A30C3-ON06256AFE.00198477@sil.org>

>I say this because there is a huge assumption that is never clearly 
stated - 
>that one "locale" is sufficient at any given time...

Before accepting a suggestion of n-dimensional locales or even 
2-dimensional locales, I'd want to see what the conceptual model is for 
what a locale is and what the n dimensions are. In your hypothetical app 

> But it is easy to conceive 
>of an app (but difficult to implement) where some elements use one 
locale, and 
>other elements use another. In particular the text of the GUI widgets (as 
>were) may support one locale and the data that is manipulated using those 

>widgets another. 

-- I don't see two locales; I only see one: the locale that determines the 
text of the GUI widgets. The text of the data is simply data, and I'd 
suggest that general text data is unrelated to locale: the Russian text 
that makes up one a Dostoyevski novel doesn't change according to the 
user's mother tongue or location or time zone etc. (I realise this may not 
fit the way some systems work, but I'd suggest that those systems lack a 
good model rather than that this model is broken.) Numeric values / 
currency, dates and similar things do change, but they are not text. If 
you are considering non-text data, then, I suspect you've still got one 
locale: the user is likely to want the times they see in that app's data 
and the times they see in a dialog describing object properties formatted 
the same way. 

Suppose I've got a database with amounts of jet fuel consumed and the app 
generally presents them to me using my user locale settings defined in the 
system, but then I'm preparing a report for the head office in another 
country and configure that report to present values per the norms for that 
country. In this situation, I could accept that there are two locales, but 
that is because there are two consumers of two information objects: I'm 
the consumer of views into the db that I use for maintaining it, and the 
managers over across the pond are the consumers of a view created for 
their benefit. I certainly don't need to track these separately in my 
system. Sure, my app needs to permit me to specify a locale on a view I'm 
creating that overrides by user locale as defined in the system, but this 
doesn't require some complicated model: each information object that 
provides a human-readable view (except for text data other than strings 
for UI widgets) potentially needs a locale setting, and it could normally 
follow the user's default as they have defined in the system while 
allowing that to be overriden.

>E.g, in an accounting program for North America, I might need the GUI to 
>either English or French, and the functionality to support US or Canadian 
>accounting. Surely at least 3 of the 4 pairs of those 2 items would be 
>for the product (French/US being the unlikely one). 

True; even fr_US is possible. But a given object in that program can only 
use one of these at any time. 

I don't see n dimensions here. I think you've got a one dimensional field 
-- a set of single-dimensional points each of which has a value for some 
property. The points in this analogy are the different information objects 
maintained in your app. So, since there's only one dimension, nothing is 
orthogonal to anything else.

I've probably goofed somewhere, though -- don't hesitate to debate the 
debatable and laugh heartily at the laughable. :-)

I still don't think I know why a browser needs a way to set locale 

- Peter

Peter Constable

Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
Received on Thursday, 8 November 2001 08:41:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:21 UTC