[Ltru] Extended language tags

There's been lots of discussion about the extended language tags, but it doesn't seem like there've been many conclusions.  I've gleaned the following points for the discussion:

        * We (the bigger software ecosystem we, tools, etc) have encouraged use of zh-HK, etc for labeling both Mandarin and Cantonese.  Whatever happens in the future a large number of legacy documents, both Manderin and Cantonese, will be labeled with the existing language tag.

        * Whether or not yue or zh-yue was used, it is a change from the current label (in most cases).  It seems that in nearly all cases this will require a code change.  In particular applications that want to include zh-HK in lists containing zh-cmn-HK or cmn-HK will need extra awareness.

        * I don't think the Breton example applies.  http-accept-lang allows for "br-FR;fr-FR" type fallback, so that is a solution.  If an application independently wanted to make this assumption that's fine by me, but this seems orthogonal to the problem we're trying to solve here.

        * Lots of zh data right now is zh-cmn.  Most of "us" seem to agree that we can't narrow the meaning of zh because it does allow Cantonese.  However if some application wanted to make an assumption that zh == zh-cmn, then that seems up to the application for fallback.

        * Even for the current tags, many of the people in the teleconference seem to extend RFC 4647 in ways that are best for them.  Strict use of 4647 behavior seems rare.  It seems reasonable to me to expect that in the future people may continue to do so and that RFC 4647 and the registry can only provide guidelines.  I don't think that it can solve all problems for all applications, and I'm fine with that.

        * It was proposed that the registry could provide a link from cmn to zh for applications that want this.  My experience has been that the registry is good for providing recommendations, but in practice software is rarely kept current with the actual data currently in the registry.

        * FWIW: some documents are currently tagged zh-yue.

        * RFC 4646 strongly implies that that direction is zh-cmn rather than cmn.  By itself this isn't a big concern to me, but taken with the grandfathered and existing zh-yue data I would think there'd need to be a strong case to change directions.

So from these points, my conclusion is that the zh-cmn form is preferable.

My reasoning is that either cmn by itself or zh-cmn will require code change in nearly all cases, either to include or exclude existing data or fallback rules.   Either was will require a code change, and either way may require knowledge that zh-HK might be interesting if the request is for {Mandarin tag}-HK.  Searching may need to include zh files for {Manderin tag} queries and exclude them for {Cantonese tag} queries, but the actual tag doesn't really change this logic.  Neither variation is likely to work with existing code when the request is for the new name and the data is tagged with the old tag.

The deciding factor for me is that to know that cmn is related to zh I'd have to look in the registry, but zh-cmn contains that information.  Otherwise I don't really see advantages with either method.

- Shawn

SDE
Windows International
Visual Studio .Net
Microsoft

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru