A translation correct in a spreadsheet can be wrong on screen — too long, ambiguous without context, awkward beside an image. Linguistic QA reviews translations in the actual UI, before release.

METHODIn-context CHECKLISTYes SIGN-OFFPer release CATCHESMeaning

F01.1 · IN CONTEXT

On screen, not in a cell.

QA happens in the running product, where the translator sees the string in place — its length, its neighbours, the image beside it. Context reveals errors a spreadsheet hides.

F01.2 · THE CHECKLIST

Consistent scrutiny.

A checklist guides each review — accuracy, tone, terminology, truncation, punctuation. A shared list means every reviewer checks the same things to the same bar.

F01.3 · SIGN-OFF

A gate before release.

Each release’s localized strings are signed off before shipping. Sign-off makes QA a gate, not a nice-to-have that slips when timelines tighten.

F01.4 · WHAT IT CATCHES

Meaning, not just spelling.

Linguistic QA catches what spellcheck can’t — a technically-correct word that’s wrong in context, an ambiguous phrase, a tone that’s off. The judgement is human.

Some things only a native speaker catches — a phrase that’s grammatically fine but no one would say, a tone that’s subtly off. Native review is the human check that makes Chinese feel truly native.

WHONative speaker WHENPer release FEEDBACKLoop CATCHESNuance

F02.1 · THE REVIEWER

A fluent, local ear.

Review is done by a native Chinese speaker familiar with the brand — not a fluent second-language speaker. Only a native reliably hears what sounds natural versus merely correct.

F02.2 · CADENCE

Every release.

Native review runs on each release’s user-facing Chinese, focusing on what changed. It’s lightweight per cycle but never skipped — nuance regresses as fast as code.

F02.3 · FEEDBACK LOOP

Findings, back to source.

Issues flow back to translators and, where the source is the problem, to the English writers. Native review improves the system, not just the current release.

F02.4 · WHAT ONLY NATIVES CATCH

The unsayable sentence.

Natives catch the grammatically-perfect line no one would actually say, the unintended connotation, the register that’s a notch off. These are invisible to everyone else.

Localization is never “done” — new strings arrive constantly. The coverage tracker shows what percentage of each locale is translated and where the gaps are, so completeness is visible and managed.

METRIC% per locale GAPSVisible TARGET100% key paths DASHLive

F03.1 · THE METRIC

A percentage, per locale.

The tracker reports what share of catalog keys each locale has translated. One honest number per language replaces a vague sense of “mostly done.”

F03.2 · GAPS

Where it’s missing.

Beyond the headline percentage, the tracker shows which areas are untranslated — so gaps in a high-traffic flow are prioritised over an obscure settings page.

F03.3 · TARGETS

100% where it counts.

The target is full coverage of key user paths, not necessarily every string everywhere. Coverage goals are set by importance, so effort goes where users actually are.

F03.4 · DASHBOARD

Live, and shared.

Coverage is a live dashboard, visible to the whole team. Making completeness public keeps localization from silently falling behind as the product grows.

A translation that fits in the spreadsheet can still overflow its button or clip at a card edge. The overflow audit scans the live UI in every locale to catch truncation before users do.

SCANTruncation PERScreen · locale FINDSOverflow FIXTracked

F04.1 · THE SCAN

Looking for clipped text.

The audit renders each screen in each locale and looks for text that overflows, truncates or wraps badly. It checks what the user will actually see, not the source data.

F04.2 · PER SCREEN

Every locale, every layout.

Coverage spans key screens across both languages, plus the padded pseudo-locale as a worst case. If it survives pseudo-loc and Chinese, it survives real translations.

F04.3 · FINDINGS

Where it breaks.

Findings pinpoint the component, locale and screen where text breaks the layout. Most overflow traces to a fixed width or a missing wrap — fixable once seen.

F04.4 · FIXES

Back to the layout.

Fixes route to the layout (flex it) or, rarely, the translation (shorten it) — layout first, because shortening text to fit a box is the wrong default. Tracked to closure.

The termbase only works if it’s followed. The terminology check scans translations against the approved terms and flags any deviation — keeping key vocabulary consistent without manual policing.

CHECKVs termbase AUTOLinting FLAGSOff-term CONSISTENCYEnforced

F05.1 · TERMBASE MATCH

Did they use the right term?

The check compares each translation against the approved termbase — where a source term appears, it verifies the target uses the agreed translation, not a synonym.

F05.2 · AUTOMATION

Machine, not memory.

The check is automated — part of QA tooling — because remembering every approved term across thousands of strings is beyond any reviewer. The machine never forgets the termbase.

F05.3 · FLAGS

Deviation, surfaced.

Off-term translations are flagged for review with the expected term shown. Some deviations are intentional — a human decides — but none slip through unnoticed.

F05.4 · CONSISTENCY

One term, everywhere.

The result: a key term translates the same way across the entire product. Combined with translation memory, terminology stays locked from sentence to sentence.