[Fwd]: Response to Mark's message]

Addison Phillips [wM] aphillips at webmethods.com
Wed Apr 9 10:38:58 CEST 2003



Peter_Constable at sil.org wrote:
> Addison Phillips wrote on 04/04/2003 03:12:16 PM:
> 
> 
> 
>>The latter. They aren't attributes of text (or numbers or dates or ...).
>>IOW a locale >>should<< not be used as a modifier to a data structure.
>>It, of course, can itself be exchanged or made to be a field in a data
>>structure. But to say that, for example, an "object of type 'x' has a
>>locale of 'y'" seems like (at best) very poor internationalization...
> 
> 
> This is in contrast to identifiers for things like languages, orthographies
> and spelling conventions: it is completely appropriate that strings should
> be so tagged.

Exactly so. I wary of confusion between "language" and "locale". For 
example, I'm reviewing the latest version of the OMI (Open Management 
Interface) Web Services spec. OMI uses xml:lang to tag string messages 
with a language, which is fine. But it also uses xml:lang to identify 
the locale desired for processing purposes. The difference between the 
two is, at best, a convention, which is confusing.

> 
> 
> 
> 
>>To go back to the starting point here, if (a) RFC3066 were changed to
>>resolve the majority of variant problems with locale identifiers
> 
> 
> I, for one, do not think that RFC3066 should be changed to deal with
> locales. It *should* be changed to accommodate distinctions in things like
> writing system/orthographies/spelling conventions as well as language, but
> not locales. Such an extended RFC3066 would be of use for locale
> identification since language and text-related distinctions are relevant
> for locales, but locales go beyond the scope of what RFC3066 has been and
> should be intended to deal with.
> 
Well that's the question, isn't it.

You and I have already had this discussion. On one level I agree with 
you: a language tag is not a locale and the two should not be confused. 
I regularly have to spend time explaining how internationalization is 
not localization misspelled. And I spend a huge amount of time 
explaining data structure and interface design to developers. These 
discussions are not aided by a desire to equate a permitted (but not 
obligatory) language tag with "a locale".

I also realize that many folks working on RFC3066 historically have been 
unhappy with the idea that the tags identify something--anything--other 
than a language. Hence, I have been working on locale identifiers as 
distinct from language identifiers.

In Prague, Mark and I sat down from some discussion of this issue. The 
problem for both of us is that neither of us really believe that we need 
anything more than a language tag to identify a locale. There are 
"international context" items that are orthogonal to locale (timezone 
comes to mind) or which are related to locale (collation), but a few 
fixes to language tags (to deal with the same ambiguities that language 
tagging folks already are aware of and discussion) would more or less 
fix the problems we face with locale tags.

Yesterday when discussing this in W3C-I18N-WG (WSTF), Martin suggested 
that one solution might just be to create a new RFC for locale 
identifiers that references 3066 or 3066bis, but creates a separate 
"referential domain".

That might be okay, but leads inexorably back to the problem Mark and I 
sketched here the other day:

Accept-Language: ja-JP
Accept-Locale: de-DE

Now what do I do?

Best Regards,

Addison

-- 
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
http://www.w3.org/International/ws




More information about the Ietf-languages mailing list