Addison: > Interestingly, the W3C I18N WG published a new working draft...
Great! I'll certainly be interested in reading it. (When I get a chance -- I still need to look at the 2nd draft of RFC3066bis; I know, you'd like that to be done yesterday.) > 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. I can feel a little bit vindicated, then :-) > Locale interchange is very important to > internationalized software.... > So, there are very valid reasons why applications need to transfer locale preferences. That, I have never questioned. > 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... > 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"). I've agreed that the two are related, and I don't contest that a language tag can be useful in making decisions about setting the locale mode of a software process. All I have said is that the notions of "locale" and "language" are distinct, that in general non-linguistic locale parameters such as number format are not appropriate things to declare about documents, and so we should not design systems or protocols that assume that locale tags can be inserted in document metadata attributes where a language tag is specified. And that it's not helpful in getting people to understand what is or isn't good to do for someone providing some degree of leadership in the area to use the terms "language" and "locale" interchangeably. Peter Peter Constable Globalization Infrastructure and Font Technologies Microsoft Windows Division
