Subject: RE: [Ltru] Re: Inversions and other problems

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 17 Oct 2006 11:06:23 -0700

+1

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Addison Phillips [mailto:[email-masked]]
Sent: Tuesday, October 17, 2006 11:57 AM
To: Addison Phillips
Cc: Frank Ellermann; [email-masked]
Subject: Re: [Ltru] Re: Inversions and other problems

Maybe more to the point, I propose we insert this text into the 
'Description' section of the document (the current Section 3.1.3.2):

<t>For a records of a given 'Type', the value of the 'Description' field 
MUST be unique. 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 also be edited prior to insertion. Duplicate, 
redundant, conflicting, or otherwise problematic descriptions SHOULD be 
omitted. Parenthetical comments, inverted names, and other formatting 
quirks SHOULD be regularized according to the guidelines used to update 
the registry in <xref target="registry-update"></xref>.</t>

Addison

Addison Phillips wrote:
> Mark Davis wrote:
>> As I said before, I can live with inversion IF it is fixed. That means 
>> an extension of Addison's proposed rules.
>>
>> 1. Follow the source standard.
>>
>> 2. Split multiple names into multiple description fields.
>> I believe Addison meant: X, Y, Y =>
>> Description: X
>> Description: Y
>> Description: Z
> 
> Yes, exactly so.
> 
>>
>> 3. Omit or edit problematic items, subject to consensus.
>>
>> plus
> 
> Well... my goal was to avoid having to spell all of this out. We've got 
> enough rules, so I think some hand-waving is in order. While I note the 
> problem projects like CLDR might have producing localizations, the use 
> of an actual Turing machine (aka Doug Ewell) to create the entries 
> should eliminate a lot of woes. Furthermore, I tend to think that the 
> *detailed* rules you propose should go into 4645bis (i.e. "how did the 
> entries get this way"), while the simpler version I proposed can go into 
> 4646bis (perhaps with a pointer to "pre-existing customary practice" in 
> 4645bis).
> 
>>
>> 4. Ensure that there are no duplicates (where inversion and/or removal 
>> of parenComments results in a duplicate within the same subtag, or 
>> where names are the same across different subtags of the same type)
> 
> I wasn't specific enough in my little bit of text above. "Duplicates" 
> (including inverted duplicates) are members of the class "problematic".
> 
> 
>>
>> 5. The only information in parentheses is a comment, eg a 
>> clarification of the description.
> 
> This could be guidance added to rule 3.
> 
>>
>> 6. The final result being that there are NO description items with 
>> commas outside of parenComments, except for the case that there is a 
>> single comma indicating inversion.
>>
> 
> Except that you go on to demonstrate below that sometimes inversion is 
> illusory.
> 
>> If these are the rules, then I'm satisfied.
>>
>> ==
>>
>> Ideally, we'd have two additional rules:
>>
>> 7. The most commonly known name is in the first Description.
>> (This may already be the case -- I don't know.)
> 
> I don't think this is appropriate. The level of judgment required is too 
> great for the ietf-languages list to manage.
> 
>>
>> 8. A description is unique even if the parenComment is removed.
>>
> 
> We need a "MUST" here. I'd propose:
> 
> -- 
> For a given record type, each Description field MUST be unique.
> -- 
> 
> Addison
> 

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

Internationalization is an architecture.
It is not a feature.

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

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.4/480 - Release Date: 10/17/2006

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 19 Oct 2006 23:40:57 -0700

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

> I'm not fond of the idea "to drop the description "Ainu (Japan)" on 
> 'ain'" (leaving just "Ainu"), since that does not hint that there 
> *may* be more than one "Ainu". Nor do I like the idea of "change the 
> "Ainu (China)" to "Ainu, China" on 'aib'", since 1) that would be 
> "equivalent" to "China Ainu" which looks strange ("Chinese Ainu" would 
> seem better), and 2) if the country name is replaced by a language 
> group name (which I would prefer, compare "Slave (Athapascan)"), both 
> the inverted and non-inverted name would look really strange.

I agree.  I don't see anything inherently wrong with these parenthetical 
modifiers that would be improved by using a comma instead.

We still need to be very careful not to confuse the three issues of (1) 
macrolanguage, (2) collective code element, and (3) different languages 
with the same name.  I'm sure Peter would be happy to repeat this 
explanation again.

> One more reason that I don't like using country names for 
> distinguishing same-named but different languages is that name tags, 
> as per 1766 and successors, already allow region codes. One may well 
> be tempted to think that:
>
> * "ain-CN" is the same as "aib", which it is not and "Ainu (China)" is 
> therefore misleading (and many UIs might not make a display name 
> distinction), and that
>
> * "swa-CG" (or "swa-CD") is the same as "swa-swc",

The use of "(country)" qualifiers may cause some confusion for casual 
perusers of the Registry, but it's probably the best we've got for two 
unrelated languages that happen to have the same name.  Some are very 
uncommon (Ethnologue cites 15 speakers of "Ainu (Japan)", and states 
that "Ainu (China)" is spoken only within the home) and there should be 
little real-world confusion.  Names based on linguistic family 
classifications might be a lot harder for non-linguists to understand. 
Subtags like these are extremely unlikely to be used with region subtags 
anyway.

Pretending for the moment that the two Ainus were in MUCH more 
widespread use, all of the following tags would make sense, because 
"Ainu of China" and ""Ainu of Japan are two different languages.

aib-CN ("Ainu of China") as used in China
aib-JP ("Ainu of China") as used in Japan
ain-CN ("Ainu of Japan") as used in China
ain-JP ("Ainu of Japan") as used in Japan

Because they are both in such limited use, both by area and by number of 
speakers, the use of region subtags above would qualify as overkill.

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 22 Oct 2006 11:20:26 -0700

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

> In practice there's a lot of stuff piling up:  the script
> issues, the review issues, the language type/scope issue,
> some type "C" oddities, now the descriptions, etc.

I agree, and feel that the chairs need to assist in sorting out and 
triaging the various change requests.  Many are not in the charter, and 
some might need to charter to be revised before they can be considered.