Translate the journey, not just the header
A multilingual site needs translated navigation, page content, form labels, validation, loading, errors and success states. A language URL alone does not establish that the visitor receives a usable translation.
Treat UI language and article availability separately. The studio interface may support fifteen languages while a particular editorial article has only English and Russian variants. Show the real variants; do not silently present the English body as a new translation.
Give every variant its own stable URL
Choose a clear structure such as /en/services/design. Keep one preferred canonical URL for each translated page. Link equivalent variants with hreflang, including self-reference and reciprocal references. Google’s localized-version guidance explains these relationships and the optional x-default fallback.
For articles, group equivalents by a stable translation-group identifier. Slugs may differ by language. The relationship should not depend on two titles happening to match.
| Visitor action | Expected behaviour |
|---|---|
| Switch language on a service | Open the equivalent service page |
| Switch language on an article with a translation | Open that actual translated slug |
| Switch to a language without this article | Open its blog index with an honest availability state |
| Submit an invalid form | Receive validation in the active interface language |
Prevent silent fallback
A translation checker should report missing or empty keys, raw keys and suspicious unchanged paragraphs. Keep an explicit exception for project and technology names. Do not exempt entire paragraphs because they contain a brand name.
Automation cannot establish linguistic quality. Review important copy with native readers, especially commercial meaning and form instructions. Use right-to-left layout for Arabic and test long labels, narrow screens and mixed-direction contact details.
Publish content variants deliberately
Fetch only published articles during the build. Generate only their real routes and language alternatives. Removing a publication requires a new deployment in a static architecture; changing a database status does not recall HTML already served by the host.
Connect website architecture and technical SEO around the same language and route inventory. Verify the generated output after every content release.
A practical question
Should we publish English text under every language URL?
No. Expose only actual translated articles and reciprocal equivalents. A translated interface can honestly link to the available language variants without inventing translations.