New item in ISO 639-2 - Zaza

Addison Phillips addison at yahoo-inc.com
Fri Aug 25 03:03:43 CEST 2006


The thing that bothers me about #1 is that, heretofore, nearly all
language tag processing required only the information in the language
tag(s), without reference to informative fields in the registry... that
is, one can match language tags "at a glance".

I think that is a Good Thing.

While fallbacks in CLDR are one thing, I think it would have a quite
negative impact on matching implementations or pure language tag
processors to require a mapping table. And "different date"
implementations would do different things with ranges or tags, which is
undesirable.

There is a specific need to accommodate existing tagging practice, such 
as the zh-* tags. There is no such need to create new macro-languages in 
the future.

In particular, I would suggest that:

1. Any ISO 639-3 code that is a "sublanguage" of an existing,
non-deprecated language subtag (and preferably an acknowledged 
macrolanguage) is made an extlang.

2. All others are language subtags.

3. Once a language subtag, always a language subtag. Once an extlang,
always an extlang.

4. If a new macro-language code is introduced that would encompass 
existing codes, it is put into the registry as a deprecated language 
subtag. (The deprecation may be subject to review: a code might be 
useful on its own). However: any existing sublanguages are NOT made into 
extlangs of it.

5. If a new sublanguage of an extant code is introduced, see #1.

Thus:

   zh-cmn  (right)
   cmn     (wrong)
   rkn     (right, deprecated)
   ams     (right)
   rkn-ams (wrong)

And if we invent a new Chinese variation 'cmx':

   cmx     (wrong)
   zh-cmx  (right)

Overall, it means that the choice of language tags is as stable as it is
reasonable to make it.

Another way of saying this is that a code is either a language subtag or
an extlang at birth and this can never change. Mutations of existing
tags remain compatible with existing documents and generally work with
extant matching schemes.


Incidentally, why are we discussing this here and not on the LTRU list?

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.




More information about the Ietf-languages mailing list