Friday, November 07, 2008

The localisation of MediaWiki extensions

Like many applications, MediaWiki has both core and extended functionality. There are a growing number of extensions and most are localised at Betawiki. For the developers who develop MediaWiki, Betawiki has proven itself a precious resource. Many of the MediaWiki extensions have been adapted in order to get proper internationalisation. Recently, an extension developed by the UNICEF was worked on for more then a day and necessary feedback was provided about the code.. It just did not work for people wanting to implement it.

As time goes on, extensions are localised in more languages. Siebrand has a list that every so often is updated with the extensions with localised messages in at least 50 languages. It is a list that is growing.

As can be expected it is the extensions used by the Wikimedia Foundation that are doing particularly well, the support for FlaggedRevs is something that amazes me because it is only used on two projects as far as I know. I am happy to see the Babel extension localised in 122 languages. This makes it a really useful tool, it is sad that the WMF does not use it because many of its projects would benefit from the big support it provides. The Meta discussion is pretty much in favour and it can benefit all our projects.

With Siebrand in a statistics mode, he also provided me with some more numbers.. Currently Betawiki supports 128 extensions with localisations in over 50 languages, in mid May there were only 64. In January, the extensions used by the WMF had 570 messages, currently there are over 1300... In January MediaWiki contained 1732 messages, now there are 2122, a growth of 23%... In January we supported 2077 extension messages, by now there are 5111, a growth of 246%.

It is all the more amazing that the MediaWiki localisation community does this well.
Thanks,
GerardM

5 comments:

Tgr said...

"the support for FlaggedRevs is something that amazes me because it is only used on two projects as far as I know"

It is only used in two projects because half a year was not enough time to turn it on in the dozen or so other projects that requested it :S

GerardM said...

Hoi, your request was made here https://bugzilla.wikimedia.org/show_bug.cgi?id=15568 so it was requested on September 11th.. Waiting is part of requesting something. The officially sanctioned start of the Eqyptian Arabic Wikipedia is waiting for 114 days at this moment...
Thanks,
GerardM

Raymond said...

" ... the support for FlaggedRevs is something that amazes me because it is only used on two projects as far as I know."

But 13 projects have requested the enabling of FlaggedRevs:

alswiki, dewiktionary, pt.wikinews, en.wikibooks he.wikisource, Classical Chinese Wikipedia, Esperanto Wikipedia, Russian Wikiquote, Russian Wikisource, Ukrainian Wiktionary, French Wikinews, Hungarian Wikipedia, Polish Wikipedia

You see, some more languages will benefit from the translation of FlaggedRevs :)

Raymond.

GerardM said...

There are 138 languages who have some localisation for FlaggedRevs.. It is amazing.. as a consequence more language support it then CentralAuth or SUL.. SUL is used on any and all WMF projects.

It is amazing and shows clearly that people localise without much consideration of what takes priority... Alternately people start with a and work their way to z ...
Thanks,
GerardM

Tgr said...

The first still active FlagRev requests are from May. I can understand that testing and evaluation takes time, but someone could really take the ten seconds and write "hi, we can't currently fulfill your request due to insuccifcient testing/lack of resources/bad mood, but will revisit it in three months". Otherwise the communities will feel that the devs/foundation pay no attention to them, which can be rather disheartening. (Of course this is even worse for communities which are waiting for the establishing of their wiki... not to mention the case of the recent Wikinews wikis, which had to wait months for a license resolution, just to get a totally braindead license which will probably be thrown out in favor of the traditional cc-by license. So many issues could be solved with a little more communication...)