Forum OpenACS Q&A: Response to OpenACS Internationalization

Collapse
Posted by Tilmann Singer on
I have a similar problem with german umlauts, here is a summary of some tests (with umlauts instead of Chinese characters).

Aolserver version is always AOLserver/3.2+ad10.


> 1. Test PG directly. Create a table with a
> "text" field, then insert and retrieve Chinese
> characters. Make sure that works.

That works. Postgres has Multibyte enabled and the database is in
UNICODE encoding (according to encoding).


> 2. Write a simple Tcl script that retrieves rows
> ALREADY IN THE TABLE, ns_write them,
> and see if you get Chinese characters out.

Works both with nsd76 and nsd8x for me.

Writing posted values into a file: works with both.

Sending mail with ns_sendmail always works (posted values, read from
db, read from file) with both.

Reading a file from the file system with umlauts in it and storing
its text in the db: works with nsd76, fails with nsd8x.


So they only place where characters get translated wrong seems to be
on the aolserver->postgres path when using nsd8x.


> (try with nsd76 and nsd8x - 76 is much better
> for OpenACS in general because Tcl 8x has
> memory leaks associated with regexps).

Somewhere at arsdigita I read that those issues are now resolved and
everybody should use nsd8x. They will eventually stop support for
nsd76 - e.g. ns_cache only works with nsd8x.

Unfortunately there seems to be no other alternative than to use nsd76
right now if you need a non US encoding.


Is it safe to say that according to the tests above it is an issue
with the nspostgres driver?


> I know that one set of bug fixes for PG 7.0.3
> involved internationalization. I suggest
> downloading and installing that with the right
> switches, for starters.

Tried it, same troubles. (PostgreSQL 7.0.3 on i686-pc-linux-gnu,
compiled by gcc 2.95.2)