[Ltru] Re: Punjabi

"Doug Ewell" <dewell@adelphia.net> Sat, 17 March 2007 16:50 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 1HSc6d-0001E2-PI; Sat, 17 Mar 2007 12:50:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSc6c-00018x-1H for ltru@ietf.org; Sat, 17 Mar 2007 12:50:10 -0400
Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSc6a-00011K-Mv for ltru@ietf.org; Sat, 17 Mar 2007 12:50:10 -0400
Received: from DGBP7M81 ([76.167.184.182]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20070317165005.LUC6520.mta13.adelphia.net@DGBP7M81>; Sat, 17 Mar 2007 12:50:05 -0400
Message-ID: <004301c768b4$50b4d9e0$6401a8c0@DGBP7M81>
From: Doug Ewell <dewell@adelphia.net>
To: LTRU Working Group <ltru@ietf.org>
References: <E1HRsNL-0001ob-5h@megatron.ietf.org> <003501c76756$f2213760$6401a8c0@DGBP7M81> <30b660a20703161305h1f007acalb7ecf2c45224b4da@mail.gmail.com> <20070316210509.GF17950@mercury.ccil.org> <30b660a20703161537q77fcf86y9c6488e0eb0603b@mail.gmail.com> <45FB2259.7050202@yahoo-inc.com>
Date: Sat, 17 Mar 2007 09:50:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc:
Subject: [Ltru] Re: Punjabi
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

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> To respond to Doug's point, I think that we are not *forced* to delay 
> RFC 4646bis or even 4645bis's appearance. What we need are clear rules 
> for the incorporation of ISO 639-3 into the registry scheme.

Which will then be a significant part of RFC 4645bis.

> This *could* take the form of a Big Bang insertion. But it would 
> certainly be valid to insert only the language (and not the extlang) 
> codes initially or to include only the finalized and stable extlang 
> codes when they are mature---on a different day.

That's an interesting idea.  It gets us almost 6,700 new primary 
language subtags that weren't available before.  One possible drawback 
is that it leaves the Panjabi/Lahnda question (and others) open, and 
might prolong the period during which things get tagged incorrectly, at 
a time when the increased capacity and visibility of our mechanism may 
spark an increase in the use of language tags.

> I would suggest that a mechanism for doing this would be to take each 
> macro-language, as a collection, and vet the contents with the RA and 
> on-list with ietf-languages before doing an insert. The Chinese and 
> Arabic collections probably get in straight-away. Lahnda's subtags (by 
> way of example) could wait---and no one is hurt by that delay. The 
> only hurt is getting the mapping wrong. Worst case we have some 
> languages that could have been extlangs that become primary language 
> subtags instead.

I wonder how subjective this "vetting" process might be, or might be 
perceived to be.  I can easily imagine other experts or native speakers 
castigating us for getting the decision "wrong," if there are no 
hard-and-fast rules.  At least if we add all encompassed languages that 
aren't currently subtags (a) as extlangs --  the original plan -- or (b) 
as primary language subtags, it can be defended as a rule application 
and not a value judgment on our part.

As you can tell, I'm not at all sure what the best course of action is, 
if we are going to revisit this most basic assumption of LTRU 2.0.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages


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