#Translation Workflow

Pluralization in React Native is deceptively complex. With no first-class plural resource system, rules are evaluated at runtime in JavaScript and behavior depends heavily on the i18n library you choose. This guide explains how React Native pluralization actually works, common failure modes teams encounter in production, and why English-only testing is insufficient. It covers library tradeoffs, runtime behavior, languages that break naive implementations, and why plural bugs tend to surface late. You’ll also learn how continuous localization and automated validation help React Native teams keep plurals correct as apps scale.

iOS pluralization is powerful, flexible—and notoriously easy to get wrong. Instead of a simple plural resource type, iOS relies on .stringsdict files that combine plural rules, formatting logic, and variable substitution. The syntax is verbose, the failure modes are subtle, and many mistakes don’t appear until you add multiple languages. Missing plural categories can cause incorrect fallbacks or even return raw keys instead of strings, while placeholder specifiers like %d or %@ can drift during translation and trigger runtime formatting errors. This guide walks through how .stringsdict files are evaluated, the most common traps teams fall into, and how to structure plural logic defensively. The goal is to make pluralization predictable and safe, even as your app scales to more languages and contributors.

Android pluralization looks simple until it isn’t. You add a <plurals> block, define one and other, and ship. Then you add a new language, QA finds broken grammar, or your build starts failing because the plural categories don’t match what that language actually needs. Android’s rules are ICU-based and language-specific, which means quantity="one" does not always mean “the number 1,” and many languages require categories like few, many, or two. Plural strings also almost always contain placeholders, and translation updates can quietly remove, reorder, or corrupt them—often without an obvious error until runtime. This guide explains how Android plurals really work, the most common mistakes teams make, how to structure plural resources defensively in your base language, and what to validate so plural bugs don’t show up late (or in production).

Store listing localization delivers 20-40% conversion improvements in new markets but remains one of the most overlooked growth levers. Most teams translate their in-app UI while leaving store metadata in English, losing discoverability and installs from users who search in their native language. Strategic localization of titles, descriptions, and keywords can significantly boost organic installs without changing any code.

Teams rarely decide all at once to replace their localization setup — they circle the decision as friction accumulates. Warning signs include translation fixes that resurface after regeneration, engineers editing copy in languages they don't speak, and CI failures that include localization issues. The real decision isn't about tools or features, but whether teams want to continue owning correctness, validation, and long-term maintenance of their localization system.

Localization rarely breaks all at once — it gets harder gradually as teams grow. Around ten engineers, informal ownership stops working as string changes become frequent, more stakeholders need input, and edge cases surface regularly. The work becomes predictable but unplanned, creating persistent friction in development workflows.

AI translation fails predictably in production through placeholder mismatches, incomplete plural forms, structurally invalid files, and unwanted translation of brand names. Teams mitigate these risks with automated validation, translation memory, and treating AI output as untrusted input that requires verification before deployment.

Most teams don't set out to build localization tooling — they arrive there gradually with a few languages, a handful of strings, and the assumption that translation is mostly a one-time task. The upfront build typically costs $10k–$20k and ongoing maintenance runs $5k–$10k annually, not counting coordination overhead when non-engineers need to manage translations. The real question isn't whether you can build it, but whether you want to keep owning a system that requires persistent attention.

Building your own AI localization system starts simple: extract strings, call an API, insert translations. The complexity emerges when you need translation memory for consistency, brand term protection, quality controls, review workflows, plural handling, and ongoing maintenance across multiple languages and platforms. This analysis examines the real engineering costs and hidden complexity of custom localization systems versus dedicated platforms.

Mobile localization bugs behave like undefined behavior in C++ — everything works until specific locales reveal edge cases that crash builds or silently fall back to English. Proper validation treats translation files as compiled resources, checking structural integrity, placeholder consistency, and platform-specific formatting requirements. This includes validating complex plural systems like Polish, where categories depend on both final digits and ranges, ensuring every translated file meets platform requirements before reaching production.