proposed ISO 639 change for "arn"

Peter Constable petercon at
Tue Dec 11 09:42:53 CET 2012

Changing the scope of "arn" to a collection was definitely not my idea. I consider it fairly problematic to change to or from a collection since 639-3 does not contain collections and 639-5 contains only collections. Moreover, I can easily imaging implementations that do not accept collections but that may already support "arn". And it doesn't solve the fundamental problem that existing implementations of "arn" still need to support it in its old usage.

Windows has shipped support for Mapudungun using "arn" in around a billion PCs. I can't exactly make that go away.


-----Original Message-----
From: ietf-languages-bounces at [mailto:ietf-languages-bounces at] On Behalf Of Phillips, Addison
Sent: December 10, 2012 10:09 PM
To: Michael Everson; ietflang IETF Languages Discussion
Subject: RE: proposed ISO 639 change for "arn"

> > Deprecations generally just cause problems, from software just not 
> > accounting for it. So it is best avoided where possible. It would be 
> > better to just leave it as arn = Mapudungun
> No, it is better to re-assign "arn" to the macrolanguage and give the 
> user community something they will actually use. Look, folks, we don't 
> have a high moral ground here. We can't say "suck it up, lads, get 
> over it". Because "arn" is clearly "araucano" and whether we like it 
> or not, "araucano" is equivalent to "nigger".

Are you sure that's the best solution, though?

Saying it's a macrolanguage basically says that the Mapudungun language is "contained by" Araucano. If your characterization is correct, that actually seems just as offensive, and maybe more so. Further, it would create a new extended language subtag (or two).

I agree with Mark that withdrawing the old code (and thus deprecating it in our registry) would be problematic for implementers (including the librarians) and should be avoided if possible: having only a small number of identified items using the code in one or another place doesn't mean that it's an easy fix. Changing codes is a problem because all implementations must deal with them as special cases effectively forever, not just as a one-time trip to the card catalog.

Actually, Peter's other suggestion (of making it a collection code) starts to seem like the best idea to me. The code is still present, but represents a collection. No special casing or extended language subtags are created. If everyone ignores the collection code hard enough, it will be as if it went away. 

Ietf-languages mailing list
Ietf-languages at

More information about the Ietf-languages mailing list