Template localisation

This page aims to give a technical review of template localisation techniques. It is only a humble beginning, written by someone not overly familiar with the inner workings of either Wikimedia Commons or Meta-Wiki, so bear patience with me and feel free to contradict anything I say here. This is simply an effort to document possible approaches, so they may be used by non-Wikimedia wikis.

If you are looking for information on MediaWiki localisation, that is, localisation of the software itself, see Localisation.

For template localisation, I ranked the approaches encountered so far, for the least recommended method to the most recommended (IMHO):

1. Kol-Zchut
2. Meta-Wiki
3. Wikimedia Commons
4. Extension:Translate

Please note: This order is for template localisation; for content translation, Meta-Wiki's way seems second-best only to the Translate extension.

Kol-Zchut

This is actually a documentation of an almost-abandoned approach, documented here just because it might benefit someone.

Our system was designed for a primary Hebrew wiki, with additional wikis for other languages, which contain mostly translated content, and very little original content ("slave" wikis). Therefore we needed an exactly replicated UI and templates for all those wikis, taking into account RTL/LTR and translations. Our original system worked like this:

• Language-driven design: mainly directionality. This is mostly taken care of by ResourceLoader using CSS-Janush, which flips css rules in stylesheets; however, as with any wiki, many templates use inline styling, which cannot take advantage of ResourceLoader. One possible solution for this was only using stylesheets; it's a very clean method, but hampers the fast creation of templates. The solution we decided on was using directionality templates. These are our three:

• {{Dir}}, which returns "rtl" or "ltr" according to the {{CONTENTLANGUAGE}}.

{{#SWITCH:{{CONTENTLANGUAGE}}
| ar
| he = rtl
| #DEFAULT = ltr
}}</includeonly>

• {{Left}} = {{#IFEQ:{{dir}}|ltr|left|right}}
• {{Right}} = {{#IFEQ:{{dir}}|ltr|right|left}}
  • A better way of doing this is probably using Mediawiki's magic word {{dirmark}}, which return ‎ / &rlm according to the system's language, and switch according to that – that saves the hassle of accounting for all cases ourselves. Since we have a small selection of languages (and were not aware of {{dirmark}} ), we took the above approach.

• String translation: done as subpages of templates (/en, /ar, /he) and not as a global i18n file. Using Extension:Variables to retrieve and store the translated strings.
• The translated template itself simply uses the variable names of the messages, ignorant of the translation process, of course.
• Default fallback language is defined in-template, not as a subpage.
• using the following template, {{translation}}:

<includeonly>{{#IFEXIST: {{{1}}}/{{CONTENTLANGUAGE}} | {{ {{{1}}}/{{CONTENTLANGUAGE}} }} | }}</includeonly><noinclude><nowiki>
If a subpage containing a translation for the wiki's content language exists, transclude it, otherwise do nothing.
</noinclude>

• Which is then used like this, for example in template {{Organization/Infobox}}:

<includeonly><!--
-->{{#VARDEFINE:title|Organization details}}<!--
-->{{#VARDEFINE:field|Field of activity}}<!--
-->{{Translation|Template: Organization/Infobox }}

• and, for example when CONTENTLANGUAGE=he, loads Template: Organization/Infobox/he, which contains:

<includeonly><!--
-->{{#VARDEFINE:Title|פרטי הארגון}}<!--
-->{{#VARDEFINE:field | תחומי עיסוק}}<!--
--></includeonly>

This system allows us to maintain all templates in one wiki; this is essential for a setup such as ours, unlike Wikipedia, in which every language's wiki is autonomous.

Keeping things in sync

We started by updating the templates in slave-wikis using export-import; this is used for batch updating. It is possible, for example, to mark all translated templates as belonging to one category (e.g., "category:transtemplates") and then export all pages by selecting that category in Special:Export. For smaller updates, it is possible to import one page at a time without first exporting by setting $wgImportSources, which is an array of interwiki prefixes from which direct import is allowed.

Another option, not yet tested by us, might be to use Extension:Push instead of export-import.

Please note: If importing from a non-english wiki, it is recommended to alias NS_TEMPLATE on the importing wiki with that non-english NS name, otherwise it makes a mess. For example, the following settings is placed on any target wiki, when importing from a Hebrew wiki, where NS_TEMPLATE is named 'תבנית', by using $wgNamespaceAliases, like this: $wgNamespaceAliases['תבנית'] = NS_TEMPLATE;

And in crept the bugs...

Later along the way we discovered problems with our translation system, for example:

• When using the same template twich on a page, it wasn't translated the second time
• Each update to translated strings required editing multiple pages, which was very cumbersome
• Setting up a new template for translation required creating multiple subpages
• It was quite easy to forget to fix the translations when the master language strings were changed.

Solutions?

Our first and immediate solution was to change to the Wikimedia Commons approach, as it required very little change from our existing system. The messages themselves may be placed in the database (the Mediawiki namespace), but for our setup of multiple wikis, a better approach was to place them in an extension alike WikimediaMessages.

Sidenote: this method also allows to override core messages without overriding them in the database.

Going forward, it seems to us that the best approach is to use Extension:Translate (see below). The issue of inter-wiki synchronization still needs to be reviewed.

Meta-Wiki

The approach shown on Meta-Wiki is still in use there, but I wouldn't recommend it nowadays; it doesn't scale (even though the translators seem to be doing an excellent job over there), and I assume it will be gradually replaced by #Extension:Translate.

Basically, everything is done manually:

1. The original (English) text is placed as a regular page (e.g., [[Example]]
2. Translations are placed in a sub-page named by the appropriate language code, e.g. [[Example/Ar]] for Arabic.
3. The status of the different translations is handled by using a translation status template, {{Translation}}, which also categorizes the translations accordingly.

   Possible status for each translation: missing, in progress, needs updating, needs proofreading, done/ready for publishing, or published.

4. This status template is transcluded inside a sub-page of the template itself, bearing the page's name - e.g., "Template:Translation/Example".
5. This sub-page is then transcluded in the original page.
6. When the original (English) text is updated, the status for other languages must be changed manually.

Wikimedia Commons

Commons only has one version of each template, with translation done by using MediaWiki messages and the {{INT:}} magic word. You can see one such example on commons:Template:Cc-by-sa-layout. Please note that there are a couple of options to use translated messages:

1. {{INT:}} uses the user's language
2. {{Mediawiki:}}, that is transclusion from the Mediawiki namespace, uses the system's language. This is useful when you want to maintain a localised template for several wikis, and not one multi-lingual wiki.

I am not sure as to the effects on caching and performance of each option.

Extension:Translate

The Translate extension was only recently enabled on Meta-Wiki, and it seems not to be in great use (see m:Special:Translate), but is already in use on other significant non-Wikimedia wikis. Even though the old system still seems predominant on Meta-Wiki, Extension:Translate seems superior to it. This method works similiarly to the old system in terms of language-code sub-pages for translation, but has a lot of automation replacing manual work, supplying the following advantages (and more):

• The status is changed automatically when the original version is edited.
• A page can be divided into sentences or paragraphs, each translated separatly, and so translators do not have to re-visit the entire text (see for example the translation for the Donor policy page.
• It can assist with consistency of terms and phrasing, using translation memory.

For an in-depth review of the extension, see Extension:Translate and Help:Extension:Translate.