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,
>>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
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
+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