How do you handle UI text pluralization with ICU Message Format?

What's really being asked

This question checks whether you treat internationalization as a first-class engineering concern rather than an afterthought. Even senior engineers sometimes expose English-centric assumptions in UI code. The interviewer wants to see that you know plural forms vary dramatically across languages and that you rely on standardized data rather than reinventing locale logic.

The full answer

First, name a standard library such as ICU MessageFormat, FormatJS, or i18next with ICU plugins. Second, explain that these libraries use CLDR plural rules which define six keyword categories: zero, one, two, few, many, and other. Third, describe the pattern structure where each keyword maps to a full message string provided by translators, not just a suffix. Fourth, note that the library evaluates the numeric input against locale-specific rules to select the correct keyword, so the code itself never contains language-specific branching. Fifth, mention that an unquoted pound sign in the pattern is replaced by the formatted number, and that offsets can shift the value used for selection.

The mistakes people make

Hard-coding a ternary check like count equals one then item else items is the classic failure because it breaks on languages with multiple plural forms such as Polish or Arabic. Another red flag is suggesting string concatenation where the code appends an s or a translator-supplied suffix; this assumes English grammar and word order. Proposing ChoiceFormat-style numeric intervals is also wrong because languages like Polish have paucal cases that apply to non-contiguous number patterns, which interval logic cannot express.

What usually comes next

The interviewer may ask how you would handle pluralization in a language with no plural forms at all, such as Japanese or Korean, where the other case covers everything. They might also probe how you combine plural arguments with gender or select expressions in a single MessageFormat pattern, or how you keep translation keys manageable when every plural case requires a distinct string. Be ready to discuss extraction workflows where translators see the full pattern rather than isolated fragments.

A concrete example

In ICU MessageFormat, a Polish inventory message looks like this: You have {count, plural, one {# produkt} few {# produkty} many {# produktów} other {# produktu}}. The keyword one covers 1, few covers 2 through 4 and numbers ending in 2 through 4 excluding teens, many covers 0 and 5 through 21 and numbers ending in 0 or 5 through 9 and teens, and other serves as the fallback. The same pattern structure works for English with only one and other defined, demonstrating that the application code remains identical while CLDR rules handle locale complexity.