Configuring MediaWiki for Multilingual Support with Translate Extension

The Translate extension turns a MediaWiki into a multilingual wiki with page translation, message groups and review workflows. Where most installs struggle is not the installation but the configuration decisions around it — languages, roles, groups and performance. This article covers the settings that actually matter, verified against the current extension (which requires MediaWiki 1.46 or newer; check your version before planning).

1. Installation checklist

wfLoadExtension( 'Translate' );

Translate adds database tables and several rights (translate, translate-manage, translate-messagereview, translate-groupreview, translate-import, unfuzzy), so run php maintenance/run.php update after loading it and confirm the extension on Special:Version.

2. Language fallbacks

Fallback chains are a core MediaWiki setting, not a Translate one — the common mistake is looking for a $wgTranslate* variable. When a page has no translation in the reader's language, MediaWiki serves the fallback language instead:

$wgLanguageFallbacks = [
    'nl' => [ 'en' ],       // Dutch pages fall back to English
    'sv' => [ 'da', 'en' ], // Swedish → Danish → English
];

Keep chains short: every hop is a decision the reader cannot make, and long chains mask missing translations. The wiki's own base language (where untranslated pages live) is set with $wgLanguageCode.

3. Who can do what

Separate the three roles the extension knows:

$wgGroupPermissions['translator']['translate'] = true;
$wgGroupPermissions['translationadmin']['translate-manage'] = true;
$wgGroupPermissions['translationreviewer']['translate-messagereview'] = true;

Translators only see the translation interface; translation administrators mark pages for translation and manage groups; reviewers approve translations where the wiki uses the review workflow. Assigning all three to one group is the configuration smell that leads to unchecked translations.

4. Groups: match the work, not the wiki

Message groups define what translators see in task lists and statistics. Default page groups are per-page, which fragments small wikis into hundreds of tiny lists. Consolidate related content into multi-page groups via Special:ManageMessageGroups (see group configuration), e.g. one group per documentation section. Group states (Special:ManageMessageGroups → set states) let you enforce a review order: untranslated → proofreading → ready.

5. Workflow and review

Workflow states are configured with $wgTranslateWorkflowStates:

$wgTranslateWorkflowStates = [
    'untranslated' => [ 'color' => 'grey' ],
    'inprogress'   => [ 'color' => 'orange' ],
    'proofreading' => [ 'color' => 'blue' ],
    'ready'        => [ 'color' => 'green' ],
];

For critical pages, require translation review by granting translate-messagereview only to a dedicated reviewer group and instructing translators to mark work 'for review' instead of 'ready'.

6. Performance settings

Translate scales fine on default settings for most wikis, but two levers matter on bigger installs:

• Message index storage — the default (an in-wiki page) works everywhere; with a Redis/MySQL service available, $wgTranslateMessageIndex can use a faster backend (see message index docs)
• Statistics — Special:LanguageStats output is cached; on large groups, cache timeouts and the group splitting advice in section 4 matter more than backend tuning

7. Day-one decisions

• Write source pages clean first — mark pages for translation only after the content is stable; every source edit fuzzes existing translations
• Keep markup out of translation units — templates, tables and parser functions outside <translate> tags; translators should translate prose
• Plan the languages — the extension supports hundreds of languages out of the box; enable the ones your community actually reads (the language list per page is configurable in Special:PageTranslation options)

The configuration documentation covers every option; the pattern above — clean source, separated roles, grouped content, short fallback chains — is the configuration most multilingual wikis actually need.