I would like to see the current translational effort integrated better, as I need to create a Danish language Wiki.
It appears that most strings are protected with a "T()" call, but that the strings database is currently just read as a hash in misc/trans.pl. I have so far put this directly in wiki.pl and translated some strings, just to see it works.
I would suggest revamping this into something very similar to the GNU translation system to get the tools from there, and to be able to have several languages to choose from. A good suggestion would be that the language could be chosen from the http-request.
Note that if multiple languages are supported, a mechanism must be derived to be able to use the cache anyway.
- DomesuWiki supports translation with Locale::Maketext::Fuzzy, which still uses a big translation table (that's all gettext does too), but it's a lot more flexible, much more so than gettext (google for Locale::Maketext::TPJ13 for the gory details). It also supports language selection through Preferences as well as the HTTP Accept-Language header (Preferences override the header). Cache isn't supported (at all) in DomesuWiki, but it's not a hard problem to fix. It's not hard to backport the preference setting for the Accept-Language header (you don't want to use the HTTP negotiate module, it's awful), but the usage of Locale::Maketext::Fuzzy pretty much involves a rewrite of all messages. --ChuckAdams