How to test a service website when a customer changes their preferred language
How to test a service website when a customer changes their preferred language
Published by Blackstone Intelligence.
A release checklist for keeping the service, enquiry details and next steps intact when a visitor changes language.
Choose the point where the customer switches language
Write down one realistic reason a visitor would switch language halfway through a task. In a fictional appliance repair business, a customer finds the English page through a search, then changes to Malay to check the appointment requirements with a family member. The business wants them to stay on the same service and keep the same next step. Ask staff to name two or three situations they actually encounter. One might begin on a phone, another with a shared link, and another inside a form. Use those situations to decide what the site should preserve. A tester can then distinguish a legitimate change of wording from an accidental change of service, location or enquiry details.
Check the service page and its counterpart
Start with a service page several levels down in the menu. Note the service name, selected branch and any filters that matter to the decision. Change the language through the real site control and confirm the translated page represents the same offering. The customer should be able to find the corresponding section even if headings are longer or sections appear in a different order. Run the same test from the translated page back to English. In the fictional repair example, a switch from a washing machine repair page should lead to washing machine repair in the other language. Sending the visitor back to the main menu creates another search task. If a translation does not exist, show that clearly and offer a useful route from the current page.
Try switching with a partly completed enquiry
Fill in a test enquiry using invented details. Choose a repair category, provide a description and select an available branch. Switch languages before submitting. Confirm which fields carry over and whether the labels still correspond to the original selections. Pay particular attention to dropdowns whose internal values are stable but whose labels are translated. Check what happens if an attachment was selected. Some browsers or form designs may require the customer to select the file again. In that case, explain it clearly before sending them away from the page. Repeat with an invalid entry and check whether the field error is translated. Agree with the team which details may be held temporarily and when they should be cleared. Avoid using real customer information in this test.
Follow a shared link and use the back button
Copy the translated service URL and open it in a fresh browser window. The intended language and service should be clear without relying on the preferences of the original tester. Then open a link from an older test email and check how it interacts with a language already chosen on that device. Set an explicit rule for whether the language in the link or the stored preference takes priority. Use the browser back button after a switch. The browser should return to the page the visitor expects without bouncing repeatedly between versions. Try the same sequence on mobile. It is easy to miss a loop if testers always start on the homepage or never use the browser history.
Test a missing or outdated translation
Choose a service with a deliberately incomplete translation in a test environment. Decide which information is essential before a visitor can act. Prices, eligibility, service limits and cancellation conditions need particular care because a partially translated message can change the meaning. A helpful fallback might keep the reader on the current page, explain which language is available and show a clearly labeled contact option. Review the source and translated versions after a policy update. Ask who owns each language and how staff know when the other version needs attention. Record a visible date only where it helps readers judge the currency of the information. A checklist that simply says both pages exist will miss differences that matter.
Check validation, confirmation and the staff inbox
Run a complete enquiry in each language. Use a bad test value to trigger validation, correct it, and submit. Read the confirmation on the page and any acknowledgement email. The customer should be able to recognise the service they chose and understand what will happen next. Check that the staff inbox receives the same service, branch and message in both cases. If language preference is passed to the team, make sure staff can distinguish it from the language of the page that happened to receive the enquiry. Confirm what staff should do if nobody on shift can reply in the preferred language. A clear handover note can be more useful than an automated message that promises a response the business cannot deliver.
Include keyboard and assistive technology checks
Ask someone to reach and operate the language selector using a keyboard. They should be able to identify the current language, open any menu, select another language and see where focus lands on the new page. Check that the language indicator is understandable without relying on flags or colour. Where the site includes passages in more than one language, ask a tester using assistive technology to listen to a short sample. Verify that the site declares the correct language for the document and marks language changes where appropriate. Run one mobile check with a longer translated label. Make sure the selector remains visible, the page does not scroll sideways and any fixed header leaves enough room to read the content.
Hand over a small set of release checks
Keep one worksheet with the start URL, original language, chosen language, service, form state and expected outcome. Add a short description of the evidence so a second person can reproduce the test. Agree which failures delay release. A lost enquiry, a different service selected after switching, or a misleading translation of important conditions should receive a clear owner. When briefing a team about web design services, share the worksheet and one fictional customer journey before layouts are approved. Ask the team to demonstrate the same steps on the live release using safe test records. Repeat those checks after changes to navigation, translations or the enquiry form. This gives the business a practical routine it can carry out without needing access to the source code.
Blackstone Intelligence is a technology consultancy based in Kuching, Sarawak, and operated by Blackstone Consultancy Sdn Bhd. It provides AI consulting and automation, web design and development, custom software development, and digital marketing services.