The "not-language" identifier (was: RE: Mandarin Chinese, Simplified Script)

[Peter Constable]

> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of L.Gillam


> AGAINST: If you have a language identifier for "not language",
> can I have one for "not French"? "not English"? "neither French nor
> English"?
> Perhaps Debbie's floodgates?
> 
> >From a 639 perspective, where could it sit - 639-4 as a general
> principle? 639-5 as the family of all not-languages? And what
> kind of documentation does one use to justify it, or is it a pure
> exception?
> 
> If it's not language, why use a language tag and then tag it to
> say that it isn't? And, hence, need to create a tag amongst
> language tags that represents not being a language? For some
> reason, identifying something as "language = it isn't" feels odd
> to me, as would doing the same with a lot of other identifiers.
> "gender = it hasn't"; "country = doesn't exist" etc.

These aren't particularly strong arguments. To go from "not language" to
"not English" is a huge leap, and it's pretty obvious the JAC would
never consider the latter. The question of what part of 639 it would fit
is isn't particularly important. Part 2 already has specials;
eventually, the alpha-3 space will likely get merged. As for why use a
language tag and then say "it isn't", those arguments have been made;
various agencies making real applications using 639 have demonstrated
needs.



> It's that ideal/real divide again, I believe.

Just so.

If ISO 639 existed solely for the purpose of language documentation,
then clearly such special-case IDs would be out of place: there's no
such language as 'not language'. But that is not why ISO 639 exists. It
exists for real IT applications.



Peter Constable