What a Locale is.... (Re: [Fwd]: Response to Mark's message])

Addison Phillips [wM] aphillips at webmethods.com
Tue Apr 15 11:29:12 CEST 2003

> Jon Hanna wrote on 04/15/2003 06:34:53 AM:
>>Implicit in my argument though is
>>the notion that zh-Hant-HK is not a suitable value for accept-language, 
> but
>>rather for a more inclusive header that may eventually replace
>>accept-language, but for now should be able to co-exist.

For efforts in the direction Jon suggests, consider the very long 
discussion on the locales at yahoogroups list roughly one year ago. The 
result of that discussion for me, at least, was an effort to think of an 
"international context" tagging system that separated the language tag 
(RFC3066) from regional and script information (my original proposal was 
called ULocales--you can see a prototype and the early whitepaper on 
http://www.inter-locale.com or, if you're willing to go through a great 
deal of marketing crud, on http://www.webmethods.com).

I referred earlier to (and you asked about) why divergence causes problems.
My thought then was that we could define a model for tagging 
"international metadata". I chose one syntax to demonstrate the idea. 
Others have proposed an XML structure. The format doesn't matter. The 
problem is that:

a) language tags already do 95% of the job.
b) language tags are already in use as if they were also locale tags.
c) fixing these edge cases finishes off most of the existing problems 
without having to change all of the existing implementations.


d) a new structure will take years to gain acceptance and be built into 
systems and APIs
e) the apparent benefit is very small

I'm also a firm believer and promotor of the idea that a data structure 
with a locale in it is Wrong. A generic context mechanism for 
applications such as Web services and HTTP servers is much more 
appealing. Mark's example of a "custom locale" is not in the least bit 
unusual, but I probably want to implement different data in my 
application context, eh?

I am interested in seeing if separating script from the existing tag 
makes any sense in resolving the positioning problem. Recall that I 
suggested a "." modifier: "zh.hant-CN" or possibly "zh-CN.hant". 
Existing parsers probably can't deal with the new syntax, but perhaps 
this can be finessed?

> You're assuming that we can create a model involving new metadata 
> categories, and get support for these incorporated into various systems, 
> such as the HTTP protocol and HTTP servers. But wasn't that already 
> discussed in this thread, with the conclusion that the likelihood of 
> success in that was very low? (I seem to recall that comment being made, 
> but perhaps I'm mistaken. I guess I could review the archive to find 
> out...)

Exactly so. I believe I mentioned it here, but it has been discussed 
elsewhere, possibly before this thread collided with this list.

Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.

+1 408.962.5487  mailto:aphillips at webmethods.com
Internationalization is an architecture. It is not a feature.

Chair, W3C I18N WG Web Services Task Force

More information about the Ietf-languages mailing list