Lesson 21·Unit 6 · Shipping translations·Find the failures you studied·Lv 301·~15 min
Final exercise: audit this checkout
One checkout screen, shipped to Germany, Egypt, and Japan without an i18n review. Twelve of the failures this course covers are on it. Each one comes from real code that does the wrong thing. Flag what you find, then check your audit against the answer key.
By the end
- ·Run a seven-point audit (numbers, dates, plurals, direction, layout, names, input) over a screen nobody marked up for you.
- ·Tell a real locale bug from output that is unfamiliar to you.
- ·Name the failure behind a symptom, and point at the fix that closes the whole class.
The problem
Each lesson in this course isolates one failure. A real release ships them together: the number format bug sits two lines above the plural bug, and both hide behind a layout that only breaks in German. The skill is to find the failures on a screen nobody annotated, in a market whose conventions are not yours. A localization review performs that pass. The team behind this checkout skipped it.
How it works
How to audit a screen
Every earlier lesson handed you one failure in isolation. A shipped screen composes them: the currency bug sits two lines above the plural bug, and the layout only clips in German. The auditor's trap is reading such a screen in your own conventions. Do that and a correct German price like 79,98 € looks like a typo while a wrong one like $1,298.98 reads fine. So the first rule is to switch reference frames: for every value on screen, ask what the market's own formatter would produce. Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }) renders that total as 1.298,98 €: point for grouping, comma for decimals, symbol after the number. Flag deviations from that output, never deviations from English.
The second rule is to walk a fixed list instead of trusting your eye, because composed bugs mask each other. Numbers first: separators, symbol side, digit script, minor units (the yen has none, so ￥12,800 is complete). Then dates: decide whether 07/17 means the 17th of July or nonsense. A de-DE reader expects day first (17.7.2026 from Intl.DateTimeFormat('de-DE')). Then plurals and leftover English: an untranslated "item(s)" or a half-English sentence means a string never reached a translator, usually because code concatenated it. Then direction: find where reading starts, which way arrows point, and whether every interpolated LTR value got bidi isolation. Then layout (check for clipping), names (which name comes first in this market), and input (whether the postal-code field can hold a valid local code). Notice what the list never asks: whether anything looks odd to you. Unfamiliar and wrong are different properties, and the whole skill is separating them.
1 numbers separators · symbol side · digit script · minor units
2 dates field order · separators · calendar
3 plurals leftover "(s)" · untranslated fragments
4 direction reading start · arrows · bidi isolation
5 layout clipping · truncation · fixed widths
6 names field order · missing phonetic fields
7 input postal formats · maxLength · placeholdersSee it yourself
Try these, in order
Each step triggers a specific failure you should recognize on sight.
- 1On the "de-DE · Germany" tab, read the Gesamt line as a German shopper: which character should group thousands, and which should mark decimals? Click the line to flag it. The total shows $ with en-US separators. German formatting is 1.298,98 €, and the line item above it, 79,98 €, already shows the correct convention. Same screen, both frames. Only one is wrong.
- 2Scan every line for leftover English. Flag "3 item(s)" and the Rückgabe line. "item(s)" is the untranslated source string dodging plural grammar with a parenthesis. The returns note mixes German and English because code assembled the sentence: only the outer fragment reached a translator.
- 3Check the date next to "Lieferung:", then the pay button and the quoted shipping option. 07/17/2026 is month-first en-US order, while a German reader expects 17.7.2026. The button clips its German label at a fixed width, and "Standardversand" carries ASCII quotes where German writes „…“.
- 4Switch to the "ar-EG · Egypt" tab. If the screen looks fine, press "Show hints". Three bugs live here. The page reads right to left: check where the back control sits, which way the stepper arrows run, and which side of the digits the $ landed on in the total. The Arabic-Indic date, though, is exactly what Intl.DateTimeFormat('ar-EG') produces: leave it alone.
- 5On the "ja-JP · Japan" tab, run the names-and-input part of the checklist: field order, postal code length, and the extras line. The form asks for the given name first (Japan writes family name first), the postal field caps at 5 digits where Japan needs 7 (NNN-NNNN), and the extras list still joins with an English "and".
- 6Press "Check my audit", read the tally, then press "Reveal the answer key" for anything still hidden. The tally reads N of 12 found. Flagged decoys cost nothing and explain why they were correct. Missed bugs appear in amber where they sit, and each one links back to the lesson that covers its failure class.
Real code rendered every line of the screen below. Some of it ran the wrong locale, the wrong CSS, or no translation at all. Click a line to flag it. Click again to unflag. Work all three markets, then check your audit. Flagging a correct line costs nothing.
0 flagged across three markets. There are 12 seeded bugs in total.
Kasse
Warenkorb → Versand → Zahlung
Bestellübersicht
If you remember one thing
Read the screen as its market reads it. Audit numbers, dates, plurals, direction, layout, names, and input against the locale's own conventions. Deviations from the locale's formatter are bugs. Deviations from English are not.
What to do about it
- Before any market launch, walk each localized screen with a fixed checklist: numbers, dates, plurals, direction, layout, names, input. Reviewers with a checklist find more defects than reviewers without one.
- For every suspicious value, check what the locale's own formatter produces (
Intl.NumberFormat,Intl.DateTimeFormat,Intl.ListFormat). Flag deviations from that output, not deviations from English. - Run a pseudolocalization pass before translation starts. It finds the concatenation and hardcoded-string bugs on this screen without a translator.
- Budget a native-speaker review per market. A machine can check formatters. It cannot check register, word choice, or honorifics.
Use this with
Stakeholders
Moments
- ·Pre-launch market readiness review
- ·Defining the i18n QA checklist for a release
- ·Onboarding reviewers who will audit localized builds
Field note
Amazon opened amazon.se in October 2020 with a catalog machine-translated into Swedish and no market review pass. Launch-day pages rendered product names as vulgarities, translated "Nintendo Switch" games as fit for a "circuit breaker", and the country picker showed Argentina's flag for Sweden. None of it was a translation-engine mystery: every item was the kind of thing a native-conventions audit of the top screens would have caught before launch.
Quick check
3 questions · pass at 2+
Question 1/3
A checkout for de-DE shows the total as "$1,298.98". What does Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }) render for the same amount?
Question 2/3
On an Arabic checkout, the translated total line renders with the $ on the wrong side of the digits. Which failure class is this, and what fixes it?
Question 3/3
Auditing a ja-JP checkout, you see the total "￥12,800" with no decimal places. What do you do?