At 10:52 AM -0500 97-02-10, Alain LaBont/e'/ wrote:
>At 06:18 97-02-10 -0800, unicode@Unicode.ORG wrote:
>>We have a problem with the language codes recognised by Web browsers.
>>
>>The standard mostly widely used in the Internet to specify language codes
>>is ISO 639 - "Codes for the representation of names of languages" (see RFC
>>1766 and RFC 2070).
>>
>>Some years ago, the ISO 639 Maintenance Agency amended the standard, adding
>>three new language codes:
>>
>> Inuktitut iu
>> Uigur ug
>> Zhuang za
>>
>>and modifying three existing language codes:
>>
>> New code Old code
>> Hebrew he iw
>> Indonesian id in
>> Yiddish yi ji
>>
>>The problems caused by the modification of existing codes have been
>>discussed previously, as have the pros and cons of the ISO 639 standard and
>>of the various competing standards and schemes. I don't want to waken those
>>particular dragons.
>>
>>What I want to raise is a very particular problem: Two of the browsers that
>>handle Hebrew (maybe this should read "The two browsers that handle
>>Hebrew"), recognise the old language code ("iw") but not the new one ("he").
>>This is very worrying. I hope the vendors will speedily enhance their
>>products to recognise both the old and new codes.
>>
>>This leaves us with a very specific problem in regard to the IUC10 Web pages
>>at <http://www.reuters.com/unicode/iuc10>. Should we use the old code for
>>Hebrew, so that the browsers recognise it and display it, or the new one so
>>as to encourage the vendors to fix their browsers, with the disadvantage
>>that the text won't display correctly? We have deferred publishing the
>>Hebrew, Arabic and Yiddish texts until we know how to resolve this (and some
>>other problems).
>
>
>Problem is that some old codes collide with new ones, as we have seen, so if
>you choose a partial support or one of the other, you create a new
>non-normalized standard. I don't know the solution to this. That is a mess
>created not so wisely by the standardizers. But after all, in last analysis,
>since the new one has created the defects, I would tend to recommend using
>the old one, adding the new codes to it ): Sorry if that does not make sense
>to some people.
>
>Alain LaBonté
>Québec
The difficulty with such type of coding is legacy versus the
standardization process.
How long has an "old" code been in use? How many documents are affected?
How difficult is it to "retrofit" these documents? Taking these questions
in consideration, may help solve the issue discussed here.
On the other hand, one can only assume now that the new codes were adopted
for valid reasons :-) By using the "old" code, one says that the
standardizers should not have changed it. But, THEY DID!
Standardization is a consensus process which normally gives enough time to
react to proposals. If one agrees with the standardization process, one
should then adopt modifications made to the standards. Otherwise, why
change the standard?
By continuing the use of "old" codes, one is perpetuating a situation that
may need to be corrected in the future. One should also say to the
Standardizers: DO NOT reassign the "old" codes or give a long period of
time to ensure that the "old" codes become obsolete. I believe this can be
done in this case since the "old" codes have not been reassigned.
I would therefore recommend to use the "new" codes.
Jean-Yves Fortin (jyfortin@tsacc.ic.gc.ca)
Secrétariat du CCCNT - TSACC Secretariat
[Conseil consultatif canadien sur les normes de télécommunications
Telecommunications Standards Advisory Council of Canada]
Webmestre/Webmaster : http://www.tsacc.ic.gc.ca/
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT