A wiki with international users may need multi-language support. Two distinct concerns: the wiki's UI (menus, buttons, system messages) and the content (the actual pages).
Different problems; different solutions.
Standard i18n: extract strings from code; translate per language; serve appropriate translation per user.
See InternationalizationAndLocalization for general patterns.
For wikis: the platform usually supports this. Most major wikis (MediaWiki, Confluence, etc.) ship with translations. Custom wikis need to handle it.
The harder problem. The pages themselves in multiple languages.
Content/
├── en/HomePage.md
├── es/HomePage.md
└── fr/HomePage.md
Each language has its own copy of each page. Translations are separate pages.
Pros: simple; easy to discover; clear ownership per language. Cons: lots of duplication; hard to keep synchronized.
Same content; different language versions linked together.
Wikipedia uses this. The English page about X has links to other languages' pages about X.
Pros: discoverable across languages. Cons: requires explicit links between language versions.
English (or whatever) is the source of truth. Translations are derived; not all pages translated.
Pros: less duplication; English version reliable. Cons: non-English readers see partial content.
Machine-translate at read time. Don't store translations.
Pros: covers all languages. Cons: quality varies; slow; cost per query.
For wikis where translation quality is important, machine translation is supplementary, not primary.
Who translates? How is translation kept current with source changes?
Options:
For most internal wikis, English-only is the realistic answer.
Source page updates; translations are now stale. Track:
Some wikis show "translation may be out of date" warnings.
Should searches return results in all languages or only the user's? Both have use cases.
Languages mixed in results requires the search system to understand language. Most wiki search is single-language.
/en/HomePage
/es/HomePage
vs
/HomePage?lang=en
/HomePage?lang=es
vs
/en.wiki.example.com/HomePage
/es.wiki.example.com/HomePage
Different SEO implications; different infrastructure complexity.
For most cases, path prefix (/en/) is the right balance.
Hebrew, Arabic, Persian, Urdu. UI must mirror.
For wiki UI: standard RTL practices. For content: usually no special handling needed (content is just stored as-is).
Source of truth is English (or whatever). Translations are derivative.
When there's conflict between source and translation, source wins. Translation gets updated.
Per-page translation status:
translations:
en: { status: source, last_updated: 2026-04-26 }
es: { status: outdated, last_synced: 2026-01-15 }
fr: { status: complete, last_synced: 2026-04-20 }
Shows what needs work.
For consistency, translation memory tools (Crowdin, Lokalise) remember past translations. New strings auto-suggest based on similar past translations.
For frequent translation, this helps consistency and speed.
Specific terms with agreed translations. Avoids "user" being translated three different ways across the wiki.
Some pages translated; most aren't. Users confused about coverage.
Either commit to translating everything (expensive) or be clear that English is primary.
Translation done once; never updated. As source evolves, translation drifts. Misleading.
Either active translation maintenance or don't translate.
Machine translation passed off as official translation. Quality issues; readers misled.
Always disclose: this is machine-translated; for reference only.
The English wiki has different structure than the Spanish wiki. Cross-references break.
Maintain parallel structure where possible.
When it's not:
For most wikis: