How to test a multilingual website: locales, currencies, dates, URLs, and fallbacks
A multilingual website is not simply the same page with different words. Changing language can also change currency, date formatting, navigation, page URLs, and the space required by a label. This guide explains how to cover those differences with shared automated scenarios instead of cloning the entire suite for every language.
Why one copy of every test per language breaks down
Consider the same checkout in English, Czech, and Slovak. With three copied tests, every checkout change has to be implemented three times. Before long, one copy uses the new delivery flow, another still targets the old screen, and the third runs successfully while asserting a different business outcome.
Language and region are also easy to conflate. English for the United Kingdom may use a different currency, time zone, and date format from English for the United States. A locale therefore represents an agreed combination of linguistic and regional conventions, not merely the label displayed in a language switcher.
Share the scenario and control the locale matrix
Separate behaviour from localised data
Keep the checkout steps and expected business outcome in one scenario. Supply the language, region, currency, expected URL, and necessary text values through configuration. The test then receives different inputs without duplicating the logic that defines success.
Find controls using stable semantics or an agreed test identifier. A selector tied to the English word “Continue” fails in Czech even when the application is working correctly. The broader guide to preparing a website for test automation explains the other conditions that keep a scenario maintainable.
Check more than translated labels
- Language selection and persistence: the switcher selects the correct variant and, where the product requires it, the choice survives a refresh, sign-in, and navigation to the next step.
- Numbers, currencies, and dates: use a fixed source value and compare the rendered result with the rules for that locale. Unicode CLDR provides locale data for dates, times, numbers, and currency symbols, but the product still needs explicit rules for the markets it supports.
- URLs and navigation: the locale path, domain, or parameter remains correct after internal navigation or a redirect, and when using browser history. Define what should happen when a localised URL does not exist.
- Unicode and layout: enter names with diacritics, longer strings, and, where relevant, other scripts or writing directions. Confirm that text does not cover a button, tables remain usable, and a saved value can be read back unchanged.
- Fallback behaviour: if a translation key or whole locale is missing, the application should use the agreed fallback language or show a controlled error. A raw translation key or empty heading is not an acceptable fallback.
Playwright can emulate browser locale and time zone. That setting does not necessarily switch every application: the product may derive language from the URL, account, cookie, or a server header. Set the same inputs that the real product uses, then assert the visible output and business outcome.
Run combinations according to risk
The primary locale can receive broad coverage on regular changes. Other languages can run critical journeys plus checks for their specific risks, such as an address form, currency formatting, or a right-to-left layout. As with a cross-browser test matrix, coverage should reflect actual usage, supported markets, and the impact of a defect.
A short multilingual smoke suite can run at a suitable point in CI/CD. A wider matrix may run overnight or before release so that it does not delay every small change.
What functional automation cannot judge
An automated check can expose missing copy, a wrong currency, a broken URL, or text overflowing its container. It cannot judge whether a translation sounds natural, uses the right tone, or carries the intended cultural meaning. Linguistic review and an SEO audit of localised pages—including hreflang and indexation—are separate activities outside this functional test.
What you gain
- One maintained scenario rather than several drifting copies.
- Verification of both the business outcome and regional differences.
- A smaller matrix driven by usage and risk.
- A clear boundary between functional automation, linguistic review, and SEO.
Next step
List the supported language-and-region combinations. For each, record the critical journey, currency, date format, URL rule, and expected fallback. Use that information to create one shared scenario and run it against a small matrix selected by risk.