Internationalization (i18n)

Why it matters

Most i18n defects are invisible in the source language, so a team that tests only in English ships them to every other market at once. They also cost more to fix late than translation defects: a hard-coded string or a fixed date pattern means a code change, a new build and a retest in every locale, while a wrong translation is one line in a resource file.

For the tester, i18n knowledge decides where a report goes. A plain English label in the Arabic interface is not a translation bug for the translator; it is a code defect, and no string key exists.

Two different jobs: once in the code, then per locale

The localization testing guide introduced the terms; what matters for test design is where the work happens. Internationalization is done once, in the code, by developers: it is a property of the product. Localization is done per locale, in content, by translators and local experts: translated strings, local formats, legal texts, payment methods. Some teams call the two together globalization (g11n).

Because the work happens in different places, so do the defects. An i18n defect usually appears in every locale except the source language, and any tester with the right data can reproduce it. An l10n defect appears in one locale and often needs a native speaker to judge. One screen can carry both: a price built from a string template (i18n) and a wrong Arabic term for "cart" (l10n).

• i18n question: can the product take any locale? Test before translation exists, with a pseudo-locale, Unicode data, right-to-left direction and non-default formats.
• l10n question: is this locale right? Test after translation exists, with the real strings, real formats and a native speaker.
• Locale, not just language: ar selects the Arabic text; ar-SA adds the region that decides formats, currency and calendar defaults. Language tags follow RFC 5646.

Externalised strings and locale data

Externalising a string means moving it out of the code into a resource file under a key: the code asks for checkout.total and the runtime returns the text of the current locale. Each sentence is one message with named parameters, never fragments glued together, because word order and agreement differ between languages. Counts use plural categories: the Unicode CLDR rules give English two, Hindi two and Arabic six, so the message carries one form per category and the formatter picks it; in the ICU MessageFormat syntax below, # stands for the number.

Locale data is everything the runtime knows about a locale that is not a translation: date and number patterns, digits, currency symbols and their position, calendar, first day of the week, plural rules and sort order. On most platforms it comes from CLDR and reaches the code through locale-aware APIs such as the ECMAScript Intl objects (ECMA-402). Internationalized code never hard-codes a pattern like DD/MM/YYYY; it passes the user’s locale tag to the API and shows what comes back. CLDR data changes with new releases, so a test should take its expected format from the platform’s formatter, not from a value copied once from a website.

• Missing keys: compare every locale file with the source file; a key in en.json that is absent from ar.json falls back to English or shows the raw key.
• Parameters: {name} and {amount} must survive translation unchanged; a translated placeholder shows raw braces or breaks the formatter, and a deleted one silently drops the value.

en.json
  "checkout.total":    "Total: {amount}"
  "checkout.nights":   "{count, plural, one {# night} other {# nights}}"
  "checkout.greeting": "Welcome back, {name}"

ar.json  (same keys; Arabic carries all six plural categories)
  "checkout.total":    "الإجمالي: {amount}"
  "checkout.nights":   "{count, plural, zero {لا ليالي} one {ليلة واحدة} two {ليلتان}
                         few {# ليالٍ} many {# ليلة} other {# ليلة}}"
  "checkout.greeting": "أهلاً بعودتك يا {name}"

What the tester checks
  every visible string has a key       -> nothing is typed in the template
  {amount} arrives already formatted   -> by the locale API, not by the message
  {count} hits every plural category   -> 0, 1, 2, 3, 11 and 100 for Arabic

Try it: JSON Diff

Worked example: a checkout screen in a pseudo-locale

Pseudo-localization generates a fake locale from the source strings: letters get accents, every message grows and is wrapped in brackets, and optionally the base direction flips to right-to-left. The team can still read the screen, and any interface text that is not transformed was never externalised. No translator is needed, so it can run in CI on every build. Android, for example, offers the pseudo-locales en-XA (accented, longer text) and ar-XB (right-to-left).

Below is a hotel checkout screen in English and in the pseudo-locale, with what each line tells the tester. Look for plain English, for several bracket pairs where one sentence should be, for a missing closing bracket, and for question marks where accented letters should be.

• Expansion: every string grows by a factor the team chooses, because many translations are longer than English and short labels grow most. A layout that survives it usually survives the real Arabic and Hindi strings.
• Right-to-left pseudo-locale: it flips the base direction without an Arabic translation, so unmirrored icons, misplaced back arrows and text aligned to the wrong side show weeks before the Arabic file exists.

English                   Pseudo-locale                  What the tester sees
------------------------  -----------------------------  --------------------------------
Checkout                  [Çĥéçķöüţ ····]                fine: externalised
Book now                  Book now                       hard-coded in the template
You have 2 guests         [Ýöü ĥàṽé] 2 [ĝüéšţš]          three pieces: concatenated
Total: SAR 1,250.00       Total: SAR 1,250.00            hard-coded: never had a key
Room type                 [?ööm ?ý?é ····]               question marks: non-UTF-8 path
Cancel booking            [Çàñçéļ ḃööķí                  truncated: fixed-width button
Welcome back, Ahmed       [Ŵéļçömé ḃàçķ, Ahmed ····]     fine: {name} survived

Try it: Multilingual Test Data Generator

Typical i18n defects and where they live

Most i18n defects fall into a few classes. Each has a symptom, a place in the code and a cheap way to provoke it; knowing the class lets you report the cause, not only the symptom.

• Hard-coded strings in validation messages, API errors, emails, labels and image text. Provoke: pseudo-locale, then Arabic, reading every message including the ones that need an error.
• Concatenation and if-based plurals: "You have " + n + " items", count === 1 ? "night" : "nights". Symptom: bracketed fragments, "2 ليلة" instead of "ليلتان". Provoke: counts 0, 1, 2, 3, 11 and 100.
• Fixed formats: DD/MM/YYYY templates, hand-placed currency codes, a decimal point typed in code. Symptom: the same format in every locale. Provoke: ar-SA and hi-IN, compared with the platform’s own formatter.
• Physical direction in layout: margin-left and text-align: left instead of logical properties that follow the text direction (margin-inline-start, text-align: start) and the dir attribute. Symptom: an Arabic page whose layout stays English. Provoke: the right-to-left pseudo-locale.
• Non-Unicode paths: a column, API or export that uses a legacy encoding instead of Unicode, or a length limit counted in bytes. Symptom: question marks, mojibake, a 100-character field that rejects 60 Arabic letters (120 bytes in UTF-8). Provoke: Unicode datasets in every field, then check the stored value.
• Locale lost in transit: the interface is Arabic but the email, PDF receipt or SMS is English. Provoke: finish a flow in Arabic and open every output that is not a screen.

Try it: Unicode Dataset Generator Try it: String Length Counter Try it: Arabic Test Data Generator Try it: Hindi Test Data Generator

Frequently asked questions

References

• Internationalization (i18n) ActivityW3CW3C's internationalization articles, tutorials and checks for building and testing multilingual web content.
• 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.
• 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.
• 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.