RE: [Ltru] Extended language tags (long reply)

================

What we don't want to do is make recommendations that if implemented, are harder for people to control and get the right answer. And baking extlang into the tags is even worse -- since it introduces backwards incompatibilities that require old code to be modified to work around.

================

cmn is completely incompatible with existing practice anyway, so you can’t claim that it solves the problem.  Existing clients ask for zh-HK (or whatever) and code is tagged as zh-HK (or whatever).  Those won’t match cmn using RFC 4647.

So for backwards compatibility zh-cmn is no worse than cmn.  And if you don’t like the inference of the zh, then you can ignore that part, but at least the data’s there if people do want it.

For some macro languages the strict fallback is probably inappropriate, however I don’t expect to find matches in that case (because I don’t expect correctly tagged data to be “zh”).  If this is a concern, those are easily filtered out.

From the discussion I don’t think the bigger problem is whether or not we go with zh-cmn or just cmn.  The bigger issue seems to be how to modify RFC 4647 to provide meaningful fallback with whichever mode is used.  Since some applications may (or may not) want to consider zh-HK or other legacy behaviors, such recommendations aren’t trivial.  Given the differing requirements amongst us, I suspect a certain flexibility of the applications will be necessary, perhaps several suggestions rather than the strict behavior of RFC 4647 (which everyone seems to modify for their purposes anyway)

- Shawn