Te Reo Māori UI Testing

1 The Hook

A Ministry of Education digital portal for schools launches a bilingual English and te reo Māori interface. The UI looks correct in the browser. Three weeks after launch, a teacher from a kura kaupapa reports that her school name — Te Kura Kaupapa Māori o Ngā Mokopuna — displays as “Te Kura Kaupapa M?ori o Ng? Mokopuna” on printed PDF reports and in email subject lines.

The macrons (ā, ō) are being stripped by the PDF generator and email system. The QA team had tested the browser UI, not the downstream outputs. The font supported Unicode. The PDF library didn’t.

This is not a cosmetic defect. Macrons are not optional decoration in te reo Māori — they change the meaning of words. Mama (light) is not māmā (mother). Keke (cake) is not kēkē (armpit). A portal that corrupts its users’ names and school identities is not a functioning product regardless of whether the browser renders correctly.

The QA team had done thorough testing. They had simply tested the wrong output channels.

2 The Rule

Testing the browser display is the starting point, not the finish line. Any system that accepts, stores, or outputs te reo Māori text — or NZ names containing macrons — must be verified end-to-end across every output pathway.

3 The Analogy

4 Watch Me Do It

Character encoding — database round-trip

Test: Database round-trip for te reo text
Input strings: "Tūhoe", "Māori", "Kōrero", "Wāhi", "Ōtautahi"

Steps:
1. Submit each string via the UI form
2. Retrieve each value via the API /GET endpoint
3. Compare retrieved string to input byte-for-byte

Expected: Characters identical including all macrons (ā, ē, ī, ō, ū)
Pass criteria: retrieved === input (strict equality, not trimmed or normalised)

Common failure mode: Database collation set to latin1 or utf8 (3-byte)
instead of utf8mb4 (4-byte Unicode). Fix: ALTER TABLE ... CONVERT TO
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Full output-channel checklist

• Browser display — Chrome, Firefox, Safari, Edge (desktop and mobile)
• Mobile browser — iOS Safari, Android Chrome (different font rendering stacks)
• PDF and print output — verify the PDF library supports Unicode, not just the font
• Email subject line and body — test with Gmail, Outlook, Apple Mail; subject lines are particularly vulnerable
• CSV and Excel export — Excel on Windows defaults to Windows-1252 encoding on open; verify UTF-8 BOM is present
• SMS notification — many SMS gateways use GSM-7 encoding which strips non-ASCII characters including macrons
• Screen reader pronunciation — NVDA + Chrome on Windows; test that macron vowels are announced correctly
• Input field — can users type macrons using macron keyboard layout, alt codes, or copy-paste?
• Search — does “Maori” (no macron) find “Māori” (with macron)? Document the expected behaviour explicitly.
• API responses — verify Content-Type header is application/json; charset=utf-8 and the JSON payload contains correct Unicode codepoints

Language switching test sequence

Test: English → te reo Māori toggle

1. Load page in English
2. Switch to te reo Māori
3. Verify: all UI labels switched, no English text remaining
4. Verify: te reo Māori text uses correct macrons throughout
5. Switch back to English
6. Verify: user state preserved (form data, selections, scroll position)
7. Refresh page → verify language preference persisted (localStorage or cookie)
8. Open in a new tab → verify preference carried across session

Search normalisation — document the expected behaviour

"Māori" with macron → should find results (baseline)
"Maori" without macron → what is the expected result?

  Option A: Finds nothing (strict Unicode match)
    → Acceptable only if documented; may frustrate users who lack a macron keyboard
  Option B: Finds Māori results (Unicode normalisation / transliteration)
    → Better UX; requires explicit normalisation logic in search layer

Whatever the decision: write it as an acceptance criterion and test it
explicitly. A silent mismatch is a defect either way.

Playwright test — macron round-trip

test('school name with macrons saves and displays correctly', async ({ page }) => {
  await page.goto('/schools/new');
  const schoolName = 'Te Kura Kaupapa Māori o Ngā Mokopuna';

  await page.getByLabel('School name').fill(schoolName);
  await page.getByRole('button', { name: 'Save' }).click();

  await page.goto('/schools/recent');
  // Exact match including macrons — not a substring or regex
  await expect(page.getByText(schoolName)).toBeVisible();

  // Also verify the API response carries the correct codepoints
  const response = await page.request.get('/api/schools/latest');
  const school = await response.json();
  expect(school.name).toBe(schoolName); // strict equality
});

5 When to Use It

Apply te reo Māori UI testing whenever:

• Building or testing a NZ government digital service — required under Te Tiriti o Waitangi obligations and the NZ Government Digital Design Standard (Te Ara Hou / Digital Service Design Standard)
• Any application serving Māori communities, kura kaupapa, or iwi organisations
• Any product that stores or displays NZ personal names, place names, or iwi names — even if the product is not marketed as bilingual
• Applications that export data to PDF, CSV, or send email or SMS containing user-supplied name fields
• Any API that stores or returns te reo Māori or NZ place name data to downstream consumers

Even a payroll system that stores employee names, or a school management system that holds whānau contact details, will encounter macrons. The obligation is not limited to dedicated te reo Māori products.

6 Common Mistakes

7 Prompt Lab

Use this prompt with an AI assistant to practise writing te reo Māori test cases. Edit it before running — the more specific your scenario, the better the output.

8 Self-Check

Click each question to reveal the answer.

9 ISTQB Mapping

10 Next Steps