A multilingual website project needs a content plan as well as a language selector. Before requesting a quotation, decide which customers you need to serve, what they need to read and who will handle their enquiries. Translating navigation while leaving the important service explanation or confirmation message in English can leave the customer journey unfinished.
This buying checklist helps a small business specify the work and judge whether it is ready to publish. It does not assume that every page needs every language, or that adding languages will automatically produce customers.
1. Start with customer tasks and language evidence
List the tasks customers already ask you to complete: understand a service, check an area you cover, request a quotation or change a booking. Use actual enquiries and feedback to decide which languages would help. A language being widely spoken in your city does not establish that its speakers want your particular service.
For each proposed language, name a person who can approve the wording and a person who can respond after submission. These may be different people. If you cannot support telephone conversations in that language, explain the available contact route accurately.
2. Build a page-and-language matrix
Use a matrix in the project brief instead of asking for an unspecified number of translated pages. The following is an illustrative starting point, not a completed customer project.
| Page or message | Language coverage decision | Content owner | Acceptance evidence |
|---|---|---|---|
| Main service page | Complete in the languages supported for this service | Service manager and language reviewer | Approved wording and equivalent live addresses |
| Contact form | Labels, help text, errors and confirmation in each supported form language | Enquiry owner | A labelled submission received and understood |
| Project examples | Translate selected relevant examples; identify unavailable equivalents | Business editor | Accurate language navigation on every example |
| Opening hours and service area | Keep operational facts consistent across versions | Operations contact | Matching approved facts in each version |
| Future announcements | Decide whether simultaneous translation is required | Publishing owner | Documented update and review process |
This table exposes work that a page count misses. It also lets suppliers price and scope the same requirement. Link the matrix to your wider website project preparation brief.
3. Specify how visitors reach equivalent pages
Ask what address each language version will use and how someone switches while reading a specific page. Switching language should lead to the equivalent service where it exists, with a clear alternative where it does not.
Google recommends separate URLs for language versions, with user-selectable links rather than forced language redirects. This gives you a useful question for a proposal: can each intended version be opened directly and shared?
Your developer should document how equivalent pages are associated. Google’s localized-page guidance describes alternate-language annotations. These support interpretation; they are not a promise of indexing or rankings.
4. Include the complete reading and enquiry experience
Review more than paragraphs. Navigation, buttons, image captions, downloadable documents, validation errors and enquiry confirmations all belong in the brief. Decide whether existing photographs contain embedded text that needs a separate version.
Where a language reads from right to left, include layout testing rather than assuming that replacing text completes the work. Check mixed-direction details such as phone numbers, addresses and product references. The W3C internationalization tips cover language declarations, form formats, character encoding and text direction.
Agree who reviews automated translations before publication. Technical delivery and language approval are separate responsibilities; a functioning page is not evidence that its wording is accurate.
5. Use practical acceptance tests
Ask the reviewer to carry out these tasks on a phone and a larger screen:
- Open a language-specific service address directly, without first visiting the homepage.
- Switch to its equivalent and back without losing the service context.
- Read headings, buttons and long labels without clipping or overlap.
- Trigger a form error and check that the correction is understandable.
- Submit one labelled test and confirm that the intended recipient receives the language and enquiry details.
- Change an operational fact in a preview and demonstrate how equivalent versions are identified for review.
Record the tested address, language, device, outcome and unresolved issue. Do not mark every version approved because one language passed.
6. Commission a maintainable first release
A smaller, complete language journey can be more manageable than a large collection nobody can keep accurate. Separate the initial page set from possible later expansion, and identify translation, publishing and enquiry responsibilities in the proposal.
Nolixia’s website and integration services can be discussed against that scope. Send your current website, intended languages, priority pages and translation approval arrangements to request a project conversation. Include how customers will reach the pages and what should happen after an enquiry so the proposal addresses the whole journey.
