Re: TR35

From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Wed May 12 2004 - 03:33:25 CDT

  • Next message: Benjamin Peterson: "Re: Disunifying CJK (was: Re: Everson-bashing)"

    On Tuesday, May 11, 2004 6:59 PM, Philippe Verdy va escriure:

    > From: "Carl W. Brown" <cbrown@xnetinc.com>
    >> Expats break the locale model anyway. The problem is that we use
    >> country as both a language modifier and a location.
    >
    > From past comments I read here, it is understood now that locale
    > identifiers used to select languages contain a country/territory code
    > only as a legacy way to select language variants.

    I disagree. You are seeing the locale identifiers just in the context of
    language tagging. It is not its primary use, nor is it the historical one,
    neither the most proeminent.

    Main usage for locale ids nowadays is to resume all the i18n settings in an
    environnement. And certainly i18n settings depends on the language, but also
    on the territory you are in. When you cross the border between Italy and
    Slovenia, or between Ontario and New York, the most striking difference is
    not the orthography or the pitch, but rather the coins.

    Then, main variations within a language have been historically identified
    with countries. This might be related to the common practice from States to
    affirm its independance by drawings laws on this respect. It might also be
    related to the current state of orthographies between both sides of Atlantic
    Ocean for some important languages (and even more when we consider the
    situation 20 years ago.)

    Whether this perception is correct as "first tie", or if it should be
    replaced by another (which one?), I cannot say. What is certain is that it
    is not universal.

    Now, the two points (locale identifiers characterizes language and
    territory, and languages are usually partitioned with territory information)
    did interfere during the last decade (certainly RFC 1766 and 3066 might be
    related to this process.) Carl's point, and I believe he is correct, is just
    that these two meanings should NOT be mixed. And that when we spoke about
    locales, the relevant one is the first one (the part you snipped.)

    > This code is meant
    > to designate the language variant as spoken in that area, but not for
    > identifying a location.

    I am very sorry, but if in

        LANG=fr; LC_MONETARY=es_ES

    you consider that _ES above is a language variant of Spanish Castilian as
    different from Hispanoamerican, you are deeply wrong.

    > However the set of variables in POSIX is not rich enough or tweaked,
    > because a single LC_ALL variable can override all these variables.

    You are completely distording the model here.
    The normal setting is as above: LANG, then LC_xxx where LANG is inadequate.
    LC_ALL is an alternative way, that allows a _supplementary_ level. This is
    very useful when you have to temporarily override the setting (please
    remember that POSIX is initially console-oriented), because this way you can
    with not too much keystrokes specify a desired behaviour for a given action,
    like it

        LC_ALL=POSIX cc myStrangeProgram.c

    > This means that all settings what can be defined in a locale must be
    > definable with the same identifier.

    No, it does not _mean_ that. No obligation here.
    Anyway, the general way to implement the standard C setlocale() is just
    that, an identifier (not even human-readable, that is not its point) that
    groups all settings.

    If a Taiwanese sets in .profile

        LC_ALL=zh_TW; export LC_ALL

    and then complains the locale model is wrong, everybody, you included, will
    tell him that what is primarly wrong is her setting.

    > Now a good question is: can all settings in locales be selective
    > enough to allow specifying correctly the possible values.

    Define "possible": are you writing about the set of already described
    locales? (the only useful, as Carl wrote, en_GU is essentially non-existent;
    same for 0x180c)
    Or about all the potential possible values, including pro_QQ for Occitan as
    used within the Chancellery of Toulouse?

    > Is the POSIX syntax enough for them?

    Since it exists an extension to it in ISO/IEC TR 14652, answer here is
    probably no.

    Antoine



    This archive was generated by hypermail 2.1.5 : Wed May 12 2004 - 04:11:36 CDT