Subject: [Ltru] More about Description fields

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 Dec 2006 00:31:39 -0800

Two more points about draft-4646bis-00 and the issue of Description 
fields taken from source standards, specifically ISO 639-3.

First, despite all we have heard on this list (and ietf-languages) about 
how the Description field(s) need to match the source standards more or 
less precisely, for various reasons, the draft still speaks in terms of 
flexibility.  Section 3.1.4 talks about editing the names, correcting 
"problematic" descriptions, regularizing irregularities (more on that 
later), and descriptions only indicating the meaning and not being 
normative.

At this point I almost don't care whether we fall on the side of 
flexibility or rigidity, but there is an obvious schism here that needs 
to be resolved one way or the other.  We will just be spinning our 
wheels if each side continues to argue its own point of view without 
looking at the other side.

Second, the section on fixing "problematic" descriptions refers 
specifically to "parenthetical comments."  I'm wondering just what is 
supposed to be wrong about them that needs fixing.  There are several 
different types of parenthetical comments in ISO 639:

1.  "(generic)" and "(specific)" indicating, respectively, a 
macrolanguage and encompassed language with the same name.  These apply 
to Dogri, Konkani, Malay, and Swahili, and additionally there is a 
language called "Zande (specific)".  These might not be necessary, since 
they would be different types of subtag.

2.  "(Other)" indicating a collection code from 639-2 (others are 
indicated by the word "languages").  These are indispensable IMHO, if we 
want to discourage use of collection-code subtags.

3.  Country or region identifiers, such as "Ainu (Japan)" or "Gimi 
(Eastern Highlands)".  These simply cannot be removed, since they 
disambiguate two languages with otherwise-identical names.

4.  Approximate dates of historic languages, such as "Old English (ca. 
450-1100)".  These might be useful to ordinary folks like me.  Eminent 
scholars probably already know the time frames.

5.  General additional information, such as "Gaelic (Scots)" or "Slave 
(Athapascan)" or my favorite, "Interlingua (International Auxiliary 
Language Association)".  If it's really necessary, these can probably be 
removed without destroying the meaning,

I need to know what the intent was of this passage in Section 3.1.4 
before implementing it in 4645bis.  And, of course, there's the 
inverted-names bit.

--
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: John Cowan <[email-masked]>
Date: Tue, 12 Dec 2006 10:59:31 -0500

> want to discourage use of collection-code subtags.

I no longer think we do, particularly.

> disambiguate two languages with otherwise-identical names.

I think it's worth noting that the overwhelming majority of parenthetical
bits in 639-3 are of this type.

> removed without destroying the meaning,

These actually fall under the same rule as "Ainu (Japan)".  There really
are two constructed languages called "Interlingua", namely "Interlingua
de IALA" (this one) and "Interlingua de Peano", also known as "Latine
Sine Flexione".  Adding "(Scots)" to "Gaelic" clarifies that it is not
Irish, which has frequently been called "Gaelic" in the past.  I'm not
sure what the story is with "Slave (Athapascan)": perhaps it is meant
to eliminate confusion with any languages or supposed languages of
slaves or former slaves.  The name of the language is pronounced with
two syllables, and is usually spelled "Slavey" these days, precisely to
prevent such confusion.

To go on, "Egyptian (Ancient)" eliminates confusion with Egyptian
Arabic and Coptic; and "Ligurian (Ancient)" eliminates confusion with
the unrelated current language Ligurian, a Romance language of the
Gallo-Romance group.

-- 
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: [email-masked]
Date: Tue, 12 Dec 2006 14:25:20 -0800

For the record, I was previously reprimanded for suggesting the use of 
"Gaelic (Scots)" because of its potential to confuse the user with the 
Scots language. I agreed. In my local applications, I'm now using "Gaelic 
(Scottish)."

FWIW,

Karen Broome

John Cowan <[email-masked]> 
12/12/2006 07:59 AM

To
Doug Ewell <[email-masked]>
cc
LTRU Working Group <[email-masked]>
Subject
Re: [Ltru] More about Description fields

-- 
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: Addison Phillips <[email-masked]>
Date: Tue, 12 Dec 2006 16:59:28 -0800

> fields taken from source standards, specifically ISO 639-3.

I think you mean draft-01

> later), and descriptions only indicating the meaning and not being 

That text was added back in August or September in response to a 
particular thread.

Very carefully I didn't define "problematic". The text about 
non-normativeness is from 4646. The idea here (more below) is that we 
have a way to edit anything bizarre without requiring a new RFC or other 
magic.

> different types of parenthetical comments in ISO 639:

I believe this was the thrust of Ye Olde Thread. Based on your note 
below and the various arguments on this list since that time, I think we 
should modify that paragraph from saying:

--
When creating a new registry entry, duplicate, redundant, conflicting, 
or otherwise problematic descriptions MUST either be corrected or 
omitted. Parenthetical comments, inverted names, and other 
irregularities SHOULD be regularized according to the guidelines used to 
update the registry in [registry-update].
--

to say instead:

--
When creating a new registry entry, duplicate, redundant, conflicting, 
or otherwise problematic descriptions MUST either be corrected or 
omitted. Any irregularities SHOULD be regularized according to the 
guidelines used to update the registry in [registry-update].
--

> before implementing it in 4645bis.  And, of course, there's the 

I think the problem here is: either we allow editing or we don't.

If we do NOT, that implies that:

  - we introduce text banning the addition or modification of 
descriptions except by action of the source standards
  - we copy the descriptions exactly from the source standards

If we DO, that implies that:

  - descriptions may be edited via the registration process.
  - (thus) descriptions may be edited at inception. This suggests that 
we regularize them minimally.

I would suggest, based on this thread, that we regularize them only 
minimally, preserving the *right* to modify anything weird that one of 
the standards might emit, while in practice (more-or-less) slavishly 
following whatever the standards bodies emit (which is the situation 
that obtains today).

That suggests neither inventing inversions or undoing them.

Addison

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

Internationalization is an architecture.
It is not a feature.

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 12 Dec 2006 18:28:58 -0800

+1

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 Dec 2006 20:24:04 -0800

John Cowan <cowan at ccil dot org> wrote:

>> indicated by the word "languages").  These are indispensable IMHO, if 
>> we want to discourage use of collection-code subtags.
>

Section 4.1, item 3 of draft-4646bis says we do.

> I think it's worth noting that the overwhelming majority of 
> parenthetical bits in 639-3 are of this type.

Absolutely true.  Actually, I obscured my own intended point, which was 
not that these parenthetical comments should or should not be deleted, 
but that I don't understand what sort of "regularizing" is supposed to 
be applied to them.  My take is that they should be left alone, except 
arguably for "(generic)" and "(specific)".

> There really are two constructed languages called "Interlingua", 
> namely "Interlingua de IALA" (this one) and "Interlingua de Peano", 
> also known as "Latine Sine Flexione".

The "other" Interlingua was apparently in the 2005-06-14 version of the 
ISO 639-3 tables ("iln") but was removed from the 2005-06-24 version, 
and has not been seen since.  Another good reason not to rely on the 
stability of draft data.

> the unrelated current language Ligurian, a Romance language of the 

Let's just not mess around with the parenthesized items.  None of them 
hold alternative names that need to be split off, or anything like that.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 12 Dec 2006 21:50:39 -0800

> I think you mean draft-01

Yep.  I'm the one who is stuck on draft-00.

> have a way to edit anything bizarre without requiring a new RFC or 
> other magic.

I don't remember anything "bizarre," other than the bizarre 
acute-accent-as-modifier in Gwich´in, which we incidentally still have.

> ... I think we should modify that paragraph...
> to say instead:
>
> --

I'm fine with that.  Does "problematic" include issues like the one 
Karen raised about Scots, though?  I know, very carefully you didn't 
define it.

> we regularize them minimally.

I agree with every word of the above.  That still leaves the question 
unanswered:  do we or don't we?

> following whatever the standards bodies emit (which is the situation 

How do the conservatives on the list feel about this?

> That suggests neither inventing inversions or undoing them.

I can live with that.

---

From: Marion Gunn <[email-masked]>
Date: Wed, 13 Dec 2006 12:35:26 +0000

On 12 Dec 2006, at 22:25, scríobh [email-masked]:
>
> For the record, I was previously reprimanded for suggesting the use  
> of "Gaelic (Scots)" because of its potential to confuse the user  
> with the Scots language. I agreed. In my local applications, I'm  
> now using "Gaelic (Scottish)."

For the record (for those who STILL find it hard to match languages  
to countries):
the "Celtic" language of Scotland is "Gaelic";
the "Celtic" language of Ireland is "Irish";
the "Celtic" language of the Isle of Man is "Manx";
the "Celtic" language of Wales is "Welsh";
the "Celtic" language of Brittany is "Breton";
the "Celtic" language of Corwall is "Cornish".

As you can see, the only mismatch is Scotland, having a language  
called "Gaelic" - ALL the other languages are called by names which  
match the names of the countries to which they belong.  Deviating  
from this simple rule causes offense to speakers and endless  
difficulties to both teachers and learners.
mg

- -
Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Dec 2006 10:23:27 -0500

> difficulties to both teachers and learners.

Quite so.  But people *do* deviate from the rules, so a little
additional disambiguation doesn't hurt.  One approach would be
to follow "Ainu (Japan)" more closely and go with "Gaelic (Scotland)".

But this is a matter for the 639 RA/JAC and not for us.

-- 
Take two turkeys, one goose, four               John Cowan
cabbages, but no duck, and mix them             http://www.ccil.org/~cowan
together. After one taste, you'll duck          [email-masked]
soup the rest of your life.
        --Groucho

---

From: Addison Phillips <[email-masked]>
Date: Wed, 13 Dec 2006 12:11:35 -0800

I thought some more about it. I'm proposing that we go even further and 
change this:

--
For records taken from a source standard (such as ISO 639 or ISO 3166), 
the 'Description' value(s) SHOULD be taken from the source standard. 
Multiple descriptions in the source standard MUST be split into separate 
'Description' fields. The source standard's descriptions MAY be edited, 
either prior to insertion or via the registration process.

To read like this:

--
For records taken from a source standard (such as ISO 639 or ISO 3166), 
the 'Description' value(s) SHOULD also be taken from the source 
standard. Multiple descriptions in the source standard MUST be split 
into separate 'Description' fields. The source standard's descriptions 
MAY be edited, either prior to insertion or via the registration process.

When creating or updating a record due to the action of one of the 
source standards, the Language Subtag Reviewer SHOULD remove duplicate 
or redundant descriptions and MAY edit descriptions to correct 
irregularities in formatting prior to submitting the proposed record to 
the ietf-languages list.
--

Note that this version stresses fixing formatting (which I take to mean 
extra spaces, unruly typesetter's quotes, capitalization irregularities, 
and the like). It also removes the need for Doug to document exactly 
what is necessary for the future. (I think he will still need to 
document his own actions, if any, in creating the updated registry.)

Addison

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Dec 2006 16:45:17 -0500

+1

Short and to the point, neither too vague nor too specific.
It has the virtue of not assuming that the Official Doug is an idiot.

-- 
Dream projects long deferred             John Cowan <[email-masked]>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
        --James Lileks