RE: [Ltru] Re: Macrolanguage and extlang

Peter Constable <petercon@microsoft.com> Mon, 16 July 2007 15:52 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASs4-0005TE-N8; Mon, 16 Jul 2007 11:52:24 -0400
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IASs3-0005T6-Gw for ltru-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 11:52:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASs3-0005Sy-7P for ltru@ietf.org; Mon, 16 Jul 2007 11:52:23 -0400
Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IASry-0000R4-SW for ltru@ietf.org; Mon, 16 Jul 2007 11:52:23 -0400
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 16 Jul 2007 08:52:18 -0700
Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) with mapi; Mon, 16 Jul 2007 08:52:16 -0700
From: Peter Constable <petercon@microsoft.com>
To: LTRU Working Group <ltru@ietf.org>
Date: Mon, 16 Jul 2007 08:52:21 -0700
Subject: RE: [Ltru] Re: Macrolanguage and extlang
Thread-Topic: [Ltru] Re: Macrolanguage and extlang
Thread-Index: AcfHOInSie+xawurRiqXq8VKFSVaDgAgQz0w
Message-ID: <DDB6DE6E9D27DD478AE6D1BBBB83579560F3DACC17@NA-EXMSG-C117.redmond.corp.microsoft.com>
References: <E1I9ghp-0006L9-0h@megatron.ietf.org> <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <20070715152301.GY9402@mercury.ccil.org> <30b660a20707151612k14b1e578q7cc7887c68ccc785@mail.gmail.com> <00d701c7c738$841e6930$6a01a8c0@DGBP7M81>
In-Reply-To: <00d701c7c738$841e6930$6a01a8c0@DGBP7M81>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

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