5 exercises — 5 exercises practising ICU MessageFormat plural rules, select expressions, nested patterns, and date/number format skeletons.
0 / 15 completed
1 / 15
A developer asks: "Why do we need ICU MessageFormat for plurals? Can't we just do count === 1 ? 'item' : 'items'?" Which explanation is correct?
The English ternary (singular/plural) breaks catastrophically for Arabic, Polish, Russian, and dozens of other languages — ICU MessageFormat is the only correct solution.
CLDR (Common Locale Data Repository) defines plural categories per language. Arabic: zero (0 items), one (1 item), two (2 items), few (3-10 items), many (11-99 items), other (100+ items) — six completely different phrase forms. Polish: one (1 item), few (2-4, 22-24, ... items), many (5-21, 25-31, ... items), other. English: one (1 item), other (everything else) — only two forms. ICU MessageFormat lets a single pattern in the source language be translated into language-appropriate plural forms by the translator: {count, plural, one {# item} other {# items}} in English becomes 6 cases in Arabic — handled correctly by the ICU runtime for each locale.
Key vocabulary: • CLDR plural categories — zero/one/two/few/many/other; the universal plural form taxonomy across all languages • plural rule — the mathematical rule determining which category applies for a given number in a specific language • ICU runtime — the library evaluating ICU patterns at runtime with actual count values
2 / 15
A localization engineer reviews a message: {gender, select, male {He replied to your comment} female {She replied to your comment} other {They replied to your comment}}. What ICU pattern is this and what is the purpose of the other
The select pattern is ICU's case-switching mechanism for non-numeric values — gender, tense, grammatical case, or any enum-like value that affects phrasing.
The other case in select is not optional — ICU requires it as the default for any value not explicitly matched. This is critical for robustness: if a user's gender data is missing or set to a value not in the pattern, other provides a grammatically neutral fallback. Best practices: always use other as a grammatically inclusive fallback (e.g., "they" in English), not as an error case. Languages where select is essential: Spanish ("él respondió" vs. "ella respondió"), German (noun gender affects articles: "der/die/das"), Russian (grammatical cases change verb and adjective endings based on subject gender).
Key vocabulary: • ICU select pattern — {variable, select, case1 {...} other {...}}; switches on a string value • other (select) — required default case; triggered by any value not explicitly listed in the pattern • gender-aware messaging — using select to provide grammatically correct phrases based on user gender/pronoun preference
3 / 15
A developer encounters this ICU pattern and asks what it does: {count, plural, one {{name} liked your photo} other {{name} and {count} others liked your photo}}. Is this valid ICU, and what does the double {{ indicate?
ICU allows free variable interpolation inside plural and select cases — the nested {name} is a standard placeholder, not special syntax.
The # symbol inside plural cases is a shorthand for the plural count value (equivalent to {count} as a number). But you can also use the full {count} if you need it formatted differently (e.g., with a specific number format). Other variables like {name} work the same as anywhere else. Complex real-world example: {numPhotos, plural, one {{name} shared 1 new photo with {numFriends, plural, one {1 friend} other {# friends}}} other {{name} shared # new photos with {numFriends, plural, one {1 friend} other {# friends}}}} — nested plural inside plural with shared variable reference.
Key vocabulary: • ICU placeholder — {variableName} inside a message pattern; replaced at runtime with the provided argument value • # (in plural) — shorthand for the formatted plural count value within a plural case • nested ICU patterns — plural or select patterns nested inside other plural/select cases; valid but increases translator complexity
4 / 15
A backend developer is formatting a date for display in multiple locales and asks about ICU date skeleton patterns. How do these differ from fixed date format strings like dd/MM/yyyy?
Date skeletons specify WHAT fields to show, not HOW to order them — the locale determines the order and separators, producing culturally correct output automatically.
The problem with hardcoded formats: dd/MM/yyyy works for UK users but confuses US users who expect MM/dd/yyyy. Japanese users expect yyyy/MM/dd. German users prefer dd.MM.yyyy. Instead of maintaining separate format strings per locale, use a skeleton: new Intl.DateTimeFormat(locale, {year: 'numeric', month: '2-digit', day: '2-digit'}).format(date) — same JavaScript, correct locale-specific output. ICU skeletons in message strings: {date, date, ::yMMMd} formats a date with year, 3-letter month, and day in the locale-appropriate order and style.
Key vocabulary: • date skeleton — ICU notation specifying date/time fields to include; locale determines field ordering • date format string — explicit pattern (dd/MM/yyyy) that produces the same output regardless of locale (avoid for localization) • Intl.DateTimeFormat — JavaScript built-in using CLDR locale data to format dates correctly per locale
5 / 15
A localization engineer identifies a bug: the French translation of an ICU plural message is missing the few and many plural categories. Is this a problem for French?
Plural categories are language-specific — providing categories a language doesn't use wastes effort; omitting categories a language does use causes incorrect output.
French plural rules (CLDR): one → numbers 0 and 1 (unusually, 0 uses singular in French), other → 2 and above. French does not use two, few, many, or zero categories. So a French translator only needs to provide: {count, plural, one {# élément} other {# éléments}}. If they were asked to provide few and many as well, those values would never be used. Contrast with Arabic (uses all 6), Russian (uses one/few/many/other), or Polish (uses one/few/many/other with complex rules). The ICU runtime uses CLDR to determine which case to apply for a given number in the active locale — unused categories are simply never triggered.
Key vocabulary: • plural category coverage — translators should only provide the CLDR categories applicable to their language • CLDR plural rules — language-specific rules mapping number values to plural category names • one (French plural) — French uses one category for both 0 and 1; unlike English where 0 uses other
6 / 15
Sarah, a senior developer, comments on a PR draft: 'I'm seeing inconsistent pluralization across the UI. The product description says 'one item', but the confirmation message uses 'items'. Shouldn't we be leveraging ICU MessageFormat for this? What's the best way to ensure consistent pluralization at scale?'
While simple `if/else` statements might work for a small number of components, they quickly become unmanageable. ICU MessageFormat provides a centralized and maintainable solution by defining plural rules once and referencing them throughout the application. Ignoring inconsistencies is not an option – it leads to a poor user experience and potential localization errors.
7 / 15
Mark, a localization engineer, is reviewing Slack messages for a new feature. He sees this message: 'You have 1 new notification.' and 'You have many notifications.'. Which of the following best describes the purpose of the ICU pattern used here?
The ICU pattern is used for pluralization. The one and many tags define the specific translations that will be used depending on the numerical value of the notification count. This allows the system to adapt the message appropriately for different numbers of notifications – a key aspect of localization engineering.
8 / 15
David, an API developer, receives this JSON response from a service: `{"count": 2, "product_name": "Widget"}`. He needs to format the product name for display in French and German. Which approach best utilizes ICU MessageFormat?
Directly manipulating strings or relying on fixed literals is inflexible and prone to errors. ICU MessageFormat offers a dynamic solution by allowing you to define plural patterns that can be automatically applied based on the numerical value (the 'count' in this case). This ensures consistency and simplifies localization management.
9 / 15
John: 'The build failed. The error message says 'Invalid count value'. What does ICU MessageFormat's count parameter refer to in this context?',
ICU MessageFormat's `count` parameter represents the numerical value used within the pluralization logic. It's the core input that dictates whether the message should use singular or plural forms. Options A, C and D are unrelated to ICU's functionality; they represent different aspects of a build failure.
10 / 15
Maria: 'I'm trying to translate this notification into Spanish. I've used ICU MessageFormat with the select parameter, but it's defaulting to 'male'. How can I ensure it correctly handles gendered pronouns?',
The select parameter in ICU MessageFormat controls the selection of a specific string based on predefined categories (like gender). While setting 'neutral' is sometimes useful, it doesn't fundamentally solve the problem; the core issue is that you need to define all relevant categories and ensure they are correctly mapped to the translation for each locale. Option D is incorrect as select only chooses between defined options.
11 / 15
Alex, a junior developer, asks during a code review: 'I've implemented pluralization using this ICU pattern: {count, plural, one {item} other {items}}. But I'm getting inconsistent results – sometimes it displays 'one item', and sometimes 'items'. What's likely causing this issue?',
The core problem is that ICU MessageFormat relies on the count parameter being correctly evaluated. The other options present overly simplistic or incorrect diagnoses of the issue. A misinterpretation of the evaluation process is most likely at play here – the pattern isn't dynamically substituting based on the count value.
12 / 15
During a Slack discussion about internationalization, Liam asks: 'We're using ICU MessageFormat to handle plural messages. I've set the select parameter to 'male' for a notification. However, the Spanish translation is still showing up with masculine pronouns even when the context suggests feminine ones. What's the best way to ensure correct gender handling?'
While ICU MessageFormat offers a degree of automatic gender handling via the select parameter, relying solely on this can be insufficient. More nuanced control is often needed, particularly when dealing with context-dependent gender variations. Using conditional logic within the translation file allows for greater flexibility and accuracy.
13 / 15
Emily, a localization engineer, is reviewing a PR description for a new feature: 'This PR implements ICU MessageFormat to handle plural counts in the product details page. The pattern uses {count, plural, zero {no products} one {one product} other {products}}. Is this an effective use of ICU MessageFormat and does it cover all potential scenarios?'
This pattern demonstrates a good understanding of ICU MessageFormat's capabilities. It correctly utilizes the count parameter and provides distinct pluralization rules for zero, one, and multiple products. The other options either misinterpret the functionality or introduce unnecessary complexity.
14 / 15
David is debugging a localization issue in an e-commerce app: 'I'm seeing that when a user adds three items to their cart, the message displays 'items' instead of 'item'. The code uses ICU MessageFormat with {count, plural, one {item} other {items}}. What could be causing this discrepancy?'
The most probable cause is an issue with how the count parameter is being passed to ICU MessageFormat. If the application logic isn't correctly providing the accurate count value, the pattern will produce incorrect results – a common source of confusion when working with dynamic pluralization.
15 / 15
During a standup meeting, Ben asks: 'We're using ICU MessageFormat to generate localized strings. I'm having trouble understanding how the format parameter interacts with the pattern. Can someone explain it?'
The format parameter within ICU MessageFormat is specifically designed for substituting dynamic data into the pattern. It leverages ICU's formatting capabilities to handle things like currency symbols, numbers, or other variables, creating highly customized and localized strings.
What will I practise in "ICU MessageFormat — Advanced Patterns Vocabulary — Localization Engineering | CoderLingo"?
5 exercises practising ICU MessageFormat plural rules, select expressions, nested patterns, and date/number format skeletons.
How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Localization Engineering Language exercises?
Browse the full Localization Engineering Language hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.