When "{n} items" Breaks Across Languages — Designing Quantity Strings with CLDR Plural Categories and Intl.PluralRules

Select the right form with Intl.PluralRules

Happily, looking up this map is built into the standard library. Give Intl.PluralRules a locale and a number, and it returns the matching category name.

// A thin wrapper that resolves a number to its CLDR category.
// Reuse one instance per locale to keep the cost down.
const rulesCache = new Map<string, Intl.PluralRules>();
 
function pluralCategory(locale: string, n: number): Intl.PluralCategory {
  let rules = rulesCache.get(locale);
  if (!rules) {
    rules = new Intl.PluralRules(locale); // defaults to cardinal
    rulesCache.set(locale, rules);
  }
  return rules.select(n);
}
 
// Examples
pluralCategory("en", 1);  // -> "one"
pluralCategory("en", 5);  // -> "other"
pluralCategory("ru", 2);  // -> "few"
pluralCategory("ru", 5);  // -> "many"
pluralCategory("ru", 21); // -> "one"
pluralCategory("ja", 3);  // -> "other"

select() always returns one of the six category names. From there you look up the string for that category, and you never write the per-language branch yourself. Notice Russian's 21 landing on one — a result the ternary could never reach, quietly corrected by the API.

One caveat: Hermes, the JavaScript engine behind React Native, only provides Intl.PluralRules in builds with Intl enabled. On a configuration without it, you hit a runtime exception, so wrap the lookup in a layer that checks for existence and falls back.

// Fall back to "other" when Intl.PluralRules is unavailable.
// At minimum, guarantee the sentence doesn't break in the majority language.
function safeCategory(locale: string, n: number): Intl.PluralCategory {
  try {
    if (typeof Intl?.PluralRules === "function") {
      return pluralCategory(locale, n);
    }
  } catch {
    // Swallow a runtime failure and fall to the default.
  }
  return n === 1 ? "one" : "other";
}

The fallback is a coarse, English-shaped rule, but the priority is that the app doesn't crash even on an Intl-disabled build. Where possible, enable Hermes Intl or load the @formatjs/intl-pluralrules polyfill to recover the true categories — that is the design you actually want.

Keep i18next plural keys as data, not code

If you use i18next for translations, this map maps straight onto your key naming. Internally i18next uses the same categories as Intl.PluralRules, resolving keys through suffixes like _one, _few, _many, and _other.

// ja/translation.json — other alone is enough
{
  "favorites_other": "お気に入り {{count}} 件"
}

// ru/translation.json — provide few / many / other
{
  "favorites_one": "{{count}} избранное",
  "favorites_few": "{{count}} избранных",
  "favorites_many": "{{count}} избранных",
  "favorites_other": "{{count}} избранного"
}

// The call site stays language-agnostic
t("favorites", { count: favorites.length });

The caller just passes count, and i18next picks the correctly suffixed key for the current locale. What you want to avoid is choosing favorites_one versus favorites_other yourself with count === 1 and baking it into the key. That throws away the map the library already holds and drags you back to the English binary. Decide once that the quantity branch lives in the data — the translation keys — not in the code.

Detecting missing keys and designing the fallback chain is a separate topic; I collected that in notes on stopping missing translations in CI. This article stays focused on the layer that selects the correct form.

Cardinals and ordinals follow different rules

There is one more branch that is easy to miss. A count like "3 items" (cardinal) and a rank like "3rd" (ordinal) are governed by different rules, even within the same language. English is the clearest case: cardinals split into one/other, but ordinals carry four forms — 1st, 2nd, 3rd, 4th.

Intl.PluralRules handles the difference through the type option.

// Look up ordinal categories
const ordinal = new Intl.PluralRules("en", { type: "ordinal" });
ordinal.select(1); // -> "one"  => 1st
ordinal.select(2); // -> "two"  => 2nd
ordinal.select(3); // -> "few"  => 3rd
ordinal.select(4); // -> "other" => 4th
 
const suffix: Record<string, string> = {
  one: "st", two: "nd", few: "rd", other: "th",
};
function ordinalEn(n: number): string {
  return `${n}${suffix[ordinal.select(n)]}`;
}
ordinalEn(21); // -> "21st"

Reuse the cardinal rule for a leaderboard or a "your Nth piece" label and English will emit something like "3th." Separating count from rank as distinct form designs from the start means the same map keeps working when you add rankings later.

Use the same map on the native side

For the native Swift that Rork Max generates, or when you use Xcode's String Catalog, the source of truth is the same CLDR. String Catalog lets a string vary by plural, and internally that maps onto the same categories (one/few/many/other …) as the older .stringsdict.

What matters for cross-language consistency is not holding separate branching logic in JavaScript and in native code. Keep both on the same two-step shape — look up a category from a number, then assign a string to that category — and translation additions and checks run through a single procedure. Even when the implementation languages differ, keep the map in your head a single sheet. That is the design decision.

Test the languages that break

The nasty part of this class of bug is that it never reproduces in a language the developer can read. So the effective move is to aim tests at languages you can't read.

First, use a pseudo-locale to surface layout breakage when strings expand and wrap. Then name the high-category languages explicitly and pin them into snapshots.

// Pin languages with many categories as representatives of what breaks
const RISKY = ["ru", "ar", "pl"] as const;
const SAMPLES = [0, 1, 2, 3, 5, 11, 21, 100];
 
for (const locale of RISKY) {
  for (const n of SAMPLES) {
    const cat = new Intl.PluralRules(locale).select(n);
    // Match the expected category against the presence of the translation key
    expect(translationHasKey(`favorites_${cat}`, locale)).toBe(true);
  }
}

The goal here is not the correctness of the wording itself but a mechanical check that no category a language needs is missing. Forgetting only the many key in Russian is invisible to the eye. Let CI watch the correspondence between categories and keys, and you get the same reassurance every time you add a language.

Closing thoughts

A quantity string is a plain single line inside an app. Yet it carries what feels natural to someone who speaks that language. Let go of the familiar "one is singular, everything else is plural" for a moment and hand the judgment to the map of CLDR categories. That alone lets you deliver a quietly correct display even to readers in languages you can't read.

I missed this trap in my first wallpaper app and only learned it from a post-release report. If it spares someone the same detour, I'll be glad. Thank you for reading.