From: Philippe VERDY (verdy_p@wanadoo.fr)
Date: Tue Apr 05 2005 - 15:06:20 CST
There's no error in Unicode. The standardized names are just used for references across documents related to the standardization process. The actual usage is given in the footer notes that are added in the PDF/printed version of the Unicode charts.
Consider those standardized names only as symbolic.
But nothing prevents developping other custom lists of character names, including actual translations.
So create a list of character names translated into Tamil, and make these names displayed in your interface.
If you really want to help the Tamil community, take the time to create a translation into Tamil of the whole (or most) set of Unicode/ISO/IEC 10646 standard names.
My opinion is that Unicode should keep these names unchanged, but may help the community by developing a non-normative, but really informative, translation into English of the normative technical names.
Note that English and French character names are also standard part of the ISO/IEC 10646 standard. May be there are errors too in the French names that are part of the normative French version of ISO/IEC 10646. In that case, having a secondary list of French names that would include corrections would be helpful too.
To develop such list, one just needs to specify the alternate names that differ in one language or locale usage. These names will then substitute those names found in the default list of normative English and French Unicode/ISO/IEC 10646 character names.
These character names translations could fit very well within the CLDR database, which is not normative but gives lots of useful hints considered as best practices unless corrections are applied. What do you think of this idea?
So why not a new repository for those character names lists?
> Message du 04/04/05 20:24
> De : "Sinnathurai Srivas" <sisrivas@blueyonder.co.uk>
> A : unicode@unicode.org, "William J Poser" <wjposer@ldc.upenn.edu>
> Copie à :
> Objet : Re: Tamil Aytham and the role of Unicode names
>
> I'm not discussing about errors and wheather it was made by ISCII or UC. I'm
> only discussing about the refusal to correct the errors in the correct way.
> I'm discussing how to deal with these matters for the future.
>
> I read the UC's rule about anotating. It clearly states to deal with it in
> such a manner that error is corrected and continuity is supported.
>
> At present the solution is continuity is supported at with the absent of
> correcting error.
> There is no justification for refusing to correct properly.
>
> The definition is wrong. The correction still places errornous definition as
> primary. All the argument of strings are not worth a cent. UC need to look
> at this with deep breath.
>
> Current definition misleads developers. This is a fctor far worse in dimage
> to Unicode than continuity. Ofcourse continuity is essential, but should be
> kept in perspective.
>
> Consider a software or hardware manufacturer, who made some mistake and are
> refusing to correct them. Can you imagine the reaction?
>
> If a problem can be solved it should be solved. Only situation I can think
> where it would become problematic is if a code point is shared by many
> languages and are all bickering about what to call it. Please resolve this
> issue.
This archive was generated by hypermail 2.1.5 : Tue Apr 05 2005 - 15:08:07 CST