Re: extlang (was Re: Suggested language for "mis" (Re: [Ltru] RE: ISO 639-2 decision: "mis"))

["Doug Ewell" <[e-mail]>]

John did a fine job articulating most of my position.  Anything not 
explicitly responded to here is +1.

John Cowan <cowan at ccil dot org> wrote:

> Mark Davis scripsit:
>
>> We added extlang to allow ourselves the freedom to make choices when 
>> 639-3 came along. We *very clearly did not define its meaning*, because 
>> we didn't know what 639-3 was finally going to look like,
>
> Not so much.  We had an excellent idea of what 639-3 would both look and 
> actually be like when 4646 was finalized.  We couldn't include 639-3 or 
> extlangs because 639-3 itself was not yet final.

In particular, we knew there would be macrolanguages and encompassed 
languages.  This was spelled out by Peter Constable on 2004-01-30 in a post 
which laid out the extlang concept for the first time:

http://www.alvestrand.no/pipermail/ietf-languages/2004-January/001658.html

>> nor did we have agreement on what we should actually do.
>
> We had at least the consensus of silence; at least, I don't remember any 
> complaints at the time.  Remember that the development of 4646 started at 
> least a year before LTRU was formally created.

I thought it was stronger than that, that just about everyone's expectation 
and understanding was that extlangs were intended for encompassed languages, 
and that encompassed languages would be represented by extlangs.  Tags like 
"zh-cmn" were registered at ietf-languages specifically so they would 
conform to this well-understood model.

>> Matching "zh" and "yue" is not something you want to do automatically.

That's only half true.  All Cantonese is Chinese, and since it's only been 
possible up to this point to tag Cantonese as "zh-something", it's 
reasonable to assume that much of it will continue to be tagged as 
"zh-something" in the future.

>> B. (optional) Add a field Macrolanguage: to the language subtag registry.
>
> I am not opposed to this, precisely because encompassed languages and the 
> corresponding macrolanguage cannot be identified syntactically.

So, for example:

Type: language
Subtag: qvc
Description: Cajamarca Quechua
Description: Quechua, Cajamarca
Added: 20xx-xx-xx
Macrolanguage: que

Would content in Cajamarca Quechua be required to be tagged as "qvc", or 
would "qu" also be acceptable?  (We all know "qu" would be widely used.) 
Would matching engines be permitted to perform one- or two-way matching 
between "qvc" and "qu"?  What about users who expect we will go through with 
the "qu-qvc" model, and the Web pages that have already started listing such 
tags?  (See www.udhrinunicode.org, for instance.)  Would all this require an 
update to 4647?

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages



_______________________________________________
Ltru mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru