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

The Translate extension is the usual choice when a MediaWiki site needs structured translation work inside the wiki itself. It is not just a language switcher. It adds translation pages, message groups, review tools, statistics, and permissions for people who prepare content and people who translate it.

Start with the official Translate extension page. Current documentation lists it as a stable extension for MediaWiki 1.46.0 and newer, with database changes and several added rights. Check that before planning an install on an older wiki.

Where Translate fits

Use Translate when you want one source page and controlled translations attached to it. Good candidates include help pages, policy pages, project documentation, interface-like text, and content that changes often enough that copied language pages would drift out of date.

Do not install it just to show a few manually written language variants. For a small static site, separate pages may be simpler. Translate becomes useful when you need workflow: who can mark pages, who can translate, who can review, and how the wiki tracks completion.

Installing the extension

Install the extension through the method that matches your MediaWiki deployment. If your wiki is managed with Composer, use the package listed by the extension docs. If you deploy extensions manually, download the matching release and place it under 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 older MediaWiki versions, the equivalent command may be:

php maintenance/update.php

After the update, check Special:Version. Translate should appear in the installed extensions list. If it does not, fix that before configuring permissions or page translation.

Permissions

Translate adds several rights, including translate, translate-manage, translate-messagereview, translate-groupreview, 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;

Exact group names are up to you. The important part is that translation administrators should understand page structure and message groups, while translators should only need the translation interface.

Preparing pages for translation

Page translation starts with source content. Write the source page cleanly first, then wrap the translatable parts with <translate> tags. Keep templates, tables, and parser functions outside 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 management rights marks it for translation. Translate then splits the page into units and exposes those units through Special:Translate.

Message groups

Message groups are how Translate organizes work. A group might represent one page, a set of help pages, or interface messages from 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 help
• Project policy for governance pages
• Extension documentation for technical pages

Avoid making one giant group for the whole wiki. Smaller groups make progress visible and reduce the risk of translators spending time on low-priority pages.

Working with fuzzy translations

When the source text changes, existing translations may be marked as outdated or fuzzy. That is a feature, not noise. It tells translators that the old translation may no longer match the source.

Good source edits help here. Make small changes, save with clear summaries, and avoid rewriting a whole page when you only changed one sentence. Smaller diffs mean fewer translation units become fuzzy, and reviewers can see what actually changed.

Review and quality

Translate supports proofreading and review workflows. Use them where correctness matters: policy, legal text, public help pages, and interface text. For low-risk pages, a lighter process may be enough.

Do not make review a bottleneck by default. Pick the pages that need it, assign reviewers clearly, and watch the queue. A translation workflow that nobody can finish is worse than no workflow.

Statistics

Translate includes reporting tools for completion and activity. 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 logs and job queue behavior. If translations do not appear when expected, check page cache, job queue processing, and whether the page was marked for translation after the latest source change.

Also decide how you will back up and deploy translation-related configuration. 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 when 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 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.