Plan a Bilingual Website So the Two Versions Stay Consistent

If your English service page says weekday visits only while the French page still offers Saturdays, customers are seeing two different promises. Planning a bilingual website means deciding how a confirmed business change reaches both versions, who reviews the wording and what happens before the update goes live.

Start with a list of paired pages and the people responsible for them. Include the smaller pieces of the journey, such as menu labels, form instructions and confirmation messages. Those need to reflect the same service facts as the main page, even when the wording differs.

Decide what each language needs to explain

Identify who will use each version and what they need to do. For a service business, that might mean understanding the offer, checking where it is available and sending an enquiry. Plan enough content in each language to support those tasks, and record any deliberate differences rather than leaving missing pages to chance.

Keep language and market decisions separate. An English and French website for one Canadian service area is a different project from separate Canadian and US offers. W3C distinguishes a multilingual website from one intended for an international audience. Serving two countries does not, by itself, tell you which languages your customers need.

Agree on the facts that must stay aligned: what is included, who the service suits, where it is offered, any limits and what happens after someone contacts you. Let the wording read naturally in each language. The reviewer should be able to check it against the agreed facts, rather than trying to resolve an unclear service policy through translation.

Language scope also needs an owner. Decide who can confirm business details, who can assess the language for the intended audience and who can make the website changes. One person may cover several roles, but supplying text and approving its meaning are still separate tasks. These planning decisions do not establish which legal obligations apply to your business.

Connect the matching pages

Give the maintainer a page-pair list, with the English address beside its French counterpart. Google recommends separate URLs for different language versions, appropriate hreflang annotations and links that let visitors choose a language. It also advises against automatically redirecting visitors based on an assumed language. These are implementation considerations, not promises of search visibility.

For two languages, visible links labelled “English” and “français” are a straightforward option. W3C’s language-navigation guidance favours direct links for a small set of versions and names written in the target language. Check the destination as well as the label: someone reading about a particular service should reach the corresponding service page when it exists.

If there is no equivalent page, make that limitation clear. Do not label an unrelated homepage as though it were the same information in French. Decide what useful route the visitor can take instead, and record the missing content so it has an owner.

Follow one service change through both versions

Consider a fictional home-maintenance business planning to stop weekend visits from a future transition date. Until that change takes effect, its existing weekday-and-weekend offer remains accurate. The owner has approved the planned service change, but the website work is still in preview.

The register below is an invented example, not a client project or a completed test. Its French entries describe the meaning and review state of a fictional draft in English. They are not French translations and do not demonstrate translation quality.

In your own record, add the affected page addresses and where each message is managed. Keep the approved service facts, intended effective date and review evidence beside the open issue. “French received” is not enough to show whether someone has checked the meaning, whether the right version is in the preview or whether it has been published.

For this fictional planned change, the team can coordinate the update before the offer changes. If your service has already changed and the live site is making a false promise, arrange a prompt, accurate correction through your authorised process. Do not leave known misinformation online simply to wait for the next routine release. Agree how the correction will be reviewed in each affected language.

Review the whole enquiry path in each language

Read each version as a customer would, from the service page through the menu and into the enquiry. Check service names, available choices, instructions, validation errors and the final message. A translated page can still lead into a form that uses older wording or switches language unexpectedly.

W3C’s form-notification guidance calls for clear success and error feedback, including instructions for correcting mistakes. Apply that check in both languages. If the form requests a visit rather than confirming an appointment, its messages should make that distinction clear in each version.

Use an agreed preview and fictional details for any test submission, with a test destination that the receiving team knows about. Compare what the visitor sees with what reaches that destination. Agree separate permission before testing a live form that sends messages or creates records. Record which routes you checked; one successful submission does not establish that every path works.

Ask the language reviewer to assess meaning and terminology, and the maintainer to check the implementation. View the actual text on a narrow screen too, looking for clipped labels, awkward buttons or instructions separated from the field they explain. Check the language switch from more than the homepage.

There is also a page-language setting to verify. W3C recommends declaring the default text language with HTML’s lang attribute. That is a different task from connecting alternate pages with hreflang. Google says it determines a page’s language from visible content, not the lang attribute. Have the maintainer check both functions rather than treating one setting as a substitute for the other.

Make the next update easier to manage

Keep the page-pair list where the people changing the service information can use it. When an offer, price, service area or contact detail changes, open the relevant record and identify the affected language versions and messages. Assign the review before the update disappears into separate email threads.

Finish by recording what actually went live and checking it against the approved change. A preview approval and a public-page check answer different questions. If something is still unresolved, leave it with a named person and a clear next action.

If you are considering ZXP’s website services, bring your intended languages, paired-page list and one example change to the scope discussion. Include who will supply and review each language. That gives the team a useful basis for agreeing the content, responsibilities and website work, without assuming translation is included.