[Ltru] Re: extlang

"Mark Davis" <mark.davis@icu-project.org> Wed, 29 August 2007 01:12 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 1IQC6Q-0003Yi-Mf; Tue, 28 Aug 2007 21:12:14 -0400
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IQC6O-0003Yc-TH for ltru-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 21:12:12 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQC6O-0003YR-HX for ltru@ietf.org; Tue, 28 Aug 2007 21:12:12 -0400
Received: from wa-out-1112.google.com ([209.85.146.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQC6N-00076L-Je for ltru@ietf.org; Tue, 28 Aug 2007 21:12:12 -0400
Received: by wa-out-1112.google.com with SMTP id k40so4892wah for <ltru@ietf.org>; Tue, 28 Aug 2007 18:12:11 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KXts8PuA42vKRvEv4Ti3FcU3NVy0301vEr7vYvQGdkz7HAthDjuLmP0DdBw2ewT+kI3MlsDWi6no+CGITmiog3iGWH0SpcF92uEIVRjXkq4I/teSK74rO5MGZ2Dedt9uoFOwi6427lRRqqUePcla/GUqcR6S4N03D209RqkOrhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jah2rp9oqeFwP/UMkUY6flP52r4hE0groW3OdnaS1nBvuBVGPleKieEbuhdnzXJDxNN7nOc7UNswRrt7qaGBdRvR8pAXIkM+vljH1pmoXnP/vsiZgOTyWXNC91WQDhtCM/otxDNjTXbWRBV8atbGYwOw7LxFFyG5sF4o+5+6tGY=
Received: by 10.114.95.1 with SMTP id s1mr24236wab.1188349930495; Tue, 28 Aug 2007 18:12:10 -0700 (PDT)
Received: by 10.114.196.12 with HTTP; Tue, 28 Aug 2007 18:12:10 -0700 (PDT)
Message-ID: <30b660a20708281812s3401e193u7c90d3ab22ac3eda@mail.gmail.com>
Date: Tue, 28 Aug 2007 18:12:10 -0700
From: Mark Davis <mark.davis@icu-project.org>
To: John Cowan <cowan@ccil.org>
In-Reply-To: <20070828223536.GB31670@mercury.ccil.org>
MIME-Version: 1.0
References: <30b660a20708281459r6000d746qe007f2882fae6d73@mail.gmail.com> <20070828223536.GB31670@mercury.ccil.org>
X-Google-Sender-Auth: 0e07330a814c19ba
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: LTRU Working Group <ltru@ietf.org>
Subject: [Ltru] Re: extlang
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>
Content-Type: multipart/mixed; boundary="===============1970632107=="
Errors-To: ltru-bounces@ietf.org

> RFC 1766 already said that fallback doesn't always work, and sometimes
> produces something unintelligible to the requester.
>
> But I believe you are misusing the term "macrolanguage".  A macrolanguage
> is not to be equated with a "main" or standardized variety.  Some
> macrolanguages like Chinese and Arabic have such varieties, others like
> Quechua and Nahuatl do not.


I'm not misusing it -- nothing I said had anything to do with the
definition, it has to do with the functional implications. If a language yyy
has the macrolanguage xx, we are talking about two possible representations

a) extlang: xx-yyy
b) lang: yyy

The main reason I've heard from you for doing (a) instead of (b) is that (a)
it has better fallback behavior. For that to be true, xx has to be a good
fallback for users of yyy, in the majority of cases. And the value has to be
worth having the extra structure. So, a natural question to ask is: are you
sure that of ALL the languages on
http://www.sil.org/iso639-3/macrolanguages.asp, the ones that we are talking
about this mechanism for, that the fallback is indeed good.

I really want some reasonable attention paid to the implications of this
whole apparatus before we ship this, because once we do, it is irrevocable!

There are (at least) two cases to consider here.


   1. There is a predominent choice in the industry for the macro
   language. For example, the content for zh is typically always Mandarin; the
   content for ar is typically always standard Arabic. Look at the concrete
   implications. It means that whenever Joe looks for a web page in Hakka
   Chinese, he will typically fall back to Mandarin. Whenever Sarah looks for a
   page in Tunisian Arabic, it will fall back to standard Mandarin.

   If you are saying however, that zh is not necessarily Mandarin, that
   Arabic is not necessarily Standard Arabic, then we fall through to case 2.

   2. There is not a predominant choice in the industry, let's say for
   Hmong. In this case, the situation is different. I could choose any of the
   Hmong for the content for hmn. We then have an even dicer case for the value
   of extlang. I localize my hmn locale with contents appropriate for
   Northeastern Dian Hmong; is that a good default for someone speaking Eastern
   Xiangxi Hmong? for Luopohe Hmong? For all the other Hmongs?


For extlang to be a good apparatus, these always have to be good choices,
since we are baking the structure into the tag.

If Peter Constable came out and said the following, then I would admit to my
sins, give in gracefully, and go along with extlang.

   - "Yes, each of the Hmongs (encompassed by hmn) are mutually
   intelligible, and are better for each one than another fallback like
   Chinese"
      - and the same is true for all the other cases with no
      predominant variant.
   - "Yes, standard Arabic is intelligible for all the encompassed
   languages from Algerian Saharan Arabic to Shihhi Arabic, and are better for
   each one than another fallback like French"
      - and the same is true for all the other cases with a
      predominant variant.

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