A bilingual website can display good translations and still leave customers stranded when they try to ask a question. The service page may be available in two languages while the form, confirmation and follow-up take the reader back to just one. Test the whole journey with a colleague who uses each language. Give them the same realistic task and let them decide where to begin. The result should tell you whether people can find the service, understand what the business needs from them and recognise that their message reached the right team.

Set up one task with a clear outcome

Choose a routine enquiry the business actually receives. A customer might want to check whether a service is available in their area and ask how to arrange a visit. Give both testers the same fictional customer details, location and objective. Ask them to start on the relevant public page in a staging environment. Give them a second route from a saved link to the other language so you can also test a reader who arrives directly.

Decide in advance what counts as success. The customer should find the correct service, identify the information needed to proceed and submit an enquiry without exposing unnecessary personal details. They should see what the business will do next. The staff member who receives the test should be able to identify the service and reply in the language the customer chose. Avoid judging the test by the fact that a form technically accepted a submission.

Check that switching language keeps the reader in place

Ask the tester to change language while reading the service page. The matching version should open at the equivalent service, or explain clearly when a translation is unavailable. Sending the reader to the homepage forces them to find the page again and makes it harder to tell whether both versions describe the same service. Repeat the switch on a phone, where a menu icon can conceal the control.

Look for labels people who use the language will recognise. A country flag may be ambiguous where several languages are common. A text label also gives you something straightforward to check with a keyboard or screen reader. Ask the tester to return to their preferred language and check that the next service page keeps that choice where the site is designed to remember it. Treat that preference as a convenience and make it easy to override.

Complete the form, including a mistake

Start by leaving a required field empty. Check that the message explains what to fix in the same language as the form. The tester should be able to find the affected field, correct it and try again without typing everything from the beginning. Repeat with an unsupported value that makes sense for this business, such as a postcode outside the delivery area if that rule really applies. Check that the form distinguishes a service restriction from a formatting problem.

Read the field labels together with the helper text. A business might ask for a location, a preferred time and a short description. Each label should tell the reader what to provide and avoid requesting details the team does not use. Check whether long translated labels wrap cleanly. A button that fits in one language can cover an error message or run off a small screen in another.

For a Kuching service website, bring a real example like this to the discussion with a Kuching web design team. A short walkthrough with the people who will answer enquiries can reveal wording and routing decisions that a translation document alone leaves open.

Follow the message all the way to the recipient

Use a staging inbox or another agreed test destination. Ask the receiving staff member to read the message without looking at the test notes. Can they identify which page generated it, the requested service and the language to use in their reply? A generic subject line can make two otherwise correct messages hard to distinguish, especially if several locations share an inbox. Give staff an easy way to identify the source without adding unnecessary customer information.

Then check the confirmation the visitor sees on the page. It should state what happened and set a realistic expectation for the next step. If the business sends an email acknowledgement, inspect its subject, content and links as well. Check a reply from the staff member in the normal tool they use. If the message must be reassigned, ask the next person to find the language preference before responding.

Repeat the journey when something fails

An enquiry flow should have a clear response when a message cannot be delivered. Test a safe failure in staging with the person responsible for the system. Check what the visitor sees, whether the data they already entered is retained when appropriate and whether someone receives an alert. Avoid showing the same success text after both successful and failed deliveries. If a phone number or alternative channel is offered, confirm that staff can actually handle an enquiry in the stated language.

Try one narrow viewport, one keyboard-only pass and one slow connection. The aim is to see whether the person can complete the journey without relying on a desktop layout or immediately loaded scripts. Keep a small list of reproducible issues. An entry should say which language and page the tester used, the action they took and what appeared. That is enough for the designer or developer to reproduce the problem.

Write down the handover decision

Group issues by what they prevent. A broken confirmation or misdirected enquiry can stop the launch. A wording improvement with a clear workaround can have a named owner and due date. Ask the colleague who originally found a serious issue to repeat that part of the test after the fix. Test both languages again when they share the same form code or routing rules.

Save the two test enquiries and the checks alongside the website handover notes, using fictional data. Give someone responsibility for retesting after changes to service areas, team inboxes, form fields or language navigation. The final handover should show that a customer can move from the service page to a clear reply in either supported language, and that the business knows who owns each step.

Prepared by Blackstone Intelligence Sarawak for teams planning service websites.