Wiki Internationalization

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.

UI internationalization

Standard i18n: extract strings from code; translate per language; serve appropriate translation per user.

See [InternationalizationAndLocalization](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.

Content internationalization

The harder problem. The pages themselves in multiple languages.

Strategy 1: parallel page sets

```

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.

Strategy 2: language interlinks

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.

Strategy 3: English primary; translate selectively

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.

Strategy 4: machine translation on the fly

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.

Practical considerations

Translation workflow

Who translates? How is translation kept current with source changes?

Options:

- Volunteer translators (community wikis)

- Professional translation (commercial)

- Machine translation + review

- Auto-machine-translation only

For most internal wikis, English-only is the realistic answer.

Synchronization

Source page updates; translations are now stale. Track:

- Source last edited

- Translation last synced

- Diff: what changed since translation

Some wikis show "translation may be out of date" warnings.

Search across languages

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.

URL structure

```

/en/HomePage

/es/HomePage

```

/HomePage?lang=en

/HomePage?lang=es

```

/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.

Right-to-left languages

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).

Specific patterns

English-source policy

Source of truth is English (or whatever). Translations are derivative.

When there's conflict between source and translation, source wins. Translation gets updated.

Translation status

Per-page translation status:

```yaml

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.

Translation memory

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.

Glossaries

Specific terms with agreed translations. Avoids "user" being translated three different ways across the wiki.

Common failure patterns

Inconsistent language support

Some pages translated; most aren't. Users confused about coverage.

Either commit to translating everything (expensive) or be clear that English is primary.

Stale translations

Translation done once; never updated. As source evolves, translation drifts. Misleading.

Either active translation maintenance or don't translate.

Auto-translation labeled as official

Machine translation passed off as official translation. Quality issues; readers misled.

Always disclose: this is machine-translated; for reference only.

Multiple language hierarchies

The English wiki has different structure than the Spanish wiki. Cross-references break.

Maintain parallel structure where possible.

When multi-language is worth the effort

- **Public-facing wikis** with international users

- **Compliance** requirements for specific languages

- **Active community** willing to translate

When it's not:

- **Internal company wikis** where English is the lingua franca

- **Small wikis** with limited resources

- **Highly technical content** where English is the working language anyway

A reasonable approach

For most wikis:

1. Pick a primary language; commit to it

2. UI in user's language (cheap; usually built-in)

3. Translate content only where there's clear demand

4. Be honest about coverage gaps

5. Update translations when source changes (or stop translating)