The editors support this, yes...
... but the problem is with text manipulation systems, such as, say,
translation memory. The numeric codes don't "segment" properly and
sometimes generate erroneous mis-matches, which must be hand corrected. In
addition, how well do text search systems do with NCRs? I'd be willing to
bet that support is spotty, at best.
Lastly, I think that NCRs violate the principle of encoding plain text as
plain text. The point of Unicode is to give us a way to encode all text in
a single encoding. NCRs are a workaround that can help for now, but I'd
rather that pressure be exerted on product developers to support real,
unadulterated Unicode end-to-end. Then all of these issues disappear...
Addison P. Phillips
Senior Globalization Consultant
Global Sight Corporation
101 Metro Drive, Suite 750
San Jose, California 95110 USA
(+1) 408.350.3649 - Phone
Going global with your web site? Global Sight provides Web-based
software solutions that simplify the process, cut costs, and save time.
Rosenne To: "Unicode List" <email@example.com>
<rosenne@qsm. cc: "Unicode List" <firstname.lastname@example.org>, email@example.com
co.il> Subject: Re: Support for Multilingual Documents
At 22:48 05/12/99 -0800, Edward Cherlin wrote:
>At 10:57 -0800 1999/12/03, firstname.lastname@example.org wrote:
>>Not to mention the annoyance/impracticality of having to manipulate,
>>maintain, translate, and otherwise use files that consist of an endless
>>stream of NCRs.
>What? We can't write a little utility to translate between UTF-8 and
>NCRs while we wait for some Web page design program to implement it
There some HTML editors in common use that do it automatically if your
default is not English. The author may not even be aware of it, since the
page will display correctly on his computer and those of his neighbors.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT