Help:Extension:Translate/Unstructured element translation

This page explains how to make translation of customized wiki interfaces messages a bit more manageable, with the Translate extension. It applies to any part of the wiki which you want to automatically provide in the user's interface language. The most typical example is the sidebar, because there can be only one, but the same method can be used for the main page, if you want to have all translations of it under the same title, or even for templates.

This method is applicable also to wiki content where full page translation just doesn't fit, like pages heavy in markup or templates, the markup of which you don't want to expose to translators. This all revolves around man-sysmsg>Special:Mylanguage/Manual:System message|interface messages, or the   magic word, that allows you to include interface messages anywhere where you can write wikitext. This magic word allows to automatically substitute the interface message, whether standard, customized or new, in the user interface language.

You can use it to bring the power of the automatic localisation of the wiki's interface to the wiki's content, but it doesn't solve the problem for anonymous users, who cannot change the interface language by default. See the note about the Universal Language Selector extension below.

Compared to page translation, this method has some drawbacks:


 * 1) MediaWiki developers usually discourage the usage of    because it fragments the cache. Instead of storing one cached rendered version of a page, when    is used it needs to be cached potentially in hundreds of different languages.
 * 2) It is harder to setup, requiring access to wiki configuration.
 * 3) There is no automatic tracking of outdated translations and completion statistics might be off when new messages are added or deleted.
 * 4) Only wiki administrators can add messages to the message groups and translate them. This means that the system is suitable only for pages which don't change often, or administrators will have a lot of work.

The good thing is that it works most of the time and you can still get the job done. There are two tutorials that provide examples of the common use cases. Before that there is section which details how to set up a message group, something which is always needed when using this method.

Setup
A server administrator must complete this step. The following snippet needs to be added to LocalSettings.php:

The message group id,  , must be unique, so don't reuse the same id for multiple groups. The second parameter to the  , refers to the  Mediawiki:Sidebar-messages  page. The label is shown in dropdowns and other places where you can select a message group. The description is shown in Special:Translate</>. Those are the values you can and should change to what suits your wiki when adding a new custom message group.

Localised sidebar tutorial
We assume that the setup step has already been done. Then you should follow the manual-int-sidebar>Special:MyLanguage/Manual:Interface/Sidebar</>|sidebar customization guide carefully. Let's assume the following simple sidebar was created:
 * sidebar-commonpages
 * FAQ|sidebar-faq

And <tvar|sidebar-commonpages> MediaWiki:Sidebar-commonpages </> contains <tvar|sidebar-commonpges-code> </>, while <tvar|sidebar-faq> MediaWiki:Sidebar-faq </> contains <tvar|sidebar-faq-code> </>.

Then all we need to do is to go to <tvar|sidebar-msg-page2> MediaWiki:Sidebar-messages </> (or whatever was defined in the previous step) and write there: sidebar-commonpages sidebar-faq

That is, the names of the system messages, without the "MediaWiki:" namespace prefix, separated by whitespace.

Then go to <tvar|wiki-sidebar> Special:Translate/wiki-sidebar </> (or whatever was defined in the previous step; see <tvar|spec-translate> Special:Translate </> for the list of defined groups). Now it is possible to translate the messages into other languages. Since all the messages are in the MediaWiki namespace, only a wiki administrator can edit the list of messages and actually translate them.

Localised main page tutorial
Another use case is a page with lots of markup or templates. The advantage of this method is that the language automatically appears in the user's interface language. The drawback is that to change the language in which the page is displayed, the interface language must be changed.

The implementation is the same as in the previous tutorial:


 * 1) Setup a new message group.
 * 2) Take a wiki page.
 * 3) Replace each translatable part with <tvar|mainpage-name>  </> and move the content to <tvar|mainpage-msg> MediaWiki:Mainpage-messagename </>.
 * 4) Go to <tvar|mainpage-msg2> MediaWiki:Mainpage-messages </> (or what was defined in the setup) and add the message names there separated by whitespace.
 * 5) You are done. Go to <tvar|spec-translate> Special:Translate </> to translate the main page.

Here is an example. Let's say <tvar|mainpage> Main Page </> contains:  is a community for chefs and bakers that love chocolate. We currently have full of chocolate.

Then change it to: 

Create <tvar|mainpage-slogan> MediaWiki:Mainpage-slogan </> with the content: is a community for chefs and bakers that love chocolate.

Create <tvar|mainpage-pagecount> MediaWiki:Mainpage-pagecount </> with the content: We currently have full of chocolate.

Create <tvar|mainpage-messages> MediaWiki:Mainpage-messages </> with the content: mainpage-slogan mainpage-pagecount

And you are done! You can add and remove new messages any time you want.

Language selector
Not only the user can't choose what localised version of the page to read unless changing their preferences, but anonymous users can't set their user interface language and always use the wiki's default language. A page translated with this system will be in the default content language, if you don't provide anonymous users a way to select their language.

Luckily, there is a solution. With the UniversalLanguageSelector extension it is possible to guess the user's preferred language and also to let the user manually select another language and store the choice in a cookie, with no need of tricks such as the  parameter, which is suitable mostly only for debugging.