Subject: [Ltru] Re: Principles of Operation

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Jan 2008 11:22:56 -0800

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> 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 ?

A Preferred-Value is a whole tag, not a subtag, so no, it is not 
possible for a variant subtag alone to serve as a P-V.

Frank is correct that a subtag can't have two or more P-Vs.  I would be 
surprised if this absolutely could not be generalized to "fr-foobar". 
Scouse is rather specifically a variant of en-GB, and Boontling is 
rather specifically a variant of en-US, but both of those variants have 
simply "en" as their P-V.  More detail would be possible, but not 
necessary.

Registered language subtags are one of the two items this group and 
ietf-languages seem rather strongly opposed to (the other being 
extensions), to the point where none might ever be created.  If that is 
true, this scenario will not occur anyway.

I think the real underlying question here is, "Will ietf-languages be 
careful to avoid painting themselves into corners like this?" and all I 
can say is, we will do our best.

--
Doug Ewell  *  Fullerton, California, 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://www1.ietf.org/mailman/listinfo/ltru

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 27 Jan 2008 13:15:03 +0100

Doug Ewell wrote:

> A Preferred-Value is a whole tag, not a subtag, so no, it is
> not possible for a variant subtag alone to serve as a P-V.

Check the registry, there are quite a lot of Preferred-Values
which are only subtags, starting with BU -> MM and DD -> DE.

For languages "tag" and "subtag" are syntactically equivalent.
There are only two Preferred-Values zh-hakka and zh-cmn which
are clearly tags.

| Preferred-Value
| *  For fields of type 'language', 'extlang', 'script', 'region',
|    and 'variant', 'Preferred-Value' contains the subtag of the
|    same 'Type' that is preferred for forming the language tag.
| *  For fields of type 'grandfathered' and 'redundant', a canonical
|    mapping to a complete language tag.

At the moment we could not deprecate language "err" in favour 
of a variant subtag "foobar" or a tag "fr-foobar".  And that
can happen for ``language´´ Europanto "eur" found by Michael:
http://www.ethnologue.com/show_language.asp?code=eur

 Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 31 Jan 2008 10:51:19 -0500

Frank Ellermann scripsit:

> of a variant subtag "foobar" or a tag "fr-foobar".  

No, we can't, but that's not a serious use case.  If ISO 639
decides to merge two languages, we aren't going to follow;
we'll just add the new merged code, and keep the two codes
they retire.

-- 
John Cowan    http://www.ccil.org/~cowan   <[email-masked]>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

---

From: "Kent Karlsson" <[email-masked]>
Date: Thu, 31 Jan 2008 19:28:05 +0100

> we'll just add the new merged code, and keep the two codes

They surely must be kept (if they ever got in to begin with),
but I do hope that, by 639-3 RA, codes that become "retired"
are "automatically" deprecated in LSR. I'm not sure if any new
text in 4646bis is needed to say that more explicitly.

If a 639-3 code is "retired" already before 4645bis is submitted
in final form, it should not be part of 4645bis. I understand
that current drafts are constructed without already retired
"new" codes.

	/kent k

---

From: John Cowan <[email-masked]>
Date: Thu, 31 Jan 2008 13:41:45 -0500

Kent Karlsson scripsit:

> are "automatically" deprecated in LSR. 

Yes, indeed.  However, in the case of a split there can be
no preferred alternative; in the case of a merge there can.

> that current drafts are constructed without already retired

Correct.

-- 
[W]hen I wrote it I was more than a little              John Cowan
febrile with foodpoisoning from an antique carrot       [email-masked]
that I foolishly ate out of an illjudged faith          http://ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta