Subject: [Ltru] Re: Description field ordering

From: "Doug Ewell" <[email-masked]>
Date: Sat, 16 Dec 2006 23:09:02 -0800

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

> Because "backwards incompatible" is the mother of all
> ugliness.  You offer no concept what a "reference name"
> might be for all other subtags, it's only well-defined
> for language subtags derived from 639-3.
> 
> A 4646bis going to a Last Call as "we added the 639-3
> languages as promised" will pass with zero complications.
> 
> For a 4646bis going to Last Call as "while we were at it
> we screwed with the 4646 syntax, update all your tools
> implemented for 4646" I'd cry foul.

+1 in toto.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
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: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Dec 2006 14:45:53 -0800

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

>> Option U:
>> For names that exist in both forms, use only the uninverted form.
>
>> Option I:
>> For names that exist in both forms, use only the inverted form.
>
> If that gives me "Frisian, Western" it's acceptable.
>
>> Option B:
>> Use both inverted and uninverted forms.
>
> Also acceptable.  Apparently I prefer "not only U" :-)

So far, most other respondents have come out in favor of Option U, the 
uninverted names.

In the interests of consensus-building... what is it about the inverted 
names that you prefer?  Is it the effect on alphabetical sorting (so all 
the Zapotecs sort together), or the fact that older ISO 639-3 files used 
inverted names as the reference name (they don't any more), or something 
else?

Note that John Cowan was originally in favor of inverted names, until 
Peter pointed out that they don't necessarily indicate the One True Way 
of inverting the name (remember "Slavonic, Old Church" versus "Church 
Slavonic, Old").  Thus any multi-word uninverted name could be inverted 
mechanically to achieve similar results, with no need to store the 
inverted forms in the Registry.

I have no interest in saying, "Well, it's 4 to 1, you lose," but I'd 
like to see what can be done so everyone is at least satisfied with the 
outcome ("overjoyed" is asking too much).

---

From: Addison Phillips <[email-masked]>
Date: Mon, 18 Dec 2006 16:27:29 -0800

> So far, most other respondents have come out in favor of Option U, the

I'm currently in favor of replicating any and all items that ISO 639 
has, with the only rectifications being spacing, punctuation, and 
capitalization.

 > like to see what can be done so everyone is at least satisfied with
 > the outcome ("overjoyed" is asking too much).

I don't see how it is in the interest of the registry and registration 
process to engage in a great deal of ad hoc editing. Obvious 
corrections, okay. Fixing apostrophes, meh, maybe. But really making 
changes, additions, and emendations to ISO 639's text should be done via 
the registration process: we provide a means to do that, even.

Now that we're adding text that says the first Description is also the 
Reference Name from ISO 639-3 for language and extlang subtags, I'm even 
more opposed to inverting OR uninverting the names. I think it bad form 
to say "this is copied from this particular field" and then say "but 
we've changed it somehow... maybe".

Thus, I give you "Option N": remove the duplicate removal within a 
record. Present whatever the source standard has (all forms).

The only caveat on Option N is that we remove *exact* duplicates 
*between* records. In that case, we presume that no two languages share 
a Reference Name. That name is guaranteed to be there, whatever form it 
takes.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Dec 2006 17:45:19 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

> Reference Name from ISO 639-3 for language and extlang subtags, I'm 
> even more opposed to inverting OR uninverting the names. I think it 
> bad form to say "this is copied from this particular field" and then 
> say "but we've changed it somehow... maybe".

and later:

> The following are issues currently under discussion, but the editors 
> are not in receipt of text or do not perceive consensus on including 
> text to address them:
>
> 1. Inversion or uninversion of Description fields.
> 2. Addition of a new field for Reference-Names (vs. various 
> permutations of Description handling).

As this explains, Section 3.1.4 of the draft just submitted still says:

> Moreover, formatting variations of the same description MUST NOT occur 
> in that specific record or in any other record of the same type. For 
> example, while the ISO 639-1 code 'fy' contains both the descriptions 
> "Western Frisian" and "Frisian, Western", only one of these 
> descriptions appears in the registry.

So I'm basically back at square one, with no rough consensus as to which 
names will appear in the Registry.  The Survey is off and I will wait 
for further instructions.

---

From: Addison Phillips <[email-masked]>
Date: Mon, 18 Dec 2006 21:07:38 -0800

> for further instructions.

The survey can go on. What's happening here is that I'm trying to keep 
the drafts under control. The I-D editors are fast about posting updated 
drafts and burning a few more integers isn't that costly. I do want to 
try and get into a rhythm of submitting text relatively quickly. It gets 
annoying to constantly remind folks that the Editor's Copy has what they 
want (or don't want, as the case may be).

I considered removing the offending text in 3.1.4 (de novo in draft-00), 
but there isn't consensus for that at present either. I think we're very 
close to a consensus, but don't want to hold back drafts indefinitely to 
achieve it.

Besides, didn't you say you'd do whatever draft-03 said? :-)

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 18 Dec 2006 23:04:17 -0800

> Besides, didn't you say you'd do whatever draft-03 said? :-)

Yep.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Dec 2006 22:21:53 +0100

Doug Ewell wrote:

> the Zapotecs sort together)

Yes.

E.g. "fy" used to be "Frisian", now it's "Frisian, Western", and in a
list of alphabetically sorted descriptions it's shown near "Frisian,
Northern".

Frank

P.S. to Mark:  While RFC 4646 doesn't allow to narrow subtags, the
source standards are still free to do whatever they wish, and the
registry is forced to play along (for an unmodified code).  We could
also pretend that "fy" always was "Western", and its description was
incomplete, but that's cheating.

---

From: John Cowan <[email-masked]>
Date: Tue, 19 Dec 2006 16:44:16 -0500

> incomplete, but that's cheating.

I suspect that in practice "fy" was almost always applied to Western Frisian,
and the change was a clarification rather than a true change in denotation.

-- 
John Cowan   http://ccil.org/~cowan    [email-masked]
We want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures.  --Samuel Gompers

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 19 Dec 2006 13:51:35 -0800

Actually, a good part of what we did with 4646 was to insulate ourselves
from instabilities in ISO. Now, we may just decide that we just don't care
about stability regarding non-modern language variants. But if we do so, we
should at least make that a conscious decision to do it, and document it so
that people know what to expect of BCP 47 regarding stability.

Part of what I was asking Peter (and still hoping for an answer) is to see
what policy ISO has regarding these codes, so that we can better determine
what to do (and say).

Mark

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Dec 2006 20:36:34 +0100

Mark Davis wrote:
 
> a good part of what we did with 4646 was to insulate ourselves from
> instabilities in ISO.

Yes, but mainly for the region codes.  For languages we quote an old
(= already stated in 3066) promise by ISO.  For 639-3 Peter said it
will follow the same rules, and Randy didn't like the idea of some
official "liaison" to renew that promise (officially covering 639-3).

For scripts I'm not aware of any promise, but there was no problem
in the past.  For extensions and variants 4646 guarantees stability.

> we may just decide that we just don't care about stability regarding
> non-modern language variants.

I wouldn't like that.  It's just that we can't do much in such cases,
"let the language list decide about the validity of new descriptions"
doesn't sound like a good idea.

> Part of what I was asking Peter (and still hoping for an answer) is
> to see what policy ISO has regarding these codes, so that we can
> better determine what to do (and say).

That's the old liaison discussion, or do you have an idea how to get
a similar effect without this bureaucratic overhead ?  I'd guess that
making or getting binding promises on behalf of ISO is as difficult as
making or getting binding promises on behalf of the IETF.

Maybe it's a part of the future 639-3 rules, that would be nice, we
could simply quote the relevant statement in 4646bis.  Then only the
script codes could get messed up (e.g. limit Latn to Mes-1, and add a
new "Lata" for "Latin all", that would be bad for our 4646 stability)

Frank