Practice i18n technical vocabulary: ICU message format, CLDR, plural rules, date and number formatting per locale, and externalising hardcoded strings.
0 / 5 completed
1 / 5
A developer says: "Use ICU message format for strings with variables and plural forms." What is ICU message format?
ICU message format solves a hard i18n problem: how do you handle strings that change based on count, gender, or other variables — across languages with very different grammatical rules? Simple string concatenation fails: 'You have ' + count + ' messages' produces grammatically wrong results in many languages. ICU format encodes the rules in the string itself: '{count, plural, zero {No messages} one {One message} other {{count} messages}}'. Libraries like FormatJS, MessageFormat, and many i18n frameworks support ICU.
2 / 5
An i18n engineer references 'CLDR data' when implementing locale-specific date formatting. What is CLDR?
CLDR (cldr.unicode.org) is the authoritative source of locale data. When a JavaScript Intl.DateTimeFormat object formats a date for fr-FR, it uses CLDR data. When a Java application displays a currency for ja-JP, it uses CLDR data. Engineers reference CLDR when implementing custom formatters, verifying that a library's locale support is CLDR-based, or checking what date format a specific locale uses. 'We pull plural rules from CLDR' is standard practice.
3 / 5
A localization engineer explains: "Russian has 3 plural forms, Arabic has 6, and Chinese has 1. This is why we cannot just use singular/plural." What are plural rules in i18n?
Plural rules are a common source of i18n bugs. English developers often assume two forms (1/many) and write code with binary plural handling — which breaks in Russian (1 item, 2-4 items, 5+ items have different forms), Arabic (six plural forms), or Welsh (six plural forms). CLDR defines plural categories: zero, one, two, few, many, other. ICU message format lets you map each number to the correct category, and translators provide a string for each category their language needs.
4 / 5
A developer asks: "Why does 1,000.50 display as 1.000,50 in German?" What i18n concept does this illustrate?
Number formatting varies widely across locales. Using Intl.NumberFormat (browser), NumberFormat (Java/ICU), or equivalent locale-aware APIs ensures correct formatting automatically. Never format numbers by manually inserting commas and periods — you will produce en-US format for all users. The same principle applies to currencies (symbol position, spacing), percentages (50% vs 50 % vs %50), and measurement units. 'Format numbers with the locale, not with string concatenation' is a core i18n rule.
5 / 5
During a code review, an engineer comments: "This hardcoded string needs to be externalized." What does externalising a string mean?
Externalising strings is the fundamental i18n step. A hardcoded string like cannot be translated without changing the code. Externalised: the code becomes and the string 'Submit Order' lives in en.json, de.json, fr.json. The i18n framework loads the appropriate file at runtime. Externalisation also catches the full scope of translation work: running an extractor tool reveals every hardcoded string in the codebase. Missing externalisations are found via pseudo-localization testing.