Re: [Ltru] Consensus call: extlang

That's a good point, John. My corrected text should would read:

I want to get Mandarin and French. For backwards compatibility, I have to
use "zh" for Mandarin, now and the the foreseeable future (I'd pointed this
out before).

What I'd like to say is

   - under RFC 4646: "zh, fr"

As John points out,  RFC4646 is already complicated by codes with zh-
prefixes, and what I actually have to say is:

   - under RFC 4646: "zh-cmn, zh, fr, zh-gan;q=0, zh-hakka;q=0,
   zh-min-nan;q=0, zh-wuu;q=0; zh-xiang;q=0, zh-yue;q=0"

And under the proposed extlang additions, I have to say:

   - under this proposal: "zh-cmn, zh, fr, zh-cjy;q=0, zh-cpx;q=0,
   zh-czh;q=0, zh-czo;q=0, zh-gan;q=0, zh-hak;q=0, zh-hsn;q=0, zh-mnp;q=0,
   zh-nan;q=0, zh-wuu;q=0, zh-yue;q=0; zh-hakka;q=0, zh-min-nan;q=0,
   zh-yue;q=0"

Thus RFC4646 is already complicated by these codes, and the proposed change
will just make it worse.

To choose a clearer example, if I want Standard Arabic and French:

What I'd like to say, and what I use now under RFC4646 is:

   - "ar, fr"

And under the proposed extlang additions, I have to say:

   - "ar, fr, ar-aao;q=0, ar-abh;q=0, ar-abv;q=0, ar-acm;q=0, ar-acq;q=0,
   ar-acw;q=0, ar-acx;q=0, ar-acy;q=0, ar-adf;q=0, ar-aeb;q=0, ar-aec;q=0,
   ar-afb;q=0, ar-ajp;q=0, ar-apc;q=0, ar-apd;q=0, ar-arq;q=0, ar-ars;q=0,
   ar-ary;q=0, ar-arz;q=0, ar-auz;q=0, ar-avl;q=0, ar-ayh;q=0, ar-ayl;q=0,
   ar-ayn;q=0, ar-ayp;q=0, ar-bbz;q=0, ar-pga;q=0, ar-shu;q=0, ar-ssh;q=0"

Shawn,
Yes, you're right: "zh, fr" means "Chinese and French". The ISO standard
that RFC4646 is based on is woefully underspecified, so you don't know
whether that "Chinese" means Standard Chinese or also includes other
languages that people call Chinese. (Magically, "German" means only
"Standard German", and "French" means "Standard French", and so on, but
"Arabic" doesn't mean "Standard Arabic",...) The text in draft 12 makes it
clear what the extent of zh is. Yet for now and into the future, if I want
Mandarin, I have to include "zh". ("zh-cmn" has been around for almost 3
years (2005-07-15), but we are seeing **no** uptake in any web documents or
Accept-Language values.)

As far as a compromise goes, I could even live with allowing either extlang
or not, since they are not semantically or syntactically the same. Then the
user has the choice of indicating s/he wants

   - Cantonese alone ("yue"), or Cantonese-with-fallback ("zh-yue"), or
   - Babalia Creole Arabic ("bbz") alone, or Babalia Creole
   Arabic-with-fallback ("ar-bbz").

Peter,
I agree with what you were saying, I didn't intend for it to be misleading.
I was really thinking about the syntactic matching, since extlang is a
syntactic device, and Accept-Language works in terms of that syntax. If we
are dealing with semantic matching, then the situation is a bit different.

Martin,
>> "consider each of the applications of language tags: identification,
lookup, filtering, and Accept-Language, and be able to have a reasoned
judgment on the technical merits."
> I assume everybody has done this.

Based on the comments, I really doubt that. Do you really think that
everyone has considered the technical ramifications of using this with
Accept-Language, even now?

>If you, or anybody else closely involved with this work, wants to
claim that they had absolutely no idea that the extlang production
in RFC 4646 was intended, at least among else if not primarily or
only, for encompassed languages, or more concretely, for cases such
as zh-yue and friends, then I'd be extremely surprised.

I dem fall, chani di üeberasche ;-)

I can at least speak for myself -- and I was "closely involved" -- that the
extlang mechanism was to allow us the syntactic wiggle room we needed should
we decide to use it for 639-3 in any way. We knew about macrolanguages, but
we had *not* weighted all of the implications at the time, and had not
committed to the use for macrolanguages, because we didn't know what shape
639-3 might take. We even allowed for multiple extlangs in a tag.

Mark

On Mon, May 26, 2008 at 8:21 PM, John Cowan <cowan@ccil.org> wrote:

> Mark Davis scripsit:
>
> > I have been a strong proponent of RFC 4646. But I can't see any way to
> sell
> > software developers on the ways in which extlang would require a radical
> > change, eg that the Accept-Language value meaning 'Mandarin then French'
> > would be
> >
> >    - under RFC 4646: "zh, fr"
> >    - under this proposal: "zh-cmn, zh, fr, zh-cjy;q=0, zh-cpx;q=0,
> >    zh-czh;q=0, zh-czo;q=0, zh-gan;q=0, zh-hak;q=0, zh-hsn;q=0,
> zh-mnp;q=0,
> >    zh-nan;q=0, zh-wuu;q=0, zh-yue;q=0".
>
> Actually, to get *exactly* the same effect under RFC 4646 you'd need to
> say "zh-cmn, zh, fr, zh-gan;q=0, zh-hakka;q=0, zh-min-nan;q=0, zh-wuu;q=0;
> zh-xiang;q=0, zh-yue;q=0", and that's not counting the deprecated forms.
>
> --
> In politics, obedience and support      John Cowan <cowan@ccil.org>
> are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan<http://www.ccil.org/%7Ecowan>
>

-- 
Mark