Localisation & Internationalisation (i18n/L10n) Testing
Test that your application works correctly in different languages and locales. This includes translated text, date/time formats, currencies, number formatting, timezone handling, right-to-left languages, and cultural appropriateness. For NZ, includes te reo Māori and NZST/NZDT timezone testing.
1 The Hook
A government agency adds te reo Māori as a second language to its public portal. The translations are commissioned properly and the toggle works. A tester switches to te reo, the page looks great, sign-off given. Ship it.
Then complaints arrive. A user named Ngārimu finds the system has stored him as Ngarimu — the macron on the ā was silently stripped by a validation rule that only allowed plain a–z. The place name Whangārei shows up as Whangarei on his rates notice. Worse, a blind kaumātua using a screen reader hears the te reo headings read out in a flat English voice, mangling every word, because the translated text was dropped into the page without a lang="mi" attribute. The translations were perfect; the system around them quietly corrupted and mispronounced them.
This is the heart of localisation testing: the words being translated is the easy part. The defects hide in what the system does around the words — the macrons it strips, the dates it reformats, the timezone it gets wrong, the language it forgets to tag. A page that “looks translated” tells you almost nothing about whether the locale actually works.
2 The Rule
Localisation is not translation — so don’t just check the words changed. Test what the system does around them: macrons preserved, dates and numbers in the right locale format, timezones correctly converted, text tagged with the right language, and layouts that survive expanded or right-to-left text.
3 The Analogy
Reading a name aloud at a pōwhiri.
Picture a school assembly where names are read out. Getting the right name on the list (the translation) is only the start. If the reader doesn’t know that Tāmati has a long “ā”, or drops the macron and says “Tamati”, or reads Ngā Puna as if it were English, the name is technically present but disrespected and wrong. The whānau in the room notice instantly.
Localisation testing is being the person who checks not just that every name is on the list, but that each one keeps its macrons, is spelled correctly, and is pronounced in the right reo. The data being “there” is never enough — it has to survive intact and be presented in a way that does it justice.
The failure mode nobody warns you about is the database collation. Teams spend weeks on pseudo-localisation and browser locale switching, then ship to a PostgreSQL instance where someone created the names column as VARCHAR with a Latin-1 collation years ago. Every macron silently survives the UI, passes the API, and then gets dropped on the INSERT. The user named Tūhoe becomes Tuhoe in the database and nobody notices until a support ticket arrives. On any NZ government or health system — Benefits NZ, HealthNZ, CoverNZ — run a macron round-trip test that queries the raw database row, not just the rendered page. If the column collation is wrong, no amount of front-end testing will catch it.
Senior engineer insight
The thing that changed how I think about localisation testing: the bug is almost never in the translation itself — it's in the five layers the translated string passes through before it reaches the screen. Macrons survive the UI, survive the API, then vanish silently on a Latin-1 database column. The date format looks right on the happy path, then quietly swaps MM/DD on the one edge case a native speaker would catch immediately. Test the pipeline, not just the output.
Most common mistake: signing off "translations look correct on screen" and calling it done — without ever querying the raw database row, inspecting lang attributes in DevTools, or running a screen reader over a single te reo heading.
From the field
A mid-size NZ councils project added bilingual (English / te reo Māori) support to its rates portal. QA signed off after a visual review — headings looked right, the language toggle worked, the translations had been reviewed by a native speaker. Three weeks post-launch a user filed a complaint: her name, Hine-ā-Parata, was appearing on every rates notice as Hine-a-Parata — the macron and the hyphen-separated structure were being flattened by a CLDR-unaware normaliser in the PDF renderer. A separate screen reader audit also found zero lang="mi" tags on any te reo heading, meaning every bilingual heading was being read aloud in a flat English voice to blind users. The lesson: bilingual sign-off needs three distinct checks — visual review by a te reo speaker, a raw data round-trip test (enter ā ē ī ō ū, export to PDF and CSV, confirm they survive), and an assistive-tech audit with a screen reader. Any one of those missing and you have shipped a defect.
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.
Localisation is not translation alone. It’s translation + cultural adaptation + format adaptation. A calendar widget for the Arabic calendar is different from a Gregorian calendar. A timezone picker needs to handle both UTC and user’s local timezone.
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
Start with pseudo-localization. Before translating into every language, pseudo-localize your app. It’ll catch hardcoded strings, text overflow, and string concatenation bugs — problems that affect every locale.
- 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".
4 Industry Reality
- Translations arrive late — often after code freeze. In practice the translation files land days before release. Testers run smoke-level locale checks rather than full regression, so macron-stripping bugs and hardcoded strings survive into production. Build locale testing into every sprint, not a late-stage gate.
- Pseudo-localisation is the first casualty of time pressure. The technique is on the roadmap but never prioritised. The result: hardcoded strings discovered only when a real language ships, usually by a customer complaint. Senior testers push to automate pseudo-locale as a CI check so it runs without asking.
- NZ government and education projects have specific Treaty obligations. Agencies subject to the Public Service Act must support te reo Māori. Real-world L10n testing on these projects includes sign-off from a te reo Māori reviewer — not just a developer’s spot-check — before a bilingual feature ships.
- Legacy systems silently strip macrons at the database layer. A VARCHAR column with a Latin-1 collation will truncate or corrupt ā, ē, ī, ō, ū on insert. Testers discover this not in unit tests but when a user named Tūhoe logs a support ticket saying their name is wrong. The fix requires a schema migration, not just a code change.
- Timezone bugs surface in production, not in dev. Development environments typically run in UTC. Bugs where displayed times are wrong only appear when a customer in Auckland sees their event at 1pm instead of 2pm after a DST transition. Teams that test with their server timezone forced to UTC and their test accounts set to Pacific/Auckland catch these; teams that don’t are surprised.
5 When to Use It — and When Not To
✓ Use it when
- The app targets more than one country, language, or locale — including te reo Māori alongside English
- You handle dates, times, currencies, or numbers displayed to end users (a wrong date format is a showstopper)
- The project is a government, education, or public-sector NZ system with Treaty or legislative obligations
- Users enter names, place names, or free text (macron and okina stripping is a defect in any NZ system)
- The system stores event times and users span multiple timezones, including across NZ’s own NZST/NZDT boundary
✗ Skip it when
- The system is genuinely internal-only, single-locale, with no personal name or date fields — a CI pipeline dashboard used by one team in one country
- All dates and times are displayed in ISO-8601 to engineers only and never converted to local time for end users
- The product is at proof-of-concept stage with no live users and no planned locale support in the roadmap
- The content is purely numeric or binary — telemetry dashboards where no locale-sensitive formatting exists
Context guide
How the right level of localisation testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Government portal with te reo Māori support (e.g. Benefits NZ, HealthNZ, Revenue NZ) | Essential | Treaty obligations and the Public Service Act require bilingual support. Missing lang="mi" attributes and macron stripping are compliance failures, not merely quality issues. Native-speaker reviewer sign-off is a formal exit criterion. |
| Customer-facing financial app handling NZ personal names and dates (e.g. Harbour Bank, Southern Bank, Pacific Bank) | Essential | Personal names with macrons (tūhoe, Ngārimu) must survive every database layer. Date format ambiguity (DD/MM vs MM/DD) causes incorrect transaction dates, which is a direct financial and regulatory risk. NZST/NZDT timezone correctness affects scheduled payments. |
| Multi-locale SaaS product launching a new language (e.g. CloudBooks adding German or Japanese) | High | Text expansion (German is 15–30% longer than English), right-to-left support, and locale-specific number formatting all require structured testing before a locale ships. Pseudo-localisation in CI catches the structural defects before translation even begins. |
| Internal NZ business app with a single English locale (e.g. Spark internal HR system) | Medium | Even single-locale apps accept employee names — macron handling and UTF-8 storage still apply. Date and timezone correctness matters for payroll and leave calculations. Lightweight macron round-trip testing and NZST/NZDT smoke tests are proportionate. |
| Internal tooling with no personal name or date fields (e.g. CI pipeline dashboard, log viewer) | Low | No locale-sensitive content means no meaningful localisation risk. Skip formal L10n testing; re-evaluate if name or date fields are ever added. |
Trade-offs
What you gain and what you give up when you choose localisation testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Pseudo-localisation exposes hardcoded strings and overflow bugs immediately, before any translation exists, at near-zero cost. | Pseudo-localisation does not catch semantic translation errors, cultural inappropriateness, or missing lang="mi" attributes — it only reveals structural defects. |
The codebase is well-structured with externalised strings and you already know overflow is not a risk — skip pseudo-locale and go straight to native-speaker review. |
| Full locale regression with real translations gives high confidence that the entire user journey works correctly for a specific market, including cultural nuance and screen reader behaviour. | Full locale regression requires translated content to exist and is expensive in time and specialist reviewer effort — it cannot be done early in development when defects are cheapest to fix. | Very early in the project with no translations yet — run pseudo-localisation instead to catch structural issues and defer native-speaker review until strings are stable. |
| Macron round-trip testing (enter ā ē ī ō ū, trace through every layer to PDF/CSV output) definitively proves whether the pipeline preserves Māori data correctly, including at the database collation level. | Round-trip testing requires access to the raw database and all export pipelines, which testers may not have in all environments. It also needs to be re-run whenever the schema or any middleware changes. | The application genuinely accepts no personal names or free-text fields — round-trip macron testing adds no value on a purely numeric data system. |
Enterprise reality
How Localisation Testing changes at 200–300-developer scale in NZ enterprise — where “check the translations look right” becomes a multi-team compliance programme
- Automation takes over the structural checks. At enterprise scale — CloudBooks, ListRight, Pacific Air — pseudo-localisation runs as a mandatory CI gate on every pull request. String extraction, locale build, and overflow detection are fully automated. What stays manual is native-speaker cultural review and screen reader audits, because no tool reliably catches both meaning-level errors and assistive-technology pronunciation failures.
- Governance and compliance are non-negotiable for public-sector contracts. Benefits NZ and HealthNZ both operate under the Public Service Act 2020, which requires te reo Māori language support across digital services. In practice this means localisation testing has a formal exit criterion signed off by a te reo Māori reviewer — not a QA team member — before any bilingual feature can merge to main. The Privacy Act 2020 and HISF (Health Information Security Framework) add further obligations: personal name data (including macronised names) must be treated as sensitive, stored in UTF-8 with documented collation settings, and auditable end-to-end.
- Tooling decisions at volume favour platform-level solutions over per-project scripts. Crowdin or Phrase as the single translation management platform, integrated with GitHub Actions and linked to Figma for in-context review, replaces the ad-hoc spreadsheets that small teams use. At TeleNZ scale, a dedicated i18n platform engineer maintains the pseudo-locale pipeline and string coverage dashboards — localisation is an infrastructure concern, not a manual tester’s side task.
- Cross-squad coordination at 10+ squads requires a locale release owner. When ten squads each own a product area, translated strings can ship out of sync — Squad A updates the checkout flow in English and German while Squad B’s payment confirmation still shows English-only. Enterprise teams appoint a locale release coordinator who owns the translation freeze date, confirms full string coverage across all squads before a locale goes live, and arbitrates when one squad holds a release for another’s missing strings. Without this role, partial-language releases reach production routinely.
◆ What I would do
Professional judgment — when to reach for localisation testing, when to skip it, and what to watch for.
Revenue NZ myIR is adding a German locale to serve NZ-resident expats. Translations are in progress but the build is only three sprints old. The project lead wants to begin locale testing immediately.
Run pseudo-localisation immediately as a CI check rather than waiting for German strings. This surfaces hardcoded strings in error messages and tax-summary labels (the Revenue NZ UI has many), UI overflow in the two-column form layout, and any broken string concatenation — all before a single translator is paid. Full German regression with a native speaker comes only after pseudo-locale is clean and the translation files are stable. I would also schedule a NZST/NZDT boundary test early: Revenue NZ transactions are time-stamped and a UTC+12/+13 error on a tax filing deadline date is a compliance incident, not just a display bug.
CoverNZ is adding a te reo Māori interface to its online claims portal. The translations have been reviewed and the language toggle works visually. The team is ready to sign off and ship.
Not sign off on visual review alone. I would run three additional checks before the release exits QA: first, a screen reader audit with NVDA over every te reo heading and label — CoverNZ claimants include kaumātua and people with disabilities, and missing lang="mi" attributes are both an accessibility and cultural failure; second, a macron round-trip test entering claimant names like Tūhoe Rēweti and confirming the name is identical in the raw database row, in the PDF claim receipt, and in the email notification (the CoverNZ PDF renderer has historically used a Latin-based font stack that silently drops macrons); third, a check that the lang attribute on the <html> element switches correctly to mi when the user selects te reo, not just the visible string content. I would make native-speaker reviewer sign-off a formal exit criterion, not an optional step.
TransitNZ is shipping a roadwork alert system that schedules events, sends SMS and email notifications with displayed times, and stores data in a UTC database. The system is NZ-only and English-only. The team argues localisation testing is not needed.
Agree to skip translation testing but disagree on skipping localisation testing entirely. NZST/NZDT timezone handling is a real risk: an alert for a motorway closure at 6:00am displayed as 5:00am (UTC offset wrong after the September DST transition) could send drivers to a closed road. I would run a targeted timezone test: create alerts on the last Sunday in September and the first Sunday in April, confirm displayed times are correct on both sides of the transition, and also check the non-existent 2:30am spring-forward is handled gracefully. I would also run a lightweight macron smoke test if contractor or place names (e.g. Waikato, Kāpiti Coast) appear in alert text — road names in NZ commonly include macronised place names. Scoped localisation testing, not none.
The bottom line: A page that looks translated tells you almost nothing — the defects that matter are invisible on screen. Always test what the system does around the words: macrons through every layer, lang attributes in the HTML, dates and numbers in the user’s locale, and timezone conversions across NZ’s own NZST/NZDT boundary.
6 Best Practices
- ✓ Run pseudo-localisation in CI before any real language ships. Automate it with a script or Crowdin’s built-in pseudo-locale so every build exposes hardcoded strings and overflow issues without manual effort.
- ✓ Test macrons end-to-end, not just on input. Enter ā, ē, ī, ō, ū and trace through save, reload, export, email notification, and PDF output. Corruption can happen at any layer — database collation, template renderer, or file encoding.
- ✓ Force server and test DB to UTC, then set user locale to Pacific/Auckland. This is the only reliable way to surface NZST/NZDT conversion bugs before they reach production.
- ✓ Create a DST boundary test calendar entry. Schedule one event at 2:00am on the last Sunday in September and one at 2:00am on the first Sunday in April. Verify displayed times are correct on each side of the transition and the non-existent spring-forward hour is handled gracefully.
- ✓ Engage a te reo Māori speaker as a reviewer, not just a proofreader. A reviewer checks cultural appropriateness and context; a proofreader only checks spelling. For government and education projects, reviewer sign-off should be a formal test exit criterion.
- ✓ Inspect te reo headings and labels with a screen reader (NVDA or JAWS) during every bilingual release. Confirm
lang="mi"is present so pronunciation is correct. This is both an accessibility requirement and a cultural obligation. - ✓ Test text expansion with real translations, not Lorem Ipsum. German is 15–30% longer than English. Test buttons, table cells, and nav items with actual German (or pseudo-locale “+30%” padding) to catch overflow before it hits production.
- ✓ Check number and currency formatting with
Intl.NumberFormator equivalent library tests. Verifynew Intl.NumberFormat('en-NZ',{style:'currency',currency:'NZD'}).format(1234.5)returnsNZ$1,234.50, not the EU dot-comma form. - ✓ Lock down the locale of your test environment explicitly. Never rely on the OS locale of the CI server — set it in your test config so results are reproducible across machines and pipelines.
- ✓ Add a locale-switching test to your regression suite. Confirm switching language mid-session updates all UI text, persists the choice on next login, and doesn’t leave any orphaned English strings on the page.
7 Common Misconceptions
❌ Myth: If the translations look right on screen, localisation testing is done.
Reality: Visible translated text is the smallest part of localisation. Defects that matter most are invisible on screen: macrons stripped in the database, dates parsed in the wrong format on the server, times stored without timezone context, lang attributes missing from te reo text. You need database queries, browser DevTools inspection, and a screen reader — not just a visual review — to confirm localisation is actually working.
❌ Myth: Te reo Māori support is just about translating the UI strings.
Reality: Translation is one dimension. Te reo support also requires: preserving macrons (ā ē ī ō ū) and the okina (ʻ) through every layer of the stack; tagging te reo text with lang="mi" for correct screen reader pronunciation; ensuring cultural appropriateness reviewed by a te reo speaker; and respecting Māori data sovereignty principles if the app handles iwi or hapū data. A page that “shows te reo” without these properties is not compliant with NZ accessibility and Treaty obligations.
❌ Myth: Localisation testing only matters for apps that ship to multiple countries.
Reality: NZ-only apps still need localisation testing. Any NZ system that accepts personal names must handle macrons. Any system displaying dates should be unambiguous (DD/MM/YYYY not MM/DD/YYYY). Any public-facing government or education app has te reo obligations. And NZST/NZDT timezone bugs affect NZ-only apps as much as global ones — they just also bite NZ users exclusively.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
A bilingual NZ council portal shows this on a rates page after switching to te reo Māori:
Heading reads “Nga utu rēti” with no lang attribute on it; the resident’s name Hēmi Te Kōtuku displays as Hemi Te Kotuku; the due date shows as 04/03/2026; and the amount shows as $1.250,00. List every localisation/i18n bug you can spot and say why each is wrong.
Show model answer
Four localisation bugs:
1. Missing macron in the heading — "Nga utu" should be "Ngā utu" (long ā). The macron has been dropped, so the te reo is misspelled. A senior would check whether input/output validation is stripping macrons system-wide.
2. Macrons stripped from the name — "Hēmi Te Kōtuku" stored/displayed as "Hemi Te Kotuku". Validation that only allows plain a–z corrupts Māori names; macrons (ā ē ī ō ū) must be preserved end to end.
3. Missing lang="mi" on the te reo heading — without it a screen reader uses an English voice engine and mispronounces the reo. Te reo text must be wrapped in lang="mi" (e.g. …).
4. Wrong number/date locale formatting — NZ uses DD/MM/YYYY and "1,250.00" (comma thousands, dot decimal). "$1.250,00" is the German/EU format (dot thousands, comma decimal), so the locale formatter is set wrong. 04/03/2026 is also ambiguous unless you confirm it is DD/MM (4 March), not MM/DD.
A developer wrote the “name” field validation below for a NZ enrolment form. It rejects valid Māori names and an English name with an apostrophe. Explain what it breaks and rewrite the rule in plain English so it accepts real NZ names.
“Name must contain only the letters A–Z and a–z and spaces. Reject anything else.”
Test inputs it wrongly rejects: Ngārimu, Tūhoe, O’Brien, Te Āti Awa.
What it breaks, and your rewritten rule:
Show model answer
What the rule breaks: - It rejects macronised vowels (ā ē ī ō ū), so Ngārimu, Tūhoe and Te Āti Awa all fail — corrupting or blocking valid Māori names. - It rejects the apostrophe/okina, so O'Brien (and te reo using the okina ʻ) fails. - "Only A–Z/a–z" assumes English-only ASCII, which is wrong for a bilingual country. Rewritten rule (plain English): "Accept Unicode letters including macronised vowels (ā ē ī ō ū and their capitals), spaces, hyphens, and apostrophes/okina. Do not strip or normalise away macrons or the okina at any stage — store and display the name exactly as entered. Reject only digits and unsafe control characters." A senior would add: store as UTF-8, test that the name round-trips unchanged through save → reload → export, and confirm it isn't silently normalised (e.g. ā collapsed to a) anywhere in the pipeline.
A national events app lets organisers schedule events and supports English and te reo Māori. Design a localisation/i18n test set covering: te reo macron handling, lang="mi" tagging, NZ date/number formatting, and the NZST↔NZDT daylight-saving transition. For each test, give the input/setup and the expected result.
Show model answer
Localisation test set for the events app: 1. Macron handling — Setup: create an event titled "Hui ā-Tau" and an organiser named "Tūhoe Rēweti"; save, reload, and export. Expected: macrons (ā ē ī ō ū) are preserved unchanged at every stage; nothing is stripped or normalised to plain vowels. 2. lang="mi" tagging — Setup: switch the interface to te reo and inspect the te reo headings/labels with DevTools and a screen reader (NVDA/JAWS). Expected: te reo text is wrapped in lang="mi" so the screen reader uses Māori pronunciation, not a flat English voice. 3. NZ date/number format — Setup: set the locale to en-NZ and view an event dated 4 March 2026 with a ticket price of 1250.5. Expected: date shows 04/03/2026 (DD/MM/YYYY), price shows $1,250.50 (comma thousands, dot decimal) — not the EU 1.250,50 form. 4. NZST/NZDT transition — Setup: schedule an event for the last Sunday in September (clocks jump UTC+12 → UTC+13) and one for the first Sunday in April (UTC+13 → UTC+12); also try the non-existent 2:30am on the spring-forward Sunday. Expected: stored in UTC, displayed in correct local time on both sides of the switch; the app handles or rejects the non-existent 2:30am gracefully rather than showing a wrong time. A senior would also test locale switching mid-session and that the choice persists on next login.
Why teams fail here
- Treating a visual translation review as full localisation sign-off — invisible defects (macron stripping, missing
langattributes, wrong date locale on the server) never appear on-screen until a real user is harmed. - Skipping database-layer macron testing — a VARCHAR column with a Latin-1 or ascii collation silently corrupts ā ē ī ō ū on INSERT; no front-end test will ever catch it.
- Deferring pseudo-localisation until a real language is ready — by then hardcoded strings and overflow bugs are embedded across dozens of components and cost ten times as much to fix.
- Testing timezone display in the same environment where events are created — NZST/NZDT conversion bugs only surface when the server clock and the user's display timezone differ; teams that never force these apart ship the bug to production.
Key takeaway
A page that looks translated tells you almost nothing — localisation testing is about proving the system preserves macrons end-to-end, tags te reo correctly for assistive tech, formats dates and numbers in the user's locale, and converts timezones reliably across NZ's own NZST/NZDT boundary.
How this has changed
The field moved. Here is how Localisation Testing evolved from its origins to current practice.
Software internationalisation is a technical exercise — character encoding (ASCII → code pages → Unicode), locale settings, and resource file externalisation. Testing is done by translators checking strings in screenshots, not by software testers.
Windows 95 global release creates large-scale localisation QA demand. Microsoft and SAP develop formal localisation testing disciplines — linguistic review, cultural suitability, functional testing in each locale, and back-translation verification.
Web applications break localisation — dynamic content, user-generated text, and Ajax make string externalisation more complex. Pseudo-localisation testing (replacing strings with accented equivalents) becomes a standard technique for catching hardcoded strings without waiting for translation.
Unicode UTF-8 near-universal adoption simplifies encoding issues. Internationalisation testing shifts focus from character encoding to layout (RTL languages, string expansion), date/time/currency formats, and locale-specific business rules.
AI translation tools (DeepL, GPT-4) make high-quality machine translation accessible, but also introduce new testing challenges — AI translations can be contextually wrong in subtle ways. For NZ, localisation testing must now include te reo Māori content testing, ensuring Māori diacritics (macrons) render correctly and that cultural content is handled appropriately.
Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Localisation Testing — and what strong answers look like.
What is pseudo-localisation and why is it useful?
Strong answer: Pseudo-localisation replaces application strings with accented, expanded versions — "Hello" becomes "[Héèllö]" — without actual translation. This makes it immediately visible when strings are hardcoded (they do not expand), when UI layouts cannot accommodate longer strings (text overflows or truncates), and when special characters break encoding. It is run by developers before translation is available, catching internationalisation bugs weeks earlier than waiting for translated builds. It is particularly useful for catching hardcoded strings in error messages, tooltips, and validation messages that are often missed during initial development.
Junior/Mid
What te reo Māori-specific issues should you test for in a NZ government application?
Strong answer: Test that macron (tohutō) characters render correctly — words like "Māori", "kāinga", "tūāhu" — in all interface components including form fields, error messages, PDF generation, and email notifications. Test that macrons survive round-trips through the database (UTF-8 encoding) and are not stripped or corrupted by middleware. Test keyboard input via both macron keys (ā ē ī ō ū) and the double-vowel convention (aa ee ii oo uu), and verify both produce equivalent stored values if the application supports it. For NZ government sites subject to Te Tiriti o Waitangi obligations, test that Māori content is given equal prominence — not truncated while English content is displayed in full.
Junior/Mid
Q1: What is the difference between internationalisation (i18n) and localisation (L10n)?
i18n is the technical groundwork — structuring code so text, dates, numbers, and layout can vary by locale (resource files, locale-aware libraries, Unicode, RTL support). L10n is the content and cultural work — translating strings and adapting imagery, formats, and tone for a specific locale. Code can be i18n-ready yet still fail L10n in a given language.
Q2: Why must te reo Māori text be wrapped in lang="mi", and what breaks without it?
The lang attribute tells assistive tech which pronunciation engine to use. Without lang="mi", a screen reader reads te reo with an English voice and mispronounces every word, which is both an accessibility failure and culturally disrespectful. Tagging the text fixes pronunciation and lets browsers apply correct language behaviour.
Q3: A name field strips the ā from “Aotearoa”. What is the bug and how do you test for it?
Input/output validation is rejecting or normalising macronised vowels, corrupting Māori names and place names. Test by entering macronised text (and the okina) and confirming it round-trips unchanged through save, reload, and export — the field must accept and preserve ā ē ī ō ū and ʻ, not collapse them to plain letters.
Q4: Why is pseudo-localization useful before you have any real translations?
It transforms English strings into an accented, bracketed, slightly longer form so you can spot problems that affect every locale: hardcoded strings (they won’t be transformed), text expansion that overflows the UI, and broken string concatenation — all without waiting for, or paying for, real translations.
Q5: Why are the NZST/NZDT transitions high-risk dates to test?
New Zealand switches to daylight saving on the last Sunday in September (UTC+12 → UTC+13) and back on the first Sunday in April. Times stored in UTC are safe, but displayed times must apply the right offset on each side of the switch, and the spring-forward 2:30am simply doesn’t exist — so events scheduled around these moments expose timezone-conversion bugs.
Q6: Your team is testing the appointment booking module on the Benefits NZ (Benefits NZ) portal, which is being updated to support te reo Māori. A quick visual check shows all headings are translated and look correct. What further checks should you prioritise and why?
A: Visual sign-off is the bare minimum. You should also: (1) inspect the HTML to confirm every te reo heading and label carries a lang="mi" attribute — missing tags cause screen readers to mangle pronunciation, which is both an accessibility failure and a Treaty obligation; (2) enter appointment times and verify they display in NZST/NZDT correctly, not raw UTC; (3) enter a test user name containing macrons (e.g. “Tūhoe Ngārimu”) and confirm the name survives save, reload, and any email confirmation without macron loss; and (4) check the date format is DD/MM/YYYY throughout. On a government portal serving Māori whānau, these invisible correctness issues matter far more than whether the translation looks right at a glance.
Q7: The Revenue NZ myIR portal is adding a German locale to serve a growing expat community. You need to choose between running full locale regression across all transaction screens versus a targeted i18n smoke test using pseudo-localisation. Which approach is more appropriate at the start of the project, and why?
A: Pseudo-localisation first. Early in development, translations often do not exist yet, and running full locale regression requires them. Pseudo-localisation transforms all English strings automatically and immediately surfaces the highest-priority structural defects — hardcoded strings that will never translate, UI overflow when text expands by 20–30%, and broken string concatenation. These are code defects that affect every future locale. Full locale regression with real German translations comes later, once the infrastructure is verified sound. Starting with full regression would consume time and budget on content review before the underlying code is trustworthy.
Q8: What is the key difference between localisation (L10n) testing and accessibility testing, given that both involve te reo Māori language tagging and screen reader checks?
A: The goals are different even when the checks overlap. Localisation testing asks whether the system correctly adapts content, formats, and behaviour to a specific locale — correct macrons, right date/number format, proper timezone offset, culturally appropriate translations. Accessibility testing asks whether the system is usable by people with disabilities regardless of locale. The lang="mi" attribute appears in both because it is simultaneously a localisation requirement (the page must identify which language content is in) and an accessibility requirement (screen readers need it to choose the correct pronunciation engine). When you find a missing lang="mi" attribute, log it as both a localisation defect and an accessibility defect, because it fails two distinct quality dimensions.
Q9: A developer says “we don’t need localisation testing — our app only shows macronised names in read-only display fields, and the database stores whatever the user types, so nothing can go wrong.” What is wrong with this and how do you respond?
A: The claim ignores the many layers between user input and display where corruption silently occurs. Macrons can be stripped at: the input validation rule (regex that only allows a–z); the database column collation (a Latin-1 or ascii-collated VARCHAR will truncate or corrupt UTF-8 characters on insert); ORM or serialisation layers that normalise strings; PDF or email template renderers that use a limited character set; and export functions that write to CSV or Excel with the wrong encoding. “Pass-through storage” is never actually pass-through. The correct response is to design a round-trip test: enter “Tūhoe Rēweti”, save, reload from the database, export to PDF and CSV, and confirm the macrons are identical at every step. On any NZ system that handles personal names — including HealthNZ, CoverNZ, KiwiSaver, or RealMe — this is a compliance concern, not just a quality nice-to-have.
Related techniques
Related: See Accessibility Testing for screen reader testing of translated content, especially te reo Māori language tagging.