A localization project rarely fails because of one catastrophic error. It fails through accumulated small omissions: a glossary that was never built, a right-to-left layout nobody tested, a legal page that slipped into the machine-only tier. A good verification list catches those omissions before they reach users.
This is meant to be used, not just read. Each item includes a short reason, because a check you do not understand is a check you will skip under deadline. Work through it before any localized content goes live, and revisit the high-stakes items every time you add a market.
Treat the list as a starting template. Some items will not apply to your situation, and your domain may add a few. The structure, however, holds across most projects.
Before You Translate Anything
Foundation Checks
- Glossary exists and is populated. Brand names, product terms, and approved phrasing should be locked before the first string runs through any engine, or the model will re-guess them inconsistently.
- Translation memory is seeded. If you have any prior approved translations, import them. Reuse is the cheapest quality and speed lever you have.
- Content is tiered by risk. Sort everything into machine-only, machine-plus-spot-check, and machine-draft-plus-full-review. Without tiering, you either over-spend on low-stakes content or under-protect high-stakes content.
- Source content is clean. Fix typos and ambiguous phrasing in the source first. Errors in the source multiply across every target language.
- Ambiguous source phrasing is rewritten. Sentences that a human could read two ways will confuse the engine in every language. Rewriting them once at the source is cheaper than correcting the result everywhere.
- Target markets and locales are confirmed. Distinguish language from locale; Portuguese for Brazil and Portugal differ, as do English variants. Confirm which locale each market actually needs before configuring anything.
During Translation
Context and Configuration Checks
- UI strings carry context comments. Isolated words like "Run" or "Share" need a note telling the engine whether they are verbs, nouns, or labels. This single step prevents a large share of UI mistranslations.
- Placeholders and variables are protected. Confirm that tokens like {username} or %s pass through untouched. A translated placeholder is a runtime bug.
- Locale formatting is configured. Dates, currencies, numbers, and units should follow each locale's conventions, not a find-and-replace of the source format.
- Tone and register are specified. Tell the engine whether to be formal or casual per market. Register mistakes read as rudeness even when the words are technically correct.
- Text expansion is accounted for. Some languages run 30 percent longer than English. Confirm that buttons, menus, and fixed-width elements survive the longest target before you ship, not after a screenshot embarrasses you.
- Non-translatable strings are marked. Brand names, code snippets, and proper nouns that should never change must be flagged so the engine leaves them alone. An over-translated brand name is a subtle but real error.
After Translation, Before Launch
Review and Validation Checks
- High-stakes content has human sign-off. Legal, financial, medical, and safety content should be reviewed and approved by a qualified human, never shipped on raw machine output.
- A native speaker spot-checks each language. Even machine-plus-light-review tiers benefit from one native read of the highest-visibility pages.
- Layout is tested in every script. Right-to-left languages and text-expansion-prone languages like German routinely break designs built for English.
- Links and embedded media are localized. A correctly translated page that links to an English-only resource still breaks the experience.
- Pluralization and grammatical gender are handled. Many languages have plural rules and gendered agreement that simple string substitution gets wrong. Confirm your tooling supports proper plural forms rather than appending an "s."
- A real user reads one full flow per market. Beyond spot-checking strings, have someone walk a complete journey, such as sign-up to first action, in each high-priority language. Isolated strings can each be correct while the flow as a whole reads strangely.
Ongoing After Launch
Maintenance Checks
- Correction tickets are tracked per language. A spike in one language signals a systemic issue, not random noise. Instrument this from day one, as covered in Reading the Signal in Localization Quality Numbers.
- Translation memory is updated from corrections. Every human fix should feed back so the same error never recurs. This is what makes the system improve over time.
- New content re-enters the tiering process. Release notes, new features, and campaigns should pass through the same triage, not bypass it because the project "shipped." The first-pass version of this discipline is laid out in Shipping One Localized Page Before You Buy a Platform.
Watch for Format Drift
- Translated files validate against their schema. JSON, XML, and similar formats can break if the engine alters structural characters or escapes. Validate every translated file programmatically before it reaches production.
- Character encoding is consistent. Confirm that accented characters, non-Latin scripts, and special symbols render correctly end to end. Encoding mismatches produce garbled text that looks fine in one tool and broken in another.
How to Use This List
Make It a Living Document
Copy these items into your project tracker and assign owners. The value comes from accountability, not from the list sitting in a document. Pair it with the decision logic in Weighing the Real Costs Behind Localized Copy so each check connects to a reasoned trade-off rather than a rote step.
Sequence the Items by Phase
The list is organized into four phases for a reason: an item done at the wrong time is nearly worthless. Building a glossary after you have translated everything means re-running the whole job. Testing layout before content exists means testing nothing. Run the phases in order, and treat the gate between phases as real, content does not advance to translation until the foundation phase is complete and signed off. Teams that skip the gates tend to discover foundation problems halfway through translation, when fixing them is most expensive.
Adapt the List to Your Domain
A few domains add their own non-negotiable checks. Healthcare adds clinical-accuracy review; finance adds regulatory disclosure verification; gaming adds character-name and lore consistency. Add those items where they apply, but resist deleting the universal foundation and high-stakes-review checks, which earn their place in nearly every project regardless of domain.
Assigning Ownership to Each Check
Who Owns What
A list without owners is a wish list. Foundation checks, glossary, translation memory, and content tiering, belong to whoever leads localization. Configuration checks like placeholder protection, locale formatting, and encoding belong to engineering. Review checks belong to native-speaking reviewers and, for high-stakes content, qualified domain specialists. Maintenance checks belong to whoever owns the localization process long-term. Writing the owner next to each item is what turns the list from a document into a working tool, because every check has a name attached and a clear point of accountability.
Running the List in Practice
The most effective teams run the list as a series of gates rather than a single end-of-project review. The foundation gate closes before any translation begins. The configuration gate closes before content reaches reviewers. The review gate closes before launch. The maintenance gate runs continuously afterward. Treating each phase as a real gate, where work does not advance until the gate's items are checked and signed, is what prevents the slow accumulation of small omissions that sink localization projects. A check performed too late is barely better than a check skipped entirely.
Frequently Asked Questions
Do I need every item for a small project?
No. The foundation and high-stakes review items apply almost universally, but a tiny internal tool can skip native spot-checks and ongoing ticket tracking. Scale the rigor to the stakes.
What is the single most skipped item?
Context comments on UI strings. They feel tedious during setup and are invisible until short strings start mistranslating in production, at which point fixing them is far more expensive.
How often should I revisit the list?
Run the full list at first launch, then re-run the maintenance and high-stakes sections every time you add a market or ship significant new content.
Can the list replace a human reviewer?
No. The list ensures a reviewer's effort is spent where it matters, but it does not substitute for human judgment on legal, medical, or brand-critical content.
Should engineering or localization own this list?
Both. Foundation and review items are localization-owned; placeholder protection, locale formatting, and layout testing are engineering-owned. Shared ownership prevents the gaps that single-team lists leave open.
Key Takeaways
- Build the glossary and seed translation memory before translating a single string.
- Tier content by risk first, then apply the right depth of review to each tier.
- Context comments on isolated UI strings prevent a large share of mistranslations.
- Test layout in right-to-left and text-expanding languages before launch, not after.
- Feed every human correction back into translation memory so errors do not recur.