Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)

Kent Karlsson <kent.karlsson14@comhem.se> Wed, 15 July 2009 18:32 UTC

Return-Path: <kent.karlsson14@comhem.se>
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54993A693A for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 11:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level:
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJupelNCyb2R for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 11:32:03 -0700 (PDT)
Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by core3.amsl.com (Postfix) with ESMTP id E909D3A6BB9 for <ltru@ietf.org>; Wed, 15 Jul 2009 11:32:02 -0700 (PDT)
Received: from c83-248-191-93.bredband.comhem.se ([83.248.191.93]:35566 helo=[192.168.1.2]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from <kent.karlsson14@comhem.se>) id 1MR9CS-0006vk-5v; Wed, 15 Jul 2009 20:27:36 +0200
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Wed, 15 Jul 2009 20:26:56 +0200
From: Kent Karlsson <kent.karlsson14@comhem.se>
To: "Broome, Karen" <Karen.Broome@am.sony.com>, debbie@ictmarketing.co.uk, LTRU Working Group <ltru@ietf.org>
Message-ID: <C683EC10.F28D%kent.karlsson14@comhem.se>
Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)
Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4ABDzJYwAGNWFd
In-Reply-To: <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3330534448_51682217"
X-Originating-IP: 83.248.191.93
X-Scan-Result: No virus found in message 1MR9CS-0006vk-5v.
X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MR9CS-0006vk-5v 73eedc8d25b9c77bbead8d0ae9e846f3
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 18:32:04 -0000

I never intended to give the impression that I assumed that dialect tagging
was obscure, nor that having a distinction between spoken and written
variants would not be useful. I just noted that the number of registrations
for dialect variants in the Language Subtag Registry is miniscule covering
only a handful of dialects of even fewer languages. And that after several
years of having a Language (Sub)Tag Registry with registration possibility.

    /kent k


Den 2009-07-15 17.37, skrev "Broome, Karen" <Karen.Broome@am.sony.com>:

> For what it's worth, the film and television world does have a pretty heavy
> requirement for dialect distinctions. We also have a need to identify spoken
> and written variants. ISO 639-6 also provides a fixed-length tag, which can be
> advantageous in some situations. While I tend to see ISO 639-6 as an
> interesting alternative to xml:lang and not necessarily something I'd use
> within xml:lang, I wanted to correct the assumption that dialect tagging is
> obscure and the distinction between spoken and written variants is not useful.
> 
> Regards,
> 
> Karen Broome
> 
> 
> -----Original Message-----
> From: ltru-bounces@ietf.org on behalf of Kent Karlsson
> Sent: Wed 7/15/2009 6:27 AM
> To: debbie@ictmarketing.co.uk; 'LTRU Working Group'
> Subject: Re: [Ltru] rechartering to handle 639-6 (was FW:
> Anomalyinupcomingregistry)
> 
> 
> Den 2009-07-15 09.00, skrev "Debbie Garside" <debbie@ictmarketing.co.uk>:
> 
>> > Well for starters, there are separate codes for Catalan and Valencian :-)
> 
> So does BCP 47 (well, nearly):
>     ca
>     ca-valencia
> 
> There is nothing in principle hindering a registration of a variant subtag
> specifically for "true" Catalan (no value judgement implied).
> 
>> > And, I rather like the way ISO 639-6 deals with variants of Chinese.
> 
> 639-3 also deals with "variants" of Chinese (separate languages, really).
> How does 639-6 do it differently (apart from using 4-letter codes instead of
> 3-letter codes)?
> 
>> > Perhaps you would like to tell me how many of the 7000+ codes of ISO 639-3
>> > will be used.  My guess is approximately 2-300 at present but over time
>> more
>> > and more.  The answer is the same for ISO 639-6.
>> >
>> > Essentially, all the reasons for including ISO 639-6 are the same as for
>> > including ISO 639-3.  Unless of course, you think that ISO 639-3 is perfect
>> > and defines all languages distinctly and that anything else cannot, is not,
>> > and definitely is not a language.  Then of course you have to decide that
>> > BCP 47 will only deal with languages and not dialects.
> 
> BCP 47 does deal with dialects, using variant subtags. However, it is very
> very far from systematic or comprehensive. It requires individual
> registration of each variant. I would venture to guess that that process
> will never result in a systematic or (in some sense) comprehensive set
> of variant subtags for dialects. On the other hand, the call for tagging
> dialects separately, currently seems fairly small amongst the consumers of
> BCP 47, IMHO.
> 
>     /kent k
> 
>> > Then, and only then,
>> > may you exclude ISO 639-6.
>> >
>> >
>> > Debbie
> 
> 
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
> 
> 
>