Forum OpenACS Q&A: Response to Globalization
Greenpeace is making heavy use of a derivative of acs-lang. Bruno Mattarollo (currently on two days' holiday so he probably won't pop up here after all) has modified it to key messages to package and locale, rather than to language. Keying to package allows for the generation of translator pages on a per-package basis (rather than burying them in a system-wide sea of messages with no organization). Keying to package/page might be better in general but the current approach suits GP's needs just fine. Keying to locale rather than language allows for the use of different dialects (American English, etc).
Also "translation missing" messages are turned into a hyperlink to an "enter translation" page if the user has privs. I think this was part of the original acs-lang, but it's possible Bruno added it.
Only user-visible pages are being internationalized. Admin pages specific to GP as well as standard ACS admin pages aren't internationalized.
Lars Pind added a "trn" tag to the template system and implemented a simple "#msg_key#" replacement syntax similar to the "@tcl_var@" construct. This means that rather than tediously call "_" ( "[_ language_id msg_key]") and reference the result via @...@, you can just reference the key directly. I modified his first "trn" implementation to allow variable substitution, so you can use it (for instance) with multirow queries that pull message keys from the db.
I've done a bunch of work to track current language and nationality via smart URLs and (if the user has them enabled) cookies, but this is more specific to GP's needs than the previous two items.
It all works quite well. acs-lang caches a message-key/message pair, so it's fast. The problem, of course, is that there's one more layer in the mix. Tcl->Adp layout->message contents. What was aD's solution for ACS Java, Yon?
When all is said and done, Bruno's anxious to get his modified acs-lang back in the mix. It will take some work because to some degree it is specific to GP, and of course we would want some public discussion to see just how folks might want this to work in a more generalized context. My guess is that it will be late summer before there's time to do this, but I can't really speak for Bruno. Maybe he has Secret Plans to add more hours to the day and do it earlier :)
Lars's changes can go in at any time. He already started a thread on a new form of the "include" tag, and was going to add it to the tree. If this is a good time to discuss his "trn" and "#msg_key#" template extensions, let's do it. They can go into the development branch of the tree at any time.
In the GP case, then, pages are designed as Tcl->Adp layout->message entities. Standard OpenACS package pages aren't constructed this way. Should they be? Should the standard package Adp templates be simple Tcl->Adp entities as they are today, with alternative Adp templates made available as replacements?