Subject: [Ltru] Re: 3066ter encompassed languages

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 22:58:07 -0700

Peter Constable <petercon at microsoft dot com> wrote:

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

I like this, but can we go one step further for consistency, and 
actually *remove* the existing inverted forms for any subtags that also 
have the non-inverted form?

Type: language
Subtag: nd
Description: Ndebele, North     <-- remove
Description: North Ndebele
Added: 2005-10-16
Suppress-Script: Latn

Type: language
Subtag: nds
Description: Low German
Description: Low Saxon
Description: German, Low     <-- remove
Description: Saxon, Low     <-- remove
Added: 2005-10-16

I don't see anything in Section 3.4 that prohibits this.  Note that I 
don't propose "un-inverting" any descriptions when the inverted form is 
all we have:

Type: language
Subtag: fro
Description: French, Old (842-ca. 1400)     <-- no change
Added: 2005-10-16

>> Scenario:  We have "Marshallese" and 639-3 changes this to "Marshall" 
>> for no immediately obvious reason.  I assume we add it; first or 
>> last?
>
> I believe work is being done to fix such minor inconsistencies.

I know the answer to this already, but it would be nice to know what 
things like this (and "zza" as macrolanguage) will be changed before the 
final release of 639-3.  We can always plan as if there will be no 
surprises, and react to those that occur.

>> 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
>
> Indeed, order doesn't matter.

Pretty much everyone seems to agree here.

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

Agreed.  For 4646bis this means we do nothing for "sgn-BE-fr" and 
"sgn-BE-nl".  John observed that "sgn-CH-de" can be replaced by 
"sgn-sgg".

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  •  UTN #14

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

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Sep 2006 23:02:30 -0700

Peter Constable <petercon at microsoft dot com> wrote:

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

I do find it useful to know, as in this example, how many conflicts 
there would be if today's draft code table were made final.  It gives me 
a good sense of whether there are 5, 50, or 500.  We do need to keep in 
mind that the exact numbers are subject to change.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Sep 2006 11:47:58 +0200

Doug Ewell wrote:

>> The inverted forms are useful only when providing a sorted
>> list for human-eader lookup, and that is not relevant for
>> the description fields.

> I like this

I don't, if I look for say SASL on the IANA page it makes me
nervous when it doesn't show up under SA or "se"(curity) -
until I finally find it under "si"(mple).

Convert registry to table and then sort by description (or by
type + description) is a good idea.  Why destroy it ?

> Description: German, Low     <-- remove

If somebody looking for "German" in a sorted table immediately
sees that there's also "German, Low" it's good.  For "Ndebele"
and "Ndebele, North" it's probably similar.

> I don't propose "un-inverting" any descriptions when the
> inverted form is all we have:

> Description: French, Old (842-ca. 1400)     <-- no change

That would be a mess, sometimes 639-2 style survives, in other
cases it's replaced by another (I say worse) style.  Stick to
639-2 for primary tags derived from 639-2.

John said that the 639-3 descriptions are more up to date in
some cases.  IMO 639-2 should then adopt it, better apostrophes
and all, it's not the job of the IANA registry to second-guess
its sources (outside of comments).

Frank

---

From: "Debbie Garside" <[email-masked]>
Date: Sat, 9 Sep 2006 11:58:57 +0100

I disagree with this and reiterate my position as stated within the "holy
apostrophe debate" on IETF-languages:

"all names as represented within the underlying standards should be included
in the registry in the EXACT format that they take within the standard.
This means that if a name is presented as Foo (Bar) in the underlying
standard then it remains as Foo (Bar).  Three reasons for this, one:
consistency, two: very often the bracketed information acts as an additional
qualifier, three: the name can be used by other systems as a Unique
Identifier (ISO 11179)."

I would further add that human readability should be taken into
consideration as should sort order. Thus, in the example given, "Ndebele,
North" should be retained.

If there is a discrepancy between the descriptions of ISO 639-2 and ISO
639-3 then BOTH should be included IMHO.

Best regards

Debbie 

> -----Original Message-----
> From: Doug Ewell [mailto:[email-masked]] 
> Sent: 09 September 2006 06:58
> To: LTRU Working Group
> Subject: [Ltru] Re: 3066ter encompassed languages
> 
> I like this, but can we go one step further for consistency, 
> and actually *remove* the existing inverted forms for any 
> subtags that also have the non-inverted form?
> 
> Type: language
> Subtag: nd
> I don't see anything in Section 3.4 that prohibits this.  
> Note that I don't propose "un-inverting" any descriptions 
> when the inverted form is all we have:
> 
> Type: language
> Subtag: fro
> I know the answer to this already, but it would be nice to 
> know what things like this (and "zza" as macrolanguage) will 
> be changed before the final release of 639-3.  We can always 
> plan as if there will be no surprises, and react to those that occur.
> 
> Agreed.  For 4646bis this means we do nothing for "sgn-BE-fr" 
> and "sgn-BE-nl".  John observed that "sgn-CH-de" can be 
> replaced by "sgn-sgg".
> 
> --
> Doug Ewell
> RFC 4645  .  UTN #14

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 9 Sep 2006 16:36:02 -0700

Hi -

> From: "Debbie Garside" <[email-masked]>
> To: "'Doug Ewell'" <[email-masked]>; "'LTRU Working Group'" <[email-masked]>
> Sent: Saturday, September 09, 2006 3:58 AM
> Subject: RE: [Ltru] Re: 3066ter encompassed languages
>

> 639-3 then BOTH should be included IMHO.
...

As a technical contributor, and in the context of the work of the ltru WG,
I agree whole-heartedly.  Anything other than what can be extracted
algorithmicly from the base standards should be debated on a case-by-case
basis on the [email-masked] list.

Our work here is not to "improve" upon the raw data.  It is to ensure that
the registry format and procedures support the needs of language tagging,
and, incidentally, to supply "mass initialization" data *derived* from those
base standards.  We aren't here to editorialize or improve on that data.
That's a problem for the [email-masked] list.

Randy

---

From: Peter Constable <[email-masked]>
Date: Sat, 9 Sep 2006 21:57:46 -0700

List-UnsuAC decides to treat msa as identical to mly resulting in the
separate entry mly being deleted, then there is no longer an issue with
two entries having otherwise identical reference names.

- If the JAC decides to treat msa as a macrolanguage, then there is
still opportunity for the reference names to be revised, and the problem
might perhaps be avoidable (e.g. by using "Standard Malay" or "Bahasa
Malay" for mly).

> But the IANA LSTR will not the same as 639-3 (for language codes).
> The IANA LSTR will, for stability reasons, continue to contain
> "collective" codes. We could either:
>
> 1) deprecate them ("collective" codes) all and for each of them refer
to
> individual language codes (from 639-3 but not in 639-2), or

I've always been in favour of deprecating collective IDs from use in
IETF language tags. 

> 2) leave them as additional "macrolanguages", giving individual
language
> codes (from 639-3, not any in 639-2) as "extlangs" for each.

Absolutely not!

> Either way, we would need an authoritative list of the individual
> language
> codes each of them *currently* cover (not to be updated in future
> versions,
> for stability, even if would leave the lists as outdated).

That was not done as part of 639-3 because it was out of scope; it might
be in scope for 639-5, however. In the early work on 639-3, when Gary
Simons and I were preparing proposals for ISO, we did our initial
analysis of the relationship between ISO 639-2 and Ethnologue 14th
edition. That included mappings from collections in 639-2 to individual
languages, and that is available here:

http://www.ethnologue.com/14/iso639/analysis.asp#C

> I don't think it would be a good idea to leave them as is. I would
> prefer
> alternative 1 above, but some of them may have been used (despite that
> being a bad idea), in which case alternative 2 may be better.

I think alternative 2 is worse than any existing use of a collective ID.

Peter Constable

---

From: Peter Constable <[email-masked]>
Date: Sat, 9 Sep 2006 21:57:46 -0700

From: Randy Presuhn [mailto:[email-masked]] 

> basis on the [email-masked] list.

IMO, you might just as appropriately have said this in your role as a WG
chair: you're clarifying what is in scope for this WG versus what is in
scope for the ietf-languages list. Probably some of us that participate
in both forget the distinction; I'm sure I do at times.

Peter Constable

bscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

From: Randy Presuhn [mailto:[email-masked]] 

> basis on the [email-masked] list.

IMO, you might just as appropriately have said this in your role as a WG
chair: you're clarifying what is in scope for this WG versus what is in
scope for the ietf-languages list. Probably some of us that participate
in both forget the distinction; I'm sure I do at times.

Peter Constable

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Sep 2006 19:19:38 +0200

>> From: "Debbie Garside" <[email-masked]>
[...]
>> If there is a discrepancy between the descriptions of ISO
>> 639-2 and ISO 639-3 then BOTH should be included IMHO.
[...]
> I agree whole-heartedly.  Anything other than what can be
> extracted algorithmicly from the base standards should be
> debated on a case-by-case basis on the
> [email-masked] list.

+1  And as far as I'm concerned if the sources aren't in an
ideal state the review list should be limited to comments
in the registry, and otherwise accept what it gets.

Apparently there's one minor detail here, Debbie proposes to
take both decriptions if they're different.  My idea was to
stick to (only) 639-2 for any languages it cares to list.

Debbie's plan is probably better, merge the descriptions if
they are different.  If that results in "Church, slavic" +
"Slavic, church" the registry and readers will survive it -
for about 16 conflicts it's no issue, and Peter said that
some discrepancies will be worked out in 639-3.

> We aren't here to editorialize or improve on that data.

+1

> That's a problem for the [email-masked] list.

The "description" shouldn't be their territory, it should be
fixed in the sources.  For 4646bis I'd like a statement that
we expect all primary and extlang tags to use a unique
namespace (apparent "dupes" limited to grandfathered tags).

But we cannot guarantee that there's only one non-deprecated
subtag for a given (primary or extlang) description.  With
an example if it exists, maybe "Malay".

Frank