Localization Testing

i18n, l10n and g11n: what is being tested

Internationalization (i18n) is an engineering property: the product is built so that it can be adapted to any locale without changing the code. Text lives in resource files, not in templates; dates, numbers and currencies go through locale-aware formatting APIs; text direction is not assumed; storage and transport are Unicode end to end. Localization (l10n) is the adaptation to one locale: translated strings, locale formats, local content, legal texts, payment methods, address and phone formats. Globalization (g11n) is the umbrella term for the business and engineering effort that combines both so one product can be offered in many markets.

The distinction matters because the defects differ. An i18n defect lives in the code and appears in every locale — a hard-coded currency symbol, a concatenated sentence, a date parsed with a fixed pattern. An l10n defect lives in one locale’s content — a wrong term, a missing translation, a wrong address format. i18n defects are cheapest to find before any translation exists, with pseudo-localization; l10n defects need the real translation and, for language quality, a native speaker.

• Locale — identified by a BCP 47 language tag (RFC 5646): ar, ar-SA, hi-IN, en-IN. The language subtag selects the translation; the region subtag selects formats, currency and calendar defaults.
• Internationalization testing — can the product support locales at all? Run it with pseudo-localized text, Unicode data, right-to-left direction and non-default formats.
• Localization testing — is this particular locale right? Translation in context, formats, cultural fit, layout with real strings.

The map of localization testing

Localization testing spans areas that need different skills and different data. Use this map to plan coverage per locale; the sections below go through each area, and right-to-left layout is covered in depth in the RTL testing guide.

• Language and translation quality — terminology, context, completeness, plural and gender forms, message parameters, truncation.
• Locale formats — dates and calendars (Gregorian and Hijri), times and time zones, numbers and digits, currencies, units, addresses, phone numbers and personal names.
• Text and script handling — encoding, Unicode normalization, grapheme clusters, fonts, sorting, searching and input methods.
• Layout — text expansion and contraction, line height for scripts with marks above and below the line, and for Arabic the whole right-to-left mirroring and bidirectional-text area.
• Locale selection and fallback — how the product chooses a locale (user setting, Accept-Language header, device, URL), what happens for an unsupported locale, and whether the choice carries over to emails, PDFs, SMS and push notifications.
• Accessibility per locale — the lang attribute that tells a screen reader which voice and pronunciation rules to use, and translated accessible names for icons and controls.

Language and translation quality

Translators usually work from a spreadsheet or a translation-management system without seeing the screen, and many translation defects come from that. The English "Save" can be a verb (save a file) or a noun (a discount); "Open" can be a status or a command; a translator without context picks one. The tester’s job is to review every string on the real screen and to report the string key together with the screenshot, so the fix lands in the right resource.

Plurals are the most common structural defect. English has two cardinal plural forms. The Unicode CLDR plural rules give Arabic six categories — zero (0), one (1), two (2), few (numbers whose last two digits are 3–10, such as 3 or 103), many (last two digits 11–99) and other (for example 100–102) — and Hindi two, where the "one" form covers 0 and 1. Code that chooses the form with count === 1 is wrong for Arabic by construction. The fix is a message format with plural categories; the test is a table of counts that hits every category.

• Terminology consistency — one term per concept across screens, help pages and emails, checked against the glossary. Calling the cart "سلة" on one screen and "عربة" on another is a defect.
• Untranslated strings — English left inside the Arabic or Hindi interface; typical in validation messages, API errors, emails and strings added late in a sprint.
• Concatenated strings — sentences assembled from fragments ("You have" + n + "items") cannot be translated correctly because word order and agreement differ; each sentence must be one message with parameters.
• Message parameters — the {name} or %s inside a translation must survive unchanged; a translated or deleted parameter shows raw braces or crashes the formatter.
• Gender and register — Arabic verbs and adjectives agree with gender; decide how messages address the user and check that the decision is applied consistently.

# ICU MessageFormat, Arabic: one message, six CLDR plural categories
cart.items = {count, plural,
  zero  {السلة فارغة}
  one   {منتج واحد في السلة}
  two   {منتجان في السلة}
  few   {# منتجات في السلة}
  many  {# منتجًا في السلة}
  other {# منتج في السلة}
}

# Counts that hit every Arabic category
0 (zero) · 1 (one) · 2 (two) · 3, 10, 103 (few) · 11, 99 (many) · 100, 101, 102 (other)

# Hindi has two categories: one (0 and 1) and other
0, 1 (one) · 2, 5, 1.5 (other)

Pseudo-localization: find i18n defects before translation

Pseudo-localization replaces every UI string with an automatically transformed version that the team can still read: accented letters, extra length, and brackets marking the start and end of each message. Run the product in the pseudo-locale and every defect class that does not need a real translation shows at once — hard-coded text stays plain English, a concatenated sentence shows several bracketed pieces, truncation cuts off the closing bracket, and characters outside ASCII expose encoding problems.

Android provides two pseudo-locales that can be enabled for debug builds: English (XA), which adds accents, expands the text and brackets each message, and AR (XB), which switches the direction to right-to-left and reverses the characters, so a team can find mirroring and bidirectional problems without knowing an RTL language. On the web, a pseudo-locale is usually one more resource file generated during the build from the source strings.

Source (en):           Save changes
Pseudo (expanded):     [Ŝàṽé çĥàñĝéš ·····]
RTL pseudo:            same text, base direction switched to right-to-left

What each symptom on screen means:
  Save changes            -> hard-coded string, never externalised
  [Ŝàṽé] [çĥàñĝéš]         -> sentence assembled by concatenation
  [Ŝàṽé çĥàñĝ             -> truncated: no room for longer translations
  [Ŝ?ṽ? ?ĥ?ñĝ?š]          -> characters lost in an encoding conversion

Dates, calendars and time zones

A date format is more than the order of day and month. The locale decides the calendar, the month names, the digits, the separators, the first day of the week and the 12- or 24-hour clock. In Saudi Arabia two calendars are in everyday use: the Gregorian calendar and the Hijri calendar, which Saudi Arabia standardises as the Umm al-Qura calendar. Products often show both or let the user choose; every place that shows, accepts, stores or compares a date must be clear about which one it uses.

Do not assume what "ar-SA" produces. Locale defaults come from the CLDR data inside the runtime and change between versions: older runtimes formatted ar-SA dates in the Hijri calendar by default, while recent ones use the Gregorian calendar with Arabic-Indic digits. Request the calendar and numbering system explicitly — for example with the Unicode locale extensions ar-SA-u-ca-islamic-umalqura or ar-SA-u-nu-latn — and test the result on every runtime you ship: server, browsers and mobile. Different Hijri calculations (Umm al-Qura, tabular civil) can place the same day on different dates, so a conversion test must name the calendar, not just "Hijri".

Time zones come from the IANA tz database. Asia/Riyadh is UTC+03:00 and Saudi Arabia does not observe daylight saving time; Asia/Kolkata is UTC+05:30, also without daylight saving. That makes DST defects invisible in local testing and real for users in Europe or North America. Store instants in UTC or with an explicit offset (ISO 8601), convert to the user’s zone only for display, and test a half-hour offset, a zone that observes DST, and times close to midnight, where the calendar day shifts.

• Each date field states its calendar; choosing a date in a Hijri picker stores the same value as choosing the equivalent Gregorian date.
• Month and year ends: Umm al-Qura months have 29 or 30 days; test the last day of a month and of a year in both calendars.
• Midnight shift: an order placed at 01:30 Riyadh time falls on the previous day in UTC; a report grouped by UTC day shows it on the wrong date.
• Week and weekend: the first day of the week varies by locale, and the weekend in Saudi Arabia is Friday and Saturday; calendars, schedules and business-day calculations must follow the product’s rule, not a hard-coded one.

One instant: 2026-09-28T09:05:00Z
(example output from Node.js 22 with ICU 78 / CLDR 48; other runtimes may differ)

ar-SA                          ٢٨ سبتمبر ٢٠٢٦
ar-SA-u-nu-latn                28 سبتمبر 2026
ar-SA-u-ca-islamic-umalqura    ١٧ ربيع الآخر ١٤٤٨ هـ
hi-IN                          28 सितंबर 2026
en-US                          September 28, 2026

Time in Asia/Riyadh  (UTC+03:00)   12:05
Time in Asia/Kolkata (UTC+05:30)   14:35

Try it: Date Test Data Generator Try it: Timezone Converter Try it: Timestamp Converter Try it: ISO 8601 Converter

Numbers, digits and currencies

Arabic text can use Western digits (0–9) or Arabic-Indic digits (٠١٢٣٤٥٦٧٨٩), and with Arabic-Indic digits the separators change too: the Arabic decimal separator ٫ (U+066B) and the Arabic thousands separator ٬ (U+066C). Hindi text normally uses Western digits, although Devanagari digits (०–९) exist and can be requested. India groups large numbers differently — 12,34,567, the lakh (1,00,000) and crore (1,00,00,000) system — in both en-IN and hi-IN. Decide per locale which digits and grouping the product uses, then test display and input: a user may type Arabic-Indic digits into an amount or phone field, and the product must either accept and normalise them or reject them with a clear message.

Currencies are identified by ISO 4217 codes — SAR for the Saudi riyal and INR for the Indian rupee, both with two minor units. Format amounts with the locale, not with string templates: the symbol, its position and the spacing vary by locale. The Saudi Central Bank introduced a dedicated riyal symbol in 2025, and Unicode 17.0 encodes it as U+20C1 SAUDI RIYAL SIGN; if your design uses it, check which fonts on your target devices can render it, because a font without the glyph shows an empty box.

Locale-formatted strings contain invisible characters. Formatting an SAR amount for ar-SA produces a right-to-left mark (U+200F) at both ends and a no-break space before the currency, so a test that compares with a hand-typed string fails although the screen looks right. Compare with the output of the same formatting API, or strip invisible characters in the assertion deliberately.

• Parsing: "1.234" is one thousand two hundred and thirty-four in some locales and one point two three four in others; a value formatted for display must be parsed with the same locale.
• Phone numbers, IBANs and ID numbers are identifiers, not quantities: never group them or convert their digits for display.

1234567.5 as currency, per locale
(example output from Node.js 22 with ICU 78 / CLDR 48)

ar-SA            SAR   ١٬٢٣٤٬٥٦٧٫٥٠ ر.س.
                       (U+200F at start and end, U+00A0 before ر.س.)
ar-SA-u-nu-latn  SAR   1,234,567.50 ر.س.
hi-IN            INR   ₹12,34,567.50
en-IN            INR   ₹12,34,567.50
en-US            SAR   SAR 1,234,567.50

1234567 with Devanagari digits (hi-IN-u-nu-deva):  १२,३४,५६७

Try it: Arabic Test Data Generator Try it: Hindi Test Data Generator Try it: Decimal Dataset Generator

Text, Unicode and scripts

Every layer must agree on UTF-8: the HTML meta charset and the HTTP Content-Type, form submission, the API, message queues, database columns and connections, logs, and CSV or PDF exports. When one layer reads UTF-8 bytes as a legacy single-byte encoding, the result is mojibake — "مرحبا" turns into something like "مرحبا" — and a round trip can make the damage permanent. Question marks in place of letters usually mean characters were lost in a conversion; empty boxes usually mean the font lacks the glyph. In MySQL, the legacy utf8 (utf8mb3) character set stores Arabic and Devanagari but not supplementary (four-byte) characters, which include most emoji; utf8mb4 stores all of Unicode.

The same visible text can be stored as different code point sequences — "é" as one precomposed code point or as "e" plus a combining accent. Unicode normalization (NFC, NFD, NFKC, NFKD) makes them comparable, so search, uniqueness checks and user names must normalise consistently. Length is ambiguous too: the Hindi word "नमस्ते" is 6 code points, 6 UTF-16 units, 18 UTF-8 bytes and 3 user-perceived characters (grapheme clusters: न, म, स्ते). A limit counted in bytes, a limit counted in characters and a cursor that moves by code point will all disagree.

Devanagari joins consonants into conjuncts (क्ष, स्त) through the virama, and some vowel signs are drawn before the consonant they follow in memory — the i-sign in "कि" is stored after क but displayed to its left. Truncating, highlighting or moving the cursor inside a cluster leaves a vowel sign without its base, which rendering engines typically show with a dotted circle (◌ि). A font without full Devanagari shaping shows conjuncts as separate letters with visible viramas.

Sorting and search are locale-specific: use the platform’s collation (Intl.Collator in JavaScript, collations in the database) and test with names that begin with the different forms of alif (ا أ إ آ), with and without diacritics, and with mixed scripts. Input needs its own checks: Arabic keyboards, Hindi typed with the InScript layout or a phonetic transliteration keyboard, and input method editors that compose text over several keystrokes — validation that fires on every keystroke can interrupt a composition.

• Text expansion and contraction: a translation can be much longer or shorter than English, especially for short labels; test buttons, tabs, table headers, toasts and badges with the real strings of every locale.
• Vertical space: Devanagari has vowel signs above and below the headline and Arabic has diacritics above and below letters; fixed line heights with hidden overflow clip them.
• SMS: a message containing Arabic or Devanagari is usually sent in UCS-2, 16 bits per character; with 140 octets of user data per SMS (3GPP TS 23.040), a single message then holds 70 characters instead of 160 in the GSM 7-bit alphabet, so OTP and notification templates can split into several messages.

Try it: Unicode Dataset Generator Try it: String Length Counter Try it: Character Counter Try it: Special Character Dataset Generator

How to run localization testing

Localization testing works best as a series of gates rather than one pass at the end: the cheapest defects (i18n) are found before translation, and the most visible ones (layout and language) need the translation. A workable order, which fits the test levels described in the end-to-end quality assurance guide:

• Review requirements and designs for locale decisions: which locales, which calendar and digits per locale, which formats the user can change, the fallback language, and what is deliberately not translated (brand names, legal texts).
• Review the code for internationalization: externalised strings, locale-aware formatting APIs, no physical left/right in layout code, Unicode storage end to end.
• Run pseudo-localization in CI: every build runs in the pseudo-locale, and any plain-English string is a defect.
• Test functionally per locale with localized test data — names, addresses, phone numbers, amounts and dates in the target scripts and formats — through every layer to the database and back out into exports, emails and SMS.
• Hold a linguistic review in context with native speakers, using screenshots and string keys, against the glossary and style guide.
• Regress per release: localized smoke tests, the missing-key check and per-locale screenshot comparison on every build, and a full localization pass when a feature changes text-heavy screens.

Localization test checklist, per locale (ar-SA, hi-IN, en-US ...)

[ ] Locale is picked correctly (setting, Accept-Language, URL) and persists
[ ] Unsupported locale falls back to the agreed default, never to raw keys
[ ] No untranslated or hard-coded strings (pseudo-locale run is clean)
[ ] Plurals: counts 0, 1, 2, 3, 11, 100 give the correct Arabic forms
[ ] Dates: calendar, digits, month names, time zone, midnight shift
[ ] Numbers: digits, decimal and grouping separators, lakh/crore in hi-IN
[ ] Currency: ISO 4217 code, symbol, position, minor units, input parsing
[ ] Text: Arabic and Devanagari intact through DB, API, CSV, PDF, email, SMS
[ ] Length limits enforced in the unit the backend uses (chars vs bytes)
[ ] Sorting and search work for the locale (alif forms, diacritics)
[ ] Layout: no truncation, clipping or overlap with real strings
[ ] RTL: direction, mirroring, bidirectional text (see the RTL guide)
[ ] lang attribute on the page and on inline foreign-language text

Try it: Multilingual Test Data Generator Try it: Arabic Test Data Generator Try it: Hindi Test Data Generator Try it: Saudi Address Test Data

Automating localization checks

Automated tests should run in more than one locale. Parameterise the suite by locale and time zone, and compute expected values with the platform’s Intl APIs instead of typing formatted strings into assertions — typed strings miss invisible marks and break when the CLDR data is updated. Compute the expected value in the same runtime that produced the actual one: a Node.js test runner and a browser can carry different ICU versions and disagree.

Three inexpensive checks catch most regressions: a missing-key check that compares every locale file with the source locale in CI, an untranslated check that flags values identical to the source (with an allow-list for brand names and codes), and a screenshot comparison per locale for key screens.

// Locale-parameterised UI check (Playwright Test)
for (const locale of ["en-US", "ar-SA", "hi-IN"]) {
  test(`order total is formatted for ${locale}`, async ({ browser }) => {
    const context = await browser.newContext({
      locale,
      timezoneId: locale === "hi-IN" ? "Asia/Kolkata" : "Asia/Riyadh",
    });
    const page = await context.newPage();
    await page.goto("/orders/ORD-2026-0042");
    // expected value computed with Intl in the same browser, not typed by hand
    const expected = await page.evaluate(
      (l) => new Intl.NumberFormat(l, { style: "currency", currency: "SAR" }).format(1500),
      locale,
    );
    await expect(page.getByTestId("order-total")).toHaveText(expected);
    await expect(page).toHaveScreenshot(`order-${locale}.png`);
  });
}

// Missing and untranslated keys (Node.js, runs in CI)
const flat = (o, p = "") => Object.entries(o).flatMap(([k, v]) =>
  v && typeof v === "object" ? flat(v, p + k + ".") : [[p + k, v]]);
const en = new Map(flat(require("./locales/en.json")));
const ar = new Map(flat(require("./locales/ar.json")));
const missing = [...en.keys()].filter((k) => !ar.has(k));
const same = [...en].filter(([k, v]) => ar.get(k) === v);
if (missing.length) { console.error("Missing in ar:", missing); process.exit(1); }
if (same.length) console.warn("Identical to en, check:", same.map(([k]) => k));

Try it: JSON Diff Try it: Multilingual Test Data Generator

Typical localization defects, written as bug titles

The examples below are illustrative, not real incidents. Each follows the bug-report pattern of symptom, place and condition; the how to write a bug report guide covers the rest of the report.

• Cart badge shows "2 منتج" instead of "منتجان" — plural chosen with a count === 1 check
• Order confirmation email arrives in English for users who selected Arabic in the app
• Hijri date picker stores the previous day when the date is chosen between 00:00 and 03:00 Riyadh time
• Amount field rejects "١٥٠٠" typed on an Arabic keyboard with "Invalid number"
• hi-IN sales report shows 1,234,567 instead of 12,34,567
• Hindi product name truncated inside a conjunct, leaving a dotted-circle vowel sign in search results
• Validation message "Field is required" not translated on the Arabic registration form

Frequently asked questions

References

• Internationalization (i18n) ActivityW3CW3C's internationalization articles, tutorials and checks for building and testing multilingual web content.
• Unicode CLDR ProjectUnicode ConsortiumThe Common Locale Data Repository: the locale data for date, time, number and currency formats and plural rules that most platforms use.
• The Unicode StandardUnicode ConsortiumThe universal character set and its encoding forms (UTF-8, UTF-16, UTF-32), normalization and the properties of every code point.
• ECMAScript Internationalization API Specification (ECMA-402)Ecma International (TC39)The JavaScript Intl API specification — locale-aware formatting of dates, numbers, currencies, lists and plural rules in the browser.
• Intl — MDNMDN Web Docs (Mozilla)The Intl namespace in practice: DateTimeFormat, NumberFormat, Collator, PluralRules and how locale negotiation works.
• Time Zone DatabaseIANAThe tz database of the world's time zones and their historical offset and daylight-saving rules, updated several times a year.
• ISO 4217 — Currency codesISOThe three-letter currency codes (SAR, INR, USD…) and their minor units — the reference for currency fields and formatting tests.
• RFC 5646: Tags for Identifying LanguagesIETF · 2009BCP 47 language tags (ar, ar-SA, hi-IN, en-GB) — the identifiers used in lang attributes, Accept-Language and locale settings.
• Indic Layout RequirementsW3C · 2020The layout requirements of Indic scripts such as Devanagari — conjuncts, vowel signs, line breaking — relevant to Hindi interfaces (a W3C Working Draft).