RE: [Ltru] Re: Macrolanguage and extlang

It's not clear to me why matching

(A) zh-Hans-CN with zh-yue-Hans-CN

is much harder than matching

(B) zh-Hans-CN with yue-Hans-CN.

In the (B) case, you need to treat "zh" and "yue" as a match at some level. In the (A) case, you need to treat "zh" and "zh-yue" as a match at that same level. The only added work for (A) is that you need to recognize "zh-yue" as the entity to be compared. But then, for (B) you still need to recognize that "yue" may match something other than "yue". There is some extra work either way.

The RFC 1766/3066 remove-from-right algorithm won't get a match in case (A), but neither will it do so in case (B). At least with the approach used in (A), it will match zh and zh-yue, whereas it won't match zh and yue, as Doug pointed out.

On the other hand...

It's not clear how important the zh/zh-yue versus zh/yue example is for Chinese: it makes an valid argument against (B) if existing content is tagged "zh-yue"/"zh-yue-Han?" and a language range "zh" is used, but says nothing about cases of content tagged "zh"/"zh-Han?"/"zh-??" and a language range "zh-yue". If we're concerned about legacy content created before the extlang "yue" was introduced, that would be the latter.

Mark's and Addison's proposal does have a couple of points in its favour -- these may or may not be significant:

- Whereas using an extlang in a case like "zh-yue" was easy to consider, not all other cases will necessarily be as easy. (Clearly we don't want to introduce macrolanguage/extlang pairs for Norwegian or Serbo-Croatian, but I think we've assumed all along these can be treated as grandfathered cases.) Mark's proposal means we're never required to consider whether "xxx-yyy" is really helpful: we just always use "yyy".

- If there's ever a case in which ISO 639 has related languages "xxx" and "yyy" and a new macrolanguage "mmm" encompassing the two is later added, we don't need to retag existing content as "mmm-xxx" and "mmm-yyy", nor do we need to do any special-case processing with the registry to keep "mmm-xxx" and "mmm-yyy" from being used. And neither do implementers need to introduce new mechanisms to get appropriate matches between "mmm" and "xxx"/"yyy" since, under M&A's proposal, they already would have a general mechanism in their matching process for this; all they need is to incorporate the new data.

Peter

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