ON LANGUAGE NAMES /// RE: Results of Duplicate Busters Survey #2//Ainu, Aynu, Ajnu

[ISO639-3 at sil.org]

>... but it was not a requirement for the RA to change its 
>policies to match our views of how names or code elements should be 
>assigned.

Nor did the ISO 639-3/RA do so (or feel pressure to do so). The 
disambiguation was necessary for the ISO 639-3 standard itself. We 
followed the precedent already established in the code set at the time of 
its adoption (and also applied since), in well over 100 other cases of 
names used for 2--in several cases 3 or 4--separate languages, involving 
over 230 language code elements. Doug took the precedent already 
established and suggested the individual case solutions based on the 
existing pattern. The RA was grateful to have the name ambiguities brought 
to our attention, and glad our solution also served yours. 

Joan Spanne
ISO 639-3/RA
SIL International
7500 W Camp Wisdom Rd
Dallas, TX 75236
ISO639-3 at sil.org




"Doug Ewell" <doug at ewellic.org> 
Sent by: ietf-languages-bounces at alvestrand.no
2008-09-12 07:56 AM

To
<ietf-languages at iana.org>
cc

Subject
Re: ON LANGUAGE NAMES /// RE: Results of Duplicate Busters Survey 
#2//Ainu, Aynu, Ajnu






Peter Constable <petercon at microsoft dot com> wrote:

> Gérard is suggesting to change the encoding of an entity encoded in 
> ISO 639-3: to change "aib" to "ajn". This would be a destabilizing 
> change that would violate the principles of BCP 47 as well as ISO 
> 639-3, and that serves no useful purpose that I can see. Please see 
> clause 4.5.2 of ISO 639-3:
>
> "To ensure continuity and stability, the identifier for any given 
> language shall not be changed."
>
> This is a complete non-starter.

I agree 100%, and also agree with Michael that talk of "improving" the 
way ISO 639-3/RA assigns code elements and names is getting out of scope 
for this list.

This is not the same as what I proposed in the surveys, which was for us 
(the BCP 47 people) to disambiguate identical Description fields for 
different languages.  The fact that ISO 639-3/RA did the work for us, 
allowing us to solve our problem while remaining name-compatible with 
639-3, is great, but it was not a requirement for the RA to change its 
policies to match our views of how names or code elements should be 
assigned.

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

_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20080912/fc6e7776/attachment.htm