Plural forms across languages — why 'append an s' does not scale

English grammar leads a lot of localization code astray, because English happens to have one of the simplest possible pluralization systems: a noun is either singular or plural, and the plural is usually formed by adding a suffix. Code written with that mental model — count the items, add an 's' if it is not exactly one — works for English and quietly breaks for most of the rest of the world.

Number marking is not universal

Japanese nouns do not inflect for number at all. The same word is used whether you mean one item or many; number, when it needs to be expressed, comes from context or an explicit counter word, not from a change to the noun itself. A localization pipeline that assumes every language distinguishes 'one' and 'other' the way English does will, at best, produce an awkward or redundant plural marker where the target language has no such concept.

Other languages sit at the opposite end: some require distinguishing not just singular and plural but several categories, with the correct form depending on the exact number or on which digits it ends in — a two-way English-style split is not enough to describe them correctly.

CLDR's plural categories

The Unicode Common Locale Data Repository (CLDR) is the standard reference most localization systems draw on for this, and it defines a fixed set of abstract plural category names used across languages: zero, one, two, few, many, and other. No language uses all six, and 'other' is the required fallback category every language has — for English, only 'one' and 'other' are used; for a language with no number inflection, only 'other' is used for every count.

Which category a given number falls into, and which categories a given language even has, are both defined per language in CLDR's plural rules data — the mapping is not something to hardcode per project, it is looked up from that shared reference.

Why naive concatenation fails

Two common shortcuts break as soon as a string leaves English:

• Appending a suffix in code — building the plural by conditionally adding an s to a noun — assumes the target language marks plurals the same way English does. It does not translate; it is an English grammar rule baked into logic that runs regardless of the output language.
• Concatenating a number and a noun at render time — joining count, a space, and the noun into one string — freezes English word order into the string and still leaves the plural form of the noun unresolved, since the correct form of the noun depends on the CLDR category the count falls into, not just on whether the noun is the same word used elsewhere in the game.

ICU MessageFormat as the portable expression

ICU MessageFormat's plural syntax lets a single translatable string encode every category a language needs, and lets the translator supply the correct wording for each one without touching code:

{count, plural,
  one {# item}
  other {# items}
}

What this means for your string files

The takeaway is not that every project needs full ICU MessageFormat support on day one — it is that pluralization has to be a first-class concept in the localization format from the start, resolved per language against CLDR's categories, rather than a suffix rule embedded in application code. Retrofitting it after strings are already flat, English-shaped templates is far more work than designing for it up front.