From: Addison Phillips [wM] (aphillips@webmethods.com)
Date: Thu May 13 2004 - 12:16:10 CDT
Interestingly, the W3C I18N WG published a new working draft of our Web services scenarios document just yesterday and some of that document grapples with this issue--when and how to exchange locale information and other "international preferences", as well as when and how to exchange language information. The document is here:
http://www.w3.org/TR/2004/WD-ws-i18n-scenarios-20040512/
I think what's interesting is that our document illustrates some of the situations in which you might wish to exchange locale information. And I think these illustrations go more to prove Peter's point than not. Locale interchange is very important to internationalized software. Certainly language tags carry or imply locale information in certain situations. Although the concepts are related, it needs to be very clear just how much information one can infer from a language tag.
For example, if you read XSLT (see: http://www.w3.org/TR/xslt#convert) and think that the "lang" attribute for converting numbers to strings is a locale, then you probably haven't read the text closely enough. It really means something more like language (I think this particular example illustrates just how fuzzy the edges are pretty nicely.)
Antoine Leca's example is a good one (there is a similar one in the document above, donated by Mark Davis), and I think it shows how distributed software needs to have locale information in order to produce results that one could deem "correct" (if that text were generated by a message formatter, for example). But we shouldn't confuse language tagging of the result ("english") with software processing used to produce it (that sentence might have been rendered in the locale "de-DE").
So, there are very valid reasons why applications need to transfer locale preferences. Check out our group's document (and the forthcoming requirements document) and see if you don't agree... but we should be wary of very broad global statements (both "all language tags are also locale tags" and "language tags are never locale tags").
Best Regards,
Addison
Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
> -----Original Message-----
> From: unicode-bounce@unicode.org
> [mailto:unicode-bounce@unicode.org]On Behalf Of Peter Constable
> Sent: 2004年5月13日 7:40
> To: Unicode Mailing List
> Subject: RE: TR35
>
>
> > Well, it is true that what I really search for is not *exactly* the
> > formatting locale, but rather another wider information, which would
> be the
> > mind setting of the writer.
>
> Precisely. The locale info only tells you how a number would have been
> formatted by the author's system, not what the author in fact did. When
> you receive a document, being told what the system would have done
> doesn't tell you anything useful. Not unless the document you receive
> was generated by the system -- and I'm guessing that in many such
> situations what's exchanged isn't a document per se but data structures
> in which numbers are in some pre-defined representation not formatted
> for the user.
>
> I'm not saying that there is never a need to exchange locale-setting
> info. Only that I don't think it's appropriate in general to tag
> documents (by which I don't mean an accounting spreadsheet or an
> order-entry record) for things like number formatting, and so such info
> should not be included in attributes like xml:lang.
>
>
> > I have another example, but I cannot expose it here publicly, it is
> related
> > to some proprietary software.
>
> If something is going on internal to proprietary software, then there
> are no rules. This is only about public interchange.
>
>
>
> Peter
>
> Peter Constable
> Globalization Infrastructure and Font Technologies
> Microsoft Windows Division
>
This archive was generated by hypermail 2.1.5 : Thu May 13 2004 - 12:18:17 CDT