Debian wiki internationalisation

[Frank Lin PIAT <fpiat@klabs.be>]

Hello,

I would like to have your opinion on a solution I have just setup to
*test* internationalizing our wiki.

Technically, we setup one wiki per language:
 http://www.klabs.be/debian-wiki-dev/fr/
 http://www.klabs.be/debian-wiki-dev/es/
 http://www.klabs.be/debian-wiki-dev/   (English!)
(note: this naming scheme is compatible with the current one).

We the use a feature of many wikis, called SisterSite, that allows to
interconnect wikis that have pages with identical names.
So if you visit the page: http://www.klabs.be/debian-wiki-dev/fr/Test ,
the navigation bar have two buttons to the "English" and "Spanish"
pages.
Also, moinmoin is quite flexible and allows to share the user database,
and wikihomepages.

Advantages of this solution:
 * All features are built-into moinmoin wiki engine, and they are
   supported (even though we are tweaking them).
 * It's pure wiki-based solution.
 * Compared to the current situation, the links among translations are
   updated automatically.

Problems of this solution:
 * The search engine only work in $language content, not throughout
   all pages (i.e untranslated pages aren't fount)
 * Synchronizing the content with the reference page is very difficult:
   It isn't possible to know if the page is lagging (or missing).
 * We need a cron job to update the list of pages in sister sites. This
   can cause a delay before translation appears in other $lang sites.
 * The solution won't scale well (navigation bar is too small, periodic
   polling can consume a lot of resources: 2^n request, where n is the
   number of supported languages).
 * No content negotiation.
 * There is one RecentChanges page per language (which can also be
   considered to be a feature).

ALTERNATIVE SOLUTION:

For the record, we had a discussion at DebConf8, and we wondered if
we could/should use traditional tools to translate the wiki (i.e export
the wiki as xml or html, then generate .pot files. The translated pages
could then be exported as html. Apache could be used to serve those
pages, and do *proper* content negotiation)

Any comments?

Franklin

P.S. In anyone think I am masochist to work on a solution I don't 
     like, well you are right ;)
     I believe that in some situation you need to actually try
     things to figure out if it works.