Localisation & Internationalisation (i18n/L10n) Testing

What it is

Localisation and internationalisation are related but distinct concepts. Internationalisation (i18n) is the technical work: structuring your code so that text, formats, and logic can vary by locale. Localisation (L10n) is the content work: translating strings, adapting imagery, and ensuring cultural appropriateness.

Testing both is critical. Code can be technically i18n-ready but still break in specific locales: German translations are longer than English, causing UI text overflow. Arabic is right-to-left, breaking a layout built for left-to-right languages. Chinese has different date conventions than English.

i18n vs L10n

Internationalisation (i18n)

The technical infrastructure:

• Storing text in resource files (JSON, YAML, PO files) rather than hardcoding strings in code
• Using locale-aware libraries for dates, times, numbers, currency
• Supporting right-to-left (RTL) languages with CSS direction control
• Using proper Unicode and character encoding
• Handling pluralisation rules (different languages have different plural forms)

Localisation (L10n)

The content and cultural adaptation:

• Translating text strings
• Adapting images (if they contain text or cultural references)
• Verifying cultural appropriateness (colours, symbols, dates, humour)
• Testing with native speakers
• Locale-specific features (bank account formats for different countries)

What to test: the i18n/L10n checklist

Text and translation

All user-facing text must be translatable. Check that no text is hardcoded in HTML or JavaScript. If you see “Click here” hardcoded in a template, that’s a bug — it can’t be translated.

Text expansion: Translated text is often longer or shorter than the source language. German is 15-30% longer than English. Arabic can be shorter. Test that translated text fits the UI without overflow or wrapping awkwardly.

Date and time formats

Different locales format dates differently:

• US: MM/DD/YYYY (12/25/2024 for Christmas)
• NZ/UK: DD/MM/YYYY (25/12/2024)
• ISO standard: YYYY-MM-DD (2024-12-25) — recommended for unambiguity

Test: Create an event on 2024-05-12 in a locale that uses MM/DD format. Does it show as May 12 (correct) or December 5 (wrong)?

Number and currency formats

Different locales use different separators:

• US: 1,234.56 (comma for thousands, period for decimal)
• Germany/many EU countries: 1.234,56 (period for thousands, comma for decimal)
• India: 12,34,567.89 (different grouping)

Test: Display a price of 1234.56 NZD in different locales. Does it show as "1,234.56" in English but "1.234,56" in German?

Time zones

A critical source of bugs. An event scheduled in UTC might display at the wrong local time for users in different zones.

NZ-specific: New Zealand has daylight saving time. NZST is UTC+12, but NZDT (daylight saving) is UTC+13. An event at 2pm displayed in NZST might be wrong during daylight saving (should be 3pm NZDT).

Test: Create an event scheduled for 2pm. View it from Auckland (NZST/NZDT), Sydney (AEDT/AEST), and London (GMT/BST). Verify each displays the correct local time.

Text direction (RTL)

Arabic, Hebrew, Persian, and Urdu are written right-to-left. UI elements, layout, and reading order must reverse for these languages.

Test: Switch the interface language to Arabic. Verify: buttons are on the right, text flows right-to-left, navigation is reversed.

Images and icons

Avoid images with embedded text (they can’t be translated). If an image must change by locale (e.g. regional variations), ensure translated versions exist.

Test: Does the app use a handshake icon for “agreement”? Verify it’s culturally neutral. (Some cultures find certain hand gestures offensive.)

Testing approaches

Pseudo-localization

Pseudo-localization is a technique: automatically transform English strings to look translated without actually translating them. For example, replace every character with an accented version and wrap strings in brackets:

• English: "Hello, World!"
• Pseudo: "[Ḧėļļő, Ŵőŕļď!]"

This reveals hardcoded text (it won’t be pseudo-localised), text expansion issues (the pseudo string is longer), and broken string concatenation (where "Hello" and "World" are translated separately but joined at runtime, causing garbled output like "Ḧėļļő Ŵőŕļď!" instead of the intended result).

Locale-specific testing

Test each locale thoroughly with a native speaker:

• Does the translation sound natural? (Machine translation often sounds robotic.)
• Are date/time formats correct for that locale?
• Do currency values display correctly?
• Are there cultural issues?

Infrastructure testing

Test the i18n infrastructure itself:

• Can users switch locales easily? Does the UI language change immediately?
• Are locale preferences persisted (in cookies, local storage, database)?
• Does the app detect the user’s locale correctly (from browser language settings, IP geolocation, or user preference)?
• What happens if a locale file is missing or corrupted?

Test scenarios

Date display across timezones

Event created in Auckland at 10am NZDT (UTC+13). User in London (UTC) views it. Should display as 9pm previous day. Test that times are correctly converted, not just offset-shifted.

Text overflow in RTL layout

A button with the label "Next" in English is 40px wide. In Arabic ("التالي"), the translated text is longer. Does it fit? Does the layout wrap correctly? Does the button expand or does text overflow?

Pseudo-localization catches hardcoded strings

Switch to pseudo-localization. Every visible string should be pseudo-localised. If you see “Hello” (not pseudo-localised), it’s hardcoded and won’t be translated.

Currency conversion

Display a price in multiple locales. 123.45 NZD should show as "123.45" in en-NZ (with NZD currency symbol), but might need conversion in other locales (or at minimum, correct number formatting).

Māori language support (NZ-specific)

If the app supports te reo Māori, test that: (a) text is properly tagged with lang="mi" so screen readers pronounce it correctly, (b) macrons (long vowels: ā, ē, ī, ō, ū) are correctly entered and displayed, (c) translations are culturally appropriate and reviewed by te reo speakers.

NZ and Māori context

Te reo Māori support

New Zealand is officially bilingual. Applications should support te reo Māori, especially government, education, and public-facing services. Key testing:

• Language tagging: Text in te reo must be wrapped in <span lang="mi"> or similar. Screen readers need this to pronounce māori correctly. Without it, English voice engines will mispronounce words.
• Macron handling: te reo uses macrons (long vowel marks): ā, ē, ī, ō, ū. Verify they display correctly and aren’t stripped out by input validation.
• Okina support: te reo uses the okina (glottal stop): ’ or ʻ. Ensure the app doesn’t treat it as punctuation and strip it.

NZST / NZDT timezone handling

New Zealand transitions to daylight saving on the last Sunday in September (UTC+13) and back to standard time on the first Sunday in April (UTC+12). This is tricky:

• An event at 2:30am on the transition Sunday doesn’t exist (clocks jump forward).
• Events stored in UTC are safe, but displayed times must account for DST.

Test: Schedule an event for late September. Verify it displays correctly before and after the DST transition. Test scheduling an event for the exact transition time (2:30am on the last Sunday in September).

Māori data sovereignty

Māori data is subject to the principles of CARE: Collective Benefit, Authority to Control, Responsibility, and Ethics. If your app handles Māori-specific data (e.g. health records, cultural information, genealogy), ensure:

• Māori communities have control over how their data is used
• Data is not extracted or used without consent for purposes not agreed to
• Cultural protocols are respected

Common localisation bugs

• Hardcoded strings — text "Click here" is hardcoded in HTML, not in a translation file; can’t be translated
• Text overflow — German translations are 30% longer than English; UI layout breaks
• Wrong date format — system always displays MM/DD/YYYY even in locales that use DD/MM/YYYY, causing confusion
• Timezone not localised — times always shown in UTC, not user’s local timezone
• RTL layout broken — Arabic interface still flows left-to-right; buttons and navigation are reversed
• Images with embedded text — an image says "Next" in English; no translated version exists for other languages
• Currency symbol wrong — always shows $ (US dollar) even in NZ context; should show NZ$
• Machine translation quality — translation is technically correct but sounds robotic or offensive
• Macrons stripped — input validation removes ā from "Aotearoa"; Māori names are corrupted

Tools and services

• Crowdin — translation management platform; supports 600+ languages, in-context translation, pseudo-localization
• OneSky — similar to Crowdin; lighter-weight, good for small teams
• Google Translate API / Phrase — automated translation (lower quality, but fast for testing)
• Locale simulators — browser DevTools or system settings to change locale and test date/time/number formats
• Unicode validators — online tools to verify character encoding and special characters (macrons, okina)
• Screen readers (NVDA, JAWS) — test that te reo Māori is tagged with lang="mi" and pronounced correctly

Tips

• Test with native speakers. Machine translation or non-native translators often miss cultural nuances. Spend the money to have a native speaker review translations.
• Test timezones with real dates. Test around DST transitions (for NZ: last Sunday in September, first Sunday in April). These are high-risk dates.
• Test locale switching. Can users switch the interface language mid-session? Does it persist on next login? Does the page re-render correctly?
• For NZ/Māori: use correct character input. Macrons (ā, ē, ī, ō, ū) and okina (ʻ) must be entered correctly. Don’t accept substitutes like "a-" for "ā".
• Test with real translations, not Lorem Ipsum. Lorem Ipsum is always the same length, so you’ll miss text expansion bugs. Use real translated text during testing.
• Check number and currency formatting in your locale library. JavaScript’s Intl object handles number and currency formatting. Test: new Intl.NumberFormat('de-DE').format(1234.56) should give "1.234,56".