Page MenuHomePhabricator

Simple multilingual wiki ability enhancement request
Closed, InvalidPublic

Description

Author: mediazilla

Description:
Multi-lingual wiki is a right pain in the ****. Setting up a single
language wiki is ease itself (well done folks). Setting up a multi-lingual
wiki is a nightmare (maybe if Jimbo and others worked in a multiligual
enviroment like Belgium life would be different).

For example:

  • for every language you have to set up a new database (even if it is part

of the same single database, I still have to go through the setup)

  • I have to have a separate copy of the MediaWiki code for every language or

figure out the wizardry to use a single version with different LocalSettings
per language

  • I have to figure out how I'm going to sort out the problem of multiple

signons (each language will have separate signons - that is just so NOT what
you want when you just want a site in 2 languages (say).

I am in Belgium where every site is always in French and Dutch and I am
gradually figuring out each of the gotchas for my site www.treekee.com.

Next I want to figure out how to do it simply for a truly multinational site
(70+ languages). At the very least I know I'm going to have to do everything
70+ times.

It should ideally be as easy as saying, in LocalSettings.php, that I want to
have a multi-lingual wiki:

$multiLang = true;

It's not. It's just a nightmare.

It seems to me that there are only 2 things which a MediaWiki admin really cares
about in relation to this. There are I know already discussions of many of the
multi-lingual aspects on the following URL
http://meta.wikimedia.org/wiki/Multilingual_MediaWiki, but many of them are
irrelevant as far as this request are concerned. The 2 things are:

  1. everything in one single database, working as one cohesive whole, with one signon
  2. each page when viewed to have all messages/menus/text in the correct language

I will look at each of these in turn.

Firstly, everything in one single database, working as one cohesive whole, with
one signon.

I think the problem is not so difficult either.

There needs to be simply one extra column in the page table specifying the
language. This column would simply contain the wiki code, "en", "fr" etc.

Then the URL needs to have some standard way for MediaWiki to extract the
language of the current page. I would have thought that some system where the
language code is in the URL would work well, e.g.
http://www.mysite.com/index.php?title=Dog&lang=en
http://www.mysite.com/index.php?title=Chien&lang=fr

These could be fairly easily transformed I would have though in the way that
URLs are currently transformed to be more user friendly:
http://www.mysite.com/en/wiki/Dog
http://www.mysite.com/fr/wiki/Chien

The interwiki table could (if you really wanted) have entries added
automatically during installation like:
"fr" => "http://www.mysite.com/fr/wiki/$1" and
"de" => "http://www.mysite.com/de/wiki/$1"
though the observant reader will realise that even these are superfluous, since
the only thing the MediaWiki software needs is a list of the wiki language codes
and it can create these easily.

Now, what does the MediaWiki software do with this extra info? I think that
either the $title could be passed as, say, "en:dog", or (better I think, since 2
parameters are treated as 2 parameters), that an extra parameter $lang would be
passed to any routine that cared, with routines having optional language
parameters received, myFunc($title, $lang="").

There would probably need to be a default language for any case where a language
is not passed. e.g. in LocalSettings.php

$multiLangDefaultLang = "en";

This could always be got via the new global $gblMultiLangDefaultLang.

Where the code finally cared about getting the right page from the now single db
for ALL languages, it would be as simple as adding "AND langCode = $lang" to the
SQL query.

OK, that very small change has now given us the ability to have a SINGLE
database with ALL languages in. One signon comes as a freebee since the signon
user table does not have a language component.

The other thing which a MediaWiki admin wants of course is for each of the pages
to appear with all the
messages/menus/text in the correct language. This is the 2nd of the requirements.

For this, I don't understand at all how the current messaging is done and I will
have to leave it to someone else to comment. I know that you have to run a tool
once at setup to get the messages in their correct language.

I would have thought though that with a little bit of thought this 2nd process
would also be fairly easy.

http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html

With these 2 things working 90% of users would have the multilingual wiki
abilities they want. And I, facing setting up 70+ subwikis/databases etc. will
be a VERY happy man.


Version: unspecified
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Multilingual_MediaWiki

Details

Reference
bz6107

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:16 PM
bzimport set Reference to bz6107.
bzimport added a subscriber: Unknown Object (MLST).

There is extension called Farmer, which may help in this, or maybe not.

(In reply to comment #0)

For example:

  • for every language you have to set up a new database (even if it is part

of the same single database, I still have to go through the setup)

Use scripting, Farmer extension or something.

  • I have to have a separate copy of the MediaWiki code for every language or

figure out the wizardry to use a single version with different LocalSettings
per language

It's quite easy, but the actual details vary so much it's not worth trying to automate it.

  • I have to figure out how I'm going to sort out the problem of multiple

signons (each language will have separate signons - that is just so NOT what
you want when you just want a site in 2 languages (say).

CentralAuth? Shared user table?

There is too many things in this bug, making it impossible to see what is missing, what is wanted and what is in which state. I'm closing this bug now, but feel free to open new bugs for specific issues that still exists.