Re: [Ltru] a modest proposal...

"Phillips, Addison" <addison@amazon.com> Fri, 30 May 2008 00:18 UTC

Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE833A6BB8; Thu, 29 May 2008 17:18:33 -0700 (PDT)
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 DAFE83A6B79 for <ltru@core3.amsl.com>; Thu, 29 May 2008 17:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.437
X-Spam-Level:
X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 rAuyXPLEuoNg for <ltru@core3.amsl.com>; Thu, 29 May 2008 17:18:31 -0700 (PDT)
Received: from smtp-fw-6101.amazon.com (smtp-fw-6101.amazon.com [72.21.208.25]) by core3.amsl.com (Postfix) with ESMTP id A88DC3A68A1 for <ltru@ietf.org>; Thu, 29 May 2008 17:18:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,563,1204502400"; d="scan'208";a="316660354"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-6101.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 May 2008 00:18:29 +0000
Received: from ex-hub-4101.ant.amazon.com (ex-hub-4101.ant.amazon.com [10.248.163.22]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id m4U0IQf6019179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 30 May 2008 00:18:29 GMT
Received: from ex-pub-4102.ant.amazon.com (10.248.180.20) by ex-hub-4101.ant.amazon.com (10.248.163.22) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 29 May 2008 17:18:26 -0700
Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-pub-4102.ant.amazon.com ([10.248.180.20]) with mapi; Thu, 29 May 2008 17:18:12 -0700
From: "Phillips, Addison" <addison@amazon.com>
To: Leif Halvard Silli <lhs@malform.no>, LTRU Working Group <ltru@ietf.org>
Date: Thu, 29 May 2008 17:18:23 -0700
Thread-Topic: [Ltru] a modest proposal...
Thread-Index: AcjB6ER82RDxEg4kTuOQJ6hskHS8bAAAAp9w
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013A90F954@EX-SEA5-D.ant.amazon.com>
References: <4D25F22093241741BC1D0EEBC2DBB1DA013A84C706@EX-SEA5-D.ant.amazon.com> <483F43C2.50905@malform.no>
In-Reply-To: <483F43C2.50905@malform.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Ltru] a modest proposal...
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

>
> > 2. Keep the Macrolanguage field in the registry for all [...]
>
>
> Will encompassed Chinese languages have the macrolanguage field?

Perhaps you should read the current draft?

>
> It is good if all macro and encompassed languages are treated the
> same way. But then it is perhaps also questionable if there are
> two such important exceptions.  Chinese is a classic example of
> what "macrolanguage" is or means.

See: "elephant in the room"

>
>  > 3. Cherry pick *only* the 'zh' (and possibly the 'ar')
>  > encompassed languages for registration as extlangs. This is
>  > done in the name of compatibility alone.
>
> I support including 'sgn'. But what does "in the name of
> compatibility alone" mean? That it isn't linked to macrolangauge?
> If it *is* linked to macrolanguage, then you can't explain it as a
> compatibility issue and vice-versa.

It means: it is not linked to "macrolanguage", a feature of ISO 639-3. It is strictly recognition that past tagging practice has used "zh-*" and "sgn-*". It has nothing to do with anything else.

>
>  > 4. Permit implementations to treat the 'language' production as
>  > atomic (that is, the sequence "zh-yue" MAY be treated as if it
>  > were a single subtag but MAY be treated as separate subtags,
>  > notably by existing implementations). Note that the 'language'
>  > production is the one that includes both the primary and
>  > extended language subtags.
>
> Might all these exceptions to 'zh' only hamper Chinese and Sign
> languages (and in the end perhaps make this tagging style unstable?)?

Uh...

1. "sgn" is not a macrolanguage and should not be.

2. The above should not hamper Chinese or sign languages. Why would you think so? You seem to support extlang. This is extlang for those languages solely.

>
> ALTERNATIVE PROPOSAL: Let's cherry pick in some way or another.

You are welcome to suggest another cherry picking device.

> But let's have extlang as a macrolanguage thing, and thus explain
> it not as an exception for compatibility reasons, but as one of
> two method for handeling the macrolanguage identification.

Well, no. The point of the "modest proposal" was to try and break the logjam in which some of us insist that we'd be better off without extlangs and others insist we'd be better off with them.

You are proposing having TWO methods tagging the same language variety, an idea that is antithetical to language tagging and which presents more problems than it solves.

Addison


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