From: JFC Morfin (jefsey@jefsey.com)
Date: Mon Apr 14 2008 - 17:27:09 CDT
Dear Asmus,
I am afraid there is a misunderstanding. Unless there is a JTC1
supplement I did not considered, Annex E (normative) of ISO/IEC
General Directives says :
(E.3) "International Standards are published by the ISO and IEC in
English and in French (and sometimes in multilingual editions also
including Russian and other languages, expecially in case of
terminology). These versions of a given International Standard are
equivalent and each is regarded as being an original-language version.
"It is advantageous for the technical content of a standard to be
expressed both in English and in French from the outset of the
drafting procedure, so that thise two versions will be studied,
amended and adopted at the same time and their linguistic equivalence
will be insurerd at all times (See also the ISO/IEC Directives, Part
2; 2001 4.5) - I suppose it is 4.3 from the copy of the document I have (?).
Annex SP (normative) SP.2.3. accepts that texts are not prepared in
parallel (however it notes the aiding comprehension issue).
Obviously, this raises the question of Unicode being chosen as a
reference by the IETF for RFC 4646 and IDNA. As you note it, Unicode
has introduced average-English speaking user friendly solutions. The
problem is that these solutions are no part of ISO 10646 both
versions. This raises polynymy issues both in tables and in using
tables, i.e. languages, and therefore thinking.
jfc
At 21:54 14/04/2008, Asmus Freytag wrote:
>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 - 17:30:42 CDT