Multilingual Wikis
At LinuxWiki.de we had a discussion (LinuxWiki/MehrSprachigkeit) about multilingual wikis. The Ideas where:
- links to the translations of each page
- show/offer page in another language if page doesn't exist
- help for translation and sychronising across multiple translations
- resolve name conflicts (we deal a lot with program name, which are constant across languages)
After I took a look on the Sources of MoinMoin it seemed to be difficult to realize this in one wiki. So I started to write a prototype implentation using a WikiFarm. Each Wiki contains one language and there is a shared directory for information about what pages are translations of eachother. I 'll try to change the MoinMoin sources as little as possible, but it is impossible to do this with MoinMoin extentions only. -- FlorianFesti 2002-10-13 02:18:40
The MultiLang Extention is now a branch in the Moinmoin CVS (see MoinDev/BranchHistory) -- 217.187.69.203 2002-12-09 05:20:14
The MultiLang Extention will need a log for setting/unsetting translation relationships. I took a look on eventlog.py and editlog.py. Things look a bit unfinished there. I don't want to write a fifth logger class, but the classes that allready exist are not in an usable state for my needs. Will there be any effords to change logging in the near future or is everything as it should be? If this is an issue of lower priority I'd like to do this by myself. But it makes no sense to do this in the multilang branch only.
I'd additionally add an parameter to allow to read the end of the logfiles only. This would allow to get the statistic functions (hitcount, ...) and RecentChanges faster, which are now really slow and get slower with every new log entry. Therefore the calulation results for the beginning of the logs could be cached easily.
-- FlorianFesti 2002-12-19 13:30:41
Why should the relation between pages be part of a log anyway? -- jh
There are no backups for translation relationships in the multilang extention. So a log would allow to undo vandalism which - for example - deleted all translation relations. This would be a edit log for translation relationships.
I decided to build a new generic logger class using large parts of the existing code. It will be generic so it could be used for editlog and eventlog too (as superclass) if this seems reasonable to reduce duplicated code.
Update: New logging code have been implemented in Moin 1.2.
Moinmoin is multilingual !
Did you know that there is a very simple way to create a multilingual moinmoin site:
- Create a moinmoin site for the default language
Create a farm of translated sites using the default site as UnderlayPages
- A user will connect using his language site. If a translated page doesn't exist, the default version will be displayed
- To create a translated version of a page, connect to the right site, edit the (default) page and save a translated local copy.
That's all.
To do & some issues:
The orginal UnderlayPages are unavailable in the translated sites. Instead of one underlay, it would be nice to have an underlay search list.
- Create a navigation menu to navigate easily between the translated sites
Use the NearLink technology to translate the links
-- JeanJacquesKahn 2004-03-04 15:32:41
Nice idea. But it depends on having one "main" language. OK, isn't that far fetched, because that is often english.
Why do you want multiple underlays? I was thinking about such stuff in 1.4, but hadn't an application yet.
-- ThomasWaldmann 2005-03-04 15:53:27
The default site can be multilingual with variants for each supported language, including english. If the default version of a page is in english, you don't have to create an english variant.
With multiple underlays you could:
- still have access to the original moinmoin underlay (system pages)
- define a search logic : if the page is not available in the requested language, first check language 2, then language 3 ... then the default. This would be a site level configuration but might be later a user preference.
-- JeanJacquesKahn 2004-03-04 17:21:31
1.4 could maybe arrange underlays according to user's browser language preferences. 
I will keep that in mind and we'll see... -- ThomasWaldmann 2005-03-04 17:44:09
Multi-language using sister sites
See HowTo/MultilingualWiki(sistersites)
Comments on MultiLang
Our multiple language feature is actually too good, you get multiple languages even when you don't want it, behind your back!. Its like kindly helping an old lady to pass the street - but she did not want to pass. How many wiki admins are aware of the fact that they have this page פתיחה on their new installed wiki, and that any user with 'he' as its first language will get this generic-say-nothing-about-this-wiki instead of FrontPage?
Worse, on each text search, people are searching about 450 pages that they don't want to search and can't read. On an idle fast server, this can take about a second of cpu time, and many more to transfer the results over the network. On a busy server and slow connection, that can be 30 seconds, when most results are not relevant, and the relevant result might be hidden somewhere in the middle.
We might want to define a language list, just like browsers and operation system are doing. Instead of default_lang, we should use languages = ['en',...]. This can be used to decided on the language search order if the client does not define this.
A local wiki might use a list with only one value, which will serve only one language for any client, ignoring the client language - just like any regular site. Or it might serve one language to anonymous users, and allow some languages for registered users. This is needed behavior for some sites.
A wiki that want to serve multiple languages will allow more or all languages in the list (we might have * or other shortcut for all)
Same variable should be also available in the user preferences. Each user can define which language she is interested. For example, I would use ['he', 'en'], then when I search or view page lists - I will see only pages using these languages, because I don't care about other pages, I can't read them anyway. A good default value for the language list is the user selected language, then 'en', since not all translations are perfect, and most users can read both.
When we have a language list, we don't have to load all languages, just those on the list. If we don't have 'zh', then we also don't have 'zh' translations, and FrontPage will not be replaced with the Chinese page if you don't want to serve such page.
About page storage, it can be done in many ways, I would check the structure when each language pages are at underlay/lang/, when lang can be some kind of special name that the wiki hide. Then unneeded languages can be removed easily. -- NirSoffer 2005-03-04 23:02:54
Simple patch to have automatic multilingual pages: http://wiki.mad.mw/MoinMoin/LocalizationPatch -- JulianRomero 2006-10-10 09:47:55
See also Creating multilingual wikis and wiki engines for an investigation of how to make moinmoin multilingual.
-- AntoniosChristofides 2005-08-24 21:09:34
See also the FeatureRequests/ThisPageInOtherLanguages that implements a box similar to MediaWiki's. -- TheAnarcat 2006-01-21 23:35:14