New item in ISO 639-2 - Zaza
cowan at ccil.org
Fri Aug 25 17:48:12 CEST 2006
Peter Constable scripsit (this is a consolidated response):
> Clarification: IIUC the scenario you're describing is that these 11
> are not newly added in 639-3 at the time of adding 'rkn' but rather
> already exist in 639-3 and (assuming 3066ter) are already in the
> subtag registry.
> (I don't see a particular reason to consider the present interim;
> only the 3066ter era matters.)
> We wouldn't be adding [extlang subtags] if they're already in the
They'd be in the registry as language subtags; we'd be adding them
as extlang subtags. A subtag can't change type, but one can be
deprecated and another added.
> It seems to me if the 11 are already in the registry, then our
> options are:
> (a) do not add 'rkn' to the subtag registry; the 11 remain as primary
> language subtags
> (b) add 'rkn'; change the 11 to extlangs and deprecate their use
> as primaries
> (c) add 'rkn' and allow the 11 to be used either as primaries or as
> extlangs with xxx and rkn-xxx synonymous
> (d) add 'rkn'; the 11 continue to be used as primaries but cannot be
> used as extlangs; we document the relationship in the registry so that
> matching processes can do the right thing (requiring a change to the
> matching algorithm)
This restates the various options we have been discussing.
> Now, if you are talking about a scenario in which the 11 are not
> already in the registry [or if] you are talking about a scenario in
> the present interim, then there is no problem:
> - The lumper / splitter tendencies are artifacts not only of 639-2 and
> 639-3 but of users out in the world (which is how 639-2 and 639-3 got
> to be the way they are).
I didn't mean to imply otherwise. To caricature my point: 639-2 was
originally designed to serve librarians, who tend to be lumpers; 639-3
was originally designed to serve translators, who tend to be splitters.
> It is not out of the question that new macrolanguage entities might
> get created in ISO 639, however, if there is a clear user need for
> such an entity. That was precisely what led to the addition at this
> time of a macrolanguage entity for Zaza.
Do you have the details? I'd be interested to know just why a
macrolanguage seemed appropriate (as opposed to registering the
two encompassed languages separately in 639-2).
> My thought is: if a new macrolanguage yyy is added to 639 for which
> there are macrolanguage mappings to some entity xxx that pre-existed,
This is the Zaza case, correct?
> or if macrolanguage mappings are added to some entity xxx that
This case is entirely novel. I understand it to mean that we find out
that although Thwackian is as sharply divergent from both Northern and
Southern Thuddian as they are from each other, nevertheless people
in the Empire of Thud consider Thwackian just another local variety
of Our Glorious Thuddian Language, and so 639-3 adds Thwackian to the
> (the two scenarios where this issue can arise), then we do not allow
> xxx to be used as an extlang; it can only be used as a primary subtag
> as it had before the change.
Well, I have to agree; though I would like to know why and when either
of these actions is worth taking.
John Cowan http://www.ccil.org/~cowan cowan at ccil.org
Please leave your values Check your assumptions. In fact,
at the front desk. check your assumptions at the door.
--sign in Paris hotel --Cordelia Vorkosigan
More information about the Ietf-languages