This is getting interesting but tricky. I think John's point...

"we don't know what the scope of actual practice will be.  For the first time we are extending language tagging to languages that either don't exist in written form at all, or are "written" by writing some closely related language.
This opens up a whole new set of hitherto unknown applications."

...was on target. I also concur with Mark's unease with "baking" in a certain approach, given the potential alternative needs. I would say "flexibility" here but that got me into trouble before.

Re Addison's explanations, replies in text...

> -----Original Message-----
> From: Addison Phillips [mailto:addison@yahoo-inc.com]
...
> 
> What we want are consistent choices for language tags.
> 
> One alternative would be to allow both "zh-cmn" and "cmn". Users would
> have to be careful to use these consistently in their content and range
> selection.

In effect cmn would "map" to zh? I wonder if the existence of the codes doesn't pretty much guarantee that some people will, for whatever reason, use the language code without attention to the macrolanguage code. One would have to consider this possibility and provide for it. Hence this seems to be a good idea.

> Another alternative would be to forget extlang altogether and permit
> *either* "zh" *or* "cmn" but not both in the same tag (except by
> grandfathering). This frees the extlang up for other, nefarious,
> purposes.

But presumably there is a relationship between zh and cmn? What about permitting all three options? This goes back to the ff examples. IOW one could tag the macrolanguage, or the language, or both. The latter two having the same function. 

For some languages at least, I wonder if removing the extlang relationship wouldn't lead to some confusion. On the other hand, if overlapping locales and the possibility of alternative tagging being used for essentially the same thing is not a problem, then maybe this could work.

> My surmise is that macro-languages are a one-time event: "discovery" of
> future macro-languages will mostly be prohibited by rule (since most of
> the languages will already have codes in the "primary" position when
> they become part of a macro-language collection). If my surmise is
> correct, we could ban future extlang additions and use the remainder of
> that namespace for (well) nefarious purposes.

Don't agree here. I think there are de facto macrolanguages out there without the title that may need new codes and the extlang relationships with other 639-3 or even 639-1/2 coded (sub)languages that those would imply (Runyakitara, Oshiwambo, and Beti are examples of possibilities, from my understanding of descriptions). At the very least, the door should not be closed.

It is a truism that language is changing, but for a number of languages there are factors (per John's comment) that are still not clear or are more "changeable" than the ones we have more experience with in ICT.

Don



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