New item in ISO 639-2 - Zaza

[John Cowan]

Frank Ellermann scripsit:

> Who's that "we" in this statement, the subtag list ?  I'd hope
> that the business of introducing new macrolanguages or not is
> the job of ISO 639, and not a side-effect of 639-2 doing this,
> and 639-3 doing that (= nothing, for the part after the "or" in
> your scenario).

Let me spell things out more clearly with a hypothetical case, set after
ISO 639/3 and RFC 3066ter are up and running:

1) A group approaches 639-2/RA (the Library of Congress) asking for
a language tag for the Ryukyuan language (closely related to, but
distinct from, Japanese) and presents the usual sort of evidence for
its registration.

2) 639-2/RA grants this, assigning it the available 3-letter code element
'rkn'.

3) 639-3/RA (SIL) notices that this "Ryukyuan language" corresponds to 11
different languages in its list, with codes 'ams', 'kzg', 'ryn', 'tkn',
'okn', 'ryu', 'xug', 'yox', 'mvi', 'rys', 'and' 'yoi'.  Therefore, it adds
'rkn' to its list of macrolanguages and specifies that it encompasses
those 11 languages.

4) We, ietf-languages, must react to the creation of this code.  It may
be that LTRU has spelled out what to do in 3066ter, or it may be that we
have been delegated the responsibility of deciding what actions to take.
In either case, the considerations below are the same.

5) Under option #2, we just add 'rkn' as a new language subtag, end
of story.  This leaves users to figure out when and whether to use it
as opposed to any of the 11 existing language subtags.  This is the
situation with "no" vs. "nb" and "nn" today.

6) Under option #1, we have two choices (again, the choice may have been
made in advance by LTRU, but that doesn't affect the argument):

6a) Add 'rkn' as a language subtag and immediately deprecate it, thus
encouraging people to use the other tags instead.  This is what we do
when ISO 3166/MA changes a country code element.

6b) Add the 11 existing 639-3 code elements as extlang subtags, add 'rkn'
as a language tag, and deprecate the 11 code elements as language subtags,
specifying "rkn-XXX" as the preferred form.  This provides the cleanest
long-term results.

> Unless 639-3 is bound to create this macrolanguage anyway, then
> getting it right before it's "official" might be an option.
> 
> It never occured to me that 639-2 and 639-3 could get into some
> conflicts, Peter always said that such issues will be fixed in
> the final version.  And I thought it couldn't happen after that
> "date-C" in 2007.

Well, hopefully the 639 RA/JAC, whose job it is to keep the various RAs
consistent, will stop the above process at step 1.  But if they do not,
then we need a resolution scheme, however unlikely it is to be used.

-- 
They tried to pierce your heart                 John Cowan
with a Morgul-knife that remains in the         http://www.ccil.org/~cowan
wound.  If they had succeeded, you would
become a wraith under the domination of the Dark Lord.         --Gandalf