Forum OpenACS Q&A: Internationalization of OpenACS 4.5

this might help you although we are using latin1...

https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=00044O

Besides compiling postgres with unicode support also make sure that your oacs database is actually unicode encoded, e.g. with createdb -E unicode yourdbname. (psql -l lists all databases and their encoding).

The following is rather speculative because I never tried that myself: if you need specific sort orders in postgres then take care to set the locale while doing initdb (initdb is called right after installation, so this cannot be changed later without destroying all your databases). E.g. after installation do a "LC_ALL=de_DE initdb".

Allegedly this slows down postgres quite a bit, and I wonder if it works with OpenACS at all. There were some issues with tree_sortkey requiring sort order of LOCALE=C, but I guess since this is not character based anymore it is not a problem anymore (Don?).

For multilingual sites there is the acs-lang package, which provides message catalog functionality. It is far from finished (lots of UI missing), but since there is a lot of interest here this is propably going to be improved sooner or later.

Date formatting is often hard coded in the toolkit with the plpgsql to_char() function (in postgres). I am going to grep for the most commonly used formats and will suggest to write some centrally defined functions instead (really soon).

string_row like 'foo%'

won't use the index on string_row if you've enabled locale support.  The problem is that indexing this relies on being able to translate the "like" into roughly:

string_row between 'foo' and ('foo' || -the-biggest-character-)

unfortunately there's no simple way to know what "the biggest character" is if locale support is enabled.

Regular operations like "string_row = 'foo'" can use an index on string_row.

So for "normal" code, this isn't a big deal.

The current PG tree_sortkey implementation uses varying bitstrings and is fully indexed regardless of locale support.  So I don't think enabling locale support will seriously impace the performance of an OpenACS 4.5/PG site.

I tried the PG version some time ago and ran into an error or two while clicking through the links on the index page of acs-lang. But then again, the functionality I found broken may have been some of the not-so-essential parts for getting a basic multilingual site going.

Sooner or later, depending on the nature of the message catalog UI (which I've read exists but not yet found in PG), I'm planning on translating at least the modules I personally use into Swedish.

Will it require much work on the level of the individual modules to run a site in a language other than english?

The info in the above discussion is on the right track.

I have posted some messages before with copies of
the tcl init file needed to set the default
character set and MIME types.

I will try to collect that stuff up on a single web page
that can go someplace easy to find (like on openacs.org).

See
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002Uv

Example config file (acs 3)
http://www.ai.mit.edu/people/hqm/openacs/acs3-pg.tcl

Kana conversion routines (half width to full width)
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0002T4

There may be some issues with .adp pages -- the issue was that
AOLserver's adp parser would assume the .adp source file
was encoded as UTF8. The workaround was to modify ACS's
adp parsing code to explicitly load the .adp file source
using a specific encoding (such as Shift JIS) based on the
defined MIME type for .adp files, and then pass the resulting
string to AOLserver's adp parser using the -string option.

The acs-lang package contains a file with a set of patches which
tweak the request processor. I am not sure if those patches
are now merged in with the ACS acs-tcl core procedures, or if it
is still necessary to apply them manually when installing the
acs-lang package.