#Developer Guide

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.

Most localization CI pipelines verify that translation files exist — not that they're correct. This post covers eight build-time checks that catch placeholder mismatches, incomplete plural forms, invisible encoding corruption, and the class of silent failures that AI-assisted translation introduces before they reach production.

With per-app language settings now standard on iOS 16+ and Android 13+, runtime locale switching is a first-class user expectation — not an edge case. This post covers the six distinct failure modes that occur when users change language mid-session, with platform-specific diagnosis and fixes for iOS, Android, and React Native. A correctly formatted string is useless if the locale state driving it is stale.

Number, date, and currency formatting is the localization category most teams treat as solved until it breaks in production. This guide covers correct formatter usage on iOS, Android, and React Native, documents the edge cases that consistently cause bugs — Arabic-Indic numerals, zero-decimal currencies, de-CH vs. de-DE — and provides a concrete testing checklist for every new locale you ship.

Most RTL launch failures aren't caused by engineers who didn't know better — they're caused by assumptions about who was handling which part of the review. This 27-item checklist covers layout mirroring, text rendering, number formatting, string quality, input behavior, and App Store distribution across iOS, Android, and React Native. Use it as a PR gate, a release sign-off template, or a handoff document to a localization QA vendor.

RTL failures cluster in predictable patterns that most test suites never exercise. This post covers six specific failure modes — from mirroring gaps in custom views to bidi rendering breaks in formatted strings — with reproduction steps and concrete fixes for Android, iOS, and React Native. Arabic and Hebrew together represent 400M+ potential users; these bugs are preventable with systematic testing.

Localization bugs ship silently, affect entire markets, and require coordinated fixes across engineering and translation teams. This guide covers a three-layer testing strategy — pseudo-localization, layout testing, and string validation — with platform-specific implementation details for iOS, Android, and React Native.