When you publish documentation in more than one language, readers need a clear, reliable way to read it in theirs. The language switcher is the reader-facing sid...
When you publish documentation in more than one language, readers need a clear, reliable way to read it in theirs. The language switcher is the reader-facing sid...
When you publish documentation in more than one language, readers need a clear, reliable way to read it in theirs. The language switcher is the reader-facing side of multi-language docs: it lets readers pick a locale, detects a sensible default automatically, and keeps the whole experience — navigation, search, and the AI assistant — localized.
What readers see
On a multi-language site, a language selector appears in the site header. It shows the current language and a dropdown of all available locales, displayed in their native names:
🌐 English ▾
├ English
├ Español
├ Deutsch
├ 日本語
└ FrançaisSelecting a language switches the reader to the equivalent page in that locale — they stay on the same topic, just translated.
Automatic language detection
The first time a reader arrives, Doxbrix chooses a default locale intelligently:
If the reader has chosen a language before, that preference is used.
If the URL includes a locale (e.g. /es/...), that locale is used.
Otherwise, the reader's browser Accept-Language is matched to an available locale.
If none match, the project's default language is shown.
The reader can always override the detected choice with the switcher, and their selection is remembered for future visits.
URL structure
Each locale has its own URL path, which keeps languages independently shareable and indexable:
https://docs.example.com/docs/quickstart ← default locale
https://docs.example.com/es/docs/quickstart ← Spanish
https://docs.example.com/ja/docs/quickstart ← JapaneseLocalized URLs are linked with hreflang tags so search engines serve the right language to the right searchers (see SEO & site layout).
What gets localized
Switching language localizes the entire reader experience, not just the page body:
| Element | Localized? |
|---|---|
| Page content | ✓ |
| Navigation (groups, pages) | ✓ |
| Search index and results | ✓ |
| Site assistant answers | ✓ (responds in the active locale) |
| UI labels (e.g. "Was this helpful?") | ✓ |
| Headers and footers | ✓ where translated |
Fallback behavior
Translation is rarely 100% complete at all times. When a page isn't yet translated into the reader's locale, Doxbrix falls back gracefully:
- The reader sees the default-language version of that specific page.
- An optional notice indicates the page hasn't been translated yet.
- The rest of the site stays in the reader's chosen language.
This means you can roll out translations page-by-page without breaking the experience for readers on partially translated locales.
The AI assistant in multiple languages
The site assistant is locale-aware. A reader on the Spanish site can ask a question in Spanish and get a Spanish answer — even drawing on content that's only authored in your default language, which the assistant can translate on the fly while citing the original source.
Configuring the switcher
The switcher appears automatically once you enable more than one locale in Settings → Localization (see Multi-language). You can configure:
- The order locales appear in the dropdown.
- Whether to show native names, English names, or locale codes.
- Whether to show the not-yet-translated notice on fallback pages.