Localization Testing Guide: Checklists, Examples, and Workflow

A German customer entered 1.234,50 as an invoice amount. The UI displayed €1,234.50 after saving, while the API stored 123450 minor units. The value happened to be correct, but the reformatted display made the customer think the decimal had moved. In a second locale, the same parser stored 123 minor units. Translation review had passed because no sentence was wrong.

Localization testing follows meaning through input, storage, display, documents, and integrations. A locale is more than a language code. Region, currency, calendar, numbering system, time zone, legal copy, and address conventions may all affect the outcome.

Define locale scope as a contract

List supported language-region pairs, fallback rules, currencies, time zones, channels, and platforms. en-US, en-GB, and en-IN share language but differ in dates, address expectations, terminology, and sometimes business policy. State whether users choose locale, inherit it from an account, or receive it from the device or browser.

Create a compact release matrix:

Add the source locale as a control and one unsupported locale to verify fallback. Record the translation bundle version and content freeze. Without those, a retest can silently use different words.

Test internationalization before translation arrives

Run pseudo-localization on builds while strings are still changing. One pseudo-locale should expand text and add visible markers; another should exercise right-to-left layout if the product supports RTL locales. Pseudo text exposes hard-coded strings, concatenation, clipping, and assumptions about character width without pretending to judge a real language.

Check that every user-facing string comes from resources, variables are named rather than positional where word order varies, plural forms are supported, and components can grow vertically. Search logs and resource output for missing keys and source-language fallback.

Use characters that exercise Unicode normalization and multiple scripts in names, searches, filenames, and free text: José, Zoë, Łukasz, 李雷, and Arabic text. Do not use them as stereotypes or assume they represent all locale rules. They are diagnostic data for encoding, storage, sorting, and rendering.

Build test data around regional decisions

Prepare data that makes locale behavior observable:

Keep the expected canonical value beside each display expectation. For the German amount, expected storage might be integer minor units 123450, while expected display is determined by the approved formatter. Never derive the expected display by calling the same formatter used by the product.

Use a synthetic customer and an unmistakable reference such as L10N-DE-0710-04. Retain API payloads and database values so a visual symptom can be traced through layers.

Validate numbers, money, dates, and time

Test entry and display separately. A localized input may accept locale separators, while an API contract may require a canonical numeric value. Paste values as well as typing them. Confirm invalid mixed separators produce a clear error instead of a guessed amount.

For money, verify currency symbol or code, placement, spacing, negative format, decimal digits, rounding grain, and conversion effective date. Never compare currencies by symbol alone because symbols can be ambiguous.

Date evidence should include the stored instant, source time zone, displayed local value, and offset. Use cases before and after daylight-saving transitions for relevant zones, plus midnight crossings. A booking at 2026-10-25T00:30:00Z should be checked against the product’s declared time-zone rule, not the tester’s laptop clock.

An API capture can make the boundary explicit:

{
  "invoiceRef": "L10N-DE-0710-04",
  "locale": "de-DE",
  "currency": "EUR",
  "amountMinor": 123450,
  "issuedAt": "2026-07-10T08:30:00Z"
}

The json block should remain locale-neutral for numeric storage while retaining locale as presentation context. Review the actual product contract before assuming every API uses minor units.

Review translation inside the working flow

Give the native reviewer the goal, audience, screen context, variables, and preceding action. A spreadsheet cell cannot show whether “Charge” is a noun, a verb, or a battery state. Review navigation, calls to action, error recovery, empty states, confirmation, legal consent, notification, and generated documents as a connected journey.

Inspect placeholders carefully. The translated sentence must retain every required variable exactly once, place it grammatically, and format it for the locale. Test values with long names and special characters. HTML or Markdown from variables must not become executable simply because it passes through a translation template.

A review record should distinguish mistranslation, terminology inconsistency, grammar, tone, untranslated text, placeholder corruption, truncation, and functional behavior. That classification sends work to the right owner.

Exercise layout and bidirectional behavior

Review at the smallest supported viewport and at enlarged text or zoom. Look for clipped buttons, overlapping badges, single-line assumptions, ellipsized critical values, broken tables, and icons separated from labels. Screenshot comparison can flag changes, but a person must decide whether information remains understandable.

For RTL locales, verify overall direction, mixed Arabic and Latin text, phone numbers, email addresses, dates, currency, breadcrumbs, progress steps, input caret, selection, and directional icons. Not every icon mirrors. A back arrow often does; a media play icon normally does not. Follow the product’s approved design semantics.

Do not force fixed-height components to preserve a screenshot. Let content reflow. A translated destructive action must never become visually indistinguishable from a safe secondary action because one label wrapped.

Test search, sort, forms, and external channels

Search with accents, case variation, composed and decomposed Unicode, partial terms, and locale-specific characters. Define whether accent-insensitive matching is expected. Sorting by raw code point rarely matches user expectations, but the required collation must come from product policy.

Forms need country-specific rules without overfitting. Change country and verify labels, required fields, validation, autocomplete, and previously entered values. Test a legitimate address that lacks a state or uses an alphanumeric postal code. Do not require a “first name” and “last name” structure unless the business truly needs it.

Follow the transaction outside the UI. Check email subject and body, push notification, SMS length behavior, PDF font embedding, CSV encoding, payment page, tax invoice, support transcript, and deep link. Confirm locale context survives asynchronous jobs. A French UI that sends an English receipt is a single-flow defect.

Automate invariants and sample meaning manually

Automate missing and duplicate resource keys, placeholder parity, locale smoke paths, canonical values, date and currency formatter tests, screenshot coverage for stable screens, and fallback behavior. Run a small critical flow for every supported locale and deeper functional coverage for representative risk groups.

Exercise fallback with a deliberately missing non-critical key and with a missing mandatory legal string. The first may fall back to an approved parent locale; the second may need to stop the release or hide the feature. Change locale during an authenticated session and confirm caches, server-rendered content, and background messages adopt the documented rule. Mixed-language pages often come from cache keys or asynchronous jobs that omitted locale context, not from absent translations.

Keep linguistic judgment with qualified reviewers. Automation cannot decide whether wording is respectful, natural, legally appropriate, or consistent with domain terminology. Provide reviewers with structured expected behavior and capture their decision as evidence rather than an informal chat approval.

Failures should record locale, region, time zone, platform, viewport, resource version, test data, expected canonical value, actual display, screenshot, and payload or log. “Looks wrong in German” is not reproducible.

Make the locale release decision visible

Before release, confirm critical journeys pass end to end, no mandatory string falls back unexpectedly, placeholder and plural checks are clean, canonical data remains correct, documents and messages use the intended locale, native review is signed off, and open issues have impact and ownership.

Report by locale rather than presenting one global pass percentage. One blocked payment flow in fr-CA cannot be averaged away by nine passing English pages. Localization confidence comes from preserving the same business meaning while allowing each supported locale to express it naturally.