Here are some random comments about my experiences with i18n for
ACS 3 and 4. They won't make too much sense until you've looked at the patch kit
I made, but I hope they can be helpful when you think about some i18n issues. There's more links to notes at
http://imode.arsdigita.com/i18nYou can basically break things down into three pieces:
1) character set encoding issues - you should store everything in
the database is unicode, and AOLserver uses Unicode internally.
You then need to make sure you convert to the appropriate encoding
when you output the pages to the browser.
AOLserver has a couple of
mechanisms for this. The one you mention above, setting the "charset" attribute in the MIME type, is usually the most convenient. You can
also set it using the ns_startcontent command.
Handling user-submitted input is the other half of the problem -
your notes mention using the ns_formfieldcharset mechanism. That
will usually work, but usually you know beforehand what to expect
anyhow because the user is submitting a form you just sent to them,
and you know what encoding you sent it in.
The one thing in my patch kit for AOLserver that might be of help
is that I redefined ns_getform to take an optional "encoding"
argument, and it can be used to convert the user-submitted input
form the specified encoding. You could modify ad_page_contract to
take an optional encoding argument, and to try to look for the
charset cookie using ns_formfieldcharset.
2) Formatting numbers, dates, etc, in a localized way.
There are some tcl utility functions in the acs-lang package, such as lc_numeric, or lc_time_fmt,
which will handle a variety of number and date formatting patterns. It has
a small amount of locale data gleaned from Linux localization tables (for US, UK, Spain, Germany France) which could be added to on. I am not sure where the script that converts unix locale files to
Tcl is though. The ArsDigita London office may still have it someplace.
3) Message-catalog facility.
Like GNU gettext, the acs-lang package provides a catalog for storing
short message strings and their translations. So you can create
message catalog files containing translations of all the strings that you would
otherwise hardcode into your source code, and assign them
symbolic names. There is also a hook to the ACS 4 templating system
to define a "TRN" tag which lets you reference the message catalog
in an .adp page.
