Re: [Ltru] Re: Macrolanguage and extlang

"Doug Ewell" <> Sun, 15 July 2007 23:33 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IADac-0005El-8I; Sun, 15 Jul 2007 19:33:22 -0400
Received: from ltru by with local (Exim 4.43) id 1IADab-0005BM-Co for; Sun, 15 Jul 2007 19:33:21 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IADab-0005BE-3O for; Sun, 15 Jul 2007 19:33:21 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IADaW-00008m-Ni for; Sun, 15 Jul 2007 19:33:21 -0400
Received: from DGBP7M81 ([]) by (InterMail vM. 201-2131-123-102-20050715) with SMTP id <>; Sun, 15 Jul 2007 23:33:15 +0000
Message-ID: <00d701c7c738$841e6930$6a01a8c0@DGBP7M81>
From: Doug Ewell <>
To: LTRU Working Group <>
References: <> <013b01c7c6a8$55cb4a20$6401a8c0@DGBP7M81> <> <>
Subject: Re: [Ltru] Re: Macrolanguage and extlang
Date: Sun, 15 Jul 2007 16:33:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Mark Davis wrote:

> The main argument I've hear for extlang is behind-the-scenes-inertia. 
> While we made provision in 4646 for possibly accepting them in the 
> future, it was by no means a done-deal.

The main argument that has been offered is that it makes matching 
easier.  Whether that argument was heard is a different question.

> The only reason I've heard advocated for them is that it makes 
> matching easier. But in practice, we have simply not found that to be 
> true. If it is indeed  worthwhile to add this mechanism to 4646, a 
> good case needs to be made for it; and inertia isn't a good case.

Here is the argument restated.  It is based not on behind-the-scenes 
inertia, but on backward compatibility, the exact same issue that caused 
us to adopt Suppress-Script.

Existing Cantonese text has been tagged as "zh", the basic ISO 
639-1-based tag, or as "zh-yue", the tag that was registered for this 
purpose back in 1999.

The extlang mechanism would have established "yue" as an extlang under 
"zh", so the proper tagging of Cantonese would continue to be "zh" (more 
general) or "zh-yue" (more specific).  Matching engines would continue 
to operate as they do now.

The proposed mechanism establishes "yue" as a primary language subtag, 
so the proper tagging of Cantonese becomes "yue".  Matching engines must 
be upgraded to RFC 4646bis in order to have any chance at finding a 
match.  The much-beloved and much-catered-to RFC 3066 remove-from-right 
"fallback" algorithm will NEVER find a match between "yue" and "zh", 
regardless of whether script and/or region subtags are involved.

Put another way: Extlangs may not make matching easier, but *not* having 
extlangs will make matching harder.

Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14

Ltru mailing list