UTS #35: Locale Data Markup Language

The deprecated items can be used to indicate elements, attributes, and attribute values
that are deprecated. This means that the items are valid, but
that their usage is strongly discouraged. When the same deprecatedItems element contains
combinations of elements, attributes, and values, then the "least significant" items are only
deprecated if they occur with the "more significant" items. For example:
Deprecated Items
elements="A B">
A and B are deprecated
attributes="C D">
C and D are deprecated on all
elements
elements="A B" attributes="C D">
C and D are deprecated, but only
if they occur on elements A or B.
elements="A B" attributes="C D" values="E">
E is deprecated, but only if it
is a value of C in an element A or B
In each case, multiple items are space-delimited.

The characters element provides a way for non-Unicode systems, or systems that only
support a subset of Unicode characters, to transform CLDR data. It gives a list of characters with
alternative values that can be used if the main value is not available. For example:



ss


Ö
O


Pts


Fr.



The ordering of the alternate elements indicates the preference among them.
Appendix D:
Language and Locale IDs
People have very slippery notions of what distinguishes a language code vs. a locale code. The
problem is that both are somewhat nebulous concepts.
In practice, many people use [
RFC3066
] codes to mean locale codes
instead of strictly language codes. It is easy to see why this came about; because [
RFC3066
includes an explicit region (territory) code, for most people it was sufficient for use as a
locale code as well. For example, when typical web software receives an [
RFC3066
code, it will use it as a locale code. Other typical software will do the same: in practice,
language codes and locale codes are treated interchangeably. Some people recommend distinguishing
on the basis of "-" vs "_" (e.g.
zh-TW
for language code,
zh_TW
for locale code),
but in practice that does not work because of the free variation out in the world in the use of
these separators. Notice that Windows, for example, uses "-" as a separator in its locale codes.
So pragmatically one is forced to treat "-" and "_" as equivalent when interpreting either one on
input.
Another reason for the conflation of these codes is that
very
little data in most
systems is distinguished by region alone; currency codes and measurement systems being some of the
few. Sometimes date or number formats are mentioned as regional, but that really doesn't make much
sense. If people see the sentence "You will have to adjust the value to १,२३४.५६७ from ૭૧,૨૩૪.૫૬"
(using Indic digits), they would say that sentence is simply not English. Number format is far
more closely associated with language than it is with region. The same is true for date formats:
people would never expect to see intermixed a date in the format "2003年4月1日" (using Kanji) in text
purporting to be purely English. There are regional differences in date and number format —
differences which can be important — but those are different in kind than other language
differences between regions.
As far as we are concerned —
as a completely practical matter
— two languages are
different if they require substantially different localized resources. Distinctions according to
spoken form are important in some contexts, but the written form is by far and away the most
important issue for data interchange. Unfortunately, this is not the principle used in [
ISO639
],
which has the fairly unproductive notion (for data interchange) that only spoken language matters
(it is also not completely consistent about this, however).
RFC3066
can
express a difference if the use of written
languages happens to correspond to region boundaries expressed as [
ISO3166
region codes, and has recently added codes that allow it to express some important cases that are
not distinguished by [
ISO3166
] codes. These include simplified and
traditional Chinese (both used in Hong Kong S.A.R.); Latin Serbian, Azeri, and Uzbek in both
Cyrillic and; Azeri in Arab.
Notice also that
currency codes
are different than
currency localizations
. The
currency localizations should normally be in the language-based resource bundles, not in the
territory-based resource bundles. Thus, the resource bundle
en
contains the localized
mappings in English for a range of different currency codes: USD => $, RUR => Rub, etc. (In
protocols, the currency codes should always accompany any currency amounts; otherwise the data is
ambiguous, and software is forced to use the user's territory to guess at the currency. For some
informal discussion of this, see
JIT
Localization
.)
Written Language
Criteria for what makes a written language should be purely pragmatic;
what would
copy-editors say?
If one gave them text like the following, they would respond that is far
from acceptable English for publication, and ask for it to be redone:
"Theatre Center News: The date of the last version of this document was 2003年3月20日.
A copy can be obtained for $50,0 or 1.234,57 грн. We would like to acknowledge contributions by
the following authors (in alphabetical order): Alaa Ghoneim, Behdad Esfahbod, Ahmed Talaat, Eric
Mader, Asmus Freytag, Avery Bishop, and Doug Felt."
So one would change it to either B or C below, depending on which orthographic variant of
English was the target for the publication:
"Theater Center News: The date of the last version of this document was 3/20/2003. A copy
can be obtained for $50.00 or 1,234.57 Ukrainian Hryvni. We would like to acknowledge
contributions by the following authors (in alphabetical order): Alaa Ghoneim, Ahmed Talaat,
Asmus Freytag, Avery Bishop, Behdad Esfahbod, Doug Felt, Eric Mader."
"Theatre Centre News: The date of the last version of this document was 20/3/2003. A copy
can be obtained for $50.00 or 1,234.57 Ukrainian Hryvni. We would like to acknowledge
contributions by the following authors (in alphabetical order): Alaa Ghoneim, Ahmed Talaat,
Asmus Freytag, Avery Bishop, Behdad Esfahbod, Doug Felt, Eric Mader."
Clearly there are many acceptable variations on this text. For example, copy editors might
still quibble with the use of first vs. last name sorting in the list, but clearly the first list
was
not
acceptable English alphabetical order. And in quoting a name, like "Theatre Centre
News", one may leave it in the source orthography even if it differs from the publication target
orthography. And so on. However, just as clearly, there limits on what is acceptable English, and
"2003年3月20日", for example, is
not
Appendix E:
Unicode Sets
A UnicodeSet is a set of Unicode characters (and possibly strings) determined by a pattern,
following
UTS #18: Unicode Regular
Expressions
URegex
]. For an example of a concrete implementation of
this, see [
ICUUnicodeSet
].
Patterns are a series of characters bounded by square brackets that contain lists of characters
and Unicode property sets. Lists are a sequence of characters that may have ranges indicated by a
'-' between two characters, as in "a-z". The sequence specifies the range of all characters from
the left to the right, in Unicode order. For example,
[a c d-f m]
is equivalent to
[a c
d e f m]
. Whitespace can be freely used for clarity, as
[a c d-f m]
means the same as
[acd-fm]
Unicode property sets are specified by any Unicode property, such as [:Letter:], using the
PropertyAlias file and the PropertyValueAlias file. The syntax for specifying the property names
is an extension of either POSIX or Perl syntax with the addition of "=value". For example, you can
match letters by using the POSIX syntax
[:Letter:]
, or by using the Perl-style syntax
\p{Letter}
The type can be omitted for the Category and Script properties, but is required for other
properties.
The table below shows the two kinds of syntax: POSIX and Perl style. Also, the table shows the
"Negative", which is a property that excludes all characters of a given kind. For example,
[:^Letter:]
matches all characters that are not
[:Letter:]
Positive
Negative
POSIX-style Syntax
[:type=value:]
[:^type=value:]
Perl-style Syntax
\p{type=value}
\P{type=value}
These following low-level lists or properties then can be freely combined with the normal set
operations (union, inverse, difference, and intersection):
To union two sets, simply concatenate them. For example,
[[:letter:] [:number:]]
To intersect two sets, use the '&' operator. For example,
[[:letter:] & [a-z]]
To take the set-difference of two sets, use the '-' operator. For example,
[[:letter:] -
[a-z]]
To invert a set, place a '^' immediately after the opening '['. For example,
[^a-z]
In any other location, the '^' does not have a special meaning.
The binary operators '&' and '-' have equal precedence and bind left-to-right. Thus
[[:letter:]-[a-z]-[\u0100-\u01FF]]
is equivalent to
[[[:letter:]-[a-z]]-[\u0100-\u01FF]]
Another example is the set
[[ace][bdf] - [abc][def]]
, which is not the empty set, but
instead the set
[def]
Another caveat with the '&' and '-' operators is that they operate between sets. That is, they
must be immediately preceded and immediately followed by a set. For example, the pattern
[[:Lu:]-A]
is illegal, since it is interpreted as the set
[:Lu:]
followed by the
incomplete range
-A
. To specify the set of uppercase letters except for 'A', enclose the
'A' in a set:
[[:Lu:]-[A]]
. A multicharacter string can be in a Unicode set, to represent a
tailored grapheme cluster for a particular language. The syntax uses curly braces for that case.
[a]
The set containing 'a'
[a-z]
The set containing 'a' through 'z' and all letters in between, in Unicode order
[^a-z]
The set containing all characters but 'a' through 'z', that is, U+0000 through 'a'-1 and
'z'+1 through U+FFFF
[[pat1][pat2]]
The union of sets specified by pat1 and pat2
[[pat1]&[pat2]]
The intersection of sets specified by pat1 and pat2
[[pat1]-[pat2]]
The asymmetric difference of sets specified by pat1 and pat2
[a{ab}{ac}]
The character 'a' and the multicharacter strings "ab" and "ac"
[:Lu:]
The set of characters belonging to the given Unicode category, as defined by
Character.getType(); in this case, Unicode uppercase letters. The long form for this is
[:UppercaseLetter:]
[:L:]
The set of characters belonging to all Unicode categories starting with 'L', that is,
[[:Lu:][:Ll:][:Lt:][:Lm:][:Lo:]]
. The long form for this is
[:Letter:]
In Unicode Sets, there are two ways to quote syntax characters and whitespace:
Single Quote
Two single quotes represents a single quote, either inside or outside single quotes. Text
within single quotes is not interpreted in any way (except for two adjacent single quotes). It is
taken as literal text (special characters become non-special).
Backslash Escapes
Outside of single quotes, certain backslashed characters have special meaning:
\uhhhh
Exactly 4 hex digits; h in [0-9A-Fa-f]
\Uhhhhhhhh
Exactly 8 hex digits
\xhh
1-2 hex digits
\ooo
1-3 octal digits; o in [0-7]
\a
U+0007 (BELL)
\b
U+0008 (BACKSPACE)
\t
U+0009 (HORIZONTAL TAB)
\n
U+000A (LINE FEED)
\v
U+000B (VERTICAL TAB)
\f
U+000C (FORM FEED)
\r
U+000D (CARRIAGE RETURN)
\\
U+005C (BACKSLASH)
\N{name}
The Unicode character named "name".
Anything else following a backslash is mapped to itself, except in an environment where it is
defined to have some special meaning. For example,
\p{uppercase}
is the set of uppercase
letters in Unicode.
Any character formed as the result of a backslash escape loses any special meaning and is
treated as a literal. In particular, note that \u and \U escapes create literal characters. (In
contrast, Java treats Unicode escapes as just a way to represent arbitrary characters in an ASCII
source file, and any resulting characters are
not
tagged as literals.)
Appendix F:
Date Format Patterns
A date pattern is a string of characters, where specific strings of characters are
replaced with date and time data from a calendar when formatting or used to generate data for a
calendar when parsing. The following are the characters used in patterns to show the appropriate
formats for a given locale. The following are examples:
Pattern
Result (in a particular locale)
yyyy.MM.dd G 'at' HH:mm:ss zzz
1996.07.10 AD at 15:08:56 PDT
EEE, MMM d, ''yy
Wed, July 10, '96
h:mm a
12:08 PM
hh 'o''clock' a, zzzz
12 o'clock PM, Pacific Daylight Time
K:mm a, z
0:00 PM, PST
yyyyy.MMMM.dd GGG hh:mm aaa
01996.July.10 AD 12:08 PM
Characters may be used multiple times. For example, if y is used for the year, '
yy
might produce '99', whereas '
yyyy
' produces '1999'. For most numerical
fields, the number of characters specifies the field width. For example, if h is the hour, 'h'
might produce '5', but '
hh
' produces '05'. For some characters, the
count specifies whether an abbreviated or full form should be used, but may have other choices, as
given below.
Note: the counter-intuitive use of 5 letters for the narrow form of weekdays and months
is forced by backwards compatibility.
Date Field Symbol Table
Field
Sym.
No.
Example
Description
era
..3
AD
Era - Replaced with the Era string for the current date.
year
1..n
1996
Year.
Normally the length specifies the padding, but for two letters it also
specifies the maximum length. Example:
Year
yy
yyy
yyyy
yyyyy
AD 1
01
001
0001
00001
AD 12
12
12
012
0012
00012
AD 123
123
23
123
0123
00123
AD 1234
1234
34
1234
1234
01234
AD 12345
12345
45
12345
12345
12345
1..n
1997
Year (of "Week of Year"), used in ISO year-week calendar. May differ from calendar
year.
1..n
4601
Extended year. This is a single number designating the year of this calendar system,
encompassing all supra-year fields. For example, for the Julian calendar system, year numbers
are positive, with an era of BCE or CE. An extended year value for the Julian calendar system
assigns positive values to CE years and negative values to BCE years, with 1 BCE being year 0.
month
1..2
09
Month - Use one or two for the numerical month, three for the
abbreviation, or four for the full name, or 5 for the narrow name.
Sept
September
week
1..2
27
Week of Year.
Week of Month
day
1..2
Date - Day of the month
1..3
345
Day of year
Day of Week in Month. The example is for the 2nd Wed in July
1..n
2451334
Modified Julian day. This is different from the conventional Julian day number in two
regards. First, it demarcates days at local zone midnight, rather than noon GMT. Second, it is
a local number; that is, it depends on the local time zone. It can be thought of as a single
number that encompasses all the date-related fields.
weekday
1..2
Day of week - Use three for the short day, or four for the full name, or
5 for the narrow name. Sunday is always day 1
Tues
Tuesday
1..2
Local day of week. Same as E except numeric value will depend on the local
starting day of the week. For this example, Monday is the first day of the week.
Tues
Tuesday
period
AM
AM or PM
hour
1..2
11
Hour [1-12].
1..2
13
Hour [0-23].
1..2
Hour [0-11].
1..2
24
Hour [1-24].
minute
1..2
59
Minute. Use one or two for zero padding.
second
1..2
12
Second. Use one or two for zero padding.
1..n
3456
Fractional Second - rounds to the count of letters. (example is for 12.34567)
1..n
69540000
Milliseconds in day. This field behaves
exactly
like a composite of all
time-related fields, not including the zone fields. As such, it also reflects discontinuities
of those fields on DST transition days. On a day of DST onset, it will jump forward. On a day
of DST cessation, it will jump backward. This reflects the fact that is must be combined with
the offset field to obtain a unique local time value.
zone
PT
Timezone. Use 1 for short wall (generic) time, 2 for long wall time, 3
for the short timezone (i.e. PST) or 4 for the full name (Pacific Standard Time). If there's
no name for the zone, fallbacks may be used, depending on available data.
Pacific Time
PDT
Pacific Daylight Time
GMT-08:00
Use 1 for GMT format, 2 for RFC 822
-0800
All non-letter character represent themselves in a pattern, except for the single quote.
It is used to 'escape' letters. Two single quotes in a row, whether inside or outside a quoted
sequence, represent a 'real' single quote.
localizedPatternChars
These are characters that can be used when displaying a date pattern to an end user. This
can occur, for example, when a spreadsheet allows users to specify date patterns. Whatever is in
the string is substituted one-for-one with the characters "
GyMdkHmsSEDFwWahKzYe",
with the above meanings
. Thus, for example, if "J" is to be used instead of
"Y" to mean Year, then the string would be: "
GyMdkHmsSEDFwWahKz
e".
This element is deprecated. It is recommended instead that a more sophisticated UI be
used for localization, such as using icons to represent the different formats (and lengths) in the
Date Field Symbol Table
AM / PM
Even for countries where the customary date format only has a 24 hour format, both the am
and pm localized strings must be present and must be distinct from one another. Note that as long
as the 24 hour format is used, these strings will normally never be used, but for testing and
unusual circumstances they must be present.
Eras
There are only two values for an era in a Gregorian calendar, "BC" and "AD". These values
can be translated into other languages, like "
a.C
." and and "
d.C
."
for Spanish, but there are no other eras in the Gregorian calendar. Other calendars have a
different numbers of eras. Care should be taken when translating the era names for a specific
calendar.
Week of Year
Values calculated for the Week of Year field range from 1 to 53. Week 1 for a year is the
first week that contains at least the specified minimum number of days from that year. Weeks
between week 1 of one year and week 1 of the following year are numbered sequentially from 2 to 52
or 53 (if needed). For example, January 1, 1998 was a Thursday. If the first day of the week is
MONDAY and the minimum days in a week is 4 (these are the values reflecting ISO 8601 and many
national standards), then week 1 of 1998 starts on December 29, 1997, and ends on January 4, 1998.
However, if the first day of the week is SUNDAY, then week 1 of 1998 starts on January 4, 1998,
and ends on January 10, 1998. The first three days of 1998 are then part of week 53 of 1997.
Values are similarly calculated for the Week of Month.
Week Elements
firstDay
A number indicating which day of the week is considered the 'first' day, for calendar
purposes. Because the ordering of days may vary between calendar, keywords are used for this
value, such as sun,
mon
,... These values will be replaced by the
localized name when they are actually used.
minDays (Minimal Days in First Week)
Minimal days required in the first week of a month or year. For example, if the first
week is defined as one that contains at least one day, this value will be 1. If it must contain
a full seven days before it counts as the first week, then the value would be 7.
weekendStart, weekendEnd
Indicates the day and time that the weekend starts or ends. As with
firstDay
, keywords are used instead of numbers.
Appendix G:
Number Format Patterns
Number Patterns
The
NumberElements
resource
affects how these patterns are interpreted in a localized context. Here are some examples, based
on the French locale. The "." shows where the decimal point should go. The "," shows where the
thousands separator should go. A "0" indicates zero-padding: if the number is too short, a zero
(in the locale's numeric set) will go there. A "#" indicates no padding: if the number is too
short, nothing goes there. A "¤" shows where the currency sign will go. The following illustrates
the effects of different patterns for the French locale, with the number "1234.567". Notice how
the pattern characters ',' and '.' are replaced by the characters appropriate for the locale.
Pattern
Currency
Text
#,##0.##
n/a
1 234,57
#,##0.###
n/a
1 234,567
###0.#####
n/a
1234,567
###0.0000#
n/a
1234,5670
00000.0000
n/a
01234,5670
# ##0.00 ¤
EUR
1 234,57 €
JPY
1 235 ¥
The number of # placeholder characters before the decimal do not matter, since no limit is
placed on the maximum number of digits. There should, however, be at least one zero someplace in
the pattern. In currency formats, the number of digits after the decimal also do not matter, since
the information in the
Appendix C: Supplemental Data
is used to
override the number of decimal places — and the rounding — according to the currency that is being
formatted. That can be seen in the above chart, with the difference between Yen and Euro
formatting.
Special Pattern Characters
Many characters in a pattern are taken literally; they are matched during parsing and
output unchanged during formatting. Special characters, on the other hand, stand for other
characters, strings, or classes of characters. For example, the '#' character is replaced by a
localized digit. Often the replacement character is the same as the pattern character; in the U.S.
locale, the ',' grouping character is replaced by ','. However, the replacement is still
happening, and if the symbols are modified, the grouping character changes. Some special
characters affect the behavior of the formatter by their presence; for example, if the percent
character is seen, then the value is multiplied by 100 before being displayed.
To insert a special character in a pattern as a literal, that is, without any special
meaning, the character must be quoted. There are some exceptions to this which are noted below.
Symbol
Location
Localized?
Meaning
Number
Yes
Digit
1-9
Number
Yes
'1' through '9' indicate rounding.
Number
No
Significant digit
Number
Yes
Digit, zero shows as absent
Number
Yes
Decimal separator or monetary decimal separator
Number
Yes
Minus sign
Number
Yes
Grouping separator
Number
Yes
Separates mantissa and exponent in scientific notation.
Need not
be quoted in prefix or suffix.
Exponent
Yes
Prefix positive exponents with localized plus sign.
Need not be
quoted in prefix or suffix.
Subpattern boundary
Yes
Separates positive and negative subpatterns
Prefix or suffix
Yes
Multiply by 100 and show as percentage
(\u2030)
Prefix or suffix
Yes
Multiply by 1000 and show as per mille
¤ (\u00A4)
Prefix or suffix
No
Currency sign, replaced by currency symbol. If doubled, replaced by international
currency symbol.
If tripled, uses the long form of the decimal symbol.
If
present in a pattern, the monetary decimal separator and grouping separators
(if
available)
are used instead of the numeric ones.
Prefix or suffix
No
Used to quote special characters in a prefix or suffix, for example,
"'#'#"
formats 123 to
"#123"
To create a single quote itself, use two in a row:
"# o''clock"
Prefix or suffix boundary
Yes
Pad escape, precedes pad character
A pattern contains a
postive
and
may contain a
negative
subpattern
, for example, "#,##0.00;(#,##0.00)". Each
subpattern
has a prefix, a numeric part, and a suffix. If there is no explicit
negative
subpattern
, the negative
subpattern
is the localized minus sign prefixed to the positive
subpattern
. That
is, "0.00" alone is equivalent to "0.00;-0.00". If there is an explicit negative
subpattern
, it serves only to specify the negative prefix and suffix; the number of
digits, minimal digits, and other characteristics are ignored in the negative
subpattern
. That means that "#,##0.0#;(#)" has precisely the same result as
"#,##0.0#;(#,##0.0#)".
Note:
The thousands separator and decimal separator in this pattern are always
',' and '.'. They are substituted by the code with the correct local values according to other
fields in CLDR.
The prefixes, suffixes, and various symbols used for infinity, digits, thousands
separators, decimal separators, etc. may be set to arbitrary values, and they will appear properly
during formatting.
However, care must be taken that the symbols and strings do not
conflict, or parsing will be unreliable.
For example, either the positive and
negative prefixes or the suffixes must be distinct for any parser using this data to be able to
distinguish positive from negative values. Another example is that the decimal separator and
thousands separator should be distinct characters, or parsing will be impossible.
The
grouping separator
is a character that separates
clusters of integer digits to make large numbers more legible. It commonly used for thousands, but
in some locales it separates ten-thousands. The
grouping size
is the number of digits between the grouping separators, such as 3 for "100,000,000" or 4 for "1
0000 0000". There are actually two different grouping sizes: One used for the least significant
integer digits, the
primary grouping size
, and one used for all
others, the
secondary grouping size
. In most locales these are
the same, but sometimes they are different. For example, if the primary grouping interval is 3,
and the secondary is 2, then this corresponds to the pattern "#,##,##0", and the number 123456789
is formatted as "12,34,56,789". If a pattern contains multiple grouping separators, the interval
between the last one and the end of the integer defines the primary grouping size, and the
interval between the last two defines the secondary grouping size. All others are ignored, so
"#,##,###,####" == "###,###,####" == "##,#,###,####".
When parsing using a number format, a more lenient parse should be used where possible.
In particular, it should implement at least the following rules.
if the separator is a NO BREAK SPACE, all input white space is treated as
matching
if the separator is an apostrophe (curly or straight), all input apostrophes
are treated as matching
if the separator has a fullwidth or halfwidth equivalent, that is treated as
matching.
For consistency in the CLDR data, the following conventions should be observed so as to
have a canonical representation:
All number patterns should be minimal: there should be no leading # marks except to
specify the position of the grouping separators (e.g. avoid  ##,##0.###).
All formats should have one 0 before the decimal point (e.g. avoid #,###.##)
Decimal formats should have three hash marks in the fractional position (e.g.
#,##0.###).
Currency formats should have two zeros in the fractional position (e.g. ¤ #,##0.00).
The exact number of decimals is overridden with the decimal count in
supplementary data.
The only time two thousands separators needs to be used is when the number of
digits varies, such as for Hindi: #,##,##0.
Formatting
Formatting is guided by several parameters, all of which can be specified either using a
pattern or using the API. The following description applies to formats that do not use
scientific notation
or
significant digits
If the number of actual integer digits exceeds the
maximum integer
digits
, then only the least significant digits are shown. For example, 1997 is
formatted as "97" if the maximum integer digits is set to 2.
If the number of actual integer digits is less than the
minimum
integer digits
, then leading zeros are added. For example, 1997 is formatted
as "01997" if the minimum integer digits is set to 5.
If the number of actual fraction digits exceeds the
maximum fraction
digits
, then half-even rounding it performed to the maximum fraction digits.
For example, 0.125 is formatted as "0.12" if the maximum fraction digits is 2. This behavior can
be changed by specifying a rounding increment and a rounding mode.
If the number of actual fraction digits is less than the
minimum
fraction digits
, then trailing zeros are added. For example, 0.125 is
formatted as "0.1250" if the
mimimum
fraction digits is set to 4.
Trailing fractional zeros are not displayed if they occur
positions after the decimal, where
is less than the maximum
fraction digits. For example, 0.10004 is formatted as "0.1" if the maximum fraction digits is
four or less.
Special Values
NaN
is represented as a single character, typically
(\uFFFD)
. This character is
determined by the localized number symbols. This is the only value for which the prefixes and
suffixes are not used.
Infinity is represented as a single character, typically
(\u221E)
, with the positive or negative prefixes and
suffixes applied. The infinity character is determined by the localized number symbols.
Scientific Notation
Numbers in scientific notation are expressed as the product of a mantissa and a power of
ten, for example, 1234 can be expressed as 1.234 x 10
. The
mantissa is typically in the half-open interval [1.0, 10.0) or sometimes [0.0, 1.0), but it need
not be. In a pattern, the exponent character immediately followed by one or more digit characters
indicates scientific notation. Example: "0.###E0" formats the number 1234 as "1.234E3".
The number of digit characters after the exponent character gives the minimum exponent
digit count. There is no maximum. Negative exponents are formatted using the localized minus
sign,
not
the prefix and suffix from the pattern. This allows
patterns such as "0.###E0 m/s". To prefix positive exponents with a localized plus sign, specify
'+' between the exponent and the digits: "0.###E+0" will produce formats "1E+1", "1E+0", "1E-1",
etc. (In localized patterns, use the localized plus sign rather than '+'.)
The minimum number of integer digits is achieved by adjusting the exponent. Example:
0.00123 formatted with "00.###E0" yields "12.3E-4". This only happens if there is no maximum
number of integer digits. If there is a maximum, then the minimum number of integer digits is
fixed at one.
The maximum number of integer digits, if present, specifies the exponent grouping. The
most common use of this is to generate
engineering notation
in which the exponent is a multiple of three, e.g., "##0.###E0". The number 12345 is formatted
using "##0.####E0" as "12.345E3".
When using scientific notation, the formatter controls the digit counts using
significant digits logic. The maximum number of significant digits limits the total number of
integer and fraction digits that will be shown in the mantissa; it does not affect parsing. For
example, 12345 formatted with "##0.##E0" is "12.3E3". See the section on significant digits for
more details.
Exponential patterns may not contain grouping separators.
Significant Digits
There are two ways of controlling how many digits are shows: (a) significant digits
counts, or (b) integer and fraction digit counts. Integer and fraction digit counts are described
above. When a formatter is using significant digits counts, the number of integer and fraction
digits is not specified directly, and the formatter settings for these counts are ignored.
Instead, the formatter uses however many integer and fraction digits are required to display the
specified number of significant digits. Examples:
Pattern
Minimum significant digits
Maximum significant digits
Number
Output
@@@
12345
12300
@@@
0.12345
0.123
@@##
3.14159
3.142
@@##
1.23004
1.23
In order to enable significant digits formatting, use a pattern containing the
'@'
pattern character. In order to disable significant digits
formatting, use a pattern that does not contain the
'@'
pattern character.
Significant digit counts may be expressed using patterns that specify a minimum and
maximum number of significant digits. These are indicated by the
'@'
and
'#'
characters. The minimum number of significant
digits is the number of
'@'
characters. The maximum
number of significant digits is the number of
'@'
characters plus the number of
'#'
characters following on
the right. For example, the pattern
"@@@"
indicates
exactly 3 significant digits. The pattern
"@##"
indicates
from 1 to 3 significant digits. Trailing zero digits to the right of the decimal separator are
suppressed after the minimum number of significant digits have been shown. For example, the
pattern
"@##"
formats the number 0.1203 as
"0.12"
If a pattern uses significant digits, it may not contain a decimal separator, nor the
'0'
pattern character. Patterns such as
"@00"
or
"@.###"
are
disallowed.
Any number of
'#'
characters may be
prepended
to the left of the leftmost
'@'
character. These have no effect on the minimum and maximum significant digits counts, but may be
used to position grouping separators. For example,
"#,#@#"
indicates a minimum of one significant digits, a maximum of two significant digits, and a
grouping size of three.
The number of significant digits has no effect on parsing.
Significant digits may be used together with exponential notation. Such patterns are
equivalent to a normal exponential pattern with a minimum and maximum integer digit count of
one, a minimum fraction digit count of
Minimum Significant Digits - 1
and a maximum fraction digit count of
Maximum Significant Digits - 1
For example, the pattern
"@@###E0"
is equivalent to
"0.0###E0"
Padding
Patterns support padding the result to a specific width. In a pattern the pad escape
character, followed by a single pad character, causes padding to be parsed and formatted. The pad
escape character is '*'. For example,
"$*x#,##0.00"
formats
123 to
"$xx123.00"
, and 1234 to
"$1,234.00"
When padding is in effect, the width of the positive
subpattern
including prefix and suffix, determines the format width. For example, in the pattern
"* #0 o''clock"
, the format width is 10.
Some parameters which usually do not matter have meaning when padding is used, because
the pattern width is significant with padding. In the pattern "*
##,##,#,##0.##",
the format width is 14. The initial characters "##,##," do not affect the grouping size or
maximum integer digits, but they do affect the format width.
Padding may be inserted at one of four locations: before the prefix, after the prefix,
before the suffix, or after the suffix. No padding can be specified in any other location. If
there is no prefix, before the prefix and after the prefix are equivalent, likewise for the
suffix.
When specified in a pattern, the code point immediately following the pad escape is
the pad character. This may be any character, including a special pattern character. That is,
the pad escape
escapes
the following character. If there is
no character after the pad escape, then the pattern is illegal.
Rounding
Patterns support rounding to a specific increment. For example, 1230 rounded to the
nearest 50 is 1250. Mathematically, rounding to specific increments is performed by multiplying by
the increment, rounding to an integer, then dividing by the increment. To take a more bizarre
example, 1.234 rounded to the nearest 0.65 is 1.3, as follows:
Original:
1.234
Divide by increment (0.65):
1.89846...
Round:
Multiply by increment (0.65):
1.3
To specify a rounding increment in a pattern, include the increment in the pattern
itself. "#,#50" specifies a rounding increment of 50. "#,##0.05" specifies a rounding increment of
0.05.
Rounding only affects the string produced by formatting. It does not affect parsing or
change any numerical values.
An implementation may allow the specification of a
rounding mode
to determine how values are rounded. In the absence of such choices, the default is to round
"half-even", as described in IEEE arithmetic. That is, it rounds towards the "nearest neighbor"
unless both neighbors are equidistant, in which case, it rounds towards the even neighbor.
Behaves as for round "half-up" if the digit to the left of the discarded fraction is odd;
behaves as for round "half-down" if it's even. Note that this is the rounding mode that
minimizes cumulative error when applied repeatedly over a sequence of calculations.
Some locales use rounding in their currency formats to reflect the smallest currency
denomination.
In a pattern, digits '1' through '9' specify rounding, but otherwise behave
identically to digit '0'.
decimalFormats
The normal locale specific way to write a base 10 number.
currencyFormats
Use \u00A4 where the local currency symbol should be. Doubling the currency symbol
(\u00A4\u00A4) will output the international currency symbol (a 3-letter code).
percentFormats
Pattern for use with percentage formatting
scientificFormats
Pattern for use with scientific (exponent) formatting.
Quoting rules
Single quotes, (
), enclose bits of the pattern that
should be treated literally. Inside a quoted string, two single quotes ('') are replaced with a
single one ('). For example:
'X '
' Q '
->
X 1939 Q
(Literal strings
underlined
.)
Number Elements
Localized symbols used in number formatting and parsing.
decimal
- separates the integer and fractional part of the number.
group
- groups (for example) units of thousands: 10
= 1,000,000. The grouping
separator is commonly used for thousands, but in some countries for ten-thousands. The interval
is a constant number of digits between the grouping characters, such as 100,000,000 or
1,0000,0000. If you supply a pattern with multiple grouping characters, the interval between the
last one and the end of the integer is the one that is used. So "#,##,###,####" == "######,####"
== "##,####,####".
list
- separates lists of numbers
percentSign
- symbol used to indicate a percentage (1/100th) amount. (If present, the value is
also multiplied by 100 before formatting. That way 1.23 => 123%)
nativeZeroDigit
- Symbol used to indicate a digit in the pattern, or zero if that place would
otherwise be empty. For example, with the digit of '0', the pattern "000" would format "34" as
"034", but the pattern "0" would format "34" as just "34". As well, the digits 1-9 are expected
to follow the code point of this specified 0 value.
patternDigit
- Symbol used to indicate any digit value, typically #. When that digit is zero, then
it is not shown.
minusSign
- Symbol used to denote negative value.
plusSign
- Symbol used to denote negative value.
exponential
- Symbol separating the mantissa and exponent values.
perMille
- symbol used to indicate a per-mille (1/1000th) amount. (If present, the value is
also multiplied by 1000 before formatting. That way 1.23 => 1230 [1/000])
infinity
- The infinity sign. Corresponds to the IEEE infinity bit pattern.
nan - Not a number
- The
NaN
sign. Corresponds to the IEEE
NaN
bit pattern.
currencySeparator
This is used as the decimal separator in currency formatting/parsing, instead of the
DecimalSeparator
from the
NumberElements
list. This item is optional in the
CLDR
currencyGroup
This is used as the grouping separator in currency formatting/parsing, instead of the
DecimalSeparator
from the
NumberElements
list. This item is optional in the
CLDR
Appendix H:
Choice Patterns
A choice pattern is a string that chooses among a number of strings, based on numeric
value. It has the following form:
choice_pattern
> = ( '|' )*
=
= ('+' | '-')? (
'∞' | [0-9]+ ('.' [0-9]+)?)
= '<' | '
≤'
The interpretation of a choice pattern is that given a number N, the pattern is scanned
from right to left, for each choice evaluating N. The first choice that
matches results in the corresponding string. If no match is found, then the first string is used.
For example:
Pattern
Result
0≤Rf|1≤Ru|1∞,
-3, -1, -0.000001
Rf (defaulted to first string)
0, 0.01, 0.9999
Rf
Ru
1.00001, 5, 99,
Re
Quoting is done using ' characters, as in date or number formats.
Appendix I:
Inheritance and Validity
The following describes in more detail how to determine the exact inheritance of
elements, and the validity of a given element in
LDML
Definitions
Attributes that serve to distinguish multiple elements at the same level are called
distinguishing
attributes. These currently consist of
key
registry
alt
and
type
(except for the
type
attribute on the elements
default
and
mapping
).
Blocking
elements are those whose subelements do not inherit from parent locales.
For example, a element is a blocking element: everything in a element is
treated as a single lump of data, as far as inheritance is concerned.
Certain elements are called
attribute-information
elements. They do not have
element content; their information is carried in their attribute values. This is unlike the other
elements, whose attributes are used to distinguish different types of data.
A list of blocking and
attribute-information
elements is found in
Appendix K: Valid Attribute Values
For any element in an XML file,
an element chain
is a
resolved
XPath
leading from the root to an element, with attributes on
each element in alphabetical order. So in, say,
we may have:
ldml
version="1.1">





localeDisplayNames

Αραβικά
...
Which gives the following element chains (among others):
//
ldml[@version="1.1"]/identity/version[@number="1.1"]
//
ldml[@version="1.1"]/localeDisplayNames
/languages/language[@type="
ar"]
An element chain A is an
extension
of an element chain B
if B is equivalent to an initial portion of A. For example, #2 below is an extension of #1.
(Equivalent, depending on the tree, may not be "identical to". See below for an example.)
//
ldml[@version="1.1"]/localeDisplayNames
//
ldml[@version="1.1"]/localeDisplayNames
/languages/language[@type="
ar"]
An
LDML
file can be thought of as an ordered list of
element pairs
: , where the element chains are all the
chains for the end-nodes. (This works because of restrictions on the structure of
LDML
, including that it doesn't allow mixed content.) The ordering is the ordering
that the element chains are found in the file, and thus determined by the
DTD
For example, some of those pairs would be the following. Notice that the first has the
null string as element contents.
//
ldml[@version="1.1"]/identity/version[@number="1.1"]
""
//
ldml[@version="1.1"]/localeDisplayNames
/languages/language[@type="
ar"]
"Αραβικά"
Note:
There are two exceptions to this:
Blocking nodes and their contents are treated as a single end note.
For attribute-information elements, in terms of computing inheritance, the element
pair consists of the element chain minus the attributes in the final element and the value is
the list of attributes for that final element.
Thus instead of the element pair being (a) below, it is (b):
//ldml[@version="1.1"]/dates/calendars/calendar[@type='gregorian']/week/weekendStart[@day='sun'][@time='00:00']
"">
//ldml[@version="1.1"]/dates/calendars/calendar[@type='gregorian']/week/weekendStart
[@day='sun'][@time='00:00']
Two
LDML
element chains are
equivalent
when they would be identical if all attributes and their values were removed
except for distinguishing attributes. Thus the following are equivalent:
//
ldml[@version="1.1"]/localeDisplayNames
/languages/language[@type="
ar"]
//
ldml[@version="1.1"]/localeDisplayNames
/languages/language[@type="
ar"][@draft="true"]
For any locale ID, an
locale chain
is an ordered list
starting with the root and leading down to the ID. For example:

Resolved Data File
To produce fully resolved locale data file from CLDR for a locale ID L, you start with
L, and successively add unique
items from the
parent
locales until you
get
up to root
. More formally, this can be expressed as the following procedure.
Let Result be initially empty.
For each Li in the locale chain for L
, starting at L and going up to root:
Let Temp be a copy of the pairs in the LDML file for Li
Replace each alias in Temp by the list of pairs it points to.
For each element pair P in
Temp
If
P does not contain a blocking element, and
Result
does not
have an element pair Q with an equivalent element chain,
add P
to Result
Note: when adding an element pair to a result, it has to go in the right order for it to
be valid according to the
DTD
Valid Data
The attribute
draft='true'
in
LDML
means that the data is not known to be valid or not. However, some data that is not explicitly
marked as draft may be implicitly draft, either because it inherits it from a parent, or from an
enclosing element.
Example 2.
Suppose that a new locale is added for
af
Afrikans
). To indicate that all of the data is draft, that attribute
can be added to the top level.







Any data can be added to that file, and the status will all be draft. Once an item is
vetted --
whether it is inherited or explicitly in the file
--
then its status can be changed to non-draft. This can be done either by leaving draft="true" on
the enclosing element and marking the child with draft="false", such as:












Or it can be done by removing the draft="false" from the enclosing element, and marking
the
other
children as draft.












Note:
A missing draft attribute is
not
the same as either a true or false value. A missing attribute means instead:
inherit
the draft status from enclosing elements and parent locales.
The attribute
validSubLocales
allows sublocales in a
given tree to be treated as though a file for them were present when there isn't one. It can be
applied to any element. It only has an effect for locales that inherit from the current file where
a file is missing, and the elements wouldn't otherwise be draft.
Example 1.
Suppose that in a particular
LDML
tree, there are no region locales for German, e.g. there is a
de.xml
file, but no files for de_AT.xml
, de_CH.xml
, or de_DE.xml
Then no elements are valid for any of those region locales. If we want to mark one of those files
as having valid elements, then we introduce an empty file, such as the following.








With the
validSubLocales
attribute, instead of adding
the empty files for de_AT.xml
, de_CH.xml
, and de_DE.xml
, in
the de file we can add to the parent locale a list of the child locales that should behave as if
files were present.






...

More formally, here is how to determine whether data for an element chain E is implicitly
or explicitly draft, given a locale L. Sections 1, 2, and 4 are simply formalizations of what is
in
LDML
already. Item 3 adds the new element.
Checking for Draft Status:
Parent Locale Inheritance
Walk through the locale chain until you find a locale ID L' with a data file D. (L'
may equal L).
Produce the fully resolved data file D' for D.
In D', find the first element pair whose element chain E' is either equivalent to or
an extension of E.
If there is no such E', return
true
If E' is not equivalent to E, truncate E' to the length of E.
Enclosing Element Inheritance
Walk through the elements in E', from back to front.
If you ever encounter draft=
, return
If L' = L, return
false
Missing File Inheritance
Otherwise, walk again through the elements in E', from back to front.
If you encounter a validSubLocales attribute:
If L is in the attribute value, return
false
Otherwise return
true
Otherwise
Return
true
The
validSubLocales
in the most specific (farthest from root
file) locale file "wins" through the full resolution step (data from more specific files replacing
data from less specific ones).
Keyword and Default Resolution
When accessing data based on keywords, the following process is used. Consider the
following example:
The locale 'de' has collation types A, B, C, and no element
The locale 'de_CH' has
Here are the searches for various combinations.
1.
de_CH
not found
de
not found
root
not found: so get the default type in de_CH
de@collation=B
found
2.
de
not found
root
not found: so get the default type in de, which itself falls back to root
de@collation=standard
not found
root@collation=standard
found
3.
de@collation=A
found
4.
de@collation=standard
not found
root@collation=standard
found
Note:
It is an invariant that the default in root for a given element must
always be a value that exists in root. So you can't have the following in root:


...
...


It is not necessary, but strongly encouraged, that the default type in root be
'standard'.
For identifiers, such as language codes, script codes, region codes, variant codes,
types, keywords, currency symbols or currency display names, the default value is the identifier
itself whenever if no value is found in the root. Thus if there is no display name for the region
code 'QA' in root, then the display name is simply 'QA'.
Appendix J:
Time Zone Fallback
When a timezone is to be displayed, the following process is used. The starred items are
skipped if is present in the resolved locale data.
Canonicalize the Olson ID, mapping to one of the 407 "real" IDs.
America/Atka => America/Adak
[TBD: point to the exact data used to do this]
If there is an exact translation in the resolved locale, use it. Note that this translation
may not at all be literal, it would be what is most recognizable for people using the target
language.
America/Los_Angeles => "Tampo de Pacifica"
Else for non-wall-time, use GMT format
America/Los_Angeles => "GMT-08:00"
Else if there is an exemplar city, use it with the region format. The
exemplar city may not be the same as the Olson ID city, if another city is much more
recognizable for whatever reason. However, it is very strongly recommended that the same city be
used.
America/Los_Angeles => "Tampo de San Fransisko"
Else if there is a country for the time zone, and a translation in the locale
for the country name, and the country only has one (modern) timezone
or is in the
singleCountries list
, use it with the region format :
Africa/Monrovia => LR => "Tampo de Liberja"
Else if it is a perpetual alias for a "real" ID, and if there is an exact translation for
that, try #1..#4 with that alias.
Europe/San_Marino => Europe/Rome => ... => "Tampo de Roma"
Else fall back to the raw Olson ID (stripping off the prefix, and turning _
into space), using the fallback format.
America/Goose_Bay => "Tampo de
Goose Bay
»"
Else use the
(possibly multi-offset)
GMT format
America/Nome => "GMT-0900/-0800"
Many time zone IDs only represent differences that are important historically, but do not make
any difference in modern times. The preferenceOrdering element can be used to select the preferred
modern IDs when desired. (The choice of the interval to use when determining when two time zone
IDs are equivalent is left to the implementation.
Whenever two timezone IDs are equivalent in effect and are in the same country, the preference
ordering list is examined according to the following process:
If x, y are in the list, then the earlier one in the list is preferred.
Else if x is in the list and y isn't, then x is preferred
Else if not in root, repeat #1 and #2 using the parent locale's list
If all else fails, use a case-insensitive comparison of the timezone IDs.
For example, the following table lists the modern equivalents for Mexico on separate rows. If
the preference ordering has one element: "America/Mexico_City", then the bolded items would be
chosen as the preferred timezone IDs.
America/Merida,
America/Mexico_City,
America/Monterrey, America/Cancun
America/Chihuahua,
America/Mazatlan
America/Hermosillo
America/Tijuana
Appendix K: Valid Attribute Values
The following list provides a list of the currently valid attributes and values, for all
elements except
collation
rules
and its subelements. For currency codes, this list only includes the ISO 4217 currency codes;
however, there are other codes in common use that may occur in LDML data. A definitive list will
be provided in the future. In addition, data marked
draft
="
true
may use attribute values that are not in the following list, to allow for proposed additions, such
as new variant codes.
In the following list, the
attribute-information
elements (
alias
default
firstDay
mapping
measurementSystem
minDays
orientation
settings
weekendStart
weekendEnd
) are marked with a *. These elements carry
all of their information in attributes, and are to have empty element contents.
There
are
currently only
two
blocking
element
collation
and
identity
The
distinguishing
attributes are not marked in the table, but currently consist
of
key
registry
alt
, and
type
(except for the
type
attribute on the elements
default
and
mapping
).
Element
Attribute
Allowed Values
[any]
alt
proposed, variant, list
draft
true, false*
references

standard

(deprecated)
validSubLocales

abbreviationFallback
type
standard, GMT
alias*
path

source

calendar
type
buddhist, chinese, gregorian, hebrew, islamic, islamic-civil, japanese, arabic[alias],
civil-arabic[alias], thai-buddhist[alias], persian
collation
type
big5han, digits-after, direct, gb2312han, phonebook, pinyin,
standard
, stroke,
traditional
currency
type
ADP, AED, AFA, AFN, ALL, AMD, ANG, AOA, AOK, AON, AOR, ARA, ARP, ARS, ATS, AUD, AWG, AZM,
BAD, BAM, BBD, BDT, BEC, BEF, BEL, BGL, BGN, BHD, BIF, BMD, BND, BOB, BOP, BOV, BRB, BRC, BRE,
BRL, BRN, BRR, BSD, BTN, BUK, BWP, BYB, BYR, BZD, CAD, CDF, CHE, CHF, CHW, CLF, CLP, CNY, COP,
COU, CRC, CSD, CSK, CUP, CVE, CYP, CZK, DDM, DEM, DJF, DKK, DOP, DZD, ECS, ECV, EEK, EGP, EQE,
ERN, ESA, ESB, ESP, ETB, EUR, FIM, FJD, FKP, FRF, GBP, GEK, GEL, GHC, GIP, GMD, GNF, GNS, GQE,
GRD, GTQ, GWE, GWP, GYD, HKD, HNL, HRD, HRK, HTG, HUF, IDR, IEP, ILP, ILS, INR, IQD, IRR, ISK,
ITL, JMD, JOD, JPY, KES, KGS, KHR, KMF, KPW, KRW, KWD, KYD, KZT, LAK, LBP, LKR, LRD, LSL, LSM,
LTL, LTT, LUC, LUF, LUL, LVL, LVR, LYD, MAD, MAF, MDL, MGA, MGF, MKD, MLF, MMK, MNT, MOP, MRO,
MTL, MTP, MUR, MVR, MWK, MXN, MXP, MXV, MYR, MZE, MZM, NAD, NGN, NIC, NIO, NLG, NOK, NPR, NZD,
OMR, PAB, PEI, PEN, PES, PGK, PHP, PKR, PLN, PLZ, PTE, PYG, QAR, RHD, ROL, RUB, RUR, RWF, SAR,
SBD, SCR, SDD, SDP, SEK, SGD, SHP, SIT, SKK, SLL, SOS, SRD, SRG, STD, SUR, SVC, SYP, SZL, THB,
TJR, TJS, TMM, TND, TOP, TPE, TRL, TRY, TTD, TWD, TZS, UAH, UAK, UGS, UGX, USD, USN, USS, UYP,
UYU, UZS, VEB, VND, VUV, WST, XAF, XAG, XAU, XBA, XBB, XBC, XBD, XCD, XDR, XEU, XFO, XFU, XOF,
XPD, XPF, XPT, XRE, XTS, XXX, YDD, YER, YUD, YUM, YUN, ZAL, ZAR, ZMK, ZRN, ZRZ, ZWD, use>
currencyFormat
type
standard
,
currencyFormatLength
type
full, long, medium, short
dateFormat
type
standard
,
dateFormatLength
type
full, long, medium, short
dateTimeFormat
type
standard
,
dateTimeFormatLength
type
full
day
type
sun, mon, tue, wed, thu, fri, sat
dayContext
type
format, stand-alone
dayWidth
type
abbreviated, narrow, wide
decimalFormat
type
standard
,
decimalFormatLength
type
full, long, medium, short
default*
type

era
type

exemplarCharacters
type
standard
, auxiliary
field
type
era, year, month, week, day, weekday, dayperiod, hour, minute, second, zone
firstDay*
day
sun, mon, tue, wed, thu, fri, sat
generation
date

inList
casing
titlecase-words, titlecase-firstword
key
type

language
type
aa, ab, ace, ach, ada, ady, ae, af, afa, afh, ak, akk, ale, alg, alt, am, an, ang, apa, ar,
arc, arn, arp, art, arw, as, ast, ath, aus, av, awa, ay, az, ba, bad, bai, bal, ban, bas, bat,
be, bej, bem, ber, bg, bh, bho, bi, bik, bin, bla, bm, bn, bnt, bo, br, bra, bs, btk, bua,
bug, byn, ca, cad, cai, car, cau, ce, ceb, cel, ch, chb, chg, chk, chm, chn, cho, chp, chr,
chy, cmc, co, cop, cpe, cpf, cpp, cr, crh, crp, cs, csb, cu, cus, cv, cy, da, dak, dar, day,
de, del, den, dgr, din, doi, dra, dsb, dua, dum, dv, dyu, dz, ee, efi, egy, eka, el, elx, en,
enm, eo, es, et, eu, ewo, fa, fan, fat, ff, fi, fil, fiu, fj, fo, fon, fr, frm, fro, fur, fy,
ga, gaa, gay, gba, gd, gem, gez, gil, gl, gmh, gn, goh, gon, gor, got, grb, grc, gu, gv, gwi,
ha, hai, haw, he, hi, hil, him, hit, hmn, ho, hr, hsb, ht, hu, hup, hy, hz, ia, iba, id, ie,
ig, ii, ijo, ik, ilo, inc, ine, inh, io, ira, iro, is, it, iu, ja, jbo, jpr, jrb, jv, ka, kaa,
kab, kac, kam, kar, kaw, kbd, kg, kha, khi, kho, ki, kj, kk, kl, km, kmb, kn, ko, kok, kos,
kpe, kr, krc, kro, kru, ks, ku, kum, kut, kv, kw, ky, la, lad, lah, lam, lb, lez, lg, li, ln,
lo, lol, loz, lt, lu, lua, lui, lun, luo, lus, lv, mad, mag, mai, mak, man, map, mas, mdf, mdr,
men, mg, mga, mh, mi, mic, min, mis, mk, mkh, ml, mn, mnc, mni, mno, mo, moh, mos, mr, ms, mt,
mul, mun, mus, mwl, mwr, my, myn, myv, na, nah, nai, nap, nb, nd, nds, ne, new, ng, nia, nic,
niu, nl, nn, no, nog, non, nr, nso, nub, nv, nwc, ny, nym, nyn, nyo, nzi, oc, oj, om, or, os,
osa, ota, oto, pa, paa, pag, pal, pam, pap, pau, peo, phi, phn, pi, pl, pon, pra, pro, ps, pt,
qu, raj, rap, rar, rm, rn, ro, roa, rom, root, ru, rw, sa, sad, sah, sai, sal, sam, sas, sat,
sc, scn, sco, sd, se, sel, sem, sg, sga, sgn, sh, shn, si, sid, sio, sit, sk, sl, sla, sm, sma,
smi, smj, smn, sms, sn, snk, so, sog, son, sq, sr, srn, srr, ss, ssa, st, su, suk, sus, sux,
sv, sw, syr, ta, tai, te, tem, ter, tet, tg, th, ti, tig, tiv, tk, tkl, tl, tlh, tli, tmh, tn,
to, tog, tpi, tr, ts, tsi, tt, tum, tup, tut, tvl, tw, ty, tyv, udm, ug, uga, uk, umb, und, ur,
uz, vai, ve, vi, vo, vot, wa, wak, wal, war, was, wen, wo, xal, xh, yao, yap, yi, yo, ypk, za,
zap, zen, zh, znd, zu, zun,
ldml
version
1.0, 1.1, 1.2, 1.3
mapping*
registry

type

measurementSystem*
type
metric, US, UK
minDays*
count
1, 2, 3, 4, 5, 6, 7
month
type
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
monthContext
type
format, stand-alone
monthWidth
type
abbreviated, narrow, wide
orientation*
characters
left-to-right
, right-to-left, top-to-bottom, bottom-to-top
lines
left-to-right, right-to-left,
top-to-bottom
, bottom-to-top
pattern
type
standard
,
percentFormat
type
standard
,
percentFormatLength
type
full, long, medium, short
preferenceOrdering
type

reference
type

uri

relative
type

reset
before
primary, secondary, tertiary
scientificFormat
type
standard
,
scientificFormatLength
type
full, long, medium, short
script
type
Arab, Armn, Bali, Batk, Beng, Blis, Bopo, Brah, Brai, Bugi, Buhd, Cans, Cham, Cher, Cirt,
Copt, Cprt, Cyrl, Cyrs, Deva, Dsrt, Egyd, Egyh, Egyp, Ethi, Geok, Geor, Glag, Goth, Grek, Gujr,
Guru, Hang, Hani, Hano, Hans, Hant, Hebr, Hira, Hmng, Hrkt, Hung, Inds, Ital, Java, Kali,
Kana, Khar, Khmr, Knda, Laoo, Latf, Latg, Latn, Lepc, Limb, Lina, Linb, Mand, Maya, Mero, Mlym,
Mong, Mymr, Nkoo, Ogam, Orkh, Orya, Osma, Perm, Phag, Phnx, Plrd, Qaai, Roro, Runr, Sara,
Shaw, Sinh, Sylo, Syrc, Syre, Syrj, Syrn, Tagb, Tale, Talu, Taml, Telu, Teng, Tfng, Tglg, Thaa,
Thai, Tibt, Ugar, Vaii, Visp, Xpeo, Xsux, Yiii, Zxxx, Zyyy, Zzzz,
settings*
alternate
non-ignorable, shifted
backwards
on, off
caseFirst
upper, lower, off
caseLevel
on, off
hiraganaQuarternary
on, off
normalization
on, off
numeric
on, off
strength
primary, secondary, tertiary, quaternary, identical
singleCountries
list

territory
type
001, 002, 003, 005, 009, 011, 013, 014, 015, 017, 018, 019, 021, 029, 030, 035, 039, 053,
054, 057, 061, 062, 142, 145, 150, 151, 154, 155, 172, 200, 419, 830, 833, AD, AE, AF, AG, AI,
AL, AM, AN, AO, AQ, AR, AS, AT, AU, AW, AX, AZ, BA, BB, BD, BE, BF, BG, BH, BI, BJ, BM, BN,
BO, BQ, BR, BS, BT, BV, BW, BY, BZ, CA, CC, CD, CF, CG, CH, CI, CK, CL, CM, CN, CO, CR, CS,
CT, CU, CV, CX, CY, CZ, DD, DE, DJ, DK, DM, DO, DZ, EC, EE, EG, EH, ER, ES, ET, FI, FJ, FK,
FM, FO, FQ, FR, FX, GA, GB, GD, GE, GF, GH, GI, GL, GM, GN, GP, GQ, GR, GS, GT, GU, GW, GY,
HK, HM, HN, HR, HT, HU, ID, IE, IL, IN, IO, IQ, IR, IS, IT, JM, JO, JP, JT, KE, KG, KH, KI,
KM, KN, KP, KR, KW, KY, KZ, LA, LB, LC, LI, LK, LR, LS, LT, LU, LV, LY, MA, MC, MD, MG, MH,
MI, MK, ML, MM, MN, MO, MP, MQ, MR, MS, MT, MU, MV, MW, MX, MY, MZ, NA, NC, NE, NF, NG, NI,
NL, NO, NP, NQ, NR, NT, NU, NZ, OM, PA, PC, PE, PF, PG, PH, PK, PL, PM, PN, PR, PS, PT, PU, PW,
PY, PZ, QA, QO, RE, RO, RU, RW, SA, SB, SC, SD, SE, SG, SH, SI, SJ, SK, SL, SM, SN, SO, SR,
ST, SU, SV, SY, SZ, TC, TD, TF, TG, TH, TJ, TK, TL, TM, TN, TO, TR, TT, TV, TW, TZ, UA, UG,
UM, US, UY, UZ, VA, VC, VD, VE, VG, VI, VN, VU, WF, WK, WS, YD, YE, YT, YU, ZA, ZM, ZW,

timeFormat
type
standard
,
timeFormatLength
type
full, long, medium, short
type
key

type

variant
type
1901, 1996, POLYTONI, POSIX, REVISED, SAAHO, boont, gaulish, guoyu, hakka, lojban, nedis,
rozaj, scouse, xiang
version
number

weekendEnd*
day
sun, mon, tue, wed, thu, fri, sat
time
24:00
)>
weekendStart*
day
sun, mon, tue, wed, thu, fri, sat
time
00:00
..24:00)>
zone
type
Africa/Abidjan, Africa/Accra, Africa/Addis_Ababa, Africa/Algiers, Africa/Asmera,
Africa/Bamako, Africa/Bangui, Africa/Banjul, Africa/Bissau, Africa/Blantyre,
Africa/Brazzaville, Africa/Bujumbura, Africa/Cairo, Africa/Casablanca, Africa/Ceuta,
Africa/Conakry, Africa/Dakar, Africa/Dar_es_Salaam, Africa/Djibouti, Africa/Douala, Africa/El_Aaiun,
Africa/Freetown, Africa/Gaborone, Africa/Harare, Africa/Johannesburg, Africa/Kampala,
Africa/Khartoum, Africa/Kigali, Africa/Kinshasa, Africa/Lagos, Africa/Libreville, Africa/Lome,
Africa/Luanda, Africa/Lubumbashi, Africa/Lusaka, Africa/Malabo, Africa/Maputo, Africa/Maseru,
Africa/Mbabane, Africa/Mogadishu, Africa/Monrovia, Africa/Nairobi, Africa/Ndjamena,
Africa/Niamey, Africa/Nouakchott, Africa/Ouagadougou, Africa/Porto-Novo, Africa/Sao_Tome,
Africa/Timbuktu, Africa/Tripoli, Africa/Tunis, Africa/Windhoek, America/Adak,
America/Anchorage, America/Anguilla, America/Antigua, America/Araguaina, America/Aruba,
America/Asuncion, America/Barbados, America/Belem, America/Belize, America/Boa_Vista, America/Bogota,
America/Boise, America/Buenos_Aires, America/Cambridge_Bay, America/Cancun, America/Caracas,
America/Catamarca, America/Cayenne, America/Cayman, America/Chicago, America/Chihuahua,
America/Cordoba, America/Costa_Rica, America/Cuiaba, America/Curacao, America/Danmarkshavn,
America/Dawson, America/Dawson_Creek, America/Denver, America/Detroit, America/Dominica,
America/Edmonton, America/Eirunepe, America/El_Salvador, America/Fortaleza, America/Glace_Bay,
America/Godthab, America/Goose_Bay, America/Grand_Turk, America/Grenada, America/Guadeloupe,
America/Guatemala, America/Guayaquil, America/Guyana, America/Halifax, America/Havana,
America/Hermosillo, America/Indiana/Knox, America/Indiana/Marengo, America/Indiana/Vevay,
America/Indianapolis, America/Inuvik, America/Iqaluit, America/Jamaica, America/Jujuy,
America/Juneau, America/Kentucky/Monticello, America/La_Paz, America/Lima, America/Los_Angeles,
America/Louisville, America/Maceio, America/Managua, America/Manaus, America/Martinique,
America/Mazatlan, America/Mendoza, America/Menominee, America/Merida, America/Mexico_City,
America/Miquelon, America/Monterrey, America/Montevideo, America/Montreal, America/Montserrat,
America/Nassau, America/New_York, America/Nipigon, America/Nome, America/Noronha, America/North_Dakota/Center,
America/Panama, America/Pangnirtung, America/Paramaribo, America/Phoenix,
America/Port-au-Prince, America/Port_of_Spain, America/Porto_Velho, America/Puerto_Rico,
America/Rainy_River, America/Rankin_Inlet, America/Recife, America/Regina, America/Rio_Branco,
America/Santiago, America/Santo_Domingo, America/Sao_Paulo, America/Scoresbysund, America/St_Johns,
America/St_Kitts, America/St_Lucia, America/St_Thomas, America/St_Vincent, America/Swift_Current,
America/Tegucigalpa, America/Thule, America/Thunder_Bay, America/Tijuana, America/Tortola,
America/Vancouver, America/Whitehorse, America/Winnipeg, America/Yakutat, America/Yellowknife,
Antarctica/Casey, Antarctica/Davis, Antarctica/DumontDUrville, Antarctica/Mawson, Antarctica/McMurdo,
Antarctica/Palmer, Antarctica/Rothera, Antarctica/Syowa, Antarctica/Vostok, Asia/Aden, Asia/Almaty,
Asia/Amman, Asia/Anadyr, Asia/Aqtau, Asia/Aqtobe, Asia/Ashgabat, Asia/Baghdad, Asia/Bahrain,
Asia/Baku, Asia/Bangkok, Asia/Beirut, Asia/Bishkek, Asia/Brunei, Asia/Calcutta, Asia/Choibalsan,
Asia/Chongqing, Asia/Colombo, Asia/Damascus, Asia/Dhaka, Asia/Dili, Asia/Dubai, Asia/Dushanbe,
Asia/Gaza, Asia/Harbin, Asia/Hong_Kong, Asia/Hovd, Asia/Irkutsk, Asia/Jakarta, Asia/Jayapura,
Asia/Jerusalem, Asia/Kabul, Asia/Kamchatka, Asia/Karachi, Asia/Kashgar, Asia/Katmandu,
Asia/Krasnoyarsk, Asia/Kuala_Lumpur, Asia/Kuching, Asia/Kuwait, Asia/Macau, Asia/Magadan,
Asia/Makassar, Asia/Manila, Asia/Muscat, Asia/Nicosia, Asia/Novosibirsk, Asia/Omsk, Asia/Oral,
Asia/Phnom_Penh, Asia/Pontianak, Asia/Pyongyang, Asia/Qatar, Asia/Qyzylorda, Asia/Rangoon,
Asia/Riyadh, Asia/Saigon, Asia/Sakhalin, Asia/Samarkand, Asia/Seoul, Asia/Shanghai,
Asia/Singapore, Asia/Taipei, Asia/Tashkent, Asia/Tbilisi, Asia/Tehran, Asia/Thimphu,
Asia/Tokyo, Asia/Ulaanbaatar, Asia/Urumqi, Asia/Vientiane, Asia/Vladivostok, Asia/Yakutsk,
Asia/Yekaterinburg, Asia/Yerevan, Atlantic/Azores, Atlantic/Bermuda, Atlantic/Canary,
Atlantic/Cape_Verde, Atlantic/Faeroe, Atlantic/Jan_Mayen, Atlantic/Madeira,
Atlantic/Reykjavik, Atlantic/South_Georgia, Atlantic/St_Helena, Atlantic/Stanley,
Australia/Adelaide, Australia/Brisbane, Australia/Broken_Hill, Australia/Darwin,
Australia/Hobart, Australia/Lindeman, Australia/Lord_Howe, Australia/Melbourne,
Australia/Perth, Australia/Sydney, Etc/GMT, Etc/GMT+1, Etc/GMT+10, Etc/GMT+11, Etc/GMT+12,
Etc/GMT+2, Etc/GMT+3, Etc/GMT+4, Etc/GMT+5, Etc/GMT+6, Etc/GMT+7, Etc/GMT+8, Etc/GMT+9,
Etc/GMT-1, Etc/GMT-10, Etc/GMT-11, Etc/GMT-12, Etc/GMT-13, Etc/GMT-14, Etc/GMT-2, Etc/GMT-3,
Etc/GMT-4, Etc/GMT-5, Etc/GMT-6, Etc/GMT-7, Etc/GMT-8, Etc/GMT-9, Etc/UCT, Etc/UTC,
Europe/Amsterdam, Europe/Andorra, Europe/Athens, Europe/Belfast, Europe/Belgrade,
Europe/Berlin, Europe/Bratislava, Europe/Brussels, Europe/Bucharest, Europe/Budapest,
Europe/Chisinau, Europe/Copenhagen, Europe/Dublin, Europe/Gibraltar, Europe/Helsinki,
Europe/Istanbul, Europe/Kaliningrad, Europe/Kiev, Europe/Lisbon, Europe/Ljubljana,
Europe/London, Europe/Luxembourg, Europe/Madrid, Europe/Malta, Europe/Minsk, Europe/Monaco,
Europe/Moscow, Europe/Oslo, Europe/Paris, Europe/Prague, Europe/Riga, Europe/Rome,
Europe/Samara, Europe/San_Marino, Europe/Sarajevo, Europe/Simferopol, Europe/Skopje,
Europe/Sofia, Europe/Stockholm, Europe/Tallinn, Europe/Tirane, Europe/Uzhgorod, Europe/Vaduz,
Europe/Vatican, Europe/Vienna, Europe/Vilnius, Europe/Warsaw, Europe/Zagreb, Europe/Zaporozhye,
Europe/Zurich, Indian/Antananarivo, Indian/Chagos, Indian/Christmas, Indian/Cocos,
Indian/Comoro, Indian/Kerguelen, Indian/Mahe, Indian/Maldives, Indian/Mauritius, Indian/Mayotte,
Indian/Reunion, Pacific/Apia, Pacific/Auckland, Pacific/Chatham, Pacific/Easter, Pacific/Efate,
Pacific/Enderbury, Pacific/Fakaofo, Pacific/Fiji, Pacific/Funafuti, Pacific/Galapagos,
Pacific/Gambier, Pacific/Guadalcanal, Pacific/Guam, Pacific/Honolulu, Pacific/Johnston,
Pacific/Kiritimati, Pacific/Kosrae, Pacific/Kwajalein, Pacific/Majuro, Pacific/Marquesas,
Pacific/Midway, Pacific/Nauru, Pacific/Niue, Pacific/Norfolk, Pacific/Noumea, Pacific/Pago_Pago,
Pacific/Palau, Pacific/Pitcairn, Pacific/Ponape, Pacific/Port_Moresby, Pacific/Rarotonga,
Pacific/Saipan, Pacific/Tahiti, Pacific/Tarawa, Pacific/Tongatapu, Pacific/Truk, Pacific/Wake,
Pacific/Wallis, Pacific/Yap
Appendix L:
Canonical Form
The following are restrictions on the format of LDML files to allow for easier parsing
and comparison of files.
Peer elements have consistent order. That is, if the DTD or this specification requires the
following order in an element foo:




It can never require the reverse order in a different element bar.




Note that there was one case that had to be corrected in order to make this true. For
that reason, pattern occurs twice under currency:
decimal?, group?, special*)) >
XML
files can have a wide variation in
textual form, while representing precisely the same data. By putting the LDML files in the
repository into a canonical form, this allows us to use the simple diff tools used widely (and in
CVS) to detect differences when vetting changes, without those tools being confused. This is not a
requirement on other uses of LDML; just simply a way to manage repository data more easily.
Content
All start elements are on their own line, indented by
depth
tabs.
All end elements (except for leaf nodes) are on their own line, indented by
depth
tabs.
Any leaf node with empty content is in the form .
There are no blank lines except within comments or content.
Spaces are used within a start element. There are no extra spaces within elements.

, not


, not

All attribute values use double quote ("), not single (').
There are no CDATA sections, and no escapes except those absolutely required.
no ' since it is not necessary
no 'a', it would be just 'a'
All attributes with defaulted values are suppressed. See the
Defaulted Attributes Table
The draft and alt="proposed.*" attributes are only on leaf elements.
The tzid are canonicalized in the following way:
All tzids as of as CLDR 1.1 (2004.06.08) in zone.tab are canonical.
After that point, the first time a tzid is introduced, that is the canonical form.
That is, new IDs are added, but existing ones keep the original form. The Olson
timezone database keeps a set of equivalences in the "backward" file. These are used to map
other tzids to the canonical form. For example, when
America/Argentina/Catamarca
was introduced as the new name for the previous
America/Catamarca
, a link was added
in the backward file.
Link America/Argentina/Catamarca America/Catamarca
Example:











¤#,##0.00;(¤#,##0.00)





Ordering
Element names are ordered by the
Element Order Table
Attribute names are ordered by the
Attribute Order Table
Attribute value comparison is a bit more complicated, and may depend on the attribute
and type. Compare two values by using the following steps:
If two values are in the
Value Order Table
, compare according to the order in the table. Otherwise if just one is,
it goes first.
If two values are numeric [0-9], compare numerically (2 < 12). Otherwise if just one
is numeric, it goes first.
Otherwise values are ordered alphabetically
An attribute-value pair is ordered first by attribute name, and then if the attribute
names are identical, by the value.
An element is ordered first by the element name, and then if the element names are
identical, by the sorted set of attribute-value pairs (sorted by #4). For the latter, compare
the first pair in each (in sorted order by attribute pair). If not identical, go to the second
pair, etc.
Any future additions to the DTD must be structured so as to allow compatibility with
this ordering.
See also Appendix K:
Valid Attribute Values
Comments
Comments are of the form .
They are logically attached to a node. There are 4 kinds:
Inline always appear after a leaf node, on the same line at the end. These are a
single line.
Preblock comments always precede the attachment node, and are indented on the same
level.
Postblock comments always follow the attachment node, and are indented on the same
level.
Final comment, after
Multiline comments (except the final comment) have each line after the first indented
to one deeper level.
Examples:

BC
...



...


Canonicalization
The process of canonicalization is fairly straightforward, except for comments. Inline
comments will have any linebreaks replaced by a space. There may be cases where the attachment
node is not permitted, such as the following.




In those cases, the comment will be made into a block comment on the last previous leaf
node, if it is at that level or deeper. (If there is one already, it will be appended, with a
line-break between.) If there is no place to attach the node (for example, as a result of
processing that removes the attachment node), the comment and its node's xpath will be appended to
the final comment in the document.
Multiline comments will have leading tabs stripped, so any indentation should be done
with spaces.
Element Order Table
The organization into bullets is purely for clarity; the ordering is established by which
comes first in the overall list. Note that most combinations of pairs of items will never be peer
elements, and thus never be compared.
ldml, identity, alias, localeDisplayNames, layout, characters, delimiters,
measurement, dates, numbers, collations, posix,
version, generation, language, script, territory, variant,
languages, scripts, territories, variants, keys, types,
key, type,
orientation, exemplarCharacters, mapping, cp,
quotationStart, quotationEnd, alternateQuotationStart, alternateQuotationEnd,
measurementSystem, paperSize, height, width,
localizedPatternChars, calendars, timeZoneNames,
months, monthNames, monthAbbr, days, dayNames, dayAbbr, week, am, pm, eras,
dateFormats, timeFormats, dateTimeFormats, fields, month, day, minDays, firstDay, weekendStart,
weekendEnd, eraNames, eraAbbr, era, pattern, displayName, hourFormat, hoursFormat, gmtFormat,
regionFormat, fallbackFormat, abbreviationFallback, preferenceOrdering, default, calendar,
monthContext, monthWidth, dayContext, dayWidth, dateFormatLength, dateFormat, timeFormatLength,
timeFormat, dateTimeFormatLength, dateTimeFormat, zone, long, short, exemplarCity, generic,
standard, daylight, field, relative,
symbols, decimalFormats, scientificFormats, percentFormats, currencyFormats,
currencies,
decimalFormatLength, decimalFormat, scientificFormatLength, scientificFormat,
percentFormatLength, percentFormat, currencyFormatLength, currencyFormat, currency, symbol,
decimal, group, list, percentSign, nativeZeroDigit, patternDigit, plusSign, minusSign,
exponential, perMille, infinity, nan,
collation,
messages, yesstr, nostr, yesexpr, noexpr,
special
(always last)
Attribute Order Table
The organization into bullets is purely for clarity; the ordering is established by which
comes first in the overall list. Note that most combinations of pairs of items will never be peer
elements, and thus never be compared.
type, key, registry, alt
(distinguishing types)
source, path,
day, date,
version, count,
lines, characters,
before,
number, time,
validSubLocales, standard, references,
draft
Value Order Table
weekendStart
day
sun, mon, tue, wed, thu, fri, sat
weekendEnd
day
type
dateFormatLength
full, long, medium, short
timeFormatLength
dateTimeFormatLength
decimalFormatLength
scientificFormatLength
percentFormatLength
currencyFormatLength
monthWidth
wide, abbreviated, narrow
dayWidth
field
era, year, month, week, day, weekday, dayperiod, hour, minute, second, zone
zone
The order for prefixes are:
America, Atlantic, Europe, Africa, Asia,
Indian, Australia, Pacific, Arctic, Antarctica, Etc.
Within the same prefix, sort first
by longitude, then latitude (both given by the zone.tab file in the Olson database), then by
full tzid.
numeric order
alphabetic order
Defaulted Values Table
ldml
version
"1.2"
orientation
characters
"left-to-right"
lines
"top-to-bottom"
weekendStart
time
"00:00"
weekendEnd
"24:00"
dateFormat
type
"standard"
timeFormat
dateTimeFormat
decimalFormat
scientificFormat
percentFormat
currencyFormat
pattern
currency
collation
References
Ancillary Information
To properly localize, parse, and format data requires
ancillary information, which is not expressed in Locale Data Markup Language. Some of the
formats for values used in Locale Data Markup Language are constructed according to external
specifications. The sources for this data and/or formats include the following:
Charts
The online code charts can be found at
An index to characters
names with links to the corresponding chart is found at
DUCET
The Default Unicode Collation Element Table (DUCET)
For the base-level collation, of which all the collation tables in this document are
tailorings.
FAQ
Unicode Frequently Asked Questions
For answers to common questions on technical issues.
FCD
As defined in UTN #5 Canonical Equivalences in Applications
Feedback
Reporting Errors and Requesting Information Online
Glossary
Unicode Glossary
For explanations of terminology used in this and other documents.
JavaChoice
Java ChoiceFormat
Olson
The Olson Data, aka TZID database
Timezone and daylight savings information.
ftp://elsie.nci.nih.gov/pub/
For archived data,
see
ftp://munnari.oz.au/pub/oldtz/
For general information, see
Reports
Unicode Technical Reports
For information on the status and development process for technical reports, and for a
list of technical reports.
UCA
UTS #10: Unicode Collation Algorithm
UCD
The Unicode Character Database (UCD)
For character properties, casing behavior, default line-, word-, cluster-breaking behavior,
etc.
Unicode
The Unicode Consortium.
The Unicode Standard, Version 4.0
. Reading,
MA, Addison-Wesley, 2003. 0-321-18578-1.
Versions
Versions of the Unicode Standard
For information on version numbering, and citing and referencing the Unicode Standard,
the Unicode Character Database, and Unicode Technical Reports.
Other Standards
Various standards define codes that are used as keys or
values in Locale Data Markup Language. These include:
ISO639
ISO Language Codes
Actual List:
ISO3166
ISO Region Codes
Actual List
ISO4217
ISO Currency Codes
(Note that as of this point, there are significant problems with this list.)
ISO15924
ISO Script Codes
Older version with Actual List:
RFC3066
IETF Language Codes
Registered Exception List (those not of the form language + region)
RFC3066bis
(latest registry draft)
UNM49
UN M.49: UN Statistics Division
Country or area & region
codes
Composition of macro geographical (continental) regions, geographical sub-regions, and
selected economic and other groupings
General
The following are general references from the text:
BIDI
UAX #9: The Bidirectional Algorithm
Calendars
Calendrical Calculations: The Millennium Edition by Edward M.
Reingold, Nachum Dershowitz; Cambridge University Press; Book and CD-ROM edition (July 1,
2001); ISBN: 0521777526.
Note that the algorithms given in this book are copyrighted.
CharMapML
UTR #22: Character Mapping Tables
Comparisons
Comparisons between locale data from different sources
CurrencyInfo
Currency Names
UNECE Currency Data
DataFormats
CLDR Data Formats
Example
A sample in Locale Data Markup Language
ICUCollation
ICU rule syntax:
ICUTransforms
Transforms
Transforms Demo
ICUUnicodeSet
ICU UnicodeSet
API:
LocaleExplorer
ICU Locale Explorer
LocaleProject
Common Locale Data Repository Project
NamingGuideline
OpenI18N Locale Naming Guideline
RBNF
Rule-Based Number Format
RBBI
Rule-Based Break Iterator
Scripts
UAX #24: Script Names
UCAChart
Collation Chart
URegex
UTR #18: Unicode Regular Expression Guidelines
UTS #18: Unicode Regular Expressions (Proposed Update)
UTCInfo
NIST Time and Frequency Division Home Page
U.S. Naval Observatory: What is Universal Time?
WindowsCulture
Windows Culture Info (with  mappings from [
RFC3066
]-style
codes to LCIDs)
Acknowledgments
Thanks to the following people for their contributions to LDML and/or CLDR:
Mati Allouche (מתתיהו  אלוש),
Tarek Abou Aly (
طارق أبو على
),
Patrick Andries,
Shu Bei (舒蓓),
Philips Benjamin,
Ernest v.d. Boogaard,
Avery Chan,
Alexis Cheng,
Séamus Ó Ciardhuáin,
Helena Shih Chapman,
Irina Chausova,
Lee Collins,
Angelo Dalli,
Simon Dean,
Jeno Demeczky,
Sivaraj Doddannan,
John Emmons,
Eva Albertsdotter Enblom,
Behdad Esfahbod (بهداد اسفهبد)
Michael Everson,
Doug Ewell,
Doug Felt,
Tom Garland,
Yun Fang Ge (葛云芳),
Deborah Goldsmith,
Hélène Guillerme,
Mine Halici,
Chris Hansten,
Yannis Haralambous (Γιάννης Χαραλάμπους),
Andy Heninger,
Hideki Hiura,
Jarkko Hietaniemi,
Denis Jacquerye,
Alexander Kachur (Александр Качур),
Kent Karlsson,
Walter Keutgen,
Akio Kido,
Yuri Kirghisov,
Erkki Kolehmainen,
Troy Korjuslommi,
Rici Lake,
Antoine Leca,
Peter Linsley,
Alan Liu,
Steven R Loomis,
Eric Mader,
Sasha Maric (Саша Марић),
Eric Muller,
Kentaroh Noji (野地　健太郎),
Peter Nugent,
Sandra O'Donnell,
Roozbeh Pournader (روزبه پورنادر),
Charles Pau,
Åke Persson,
Eike Rathke,
Vytautas Rekus,
George Rhoten,
Jonathan Rosenne (יונתן רוזן),
Markus Scherer,
Dale Schultz,
Javier Sola,
Baldev Soor,
Michael Twomey,
Dick Veerhar,
Philippe Verdy,
Ram Viswanadha (రఘురామ్ విశ్వనాధ),
Vladimir Weinstein
(Владимир Вајнштајн),
Jarosław Włodarczyk,
Daniel Yacob
Special thanks to the following people for their continuing overall contributions to the CLDR
project, and for their specific contributions in the following areas: John Emmons for the POSIX
conversion tool; Deborah Goldsmith for her contributions to LDML architecture; Chris Hansten for
coordinating and managing data submissions and vetting; Erkki Kolehmainen and his team for their
work on Finnish; Steven Loomis for development of the survey tool; Peter Nugent for his
contributions to the POSIX tool and from Open Office, and for coordinating and managing data
submissions and vetting. George Rhoten for his work on currencies; Roozbeh Pournader for his work
on South Asian countries; Ram Viswanadha for all of his work on LDML tools and data integration,
and for coordinating and managing data submissions and vetting; Vladimir Weinstein for his work on
collation.
Modifications
The following summarizes modifications from the previous revision of this document.
The canonical form for variants is uppercase
Addition of UN M.49 codes
Addition of persian and coptic calendar IDs
Clarification of alias inheritance
New XML references section
Modified revision and generation field format
Use of language display names for whole initial segments of locale IDs names, such as nl-BE
Addition of the inList element
Clarification of 'narrow'
Additional dateTimeFormat description
Names of calendar fields, and relative times.
New element currencySpacing
Descriptions of POSIX yes/now
New supplemental data elements/attributes (end of Appendix C)
currency to/from
languageData
timezoneData
territoryContainment
mapTimezones
alias
deprecated
characters
in dateExtension of era to 1..3
Clarification of year padding
Deprecation of localizedPatternChars
Use of the singleCountries list
Appendix L: canonical form
Misc editing
Revision 1
(2005-06-30): added link to Corrigenda.
Copyright © 2001-2005 Unicode, Inc. All Rights Reserved. The Unicode
Consortium makes no expressed or implied warranty of any kind, and assumes no liability for errors
or omissions. No liability is assumed for incidental and consequential damages in connection with
or arising out of the use of the information or programs contained or accompanying this technical
report. The Unicode
apply.
Unicode and the Unicode logo are trademarks of Unicode, Inc., and are
registered in some jurisdictions.