Locale data
The maintained data behind local date patterns, number symbols, plural rules, alphabet order, and other behavior exposed through Intl.
What it is
Locale data is the structured set of conventions software consults to format and compare language-sensitive content. Unicode CLDR records things such as date patterns, month names, decimal symbols, plural categories, collation rules, and localized currency names. ICU consumes that data, and browser Intl APIs expose much of the behavior to JavaScript.
Reach for CLDR-backed APIs instead of maintaining country tables in the app. Pass a BCP 47 tag to Intl.DateTimeFormat, Intl.NumberFormat, Intl.PluralRules, or Intl.Collator and let the runtime select the data. If a server or polyfill bundles locale packs, load only the locales the product supports and keep their CLDR version consistent. Node.js is the classic trap: builds before version 13 shipped small-icu with English data only, so Intl silently formatted every locale as en-US until someone installed full-icu.
Gotcha: locale data is not your translated product copy, and it is not a source of live exchange rates, tax rules, or legal requirements. CLDR can supply a localized time zone name, but daylight-saving transitions come from the IANA time zone database. Treat those as separate datasets with separate update cycles.
Ask AI for it
Delete the hand-written country and language formatting tables. Replace them with Intl.DateTimeFormat, Intl.NumberFormat, Intl.PluralRules, and Intl.Collator calls driven by one canonical BCP 47 locale tag. If the target runtime lacks a required locale, load that locale's FormatJS polyfill data generated from Unicode CLDR, pin the package version in the lockfile, and document which CLDR release it uses. Keep message translations, IANA time zone rules, exchange rates, tax logic, and currency choice outside the locale-data module.