Translation gets reviewed. The built page often does not.

A string can be correct in the file and wrong on the screen — truncated in a button, breaking mid-word in Chinese, sorting incorrectly in a dropdown, or sitting next to a date format nobody in that market reads. None of those are translation errors. All of them reach the customer.

Localization testing is the step that catches them, and it happens on the built artifact, in context, on the devices the market actually uses.

Working Assumption

Most post-launch localization bugs are not translation defects. They are integration defects — correct text placed into a layout, a format, or a code path that was never verified in that locale.

Internationalization testing vs localization testing

These get collapsed into one step, which is why the same bugs recur every launch. They ask different questions and they run at different times.

Internationalization (i18n) testing asks whether the build can support any locale. It runs once, on the codebase, ideally before translation begins. Can the interface hold longer strings? Is text externalized rather than hardcoded? Does the encoding survive non-Latin characters? Are dates and numbers formatted by locale rather than assumed?

Localization (L10n) testing asks whether this locale is right. It runs per language, on the built site, after translation. Is the terminology correct for this market? Does the layout hold with this language’s actual text? Are the market’s conventions respected?

Running i18n testing first is what makes L10n testing cheap. Skip it, and every language rediscovers the same structural bug.

The checklist at a glance

• Internationalization readiness — 6 checks: externalized strings · encoding · locale-aware formatting · layout tolerance to expansion · bidirectional support if needed · pseudo-localization pass
• Language in context — 5 checks: terminology against the glossary · tone and register · truncation and abbreviation · placeholder and variable handling · legal and safety wording
• Layout and typography — 6 checks: text expansion · line breaking · font fallback · vertical rhythm · images with embedded text · responsive behaviour at each breakpoint
• Functional and data formats — 6 checks: dates and times · numbers and currency · addresses and phone formats · sorting and search · form validation · units of measure
• The pre-launch pass — 4 checks: hreflang and language switcher · SEO metadata per locale · legal pages and consent · real-device spot check in market

Each section below expands these into what to actually look at.

Internationalization readiness

Do this before translation, once, on the codebase.

• Strings are externalized. No user-facing text hardcoded in templates or code. If a string cannot be extracted, it cannot be translated or tested.
• Encoding is end to end. UTF-8 through storage, transport and display. Test with a string that combines CJK, accented Latin and an emoji; anything that mangles is a pipeline problem, not a font problem.
• Formatting is locale-aware. Dates, numbers, currency and pluralization resolved by locale rather than hardcoded to the home market.
• Layout tolerates expansion. German and French commonly run 20–35% longer than English; Russian and Finnish can run longer still. Fixed-width buttons and single-line labels are where this surfaces first.
• Bidirectional support, if any RTL market is on the roadmap. Retrofitting RTL after launch is significantly more expensive than allowing for it now.
• Pseudo-localization pass. Replace strings with accented, lengthened equivalents that remain readable — [Ĉöñƒïŕɱ öŕðéŕ……]. Every hardcoded string, truncation point and layout break shows up immediately, in one pass, before a single word is translated.

Language in context

Now per language, on the built site.

• Terminology matches the glossary. Not “is it a reasonable translation” but “is it the approved term for this market” — checked against the same list the whole content set uses.
• Tone and register fit the surface. A microcopy string, a legal paragraph and a marketing headline should not read as if one person translated all three the same way.
• Truncation and abbreviation are deliberate. Where text was shortened to fit, confirm the short form is still correct and idiomatic — not the first N characters.
• Placeholders and variables resolve correctly. Word order changes between languages; a sentence assembled from fragments in English order can be nonsense elsewhere. Check every interpolated string with real data.
• Legal and safety wording is market-correct. Warranty, privacy and safety text must satisfy local requirements, not just read accurately. This needs local review, not translation review.

Layout and typography

• Text expansion holds. Check the longest realistic string in each component, not the average one.
• Line breaking is correct for the script. Chinese, Japanese and Thai do not break on spaces; naive breaking splits words and, in Japanese, can strand punctuation at the start of a line.
• Font fallback is intentional. If the brand font lacks CJK coverage, the fallback is what customers actually see — so it should be chosen, not inherited.
• Vertical rhythm survives. CJK glyphs sit differently against Latin baselines; line height set for English often looks cramped in Chinese.
• Images with embedded text are localized or replaced. Text baked into an image is invisible to the translation pipeline and to search engines.
• Every breakpoint is checked. Expansion that fits on desktop often breaks the mobile layout, which is where most of the traffic is.

Functional and data formats

• Dates and times. Order, separators, 12- versus 24-hour, and time zone display. 03/04 is two different days depending on the reader.
• Numbers and currency. Decimal and thousands separators invert between markets; currency symbol placement and spacing differ.
• Addresses and phone numbers. Field order, postal code format and whether the form even accepts the local shape.
• Sorting and search. Alphabetical order is language-specific, and CJK sorting has multiple valid schemes. Search must match how users actually type, including without diacritics.
• Form validation. Name fields that require a Latin alphabet, postcode patterns that assume one country, and phone validators that reject valid local numbers are among the most common conversion killers.
• Units of measure. Converted where the market expects it, not merely translated.

The pre-launch pass

Takeaway

Run internationalization testing once on the build before translation, then localization testing per language on the built site. A pseudo-localization pass before any translation exists finds most structural defects in a single sweep — and is the cheapest test on this list.

• hreflang and the language switcher. Tags correct and reciprocal for every locale; the switcher visible and landing on the equivalent page rather than the homepage.
• SEO metadata per locale. Titles, descriptions and structured data localized — not left in the source language, and not machine-filled.
• Legal pages and consent. Privacy, terms, cookie banner and consent text present in the local language and satisfying local requirements.
• A real-device spot check in market. Ideally by someone in that market, on a device and network typical there. Rendering, font availability and load behaviour all differ from a developer’s machine.

Where this fits

This checklist covers verifying what was built. The decisions that determine how much there is to verify — scope, update workflow, review ownership, terminology — happen earlier, and are covered in the website localization checklist.

If you are planning a multilingual launch and want the testing layer run properly rather than squeezed into the last sprint, our multilingual web and product content service includes it as part of the workflow. To get a read on your current setup, start here.