Re: ISO 639 "duplicate" codes (was: Re: Ligatures in Turkish and Azeri, was: Accented ij ligatures)

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Jul 12 2003 - 17:45:35 EDT

  • Next message: Philippe Verdy: "Re: Ligatures in Portuguese, French (was: ... Turkish and Azeri)"

    On Saturday, July 12, 2003 4:17 PM, Jony Rosenne <rosennej@qsm.co.il> wrote:

    > What has "iw" to with Hebrew?
    >
    > I wasn't involved with the change, but I'm glad it was done. Java and
    > other systems probably still use it because they never bothered to
    > check the latest version of 639. I know for certain that this was the
    > case with one of the major computer vendors.

    In the case of Java, I don't think so. Sun has certainly maintained the
    language code simply to avoid breaking existing localizations to
    Hebrew of Java-written software, waiting probably for a better way to
    locate locales than the fixed "locales path resolution algorithm" which
    is part of its core Classes since the beginning.

    As long as Java core classes will not use a locale resolver that allows
    tuning the resolution algorithm used to load resource bundles, while
    also maintaining the compatibility with the existing softwares that
    assume that Hebrew resources are loaded with the "iw" language code,
    Sun will not change this code.

    In IBM ICU4J, there is such an extended resolver, but Sun takes a
    long time to approve such proposals, and have it first accepted,
    documented, balloted and voted in its JCP program. Of course
    Java already includes some parts of ICU, but other things are in
    ICU4J are difficult now to integrate in Java, simply because IBM
    forgot to modularize ICU so that it can be integrated slowly.
    Accepting ICU4J as part of the core is a big decision choice,
    because ICU4J is quite large, and there are certainly developers
    for Java that would not accept to have 1 aditional MB of data and
    classes loaded in each JVM (particularly because the integration
    of ICU would affect a lot of core classes for the Java2 platform
    now also used for small devices).

    For example, it is impossible to integrate the ICU's Normalizer
    class in Java without also importing the UChar class and all its
    related services for UString, such as transliterators, and
    advanced features such as the UCA tailoring rules run-time
    compiler. Some ICU open-sourcers, as well as its users seem
    to think now that the modularization of ICU is an important but
    complex project.

    -- 
    Philippe.
    Spams non tolérés: tout message non sollicité sera
    rapporté à vos fournisseurs de services Internet.
    


    This archive was generated by hypermail 2.1.5 : Sat Jul 12 2003 - 18:44:40 EDT