Subject: [Ltru] Disambiguating specific and generic names

From: "Doug Ewell" <[email-masked]>
Date: Sat, 14 Oct 2006 23:30:23 -0700

I've just learned, from reading the ISO 639-3 FDIS text (Section 4.3), 
that when a macrolanguage and an individual encompassed language have 
the same name -- for example, Konkani "kok" and Konkani ""knn" -- they 
will be suffixed with the strings "(macrolanguage)" and "(individual 
language)" respectively, not "(macrolanguage)" and BLANK as previously 
reported.

I'll correct the proposed RFC 4646bis Registry to reflect this, and will 
submit draft-4645bis-01 to internet-drafts shortly.

--
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: "Mark Davis" <[email-masked]>
Date: Sun, 15 Oct 2006 11:07:33 -0700

I don't see why that is necessary. The registry has the tag extlang, which
tells us that knn is Konkani as an individual language. We hardly need a
paranthetical to do that, because we have extlang.

%%
Type: extlang
Subtag: knn
Description: Konkani
Added: 2007-01-01
Prefix: kok

Formally, also, the second description line in the following is unnecessary:

%%
Type: language
Subtag: kok
Description: Konkani
Description: Konkani (macrolanguage)
Added: 2005-10-16
Suppress-Script: Deva

I can tell that kok is Konkani as a macrolanguage simply by the fact that it
is the prefix of some extlang (such as knn) in the repository.

Mark

---

From: John Cowan <[email-masked]>
Date: Sun, 15 Oct 2006 14:18:37 -0400

Mark Davis scripsit:

> I don't see why that is necessary. The registry has the tag extlang,
> which tells us that knn is Konkani as an individual language. We hardly
> need a paranthetical to do that, because we have extlang.

The point here is to track 639-3 in the Description fields.

> is the prefix of some extlang (such as knn) in the repository.

In fact, you can't reliably do so, because encompassed languages
that have their own 639-2 tags (e.g. sr) are given language subtags,
not extlang subtags.

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
Half the lies they tell about me are true.
        -- Tallulah Bankhead, American actress

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 15 Oct 2006 11:59:12 -0700

Functionally in the registry, X is a macrolanguage iff it has at least one
extlang. Macrolanguages that don't have any extlangs behave precisely the
same as non-macro languages, so as far as the registry is concerned there is
no functional difference.

So the only issue is whether there could be confusion between two language
tags (not including extlangs) that would be cleared up by adding the extra
paranthetical to one of them that it is a macro language. So you might look
to see if there are any such cases.

Mark

---

From: John Cowan <[email-masked]>
Date: Sun, 15 Oct 2006 15:29:07 -0400

Mark Davis scripsit:

> Functionally in the registry, X is a macrolanguage iff it has at least 
> one extlang.

Syntactically, yes.  Semantically, no.

-- 
BALIN FUNDINUL          UZBAD KHAZADDUMU        [email-masked]
BALIN SON OF FUNDIN     LORD OF KHAZAD-DUM      http://www.ccil.org/~cowan

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 15 Oct 2006 12:48:21 -0700

The only way the semantics play a role is, as I said, if they serve to
disambiguate two entries. If you think this information is necessary, it
would be useful to find a case where it does, in fact, disambiguate.
Otherwise it is unnecessary in the registry. There is *lots* of information
about languages out in the world -- we just need to focus on the information
that is necessary for the registry itself.

Mark

---

From: "Kent Karlsson" <[email-masked]>
Date: Sun, 15 Oct 2006 22:15:54 +0200

I still hope that 639-3 will not use "(specific)"/"(macrolanguage)" or similar parentheticals, but rather
along the line of adding "Standard" (or similar) where necessary to bring clarity to the names.
 
B.t.w, I find it strange that    zne Zande     (Standard Zande?) is regarded as a "(specific)" language,
while       znd Zande      is regarded as a "collective" language code, not a macrolanguage code.
 
        /kent k

-----Original Message-----
From: Mark Davis [mailto:[email-masked]] 
Sent: Sunday, October 15, 2006 9:48 PM
To: John Cowan
Cc: [email-masked]
Subject: Re: [Ltru] Disambiguating specific and generic names

The only way the semantics play a role is, as I said, if they serve to disambiguate two entries. If you think this information is necessary, it would be useful to find a case where it does, in fact, disambiguate. Otherwise it is unnecessary in the registry. There is *lots* of information about languages out in the world -- we just need to focus on the information that is necessary for the registry itself. 

Mark

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 15 Oct 2006 16:07:28 -0700

Mark Davis wrote:

> which tells us that knn is Konkani as an individual language. We 
> hardly need a paranthetical to do that, because we have extlang.
> ...
> I can tell that kok is Konkani as a macrolanguage simply by the fact 
> that it is the prefix of some extlang (such as knn) in the repository.

OK, then, once and for all:

Are we going to adhere to a rule that all Description fields must match 
the source standards exactly, or are we not?

We cannot continue to claim we follow this rule, constrain ourselves by 
it, and then not follow it, or vice versa.  We must make a decision one 
way or the other and stick to it.

I will wait until one of the co-chairs has declared a rough consensus on 
this issue before releasing draft-4645bis-01.

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 15 Oct 2006 16:19:55 -0700

My vote is that we do not constrain ourselves to follow precisely what is in
the source standard. Our descriptions should be clear, unambiguous, and
useful. Wherever the source standard description is such, we should follow
it precisely. Wherever not, we should not be bound to it.

Mark

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 15 Oct 2006 16:24:18 -0700

Mark Davis wrote:

> My vote is that we do not constrain ourselves to follow precisely what 
> is in the source standard. Our descriptions should be clear, 
> unambiguous, and useful. Wherever the source standard description is 
> such, we should follow it precisely. Wherever not, we should not be 
> bound to it.

To play devil's advocate, I would argue that "Konkani (macrolanguage)" 
and "Konkani (individual language)" are all of those: clear, 
unambiguous, and useful.  If you want to add "maximally concise" to the 
list, then there are a great many Description fields that would have to 
be re-examined as well.

---

From: John Cowan <[email-masked]>
Date: Sun, 15 Oct 2006 20:26:38 -0400

Kent Karlsson scripsit:

> B.t.w, I find it strange that    zne Zande     (Standard Zande?) is
> regarded as a "(specific)" language, while       znd Zande      is
> regarded as a "collective" language code, not a macrolanguage code.

Such things are not uncommon.  Consider German vs. Germanic, or 
Greek (the language) vs. Greek (the subfamily of Indo-European),
or Turkish vs. Turkic (which are the same word in Turkish).

-- 
John Cowan  [email-masked]   http://ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
       --Specht v. Netscape

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Oct 2006 02:25:00 +0200

Doug Ewell wrote:
 
> I will wait until one of the co-chairs has declared a rough
> consensus on this issue before releasing draft-4645bis-01.

If there are any modifications in your -01pre better submit
it before the IETF 67 cut-off (next Monday) and let's see it.

Randy and Martin can't make up such decisions, they need to
see some discussions on the list first, and ideally proposed
text (or alternative proposals like Mark's A vs. B). 

At the moment I'm not sure what's better, I like the output
of B better than A.  Apparently B keeps all "xyz, adjective"
together in a list sorted by descriptions, that's a feature.

Apparently B tosses out any original "adjective xyz", that's
bad.  And apparently B requires to replace some commata by
semicolons based on manual inspection, that's utter dubious:
If the source is buggy it has to be fixed.

Frank

---

From: John Cowan <[email-masked]>
Date: Sun, 15 Oct 2006 20:26:38 -0400

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Oct 2006 02:25:00 +0200

Frank

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 16 Oct 2006 08:27:30 -0700

My list of examples was a quick pass, just to see what the results would
look like. I do *not* think that all the items were correct.

That is actually the point -- it is impossible to mechanically distinguish
between cases that are inversions and the cases that are separate items.

That's why knowledgeable people need to go through the items to repair this
mess.

Mark