Subject: Re: [Ltru] Expanding the xx..yy ranges (was: Re: Two grandfathered tags for 'Hakka')

From: "Doug Ewell" <[email-masked]>
Date: Tue, 29 Jul 2008 18:56:52 -0600

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

>> 1. whether to modify the Description fields of ISO 639-3 language 
>> names that contain ASCII approximations of click letters, replacing 
>> them with real Unicode click letters
> ...
>
> I think ltru is the wrong place to be making such a change - this 
> would be more properly discussed on [email-masked], since it 
> pertains to the content of specific registration records, rather than 
> being a general question of policy or format.

You correct me on this point from time to time.  Here's why I think this 
issue does belong here:

1. We have an existing policy of treating ISO-derived Description fields 
as sacrosanct, for traceability purposes.

2. We (LTRU) are planning to modify this policy to allow disambiguation 
of duplicate names (which I think is a great idea).  This would apply to 
new records added as part of the LTRU 2.0 effort (derived from ISO 
639-3), since no such duplicates exist in the current Registry. 
Therefore, this is generally acknowledged to be an LTRU function.

3. The present proposal (due to Kent) is to allow Description fields 
that include ASCII approximations of click letters to be changed to use 
the real click letters instead.  This also applies only to the new LTRU 
2.0 records, since the click letters exist only in ISO 639-3 code 
elements (not in other parts of ISO 639) and since no other ASCII-only 
Description fields have ever been proposed to be changed to use 
non-ASCII.  This too is a matter of policy, and therefore (I contend) 
also an LTRU function.

We can defer it to ietf-languages if you like, but I predict that it 
will be handled there in an inconsistent, ad-hoc, one-off manner, as 
always when ietf-languages is asked to create general guidelines left 
out of the RFC.

> Furthermore, if there is support for including the "real" Unicode 
> clicks, I believe these should be in addition to, rather than as 
> replacements for, the representations we got from ISO 639-3.

In that case, I oppose adding them.  We really don't need more 
typographical duplicates that add no new information, but merely call 
attention to perceived character set problems or font coverage problems. 
We already have:

Description: Ethiopic (Geʻez)
Description: Ethiopic (Ge'ez)

and:

Description: Hangul (Hangŭl, Hangeul)

and:

Also known as: New Turkic Alphabet; Birlәşdirilmiş Jeni Tyrk Әlifbasь 
(Birlesdirilmis Jeni Tyrk Elifbasi); Jaŋalif (Janalif).

and I think this is nonsense, and I am trying to get rid of it.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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