Forum OpenACS Q&A: i18n work update: We'll soon be committing the first chunks
required part of ACS Core, and integrating it into the templating
system, the request-processor, and the APM parameters system as
Shortly after the 4.6 branch has been cut, we'll commit this into
the OpenACS CVS tree on the trunk.
Once that has happened, you can all start participating by moving
language text out of the pages and procs and into the message
catalog. We'll provide you with a short document that tells you how
to do that.
In the meantime, we'll be adding more sophistication to the local
negotiation, such as settings per site node, URL rewriting that
allows us to have the locale as the first part of a URL, and lots of
If you had an option for locale extension, e.g. q-and-a-fetch-msg.locale.tcl instead of /locale/bboard/q-and-a-fetch-msg.tcl, then one could use relative links between same content in different languages.
It should be easy to construct a language-switch page that redirects to the page it was referenced from with a different language prefix, possibly making it unnecessary to do relative links between different languages.
Some random questions / remarks:
Are you planning to enable both language _or_ locale information in the smart url system, e.g. by supporting both the urls /en/bboard/foo and /en-gb/bboard/foo? (I hope this is the correct distinction between the meaning of the words language and locale)
If yes then I'd like to vote for the /en-gb/ syntax instead of the more common /en_GB/, just for aesthetic reasons and in order to conform with the URL style of the rest of openacs.
When working on acs-lang, did you base your work on gp-lang from greenpeace, and if yes did you consider splitting the key into two separate fields in the database? As far as I remember the new style message keys introduced in gp-lang have always two parts, and it occured to me that having two separate fields would make a lot of operations on the messages easier (this is purely theoretical though).
Wouldn't there be problems with en-gb? How can the server tell that this is a locale-prefix and not part of the URL?
We'll get to it in a bit. This is not critical for committing these changes. The idea is to commit the stuff that's necessary for package translation. Then we can make the core locale negotiation process more sophisticated at a later point.
Increasingly its looking like I may need to be.....
Is therea description/doc or anything describing whats already there and in particular what was done for GP?
I have a version of Don's code with the greenpeace specific stuff removed (it only looks for the /en/ syntax yet), which may be useful as a starting point.
So this might still be a cause for confusion but not as serious as if it would be when all top-level two-letter URL's were disabled.
Or even say that something like "/_g" are used for smart URL's connected to globalization and other underscore prefixes could be used for smart URL's in connection with other modules?
Yes, I've thought about something like that, but it's ugly! :)
I don't know what the best solution is here.
/locale=en_US/foobar? ... we can have an equal sign be part of the URL, no?
You're probably right about that. Putting a "=" won't help much though -- it'll still be ugly.
Another way might be to use the "~" as a prefix. It probably won't be used with OpenACS, but people are used to seeing it in URL's...
We have committed our changes so far to the acs-lang package and the changes that we have made to OpenACS core. The CVS commit comment for acs-lang was:
adding namespaces to the TCL API, adding new procedures for extracting keys from adp pages and parsing keys embedded in text, adding a translation web UI that was used at Greenpeace (at www/admin) and making it work with PostgreSQL, moving the old pages under www to be under www/admin/test, making the lang_messages table use locale rather than language, added upgrade scripts
The most important changes to OpenACS core include substituting #package_key.message_key# occurencies in adp pages with message lookups and setting up ad_conn locale in the request processor.
We are now working on committing Jeff Davis's magic script that can suck out translatable text from adp pages and replace them with message catalog lookups (yes I know, it's amazing, but it works!). As soon as we have committed this script we will encourage package owners to run those scripts on their packages and then test and go through pages and manually do any missing message lookups. We have started writing an I18N developers guide and you can find a snapshot of it here.