From: JFC (Jefsey) Morfin (jefsey@jefsey.com)
Date: Tue May 17 2005 - 04:50:29 CDT
At 22:22 16/05/2005, Philippe Verdy wrote:
>If something is wrong here, there's something not documented in ISO15924
>(the list of characters that are considered part of the script).
Thank you for this. This is the very point I need to "debug" for several
months. A human being can more or less understand "Latn". A computer needs
a charset. In calling me names, some may add to the humanity's patrimony
but will not address the problem.
My understanding is that the proposed solution - but it should be worded
out and clarified on several points - by some (I feel there is also strong
opposition) is to say:
1. we have languages documented in ISO 639
2. we have political influence on languages, commercial contractual issues
and user associations support - to quote a few - on a country basis and ISO
3166
3. we now have a script list with ISO 15924, never mind if it is much
precise or not, it is a good level iteration
4. let stabilise an ISO 15924 - ISO 639 - ISO 3166 formal relation, as a
common tag, and let use it consistently every where, including defining
locales.
5. this way when we quote the tag, we quote the locale. When we have the
locale we have all the information you call for (provided the way to to
draw letters, but also icones, etc. is included in the locale). At that
time a "script" will become a synonym for a "dynamic locale" (what your
computer should have loaded as a locale to accomplish the task ahead).
If this is the Unicode final idea, it looks a very good idea on the paper.
But first it should be spelled out so everyone supporting more or less the
idea has the same point of view in here, at ISO, at the IETF etc.. Then
debates, on what is missing or not, should not be on specific situations
(this language, vs. this script) but on the locales XML/ASN.1 supporting
scheme. In the meanwhile transition should be documented because the work
is important and will take years while other parallel efforts (TBX, CRC,
IDN, etc.) may add to it and existing daily usages can be destabilised.
There is then - but this is not the place - issues of methodology and of
consistency with usage applications systems, and the user
acceptance. Probably in many different areas. Also a problem coming from
the character oriented Unicode basis is to insure a continuity with sounds,
icons, gestures and procedures. Another problem where Unicode/CLDR can be
in a good position to contribute is normalised languages or whatever the
name being used for the human/machine compatible/referenced languages or
constrained for a purpose (like Basic English)
jfc
This archive was generated by hypermail 2.1.5 : Tue May 17 2005 - 10:13:56 CDT