#Translation Workflow

Pseudo-localization catches structural issues — truncated strings, broken layouts, hardcoded text — but it leaves a predictable set of semantic and logic bugs untouched. Plural forms collapse to a single tested path, placeholder reordering silently corrupts formatted strings, and RTL layout breaks only appear with real Arabic or Hebrew content. This post covers the five bug categories that reliably survive pseudo-localization and the targeted, automatable tests that catch them before production.

Every AI translation pass without a Translation Memory pays the full cost of localization for strings that were already approved last release. This post covers how to build and wire a Translation Memory and Glossary into your AI pipeline so incremental releases only pay for the delta — with concrete implementation steps for Android, iOS, and React Native.

AI-translated localization files routinely pass CI while containing broken placeholders, missing plural categories, and inconsistent terminology. These five validation gates — placeholder integrity, file structure, plural coverage, glossary consistency, and human spot-check routing — are the enforcement layer between LLM output and your release branch. Each can be wired into a standard GitHub Actions pipeline with minimal setup.

AI translation tools like ChatGPT have no memory of what they translated three strings ago, producing different words for the same concept across your app. This post covers the five most common terminology drift patterns, shows a concrete before/after in Android strings.xml, and explains why the fix has to happen at the pipeline level — not the prompt level.

Pasting strings into ChatGPT before each release works until it doesn't — and the failure is cumulative, not sudden. This post details six structural breakdowns that compound across releases when you treat AI translation as a one-time task rather than a continuous workflow, and provides a practical framework for deciding when to make the switch.

AI-generated translations are syntactically valid, which means they pass standard CI checks and look fine in code review—until a native speaker opens the app. This post documents seven structural failure modes that survive every standard quality gate, with the exact pre-release checks that catch each one before they reach production.

AI translation tools process strings as isolated key-value pairs, with no knowledge of screen context, UI element type, glossary constraints, or prior translation decisions. This produces fluent, grammatically correct output that is semantically wrong in ways no automated checker catches — wrong part of speech, broken gender agreement, formality drift, terminology inconsistency, and silently truncated strings.

Most AI translation failures in mobile apps are caused by what you hand the model, not by the model itself. This checklist covers file format preparation, context attachment, terminology constraints, and locale-specific rules for strings.xml, .strings, .stringsdict, and React Native JSON — the steps that determine whether you get clean output or a debugging session.

After a bad AI translation run, localization bugs fall into four distinct classes — structural, placeholder, plural, and semantic — each requiring a different debugging approach. This playbook walks through platform-specific validation tools, a scriptable placeholder audit, CLDR-aware plural checks, and a structured semantic spot-check protocol. Running these steps in sequence gets you from "something is wrong in production" to a validated, CI-gated localization pipeline.

Pluralization is the highest-risk surface for one-shot LLM translation: rules are language-specific, file formats are deeply structured, and the failure modes are invisible at compile time. This post covers six specific ways Claude and ChatGPT corrupt .stringsdict, Android quantity strings, and ICU MessageFormat files — and why standard CI pipelines catch none of them.