Re: TR35

From: Antoine Leca (
Date: Tue May 18 2004 - 06:39:03 CDT

  • Next message: Andrew C. West: "Re: Vertical BIDI"

    On Friday, May 14, 2004 10:22 PM, Peter Constable wrote:
    > It is simply inadequate analysis of usage scenarios to say "an
    > order form contains formatted dates / numbers / currency that need to
    > be interpreted, therefore this document has a locale".

    Sorry, you lost me. I do not know what "usage scenario" are. But if "usage
    scenario" describes a workflow, if the workflow involve orders, and if the
    amounts can be written in ambiguous form, I would have thought that, _at
    some level of the modelisation_, some notion of locale might be present; and
    then that a realisation (I hope you get my vocabulary of specification
    right) might have an property "locale id" attached to the "order form"
    document. This was the scheme I had in hand. Of course, it results that
    "this document has a locale" is a shorthand.

    Nevertheless, I did not deny your analysis. Rather, I pointed that I my
    view, it would be wrong to think that "no document has a locale," which is a
    quite different thing.

    In the case it was not clear before, I agree that in most cases, they do

    > But if the <amt> record is *not* in a
    > neutral representation, then there are several other questions that
    > need to be considered regarding how the string was generated, and how
    > the receiver knows what was assumed by the authoring process.

    Regarding you example: I do envision very well an application that will tag
    the <amt>, and also the XML document, with some externally defined locale id
    (and I do not mean language here). And I also have already seen a pair of
    application doing similar things... Whether this is sensible or not is
    another debate entirelly: I just point out it could be done.

    >> And these files do
    >> include or refer locale ids and language ids, sometimes named one
    >> for the other BTW.
    > Just because someone called the two the same doesn't mean that the
    > notions are not distinct, and that it wouldn't be helpful for us to
    > understand that distinction.

    Again, I am lost: I did not say they are merged, just that some use the name
    of the former to design the latter. Now, I can accept they may be in fact
    the same thing, since I am not an expert of this field: just that for me,
    they appear as different for the moment (and the more I read in this thread,
    the more I stay on my initial idea that they are different.)

    >> And what you see as "internal to
    >> your process" is, to me, actually an usable, external, data.
    > If you consider it external, then it is because you expect others to
    > use what you put there, or you are using what others put there -- and
    > so it is indeed external.

    Yes, exactly.

    >> See my example,
    >> imagining it is a text processing file: deeply inside, I have found
    >> the locale id of the sender. Which was an hint, not the real data I
    >> would have liked.
    > If the document includes an ID that indicates the locale mode that was
    > set in the author's software when the author created that file, and
    > you wish to use that as a hint to set a processing mode on your end,
    > I have no problem with that; I have never said anything against that.

    This is what I missed.
    I claimed, this ID was considered (by me) as a locale tagging of the
    document (see above my full reasonment). I never claimed it was intended
    that way at the beginning, or in other processes, including the ones that
    will follow the one of recognition of the intended meaning.

    But in that particular process, it looked very much like a locale id tagging
    a document to me.

    > Rather, I'm saying that the conceptual model we have inherited from
    > the past is inadequate, and that we need to adopt a more
    > carefully-conceived model around which to design i18n platforms for
    > the future.

    This is starting to be interesting: we obviously will have quite of bit of
    "backward compatibility" (in the minds of the people) to deal with, won't

    > And it starts by understanding that while they may be
    > related, "locale" and "language" are conceptually two different
    > things.

    I never thought such a thing, did I?

    OTOH, I acknowledged your terse description of the question as being a very
    good thing (« ce qui se conçoit bien s'énonce clairement, et les mots pour
    le dire viennent aisément » --the well understood would be explained
    clearly, and the words to say it will flow easily-- sorry M. de Boileau for
    the bad English translation)


    This archive was generated by hypermail 2.1.5 : Tue May 18 2004 - 06:41:22 CDT