Subject: [Ltru] Re: Principles of Operation

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 18:33:07 +0100

Peter Constable wrote on the language subtag review list:

> To veto 639-3 because of issues in 0.04% of the code table
> that had no bearing on the text of the standard and could
> have been corrected at any time would have been folly.

As soon as a 4646bis registry imported 639-3 wholesale later
corrections of the 4646bis registry are intentionally limited,
there's no way to "unregister" subtags after they're in.  Can
that happen in 639-3 ?

 Frank (jumping from "languages" to LTRU, it affects 4646bis)

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

---

From: John Cowan <[email-masked]>
Date: Fri, 25 Jan 2008 12:52:01 -0500

> there's no way to "unregister" subtags after they're in.  Can

639-3 code elements can be, and have been, retired for any of a variety
of reasons.  (However, they will not be reused.)

-- 
John Cowan  [email-masked]  http://ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"

---

From: Peter Constable <[email-masked]>
Date: Fri, 25 Jan 2008 10:24:28 -0800

> From: John Cowan

> of reasons.  (However, they will not be reused.)

Right. If something like Scanian were coded once, it would always remain coded; but in the process of maintaining 639-3 such a code could be deprecated on the basis (say) that it is determined to be best considered a dialect of another language rather than a separate individual language. Given the comprehensive scope of 639-3, such changes *are* going to happen because by definition its scope extends to the limits of knowledge and understanding of the world's languages.

Peter

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 20:37:59 +0100

Peter Constable wrote:

>> 639-3 code elements can be, and have been, retired for any of a
>> variety of reasons.  (However, they will not be reused.)

> Right. If something like Scanian were coded once, it would always
> remain coded; but in the process of maintaining 639-3 such a code
> could be deprecated on the basis (say) that it is determined to be
> best considered a dialect of another language rather than a separate
> individual language. Given the comprehensive scope of 639-3, such
> changes *are* going to happen because by definition its scope
> extends to the limits of knowledge and understanding of the world's
> languages.

Okay, "deprecate" is good enough.  But it could get tricky if it 
gets a Preferred-Value that is actually a variant.  Collisions of
variants with registered languages could cause havoc, example:

Language: foobar 
[...]
Language: err
[...]
Variant: foobar
Prefix: fr-CA
Prefix: fr-PM
[...]

Language "err" deprecated because it was found to be some dialect,
as it happens the dialect registered as "foobar", unrelated to the
language "foobar".  

AFAIK we can't have preferred values fr-CA-foobar AND fr-PM-foobar,
(please assume that this is important, it's only an example), and
what we really want is Preferred-Value: foobar as a pointer to the
variant, not the language.  Are we stuck in this case ?

 Frank