RE: Unicode <-> CJKV national encoding; supporting multi-lingualwebcontent

Andrea,

You are right about a lot of Java applications.  Many of them I suspect are
written because it is easier to develop cross platform code than in C/C++
and not necessarily for the i18n values.

What I am addressing is the existing C/C++ code that people want to
internationalize.  There are also people who prefer to also develop new
applications in C/++ as well.  This is very useful for applications that
have been MBCS enabled where that have added their own MBCS support.
Replacing it with Unicode support becomes very easy.

The reference to Apache problems was mine.  I think that you are too
ladylike to point out problems with the competition's designs.  ;-}

I figured out that this is code that I had to maintain to make it faster to
implement ICU for my clients.  By making it open source people can either
contact me because I wrote it, or use it themselves in which case I would
not have gotten the business anyway.  In either case we will have more
Unicode implementations which will make all of our lives easier.

Until ICU 1.5 I had to fix a lot of ICU code to make it really work
properly.  Now it is a very solid product.

Your bottom line hit me - EXPERIMENTATION.  Too much of this is just
experience.  Much of that is trial and error.  I think this is because it is
not so much a matter of knowing the answers but one of knowing the
questions.

My code gives people a frame of reference that they can start from.  For
example I implement xiua_strcmp where I compare all Unicode strings in
Unicode code point order.  It the user is transforming Unicode from one from
say UTF-8 to UTF-16, sorting sequences may matter.  They can like the idea
or not.  If they don't they can take it out.  However, at least they think
about the issue.

Just as valuable is the test code.  All i18n support modules should be unit
tested.  It is too difficult to test the support through the application.

Carl

Received on Thursday, 16 August 2001 22:13:54 UTC