Sample IANA language subtag registry

Peter Constable petercon at microsoft.com
Thu Jul 8 02:02:41 CEST 2004


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


> Section 3.2 of draft-phillips-langtags-04 describes the format of the
> IANA language subtag registry, which would be a normative part of RFC
> 3066bis.
> 
> This registry is to be assembled by the language subtag reviewer, but
to
> get a jump on implementation and to solidify my understanding of
> conformance issues, I've gone ahead and created my own copy of what
the
> registry might look like...

> This is intended as a sample of the final registry, and at present
> contains only the standard codes:
> 
> * ISO 639 alpha-2 and alpha-3 language codes
> * ISO 15924 alpha-4 script codes
> * ISO 3166 alpha-2 and UN M.49 numeric region codes
> 
> and no entries yet for registered subtags or grandfathered whole-tags.

Whoa! Back up the truck!

In the past, it has not be necessary to register entire tags that were
considered as given because they consisted of combinations of ISO 639
and ISO 3166 IDs. It has only been necessary (and expected) to register
complete tags (other than x-...) in case they do *not* consist of
combinations of existing ISO 639 and ISO 3166 IDs.

Under the terms of the new RFC the only subtags that should need to be
registered are the language IDs that are not in ISO 639, or variant IDs.

There is no need to create a registry of existing ISO 639 IDs, ISO 3166
IDs, or ISO 15924 IDs. 

We should not be providing lists that mirror the code tables for those
standards. The *only* reason to provide a list of ISO 639 IDs or ISO
3166 IDs, etc., would be if we explicitly wanted to limit the accepted
values from one of those sources (such as I suggested at one point that
we do for ISO 639-1). If we simply mirror what is published elsewhere,
then we will inevitably create synchronization problems. And there is no
reason to provide lists of IDs along with names that have been
normalized to some constraint, such as using only ASCII letters. We are
not providing a standard set of names for language, countries and
scripts.


Sorry, Doug, but this time I think the work you have done is badly
misguided (a rare occurrence).



Peter
 
Peter Constable
Globalization Infrastructure and Font Technologies
Microsoft Windows Division


More information about the Ietf-languages mailing list