proposed ISO 639 change for "arn"

[Doug Ewell]

Michael Everson <everson at evertype dot com> wrote:

> This isn't simple "political correctness". The user community refuses
> to use this code element because they consider it to be deeply
> offensive.

I'm not sure what code element the user community, which "is about to
enter the digital age in a big way" and thus presumably will have
increasing need for a code element, plans to use if they refuse to use
the official one. Maybe they would make up their own, ignoring the
user-defined zone of ISO 639-3 in favor of something starting with 'm',
and of course that is the worst outcome of all. So I'm willing to take
"leave it alone" off the table and concede a change of some kind is
needed.

I remain convinced that a macrolanguage is exactly the wrong way to go
here. There doesn't appear to be any evidence, in the case of Mapudungun
and either Huilliche or any other language, that we are looking at two
or more "closely-related language varieties that [...] can be considered
distinct individual languages, yet in certain usage contexts a single
language identity for all is needed."

The online Ethnologue page on Huilliche says, "Related to Mapudungun
[arn], but barely intelligible with it." The Ethnologue page on
Mapudungun doesn't even mention Huilliche. This does not seem at all
like an appropriate situation for creation of a macrolanguage. Doing so
merely to achieve a particular outcome with respect to the use of old
and new code elements would amount to gaming the system, and it would
confuse users of 639-3 even more about what a macrolanguage is, and
dilute its meaning for future use of the standard.

Creating a collection code element that encompasses Mapudungun and
Huilliche is a bit more defensible. Ethnologue does recognize an
"Araucanian" language family that contains exactly these two languages.
However, if 'arn' were reclassified to apply to this collection (which
is the whole point behind this exercise, right?), then Peter's concern
about the logistics of moving a code element out of 639-3 and into 639-5
would kick in. And Addison's objection would apply as well: saying that
Mapudungun is "contained within" Araucanian would do little to help an
offended people feel less offended.

Michael cited an example of three 639-2 code elements being changed,
back in 1998. Earlier, Philip mentioned iw/he and in/id and ji/yi. I
don't see why this isn't exactly the same situation, or in what way
creating a bogus macrolanguage just to keep 'arn' alive would be "safer"
than withdrawing 'arn' and assigning a new identifier. There was already
deployed software and data that used 'iw' and 'in' and 'ji', and they
were used for many years after the official changes -- partly because at
the time, unofficial, outdated lists of ISO 639 code elements were much
easier to find online than official, current lists. But we survived
nonetheless.

Nobody really wants to change code elements again, but this is the least
evil option. There is, as Gordon said, precedent for it. From a BCP 47
standpoint, the solution is especially clean because the concept of
"deprecated" subtags exists: you can still use the old subtag, and your
data won't be corrupted, but you really should use the new subtag
instead.

Most importantly, though, it's the *right thing to do* in this
situation. If the real requirement is to change a code element, change
the code element.

--
Doug Ewell | Thornton, Colorado, USA
http://www.ewellic.org | @DougEwell ­