Multi-language support lets one project serve readers across several locales without forcing each language into a separate documentation site. In Doxbrix, locali...
Multi-language support lets one project serve readers across several locales without forcing each language into a separate documentation site. In Doxbrix, locali...
Multi-language support lets one project serve readers across several locales without forcing each language into a separate documentation site. In Doxbrix, localization is handled as part of the project model, so structure, page slots, and reader experience can stay aligned across languages.
How localization works
- Every project has a Default language
- You can add more locales through Enabled locales
- New locales can inherit the existing structure through Clone structure for new locales
- Readers can switch languages on the published site where locale coverage exists
This is useful because it keeps one project as the system of record, even when several language variants are being maintained in parallel.
Set up localization
You can enable more than one language during project creation through Multi-language docs, or later in Localization inside Project settings.
Open Project settings, then select Localization.
Confirm Default language and choose the URL structure that fits your publishing model.
In Enabled locales, click Add locale. For each locale, review the values for Language, Display label, and Code.
Turn on Clone structure for new locales if new locales should inherit the current navigation and blank page structure.
Understand what gets copied
When Clone structure for new locales is enabled, Doxbrix copies the current structural model into the new locale:
- spaces
- navigation hierarchy
- page slots
What it does not copy is finished translation work. Authors still need to create or review the localized content for each page.
This approach is usually better than starting from a blank locale because it preserves parity across the navigation model while still allowing localized page content to be authored intentionally.
Translate content per locale
Once a locale is enabled, authors can work on the translated version of each page as its own maintained document. This supports workflows such as:
- writing directly in the editor with reviewers checking terminology and accuracy
- pulling source content through the CLI and translating through an external process
- rolling out locale coverage gradually rather than translating the entire site at once
Plan the editorial workflow, not just the settings
Multi-language documentation works best when the operational model is clear. Decide:
- which locale is the source of truth
- who owns updates when the source language changes
- how translated pages are reviewed
- how incomplete locale coverage should be communicated to readers
Without that process, multi-language support can create structural parity but editorial drift.
Best practices
- Enable only the locales you intend to maintain well
- Translate high-value pages first, then expand gradually
- Keep commands, code samples, and product names consistent across locales
- Check page layout and visual balance in preview before publishing
- Revisit older translated pages when the source content changes substantially