RE: [Ltru] LTRU progress and ISO 639-6

"Debbie Garside" <debbie@ictmarketing.co.uk> Thu, 16 November 2006 09:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdLl-0002xt-8B; Thu, 16 Nov 2006 04:16:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkdLh-0002tS-VY for ltru@ietf.org; Thu, 16 Nov 2006 04:15:57 -0500
Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkdLg-0001LH-5Y for ltru@ietf.org; Thu, 16 Nov 2006 04:15:57 -0500
Received: from web2.nexbyte.net by mx1.nexbyte.net (MDaemon PRO v9.0.5) with ESMTP id md50005726415.msg for <ltru@ietf.org>; Thu, 16 Nov 2006 09:18:58 +0000
Received: from DebbieLaptop ([83.67.121.192]) by home with MailEnable ESMTP; Thu, 16 Nov 2006 09:16:17 +0000
From: Debbie Garside <debbie@ictmarketing.co.uk>
To: cowan@ccil.org
Subject: RE: [Ltru] LTRU progress and ISO 639-6
Date: Thu, 16 Nov 2006 09:15:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Thread-Index: AccJR7NekZbU9plURQqQzTTAMkGT1AAFyb2g
In-Reply-To: <20061116062208.GI5359@ccil.org>
Message-ID: <2E10DD4D89E34A65A1E228C7DDD8276D.MAI@home>
X-Spam-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:18:58 +0000 (not processed: message from valid local sender)
X-MDRemoteIP: 192.168.51.14
X-Return-Path: debbie@ictmarketing.co.uk
X-Envelope-From: debbie@ictmarketing.co.uk
X-MDaemon-Deliver-To: ltru@ietf.org
X-MDAV-Processed: mx1.nexbyte.net, Thu, 16 Nov 2006 09:18:58 +0000
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: ltru@ietf.org
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: debbie@ictmarketing.co.uk
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

John wrote:

> I think this is basically the right idea, but I'd add the 
> following qualifiers (this is very preliminary):
> 
> 0) Before publication, 639-6 should be harmonized with ISO 
> 15924 and ISO
> 3166-1 where possible; that is, new optional fields should be 
> added to map kcal to Latn and kcac/kcao/kccc/kcav/kcak/kcam 
> to Cyrl, and likewise to map any country-specific code 
> elements to the 3166-1 code for the country.
> Until this is done, I don't think 639-6 is ready for use in BCP 47.

Can you elaborate as to your reasons for requiring this please?  It is not a
problem as this information is currently being compiled anyway.

> 1) In the case of a code element identical to a 639-3 code 
> element, the 639-6 addendum should be disallowed: kca, not 
> kca-6-kca, obviously.

This is absolutely correct. kca represents an ISO 639-3 code element
 
> 2) Supralanguage code elements (those which have no 639-3-equivalent
> ancestor) should be IMHO excluded from BCP 47; they are 
> unsuitable for language tagging.  I'd like to see the 639-2 
> language collections deprecated as well (though not removed, 
> of course).  There is simply no point in tagging a document 
> as being in some Indo-European language -- the tag is too 
> vague to be useful.  This is not to say, of course, that 
> these code elements are not useful for other purposes.

The hierarchical system facilitatates the exclusion of code elements "above"
ISO 639-3.

> 3) Infralanguage code elements (roughly, those that are not 
> equivalent to any code element, but have at least one of them 
> as an ancestor) should be represented using a variant rather 
> than an extension.  

I am not sure I understand this.  Please elaborate.

>We could for example use 6kcao, which is 
> a variant, rather than jumping through hoops to declare a 6 
> extension.  

OK, sounds reasonable.

>The script and country values should also be 
> used, and the variant should be omitted if it contains no 
> further data:  kca-Latn, not kca-Latn-6kcal.

Agreed, other than when suppress script comes into play.

Debbie




> 
> -- 
> The first thing you learn in a lawin' family    John Cowan
> is that there ain't no definite answers         cowan@ccil.org
> to anything.  --Calpurnia in To Kill A Mockingbird
> 
> 
> 
> 





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