Mastering MediaWiki: A Deep Dive into the Content Translation Extension

Content Translation (CT) is the extension behind Wikipedia's article translation tool: it shows the source article side-by-side with an editor window, suggests machine translations paragraph by paragraph, and produces a publishable wikitext article in the target language. It handles the editor experience; the surrounding structure (language codes, translation pages under Translations: pseudo-namespaces) comes with it. This guide covers what CT needs on a self-hosted wiki and how to make it useful.

Requirements and installation

CT assumes a modern MediaWiki with the editing stack in place:

• MediaWiki with Parsoid in core (1.42+) — CT's editor works through the VisualEditor interface, which needs Parsoid (integrated since 1.42; on older versions an external Parsoid service)
• VisualEditor — the translation editor surface
• UniversalLanguageSelector — for language selection and input tools

Then load the extension:

wfLoadExtension( 'ContentTranslation' );

and run php maintenance/run.php update — CT creates its own tables for translation sessions and published-translation records. The entry point is Special:ContentTranslation.

How translation works

An editor picks a source page and a target language; CT copies the source's structure (headings, images, templates) and aligns sections. Machine translation is optional and segment-level: the editor accepts, fixes or replaces each suggestion, and sections not touched remain machine-translated or untranslated as configured. The result is not a fork of the source — CT keeps track of which published articles are translations of which sources (visible as 'translated page' entries in history and via the cx features), so updates can be tracked.

Machine translation configuration

Two modes exist, controlled by $wgContentTranslationTranslateInTarget (default true):

• Client-side (true) — MT suggestions are produced in the browser using provider pack-ages; simplest to operate, no external service to run
• Server-side (false) — MT runs on a dedicated translation service (the Apertium/Google endpoints Wikimedia uses); higher quality for more languages, but you must operate or integrate such a service

Language pair availability depends on the provider: Apertium covers many European pairs; everything else falls back to 'translate manually' with no MT suggestions, which is still a usable workflow. You can restrict which language pairs offer MT and which tools are allowed via the extension configuration ($wgContentTranslationLanguagePivot and related settings are documented on the extension page).

Publishing

Publishing creates a regular page in the target language (e.g. Mitochondrial DNA/de style names can be avoided — the title is chosen by the translator). CT supports publishing into user namespace first for review, and on Wikimedia it adds a {{translated page}}-style tracking template; on your own wiki that template is up to you. Editors need the normal edit rights; blocking MT for specific users or languages is possible via the extension's permissions model.

Operating notes

• Not a replacement for Translate — CT creates one translated article per source per language; systematic page-translation workflow (message groups, review states, statistics) is the Translate extension's job. The two are complementary — source documentation can be managed with Translate while editors draft articles with CT
• MT quality varies — for encyclopedic content, MT is a draft generator; if your wiki publishes without review, consider restricting CT to trusted groups
• Resource use — the editor is a real-time environment with embedded citations and image handling; it is heavier than plain editing. Budget accordingly on small VPS setups

Content Translation turns a wiki into an active translation hub instead of a copy-paste chore. On Wikimedia it produces tens of thousands of articles a year; on a self-hosted wiki the same mechanics work at a smaller scale. The extension page documents the full configuration surface.