You paste your strings into ChatGPT before each release, get translations back in 10 minutes, and commit them. For v1, this feels like a reasonable tradeoff. By v5, you're debugging why your German UI calls the same feature three different things, your placeholder syntax has drifted across locales, and your translation "coverage" is quietly 60% stale.
This is the third post in a series on AI translation failures in mobile apps. The first post covered how LLMs lose context between strings and why that produces subtle, hard-to-catch errors. The second went deep on specific failure modes that survive to production — corrupted plurals, malformed placeholders, structural damage to resource files.
This post zooms out. Even if you fix every individual bug, the one-shot model has a structural problem that compounds across every release. The goal here is to name it precisely so you can decide what to do about it.
The workflow is simple enough that it's tempting to defend it:
For v1 — small string count, one or two languages, one developer who knows every string personally — this is genuinely fine. The session context is small enough that ChatGPT holds it coherently. You know the product well enough to spot bad output. There are no prior translations to contradict.
The wall appears incrementally, which is what makes it dangerous. By v3 or v4, you have:
At this point the workflow hasn't visibly broken — it just quietly starts producing worse output with no feedback signal. The build passes. The app ships. Users in affected locales start leaving reviews you can't read.
When you paste an entire strings file into ChatGPT, everything gets retranslated — including the 95% of strings that haven't changed since last release. This isn't just inefficient. It means terminology decisions made in v1 are silently overridden each time.
In v1, ChatGPT translated "workspace" as Arbeitsbereich in German. In v3, a slightly different prompt produces Workspace (borrowed English term). In v5, it becomes Projektbereich. No one flagged any of these as wrong because each individual translation is defensible. But a German user who's been using the app since v1 has now seen three different words for the same concept.
A continuous system translates only what changed — string-level diffing against the last approved translation, not file-level replacement. The strings that haven't changed don't get touched.
Translation memory (TM) is the mechanism that prevents the above. When a string has an approved translation, that translation is stored and reused — or surfaced as a reference — when related strings are translated in the future.
Without TM, each session is a blank slate. The LLM makes fresh decisions about terminology, formality register, and phrasing every time. Across 10 releases and 10 languages, this produces what linguists call inconsistency and what users call a buggy app.
Glossary enforcement is the other half of this. A locked glossary — "always translate 'workspace' as Arbeitsbereich; never borrow the English term" — gets injected into the prompt before translation runs. ChatGPT in a new session has no access to either of these mechanisms.
When you remove a feature, you (hopefully) delete its source strings. But the translated files don't automatically get updated. If your workflow is "paste everything in, get everything back," the deleted strings simply don't appear in the new output — but they may still exist in the locale files from the previous release.
Over several releases, you accumulate dead strings that:
A diff-aware system tracks deletions explicitly. Dead keys are flagged and removed. Your locale files stay in sync with source.
Who approved the French translation of your payments screen? In a one-shot workflow, nobody did. The LLM produced it, you committed it, and it shipped.
This creates two problems. First, there's no way to route a native speaker's correction back into the system in a way that persists. A French contractor might correct "Paiement" to "Règlement" in one file, but the next ChatGPT run will revert it. Second, there's no audit trail — you can't answer questions like "when did this string change?" or "which translations have been human-reviewed?"
For regulated industries (fintech, healthcare), this isn't just a quality concern. It's a compliance concern.
A review workflow doesn't have to mean every string goes to a human. It means AI drafts are flagged based on configurable risk criteria — string type, locale, validation failures — and routed accordingly. Low-risk UI chrome can auto-approve. Payment flows and legal copy go to a native reviewer. That distinction is impossible to make in a one-shot workflow.
As covered in Part 1 of this series, ChatGPT has no memory between sessions. Every time you open a new chat, the model starts cold — no knowledge of your product, your tone guidelines, your previous decisions.
Compounded across 10 releases, this produces drift in:
Individual strings might look fine in isolation. The problem is cumulative incoherence across the product experience.
This is the most underappreciated failure mode. In a one-shot workflow, your CI pipeline has no way to distinguish:
Everything looks green. The build passes. CI-integrated locale validation can catch structural errors, but it can't tell you that your Japanese translations are 14 months stale if the keys are still present.
Translation status — what's current, what's reviewed, what's AI-drafted pending review — should be a first-class build signal. In a continuous localization system, it is. In a one-shot workflow, it doesn't exist.
The term gets used loosely, so here's what it means in mechanical terms:
String-level diffing: On each commit or merge, the system compares source strings against the last translation run. Only new or modified strings are sent for translation. Unchanged strings use their existing approved translations.
Translation memory: Approved translations are stored in a queryable database. Before any string is sent to an AI model, the TM is checked for matches (exact or fuzzy). Exact matches are applied automatically. High-confidence fuzzy matches are suggested to reviewers. The AI only runs on strings with no TM coverage.
Glossary enforcement: A glossary of locked terms — product names, feature names, UI primitives — is injected into every AI translation prompt. The model is instructed to use these terms exactly, not generate alternatives. This is the mechanism that prevents "workspace" from becoming four different words across releases.
Review routing: Not every string needs human review. A continuous system lets you define routing rules: strings containing payment-related keys go to a reviewer; strings modified more than 6 months after their source string go to a reviewer; strings that failed placeholder validation go to a reviewer. Everything else auto-approves after AI translation.
Audit trail: Every string has a full history: source text → change date → AI draft → reviewer → approval. You can answer "what did this string say in Japanese six months ago?" and "who approved the German translation of this payment confirmation?"
CI integration: Translation status is queryable from your pipeline. You can fail builds on untranslated strings in release branches, warn on strings pending review, or block releases when locale coverage drops below a threshold.
None of this requires magic. It requires infrastructure.
If you're considering building continuous localization in-house, the component list is longer than it looks:
| Component | What It Is | Rough Effort |
|---|---|---|
| Translation memory store | Database + fuzzy match (e.g., Levenshtein or embedding-based) | 2–3 weeks |
| Diff engine | String-level change detection across branches/commits | 1–2 weeks |
| Glossary management | Term storage + prompt injection | 1 week |
| Validation layer | Placeholder, plural, structural checks | 2–3 weeks |
| Review workflow | Assignment, commenting, approval states, notifications | 3–4 weeks |
| CI integration | Status API, pipeline hooks, coverage thresholds | 1–2 weeks |
A realistic v1 estimate is 6–12 weeks of engineering time, depending on your stack. That's before you account for ongoing maintenance, edge cases across platform-specific file formats (.strings, .stringsdict, strings.xml, React Native JSON), and the ongoing cost of keeping the system current as your string volume grows.
The validation layer alone has enough failure modes to warrant its own post — we've covered many of them here. Placeholder validation, plural rule enforcement, structural integrity checks: each one is straightforward in isolation, complex when you're handling five platforms and twelve locales simultaneously.
For most teams, the honest build-vs-buy calculus points toward purpose-built tooling. The upfront cost of a platform is typically less than the engineering cost of building and maintaining equivalent infrastructure. We've written about where one-shot AI falls short structurally and what safe AI translation workflows look like in practice.
Here's an honest matrix. Not every team needs continuous localization on day one.
| Condition | One-Shot OK? |
|---|---|
| < 500 strings, < 5 languages, v1 launch | Yes |
| > 500 strings OR > 5 languages | No |
| Active users in existing locales | No — regression risk is real |
| Release cadence > once per month | No — drift compounds too fast |
| Multiple developers touching strings | No — no coordination mechanism |
| Payment, legal, or healthcare copy | No — review accountability required |
| Solo developer, prototype, no existing users | Yes |
The threshold that matters most is "do you have existing users in existing locales?" Once the answer is yes, you're no longer just producing translations — you're maintaining them. The one-shot model has no maintenance mechanism. Every release is a fresh start, which means every release potentially reverses decisions users have already learned.
The other threshold is team size. One developer who personally knows every string can catch a bad output. Three developers working across a 1,200-string corpus cannot.
AI translation speed is real. Getting a first draft of 500 strings back in 10 minutes is genuinely useful, and dismissing it entirely misses the point.
The problem isn't the AI — it's treating a workflow problem as a prompting problem. A better prompt won't give ChatGPT memory between sessions. A better prompt won't prevent stale strings from accumulating in your locale files. A better prompt won't create an audit trail or route broken translations to a reviewer.
Continuous localization is how you get AI's speed on every release without re-paying the context and quality tax each time. The translation memory means approved work compounds instead of getting overwritten. The diff engine means you're only paying for what changed. The review routing means human attention goes where it actually matters.
If you're still on the one-shot model and your app is past v1 with real users in multiple locales, the question isn't whether the compounding cost is real — it is — but whether you've noticed it yet. Usually you notice it in a user review, a support ticket in a language nobody on your team reads, or the moment someone asks you to explain why your German UI uses three different words for the same feature.
That's a hard conversation to have when the answer is "we pasted it into ChatGPT."
