Subject: Re: [Ltru] "extlangish" (was: Re: draft updated)

From: "Doug Ewell" <[email-masked]>
Date: Fri, 20 Jun 2008 20:42:34 -0600

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>> One thing for which there was NEVER any consensus was to pick 
>> individual encompassed languages to be extlangs based on whether 
>> there was a corresponding "extlangish" grandfathered tag.  That would 
>> make "cmn" an extlang but not "cdo".  That way lies complete madness.
>
> Not an argument for picking individual extlang subtags. But as I read 
> the arguments, it has been a motivation for picking certain primary 
> laguage subtags to get extlang subtags: the backwards compatibility 
> argument for extlang support. And that really only applies to 'zh', 
> very very weakly to 'sgn' (I'd say not at all, but...), and not at all 
> to 'ar' or any other primary language subtags.

It's true that RFC 1766/3066 tags were registered in the form 
"zh-something", and that some of these tags syntactically resemble 
language-extlang pairs and others resemble language-variant pairs.  I 
would say this is more an artifact of the macrolanguage nature of 
Chinese -- sometimes it is considered a single language, as in ISO 639-1 
and -2, while other times it is considered a family of languages --  
rather than an attempt to maintain compatibility with the "extlangish" 
tags.

As for the other prefix languages, none of the proposed "sgn-something" 
extlang combinations is compatible with the registered tags, and there 
are no registered tags in "ar" or the other four languages, so I 
wouldn't say there is any backward compatibility argument at all.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 20 Jun 2008 22:01:17 -0600

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

>> Admittedly this was a bit more plausible in 2001, when we were still 
>> fooling ourselves that there was no generative mechanism and tags 
>> were completely atomic.
>
> The <language code>-<region code> tags have been generative since RFC 
> 1766.

Both 1766 and 3066 do say this about the language-region combinations. 
My comment was based largely on the remarks of Harald Alvestrand (of 
course the author of 1766 and 3066), back in June 2004 when we were 
planning to extend the generative mechanism beyond languages and 
regions:

"I think subtag registration is an approach that is harder to manage and 
less useful to the wide communtiy than a whole-tag registration scheme, 
and I think that generative grammars that permit 'all well-formed tags' 
is less useful than a scheme that permits only tags that someone has 
bothered to argue are useful. But I have been convinced by the debate on 
the ietf-languages list that a) I'm in a minority on this, and b) there 
are reasonable arguments for switching to a generative scheme."

RFC 1766 actually went farther than this in declaring tags, even the 
language-region combinations, to be atomic:

"Applications should always treat language tags as a single token; the 
division into main tag and subtags is an administrative mechanism, not a 
navigation aid."

> And both RFC 1766 and RFC 3066 say (without exception!) that the 
> two-letter second subtags are region subtags (here the 1766 
> formulation; slighly expanded, but still no exeptions, in RFC 3066):
>
> |    -    All 2-letter codes are interpreted as ISO 3166 alpha-2
> |         country codes denoting the area in which the language is
> |         used.

This is true as far as it applied to generative tags.  The problem was 
that RFC 3066 introduced the "additional information" registration 
model, specifically to sanction the sign-language tagging mechanism that 
actually changed the definition of the tags somewhat:

"This [registration] procedure MAY also be used to register information 
with the IANA about a tag defined by this document, for instance if one 
wishes to make publicly available a reference to the definition for a 
language such as sgn-US (American Sign Language)."

Although the second subtag in each of the registered sgn-tags was in 
fact an ISO 3166 alpha-2 country code, it was meant to identify the 
language, not necessarily its region of use.  Not only is ASL used 
outside the United States, as John pointed out, but the tag "sgn-US" 
applies equally to ASL in the U.S. or anywhere else.  This is not the 
usual purpose of region subtags; while they are not expected to be 
laser-precise in pinpointing geographic usage, they are meant to show 
regional differences:

"But on forty-three minutes, United were level."  (actual en-GB quote)
"But with two minutes to go in the half, Manchester United tied it up." 
(translation into en-US)

> I see that as implying that there is an implicit "as used in the US" 
> part of the description of "sgn-US", even though that is not part of 
> the description for "sgn-US" in the registry. (Etc. for the other 
> sgn-* grandfathered tags.)

We don't have to guess at this; we could simply ask Michael what his 
intent was for the denotation of these tags.

I'm basing my interpretation on the Description fields in the Language 
Subtag Registry, which were copied from the RFC 3066 registration 
records, and on the table at evertype.com which lists the registered 
sgn-tags as well as many others which were never proposed, and on my 
recollection from the discussions on ietf-languages in 2001.

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 20 Jun 2008 22:13:53 -0600

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> As long as each grandfathered tag has a preferred value that is a 
> non-grandfathered tag, everything's fine. Even "i-default" could be 
> given that status - when you look at the RFCs where it is used, "und" 
> would work just fine. And "i-default" would still be valid, and 
> perfectly acceptable for use in those RFCs.

I still don't see the point of this at all.  Even if we could have a 
regular tag for every single grandfathered tag -- even the oddball cases 
like "i-default" and "zh-min" -- we still can't wish away the 
grandfathered tags.  They are still legal for tagging, and parsers still 
have to recognize them, regardless of whether they are canonical or not.

Therefore, when Mark continues:

> However, this all pales in priority to getting 4646bis out the door.

I concur very, very strongly, and suggest that we not reopen this 
Pandora's can of worms unless some truly new information is provided.

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 22 Jun 2008 14:37:27 -0700

First, the advantage is that a parser can convert them into regular codes,
and then any further processing in the pipeline can assume regularity.

Second, it is perfectly permissible for a particular parser to recognize a
subset of BCP 47 codes (like the ones that a produce supports).

Mark

On Fri, Jun 20, 2008 at 9:13 PM, Doug Ewell <[email-masked]> wrote:

>> non-grandfathered tag, everything's fine. Even "i-default" could be given
>> that status - when you look at the RFCs where it is used, "und" would work
>> just fine. And "i-default" would still be valid, and perfectly acceptable
>> for use in those RFCs.
>>
>
> like "i-default" and "zh-min" -- we still can't wish away the grandfathered
> tags.  They are still legal for tagging, and parsers still have to recognize
> them, regardless of whether they are canonical or not.
>
> I concur very, very strongly, and suggest that we not reopen this Pandora's
> can of worms unless some truly new information is provided.
>
> --

---

From: John Cowan <[email-masked]>
Date: Sun, 22 Jun 2008 19:13:27 -0400

> and then any further processing in the pipeline can assume regularity.

If you want to do that (and I agree it is a reasonable thing to do),
then you need to:

a)	Get a variant tag for "OED orthography" from ietf-languages.

b)	Figure out what to do with "i-default".

c)	Get a 639-3 language code for Enochian from Linguist List.

d)	Get a variant tag for "Mingo dialect of Seneca" from
	ietf-languages; alternatively, get a 639-3 language code for
	Mingo from SIL.

e)	Get a collection code for "Gaulish languages" from LoC;
	alternatively, get a macrolanguage code for "Gaulish" from SIL.

f)	Get a collection code for "Min Chinese languages" from LoC.

-- 
He made the Legislature meet at one-horse       John Cowan
tank-towns out in the alfalfa belt, so that     [email-masked]
hardly nobody could get there and most of       http://www.ccil.org/~cowan
the leaders would stay home and let him go      --H.L. Mencken's
to work and do things as he pleased.              Declaration of Independence
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 22 Jun 2008 19:55:03 -0600

> b) Figure out what to do with "i-default".

b) Get a registered language subtag 'default' from ietf-languages.  No 
other option makes sense; SIL and Linguist List and LoC probably won't 
register it, since it isn't a language, and it certainly isn't a variant 
of anything.

This whole discussion about registering subtags belongs on 
ietf-languages.

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 22 Jun 2008 20:01:56 -0700

That's why I haven't pushed it here, nor do I intend to, until we get
4646bis out the door.

Mark

On Sun, Jun 22, 2008 at 6:55 PM, Doug Ewell <[email-masked]> wrote:

> register it, since it isn't a language, and it certainly isn't a variant of
> anything.
>
> This whole discussion about registering subtags belongs on ietf-languages.
>
>
> --

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 22 Jun 2008 21:39:24 -0700

How about: do nothing. I-default is perfectly suited to its singular purpose. The relevant RFC won't be any different just because we deprecated it for something. Having exactly one non-deprecated grandfathered tag and having it be 'i-default' seems perfectly reasonable to me. John Cowan occasionally has in his footer a relevant quote:

--
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."
--

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Doug Ewell
> Sent: Sunday, June 22, 2008 6:55 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] ABNF for grandfathered/irregular
>