Subject: [Ltru] Re: 3066ter encompassed languages

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 06:33:52 -0700

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

>> the due dates for first drafts were *NOT* extended as I requested, we 
>> have only 21 days to put together some 3066ter documents.
>
> Don't take these dates *too* serious, no angry ADs asking Randy and 
> Martin why LTRU is out of line if that takes a few weeks longer - but 
> admittedly I was ashamed when I stumbled over an IESG narrative report 
> with a DISCUSS for an ABNF issue in the matching draft.  Let's please 
> get the ABNF right in 3066ter before Last Call.  (If we touch the ABNF 
> at all, unlikely)

I hope we don't touch it.  We went to some lengths to build a syntax 
that would also work for 3066ter.

> Yes.  Don't touch anything in the existing registry unless it is 
> grandfathered or a variant.  Downgrading language tags to extlang-s is 
> out.

OK, I think we at least have that one worked out.

>> 1.  what to do about the Description fields when the 639-2 and 639-3 
>> descriptions don't match exactly
>
> Keep as is, 639-2 as primary source, 639-3 as supplemental.

Scenario:  We have "Church Slavic" plus 4 other variants.  639-3 adds an 
inverted form, "Slavic, Church".  I assume we add it; first or last?

Scenario:  We have "Malay".  639-3 changes this to "Malay (specific)" 
because there is also "Malay (specific)" plus a host of others such as 
"Malay, Ambonese".  I assume we REPLACE the existing description with 
the one from 639-3.

Scenario:  We have "Ainu".  639-3 changes this to "Ainu (Japan)" to 
differentiate it from the unrelated "Ainu (China)".  Same outcome as 
above, plus we should probably point out in the registry update draft 
that these parenthesized country names are there to disambiguate 
colliding language names and not to take the place of region subtags.

Scenario:  We have "Marshallese" and 639-3 changes this to "Marshall" 
for no immediately obvious reason.  I assume we add it; first or last?

Scenario:  We have "Luxembourgish" followed by "Letzeburgesch".  639-3 
reverses the order.  I know many have said order doesn't matter, and I 
suspect we will do nothing here

In my private testing I've put the new 639-3 descriptions first and 
changed ordering to favor 639-3 (making the more comprehensive 639-3 the 
primary source and 639-2 supplemental).  Doing it Frank's way results in 
fewer gratuitous changes to ordering, but sometimes ("Malay") it is 
fairly clear we need to replace the existing string.

>> 2.  what to do about sign languages
>
> Would a decree that sgn is a pseudo-macrolanguage help ?  IIRC there's 
> no chance that sgn will ever be used for something else

It's our "decree," our decision to make.  That's what I'm asking for. 
We also need to decree that "sgn-US" et al. will be deprecated in favor 
of "sgn-ase" et al., or provide an alternative.  And we may need to 
decide what to do about "sgn-BE-fr" and other sign languages that 
Michael mentions on his page but that aren't in 639-3.

>> 3.  which grandfathered tags to deprecate in favor of new 639-3-based 
>> subtags
>
> Same procedure as for grandfathered tags replaced by 639-2 tags

john suggested deprecating "i-enochian" and "i-mingo" but didn't have 
anything to replace them with.  We probably shouldn't deprecate tags for 
"real" languages (cf. "zh-min") unless we provide a better way to tag 
them.  And he suggested deprecating "i-tao" (Tao) with "tao" (Yami) and 
"i-tay" (Tayal) with "tal" (Tal), which weren't at all obvious to me.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
Editor, draft-ietf-ltru-initial 

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 16:27:17 +0200

Doug Ewell wrote:

>> (If we touch the ABNF at all, unlikely)
> I hope we don't touch it.  We went to some lengths to build a
> syntax that would also work for 3066ter.

I'd make an exception if <extlang> turns out to be unnecessary.
 
> Scenario:  We have "Church Slavic" plus 4 other variants.
> 639-3 adds an inverted form, "Slavic, Church".  I assume we
> add it; first or last?

The source for Church Slavic was 639-2.  I'd stick to it as is
in the registry, don't add it.

> Scenario:  We have "Malay".  639-3 changes this to "Malay
> (specific)" because there is also "Malay (specific)" plus a
> host of others such as "Malay, Ambonese".

If we can also get away with keeping the 639-2 Malay as is...
adding a comment with the more specific name is an option.

For the future (not the initial bulk update) the review list
could figure out what's best.  E.g. add it if really needed.

For the bulk update:  How many conflicts are there ? 

> I assume we REPLACE the existing description with the one
> from 639-3.

I don't like that, so far the description always mirrors the
source.  "No creative corrections of dubious apostrophes" was
an example.

> Scenario:  We have "Ainu".  639-3 changes this to "Ainu
> (Japan)" to differentiate it from the unrelated "Ainu
> (China)".  Same outcome as above

Yes, 639-3 shouldn't change 639-2 indirectly via the registry.

> we should probably point out in the registry update draft
> that these parenthesized country names are there to
> disambiguate colliding language names and not to take the
> place of region subtags.

ACK.
 
> We have "Marshallese" and 639-3 changes this to "Marshall"
> for no immediately obvious reason.

639-2 was the primary source, keep as is.

> Scenario:  We have "Luxembourgish" followed by
> "Letzeburgesch".  639-3 reverses the order.

Keep as is.  639-3 is supplemental, not an override.

> We also need to decree that "sgn-US" et al. will be
> deprecated in favor of "sgn-ase" et al.

I hope these cases are obvious for you or somebody else here,
they're not for me.  

> john suggested deprecating "i-enochian" and "i-mingo" but
> didn't have anything to replace them with.

Dubious idea under 4646-rules, there's some MUSTard saying that
"Preferred-Value" can't be added after deprecation.  I see no
compelling reason to change that rule.

> he suggested deprecating "i-tao" (Tao) with "tao" (Yami) and

Also not for me, but if we find a somewhat reliable source to
justify this it's okay.  That's how we got Suppress-Scripts, I
expected interesting debates and reviews in the Last Call, but
unfortunately nothing happened.

For a first impression (and draft) you can take any consistent
rules, we then look in the output, especially into all changes
wrt existing tags, and if it's dubious tune the rules until the
output passes giggle tests (not the "Church, Slavic" example).

Frank

---

From: Peter Constable <[email-masked]>
Date: Fri, 8 Sep 2006 08:23:39 -0700

> From: Doug Ewell [mailto:[email-masked]]

> inverted form, "Slavic, Church".  I assume we add it; first or last?

Perhaps we have a working convention that we only use non-inverted name
forms in the Description field. The inverted forms are useful only when
providing a sorted list for human-eader lookup, and that is not relevant
for the description fields.

> for no immediately obvious reason.  I assume we add it; first or last?

I believe work is being done to fix such minor inconsistencies.

> suspect we will do nothing here

Indeed, order doesn't matter.

> It's our "decree," our decision to make.  That's what I'm asking for.

+1

> of "sgn-ase" et al., 

+1

> or provide an alternative. 

-1

> And we may need to

Someone should prepare proposals to get them added to 639-3; in the mean
time, those tags remain grandfathered until such time as there is a
syntax-conformant tag that can supersede it.

> "real" languages (cf. "zh-min") 

zh-min isn't an individual language; it's a putative genetic sub-family
of Chinese. We should deprecate that.

Peter Constable

---

From: Peter Constable <[email-masked]>
Date: Fri, 8 Sep 2006 08:27:14 -0700

> From: Frank Ellermann [mailto:[email-masked]]

> For the bulk update:  How many conflicts are there ?

A final answer cannot be provided until the final draft of the code
table for 639-3 is completed. There are still some issues for the JAC to
review.

Peter Constable

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Sep 2006 16:53:06 -0400

Peter Constable scripsit:

+1 to omitting inverted names, order doesn't matter, sgn is treated as
a macrolanguage, sgn-XX deprecated.

> syntax-conformant tag that can supersede it.

Ethnologue thinks the difference between sgn-BE-fr and sgn-BE-nl is
dialectal.  This needs to be hashed out at the 639-3/RA when it is
functional.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       [email-masked]
you'd get cooks very confused.          --RMS

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Sep 2006 17:06:34 -0400

> "i-tay" (Tayal) with "tal" (Tal), which weren't at all obvious to me.

Enochian is a conlang and needs to be processed through Linguist List,
the sub-registrar for conlangs, in order to get incorporated into 639-3
at a later stage.  Until then, i-enochian stays.

Mingo is either a dialect of Seneca or a separate language, depending on
how distinct its orthography is.  It's mutually intelligible with Seneca,
by direct report.  The experts haven't yet weighed in.  In any case,
we keep i-mingo for now and then either register 'mingo' as a variant
subtag with prefix 'see', or else 639-3 registers a new tag.

zh-min should just be deprecated: it's a bogus macrolanguage.

http://www.ethnologue.com/show_language.asp?code=tao says that Tao is
an alternative (and locally preferred) name for Yami.  I assume Peter
changed the code to "tao" to agree with i-tao.

"tal" was a typo on my part: should have been "tay"; so deprecate "i-tay"
in favor of "tay".  Tayal is a listed alternate name at Ethnologue.

-- 
As you read this, I don't want you to feel      John Cowan
sorry for me, because, I believe everyone       [email-masked]
will die someday.                               http://www.ccil.org/~cowan
        --From a Nigerian-type scam spam

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Sep 2006 17:15:59 -0400

> host of others such as "Malay, Ambonese".

In fact it does not.  639-1 "ms" / 639-2 "msa" maps to 639-3's "Malay
(generic)", the macrolanguage.  The 639-3 "mly" maps to the language
called "Malay (specific)"; that is, the individual language encompassed by
"ms" that is also confusingly called "Malay".

-- 
A witness cannot give evidence of his           John Cowan
age unless he can remember being born.          [email-masked]
  --Judge Blagden                               http://www.ccil.org/~cowan

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 21:33:04 -0700

John Cowan <cowan at ccil dot org> wrote:

> the sub-registrar for conlangs, in order to get incorporated into 
> 639-3 at a later stage.  Until then, i-enochian stays.
>
> Mingo is either a dialect of Seneca or a separate language, depending 
> on how distinct its orthography is.  It's mutually intelligible with 
> Seneca, by direct report.  The experts haven't yet weighed in.  In any 
> case, we keep i-mingo for now and then either register 'mingo' as a 
> variant subtag with prefix 'see', or else 639-3 registers a new tag.

In your message of August 29 (msg05281) you had labeled both of these 
"Deprecated in 3066ter" but with a Preferred-Value of "not known."  I 
prefer this more conservative approach.

> zh-min should just be deprecated: it's a bogus macrolanguage.

Agreed.  "cf." was meant to convey that: "real languages, as opposed to 
zh-min."

> "tal" was a typo on my part: should have been "tay"; so deprecate 
> "i-tay" in favor of "tay".  Tayal is a listed alternate name at 
> Ethnologue.

Thanks for doing the research on both of those.

RFC 4645  ·  UTN #14

---

From: John Cowan <[email-masked]>
Date: Sat, 9 Sep 2006 01:10:52 -0400

> prefer this more conservative approach.

So do I, now that I have the facts.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
Economists were put on this planet to make astrologers look good.
        --Leo McGarry