A multilingual website is ready when a customer can understand the offer, make an informed choice and take the next step in the language they selected. A translated homepage is only one part of that journey. The service page, enquiry form, confirmation and person answering the enquiry all need an agreed role.
This multilingual website launch checklist helps a small business prepare a brief and review a delivery. Start with a page-and-language worksheet, then follow one real customer task through every planned language. You will finish with a practical release decision: which journeys are ready, which need correction and which should wait.
1. Choose languages you can support after launch
Write down who needs each language and what they should be able to do. An existing customer asking for support has different needs from a new visitor comparing services. Use enquiries, conversations and your team's experience to choose the first journeys. Avoid adding a language simply because the software makes another menu item easy to create.
Separate language from commercial availability. A French page can explain a service to French speakers in several countries; it does not establish where you deliver that service. Record the locations you serve, the currency you actually charge and the language in which someone can expect a reply. Keep those decisions visible in the brief.
Choose a manageable first release. You might launch a complete service enquiry journey in two languages while a third remains in preparation. Give every proposed language a named reviewer and an operational contact. If nobody can check the wording or respond to customers, resolve that gap before promising a full experience.
2. Make a page-and-language map before translating
List the pages needed to complete the chosen task: arrival page, service details, supporting information, enquiry and confirmation. Include navigation labels, button text, validation messages, image descriptions and downloadable documents. These smaller pieces are easy to miss when the brief counts only full pages.
For each page and language, record the source version, translation status, reviewer, destination URL and next action. Use explicit states such as “not started”, “in review”, “approved” and “checked in browser”. Approval of a text document and approval of the finished page are different milestones.
| Item to record | Example entry | Decision it supports |
|---|---|---|
| Customer task | Ask about a service in French | Which pages and messages belong in the release |
| Content owner | Service lead approves the source copy | Who can resolve a changed promise |
| Language reviewer | Named French reviewer, with an agreed review date | Whether the language can be accepted |
| Next destination | French enquiry page and confirmation | Whether the journey keeps its language |
| Open issue | Download is available only in English | Translate it, label it clearly or postpone it |
The entries above illustrate a planning method, not a delivered client project. Build your own worksheet around the task your customers need. Count translated page versions and shared interface messages separately so a quotation does not hide a large amount of review work behind a small page count.
3. Approve the meaning as well as the words
Stabilise the source copy before translating it. Agree service names, inclusions, exclusions, price wording and the action each button describes. Keep a short terminology sheet with preferred terms, terms to avoid and names that stay unchanged. Include tone and formality so one page does not address a customer very differently from the next.
Ask the language reviewer to read for decisions: can a visitor tell what is offered, what they must provide and what happens next? A fluent sentence can still promise more than the source. Check qualifying words carefully, including “from”, “up to”, “estimated” and “optional”. Keep a record of questions that need the business owner's answer.
Review examples and practical details locally. Make dates unambiguous, identify the currency and check phone numbers, address instructions and business hours where they appear. Translation should not silently change an actual price or create a service commitment for a region you do not cover.
Use a short change log
If the source offer changes during review, mark every affected language as needing another check. A simple entry can say what changed, which page versions are affected and who will approve them. This avoids a release where the English page describes a new package but another language still sells the old scope.
4. Keep the customer's language through the next step
Use that as a starting point for a reviewable journey. Agree what switching language does on a service page, a guide and an enquiry page. Where an equivalent exists, make that equivalent the destination. When it does not, choose an honest fallback: explain what is available, offer a suitable translated page or keep the unfinished version out of the selector.
Write the fallback into the acceptance notes. Sending someone to an unrelated homepage without explanation can make them repeat their search. A language selector should also be recognisable to someone who cannot read the current page. Use language names that the intended readers recognise, and check the control on a narrow screen.
Follow the main button beyond the page. Check the language of the form labels, required-field errors, success message and any confirmation the agreed workflow sends. If booking, payment or support happens in another tool, inspect that handoff too. State any unavoidable language limitation before a customer starts the action.
A hypothetical enquiry journey
Imagine a consultancy preparing English and French service pages. Its French copy is approved, but the booking tool and appointment confirmation are English-only. The team records that limitation, agrees clear wording before the booking link and assigns someone who can answer French enquiries. It can then decide whether that limited journey is acceptable or whether booking should wait. This is a planning example, not a client outcome.
5. Ask for a small, inspectable technical handover
You do not need to write code to request evidence. Ask for a list of the final page addresses and the language each page presents. Open the links yourself. Confirm that each address leads to the intended content without requiring a previous visit or an unexplained change of language.
Ask the developer to check that the declared alternatives represent equivalent pages. Request a short exception list for missing translations, retired pages or regional differences. A technical report should make those decisions easier to inspect, with actual addresses rather than a generic statement that multilingual setup is complete.
Include the declared page language in the handover checks. Also ask which pages are intended for search and whether the final titles, descriptions and preferred URLs match that plan. Keep private previews and unfinished material out of the public release. Treat these as checks on the implementation; they do not establish search rankings or confirm that a page has been indexed.
6. Review each language in the finished layout
Give reviewers the actual pages on a phone and a desktop, using the same version intended for release. Longer headings, compound words and expanded button labels can behave differently from the source text. Check navigation, cards, tables and form messages with the longest realistic wording you intend to publish.
Ask someone to complete a task without explaining where to click. Can they find the service, understand its limits, change language and reach the correct next step? Record the page, language, device, observed problem and expected result. “French mobile menu covers the enquiry button” gives the developer something concrete to fix.
Include keyboard navigation, visible focus, readable text at increased zoom and meaningful image descriptions in the review. Check that important information remains available if a decorative image is absent. A screenshot is useful evidence of appearance, but it cannot prove that a button, language switch or form journey works.
Agree controlled test arrangements for any action that creates an enquiry, booking or message. Identify the test recipient, expected confirmation and person checking the result. Keep real customers out of the test. Save the result and retest corrected failures on the version that will actually ship.
7. Decide what ships and who keeps it current
Review the worksheet language by language. Treat an incorrect offer, an unusable main action or an unexplained language dead end as a reason to hold that journey. Record lesser wording or presentation issues with an owner and a planned correction. Avoid an overall “looks good” approval that hides an unfinished language.
- Content: the named reviewer has approved the offer, limitations and next-step wording.
- Journey: the agreed task works through the final destination, with any language limitations disclosed.
- Pages: final addresses, language alternatives and page-language declarations have been checked.
- Presentation: the actual release version has been reviewed on the agreed screens and input methods.
- Operations: someone owns enquiries, future translations and correction of stale information.
- Release: someone authorises publishing and knows how to restore the previous version if necessary.
After launch, use the same worksheet when prices, availability or service scope change. Record the affected languages, reviewer and publication date. Schedule that review around actual business changes and your team's capacity. Maintaining a smaller, accurate language set is a sensible starting point when review resources are limited.
Prepare a useful website brief
Send your page-and-language map, approved source copy, available reviewers and any external booking or contact tools with the enquiry. Our website project brief guide helps organise the wider project. The Doggo Paradiso case shows the published scope of a site with Spanish, English and Catalan pages.
Digital Studio's website service starts at EUR 2,190 for a one-off build of up to five pages using supplied content, with responsive design, SEO foundations, one lead form and launch on your domain. Languages, pages, supplied content and review responsibilities are agreed before the price and timing are confirmed. Do not assume every translation or check in this guide is included in the starting package.
Describe the multilingual website you need, including the first customer task you want to support. The enquiry is free and requires no payment. A clear language scope gives both sides something concrete to price, build and accept.
