[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
That might be okay, but leads inexorably back to the problem Mark and I
sketched here the other day:
Now what do I do?
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