apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: i18n on Win32
Date Sun, 19 Nov 2000 15:28:56 GMT
"William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:

> Here's the analysis,
>   We can port and drop in iconv-1.1, iconv-extra-1.1, and iconv-rfc1345-1.1
> by Konstantin Chuguev from FreeBSD.  License of sources is essentially
> compatible, but includes the advertising clause, requiring that we cite him
> and include the disclaimer (which is essentially our own
> disclaimer.)

(naive) perhaps the advertising clause is a legacy from the old BSD
license and he would be willing to "upgrade"?

>   The other/better alternative would be IBM's ICU package, but it isn't going
> to be a direct and simple thing, since I find no charset <-> charset funcs,
> only conversion into and out of Unicode.  The IBM Public License, of course, 
> is more compatible and doesn't contain the advertising clause.  I would also 
> put more faith into IBM and the ICU colaborators' efforts to have their tables 
> right, and correct and expand them very quickly.

>   Jeff, had you considered ICU when you started your i18n work?  If so, what
> were the shortcomings (e.g. the missing charset <-> charset functions) or
> did you find these functions?

I never considered ICU; I had never heard of it.  Code I'm familiar
with has all used iconv().  Importantly for Apache development,
iconv() was available and well-supported on enough platforms for me
already (OS/390, Solaris, recent glibc on Linux).  It is nice to use
iconv() on platforms which support it natively because administrators
can add support for their own special translations once and everything
works with it. 

>   Implementing xlate within ICU is probably no great challenge, and ICU is
> already ported to Win32, so does anyone care, or should I stay with
> iconv?

There is nothing particularly good about iconv() other than the fact
that on some platforms most everything uses it, making it is easy for
administrators to add support for special translations since adding to
the iconv() database instantly upgrades most apps.

On platforms where neither ICU nor iconv() is native, it probably
doesn't matter to the end user (unless one of them doesn't work well
or doesn't have an easy way for users to add tables or custom
translation logic).

Jeff Trawick | trawick@ibm.net | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message