Subject: [Ltru] Re: New item in ISO 639-2 - Zaza

From: Frank Ellermann <[email-masked]>
Date: Fri, 25 Aug 2006 14:37:13 +0200

Addison Phillips wrote:

> one can match language tags "at a glance".
> I think that is a Good Thing.

Where that works, sure.  The hypothetical Ryukyu "rkn" was an
attempt to create a worst case.

> 1. Any ISO 639-3 code that is a "sublanguage" of an existing,
> non-deprecated language subtag (and preferably an
> acknowledged macrolanguage) is made an extlang.

> 2. All others are language subtags.
 
> 3. Once a language subtag, always a language subtag. Once an
> extlang, always an extlang.

+3 so far.
 
> 4. If a new macro-language code is introduced that would
> encompass existing codes, it is put into the registry as a
> deprecated language subtag.

That solves the hypothetical "rkn" mess.

>    zh-cmn  (right)
>    cmn     (wrong)
>    rkn     (right, deprecated)
>    ams     (right)
>    rkn-ams (wrong)

Good, I arrived at "rkn-ams (right, deprecated)", but "wrong"
is probably better.  At this point you've lost the info that
"ams" is related to "exa" based on a (deprecated) "rkn-exa".
On the other hand you've no zoo of deprecated synonyms.

The lost info could be kept as comment in "rkn", but comments
are not meant to be machine-readable meta-data.

> Another way of saying this is that a code is either a
> language subtag or an extlang at birth and this can never
> change.

Noted, I hope that makes it into the first draft.

> Incidentally, why are we discussing this here and not on the
> LTRU list?

Because nobody bothered to change the subject...  I don't like
to change the subject and the list simultaneously, it could
break threading where the references header field is lost.

Frank

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

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 25 Aug 2006 10:09:30 -0700

[moving to LTRU]

> From: John Cowan [mailto:[email-masked]]

> > our protocols. (Which is exactly the same thing I'd say wrt the
639-1
> > "freeze": we don't need any guarantees from the JAC about new
alpha-2
> > IDs; we can simply decide that we will not allow use any new alpha-2
> > IDs from this point forward.)
> 
> At the moment, we have no such option: if the various RAs and MAs add
> a new code element, we MUST add it to the registry.  The most we can
> do is deprecate it on the spot.
> 
> If we want to add the option to reject (and I'd be nervous about it --
> this list could in future be captured by Not Invented Here bigots),
> we need to add it to 3066ter.

I suggested it for 3066bis, but either most weren't interested or the
focus was on other issues at the time.

Peter Constable