At Wed, 11 Jan 2006 22:18:04 +0900, Nick May wrote:
>
> [...] Imagine telling 1 in a hundred
> Americans they can't use their own name on their bank account...
Actually, a great many early Americans (including my mother's family)
were forced to change the their names when coming in through Ellis
Island, for the "technical limitation" that the other Americans
wouldn't be able to pronounce it. Some people probably liked the
change, some likely didn't care, and many were no doubt outraged.
The early Unicode versions took the Ellis Island approach - we
(meaning *you*) need to make sacrifices to live together. This was
insane, since the countries most affected weren't refugees with no
choice, they were proud and strong cultures that would simply *never*
have accepted the early Unicodes. No doubt, however, some individuals
in Japan did like the early Unicode proposals and told the designers
"we can live without those characters," leading to confusion and
ultimately irrational debate.
Unicode has changed a lot - it has all the characters and room to add
more, and is continuing to do so. It has solved many technical
problems, both old as well as new issues arising from the merging of
languages. Even the most common current complaint:
> My main practical objection to UNICODE now - UTF-8 at least - is that
> it is fat-arsed. The Oompah Loompah of encodings. Want to send data
> to keitai? You will send FAR fewer bites with sjis.
has been addressed by Unicode technical report 6 (which is especially
efficient for Japanese). Note wireless connections are getting
increasingly faster and cheaper, and recoding/compression at the
gateway solves this problem anyway.
Unicode is also becoming the industry standard, as it is the native
encoding of Windows, OS X, Linux desktop environments, new programming
languages and new standards. There really isn't any alternative with
the maturity and support.
Which is why, to people working successfully everyday with Unicode,
uninformed complaints such as "it doesn't have character X" and
irrational complaints such as "it wasn't designed with us in mind" are
just unhelpful. If something like TRON genuinely is superior I'd like
to know why, and like to see how it addresses all of the Unicode
standards and technical reports. Then if it can gain the software
support momentum needed it may be worth considering, but at this point
it would need to be clearly and significantly superior to warrant the
effort of switching.
--
Alex
Received on Thu Jan 12 04:39:22 2006