LANGUAGE TAG REGISTRATION FORM

Michael Everson everson at evertype.com
Fri Apr 11 18:52:59 CEST 2003


At 09:03 -0700 2003-04-11, Mark Davis wrote:
>re Michael's message:
>
>>  Is there a distinction between az-Latn and az-Latn-AZ? If so, what is
>>  it? If not, then only one tag is required in the language-tag
>>  registry, surely.
>
>Is there a distinction in orthography between each pair of the following?

Your answer is "No", then.

>Unknown, yet 3066 permits all of them, since it is better to be safe than
>sorry.

That is NOT why 3066 does what it does. 3066 extends 639 by adding 
additional codes to represent the names of languages.

>  > >4. Using the country code to distinguish orthographies is *not* a new
>>  >concept; RFC-3066 permits that with *any* combination of ISO 639 code.
>>  >5. Why should the Azeri with Latin script be permitted fewer distinctions
>  > >than English or other languages?

Because you are asking for a bunch of bogus busywork duplicate 
registrations in order to serve the problems some software has and I 
find that objectionable. We are NOT going to encode;

>en-AF, en-AL, en-DZ, en-AS, en-AD, en-AO, en-AI, en-AQ, en-AG, en-AR, en-AM,
>en-AW, en-AU, en-AT, en-AZ, en-BS, en-BH, en-BD, en-BB, en-BY, en-BE, en-BZ,
>en-BJ, en-BM, en-BT, en-BO, en-BA, en-BW, en-BV, en-BR, en-IO, en-BN, en-BG,
>en-BF, en-BI, en-KH, en-CM, en-CA, en-CV, en-KY, en-CF, en-TD, en-CL, en-CN,
>en-CX, en-CC, en-CO, en-KM, en-CG, en-CD, en-CK, en-CR, en-CI, en-HR, en-CU,
>en-CY, en-CZ, en-DK, en-DJ, en-DM, en-DO, en-EC, en-EG, en-SV, en-GQ, en-ER,
>en-EE, en-ET, en-FK, en-FO, en-FJ, en-FI, en-FR, en-GF, en-PF, en-TF, en-GA,
>en-GM, en-GE, en-DE, en-GH, en-GI, en-GR, en-GL, en-GD, en-GP, en-GU, en-GT,
>en-GN, en-GW, en-GY, en-HT, en-HM, en-VA, en-HN, en-HK, en-HU, en-IS, en-IN,
>en-ID, en-IR, en-IQ, en-IE, en-IL, en-IT, en-JM, en-JP, en-JO, en-KZ, en-KE,
>en-KI, en-KP, en-KR, en-KW, en-KG, en-LA, en-LV, en-LB, en-LS, en-LR, en-LY,
>en-LI, en-LT, en-LU, en-MO, en-MK, en-MG, en-MW, en-MY, en-MV, en-ML, en-MT,
>en-MH, en-MQ, en-MR, en-MU, en-YT, en-MX, en-FM, en-MD, en-MC, en-MN, en-MS,
>en-MA, en-MZ, en-MM, en-NA, en-NR, en-NP, en-NL, en-AN, en-NC, en-NZ, en-NI,
>en-NE, en-NG, en-NU, en-NF, en-MP, en-NO, en-OM, en-PK, en-PW, en-PS, en-PA,
>en-PG, en-PY, en-PE, en-PH, en-PN, en-PL, en-PT, en-PR, en-QA, en-RE, en-RO,
>en-RU, en-RW, en-SH, en-KN, en-LC, en-PM, en-VC, en-WS, en-SM, en-ST, en-SA,
>en-SN, en-SC, en-SL, en-SG, en-SK, en-SI, en-SB, en-SO, en-ZA, en-GS, en-ES,
>en-LK, en-SD, en-SR, en-SJ, en-SZ, en-SE, en-CH, en-SY, en-TW, en-TJ, en-TZ,
>en-TH, en-TL, en-TG, en-TK, en-TO, en-TT, en-TN, en-TR, en-TM, en-TC, en-TV,
>en-UG, en-UA, en-AE, en-GB, en-US, en-UM, en-UY, en-UZ, en-VU, en-VE, en-VN,
>en-VG, en-VI, en-WF, en-EH, en-YE, en-YU, en-ZM, en-ZW

Because to do so would be idiotic. 3066 lets you add country codes in 
order to make LINGUISTIC distinctions, not to perform kludges for 
software that screwed up the way it handles languages and locales. 
en-GB and en-US may be there because they are in fact different. 
az-Latn and az-Cyrl are different. az-Latn and az-Latn-AZ are the 
same thing.

We aren't registering en-Latin-GB in addition.

>I can understand your concern. Well, among languages we need to make at
>least the distinctions that Windows and others make; we have to be able to
>interwork with major platforms. If the end goal is to extend 3066bis to
>permit the equivalent of:
>
>5. <iso_639_code> "-" <iso_15924_code>
>6. <iso_639_code> "-" <iso_15924_code> "-" <iso_3166_code>
>
>then it does no harm to have the additional registrations.

Bull. It takes time and effort on my part, on the part of IANA, and 
on the part of all the people who AREN'T Microsoft and whatever 
"others" you refer to to weed through the mass of duplicate 
registrations in order to determine what the unique entities are.

>If we can only
>get az-Cryl and az-Latn registered, or if the end goal for 3066bis will not
>permit both #5 and #6, then we would probably be forced to define our
>language codes as "based on" RFC 3066, but not identical.

Or you could alter your software and make it work properly with 
language codes and locales.

These codes are to encode language distinctions, and are NOT intended 
to become the catch-all for locale identification. The point is, 
locale specification has not been done correctly, and it should not 
be on the entity-coders to fix it. It should be on the people who 
have botched their locale identification structures.
-- 
Michael Everson * * Everson Typography *  * http://www.evertype.com


More information about the Ietf-languages mailing list