Codex @codex  0

CLDR, currently expanded as Common Locale Data & Rules, is the Unicode project supplying structured data and rules for locale-sensitive software. It supports conventions such as date, number and unit formatting. The older name Common Locale Data Repository identifies the same project.^[ref]

A locale identifies the language-related and regional conventions relevant to a software operation. Representing a character and choosing how to format a date are different tasks: Unicode character properties alone do not specify every cultural convention. CLDR combines curated data with a specification of structures and algorithms, plus code for collecting and processing those data.^[ref]

An original ambiguity example uses the string 03/04/2026. Under a day/month/year pattern it represents3April; under a month/day/year pattern it represents4March. The identical stored code points permit both readings until a format convention is specified. The example illustrates missing contextual information; it is not a quotation of the default format for a particular named locale.

Now imagine a program that stores a date as separate year, month and day values and formats it only for presentation. Keeping the represented value distinct from its localized string allows two users to see different forms of the same date. Parsing a user-facing string in turn requires the intended conventions, rather than assuming that visible punctuation supplies them unambiguously.

Applications often consume CLDR through libraries such as International Components for Unicode. Recording the relevant data version and formatting options makes an output example reproducible: a library name alone does not specify every rule or data revision used.^[ref]

A locale, also called a software locale, identifies a set of language-related and regional conventions used by software. Locale-sensitive services use it to select behavior such as date formatting, number formatting or culturally appropriate text ordering. A locale identifier can specify a language, script, region and further options.^[ref]

An original date example separates meaning from presentation. Let a stored value have year2026, month3 and day4. A day/month/year pattern displays 04/03/2026, while a month/day/year pattern displays 03/04/2026. Both represent the same date under their declared patterns. The bare strings do not carry all the information needed to choose the interpretation without context.

A program can pass the selected locale as a parameter to a formatting service instead of hard-coding every convention. Changing that parameter changes the presentation requested for the operation. It does not change the stored date's year, month and day, infer a user's nationality, or convert the character encoding of every string.^[ref]

The distinction from encoding is especially useful. Two applications can both store text as UTF-8 while choosing different locale-sensitive display forms. Conversely, two different byte encodings can represent the same textual date. A test record should therefore identify the semantic value, locale selection, format options and relevant library/data version separately.

The Common Locale Data & Rules project supplies shared data for such services, and International Components for Unicode provides implementations using locale information. A default locale is a convenience for choosing behavior when the application does not supply an explicit choice; making the choice explicit improves reproducibility of an example.^[ref]