Localization Testing: How to Test Multilingual Websites

To test a multilingual website, use two layers: first verify that the product supports different scripts, locales, formats, and writing directions; then test each localized version for functional parity, visual defects, linguistic accuracy, and market fit. Automate repeatable checks across locales, inspect real pages at multiple viewport sizes, and have qualified reviewers assess language and cultural context. This sequence follows Microsoft and W3C guidance (Microsoft internationalization testing, Microsoft localization testing).

1. Define what you are testing

Internationalization testing asks whether the application can handle different languages, scripts, locales, time zones, units, and market conventions. Localization testing asks whether a specific localized version works correctly and is suitable for its target language and market. Address internationalization defects early; otherwise they can surface repeatedly in each translation.

Make a target matrix before testing. “Spanish” or “Arabic” alone may not define the locale behavior you need to verify.

Dimension	Record
Locale	Language and relevant regional variant, such as the locale identifiers your product supports
Script and direction	Writing system, left-to-right or right-to-left direction, and mixed-script cases
Platforms	Supported browsers, devices, operating systems, and narrow and wide viewports
Journeys	Language switching, search, sign-in, forms, checkout, errors, and other critical tasks
Market behavior	Dates, numbers, names, addresses, phone numbers, units, legal needs, and local workflows

2. Prepare the application and test data

Keep source content translation-ready

Use clear, consistent source wording. Avoid slang, culture-specific references, and sentences assembled from separately translated fragments. Word order can change between languages, so translators need whole messages with context. Keep text separate from layout and avoid baking translatable copy into images where possible. W3C’s Internationalization Quick Tips covers translation expansion, text in graphics, language, direction, and other web content concerns.

Use realistic test values

Prepare names, addresses, phone numbers, dates, currencies, and user-entered text that represent the supported markets. Include non-Latin scripts, accented characters, combining marks where relevant, long strings, punctuation, and mixed-direction values such as a Latin URL inside Arabic text. Test data should exercise the actual field limits and validation rules.

Use pseudolocalization early

Pseudolocalized strings can expose hard-coded text, missing translation resources, fragile concatenation, clipping, and expansion problems before real translations are ready. Test pseudo versions both functionally and visually. For right-to-left targets, a pseudomirrored interface can reveal layout assumptions. Pseudolocalization does not validate the accuracy or cultural appropriateness of a real translation.

3. Check internationalization foundations

Encoding and multilingual input

Declare and serve UTF-8 consistently for pages and relevant responses; check the document and HTTP headers.
Enter multilingual text through forms, submit it, save it, retrieve it, and display it again. Inspect the browser, API, application, and storage path if characters change or disappear.
Test search, sorting, and validation with the characters and scripts your product supports.

W3C recommends UTF-8 for web content, and the Unicode Consortium’s web FAQ discusses consistent encoding for multilingual pages and databases.

Language and direction metadata

Check that the page declares its primary language and that sections in another language identify their language where appropriate.
Verify right-to-left direction at the document or component level where needed. Check mixed-direction text containing names, numbers, punctuation, and URLs.
Inspect fonts and glyph coverage for each script; missing glyphs, unsuitable fallbacks, or incorrect shaping can make otherwise valid text unreadable.

Locale-sensitive behavior

Check display and input behavior for dates, times, numbers, currencies, units, names, addresses, and phone numbers. Verify sorting, capitalization, and validation under each relevant locale. Do not assume that a format or valid character set from the source market is suitable elsewhere. Microsoft’s internationalization test guidance includes target-market formats and conventions, sorting, casing, units, and paper sizes.

4. Test functional parity in every locale

Reuse automated test cases across localized versions when the tests and application are sufficiently globalized. A test should select a locale explicitly and verify user-visible outcomes rather than relying only on source-language text.

Switch language and region, then verify the expected locale persists through navigation and reloads.
Complete critical journeys: account creation, sign-in, search, forms, checkout or equivalent, and support contact.
Check menus, links, errors, confirmations, empty states, and validation messages. Confirm each intended journey can be completed in every supported locale.
Submit locale-appropriate data and verify it is accepted, stored, and presented consistently.
Check that language switching does not strand the user on a missing route or silently return them to the default language.

Functional parity means the localized versions support the intended product tasks. It does not necessarily mean every locale has identical content or market features; record deliberate regional differences separately from defects.

5. Check translated text in the layout

Review actual localized pages at narrow and wide viewport sizes. Include long and short translations, larger text settings where relevant, and real font rendering. Look for:

Clipped or overlapping text, unexpected wrapping, awkward line breaks, and controls that no longer fit.
Buttons, menus, tables, dialogs, labels, validation messages, and navigation that overflow or become difficult to use.
Missing glyphs, incorrect font fallback, line-height problems, and script rendering defects.
Text embedded in images or graphics that was not localized.
For right-to-left interfaces, correct reading direction and usable mirrored layout where appropriate, plus correct handling of left-to-right fragments.

To check whether a translation fits the layout, compare the localized page against the same task in the source locale, exercise strings likely to expand, and inspect the actual rendered page at supported sizes. Do not rely solely on a character-count estimate: line breaks, font metrics, and control constraints affect fit.

6. Validate language and market fit with people

Automation can catch many layout and functional regressions, but it cannot reliably judge idiom, meaning in context, terminology, tone, or cultural suitability. Ask qualified reviewers familiar with the target language and audience to check grammar, terminology, meaning, formatting, imagery, humor, and culturally or politically sensitive content. Review local features, legal requirements, audiovisual material, and support access where relevant. Microsoft treats functional, visual, linguistic, and other market risks as distinct parts of localization testing (localization testing guidance).

7. Use web diagnostics and browser automation appropriately

W3C Internationalization Checker

The W3C Internationalization Checker reports page-level international settings such as encoding, language declarations, and text direction. It considers markup and HTTP headers and can provide warnings and suggestions. Use it as an initial diagnostic, not as proof that a site is fully localized or that translations are correct.

W3C i18n test suite

The W3C i18n test repository contains standard HTML and interactive tests for internationalization features, including browser and font support. Some server-side checks, such as those based on HTTP headers, rely on W3C-hosted pages. The repository also describes tests as educational and exploratory, so do not treat every test as a complete pass/fail localization suite.

Automated browser checks

Browser automation is useful for repeating the same journey across locales and viewport sizes. Use stable selectors and assertions that account for expected translations and regional differences. Keep human review for linguistic quality and cultural fit. Microsoft recommends automation where tests are sufficiently globalized and manual validation where coverage is incomplete.

8. A repeatable release checklist

List supported locales, scripts, direction, devices, and critical journeys.
Run encoding, metadata, font, and locale-format checks with representative data.
Run pseudolocalized functional and visual checks before translations are complete.
Run critical automated journeys against each actual localized version.
Inspect rendered pages at narrow and wide sizes, including RTL and mixed-direction cases.
Arrange qualified language and market review for changed or high-risk content.
Log each issue with locale, browser/device, steps, expected and actual result, screenshot or text example, severity, and whether it is global or locale-specific.
Retest affected journeys after fixes and retain a regression set for supported versions.

9. Capture visual evidence across locales

Screenshots make layout regressions easier to discuss and compare, especially when a defect occurs only in one locale or viewport. Capture the same route and state for each comparison, and record the locale, viewport, browser, and steps with the image. A screenshot can show clipping or direction problems; it cannot establish that a translation is accurate or culturally appropriate.

For repeatable checks, use browser automation when you need interaction, assertions, and control of the test environment. For a quick page capture or a capture pipeline, ScreenshotNeo is a website screenshot API and MCP server. Its capture options include viewport and device presets, full-page capture, CSS selectors for a single element, custom CSS and JavaScript, and locale-relevant controls such as timezone and geolocation. These options can help produce comparable visual evidence; they do not replace language review.

Or skip the browser setup

For a quick screenshot of a localized page, call the ScreenshotNeo API with the target URL. See the ScreenshotNeo API documentation for request options and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/fr -o shot.webp

The API also works from Python and Node.js:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/fr"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/fr' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server provides screenshot tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

Troubleshooting common failures

Symptom	Likely cause	What to check or fix
Accented or non-Latin characters appear as replacement symbols	Encoding is missing or inconsistent along the page, request, application, or storage path	Check UTF-8 declarations and response headers, then trace the same test value through submission, storage, retrieval, and rendering.
Text is present but glyphs are boxes or shapes are wrong	Font coverage, fallback, or script rendering is unsuitable	Inspect the actual font loaded for that script and test on supported browsers and devices.
RTL text reads incorrectly or punctuation appears misplaced	Direction metadata or bidirectional handling is wrong for the page, component, or embedded value	Check direction declarations and test mixed-script strings with numbers, punctuation, and URLs.
Translated text overlaps or gets cut off	Layout assumes source-language string lengths or fixed control dimensions	Test longer localized and pseudo strings at multiple widths; allow wrapping or adjust the layout.
A locale journey fails despite the page looking translated	Routes, validation, persistence, or an interaction remains tied to the default locale	Repeat the complete journey in that locale and inspect navigation, submitted data, errors, and reload behavior.
A page-level checker reports warnings	Metadata, encoding, or direction may be absent or inconsistent; a warning may also need context	Review the markup and HTTP headers, correct applicable defects, and verify the rendered behavior. The checker is diagnostic, not a full localization verdict.
Automated text assertions fail across languages	The test expects source-language copy or ignores intentional regional differences	Use locale-aware expected values or assert stable behavior and accessible structure instead of one fixed string.
Visual comparison changes on every run	Dynamic content, timing, fonts, animation, or changing page state affects captures	Stabilize test data and page state, wait for the relevant content, and compare equivalent viewport and locale conditions.

Performance, reliability, and cost

Run inexpensive foundation and smoke checks on every relevant change, then reserve full locale-by-browser-by-viewport visual review for release candidates or changed areas. Prioritize critical journeys and high-risk scripts or markets rather than multiplying every dimension blindly. Reuse stable automated cases, but keep enough real localized content to expose expansion and rendering issues.

Visual capture pipelines are useful evidence, not an oracle. Dynamic pages and delayed fonts or content can make captures inconsistent; wait for the state under review and keep the environment comparable. A successful screenshot says nothing by itself about translation quality. Budget language-aware human review according to the content’s risk and change rate. The research sources provide no universal defect-rate or cost benchmark, so estimate from your own locale count, browser matrix, journey coverage, and review needs.

FAQ

How do I test a multilingual website?

Check internationalization foundations first, then verify functional parity, visual quality, language accuracy, and market fit for each supported locale.

How do I check whether a translation fits the layout?

Render real and pseudo-translated content at supported viewport sizes and inspect wrapping, controls, fonts, and overflow. Include long strings and actual script rendering.

How do I test a website in Arabic or another right-to-left language?

Test a real RTL locale, direction metadata, mirrored layout where appropriate, and mixed-direction values such as URLs, names, numbers, and punctuation. Have a qualified reader check the language and usability.

Can an internationalization checker approve my localization?

No. It can flag technical page settings, but it cannot validate the full user journey, translation quality, or cultural suitability.

Can visual automation replace a language reviewer?

No. Automation can repeat layout and functional checks; qualified people need to assess meaning, idiom, terminology, and market context.