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

"Broome, Karen" <Karen.Broome@am.sony.com> Wed, 15 July 2009 21:46 UTC

Return-Path: <Karen.Broome@am.sony.com>
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 221F53A6C8D for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 14:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.365
X-Spam-Level:
X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 4+R29LW3Bd9F for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 14:46:49 -0700 (PDT)
Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id AE03C3A6C66 for <ltru@ietf.org>; Wed, 15 Jul 2009 14:46:49 -0700 (PDT)
Received: from mail116-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 8.1.340.0; Wed, 15 Jul 2009 21:30:47 +0000
Received: from mail116-tx2 (localhost.localdomain [127.0.0.1]) by mail116-tx2-R.bigfish.com (Postfix) with ESMTP id 172F05681E8; Wed, 15 Jul 2009 21:30:47 +0000 (UTC)
X-SpamScore: -52
X-BigFish: VPS-52(zz542N1432R936eM1442J9371Pf4eM14bclzz1202hzz1033ILz2fh6bh61h)
X-Spam-TCS-SCL: 0:0
X-FB-SS: 5,5,
Received: by mail116-tx2 (MessageSwitch) id 1247693444440149_3412; Wed, 15 Jul 2009 21:30:44 +0000 (UCT)
Received: from mail8.fw-sd.sony.com (mail8.fw-sd.sony.com [160.33.66.75]) by mail116-tx2.bigfish.com (Postfix) with ESMTP id 35B0DF28051; Wed, 15 Jul 2009 21:30:44 +0000 (UTC)
Received: from mail1.bc.in.sel.sony.com (mail1.bc.in.sel.sony.com [43.144.65.111]) by mail8.fw-sd.sony.com (8.14.2/8.14.2) with ESMTP id n6FLUhWv009438; Wed, 15 Jul 2009 21:30:43 GMT
Received: from USBMAXIM02.am.sony.com ([43.145.108.26]) by mail1.bc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id n6FLUhfM022502; Wed, 15 Jul 2009 21:30:43 GMT
Received: from USBMAXRG02.am.sony.com ([43.145.108.24]) by USBMAXIM02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 17:30:42 -0400
Received: from USSDIXRG02.am.sony.com ([43.130.140.32]) by USBMAXRG02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 17:30:42 -0400
Received: from USSDIXRG01.am.sony.com ([43.130.140.31]) by USSDIXRG02.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 14:30:37 -0700
Received: from USSDIXMS01.am.sony.com ([43.130.140.21]) by USSDIXRG01.am.sony.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jul 2009 14:30:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0593.775833D6"
Date: Wed, 15 Jul 2009 14:30:25 -0700
Message-ID: <8D97027965E89F488BC87B919382D9FD0510BED1@ussdixms01.am.sony.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ltru] rechartering to handle 639-6 (was FW:Anomalyinupcomingregistry)
Thread-Index: AcoExZndZwd0A4NlQZKsK0un4iE/ggAUx4RwAA3VKU4ABDzJYwAKSnOwAAHcH5A=
References: <C683A5F6.F25A%kent.karlsson14@comhem.se> <8D97027965E89F488BC87B919382D9FD0510BEC2@ussdixms01.am.sony.com> <DDB6DE6E9D27DD478AE6D1BBBB8357956B0B299E56@NA-EXMSG-C117.redmond.corp.microsoft.com>
From: "Broome, Karen" <Karen.Broome@am.sony.com>
To: Peter Constable <petercon@microsoft.com>, Kent Karlsson <kent.karlsson14@comhem.se>, debbie@ictmarketing.co.uk, LTRU Working Group <ltru@ietf.org>
X-OriginalArrivalTime: 15 Jul 2009 21:30:37.0133 (UTC) FILETIME=[7E5547D0:01CA0593]
X-SEL-encryption-scan: scanned
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 21:46:51 -0000

One example:

What would you suggest for an international file-naming standard that is composed of concatenated fixed-length components (much like BCP 47) where the file name needs to indicate the language of the subtitled or dubbed asset? 

There are other examples, but this one should be well-understood by this group. What would we do in RFC 4646 if we had a source tag set with this much variability in code length? Though BCP 47 seems to work well in many situations and addresses the language lists I've seen, there have been times that I have run up against a fixed-length tag limitation.

Regards,

Karen Broome


-----Original Message-----
From: Peter Constable [mailto:petercon@microsoft.com]
Sent: Wed 7/15/2009 1:27 PM
To: Broome, Karen; Kent Karlsson; debbie@ictmarketing.co.uk; LTRU Working Group
Subject: RE: [Ltru] rechartering to handle 639-6 (was FW:Anomalyinupcomingregistry)
 
Karen: do you want a list of (order of magnitude) 10,000 language variants for users in the film & television industry to choose from, or just those that they need?

What we have now _should_ be able to deliver what they need.

One thing that an atomic, fixed-length tag does *not* do well: provide individual facets of the total information denoted -- the language, the region, the script - except by relying on carrying tables of data in which those can be looked up.


Peter

From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Broome, Karen
Sent: Wednesday, July 15, 2009 8:37 AM
To: Kent Karlsson; debbie@ictmarketing.co.uk; LTRU Working Group
Subject: Re: [Ltru] rechartering to handle 639-6 (was FW: Anomalyinupcomingregistry)


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