Define a publishing system, not a translation feature
Multilingual website requirements should define target language and region combinations, stable locale URLs, relationships between equivalent pages, language switching and fallback, content and review ownership, CMS fields and publishing states, localized actions, accessibility, search metadata, analytics, integrations, quality evidence, change propagation, and retirement. Translating visible paragraphs is only one part of the release.
Start with one page family and one conversion journey in the first two launch locales. Include a page that does not exist in every locale, a source-page update, a form, a local claim or disclaimer, and a retired offer. Those cases expose governance, URL, routing, analytics, and stale-content decisions that a translation plugin demo hides.
Use the website requirements checklist for the whole brief. This guide adds the locale relationships, operating model, and evidence needed when more than one language or region is in scope.
Separate language, region, market, and legal scope
Language answers how content is written. Region or market may change availability, price, currency, units, contact routes, imagery, examples, terms, consent, delivery, or support. Google distinguishes multilingual sites from multi-regional sites in its multilingual and multi-regional site guidance. Define the exact combinations you will operate rather than treating country, language, and currency as interchangeable.
Create a locale inventory with language tag, region when needed, script or reading direction, domain or path, page families, content owner, reviewer, forms, lead destination, analytics view, consent behavior, and support path. State which content is globally shared, adapted, locally authored, legally reviewed, unavailable, or intentionally redirected.
Do not promise every language on every page unless the team can maintain it. A smaller complete launch—with core journeys, truthful availability, and owned updates—is safer than dozens of thin locale shells. If physical locations also vary, pair this plan with the multi-location website requirements.
Give every locale edition an explicit content contract
Model a page family separately from its locale editions. The family can hold shared intent, product relationships, component eligibility, and required actions. Each edition needs its own stable URL, slug, title, description, body, assets, language, region, owner, review state, source revision, publication date, local action, structured data, and relationship to alternates.
Avoid a single “translated” flag. Useful states include not required, queued, translating, adapted, under review, approved, scheduled, live, stale, blocked, withdrawn, and archived. Show why an edition is blocked and whether its existing live version remains valid after a source change.
Design CMS workflow around source changes and accountability
Choose whether one locale is a source, several markets author independently, or a shared product record feeds locally owned pages. Define translation memory and terminology use, machine translation boundaries, human review tiers, comments, revision history, preview, approvals, scheduling, rollback, and who may override a source update.
| Content risk | Examples | Suggested evidence |
|---|---|---|
| Low | Navigation labels, stable help text, non-critical summaries | Language review, layout check, link and search test |
| Commercial | Offers, comparison copy, forms, calls to action | Market owner approval, routing test, analytics event proof |
| Sensitive | Legal, privacy, safety, finance, regulated or binding claims | Accountable specialist approval and retained revision evidence |
| Dynamic | Inventory, prices, product data, user-generated or frequently changing content | Source contract, fallback, freshness monitor, failure handling |
For every source edit, capture the changed facts, affected page families, impacted locales, required review, due date, current live validity, and release decision. A headless or traditional CMS choice matters less than whether the chosen system can enforce this workflow without spreadsheets and silent overwrites.
Specify language switching, layout, forms, and accessibility
Keep direct locale URLs available and make switching a user choice. Define whether the switcher moves to the equivalent page or a locale home when no equivalent exists, how it names languages, whether it remembers a preference, and what happens to a partially completed form. Google advises against automatic language redirects that prevent users or crawlers from reaching every version in its multi-regional guidance.
Test text expansion, wrapping, truncation, dates, numbers, addresses, currencies, names, search, sorting, fonts, downloads, images containing words, left-to-right and right-to-left layout, keyboard order, focus, validation, errors, and status messages. Translate accessible names, alt text, captions, transcripts, form instructions, and document metadata—not only visible body copy.
W3C's WCAG guidance requires the page language and changes in language to be programmatically determinable. Its language-of-parts explanation describes how language markup supports correct pronunciation by assistive technology. Include the broader website accessibility requirements in design and acceptance rather than treating localization as a separate final pass.
Make locale relationships crawlable, reciprocal, and testable
Give indexable language editions separate URLs. Decide the subdirectory, subdomain, or country-domain pattern; normalize trailing slashes and parameters; and define redirects for old or changed locale routes. Each live edition should normally have a self-referencing canonical. Equivalent regional variants may need both canonical and locale relationship decisions based on whether the main content is actually distinct.
Google's localized versions documentation supports HTML, HTTP header, or sitemap methods for declaring alternates and says every language version must list itself and the other versions. Choose one maintainable source of truth for complete, reciprocal sets. Do not emit an alternate for a draft, error, redirect, or placeholder page.
Localize titles, descriptions, headings, body copy, image text alternatives, structured data values, social metadata, internal links, breadcrumbs, and sitemap discovery. Keep one primary language per page rather than placing full translations side by side. Validate rendered HTML and crawl paths, not only CMS records or plugin settings.
Operate every source change through a locale release lifecycle
Define triggers for new pages, changed claims, design-system updates, navigation changes, media replacement, form changes, product withdrawal, market exit, and regulatory review. The workflow should identify affected locale editions, preserve the live approved version when appropriate, prevent accidental publication, and expose stale or blocked work to owners.
Monitor availability, indexability, alternate-set completeness, broken internal links, missing translations, source-to-locale revision lag, forms, lead routing, analytics coverage, consent, and conversion by locale. Define alert thresholds and repair owners without inventing a single cross-market performance benchmark.
Retirement needs the same discipline as launch. Decide whether to update, withdraw, redirect, archive, or return a gone status; remove invalid alternates and sitemap entries; preserve required records; and test bookmarks, inbound links, language switching, forms, and analytics after the change.
Use this two-locale multilingual website release worksheet
- Audience: Which language, region, market, and user situation does each locale serve?
- Journey: Which page family, search path, form, and post-submit owner complete the first release?
- URLs: Which route model, canonical, alternate set, switch, fallback, and redirect rules apply?
- Content: What is shared, adapted, local, dynamic, unavailable, sensitive, or independently authored?
- Workflow: Who translates, reviews, approves, publishes, monitors, and retires each risk level?
- Experience: Which scripts, directions, expansion, formats, forms, accessibility, and assets must be tested?
- Evidence: What proves content accuracy, technical relationships, routing, analytics, and recovery?
- Decision: Which evidence supports platform configuration, focused extension, custom build, narrower rollout, or delay?
Scope the first release around real journeys, not a target count of translated strings. A maintainable multilingual site is a content operation with software support. If the workflow and discovery model are clear, a focused website development project can implement the smallest complete locale system and expand it from evidence.
Frequently asked questions
What should multilingual website requirements include?
Include target languages and regions, locale codes, URL structure, page relationships, language switching, fallback behavior, content ownership, translation and review workflow, CMS fields and states, localized metadata and structured data, accessibility, search and hreflang rules, forms and routing, analytics, integrations, QA scenarios, migration, change propagation, and retirement.
Should each language have a separate URL?
For indexable multilingual pages, usually yes. Stable, crawlable locale URLs make each version linkable and allow explicit relationships between alternates. The team still needs to choose a subdirectory, subdomain, or country-domain model and define canonicals, hreflang sets, sitemaps, redirects, and fallback behavior consistently.
Is automatic translation enough for a multilingual website?
It may help produce a draft or cover low-risk content, but requirements must still define human accountability, terminology, local claims and actions, design expansion, accessibility, metadata, legal review where relevant, and what happens when the source changes. The risk of the content should determine the review path.
How should a multilingual website be tested before launch?
Test complete page families and user journeys for every launch locale, including direct entry, language switching, unavailable translations, right-to-left layout where applicable, forms, search, metadata, canonicals, hreflang reciprocity, sitemaps, structured data, analytics, consent, redirects, source updates, withdrawn pages, and mobile and assistive-technology use.