Websites with Bilingual Content: Resolving Language Switching Before Drawing the First Layout

Language switching on a bilingual website should let someone continue the same task in another language without losing their place. Before choosing where the switcher sits, map the equivalent pages, confirm what is translated and decide what happens when an equivalent does not exist.

A small language control can hide a substantial content decision. Changing the navigation labels while leaving service information, downloads or contact instructions untranslated may produce a route that looks complete but stops being useful halfway through. Resolve that route before the first layout.

Agree what the two language versions provide

List the visitor tasks the website must support in each language: understanding the offer, exploring work, checking practical details and making an enquiry. Identify the content required to complete those tasks, including any documents or external destinations.

Two languages do not necessarily mean two different audiences or two different offers. Someone may prefer to read a technical explanation in one language while working in a country where another is spoken. Avoid assuming that the selected language also identifies their location, customer type or needs.

If the business actually serves distinct audiences, plan that difference separately. The guide to resolving two competing user journeys helps distinguish an audience-specific route from a language version of the same route.

Agree the translation scope with the people responsible for the content. A smaller, complete bilingual route can be more useful than a larger set of partially translated pages. Record any deliberate differences and explain them where visitors would otherwise expect the same material.

Map equivalent pages before placing the switcher

Create a pairing table using stable content identifiers. Each entry should record the page purpose, both URLs, translation status and the destination offered by the language control. Do not rely on replacing a word in the URL and hoping the corresponding page exists.

This fictional English–Italian example illustrates the planning document. The paths are examples, not routes on the SavianoDesign website.

Content item	English example	Italian example	Switching decision
Studio introduction	/en/studio/	/it/studio/	Open the equivalent introduction
Website service	/en/web-design/	/it/progettazione-siti/	Keep the visitor on the same service
Project case study	/en/work/project-a/	Translation not ready	Explain the gap and offer an explicit alternative
Contact information	/en/contact/	/it/contatti/	Preserve the purpose of the enquiry

The URL words can differ while the content remains equivalent. The pairing needs to express the relationship rather than infer it from spelling. Give a renamed page the same content identity so future editorial changes do not silently break the switch.

Google’s guidance for multilingual sites recommends separate URLs for different language versions and links that let visitors choose between them. Stable language URLs also give your team concrete destinations to review and share.

Keep the choice recognizable and available

Use readable language names, such as “English” and “Italiano,” and make the current language clear. A country flag is a poor sole label because a language can be used in several countries, and a country can have several languages.

Place the control consistently across pages. With two languages, a visible alternative-language link may be enough. A dropdown adds behaviour to specify, including its label, opening action, focus treatment and keyboard operation.

Plan the narrow-screen version at the same time. If the language choice moves into the mobile menu, visitors must still be able to find and operate it without understanding every word in that menu. A familiar, clearly labelled language control should not depend on hover.

Avoid forcing a change based only on an inferred location or browser preference. Google’s multilingual guidance advises against automatic language redirects that can prevent access to versions. An optional suggestion can leave the choice with the visitor; an explicitly shared language URL should remain usable.

The website navigation guide explains how consistent labels and predictable control behaviour support the wider journey.

Decide how to handle a missing translation

Do not send every language switch to the other homepage without explanation. Someone reading a project would lose the context they just chose. Likewise, a translated navigation label should not imply that the destination’s main content is available in that language when it is not.

Agree a visible fallback. For example, the page might say that this case study is currently available only in English and offer an explicitly labelled Italian portfolio overview. The visitor can then choose whether to continue with the original or explore the alternative.

When no useful equivalent exists, do not present a dead or misleading switch. Keep the availability message clear and offer a relevant route that actually exists. If the page is essential to a core task, completing its translation may be a launch requirement rather than a fallback problem.

Distinguish a missing translation from a different service offer. A business may provide a service in one market but not another; that needs an accurate explanation. Translating a button cannot make the underlying offer available.

Translate the journey around the page

Review the navigation, page heading, body copy, captions, alternative text, link labels and next-step instructions together. Include helpful error or empty-state messages where the interface uses them. A fluent main paragraph cannot compensate for an unclear action at the end.

Check downloads and external links explicitly. If a brochure is available in only one language, label that before the visitor opens it. If an external booking or enquiry provider uses its own language settings, verify what happens and explain any limitation in the route.

Keep operational promises accurate. A website offering English content does not automatically mean the team provides telephone support in English. State the actual contact options and have the business approve them.

For a site with several branches, distinguish translated wording from facts that should remain consistent, such as addresses and visiting arrangements. The guide to organizing multi-location information helps identify a maintained source for those facts.

Allow space for translated text to grow. Review longer headings, buttons and navigation labels before fixing their dimensions. Where the languages use different reading directions, include that behaviour in the implementation brief rather than treating it as a final text replacement.

Define the technical language signals accurately

The visible switcher, the page’s language declaration and search annotations serve different purposes. Document all three so the implementation does not assume one replaces the others.

W3C’s guidance on declaring language in HTML explains using the lang attribute on the html element and marking passages in another language where appropriate. This tells software the language of the text; it does not translate the content.

Google’s localized-version guidance describes hreflang annotations for equivalent language or regional pages. When using them, list the page itself and its actual alternates, use fully qualified URLs and maintain reciprocal references. Do not claim an unfinished or unrelated page as a translation merely to fill a pair.

Give each genuine translated page an appropriate search title and description. Keep canonical decisions consistent with the published content; do not automatically point all translations at the original-language page as a shortcut. Check the generated pages and links, not only the translation spreadsheet.

Assign update responsibilities in both languages

Record who approves the original content, who reviews the translation and what happens when either changes. Service scope, contact instructions and dates need a coordinated review because an outdated translation can give a different promise.

Historical content also needs agreement on names, approximate dates and explanatory context. The guide to organizing a long company history helps settle the source story before it is translated.

Time-sensitive information needs a stronger update plan. If a program closes for registration, both versions should communicate that status. Use the guide to expired and upcoming seasonal content to separate activity dates, booking deadlines and editorial review dates.

Test a small set of complete routes in both languages: arrive directly on a service page, switch language, inspect a project and find the appropriate contact. Include a missing translation, a narrow screen and keyboard navigation. Ask a competent reader of each language to check meaning as well as grammar.

Common questions

Should the language switch always open the other homepage?

Prefer the equivalent page so visitors can continue their task. If that translation is unavailable, explain the limitation and offer a clearly labelled alternative. A homepage fallback should be an explicit choice, not a surprising loss of context.

Does every page have to be translated before launch?

The priority is a complete, accurate route for the tasks promised in each language. Some supporting material can remain untranslated if its availability is clear. Essential service and next-step information should not disappear halfway through the route.

Is adding a translation widget enough for a bilingual website?

A widget does not settle page equivalence, terminology, content ownership or the contact experience. Evaluate its output and behaviour against the same planning questions. Important business statements and time-sensitive details still need an agreed review process.

Plan your bilingual website with SavianoDesign

SavianoDesign’s Web Design service can bring language routes, content hierarchy and responsive layouts into a complete website design or redesign, with front-end requirements agreed around the project.

Explore the Web Design portfolio and contact Francesco about your website. Share the current site, the languages required and the reviewed copy available. Translation, editorial approval and any external service dependencies can then be assigned clearly in the brief.