Building a Multi-Language Wiki with MediaWiki's Translate Extension

The Translate extension is the standard choice when a MediaWiki site needs structured translation work inside the wiki itself. It is more than a language switcher: it adds translatable pages, message groups, review workflows, statistics and a permission model that separates those who prepare content from those who translate it. The extension is stable, is part of the MediaWiki Language Extension Bundle, and its current releases require MediaWiki 1.46.0 or newer and database changes, so check compatibility before planning an install on an older wiki.

What Translate is for

Use Translate when you want one source page with controlled translations attached to it. Good candidates are help pages, policy documents, product documentation and any content that changes often enough that manually copied language pages would drift out of date. The extension is also used beyond page translation: translatewiki.net uses it to localize software interface messages, and the same message group machinery can translate the wiki interface or an external software product.

Do not install it just to show a few manually written language variants — for a small static site, separate pages are simpler. Translate becomes valuable once you need workflow: who can mark pages, who can translate, who can review, and how the wiki tracks completion.

Installation

Install the extension through the method that matches your deployment: with Composer use the mediawiki/translate package, otherwise download the matching release and place it in extensions/Translate. Then load it from LocalSettings.php:

wfLoadExtension( 'Translate' );

Because Translate changes the database schema, run the MediaWiki update script after installation:

php maintenance/run.php update

On MediaWiki versions older than 1.40, the equivalent command is php maintenance/update.php. Verify the extension appears under Special:Version before configuring permissions. Page translation is enabled through the $wgEnablePageTranslation setting (defaults to true).

Roles and permissions

Translate adds several rights, including translate, translate-manage, translate-messagereview, translate-groupreview, translate-import and unfuzzy. Keep those roles separate: translating text and managing translatable pages are not the same job. A simple production split looks like this:

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

The group names are up to you; what matters is that translation administrators understand page structure and message groups, while translators only need the translation interface.

Preparing pages for translation

Page translation starts with the source content. Write the source page cleanly first, then wrap the translatable parts in <translate> tags. Keep templates, tables and parser functions outside the translation units where possible — translators should translate prose, not reverse-engineer page layout:

<translate>
This page explains how to request an account.

== Before you start ==

You need a valid email address and a short reason for access.
</translate>

After saving the page, a user with the translate-manage right marks it for translation at Special:PageTranslation. Translate then splits the page into units and exposes them through Special:Translate. When the source changes later, only the affected units are marked outdated ("fuzzy") instead of the whole page.

Message groups

Message groups are how Translate organizes work. A group can represent one page, a set of help pages, or all interface messages of a software project. Groups are what translators see in statistics and task lists, so name them after the work they represent. For a documentation wiki, useful groups might be:

• Help pages for user-facing documentation
• Project policy for governance pages
• Extension documentation for technical pages

Avoid one giant group for the whole wiki: smaller groups make progress visible and let you prioritize what matters.

Working with fuzzy translations

When the source text changes, translations of the affected units are marked outdated. That is a feature, not noise: it tells translators the old translation may no longer match the source. Small source edits with clear summaries keep the number of fuzzy units low, since only changed units are affected, not the whole page.

Review and quality assurance

Translate supports proofreading workflows (translate-messagereview) and message group states (Special:ManageMessageGroups / group review). Use them where correctness matters — policy, legal text, public help pages — and keep a lighter process elsewhere. Do not make review a bottleneck by default: pick the pages that need it, assign reviewers, and watch the queue. A workflow nobody can finish is worse than none. Quality can be further automated with translation validators, which reject or warn on common errors before a translation is saved.

Statistics

The extension ships reporting tools at Special:LanguageStats and Special:MessageGroupStats. Use them to decide where to focus, not just to show progress bars — a language at 80% completion may still be missing the one page most readers need. Practical checks:

• Which message groups are incomplete in active languages?
• Which pages became fuzzy after recent source edits?
• Which languages have translators but no reviewers?
• Which old groups are no longer worth translating?

Operations notes

Translate touches caching, jobs, permissions and database tables. After installation or large source updates, watch the logs and job queue behavior. If translations do not appear when expected, check page cache, job queue processing, and whether the page was actually marked for translation after the latest source change. Translation memory (the matching-suggestions service behind the translator interface) is enabled by default, and can be backed by an external service if you need it at scale.

Decide in advance how configuration is backed up and deployed: a multilingual wiki is harder to repair if group definitions and permission changes live only in somebody's memory.

Common mistakes

• Too much markup inside translation units — keep layout outside whenever possible
• No owner for source pages — translators need stable source text
• One huge message group — smaller groups are easier to assign and review
• Permissions copied from another wiki — match rights to your actual workflow
• Ignoring fuzzy markers — outdated translations need review, especially on high-traffic pages

Translate works best when the wiki treats translation as ongoing maintenance, not a one-time launch task: install the extension, set clear roles, prepare pages carefully, and keep the source text stable enough that translators are not chasing constant rewrites. The official Help:Extension:Translate documentation covers the full workflow in detail.