Common Locale Data Repository
Learn about Common Locale Data Repository
topic at defaultLogic. defaultLogic
provides comprehensive technology and business learning resources.
The Common Locale Data Repository Project, often abbreviated as CLDR, is a project of the Unicode Consortium to provide locale data in the XML format for use in computer applications. CLDR contains locale-specific information that an operating system will typically provide to applications. CLDR is written in LDML (Locale Data Markup Language). The information is currently used in International Components for Unicode, Apple's macOS, LibreOffice, MediaWiki, and IBM's AIX, among other applications and operating systems.
Among the types of data that CLDR includes are the following:
- Translations for language names.
- Translations for territory and country names.
- Translations for currency names, including singular/plural modifications.
- Translations for weekday, month, era, period of day, in full and abbreviated forms.
- Translations for timezones and example cities (or similar) for timezones.
- Translations for calendar fields.
- Patterns for formatting/parsing dates or times of day.
- Exemplar sets of characters used for writing the language.
- Patterns for formatting/parsing numbers.
- Rules for language-adapted collation.
- Rules for formatting numbers in traditional numeral systems (like Roman numerals, Armenian numerals, ...).
- Rules for spelling out numbers as words.
- Rules for transliteration between scripts. A lot of it is based on BGN/PCGN romanization.
It overlaps somewhat with ISO/IEC 15897 (POSIX locales). POSIX locale information can be derived from CLDR by using some of CLDR's conversion tools.
CLDR is maintained by the CLDR technical committee, which includes employees from IBM, Apple, Google, Microsoft, and some government-based organizations. The committee is currently chaired by John Emmons (IBM), with Mark Davis (Google) as vice-chair.
- ^ a b CLDR Releases/Downloads
- ^ Updating DTDs, CLDR makes special use of XML because of the way it is structured. In particular, the XML is designed so that you can read in a CLDR XML file and interpret it as an unordered list of <path,value> pairs, called a CLDRFile internally. These path/value pairs can be added to or deleted, and then the CLDRFile can be written back out to disk, resulting in a valid XML file. That is a very powerful mechanism, and also allows for the CLDR inheritance model.
- ^ http://cldr.unicode.org/index/process#TOC-Officers