Subject: Re: [Ltru] I'm really confused by chinese in 4646bis (was my incorrectly named brain-cramp :)

From: Shawn Steele <[email-masked]>
Date: Fri, 2 May 2008 23:19:59 -0700

> I stand by what I said: it has long been used to mean just Mandarin. If you make a

> request using 'zh' to products from Google, Microsoft, Apple, Sun, and so on, in

> practice that does not mean:

>     Give me some kind of Chinese, I don't care whether it is Mandarin or Cantonese or Hakka.

> Instead, in practice, it means:

>     Give me Mandarin.

I would disagree (for Microsoft products).  We don't provide any other code (easily) to the end-user, so a Chinese speaker in HK would have to request zh-HK, regardless of whether they really wanted Cantonese or Mandarin.  I will happily recognize that our localization is Mandarin and that most of the content you'd get from a search would be Mandarin, but that doesn't mean that we meant Mandarin.  In fact we end up saying "Chinese (Traditional)" in the UI, so we're pretty vague.

> I am NOT saying that zh is the same as cmn. I'm not changing the semantics of 'zh' at all*.
> What I'm saying is: although they are semantically distinct, my advice to most users

> would be that in practice for backwards compatibility in programs they are best off treated

> as synonyms.

That seems to be quibbling a bit.  If you tell developers/users to treat them as synonyms, especially if you also say "use zh for back compat", then the net result is that they are synonyms with no special meaning.  If I always use cmn as an alias for zh and zh as an alias for cmn, then they will behave identically.  If they end up behaving identically, then there's no point in having distinct codes.  Assuming that I really, really need them to be distinct for my application or data for some reason, then I won't be able to because anything I interoperate with is going to assume that they are identical because of the recommendation.

Frankly, its easiest for me to just say "zh" == Mandarin.  I haven't figured out how I'm going to do Windows & .Net resource fallback and user locale settings if the preference gets changed from "zh" to "cmn".  cmn-HK would still need to find zh-HK or zh-Hant resources.  New apps would also need to find cmn tagged resources even when the user UI language was zh-HK.  So it would seem that I'm sort of stuck treating them as aliases for each other.

>From the discussion and the draft it seems that there're a few suggestions/interpretations:

* Use zh and cmn as aliases for each other.  This seems silly to me and just maintenance headache.  I include the zh==cmn 99.99999% of the time case here because in practice the other 0.00001% isn't going to be able to shake the aliasing.

* Just use zh and grandfather cmn, that way at least we have a consistent, if a tad odd, behavior.

* Use zh for "Chinese" and cmn for "Mandarin".  As I said, the migration seems pretty tough, but at least the meaning is clear.

* Use zh for Chinese and zh-cmn for Chinese (Mandarin).  I realize we already decided against this form, but perhaps its worth reconsidering.  Then the fallback is clear, as are the different use cases.  Migration is still a pain, but there's a chance that some of my back-compat cases would accidentally solve themselves when apps do RFC 4647 style fallback.  (There's no chance of existing apps figuring out that cmn should consider zh as a fallback.)

Whatever is chosen, I think the RFC MUST ;-) be explicit.  Particularly if it is recommending that sometimes Mandarin should be tagged one way, but sometimes it could be tagged another way.

- Shawn
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru