Pluralization on Android looks simple until it isn’t. You add a <plurals> block, define a few quantities, and ship. Then a new language lands, QA reports strange grammar, or worse — your build starts failing in CI.
This post walks through how Android pluralization actually works, where teams usually get tripped up, and how to structure plural resources so they’re safe across languages and releases.
Android pluralization is built on ICU plural rules, not English rules. That means the quantities you define (zero, one, two, few, many, other) are evaluated differently depending on the target language.
A basic example:
<plurals name="item_count">
<item quantity="one">%d item</item>
<item quantity="other">%d items</item>
</plurals>
This works in English — but it’s incomplete for many other languages.
When a required plural category is missing, Android does not always fail loudly.
Depending on how the string is accessed and which value is passed, Android may:
- Fall back to the other category
- Return the resource key instead of a string
- Throw a runtime exception
This is why plural bugs are so hard to catch early. Many test values never exercise categories like few or many, so issues stay hidden until a specific language or count hits production.
Some languages are especially unforgiving if your base plural structure is incomplete:
one, few, and manyzero and twoIf your base plurals.xml file doesn’t account for these categories, every translated file inherits the same structural weakness.
one and other Are Enough¶They aren’t. Not globally.
Many teams localize their base language first, then translate later. If the base plurals.xml file is incomplete, every translated file inherits that problem.
quantity="one" does not mean “the number 1.” It means “whatever this language considers singular.”
In some languages, values like 21 map to one. In others, they don’t. Hardcoding English assumptions leads to grammatically incorrect UI even when translations are technically valid.
Plural strings almost always include placeholders:
<item quantity="few">%d items</item>
During translation, placeholders can be removed, reordered, or accidentally modified. The result is often a runtime formatting crash that only appears under specific conditions.
A safer base-language approach is to define all plural categories, even if English doesn’t need them:
<plurals name="item_count">
<item quantity="zero">%d items</item>
<item quantity="one">%d item</item>
<item quantity="two">%d items</item>
<item quantity="few">%d items</item>
<item quantity="many">%d items</item>
<item quantity="other">%d items</item>
</plurals>
This feels redundant — but it creates a structurally correct template for every language you add later.
Plural bugs often surface in CI after a new language is added or translations are updated.
That’s because CI is often the first place where:
- All plural categories are evaluated
- Placeholder consistency is checked
- Structural validation is enforced
Treating localization as a continuous process — with validation on every change — makes these failures predictable instead of surprising. This is a core part of modern continuous localization workflows.
Pluralization isn’t just copy — it’s structure.
If your base Android plurals are incomplete or loosely defined, problems will surface later, usually at the worst possible time. Treat plurals as part of your app’s contract, validate them continuously, and avoid English-centric assumptions.