Re: VS: "French+" support by Unicode

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Mon Apr 14 2008 - 14:54:30 CDT

  • Next message: JFC Morfin: "Unicode normative value [was. Re: VS: "French+" support by Unicode]"

    On 4/14/2008 11:00 AM, JFC Morfin wrote:
    >
    >> The French version is a translation of the English version and - as
    >> such -
    >> it is not subject to the same level of scrutiny.
    >
    > This is a mistake.
    > (1) a version is not a translation. It is a version. If its content is
    > non reviewed translation the Chair is at deep fault, because he
    > endorses texts he does not know, and because most probably (this is
    > the purpose of the bilingual publication) there are unclarities which
    > have been found in the English text that have been translated in a way
    > the English has not benefited.

    That's the reason people actually familiar with the way 10646 is produce
    keep commenting on your claims: There's no substantive endorsement by
    the working group of the contents of the translations, therefore,
    calling these versions is an inherent misrepresentation.

    > (2) This is why I say that - if the translators are good, and I
    > suppose they are - the French version is necessarily more advanced
    > than the English version. And this is abnormal.

    In the case of 10646, the character names in the translations are not
    subject to the same stability guarantees and restrictions as those in
    the original - making the translated names not suitable as formal
    identifiers. While this may make them more user-friendly to human
    readers, the necessarily have a different status.

    >> Since it cannot have any
    >> normative information beyond that of the English version, it would be
    >> wrong
    >> to use it as the base for any further translation, because this could
    >> lead
    >> to errors in interpreting interpretations.
    >
    > French and English versions are legally equally normative.

    Well, they can't be used that way in practice, because of the fact that
    "English" character names are guaranteed to be suitable as identifiers,
    while translated character names are not so guaranteed. For example, the
    set of allowed characters in the names is carefully restricted in 10646,
    so that it does not contain characters that cannot be readily used in
    identifiers in most programming languages (after removing/substituting
    space and '-'). The French names use single quotes and other features
    which prevent these names from being readily used as identifiers in many
    if not most such languages.

    This is not a defect of the French translation, as 10646 specifies that
    certain restrictions don't apply to translations, but it prevents
    translations from being 'equally normative' unless they also contain the
    English character names, for example.

    The English character names, are acknowledged to be formal identifiers
    of a somewhat arbitrary, but stable nature. They are known to not alway
    represent the most user-friendly designation of a character, and in
    fact, one would need to use a regional flavor of English to get the most
    user-friendly designation for certain characters, because usage and
    conventions disagree.

    The problem is real, but thankfully rather limited, however, there have
    been occasional suggestions that the formal nature of the character
    names should be recognized by creating a translation of character names
    for average English speaking users; to be used when usage as identifiers
    is not intended. However, so far, the problem has been handled by
    providing various user-friendly aliases (in the Unicode Standard).

    A./



    This archive was generated by hypermail 2.1.5 : Mon Apr 14 2008 - 14:58:01 CDT