Google Git
Sign in
android / platform / external / cldr / cldr-release-34 / . / specs / ldml / tr35.html
blob: 1dd7029c19aff0c8508a6a04bdfddecf7b971993 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="Content-Language" content="en-us">
<link rel="stylesheet" href="http://unicode.org/reports/reports.css"
type="text/css">
<title>UTS #35: Unicode Locale Data Markup Language</title>
<style type="text/css">
<!--
.dtd {
font-family: monospace;
font-size: 90%;
background-color: #CCCCFF;
border-style: dotted;
border-width: 1px;
}
.xmlExample {
font-family: monospace;
font-size: 80%
}
.blockedInherited {
font-style: italic;
font-weight: bold;
border-style: dashed;
border-width: 1px;
background-color: #FF0000
}
.inherited {
font-weight: bold;
border-style: dashed;
border-width: 1px;
background-color: #00FF00
}
.element {
font-weight: bold;
color: red;
}
.attribute {
font-weight: bold;
color: maroon;
}
.attributeValue {
font-weight: bold;
color: blue;
}
li, p {
margin-top: 0.5em;
margin-bottom: 0.5em
}
h2, h3, h4, h5, table {
margin-top: 1.5em;
margin-bottom: 0.5em;
}
h5 {
font-size: medium;
font-style: italic
}
-->
</style>
</head>
<body>
<table class="header" width="100%">
<tr>
<td class="icon"><a href="http://unicode.org"> <img
alt="[Unicode]" src="http://unicode.org/webscripts/logo60s2.gif"
width="34" height="33"
style="vertical-align: middle; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px; border-top-width: 0px;"></a>&nbsp;
<a class="bar" href="http://www.unicode.org/reports/">Technical
Reports</a></td>
</tr>
<tr>
<td class="gray">&nbsp;</td>
</tr>
</table>
<div class="body">
<h2 style="text-align: center">
Unicode Technical Standard #35
</h2>
<h1 style="text-align: center">Unicode Locale Data Markup Language (LDML)</h1>
<!-- At least the first row of this header table should be identical across the parts of this UTS. -->
<table border="1" cellpadding="2" cellspacing="0" class="wide">
<tr>
<td>Version</td>
<td>34</td>
</tr>
<tr>
<td>Editors</td>
<td><a
href="https://plus.google.com/114199149796022210033?rel=author">
Mark Davis</a> (<a href="mailto:markdavis@google.com">markdavis@google.com</a>)
and <a href="tr35.html#Acknowledgments">other CLDR committee
members</a></td>
</tr>
<tr>
<td>Date</td>
<td>2018-10-10</td>
</tr>
<tr>
<!-- This link must be made live when posting the final version but is disabled during proposed update stage. -->
<td>This Version</td>
<td>
<a href="http://www.unicode.org/reports/tr35/tr35-53/tr35.html">
http://www.unicode.org/reports/tr35/tr35-53/tr35.html</a></td>
</tr>
<tr>
<td>Previous Version</td>
<td>
<a href="http://www.unicode.org/reports/tr35/tr35-51/tr35.html">http://www.unicode.org/reports/tr35/tr35-51/tr35.html</a></td>
</tr>
<tr>
<td>Latest Version</td>
<td><a href="http://www.unicode.org/reports/tr35/">http://www.unicode.org/reports/tr35/</a></td>
</tr>
<tr>
<td>Corrigenda</td>
<td><a href="http://unicode.org/cldr/corrigenda.html">http://unicode.org/cldr/corrigenda.html</a></td>
</tr>
<tr>
<td>Latest Proposed Update</td>
<td><a href="http://www.unicode.org/reports/tr35/proposed.html">http://www.unicode.org/reports/tr35/proposed.html</a></td>
</tr>
<tr>
<td>Namespace</td>
<td><a href="http://cldr.unicode.org/">http://cldr.unicode.org/</a></td>
</tr>
<tr>
<td>DTDs</td>
<td><a href="http://unicode.org/cldr/dtd/34/">
http://unicode.org/cldr/dtd/34/</a></td>
</tr>
<tr>
<td>Revision</td>
<td><a href="#Modifications">53</a></td>
</tr>
</table>
<h3>
<i>Summary</i>
</h3>
<p>
This document describes an XML format (<i>vocabulary</i>) for the
exchange of structured locale data. This format is used in the <a
href="http://cldr.unicode.org/">Unicode Common Locale Data
Repository</a>.
</p>
<h3>
<i>Status</i>
</h3>
<!-- NOT YET APPROVED
<p>
<i class="changed">This is a<b><font color="#ff3333">
draft </font></b>document which may be updated, replaced, or superseded by
other documents at any time. Publication does not imply endorsement
by the Unicode Consortium. This is not a stable document; it is
inappropriate to cite this document as other than a work in
progress.
</i>
</p>
END NOT YET APPROVED -->
<!-- APPROVED -->
<p>
<i>This document has been reviewed by Unicode members and other
interested parties, and has been approved for publication by the
Unicode Consortium. This is a stable document and may be used as
reference material or cited as a normative reference by other
specifications.</i>
</p>
<!-- END APPROVED -->
<blockquote>
<p>
<i><b>A Unicode Technical Standard (UTS)</b> is an independent
specification. Conformance to the Unicode Standard does not imply
conformance to any UTS.</i>
</p>
</blockquote>
<p>
<i>Please submit corrigenda and other comments with the CLDR bug
reporting form [<a href="http://cldr.unicode.org/index/bug-reports">Bugs</a>].
Related information that is useful in understanding this document is
found in the <a href="#References">References</a>. For the latest
version of the Unicode Standard see [<a
href="http://www.unicode.org/versions/latest/">Unicode</a>]. For a
list of current Unicode Technical Reports see [<a
href="http://www.unicode.org/reports/">Reports</a>]. For more
information about versions of the Unicode Standard, see [<a
href="http://www.unicode.org/versions/">Versions</a>].
</i>
</p>
<!-- This section of Parts should be identical in all of the parts of this UTS. -->
<h2>
<a name="Parts" href="#Parts">Parts</a>
</h2>
<p>The LDML specification is divided into the following parts:</p>
<ul class="toc">
<li>Part 1: <a href="tr35.html#Contents">Core</a> (languages,
locales, basic structure)
</li>
<li>Part 2: <a href="tr35-general.html#Contents">General</a>
(display names &amp; transforms, etc.)
</li>
<li>Part 3: <a href="tr35-numbers.html#Contents">Numbers</a>
(number &amp; currency formatting)
</li>
<li>Part 4: <a href="tr35-dates.html#Contents">Dates</a> (date,
time, time zone formatting)
</li>
<li>Part 5: <a href="tr35-collation.html#Contents">Collation</a>
(sorting, searching, grouping)
</li>
<li>Part 6: <a href="tr35-info.html#Contents">Supplemental</a>
(supplemental data)
</li>
<li>Part 7: <a href="tr35-keyboards.html#Contents">Keyboards</a>
(keyboard mappings)
</li>
</ul>
<h2>
<a name="Contents" href="#Contents">Contents of Part 1, Core</a>
</h2>
<!-- START Generated TOC: CheckHtmlFiles -->
<ul class="toc">
<li>1 <a href="#Introduction">Introduction</a>
<ul class="toc">
<li>1.1 <a href="#Conformance">Conformance</a></li>
</ul>
</li>
<li>2 <a href="#Locale">What is a Locale?</a></li>
<li>3 <a href="#Identifiers">Unicode Language and Locale
Identifiers</a>
<ul class="toc">
<li>3.1 <a href="#Unicode_language_identifier">Unicode
Language Identifier</a></li>
<li>3.2 <a href="#Unicode_locale_identifier">Unicode
Locale Identifier</a></li>
<li>3.3 <a href="#BCP_47_Conformance">BCP 47 Conformance</a>
<ul class="toc">
<li>3.3.1 <a href="#BCP_47_Language_Tag_Conversion">BCP
47 Language Tag Conversion</a></li>
</ul>
</li>
<li>3.4 <a href="#Field_Definitions">Language Identifier
Field Definitions</a>
<ul class="toc">
<li>Table: <a href="#Language_Locale_Field_Definitions">Language
Identifier Field Definitions</a></li>
</ul>
</li>
<li>3.5 <a href="#Special_Codes">Special Codes</a>
<ul class="toc">
<li>3.5.1 <a href="#Unknown_or_Invalid_Identifiers">Unknown
or Invalid Identifiers</a></li>
<li>3.5.2 <a href="#Numeric_Codes">Numeric Codes</a></li>
<li>3.5.3 <a href="#Private_Use">Private Use Codes</a>
<ul class="toc">
<li>Table: <a href="#Private_Use_CLDR">Private Use
Codes in CLDR</a></li>
</ul>
</li>
</ul>
</li>
<li>3.6 <a href="#Locale_Extension_Key_and_Type_Data">Unicode
BCP 47 U Extension</a>
<ul class="toc">
<li>3.6.1 <a href="#Key_And_Type_Definitions_">Key And
Type Definitions</a>
<ul class="toc">
<li>Table: <a href="#Key_Type_Definitions">Key/Type
Definitions</a></li>
</ul>
</li>
<li>3.6.2 <a href="#Numbering System Data">Numbering
System Data</a></li>
<li>3.6.3 <a href="#Time_Zone_Identifiers">Time Zone
Identifiers</a></li>
<li>3.6.4 <a href="#Unicode_Locale_Extension_Data_Files">U
Extension Data Files</a>
</li>
<li>3.6.5 <a href="#Unicode_Subdivision_Codes">Subdivision
Codes</a>
<ul class="toc">
<li>3.6.5.1 <a href="#Validity">Validity</a></li>
</ul>
</li>
</ul>
</li>
<li>3.7 <a href="#t_Extension">Unicode BCP 47 T Extension</a>
<ul class="toc">
<li>3.7.1 <a href="#Transformed_Content_Data_File">T
Extension Data Files</a></li>
</ul>
</li>
<li>3.8 <a href="#Compatibility_with_Older_Identifiers">Compatibility
with Older Identifiers</a>
<ul class="toc">
<li>3.8.1 <a href="#Old_Locale_Extension_Syntax">Old
Locale Extension Syntax</a>
<ul class="toc">
<li>Table: <a href="#Locale_Extension_Mappings">Locale
Extension Mappings</a></li>
</ul>
</li>
<li>3.8.2 <a href="#Legacy_Variants">Legacy Variants</a>
<ul class="toc">
<li>Table: <a href="#Legacy_Variant_Mappings">Legacy
Variant Mappings</a></li>
</ul>
</li>
<li>3.8.3 <a href="#Relation_to_OpenI18n">Relation to
OpenI18n</a></li>
</ul>
</li>
<li>3.9 <a href="#Transmitting_Locale_Information">Transmitting
Locale Information</a>
<ul class="toc">
<li>3.9.1 <a href="#Message_Formatting_and_Exceptions">Message
Formatting and Exceptions</a></li>
</ul>
</li>
<li>3.10 <a href="#Language_and_Locale_IDs">Unicode
Language and Locale IDs</a>
<ul class="toc">
<li>3.10.1 <a href="#Written_Language">Written Language</a></li>
<li>3.10.2 <a href="#Hybrid_Locale">Hybrid Locale Identifiers</a></li>
</ul>
</li>
<li>3.11 <a href="#Validity_Data">Validity Data</a></li>
</ul>
</li>
<li>4 <a href="#Locale_Inheritance">Locale Inheritance and
Matching</a>
<ul class="toc">
<li>4.1 <a href="#Lookup">Lookup</a>
<ul class="toc">
<li>4.1.1 <a href="#Bundle_vs_Item_Lookup">Bundle vs
Item Lookup</a>
<ul class="toc">
<li>Table: <a href="#Lookup-Differences">Lookup
Differences</a></li>
</ul>
</li>
<li>4.1.2 <a href="#Multiple_Inheritance">Lateral
Inheritance</a>
<ul class="toc">
<li>Table: <a href="#Count_Fallback_normal">Count
Fallback: normal</a></li>
<li>Table: <a href="#Count_Fallback_currency">Count
Fallback: currency</a></li>
</ul>
</li>
<li>4.1.3 <a href="#Parent_Locales">Parent Locales</a></li>
</ul>
</li>
<li>4.2 <a href="#Inheritance_and_Validity">Inheritance
and Validity</a>
<ul class="toc">
<li>4.2.1 <a href="#Definitions">Definitions</a></li>
<li>4.2.2 <a href="#Resolved_Data_File">Resolved Data
File</a></li>
<li>4.2.3 <a href="#Valid_Data">Valid Data</a></li>
<li>4.2.4 <a href="#Checking_for_Draft_Status">Checking
for Draft Status</a></li>
<li>4.2.5 <a href="#Keyword_and_Default_Resolution">Keyword
and Default Resolution</a></li>
<li>4.2.6 <a
href="#Inheritance_vs_Related">Inheritance vs Related Information</a></li>
</ul>
</li>
<li>4.3 <a href="#Likely_Subtags">Likely Subtags</a></li>
<li>4.4 <a href="#LanguageMatching">Language Matching</a>
<ul>
<li>4.4.1 <a href="#EnhancedLanguageMatching">Enhanced Language Matching</a></li>
</ul>
</li>
</ul>
</li>
<li>5 <a href="#XML_Format">XML Format</a>
<ul class="toc">
<li>5.1 <a href="#Common_Elements">Common Elements</a>
<ul class="toc">
<li>5.1.1 <a href="#special">Element special</a>
<ul class="toc">
<li>5.1.1.1 <a href="#Sample_Special_Elements">Sample
Special Elements</a></li>
</ul>
</li>
<li>5.1.2 <a href="#Alias_Elements">Element alias</a>
<ul class="toc">
<li>Table: <a href="#Inheritance_with_source_locale_">Inheritance
with source=&quot;locale&quot;</a></li>
</ul>
</li>
<li>5.1.3 <a href="#Element_displayName">Element
displayName</a></li>
<li>5.1.4 <a href="#Escaping_Characters">Escaping
Characters</a></li>
</ul>
</li>
<li>5.2 <a href="#Common_Attributes">Common Attributes</a>
<ul class="toc">
<li>5.2.1 <a href="#Attribute_type">Attribute type</a></li>
<li>5.2.2 <a href="#Attribute_draft">Attribute draft</a></li>
<li>5.2.3 <a href="#alt_attribute">Attribute alt</a></li>
</ul>
</li>
<li>5.3 <a href="#Common_Structures">Common Structures</a>
<ul class="toc">
<li>5.3.1 <a href="#Date_Ranges">Date and Date Ranges</a></li>
<li>5.3.2 <a href="#Text_Directionality">Text
Directionality</a></li>
<li>5.3.3 <a href="#Unicode_Sets">Unicode Sets</a>
<ul class="toc">
<li>5.3.3.1 <a href="#Lists_of_Code_Points">Lists of
Code Points</a></li>
<li>5.3.3.2 <a href="#Unicode_Properties">Unicode
Properties</a></li>
<li>5.3.3.3 <a href="#Boolean_Operations">Boolean
Operations</a></li>
<li>5.3.3.4 <a href="#UnicodeSet_Examples">UnicodeSet
Examples</a></li>
</ul>
</li>
<li>5.3.4 <a href="#String_Range">String Range</a></li>
</ul>
</li>
<li>5.4 <a href="#Identity_Elements">Identity Elements</a></li>
<li>5.5 <a href="#Valid_Attribute_Values">Valid Attribute
Values</a></li>
<li>5.6 <a href="#Canonical_Form">Canonical Form</a>
<ul class="toc">
<li>5.6.1 <a href="#Content">Content</a></li>
<li>5.6.2 <a href="#Ordering">Ordering</a></li>
<li>5.6.3 <a href="#Comments">Comments</a></li>
</ul>
</li>
<li>5.7 <a href="#DTD_Annotations">DTD Annotations</a></li>
</ul>
</li>
<li>6 <a href="#Property_Data">Property Data</a>
<ul class="toc">
<li>6.1 <a href="#Script_Metadata">Script Metadata</a></li>
<li>6.2 <a href="#Extended_Pictographic">Extended Pictographic</a></li>
<li>6.3 <a href="#Labels.txt">Labels.txt</a></li>
</ul>
</li>
<li>7 <a href="#Format_Parse_Issues">Issues in Formatting
and Parsing</a>
<ul class="toc">
<li>7.1 <a href="#Lenient_Parsing">Lenient Parsing</a>
<ul class="toc">
<li>7.1.1 <a href="#Motivation">Motivation</a></li>
<li>7.1.2 <a href="#Loose_Matching">Loose Matching</a></li>
</ul>
</li>
<li>7.2 <a href="#Invalid_Patterns">Handling Invalid
Patterns</a></li>
</ul>
</li>
<li>Annex A <a href="#Deprecated_Structure">Deprecated Structure</a>
<ul class="toc">
<li>A.1 <a href="#Fallback_Elements">Element fallback</a></li>
<li>A.2 <a href="#BCP47_Keyword_Mapping">BCP 47 Keyword
Mapping</a></li>
<li>A.3 <a href="#Choice_Patterns">Choice Patterns</a></li>
<li>A.4 <a href="#Element_default">Element default</a></li>
<li>A.5 <a href="#Deprecated_Common_Attributes">Deprecated
Common Attributes</a>
<ul>
<li>A.5.1 <a href="#Attribute_standard">Attribute
standard</a></li>
<li>A.5.2 <a href="#Attribute_draft_nonLeaf">Attribute
draft in non-leaf elements</a></li>
</ul>
</li>
<li>A.6 <a href="#Element_base">Element base</a></li>
<li>A.7 <a href="#Element_rules">Element rules</a></li>
<li>A.8 <a href="#Deprecated_subelements_of_dates">Deprecated
subelements of &lt;dates&gt;</a></li>
<li>A.9 <a href="#Deprecated_subelements_of_calendars">Deprecated
subelements of &lt;calendars&gt;</a></li>
<li>A.10 <a href="#Deprecated_subelements_of_timeZoneNames">Deprecated
subelements of &lt;timeZoneNames&gt;</a></li>
<li>A.11 <a href="#Deprecated_subelements_of_zone_metazone">Deprecated
subelements of &lt;zone&gt; and &lt;metazone&gt;</a></li>
<li>A.12 <a
href="#Renamed_attribute_values_for_contextTransformUsage">Renamed
attribute values for &lt;contextTransformUsage&gt; element</a></li>
<li>A.13 <a href="#Deprecated_subelements_of_segmentations">Deprecated
subelements of &lt;segmentations&gt;</a></li>
<li>A.14 <a href="#Element_cp">Element cp</a></li>
<li>A.15 <a href="#validSubLocales">Attribute
validSubLocales</a></li>
<li>A.16 <a href="#postCodeElements">Elements
postalCodeData, postCodeRegex</a></li>
<li>A.17 <a href="#telephoneCodeData">Element
telephoneCodeData</a></li>
</ul>
</li>
<li>Annex B <a href="#Links_to_Other_Parts">Links to Other Parts</a>
<ul class="toc">
<li>Table: <a href="#Part_2_Links">Part 2 Links: General
(display names &amp; transforms, etc.)</a></li>
<li>Table: <a href="#Part_3_Links">Part 3 Links: Numbers
(number &amp; currency formatting)</a></li>
<li>Table: <a href="#Part_4_Links">Part 4 Links: Dates
(date, time, time zone formatting)</a></li>
<li>Table: <a href="#Part_5_Links">Part 5 Links: Collation
(sorting, searching, grouping)</a></li>
<li>Table: <a href="#Part_6_Links">Part 6 Links:
Supplemental (supplemental data)</a></li>
<li>Table: <a href="#Part_7_Links">Part 7 Links: Keyboards
(keyboard mappings)</a></li>
</ul>
</li>
<li><a href="#References">References</a></li>
<li><a href="#Acknowledgments">Acknowledgments</a></li>
<li><a href="#Modifications">Modifications</a></li>
</ul>
<!-- END Generated TOC: CheckHtmlFiles -->
<h2>
<a name="Introduction" href="#Introduction">1 Introduction</a>
</h2>
<p>Not long ago, computer systems were like separate worlds,
isolated from one another. The internet and related events have
changed all that. A single system can be built of many different
components, hardware and software, all needing to work together. Many
different technologies have been important in bridging the gaps; in
the internationalization arena, Unicode has provided a lingua franca
for communicating textual data. However, there remain differences in
the locale data used by different systems.</p>
<p>The best practice for internationalization is to store and
communicate language-neutral data, and format that data for the
client. This formatting can take place on any of a number of the
components in a system; a server might format data based on the
user&#39;s locale, or it could be that a client machine does the
formatting. The same goes for parsing data, and locale-sensitive
analysis of data.</p>
<p>
But there remain significant differences across systems and
applications in the locale-sensitive data used for such formatting,
parsing, and analysis. Many of those differences are simply
gratuitous; all within acceptable limits for human beings, but
yielding different results. In many other cases there are outright
errors. Whatever the cause, the differences can cause discrepancies
to creep into a heterogeneous system. This is especially serious in
the case of collation (sort-order), where different collation caused
not only ordering differences, but also different results of queries!
That is, with a query of customers with names between &quot;Abbot,
Cosmo&quot; and &quot;Arnold, James&quot;, if different systems have
different sort orders, different lists will be returned. (For
comparisons across systems formatted as HTML tables, see [<a
href="#Comparisons">Comparisons</a>].)
</p>
<blockquote>
<p class="note">
<b>Note:</b> There are many different equally valid ways in which
data can be judged to be &quot;correct&quot; for a particular
locale. The goal for the common locale data is to make it as
consistent as possible with existing locale data, and acceptable to
users in that locale.
</p>
</blockquote>
<p>This document specifies an XML format for the communication of
locale data: the Unicode Locale Data Markup Language (LDML). This
provides a common format for systems to interchange locale data so
that they can get the same results in the services provided by
internationalization libraries. It also provides a standard format
that can allow users to customize the behavior of a system. With it,
for example, collation (sorting) rules can be exchanged, allowing two
implementations to exchange a specification of tailored collation
rules. Using the same specification, the two implementations will
achieve the same results in comparing strings. Unicode LDML can also
be used to let a user encapsulate specialized sorting behavior for a
specific domain, or create a customized locale for a minority
language. Unicode LDML is also used in the Unicode Common Locale Data
Repository (CLDR). CLDR uses an open process for reconciling
differences between the locale data used on different systems and
validating the data, to produce with a useful, common, consistent
base of locale data.</p>
<p>
For more information, see the Common Locale Data Repository project
page [<a href="#localeProject">LocaleProject</a>].
</p>
<p>As LDML is an interchange format, it was designed for ease of
maintenance and simplicity of transformation into other formats,
above efficiency of run-time lookup and use. Implementations should
consider converting LDML data into a more compact format prior to
use.</p>
<h3>
<a name="Conformance" href="#Conformance">1.1 Conformance</a>
</h3>
<p>There are many ways to use the Unicode LDML format and the data
in CLDR, and the Unicode Consortium does not restrict the ways in
which the format or data are used. However, an implementation may
also claim conformance to LDML or to CLDR, as follows:</p>
<p>&nbsp;</p>
<p>
<i><b>UAX35-C1.</b> </i>An implementation that claims conformance to
this specification shall:
</p>
<ol>
<li>Identify the sections of the specification that it conforms
to.
<ul>
<li>For example, an implementation might claim conformance to
all LDML features except for <i>transforms</i> and <i>segments</i>.
</li>
</ul>
</li>
<li>Interpret the relevant elements and attributes of LDML
documents in accordance with the descriptions in those sections.
<ul>
<li>For example, an implementation that claims conformance to
the date format patterns must interpret the characters in such
patterns according to <a
href="tr35-dates.html#Date_Field_Symbol_Table">Date Field
Symbol Table</a>.
</li>
</ul>
</li>
<li>Declare which types of CLDR data that it uses.
<ul>
<li>For example, an implementation might declare that it only
uses language names, and those with a <i>draft</i> status of <i>contributed</i>
or <i>approved</i>.
</li>
</ul>
</li>
</ol>
<p>
<i><b>UAX35-C2.</b> </i>An implementation that claims conformance to
Unicode locale or language identifiers shall:
</p>
<ol>
<li>Specify whether Unicode locale extensions are allowed</li>
<li>Specify the canonical form used for identifiers in terms of
casing and field separator characters.</li>
</ol>
<p>External specifications may also reference particular
components of Unicode locale or language identifiers, such as:</p>
<blockquote>
<p>
<i>Field X can contain any Unicode region subtag values as given
in Unicode Technical Standard #35: Unicode Locale Data Markup
Language (LDML), excluding grouping codes.</i>
</p>
</blockquote>
<h2>
<a name="Locale" href="#Locale">2 What is a Locale?</a>
</h2>
<p>Before diving into the XML structure, it is helpful to describe
the model behind the structure. People do not have to subscribe to
this model to use data in LDML, but they do need to understand it so
that the data can be correctly translated into whatever model their
implementation uses.</p>
<p>
The first issue is basic: <i>what is a locale?</i> In this model, a
locale is an identifier (id) that refers to a set of user preferences
that tend to be shared across significant swaths of the world.
Traditionally, the data associated with this id provides support for
formatting and parsing of dates, times, numbers, and currencies; for
measurement units, for sort-order (collation), plus translated names
for time zones, languages, countries, and scripts. The data can also
include support for text boundaries (character, word, line, and
sentence), text transformations (including transliterations), and
other services.
</p>
<p>Locale data is not cast in stone: the data used on
someone&#39;s machine generally may reflect the US format, for
example, but preferences can typically set to override particular
items, such as setting the date format for 2002.03.15, or using
metric or Imperial measurement units. In the abstract, locales are
simply one of many sets of preferences that, say, a website may want
to remember for a particular user. Depending on the application, it
may want to also remember the user&#39;s time zone, preferred
currency, preferred character set, smoker/non-smoker preference, meal
preference (vegetarian, kosher, and so on), music preference,
religion, party affiliation, favorite charity, and so on.</p>
<p>Locale data in a system may also change over time: country
boundaries change; governments (and currencies) come and go:
committees impose new standards; bugs are found and fixed in the
source data; and so on. Thus the data needs to be versioned for
stability over time.</p>
<p>
In general terms, the locale id is a parameter that is supplied to a
particular service (date formatting, sorting, spell-checking, and so
on). The format in this document does not attempt to represent all
the data that could conceivably be used by all possible services.
Instead, it collects together data that is in common use in systems
and internationalization libraries for basic services. The main
difference among locales is in terms of language; there may also be
some differences according to different countries or regions.
However, the line between <i>locales</i> and <i>languages</i>, as
commonly used in the industry, are rather fuzzy. Note also that the
vast majority of the locale data in CLDR is in fact language data;
all non-linguistic data is separated out into a separate tree. For
more information, see <i><a href="#Language_and_Locale_IDs">Section
3.10 Language and Locale IDs</a></i>.
</p>
<p>
We will speak of data as being &quot;in locale X&quot;. That does not
imply that a locale <i>is</i> a collection of data; it is simply
shorthand for &quot;the set of data associated with the locale id
X&quot;. Each individual piece of data is called a <i>resource </i>or
<i>field</i>, and a tag indicating the key of the resource is called
a <i>resource tag.</i>
</p>
<h2>
<a name="Identifiers" href="#Identifiers"></a><a
name="Unicode_Language_and_Locale_Identifiers"
href="#Unicode_Language_and_Locale_Identifiers"> 3 Unicode
Language and Locale Identifiers</a>
</h2>
<p>
Unicode LDML uses stable identifiers based on [<a href="#BCP47">BCP47</a>]
for distinguishing among languages, locales, regions, currencies,
time zones, transforms, and so on. There are many systems for
identifiers for these entities. The Unicode LDML identifiers may not
match the identifiers used on a particular target system. If so, some
process of identifier translation may be required when using LDML
data.
</p>
<p>
The BCP 47 extensions (-u- and -t-) are described in <em>Section
3.6 <a href="#u_Extension">Unicode BCP 47 U Extension</a>
</em> and <em>Section 3.7 <a href="#BCP47_T_Extension">Unicode
BCP 47 T Extension</a></em>.
</p>
<h3>
<i><a name="Unicode_language_identifier"
href="#Unicode_language_identifier">3.1 Unicode Language
Identifier</a></i>
</h3>
<p>
A <i>Unicode language identifier</i> has the following structure
(provided in either EBNF (Perl-based) or ABNF [<a href="#RFC5234">RFC5234</a>]).
The following table defines syntactically well-formed identifiers:
they are not necessarily valid identifiers. For additional validity
criteria, see the links on the right.
</p>
<table>
<tr>
<th>&nbsp;</th>
<th><div align="center">EBNF</div></th>
<th><div align="center">ABNF</div></th>
<th><div align="center">Validity / Comments</div></th>
</tr>
<tr>
<td><code>
<a href="#unicode_language_id" name="unicode_language_id">unicode_language_id</a>
</code></td>
<td><code>
= &quot;root&quot;<br>
| (unicode_language_subtag <br>     (sep
unicode_script_subtag)? <br>   | unicode_script_subtag)<br>
  (sep unicode_region_subtag)? <br>
  (sep
unicode_variant_subtag)* ;
</code></td>
<td><code>
= &quot;root&quot;<br>
/ (unicode_language_subtag <br>     [sep
unicode_script_subtag] <br>   / unicode_script_subtag)<br>
  [sep unicode_region_subtag] <br>
  *(sep
unicode_variant_subtag)
</code></td><td>"root" is treated as a special <code>unicode_language_subtag</code></tr>
<tr>
<td><code>
<a href="#unicode_language_subtag" name="unicode_language_subtag">unicode_language_subtag</a>
</code></td>
<td><code> = alpha{2,3} | alpha{5,8}; </code></td>
<td><code> = 2*3ALPHA / 5*8ALPHA </code></td>
<td><code>
<a href='#unicode_language_subtag_validity'>validity</a><br>
<a href='http://unicode.org/cldr/latest/common/validity/language.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>
<a href="#unicode_script_subtag" name="unicode_script_subtag">unicode_script_subtag</a>
</code></td>
<td><code>= alpha{4} ;</code></td>
<td><code>= 4ALPHA</code></td>
<td><code>
<a href='#unicode_script_subtag_validity'>validity</a><br>
<a href='http://unicode.org/cldr/latest/common/validity/script.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>
<a href="#unicode_region_subtag" name="unicode_region_subtag">unicode_region_subtag</a>
</code></td>
<td><code>= (alpha{2} | digit{3}) ;</code></td>
<td><code>= 2ALPHA / 3DIGIT</code></td>
<td><code>
<a href='#unicode_language_subtag_validity'>validity</a><br>
<a href='http://unicode.org/cldr/latest/common/validity/region.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>
<a href="#unicode_variant_subtag" name="unicode_variant_subtag">unicode_variant_subtag</a>
</code></td>
<td><code>
= (alphanum{5,8} <br> | digit alphanum{3}) ;
</code></td>
<td><code>
= 5*8alphanum<br>/ (DIGIT 3alphanum)
</code></td>
<td><code>
<a href='#unicode_language_subtag_validity'>validity</a><br>
<a href='http://unicode.org/cldr/latest/common/validity/variant.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>sep</code></td>
<td><code>= [-_] ;</code></td>
<td><code>= "-" / "_"</code></td>
</tr>
<tr>
<td><code>digit</code></td>
<td><code>= [0-9] ;</code></td>
<td><code>&nbsp;</code></td>
</tr>
<tr>
<td><code>alpha</code></td>
<td><code>= [A-Z a-z] ;</code></td>
<td><code>&nbsp;</code></td>
</tr>
<tr>
<td><code>alphanum</code></td>
<td><code>= [0-9 A-Z a-z] ;</code></td>
<td><code>= ALPHA / DIGIT</code></td>
</tr>
</table>
<p>
The semantics of the various subtags is explained in <em>Section
3.4 <a href="#Field_Definitions">Language Identifier Field
Definitions</a>
</em>; there are also direct links from
<code>
<a href="#unicode_language_subtag">unicode_language_subtag</a>
</code>
, etc. While theoretically the
<code>
<a href="#unicode_language_subtag">unicode_language_subtag</a>
</code>
may have more than 3 letters through the IANA registration process,
in practice that has not occurred. The
<code>
<a href="#unicode_language_subtag">unicode_language_subtag</a>
</code>
&quot;und&quot; may be omitted when there is a
<code>
<a href="#unicode_script_subtag">unicode_script_subtag</a>
</code>
; for that reason
<code>
<a href="#unicode_language_subtag">unicode_language_subtag</a>
</code>
values with 4 letters are not permitted. However, such
<code>
<a href="#unicode_language_id">unicode_language_id</a>
</code>
values are not intended for general interchange, because they are not
valid BCP 47 tags. Instead, they are intended for certain protocols
such as the identification of transliterators or font ScriptLangTag
values.
</p>
<p>For example, &quot;en-US&quot; (American English),
&quot;en_GB&quot; (British English), &quot;es-419&quot; (Latin
American Spanish), and &quot;uz-Cyrl&quot; (Uzbek in Cyrillic) are
all valid Unicode language identifiers.</p>
<h3>
<i><a name="Unicode_locale_identifier"
href="#Unicode_locale_identifier">3.2 Unicode Locale Identifier</a></i>
</h3>
<p>
A <i>Unicode locale identifier</i> is composed of a Unicode language
identifier plus (optional) locale extensions. It has the
following structure. The semantics of the U and T extensions are
explained in <em>Section 3.6 <a href="#u_Extension">Unicode
BCP 47 U Extension</a>
</em> and <em>Section 3.7 <a href="#BCP47_T_Extension">Unicode
BCP 47 T Extension</a></em>. Other extensions and private use extensions are supported for pass-through. The following table defines syntactically
<em>well-formed</em> identifiers: they are not necessarily <em>valid</em> identifiers.
For additional validity criteria, see the links on the right. </p>
<table border="0">
<tr>
<th>&nbsp;</th>
<th><div align="center">EBNF</div></th>
<th><div align="center">ABNF</div></th>
<th><div align="center">Validity</div></th>
</tr>
<tr>
<td><code>
<a href="#unicode_locale_id" name="unicode_locale_id">unicode_locale_id</a>
</code></td>
<td><code>
= unicode_language_id<br>
  extensions*<br>
 
pu_extensions? ; </code></td>
<td><code>
= unicode_language_id<br>
  [extensions]   <br>
 
1*pu_extensions </code></td>
</tr>
<tr>
<td><code>
<a href="#extensions" name="extensions">extensions</a>
</code></td>
<td><code>
= unicode_locale_extensions <br>
| transformed_extensions <br>
| other_extensions ;</code></td>
<td><code>= unicode_locale_extensions <br>
/ transformed_extensions <br>
/ other_extensions</code></td>
</tr>
<tr>
<td><code>
<a href="#unicode_locale_extensions"
name="unicode_locale_extensions">unicode_locale_extensions</a>
</code></td>
<td><code>
= sep [uU]<br>   ((sep keyword)+ <br>   |(sep attribute)+
(sep keyword)*) ;
</code></td>
<td><code>
= sep &quot;u&quot; <br>   (1*(sep keyword) <br>   / 1*(sep
attribute) *(sep keyword))
</code></td>
</tr>
<tr>
<td><code>
<a href="#transformed_extensions" name="transformed_extensions">transformed_extensions</a>
</code></td>
<td><code>
= sep [tT] <br>   ((sep tlang (sep tfield)*) <br>
  | (sep tfield)+) ; </code></td>
<td><code>
= sep &quot;t&quot; <br>   ((sep tlang
*(sep tfield)) <br>   / 1*(sep tfield)) </code></td>
</tr>
<tr>
<td><code><a href="#pu_extensions" name="pu_extensions">pu_extensions</a></code></td>
<td><code>= sep [xX] <br>
 
(sep alphanum{1,8})* ;</code></td>
<td><code>= sep &quot;x&quot; <br>
 
[sep 1*8alphanum]</code></td>
</tr>
<tr>
<td><code><a href="#other_extensions" name="other_extensions">other_extensions</a></code></td>
<td><code>= [alphanum-[tTuUxX]]<br>
 
(sep alphanum{2,8})* ;</code></td>
<td><code>= (DIGIT<br>
   
/ %x61-%x73<br>
    / %x76-%x77<br>
   
/ %x79-%x7A)<br>
 
*(sep 2*8alphanum)</code></td>
</tr>
<tr>
<td><code>keyword</code></td>
<td><code>= key (sep type)? ;</code></td>
<td><code>= key [sep type]</code></td>
</tr>
<tr>
<td><code>key</code></td>
<td><code>
= alphanum alpha ;
</code></td>
<td><code>
= alphanum ALPHA
</code></td>
<td><code>
<a href="#Key_Type_Definitions">validity</a><br>
<a
href='http://unicode.org/cldr/latest/common/bcp47'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>type</code></td>
<td><code>
= alphanum{3,8}<br>  (sep alphanum{3,8})* ;
</code></td>
<td><code>
= 3*8alphanum<br>  *(sep 3*8alphanum)
</code></td>
<td><code>
<a href="#Key_Type_Definitions">validity</a><br>
<a
href='http://unicode.org/cldr/latest/common/bcp47'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>attribute</code></td>
<td><code>= alphanum{3,8} ;</code></td>
<td><code>= 3*8alphanum</code></td>
</tr>
<tr>
<td><code>
<a name="unicode_subdivision_id" href="#unicode_subdivision_id">unicode_subdivision_id</a><a
name="unicode_subdivision_subtag"></a><a
name="subdivision_attribute"></a>
</code></td>
<td><code>
= <a href="#unicode_region_subtag">unicode_region_subtag</a> unicode_subdivision_suffix ;
</code></td>
<td><code>
= <a href="#unicode_region_subtag">unicode_region_subtag</a> unicode_subdivision_suffix
</code></td>
<td><code>
<a href='#unicode_subdivision_subtag_validity'>validity</a><br>
<a
href='http://unicode.org/cldr/latest/common/validity/subdivision.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>unicode_subdivision_suffix</code></td>
<td><code> = (alphanum{1,4} ;</code></td>
<td><code>= 1*4alphanum</code></td>
</tr>
<tr>
<td><code>
<a name="unicode_measure_unit" href="#unicode_measure_unit">unicode_measure_unit</a>
</code></td>
<td><code>
= alphanum{3,8}<br>   (sep alphanum{3,8})* ;
</code></td>
<td><code>
= 3*8alphanum<br>   *(sep 3*8alphanum)
</code></td>
<td><code>
<a href='#Validity_Data'>validity</a><br>
<a
href='http://unicode.org/cldr/latest/common/validity/unit.xml'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>tlang</code></td>
<td><code>
= unicode_language_subtag<br>   (sep unicode_script_subtag)?<br>   (sep unicode_region_subtag)?<br>   (sep unicode_variant_subtag)* ; </code></td>
<td><code>
= unicode_language_subtag <br>   [sep unicode_script_subtag] <br>   [sep unicode_region_subtag] <br>
 
*(sep unicode_variant_subtag) </code></td>
</tr>
<tr>
<td><code>tfield</code></td>
<td><code>
= tkey tvalue;
</code></td>
<td><code>
= tkey tvalue
</code></td>
<td><code>
<a href="#BCP47_T_Extension">validity</a><br>
<a
href='http://unicode.org/cldr/latest/common/bcp47'>latest-data</a>
</code></td>
</tr>
<tr>
<td><code>
tkey
</code></td>
<td><code>
= alpha digit ;
</code></td>
<td><code>= ALPHA DIGIT</code></td>
</tr>
<tr>
<td><code>
tvalue
</code></td>
<td><code>= (sep alphanum{3,8})+ ;</code></td>
<td><code>= 1*(sep 3*8alphanum)</code></td>
</tr>
</table>
<p>
For historical reasons, this is called a Unicode locale identifier.
However, it really functions (with few exceptions) as a <span
class="st">language</span> identifier, and accesses <span class="st">language</span>-based
data. Except where it would be unclear, this document uses the term
&quot;locale&quot; data loosely to encompass both types of data: for
more information, see <i><a href="#Language_and_Locale_IDs">Section
3.10 Language and Locale IDs</a></i>.
</p>
<p></p>
<p>As of the release of this specification, there were no other_extensions defined. The other_extensions are present in the syntax to allow implementations to preserve that information. There cannot be more than one extension with the same singleton (-u-, -t-, ...). The private use extension must come after all other extensions.
</p>
<p>As for terminology, the term <i>code</i> may also be used instead of
&quot;subtag&quot;, and &quot;territory&quot; instead of
&quot;region&quot;. The primary language subtag is also called the <i>base
language code</i>. For example, the base language code for
&quot;en-US&quot; (American English) is &quot;en&quot; (English). The
<i>type</i> may also be referred to as a <i>value</i> or <i>key-value</i>.
</p>
<p>
The identifiers can vary in case and in the separator characters. The
&quot;-&quot; and &quot;_&quot; separators are treated as equivalent, although &quot;-&quot; is preferred.</p>
<p>All identifier field values are case-insensitive. Although case
distinctions do not carry any special meaning, an implementation of
LDML should use the casing recommendations in [<a href="#BCP47">BCP47</a>],
especially when a Unicode locale identifier is used for locale data
exchange in software protocols.</p>
<p>The canonical form of a <code><a href="#unicode_locale_id">unicode_locale_id</a></code> has:</p>
<ul>
<li> a language subtag (those beginning with a script subtag only are specialized use)</li>
<li>any script subtag in title case (eg, Hant)</li>
<li>any region subtag in uppercase (eg, DE)</li>
<li>all other subtags in lowercase (eg, en)</li>
<li>any variants in alphabetical order (eg, en-fonipa-scouse, not en-scouse-fonipa)</li>
<li>any extensions in alphabetical order by their singleton (eg, en-t-xxx-u-yyy, not en-u-yyy-t-xxx)</li>
</ul>
<p>
<b>Note:</b> The current version of CLDR data uses some non-preferred forms for backward compatibility. This might be changed in future CLDR releases.</p>
<ul>
<li>It uses uppercase letters for
variant subtags, while the preferred forms are all lowercase.</li>
<li>It uses &quot;_&quot; as the separator, while the preferred form of the separator is "-".</li>
<li>It uses &quot;root&quot;, while the preferred form is &quot;und&quot;.</li>
</ul>
<h3>
<a name="BCP_47_Conformance" href="#BCP_47_Conformance">3.3 BCP
47 Conformance</a>
</h3>
<p>
Unicode language and locale identifiers inherit the design and the
repertoire of subtags from [<a href="#BCP47">BCP47</a>] Language
Tags. There are some extensions and restrictions made for the use of
the Unicode locale identifier in CLDR:
</p>
<ul>
<li>It does not allow for the full syntax of [<a href="#BCP47">BCP47</a>]:
<ul>
<li>No extlang subtags are allowed (as in the BCP 47 canonical form, see BCP 47 <a href="https://tools.ietf.org/html/bcp47#section-4.5">Section 4.5</a> and <a href="https://tools.ietf.org/html/bcp47#section-3.1.7" target="_blank" >Section 3.1.7</a>)</li>
<li>No irregular BCP 47 grandfathered tags are allowed (these are all deprecated in BCP 47)</li>
<li>A tag must not start with the subtag &quot;x&quot;: thus a <em>privateuse</em> (eg x-abc) can only be after a language subtag, like &quot;und&quot;</li>
</ul>
</li>
<li>It allows for certain semantic additions and constraints:
<ul>
<li>Certain codes that are private-use in BCP-47 and ISO are given semantics by LDML</li>
<li>Each macrolanguage has an identified primary encompassed language, which is treated as an alias for the macrolanguage, and thus is replaced when canonicalizing (as allowed by BCP 47, see <a href="https://tools.ietf.org/html/bcp47#section-4.1.2">Section 4.1.2</a>)</li>
</ul>
</li>
<li>It allows certain syntax for backwards compatibility (not BCP 47-compatible):
<ul>
<li>The "_" character for field separator characters, as well as the "-" used in [<a href="#BCP47">BCP47</a>]
(however, the canonical form is with &quot;-&quot;)</li>
<li>The subtag "root" to indicate the generic locale used as the parent
of all languages in the CLDR data model (&quot;und&quot; can be used instead)</li>
<li>The language tag may begin with a script subtag rather than a language subtag. This is specialized use only, and not required for CLDR conformance.</li>
</ul>
</li>
</ul>
<p>There are thus two subtypes of Unicode locale identifiers:</p>
<ul>
<li>the term <em>Unicode CLDR locale identifier</em> applies where the backwards compatibility syntax is used.</li>
<li>the term <em>Unicode BCP 47 locale identifier</em> applies otherwise. A <em>Unicode BCP 47 locale identifier</em> is also a valid BCP 47 language tag.</li>
</ul>
<h4>
<a name="BCP_47_Language_Tag_Conversion"
href="#BCP_47_Language_Tag_Conversion">3.3.1 BCP 47 Language Tag
Conversion</a>
</h4>
<p>The different identifiers can be converted to one another as described in this section.
<p>
<h5>
<a name="Language_Tag_to_Locale_Identifier"
href="#Language_Tag_to_Locale_Identifier">BCP 47 Language Tag to Unicode BCP 47 Locale Identifier</a>
</h5>
<p>A valid [<a href="#BCP47">BCP47</a>] language tag can be converted
to a valid Unicode BCP 47 locale identifier by performing the
following transformation. </p>
<ol>
<li>Canonicalize the language tag (afterwards, there will be no
extlang subtags).</li>
<li>If the BCP 47 primary language subtag matches the <i>type</i>
attribute of a <i>languageAlias</i> element in <a
href="tr35-info.html#Supplemental_Data">Supplemental Data</a>,
replace the language subtag with the <i>replacement</i> value.
<ol>
<li>If there are additional subtags in the <i>replacement</i>
value, add them to the result, but only if there is no
corresponding subtag already in the tag.
</li>
</ol>
</li>
<li>If the BCP 47 region subtag matches the <i>type</i>
attribute of a <i>territoryAlias</i> element in <a
href="tr35-info.html#Supplemental_Data">Supplemental Data</a>,
replace the language subtag with the <i>replacement</i> value, as
follows:
<ol>
<li>If there is a single territory in the replacement, use it.</li>
<li>If there are multiple territories:
<ol>
<li>Look up the most likely territory for the base language
code (and script, if there is one).</li>
<li>If that likely territory is in the list, use it.</li>
<li>Otherwise, use the first territory in the list.</li>
</ol>
</li>
</ol>
</li>
<li>If the tag is one of the five deprecated grandfathered tags (cel-gaulish, i-default, i-enochian, i-mingo, zh-min) remaining after step #1, prefix by &quot;und-x-&quot;.</li>
<li>If the first subtag is &quot;x&quot;, prefix by &quot;und-&quot;.</li>
</ol>
<p>The result is a Unicode BCP 47 locale identifier, in canonical form. It is both a BCP 47 language tag and a Unicode locale identifier. Because the process maps from all BCP 47 language tags into a subset of BCP 47 language tags, the format changes are not reversible, much as a lowercase transformation of the string “McGowan” is not reversible.</p>
<br>
<p><em>Examples</em></p>
<table>
<tr>
<th style='width:10em'>BCP 47 language tag</th>
<th style='width:10em'>Unicode BCP 47 locale identifier</th>
<th>Comments</th>
</tr>
<tr>
<td><code>en-US</code></td>
<td><code>en-US</code></td>
<td>no changes</td>
</tr>
<tr>
<td><code>iw-FX</code></td>
<td><code>he-FR</code></td>
<td>BCP 47 canonicalization [1]</td>
</tr>
<tr>
<td><code>cmn-TW</code></td>
<td><code>zh-TW</code></td>
<td>language alias [2]</td>
</tr>
<tr>
<td><code>zh-cmn-TW</code></td>
<td><code>zh-TW</code></td>
<td>BCP 47 canonicalization [1], then language alias [2]</td>
</tr>
<tr>
<td><code>sr-CS</code></td>
<td><code>sr-RS</code></td>
<td>territory alias [3]</td>
</tr>
<tr>
<td><code>sh</code></td>
<td><code>sr-Latn</code></td>
<td>multiple replacement subtags [2.1]</td>
</tr>
<tr>
<td><code>sh-Cyrl</code></td>
<td><code>sr-Cyrl</code></td>
<td>no replacement with multiple replacement subtags [2.1 doesn't apply]</td>
</tr>
<tr>
<td><code>hy-SU</code></td>
<td><code>hy-AM</code></td>
<td>multiple territory values [3.2]<br> <code>&lt;territoryAlias
type=&quot;SU&quot; replacement=&quot;RU AM AZ BY EE GE KZ KG LV
LT MD TJ TM UA UZ&quot; …/&gt;</code></td>
</tr>
<tr>
<td><code>i-enochian</code></td>
<td><code>und-x-i-enochian</code></td>
<td>prefix any grandfathered tags with &quot;und-x-&quot; [4]</td>
</tr>
<tr>
<td><code>x-abc</code></td>
<td><code>und-x-abc</code></td>
<td>prefix with &quot;und-&quot;, so that there is always a base language subtag [5]</td>
</tr>
</table>
<p>&nbsp;</p>
<h5>
<a name="Unicode_Locale_Identifier_CLDR_to_BCP_47"
href="#Unicode_Locale_Identifier_CLDR_to_BCP_47">Unicode Locale Identifier: CLDR to BCP 47</a>
</h5>
<p>A Unicode CLDR locale identifier can be converted to a valid [<a
href="#BCP47">BCP47</a>] language tag (which is also a Unicode BCP 47 locale identifier) by performing the following
transformation. </p>
<ol>
<li>Replace the "_" separators with "-"</li>
<li>Replace the special language identifier "root" with the BCP
47 primary language tag "und"</li>
<li>Add an initial &quot;und&quot; primary language subtag if the first subtag is a script.</li>
</ol>
<p><em>Examples:</em></p>
<table>
<tr>
<th style='width:10em'>Unicode CLDR locale identifier</th>
<th style='width:10em'>BCP 47 language tag</th>
<th>Comments</th>
</tr>
<tr>
<td><code>en_US</code></td>
<td><code>en-US</code></td>
<td>change separator [1]</td>
</tr>
<tr>
<td><code>de_DE_u_co_phonebk</code></td>
<td><code>de-DE-u-co-phonebk</code></td>
<td>change separator [1]</td>
</tr>
<tr>
<td><code>root</code></td>
<td><code>und</code></td>
<td>change to &quot;und&quot; [2]</td>
</tr>
<tr>
<td><code>root_u_cu_usd</code></td>
<td><code>und-u-cu-usd</code></td>
<td>change to &quot;und&quot; [1, 2]</td>
</tr>
<tr>
<td><code>Latn_DE</code></td>
<td><code>und-Latn-DE</code></td>
<td>add &quot;und&quot; [1, 3]</td>
</tr>
</table><br>
<p></p>
<h5>
<a name="Unicode_Locale_Identifier_BCP_47_to_CLDR"
href="#Unicode_Locale_Identifier_BCP_47_to_CLDR">Unicode Locale Identifier: BCP 47 to CLDR</a>
</h5>
<p>A Unicode BCP 47 locale identifier can be transformed into a Unicode CLDR locale identifier by performing the following transformation.</p>
<ol>
<li>the separator is changed to &quot;_&quot;</li>
<li>the primary language subtag "und" is replaced with "root"
if no script, region, or variant subtags are present.</li>
</ol>
<p><em>Examples:</em></p>
<table>
<tr>
<th style='width:10em'>BCP 47 language tag</th>
<th style='width:10em'>Unicode CLDR locale identifier</th>
<th>Comments</th>
</tr>
<tr>
<td><code>en-US</code></td>
<td><code>en_US</code></td>
<td>changes separator [1]</td>
</tr>
<tr>
<td><code>und</code></td>
<td><code>root</code></td>
<td>changes to &quot;root&quot;, because no script, region, or variant tag is
present [2]</td>
</tr>
<tr>
<td><code>und-US</code></td>
<td><code>und_US</code></td>
<td>no change to &quot;und&quot;, because a region subtag is present [1]</td>
</tr>
<tr>
<td nowrap><code>und-u-cu-USD</code></td>
<td nowrap><code>root_u_cu_usd</code></td>
<td>changes to &quot;root&quot;, because no script, region, or variant tag is
present [1, 2]</td>
</tr>
</table>
<h3>
<a name="Field_Definitions" href="#Field_Definitions">3.4
Language Identifier Field Definitions </a>
</h3>
<p>
Unicode language and locale identifier field values are provided in
the following table. Note that some private-use BCP 47 field values
are given specific meanings in CLDR. While field values are based on
[<a href="#BCP47">BCP47</a>] subtag values, their validity status in
CLDR is specified by means of machine-readable files in the <a
href='http://unicode.org/repos/cldr/tags/latest/common/validity/'>common/validity/</a>
subdirectory, such as language.xml. For the format of those files and
more information, see <em><a href='#Validity_Data'>Section
3.11 Validity Data</a></em>.
</p>
<table>
<caption>
<a name="Language_Locale_Field_Definitions"
href="#Language_Locale_Field_Definitions">Language Identifier
Field Definitions </a>
</caption>
<tr>
<th>Field</th>
<th>Valid values</th>
</tr>
<tr>
<td><a href="#unicode_language_subtag_validity"
name="unicode_language_subtag_validity">unicode_language_subtag</a>
<p>
(also known as a <i>Unicode base language code)</i>
</p></td>
<td>Subtags in the language.xml file (see <em>Section 3.11
<a href="#Validity_Data">Validity Data</a>
</em>). These are based on [<a href="#BCP47">BCP47</a>] subtag values
marked as <b>Type: language</b>
<p>ISO 639-3 introduces the notion of
&quot;macrolanguages&quot;, where certain ISO 639-1 or ISO 639-2
codes are given broad semantics, and additional codes are given
for the narrower semantics. For backwards compatibility, Unicode
language identifiers retain use of the narrower semantics for
these codes. For example:</p>
<table border="1" cellspacing="0" cellpadding="2"
style="margin: 0.5em">
<tr>
<th>For</th>
<th>Use</th>
<th><i>Not</i></th>
</tr>
<tr>
<td>Standard Chinese (Mandarin)</td>
<td><code>zh</code></td>
<td><code>cmn</code></td>
</tr>
<tr>
<td>Standard Arabic</td>
<td><code>ar</code></td>
<td><code>arb</code></td>
</tr>
<tr>
<td>Standard Malay</td>
<td><code>ms</code></td>
<td><code>zsm</code></td>
</tr>
<tr>
<td>Standard Swahili</td>
<td><code>sw</code></td>
<td><code>swh</code></td>
</tr>
<tr>
<td>Standard Uzbek</td>
<td><code>uz</code></td>
<td><code>uzn</code></td>
</tr>
<tr>
<td>Standard Konkani</td>
<td><code>kok</code></td>
<td><code>knn</code></td>
</tr>
<tr>
<td>Northern Kurdish</td>
<td><code>ku</code></td>
<td><code>kmr</code></td>
</tr>
</table>
<p>
If a language subtag matches the type attribute of a languageAlias
element, then the replacement value is used instead. For example,
because "swh" occurs in
<tt>&lt;languageAlias type="swh" replacement="sw"/&gt;</tt>
, "sw" must be used instead of "swh". Thus Unicode language
identifiers use &quot;ar-EG&quot; for Standard Arabic (Egypt), not
&quot;arb-EG&quot;; they use &quot;zh-TW&quot; for Mandarin
Chinese (Taiwan), not &quot;cmn-TW&quot;.
</p>
<p>
The private use codes listed as <strong>excluded</strong>
in <em>Section 3.5.3 <a href="#Private_Use">Private Use Codes</a></em>
will never be given specific semantics in Unicode identifiers, and
are thus safe for use for other purposes by other applications. </p>
<p>The CLDR provides data for normalizing language/locale
codes, including mapping overlong codes like &quot;eng-840&quot;
or &quot;eng-USA&quot; to the correct code &quot;en-US&quot;;
see the
<strong><a href="https://www.unicode.org/cldr/charts/latest/supplemental/aliases.html">Aliases</a></strong>
Chart.</p>
<p>The following are special language subtags:</p>
<table class="simple" border="1" cellspacing="0" cellpadding="2">
<tr>
<td>&nbsp;</td>
<td><strong>Name</strong></td>
<td><strong>Comment</strong></td>
</tr>
<tr>
<td><code>mis</code></td>
<td>Uncoded languages</td>
<td>The content is in a language that doesn't yet have an ISO 639 code.</td>
</tr>
<tr>
<td><code>mul</code></td>
<td>Multiple languages</td>
<td>The content contains more than one language or text that is simultaneously in multiple languages (such as brand names).</td>
</tr>
<tr>
<td><code>zxx</code></td>
<td>No linguistic content</td>
<td>The content is not in any particular languages (such as images, symbols, etc.)</td>
</tr>
</table></td>
</tr>
<tr>
<td><a href="#unicode_script_subtag_validity"
name="unicode_script_subtag_validity">unicode_script_subtag</a>
<p>
(also known as a <i>Unicode script code)</i>
</p></td>
<td>Subtags in the script.xml file (see <em>Section 3.11 <a
href="#Validity_Data">Validity Data</a></em>). These are based on [<a
href="#BCP47">BCP47</a>] subtag values marked as <b>Type:
script</b>
<p>In most cases the script is not necessary, since the
language is only customarily written in a single script. Examples
of cases where it is used are:</p>
<table border="1" cellspacing="0" cellpadding="2"
style="margin: 0.5em">
<tr>
<td><code>az_Arab</code></td>
<td>Azerbaijani in Arabic script</td>
</tr>
<tr>
<td><code>az_Cyrl</code></td>
<td>Azerbaijani in Cyrillic script</td>
</tr>
<tr>
<td><code>az_Latn</code></td>
<td>Azerbaijani in Latin script</td>
</tr>
<tr>
<td><code>zh_Hans</code></td>
<td>Chinese, in simplified script (=zh, zh-Hans, zh-CN,
zh-Hans-CN)</td>
</tr>
<tr>
<td><code>zh_Hant</code></td>
<td>Chinese, in traditional script</td>
</tr>
</table>
<p>
Unicode identifiers give specific semantics to certain Unicode Script values. For more information, see also [<a
href="http://www.unicode.org/reports/tr41/#UAX24">UAX24</a>]:
</p>
<table cellspacing="0" cellpadding="2" border="1"
style="margin: 0.5em">
<tr>
<td><code>Qaag</code></td>
<td>Zawgyi</td>
<td colspan="2">Qaag is a special script code for identifying the non-standard use of Myanmar characters for display with the Zawgyi font. The purpose of the code is to enable migration to standard, interoperable use of Unicode by providing an identifier for Zawgyi for tagging text, applications, input methods, font tables, transformations, and other mechanisms used for migration.</td>
</tr>
<tr>
<td><code>Qaai</code></td>
<td>Inherited</td>
<td colspan="2"><strong>deprecated</strong>: the <em>canonicalized</em>
form is Zinh</td>
</tr>
<tr>
<td><code>Zinh</code></td>
<td>Inherited</td>
<td colspan="2">&nbsp;</td>
</tr>
<tr>
<td><code>Zsye</code></td>
<td>Emoji Style</td>
<td colspan="2">Prefer emoji style for characters that have both text
and emoji styles available.</td>
</tr>
<tr>
<td><code>Zsym</code></td>
<td>Text Style</td>
<td colspan="2">Prefer text style for characters that have both text and
emoji styles available.</td>
</tr>
<tr>
<td rowspan="7"><code>Zxxx</code></td>
<td rowspan="7">Unwritten</td>
<td colspan="2">Indicates spoken or otherwise unwritten content. For example:</td>
</tr>
<tr>
<th>Sample(s)</th>
<th>Description</th>
</tr>
<tr>
<td>uz</td>
<td>either written or spoken content</td>
</tr>
<tr>
<td>uz-Latn <em>or</em> uz-Arab</td>
<td>written-only content (particular script)</td>
</tr>
<tr>
<td>uz-Zyyy</td>
<td>written-only content (unspecified script)</td>
</tr>
<tr>
<td>uz-Zxxx</td>
<td>spoken-only content</td>
</tr>
<tr>
<td>uz-Latn, uz-Zxxx</td>
<td>both specific written and spoken content (using a <em>language list</em>)</td>
</tr>
<tr>
<td><code>Zyyy</code></td>
<td>Common</td>
<td colspan="2">&nbsp;</td>
</tr>
<tr>
<td><code>Zzzz</code></td>
<td>Unknown</td>
<td colspan="2">&nbsp;</td>
</tr>
</table>
<p>The private use subtags listed as <strong>excluded</strong> in <em>Section 3.5.3 <a href="#Private_Use">Private Use Codes</a></em> will never be given
specific semantics in Unicode identifiers, and are thus safe for
use for other purposes by other applications.</p></td>
</tr>
<tr>
<td><a href="#unicode_region_subtag_validity"
name="unicode_region_subtag_validity">unicode_region_subtag</a>
<p>
(also known as a <i>Unicode region code, </i>or<i> a Unicode
territory code)</i>
</p></td>
<td>Subtags in the region.xml file (see<em> Section 3.11 <a
href="#Validity_Data">Validity Data</a></em>). These are based on [<a
href="#BCP47">BCP47</a>] subtag values marked as <b>Type:
region</b>
<p>Unicode identifiers give specific semantics to the following
subtags:</p>
<table border="1" cellspacing="0" cellpadding="2">
<tr>
<td>&nbsp;</td>
<td><strong>Name</strong></td>
<td><strong>Comment</strong></td>
<td><strong> ISO 3166-1 status</strong></td>
</tr>
<tr>
<td><code>QO</code></td>
<td>Outlying Oceania</td>
<td>countries in Oceania [009] that do not have a <a
href="http://www.unicode.org/cldr/charts/latest/supplemental/territory_containment_un_m_49.html">subcontinent</a>.
</td>
<td>private use</td>
</tr>
<tr>
<td><code>QU</code></td>
<td>European Union</td>
<td><strong>deprecated</strong>: the <em>canonicalized</em>
form is EU</td>
<td>private use</td>
</tr>
<tr>
<td><code>UK</code></td>
<td>United Kingdom</td>
<td><strong>deprecated</strong>: the <em>canonicalized</em>
form is GB</td>
<td>exceptionally reserved</td>
</tr>
<tr>
<td><code>XA</code></td>
<td>Pseudo-Accents</td>
<td>special code indicating derived testing locale with English + added accents and lengthened</td>
<td>private use</td>
</tr>
<tr>
<td><code>XB</code></td>
<td>Pseudo-Bidi</td>
<td>special code indicating derived testing locale with forced RTL English</td>
<td>private use</td>
</tr>
<tr>
<td><code>XK</code></td>
<td>Kosovo</td>
<td>industry practice</td>
<td>private use</td>
</tr>
<tr>
<td><code>ZZ</code></td>
<td>Unknown or Invalid Territory</td>
<td>used in APIs or as replacement for invalid code</td>
<td>private use</td>
</tr>
</table>
<p>The private use subtags listed as <strong>excluded</strong> in <em>Section 3.5.3 <a href="#Private_Use">Private Use Codes</a></em> will normally never be
given specific semantics in Unicode identifiers, and are thus safe
for use for other purposes by other applications. However, LDML
may follow widespread industry practice in the use of some of
these codes, such as for XK.</p>
<p>The CLDR provides data for normalizing territory/region
codes, including mapping overlong codes like &quot;eng-840&quot;
or &quot;eng-USA&quot; to the correct code &quot;en-US&quot;.</p>
<p>Special Codes:</p>
<ul>
<li>The territory code 'UK' has a special status in ISO, and
is used for the domain name instead of GB. It is thus recognized
by CLDR as being an alternate (unnormalized) form of 'GB'.</li>
<li>The territory code '001' (the World) is used to indicate
a standardized form, such as &quot;ar-001&quot; for Modern
Standard Arabic.</li>
</ul></td>
</tr>
<tr>
<td><a href="#unicode_variant_subtag_validity"
name="unicode_variant_subtag_validity">unicode_variant_subtag</a>
<p>
(also known as a <i>Unicode language variant code)</i>
</p></td>
<td>Subtags in the variant.xml file (see<em> Section 3.11
<a href="#Validity_Data">Validity Data</a>
</em>). These are based on [<a href="#BCP47">BCP47</a>] subtag values
marked as <b>Type: variant</b>
<p>
CLDR provides data for normalizing variant codes. About handling
of the "POSIX" variant see <i>Section 3.8.2, <a
href="#Legacy_Variants">Legacy Variants</a></i>.
</p></td>
</tr>
</table>
<p>
<i>Examples:</i>
</p>
<blockquote>
<pre>en
fr_BE
zh-Hant-HK</pre>
</blockquote>
<p>
<em>Deprecated</em> codes—such as QU above—are valid, but strongly
discouraged.
</p>
<p>
A locale that only has a language subtag (and optionally a script
subtag) is called a <i>language locale</i>; one with both language
and territory subtag is called a <i>territory locale</i> (or <i>country
locale</i>).
</p>
<h3>
<a name="Special_Codes" href="#Special_Codes">3.5 Special Codes</a>
</h3>
<h4>
<a name="Unknown_or_Invalid_Identifiers"
href="#Unknown_or_Invalid_Identifiers">3.5.1 Unknown or Invalid
Identifiers</a>
</h4>
<p>The following identifiers are used to indicate an unknown or
invalid code in Unicode language and locale identifiers. For Unicode
identifiers, the region code uses a private use ISO 3166 code, and
Time Zone code uses an additional code; the others are defined by the
relevant standards. When these codes are used in APIs connected with
Unicode identifiers, the meaning is that either there was no
identifier available, or that at some point an input identifier value
was determined to be invalid or ill-formed.</p>
<table border="1" cellspacing="0" cellpadding="4"
style="margin-top: 0.5em; margin-bottom: 0.5em" id="table4">
<tr>
<th>Code Type</th>
<th>Value</th>
<th>Description in Referenced Standards</th>
</tr>
<tr>
<td>Language</td>
<td><code>und</code></td>
<td>Undetermined language, also used for “root”</td>
</tr>
<tr>
<td>Script</td>
<td><code>Zzzz</code></td>
<td>Code for uncoded script, Unknown [<a
href="http://www.unicode.org/reports/tr41/#UAX24">UAX24</a>]
</td>
</tr>
<tr>
<td>Region&nbsp;&nbsp;</td>
<td><code>ZZ</code></td>
<td>Unknown or Invalid Territory</td>
</tr>
<tr>
<td>Currency</td>
<td><code>XXX</code></td>
<td>The codes assigned for transactions where no currency is
involved</td>
</tr>
<tr>
<td>Time Zone</td>
<td><code>unk</code></td>
<td>Unknown or Invalid Time Zone</td>
</tr>
<tr>
<td>Subdivision</td>
<td><em>&lt;region&gt;</em>zzzz</td>
<td>Unknown or Invalid Subdivision</td>
</tr>
</table>
<p>When only the script or region are known, then a locale ID will
use &quot;und&quot; as the language subtag portion. Thus the locale
tag &quot;und_Grek&quot; represents the Greek script;
&quot;und_US&quot; represents the US territory.</p>
<h4>
<a name="Numeric_Codes" href="#Numeric_Codes">3.5.2 Numeric Codes</a>
</h4>
<p>For region codes, ISO and the UN establish a mapping to
three-letter codes and numeric codes. However, this does not extend
to the private use codes, which are the codes 900-999 (total: 100),
and AAA, QMA-QZZ, XAA-XZZ, and ZZZ (total: 1092). Unicode identifiers
supply a standard mapping to these: for the numeric codes, it uses
the top of the numeric private use range; for the 3-letter codes it
doubles the final letter. These are the resulting mappings for all of
the private use region codes:</p>
<table border="1" cellspacing="0" cellpadding="4"
style="margin-top: 0.5em; margin-bottom: 0.5em" id="table19">
<tr>
<th>Region</th>
<th>UN/ISO Numeric</th>
<th>ISO 3-Letter</th>
</tr>
<tr>
<td><code>AA</code></td>
<td><code>958</code></td>
<td><code>AAA</code></td>
</tr>
<tr>
<td><code>QM..QZ</code></td>
<td><code>959..972</code></td>
<td><code>QMM..QZZ</code></td>
</tr>
<tr>
<td><code>XA..XZ</code></td>
<td><code>973..998</code></td>
<td><code>XAA..XZZ</code></td>
</tr>
<tr>
<td><code>ZZ</code></td>
<td><code>999</code></td>
<td><code>ZZZ</code></td>
</tr>
</table>
<p>For script codes, ISO 15924 supplies a mapping (however, the
numeric codes are not in common use):</p>
<table border="1" cellspacing="0" cellpadding="4"
style="margin-top: 0.5em; margin-bottom: 0.5em" id="table21">
<tr>
<th>Script</th>
<th>Numeric</th>
</tr>
<tr>
<td><code>Qaaa..Qabx</code></td>
<td><code>900..949</code></td>
</tr>
</table>
<br>
<h4>
3.5.3 <a name="Private_Use" href="#Private_Use">Private Use Codes</a>
</h4>
<p>Private use codes fall into three groups.</p>
<ul>
<li><strong>defined:</strong> those that are given particular
semantics currently in CLDR</li>
<li><strong>reserved:</strong> those that may be given
particular semantics in future versions of CLDR</li>
<li><strong>excluded:</strong> those that will never be given
particular CLDR semantics in the future, and thus can normally be
used by applications without worrying about collisions. However,
CLDR may follow widespread industry practice in the use of some of
these codes, such as for XA, XB, and XK.</li>
</ul>
<table>
<caption>
<a name="Private_Use_CLDR" href="#Private_Use_CLDR">Private Use
Codes in CLDR</a>
</caption>
<tr>
<th>category</th>
<th>status</th>
<th>codes</th>
</tr>
<tr>
<td rowspan="3">base language</td>
<td>defined</td>
<td>none</td>
</tr>
<tr>
<td>reserved</td>
<td>qaa..qfy</td>
</tr>
<tr>
<td>excluded</td>
<td>qfz..qtz</td>
</tr>
<tr>
<td rowspan="3">script</td>
<td>defined</td>
<td>Qaai (obsolete), Qaag</td>
</tr>
<tr>
<td>reserved</td>
<td>Qaaa..Qaaf Qaah Qaaj..Qaap</td>
</tr>
<tr>
<td>excluded</td>
<td>Qaaq..Qabx</td>
</tr>
<tr>
<td rowspan="3">region</td>
<td>defined</td>
<td>QO, QU, UK, XA, XB, XK, ZZ</td>
</tr>
<tr>
<td>reserved</td>
<td>AA QM..QN QP..QT QV..QZ</td>
</tr>
<tr>
<td>excluded</td>
<td>XC..XJ, XL..XZ</td>
</tr>
<tr>
<td rowspan="3">timezone</td>
<td>defined</td>
<td>IANA: Etc/Unknown<br>
bcp47: as listed in bcp47/timezone.xml
</td>
</tr>
<tr>
<td>reserved</td>
<td>bcp47: all non-5 letter codes not starting with x</td>
</tr>
<tr>
<td>excluded</td>
<td>bcp47: all non-5 letter codes starting with x</td>
</tr>
</table>
<p>
See also <em>Section 3.5.1 <a
href="#Unknown_or_Invalid_Identifiers">Unknown or Invalid
Identifiers</a></em>.
</p>
<p></p>
<h3>
<a name="Locale_Extension_Key_and_Type_Data"></a><a
name="u_Extension" href="#u_Extension">3.6 Unicode BCP 47 U
Extension</a>
</h3>
<p>
[<a href="#BCP47">BCP47</a>] Language Tags provides a mechanism for
extending language tags for use in various applications by extension
subtags. Each extension subtag is identified by a single alphanumeric
character subtag assigned by IANA.
</p>
<p>
The Unicode Consortium has registered and is the maintaining
authority for two BCP 47 language tag extensions: the extension 'u'
for Unicode locale extension [<a href="#RFC6067">RFC6067</a>] and
extension 't' for transformed content [<a href="#RFC6497">RFC6497</a>].
The Unicode BCP 47 extension data defines the complete list of valid
subtags.
</p>
<p>
These subtags are all in lowercase (that is the canonical casing for
these subtags), however, subtags are case-insensitive and casing does
not carry any specific meaning. All subtags within the Unicode
extensions are alphanumeric characters in length of two to eight that
meet the rule
<code>extension</code>
in the [<a href="#BCP47">BCP47</a>]
</p>
<p>
<strong>The -u- Extension.</strong> The syntax of 'u' extension
subtags is defined by the rule
<code>unicode_locale_extensions</code>
in <a href="#Unicode_locale_identifier">Section 3.2 Unicode
locale identifier</a>, except the separator of subtags
<code>sep</code>
must be always hyphen '-' when the extension is used as a part of BCP
47 language tag.
</p>
<p>
A 'u' extension may contain multiple
<code>attribute</code>
s or
<code>keyword</code>
s as defined in <a href="#Unicode_locale_identifier">Section 3.2
Unicode locale identifier</a>. Although the order of
<code>attribute</code>
s or
<code>keyword</code>
s does not matter, this specification defines the canonical form as
below:
</p>
<ul>
<li>All attributes are sorted in alphabetical order.</li>
<li>All keywords are sorted by alphabetical order of keys.</li>
<li>All keywords are in lowercase.</li>
<li>All keys and types use the canonical form (from the name
attribute; see <a href="#Unicode_Locale_Extension_Data_Files">Section
3.6.4 U Extension Data Files</a>).
</li>
<li>Type value "true" is removed.</li>
</ul>
<p>For example, the canonical form of 'u' extension
"u-foo-bar-nu-thai-ca-buddhist-kk-true" is
"u-bar-foo-ca-buddhist-kk-nu-thai". The attributes "foo" and "bar" in
this example are provided only for illustration; no attribute subtags
are defined by the current CLDR specification.</p>
<p>
<em>See also <a
href="http://cldr.unicode.org/index/bcp47-extension"> Unicode
Extensions for BCP 47</a> on the CLDR site.
</em>
</p>
<h4>
<a href="#Key_And_Type_Definitions_" name="Key_And_Type_Definitions_">3.6.1
Key And Type Definitions</a>
</h4>
<p>The following chart contains a set of U extension key values
that are currently available, with a description or sampling of the U
extension type values. Each category is associated with an XML file
in the bcp47 directory.</p>
<p>
For the complete list of valid keys and types defined for Unicode
locale extensions, see <a href="#Unicode_Locale_Extension_Data_Files">Section
3.6.4 U Extension Data Files</a>. For information on the process for
adding new <i>key</i>/<i>type</i>, see [<a href="#localeProject">LocaleProject</a>].
</p>
<p>
Most type values are represented by a single subtag in the current
version of CLDR. There are exceptions, such as types used for key
"ca" (calendar) and "kr" (collation reordering). If the type is not
included, then the type value "true" is assumed. Note that the
default for key with a possible &quot;true&quot; value is often
&quot;false&quot;, but may not always be. Note also that
"true"/"True" is not a valid script code, since <a
href="http://www.unicode.org/iso15924/codelists.html">the ISO
15924 Registration Authority has exceptionally reserved it</a>, which
means that it will not be assigned for any purpose.
</p>
<p>The BCP 47 form for keys and types is the canonical form, and
recommended. Other aliases are included for backwards compatibility.
</p>
<table>
<caption>
<a name="Key_Type_Definitions" href="#Key_Type_Definitions">Key/Type
Definitions</a>
</caption>
<tr>
<th>key<br> (old key name)
</th>
<th>key description</th>
<th>example type<br> (old type name)
</th>
<th>type description</th>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeCalendarIdentifier" name="UnicodeCalendarIdentifier">Unicode
Calendar Identifier</a> defines a type of calendar. The valid values
are those <em>name</em> attribute values in the <em>type</em>
elements of key name="ca" in bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml">calendar.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="10">"ca"<br> (calendar)
</td>
<td rowspan="10">Calendar algorithm<br> <br> <i>(For
information on the calendar algorithms associated with the data
used with these, see [<a href="#Calendars">Calendars</a>].)
</i></td>
<td>"buddhist"</td>
<td>Thai Buddhist calendar (same as Gregorian except for the
year)</td>
</tr>
<tr>
<td>"chinese"</td>
<td>Traditional Chinese calendar</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td>"gregory"<br> (gregorian)
</td>
<td>Gregorian calendar</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td>"islamic"</td>
<td>Islamic calendar</td>
</tr>
<tr>
<td>"islamic-civil"</td>
<td>Islamic calendar, tabular (intercalary years
[2,5,7,10,13,16,18,21,24,26,29] - civil epoch)</td>
</tr>
<tr>
<td>"islamic-umalqura"</td>
<td>Islamic calendar, Umm al-Qura</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td colspan="2"><b>Note:</b> <i>Some calendar types are
represented by two subtags. In such cases, the first subtag
specifies a generic calendar type and the second subtag specifies
a calendar algorithm variant. The CLDR uses generic calendar types
(single subtag types) for tagging data when calendar algorithm
variations within a generic calendar type are irrelevant. For
example, type "islamic" is used for specifying Islamic calendar
formatting data for all Islamic calendar types, including
"islamic-civil" and "islamic-umalqura".</i></td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeCurrencyFormatIdentifier"
name="UnicodeCurrencyFormatIdentifier">Unicode Currency Format
Identifier</a> defines a style for currency formatting. The valid
values are those <em>name</em> attribute values in the <em>type</em>
elements of key name="cf" in bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/currency.xml">currency.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="2">"cf"</td>
<td rowspan="2">Currency Format style</td>
<td>"standard"</td>
<td>Negative numbers use the minusSign symbol (the default).</td>
</tr>
<tr>
<td>"account"</td>
<td>Negative numbers use parentheses or equivalent.</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeCollationIdentifier"
name="UnicodeCollationIdentifier">Unicode Collation Identifier</a>
defines a type of collation (sort order). The valid values are
those <em>name</em> attribute values in the <em>type</em> elements
of bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/collation.xml">collation.xml</a></strong>.</td>
</tr>
<tr>
<td colspan="4"><i>For information on each collation
setting parameter, from <strong>ka</strong> to <strong>vt</strong>,
see <a href="tr35-collation.html#Setting_Options">Setting
Options</a>
</i></td>
</tr>
<tr>
<td rowspan="9">"co"<br> (collation)
</td>
<td rowspan="9">Collation type</td>
<td>"standard"</td>
<td>The default ordering for each language. For root it is
based on the [<a href="#DUCET">DUCET</a>] (Default Unicode
Collation Element Table): see <em><a
href="tr35-collation.html#Root_Collation">Root Collation</a></em>. Each
other locale is based on that, except for appropriate modifications
to certain characters for that language.
</td>
</tr>
<tr>
<td>"search"</td>
<td>A special collation type dedicated for string search—it is
not used to determine the relative order of two strings, but only
to determine whether they should be considered equivalent for the
specified strength, using the string search matching rules
appropriate for the language. Compared to the normal collator for
the language, this may add or remove primary equivalences, may make
additional characters ignorable or change secondary equivalences,
and may modify contractions to allow matching within them,
depending on the desired behavior. For example, in Czech, the
distinction between ‘a’ and ‘á’ is secondary for normal collation,
but primary for search; a search for ‘a’ should never match ‘á’ and
vice versa. A search collator is normally used with strength set to
PRIMARY or SECONDARY (should be SECONDARY if using “asymmetric”
search as described in the [<a
href="http://www.unicode.org/reports/tr41/#UTS10">UCA</a>] section
Asymmetric Search). The search collator in root supplies matching
rules that are appropriate for most languages (and which are
different than the root collation behavior); language-specific
search collators may be provided to override the matching rules for
a given language as necessary.
</td>
</tr>
<tr>
<td colspan="2"><p>
Other keywords provide additional choices for certain locales; <i>they
only have effect in certain locales.</i>
</p></td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td>"phonetic"</td>
<td>Requests a phonetic variant if available, where text is
sorted based on pronunciation. It may interleave different scripts,
if multiple scripts are in common use.</td>
</tr>
<tr>
<td>"pinyin"</td>
<td>Pinyin ordering for Latin and for CJK characters; that is,
an ordering for CJK characters based on a character-by-character
transliteration into a pinyin. (used in Chinese)</td>
</tr>
<tr>
<td>"reformed"</td>
<td>Reformed collation (such as in Swedish)</td>
</tr>
<tr>
<td>"searchjl"</td>
<td>Special collation type for a modified string search in
which a pattern consisting of a sequence of Hangul initial
consonants (jamo lead consonants) will match a sequence of Hangul
syllable characters whose initial consonants match the pattern. The
jamo lead consonants can be represented using conjoining or
compatibility jamo. This search collator is best used at SECONDARY
strength with an "asymmetric" search as described in the [<a
href="http://www.unicode.org/reports/tr41/#UTS10">UCA</a>] section
Asymmetric Search and obtained, for example, using ICU4C's usearch
facility with attribute USEARCH_ELEMENT_COMPARISON set to value
USEARCH_PATTERN_BASE_WEIGHT_IS_WILDCARD; this ensures that a full
Hangul syllable in the search pattern will only match the same
syllable in the searched text (instead of matching any syllable
with the same initial consonant), while a Hangul initial consonant
in the search pattern will match any Hangul syllable in the
searched text with the same initial consonant.
</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeCurrencyIdentifier" name="UnicodeCurrencyIdentifier">Unicode
Currency Identifier</a> defines a type of currency. The valid values
are those <em>name</em> attribute values in the <em>type</em>
elements of key name="cu" in bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/currency.xml">currency.xml</a>.
</strong></td>
</tr>
<tr>
<td>"cu"<br> (currency)
</td>
<td>Currency type</td>
<td><i>ISO 4217 code,</i>
<p>
<i>plus others in common use</i>
</p></td>
<td><p>
Codes consisting of 3 ASCII letters that are or have been valid in
ISO 4217, plus certain additional codes that are or have been in
common use. The list of countries and time periods associated with
each currency value is available in <a
href="tr35-numbers.html#Supplemental_Currency_Data">Supplemental
Currency Data</a>, plus the default number of decimals.
</p>
<p>
The XXX code is given a broader interpretation as <em>Unknown
or Invalid Currency</em>.
</p></td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeEmojiPresentationStyleIdentifier" name="UnicodeEmojiPresentationStyleIdentifier">Unicode
Emoji Presentation Style Identifier</a> specifies a request for
the preferred emoji presentation style. This can be used as part of
the value for an HTML lang attribute, for example
<code>&lt;html lang=&quot;sr-Latn-u-em-emoji&quot;&gt;</code>.
The valid values are those <em>name</em> attribute values
in the <em>type</em> elements of key name="em" in bcp47/<a
target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/variant.xml">variant.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="3">"em"</td>
<td rowspan="3">Emoji presentation style</td>
<td>"emoji"</td>
<td>Use an emoji presentation for emoji characters if possible.</td>
</tr>
<tr>
<td>"text"</td>
<td>Use a text presentation for emoji characters if possible.</td>
</tr>
<tr>
<td>"default"</td>
<td>Use the default presentation for emoji characters as specified in UTR #51 Section 4,
<a href="http://www.unicode.org/reports/tr51/#Presentation_Style">Presentation Style</a>.</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeFirstDayIdentifier" name="UnicodeFirstDayIdentifier">Unicode
First Day Identifier</a> defines the preferred first day of the week
for calendar display. Specifying "fw" in a locale identifier
overrides the default value specified by supplemental week data
(see Part 4 Dates, section 4.3 <a href="tr35-dates.html#Week_Data">Week
Data</a>). The valid values are those <em>name</em> attribute values
in the <em>type</em> elements of key name="fw" in bcp47/<a
target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml">calendar.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="4">"fw"</td>
<td rowspan="4">First day of week</td>
<td>"sun"</td>
<td>Sunday</td>
</tr>
<tr>
<td>"mon"</td>
<td>Monday</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td>"sat"</td>
<td>Saturday</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeHourCycleIdentifier"
name="UnicodeHourCycleIdentifier">Unicode Hour Cycle
Identifier</a> defines the preferred time cycle. Specifying "hc" in a
locale identifier overrides the the default value specified by
supplemental time data (see Part 4 Dates, section 4.4 <a
href="tr35-dates.html#Time_Data">Time Data</a>). The valid values
are those <em>name</em> attribute values in the <em>type</em>
elements of key name="hc" in bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/calendar.xml">calendar.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="4">"hc"</td>
<td rowspan="4">Hour cycle</td>
<td>"h12"</td>
<td>Hour system using 1–12; corresponds to 'h' in patterns</td>
</tr>
<tr>
<td>"h23"</td>
<td>Hour system using 0–23; corresponds to 'H' in patterns</td>
</tr>
<tr>
<td>"h11"</td>
<td>Hour system using 0–11; corresponds to 'K' in patterns</td>
</tr>
<tr>
<td>"h24"</td>
<td>Hour system using 1–24; corresponds to 'k' in pattern</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeLineBreakStyleIdentifier"
name="UnicodeLineBreakStyleIdentifier">Unicode Line Break
Style Identifier</a> defines a preferred line break style
corresponding to the CSS level 3 <a
href="https://drafts.csswg.org/css-text/#line-break-property">line-break
option</a>. Specifying "lb" in a locale identifier overrides the
locale‘s default style (which may correspond to "normal" or
"strict"). The valid values are those <em>name</em> attribute
values in the <em>type</em> elements of key name="lb" in bcp47/<a
target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/segmentation.xml">segmentation.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="3">"lb"</td>
<td rowspan="3">Line break style</td>
<td>"strict"</td>
<td>CSS level 3 line-break=strict, e.g. treat CJ as NS</td>
</tr>
<tr>
<td>"normal"</td>
<td>CSS level 3 line-break=normal, e.g. treat CJ as ID, break
before hyphens for ja,zh</td>
</tr>
<tr>
<td>"loose"</td>
<td>CSS lev 3 line-break=loose</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeLineBreakWordIdentifier"
name="UnicodeLineBreakWordIdentifier">Unicode Line Break Word
Identifier</a> defines preferred line break word handling behavior
corresponding to the CSS level 3 <a
href="https://drafts.csswg.org/css-text/#word-break-property">word-break
option</a>. The valid values are those <em>name</em> attribute values
in the <em>type</em> elements of key name="lw" in bcp47/<a
target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/segmentation.xml">segmentation.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="3">"lw"</td>
<td rowspan="3">Line break word handling</td>
<td>"normal"</td>
<td>CSS level 3 word-break=normal, normal script/language
behavior for midword breaks</td>
</tr>
<tr>
<td>"breakall"</td>
<td>CSS level 3 word-break=break-all, allow midword breaks
unless forbidden by lb setting</td>
</tr>
<tr>
<td>"keepall"</td>
<td>CSS level 3 word-break=keep-all, prohibit midword breaks
except for dictionary breaks</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeMeasurementSystemIdentifier"
name="UnicodeMeasurementSystemIdentifier">Unicode Measurement
System Identifier</a> defines a preferred measurement system.
Specifying "ms" in a locale identifier overrides the default value
specified by supplemental measurement system data (see Part 2
General, section 5 <a
href="tr35-general.html#Measurement_System_Data">Measurement
System Data</a>). The valid values are those <em>name</em> attribute
values in the <em>type</em> elements of key name="ms" in bcp47/<a
target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/measure.xml">measure.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="3">"ms"</td>
<td rowspan="3">Measurement system</td>
<td>"metric"</td>
<td>Metric System</td>
</tr>
<tr>
<td>"ussystem"</td>
<td>US System of measurement: feet, pints, etc.; pints are 16oz</td>
</tr>
<tr>
<td>"uksystem"</td>
<td>UK System of measurement: feet, pints, etc.; pints are 20oz</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeNumberSystemIdentifier"
name="UnicodeNumberSystemIdentifier">Unicode Number System
Identifier</a> defines a type of number system. The valid values are
those <em>name</em> attribute values in the <em>type</em> elements
of bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/number.xml">number.xml</a>.
</strong></td>
</tr>
<tr>
<td rowspan="7">"nu"<br> (numbers)
</td>
<td rowspan="7">Numbering system</td>
<td><i>Unicode script subtag</i></td>
<td><p>
Four-letter types indicating the primary numbering system for the
corresponding script represented in Unicode. Unless otherwise
specified, it is a decimal numbering system using digits
[:GeneralCategory=Nd:]. For example, &quot;latn&quot; refers to
the ASCII / Western digits 0-9, while &quot;taml&quot; is an
algorithmic (non-decimal) numbering system. (The code "tamldec" is
indicates the "modern Tamil decimal digits".)<br>
</p>
<p class="note">
For more information, see <a
href="tr35-numbers.html#Numbering_Systems">Numbering Systems</a>.
</p></td>
</tr>
<tr>
<td>"arabext"</td>
<td>Extended Arabic-Indic digits ("arab" means the base
Arabic-Indic digits)</td>
</tr>
<tr>
<td>"armnlow"</td>
<td>Armenian lowercase numerals</td>
</tr>
<tr>
<td colspan="2">…</td>
</tr>
<tr>
<td>"roman"</td>
<td>Roman numerals</td>
</tr>
<tr>
<td>"romanlow"</td>
<td>Roman lowercase numerals</td>
</tr>
<tr>
<td>"tamldec"</td>
<td>Modern Tamil decimal digits</td>
</tr>
<tr>
<td colspan="4"><strong>A <a href="#RegionOverride"
name="RegionOverride">Region Override</a> specifies an alternate
region to use for obtaining certain region-specific default values
(those specified by the <a href="tr35-info.html#rgScope">&lt;rgScope&gt;</a>
element), instead of using the region specified by the <a
href="#unicode_region_subtag">unicode_region_subtag</a> in the
Unicode Language Identifier (or inferred from the <a
href="#unicode_language_subtag">unicode_language_subtag</a>).
</strong></td>
</tr>
<tr>
<td rowspan="2">"rg"</td>
<td rowspan="2">Region Override</td>
<td>&quot;uszzzz&quot;<br> <br></td>
<td rowspan="2">The value is a <a href="#unicode_region_subtag">unicode_region_subtag</a>
for a regular region (not a macroregion), suffixed by "ZZZZ" (case
is not significant). For example, “en-GB-u-rg-uszzzz” represents a
locale for British English but with region-specific defaults set to
US for items such as default currency, default calendar and week
data, default time cycle, and default measurement system and unit
preferences.
</td>
</tr>
<tr>
<td>…</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
name="unicode_subdivision_subtag_validity"></a><a
href="#UnicodeSubdivisionIdentifier"
name="UnicodeSubdivisionIdentifier">Unicode Subdivision
Identifier</a> defines a regional subdivision used for locales. The
valid values are based on the <em>subdivisionContainment</em>
element as described in <em>Section <a
href="#Unicode_Subdivision_Codes">3.6.5 Subdivision Codes</a></em>.
</strong></td>
</tr>
<tr>
<td rowspan="2">"sd"</td>
<td rowspan="2">Regional Subdivision</td>
<td>&quot;gbsct&quot;<br> <br></td>
<td rowspan="2">A <a href="#unicode_subdivision_id">unicode_subdivision_id</a>, which is
a <a href="#unicode_region_subtag">unicode_region_subtag</a>concatenated
with a unicode_subdivision_suffix.<br> For example, <em>gbsct</em> is “gb”+“sct” (where sct
represents the subdivision code for Scotland). Thus
“en-GB-u-sd-gbsct” represents the language variant “English as used
in Scotland”. And both “en-u-sd-usca” and “en-US-u-sd-usca”
represent “English as used in California”. See
<strong><em><a href="#Unicode_Subdivision_Codes">3.6.5
Subdivision Codes</a></em></strong>.
</td>
</tr>
<tr>
<td>…</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeSentenceBreakSuppressionsIdentifier"
name="UnicodeSentenceBreakSuppressionsIdentifier">Unicode
Sentence Break Suppressions Identifier</a> defines a set of data to
be used for suppressing certain sentence breaks that would
otherwise be found by UAX #14 rules. The valid values are those <em>name</em>
attribute values in the <em>type</em> elements of key name="ss" in
bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/segmentation.xml">segmentation.xml</a></strong>.</td>
</tr>
<tr>
<td rowspan="2">"ss"</td>
<td rowspan="2">Sentence break suppressions</td>
<td>"none"</td>
<td>Don’t use sentence break suppressions data (the default).</td>
</tr>
<tr>
<td>"standard"</td>
<td>Use sentence break suppressions data of type "standard"</td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeTimezoneIdentifier" name="UnicodeTimezoneIdentifier">Unicode
Timezone Identifier</a> defines a timezone. The valid values are
those name attribute values in the <em>type</em> elements of
bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/timezone.xml">timezone.xml</a>.
</strong></td>
</tr>
<tr>
<td>"tz"<br> (timezone)
</td>
<td>Time zone</td>
<td><i>Unicode short time zone IDs</i></td>
<td><p>
Short identifiers defined in terms of a TZ time zone database [<a
href="#Olson">Olson</a>] identifier in the file
common/bcp47/timezone.xml file, plus a few extra values.
</p>
<p>
For more information, see <a href="#Time_Zone_Identifiers">Section
3.7.1.2 Time Zone Identifiers</a>.
</p>
<p>CLDR provides data for normalizing timezone codes.</p></td>
</tr>
<tr>
<td colspan="4"><strong>A <a
href="#UnicodeVariantIdentifier" name="UnicodeVariantIdentifier">Unicode
Variant Identifier</a> defines a special variant used for locales.
The valid values are those name attribute values in the <em>type</em>
elements of bcp47/<a target="_blank"
href="http://www.unicode.org/repos/cldr/tags/latest/common/bcp47/variant.xml">variant.xml</a>.
</strong></td>
</tr>
<tr>
<td>"va"</td>
<td>Common variant type</td>
<td>"posix"</td>
<td>POSIX style locale variant. About handling of the "POSIX"
variant see <i>Section 3.8.2, <a href="#Legacy_Variants">Legacy
Variants</a></i>.
</td>
</tr>
</table>
<p>
For more information on the allowed keys and types, see the specific
elements below, and <a href="#Unicode_Locale_Extension_Data_Files">Section
3.6.4 U Extension Data Files</a>.
</p>
<p>Additional keys or types might be added in future versions.
Implementations of LDML should be robust to handle any syntactically
valid key or type values.</p>
<h4>
<a href="#Numbering System Data" name="Numbering System Data">3.6.2
Numbering System Data </a>
</h4>
<p>
LDML supports multiple numbering systems. The identifiers for those
numbering systems are defined in the file <strong>bcp47/number.xml</strong>.
For example, for the 'trunk' version of the data see <a
href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/number.xml">bcp47/number.xml</a>.<br>
</p>
<p>
Details about those numbering systems are defined in <strong>supplemental/numberingSystems.xml</strong>.
For example, for the 'trunk' version of the data see <a
href="http://unicode.org/repos/cldr/tags/latest/common/supplemental/numberingSystems.xml">supplemental/numberingSystems.xml</a>.<br>
</p>
<p>
LDML makes certain stability guarantees on this data: <br>
</p>
<ol>
<li>Like other BCP 47 identifiers, once a numeric identifier is
added to <strong>bcp47/number.xml</strong> or <strong>numberingSystems.xml</strong>,
it will never be removed from either of those files.
</li>
<li>If an identifier has type="numeric" in numberingSystems.xml,
then
<ol>
<li>It is a decimal, positional numbering system with an
attribute digits=X, where X is a string with the 10 digits in
order used by the numbering system.</li>
<li>The values of the type and digits will never change.</li>
</ol>
</li>
</ol>
<h4>
<a href="#Time_Zone_Identifiers" name="Time_Zone_Identifiers">3.6.3
Time Zone Identifiers</a>
</h4>
<p>
LDML inherits time zone IDs from the tz database [<a href="#Olson">Olson</a>].
Because these IDs from the tz database do not satisfy the BCP 47
language subtag syntax requirements, CLDR defines short identifiers
for the use in the Unicode locale extension. The short identifiers
are defined in the file <strong>common/bcp47/timezone.xml</strong>.
</p>
<p>
The short identifiers use UN/LOCODE [<a href="#LOCODE">LOCODE</a>]
(excluding a space character) codes where possible. For example, the
short identifier for "America/Los_Angeles" is "uslax" (the LOCODE for
Los Angeles, US is "US LAX"). Identifiers of length not equal to 5
are used where there is no corresponding UN/LOCODE, such as
"usnavajo" for "America/Shiprock", or "utcw01" for "Etc/GMT+1", so
that they do not overlap with future UN/LOCODE.
</p>
<p>Although the first two letters of a short identifier may match
an ISO 3166 two-letter country code, a user should not assume that
the time zone belongs to the country. The first two letters in an
identifier of length not equal to 5 has no meaning. Also, the
identifiers are stabilized, meaning that they will not change no
matter what changes happen in the base standard. So if Hawaii leaves
the US and joins Canada as a new province, the short time zone
identifier "ushnl" would not change in CLDR even if the UN/LOCODE
changes to "cahnl" or something else.</p>
<p>There is a special code "unk" for an Unknown or Invalid time
zone. This can be expressed in the tz database style ID
"Etc/Unknown", although it is not defined in the tz database.</p>
<p>
<b>Stability of Time Zone Identifiers</b>
</p>
<p>
Although the short time zone identifiers are guaranteed to be stable,
the preferred IDs in the tz database (as those found in <strong>zone.tab</strong>
file) might be changed time to time. For example, "Asia/Culcutta" was
replaced with "Asia/Kolkata" and moved to <strong>backward</strong>
file in the tz database. CLDR contains locale data using a time zone
ID from the tz database as the key, stability of the IDs is cirtical.
</p>
<p>
To maintain the stability of "long" IDs (for those inherited from the
tz database), a special rule applied to the <i>alias</i> attribute in
the &lt;type&gt; element for "tz" - the first "long" ID is the CLDR
canonical "long" time zone ID.
</p>
<p>For example:</p>
<blockquote>&lt;type name="inccu" alias="Asia/Calcutta
Asia/Kolkata" description="Kolkata, India"/&gt;</blockquote>
<p>
Above &lt;type&gt; element defines the short time zone ID "inccu"
(for the use in the Unicode locale extension), corresponding <em>CLDR
canonical "long" ID</em> "Asia/Culcutta", and an alias "Asia/Kolkata".
</p>
<h4>
<a href="#Unicode_Locale_Extension_Data_Files"
name="Unicode_Locale_Extension_Data_Files">3.6.4 U Extension
Data Files</a>
</h4>
<p>
The 'u' extension data is stored in multiple XML files located under
common/bcp47 directory in CLDR. Each file contains the locale
extension key/type values and their backward compatibility mappings
appropriate for a particular domain. <a
href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/collation.xml">common/bcp47/collation.xml</a>
contains key/type values for collation, including optional collation
parameters and valid type values for each key.
</p>
<p>
The 't' extension data is stored in <a
href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform.xml">common/bcp47/transform.xml</a>.
</p>
<p class="dtd">&lt;!ELEMENT keyword ( key* )&gt;</p>
<p class="dtd">
&lt;!ELEMENT key ( type* )&gt;<br> &lt;!ATTLIST key extension
NMTOKEN #IMPLIED&gt;<br> &lt;!ATTLIST key name NMTOKEN
#REQUIRED&gt;<br> &lt;!ATTLIST key description CDATA
#IMPLIED&gt;<br> &lt;!ATTLIST key deprecated ( true | false )
"false"&gt;<br> &lt;!ATTLIST key preferred NMTOKEN #IMPLIED&gt;<br>
&lt;!ATTLIST key alias NMTOKEN #IMPLIED&gt;<br> &lt;!ATTLIST key valueType (single | multiple
| incremental | any) #IMPLIED &gt;<br> &lt;!ATTLIST key since
CDATA #IMPLIED&gt;
</p>
<p class="dtd">
&lt;!ELEMENT type EMPTY&gt;<br> &lt;!ATTLIST type name NMTOKEN
#REQUIRED&gt;<br> &lt;!ATTLIST type description CDATA
#IMPLIED&gt;<br> &lt;!ATTLIST type deprecated ( true | false )
"false"&gt;<br> &lt;!ATTLIST type preferred NMTOKEN #IMPLIED&gt;<br>
&lt;!ATTLIST type alias CDATA #IMPLIED&gt;<br> &lt;!ATTLIST type
since CDATA #IMPLIED&gt;
</p>
<p class="dtd">
&lt;!ELEMENT attribute EMPTY&gt;<br> &lt;!ATTLIST attribute name
NMTOKEN #REQUIRED&gt;<br> &lt;!ATTLIST attribute description
CDATA #IMPLIED&gt;<br> &lt;!ATTLIST attribute deprecated ( true
| false ) "false"&gt;<br> &lt;!ATTLIST attribute preferred
NMTOKEN #IMPLIED&gt;<br> &lt;!ATTLIST attribute since CDATA
#IMPLIED&gt;
</p>
<p>The extension attribute in &lt;key&gt; element specifies the
BCP 47 language tag extension type. The default value of the
extension attribute is "u" (Unicode locale extension). The
&lt;type&gt; element is only applicable to the enclosing &lt;key&gt;.
</p>
<p>
In the Unicode locale extension 'u' and
't' data files, the common attributes for the &lt;key&gt;,
&lt;type&gt; and &lt;attribute&gt; elements are as follows:
</p>
<dl>
<dt>
<b>name</b>
</dt>
<dd>
<p>
The key or type name used by Unicode locale extension with <a
href="#Unicode_locale_identifier">'u' extension syntax</a> or the 't' extensions syntax. When <i>alias</i>
below is absent, this name can be also used with the old style <a
href="#Old_Locale_Extension_Syntax"> "@key=type" syntax</a>.
</p>
<p>
Most type names are <strong>literal type names</strong>, which
match exactly the same value. All of these have at least one
lowercase letter, such as &quot;buddhist&quot;. There are a small
number of <strong>indirect type names</strong>, such as
&quot;RG_KEY_VALUE&quot;. These have no lowercase letters. The
interpretation of each one is listed below.
</p>
<h5>
<a name="CODEPOINTS" href="#CODEPOINTS">CODEPOINTS</a>
</h5>
<p>
The type name <strong>"CODEPOINTS"</strong> is reserved for a
variable representing Unicode code point(s). The syntax is:
</p>
<table border="0">
<tr>
<th>&nbsp;</th>
<th><div align="center">EBNF</div></th>
<th><div align="center">ABNF</div></th>
</tr>
<tr>
<td><pre>codepoints</pre></td>
<td><pre>= codepoint (sep codepoint)?</pre></td>
<td><pre>= codepoint *(sep codepoint)</pre></td>
</tr>
<tr>
<td><pre>codepoint</pre></td>
<td><pre>= [0-9 A-F a-f]{4,6}</pre></td>
<td><pre>= 4*6HEXDIG</pre></td>
</tr>
</table>
<p>In addition, no codepoint may exceed 10FFFF. For example,
"00A0", "300b", "10D40C" and "00C1-00E1" are valid, but "A0",
"U060C" and "110000" are not.</p>
<p>In the current version of CLDR, the type "CODEPOINTS" is only
used for the deprecated locale extension key "vt" (variableTop).
The subtags forming the type for "vt" represent an arbitrary string
of characters. There is no formal limit in the number of
characters, although practically anything above 1 will be rare, and
anything longer than 4 might be useless. Repetition is allowed, for
example, 0061-0061 ("aa") is a Valid type value for "vt", since the
sequence may be a collating element. Order is vital: 0061-0062
("ab") is different than 0062-0061 ("ba"). Note that for
variableTop any character sequence must be a contraction which
yields exactly one primary weight.</p>
<p>For example,</p>
<blockquote>
<p>
<strong>en-u-vt-00A4</strong> : this indicates English, with any
characters sorting at or below &quot; ¤&quot; (at a primary level)
considered Variable.
</p>
</blockquote>
<p>
By default in UCA, variable characters are ignored in sorting at a
primary, secondary, and tertiary level. But in CLDR, they are not
ignorable by default. For more information, see <a
href="tr35-collation.html#Setting_Options">Collation: Section
3.3 <em>Setting Options</em>
</a>.
</p>
<h5>
<a name="REORDER_CODE" href="#REORDER_CODE">REORDER_CODE</a>
</h5>
<p>
The type name <strong>"REORDER_CODE"</strong> is reserved for
reordering block names (e.g. "latn", "digit" and "others") defined
in the <i><a href="tr35-collation.html#Root_Collation">Root
Collation</a></i>. The type "REORDER_CODE" is used for locale extension
key "kr" (colReorder). The value of type for "kr" is represented by
one or more reordering block names such as "latn-digit". For more
information, see <a href="tr35-collation.html#Script_Reordering">Collation:
Section 3.12 <em>Collation Reordering</em>
</a>.
</p>
<h5>
<a name="RG_KEY_VALUE" href="#RG_KEY_VALUE">RG_KEY_VALUE</a>
</h5>
<p>
The type name <strong>"RG_KEY_VALUE"</strong> is reserved for
region codes in the format required by the "rg" key; this is a
region code from the idValidity data in common/validity/region.xml
(with certain exclusions, listed below) followed by "zzzz". The
excluded region codes are those with idStatus='unknown' and
'macroregion'; region codes with idStatus='deprecated' should not
be generated, and those with idStatus='private_use' are only to be
used with prior agreement. Thus the value for the "rg" key will
normally be a region code with idStatus='regular' followed by
"zzzz"; this set of values is the same as the subdivision codes
with idStatus='unknown' from the idValidity data in
common/validity/subdivision.xml.
</p>
<h5>
<a name="SUBDIVISION_CODE" href="#SUBDIVISION_CODE">SUBDIVISION_CODE</a>
</h5>
<p>
The type name <strong>"SUBDIVISION_CODE"</strong> is reserved for
subdivision codes in the format required by the "sd" key; this is a
subdivision code from the idValidity data in
common/validity/subdivision.xml, excluding those with
idStatus='unknown'. Codes with idStatus='deprecated' should not be
generated, and those with idStatus='private_use' are only to be
used with prior agreement.
</p>
<h5>
<a name="PRIVATE_USE" href="#PRIVATE_USE">PRIVATE_USE</a>
</h5>
<p>
The type name <strong>"PRIVATE_USE"</strong> is reserved for
private use types. A valid type value is composed of one or more
subtags separated by hyphens and each subtag consists of three to
eight ASCII alphanumeric characters. In the current version of
CLDR, <strong>"PRIVATE_USE"</strong> is only used for transform
extension "x0".
</p>
</dd>
<dt>
<b>valueType</b>
</dt>
<dd>
<p>The valueType attribute indicates how many
subtags are valid for a given key:</p>
<table class='simple' width="100%" border="1">
<tbody>
<tr>
<th>single</th>
<td>Either exactly one type value, or no type value (but only if the value of &quot;true&quot; would be valid). This is the default
if no valueType attribute is present.</td>
</tr>
<tr>
<th>incremental</th>
<td>Multiple type values are allowed, but only if a prefix
is also present, and the sequence is explicitly listed. Each
successive type value indicates a refinement of its prefix. For
example:<br> &lt;key name=&quot;ca&quot;
description=&quot;Calendar algorithm key&quot;<strong>
valueType=&quot;incremental&quot;</strong>&gt; <br>&nbsp;&nbsp;&lt;type
name=&quot;islamic&quot; description=&quot;Islamic
calendar&quot;/&gt;<br> &nbsp;&nbsp;&lt;type
name=&quot;islamic-umalqura&quot; description=&quot;Islamic
calendar, Umm al-Qura&quot;/&gt;<br> Thus <em>ca-islamic-umalqura</em>
is valid. However, <em>ca-gregory-japanese</em> is not valid,
because &quot;gregory-japanese&quot; is not listed as a type.
</td>
</tr>
<tr>
<th>multiple</th>
<td>Multiple type values are allowed, but each may only
occur once. For example:<br>&lt;key name=&quot;kr&quot;
description=&quot;Collation reorder codes&quot; <strong>valueType=&quot;multiple&quot;</strong>&gt;<br>
&nbsp;&nbsp;&lt;type name=&quot;REORDER_CODE&quot; …/&gt;
</td>
</tr>
<tr>
<th>any</th>
<td>Any number of type values are allowed, with none of the
above restrictions. For example:<br> &lt;key
extension=&quot;t&quot; name=&quot;x0&quot;<strong> </strong>description=&quot;Private
use transform type key.&quot;<strong>
valueType=&quot;any&quot;</strong>&gt;<br> &nbsp;&nbsp;&lt;type
name=&quot;PRIVATE_USE&quot; …/&gt;
</td>
</tr>
</tbody>
</table>
</dd>
<dt>
<b>description</b>
</dt>
<dd>
<p>
The description of the key, type or attribute element. There is
also some informative text about certain keys and types in the
Section 3.5 <a href="#Key_And_Type_Definitions_">Key And Type
Definitions</a>.
</p>
</dd>
<dt>
<b>deprecated</b>
</dt>
<dd>
<p>The deprecation status of the key, type or attribute element.
The value "true" indicates the element is deprecated and no longer
used in the version of CLDR. The default value is "false".</p>
</dd>
<dt>
<b>preferred</b>
</dt>
<dd>
<p>The preferred value of the deprecated key, type or attribute
element. When a key, type or attribute element is deprecated, this
attribute is used for specifying a new canonical form if available.</p>
</dd>
<dt>
<b>alias</b> (Not applicable to &lt;attribute&gt;)
</dt>
<dd>
<p>The BCP 47 form is the canonical form, and recommended. Other
aliases are included only for backwards compatibility.</p>
</dd>
<dd>
<em>Example:</em>
</dd>
<dd>
<p>
&lt;type name="phonebk" <strong>alias="phonebook"</strong>
description="Phonebook style ordering (such as in German)"/&gt;<br>
</p>
The preferred term, and the only one to be used in BCP 47, is the
name: in this example, &quot;phonebk&quot;.<br>
</dd>
<dd>
<p>
The alias is a key or type name used by Unicode locale extensions
with the old <a href="#Old_Locale_Extension_Syntax">"@key=type"
syntax</a>. The attribute value for type may contain multiple names
delimited by ASCII space characters. Of those aliases, the first
name is the preferred value.
</p>
</dd>
<dt>
<b>since</b>
</dt>
<dd>The version of CLDR in which this key or type was
introduced. Absence of this attribute value implies the key or type
was available in CLDR 1.7.2.</dd>
</dl>
<p>
<em>Note: There are no values defined for the locale extension
attribute in the current CLDR release. </em>
</p>
<p>For example,</p>
<pre>
&lt;key name="co" alias="collation" description="Collation type key"&gt;
&lt;type name="pinyin" description="Pinyin ordering for Latin and for CJK characters (used in Chinese)"/&gt;
&lt;/key&gt;
&lt;key name="ka" alias="colAlternate" description="Collation parameter key for alternate handling"&gt;
&lt;type name="noignore" alias="non-ignorable" description="Variable collation elements are not reset to ignorable"/&gt;
&lt;type name="shifted" description="Variable collation elements are reset to zero at levels one through three"/&gt;
&lt;/key&gt;
&lt;key name="tz" alias="timezone"&gt;
...
&lt;type name="aumel" alias="Australia/Melbourne Australia/Victoria" description="Melbourne, Australia"/&gt;
&lt;type name="aumqi" alias="Antarctica/Macquarie" description="Macquarie Island Station, Macquarie Island" since="1.8.1"/&gt;
...
&lt;/key&gt;
</pre>
The data above indicates:
<ul>
<li>type "pinyin" is valid for key "co", thus "u-co-pinyin" is a
valid Unicode locale extension.</li>
<li>type "pinyin" is not valid for key "ka", thus "u-ka-pinyin"
is not a valid Unicode locale extension.</li>
<li>type "pinyin" has no <i>alias</i>, so "zh@collation=pinyin"
is a valid Unicode locale identifier according to the old syntax.
</li>
<li>type "noignore" has an alias attribute, so
"en@colAlternate=noignore" is not a valid Unicode locale identifier
according to the old syntax.</li>
<li>type "aumel" is valid for key "tz", supported by CLDR 1.7.2
(default value) or later versions.</li>
<li>type "aumqi" is valid for key "tz", supported by CLDR 1.8.1
or later versions.</li>
</ul>
<p>It is strongly recommended that all API methods accept all
possible aliases for keywords and types, but generate the canonical
form. For example, &quot;ar-u-ca-islamicc&quot; would be equivalent
to &quot;ar-u-ca-islamic-civil&quot; on input, but the latter should
be output. The one exception is where an alias would only be
well-formed with the old syntax, such as &quot;gregorian&quot; (for
&quot;gregory&quot;).</p>
<h4>
<a href="#Unicode_Subdivision_Codes" name="Unicode_Subdivision_Codes">3.6.5
Subdivision Codes</a>
</h4>
<p>
The subdivision codes designate a
subdivision of a country or region. They are called various names,
such as a <em>state</em> in the United States, or a <em>province</em>
in Canada. The codes in CLDR
are based on ISO 3166-2 subdivision codes. The
ISO codes have a region code followed by a hyphen, then a suffix
consisting of 1..3 ASCII letters or digits.
</p>
<p>
The CLDR codes are designed to work in a
<a href='#unicode_locale_id'>unicode_locale_id</a> (BCP47), and are
thus all lowercase, with no hyphen.
For example, the following are valid, and mean “English as used in
California, USA”.
</p>
<ul>
<li>en-u-sd-<strong>usca</strong></li>
<li>en-US-u-sd-<strong>usca</strong></li>
</ul>
<p>CLDR has additional subdivision codes. These
may start with a 3-digit region code or use a suffix of 4 ASCII
letters or digits, so they will not collide with the ISO codes.
Subdivision codes for unknown values are the region code plus
&quot;zzzz&quot;, such as &quot;uszzzz&quot; for an unknown
subdivision of the US. Other codes may be added for stability.</p>
<p>
Like BCP 47, CLDR requires stable codes, which are not guaranteed for
ISO 3166-2 (nor have the ISO 3166-2
codes been stable in the past). If an ISO 3166-2 code is removed, it
remains valid (though marked as deprecated) in CLDR. If an ICU 3166-2
code is reused (for the same region), then CLDR will define a new
equivalent code using these a 4-character suffixes.
</p>
<h5>
<a name="Validity" href="#Validity">3.6.5.1 Validity</a>
</h5>
<p>
A <a href="#unicode_subdivision_id">unicode_subdivision_id</a>
is only valid when it is present in the
subdivision.xml file as described in <em>Section 3.11 <a
href="#Validity_Data">Validity Data</a></em>.
The data is in a compressed form, and thus needs to be expanded
before such a test is made.
</p>
<p>
<em> Examples:<br>
</em>
</p>
<ul>
<li><strong>usca</strong> is valid — there is an <strong>id</strong>
element<code>&lt;id type="subdivision"…&gt;… usca
…&lt;/id&gt;</code></li>
<li><strong>ussct</strong> is invalid — there is no <strong>id</strong>
element <code>&lt;id type="subdivision"…&gt;… ussct
…&lt;/id&gt;</code></li>
</ul>
<p>If a <a href='#unicode_locale_id'>unicode_locale_id</a> contains both a <a
href="#unicode_region_subtag">unicode_region_subtag</a> and a <a
href="#unicode_subdivision_id">unicode_subdivision_id</a>, it is only valid if the <a
href="#unicode_subdivision_id">unicode_subdivision_id</a> starts with the <a
href="#unicode_region_subtag">unicode_region_subtag</a> (case-insensitively).<br>
</p>
<p>It is recommended that a <a href='#unicode_locale_id'>unicode_locale_id</a> contain a <a
href="#unicode_region_subtag">unicode_region_subtag</a> if it contains a <a
href="#unicode_subdivision_id">unicode_subdivision_id</a> and the region would not be added by adding likely subtags. That produces better behavior if the <a
href="#unicode_subdivision_id">unicode_subdivision_id</a> is ignored by an implementation or if the language tag is truncated. </p>
<p>
Examples:<br>
</p>
<ul>
<li>en-<strong>US</strong>-u-sd-<strong>us</strong>ca
is valid — the region &quot;US&quot; matches
the first part of "usca"</li>
<li>en-u-sd-<strong>us</strong>ca is valid — it still works after adding likely subtags.</li>
<li>en-<strong>CA</strong>-u-sd-<strong>gb</strong>sct is
invalid — the region &quot;CA&quot; does not match the first part of &quot;gbsct&quot;. An implementation should disregard the subdivision id (or return an error).</li>
<li>en-u-sd-<strong>gb</strong>sct is valid but not recommended — an implementation that ignores the <a
href="#unicode_subdivision_id">unicode_subdivision_id</a> can get the wrong fallback behavior, or could add likely subtags and get the invalid en<strong>-Latn-US</strong>-u-sd-<strong>gb</strong>sct</li>
</ul>
<p>
In version 28.0, the subdivisions in the
validity files used the ISO format, uppercase with a hyphen separating two
components, instead of the BCP 47 format.
</p>
<h3>
<a name="t_Extension"></a><a name="BCP47_T_Extension"
href="#BCP47_T_Extension">3.7 Unicode BCP 47 T Extension</a>
</h3>
<p>
The Unicode Consortium has registered and is the maintaining
authority for two BCP 47 language tag extensions: the extension 'u'
for Unicode locale extension [<a href="#RFC6067">RFC6067</a>] and
extension 't' for transformed content [<a href="#RFC6497">RFC6497</a>].
The Unicode BCP 47 extension data defines the complete list of valid
subtags.
While the title of the RFC is &ldquo;Transformed Content&rdquo;, the abstract makes it clear that the scope is broader than the term "transformed" might indicate to a casual reader: “including content that has been transliterated, transcribed, or
translated, or <em>in some other way influenced by the source. It also provides for additional information used for identification.</em>”</p>
<p>
<strong>The -t- Extension.</strong> The syntax of 't' extension
subtags is defined by the rule
<code>unicode_locale_extensions</code>
in <a href="#Unicode_locale_identifier"><em>Section 3.2
Unicode locale identifier</em></a>, except the separator of subtags
<code>sep</code>
must be always hyphen '-' when the extension is used as a part of BCP
47 language tag. For information about the registration process,
meaning, and usage of the 't' extension, see [<a href="#RFC6497">RFC6497</a>].
</p>
<p>
These subtags are all in lowercase (that is the canonical casing for
these subtags), however, subtags are case-insensitive and casing does
not carry any specific meaning. All subtags within the Unicode
extensions are alphanumeric characters in length of two to eight that
meet the rule
<code>extension</code>
in the [<a href="#BCP47">BCP47</a>].</p>
<p>The following keys are defined for the -t- extension:</p>
<table class='simple'>
<tbody>
<tr>
<th>Keys</th>
<th>Description</th>
<th>Values in latest release</th>
</tr>
<tr>
<td>m0</td>
<td><strong>Transform extension mechanism:</strong> to reference an authority or rules for a type of transformation</td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform.xml">​transform.xml</a></td>
</tr>
<tr>
<td nowrap>s0, d0 </td>
<td><strong>Transform source/destination:</strong> for non-languages/scripts, such as fullwidth-halfwidth conversion.</td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform-destination.xml">​transform-destination.xml</a></td>
</tr>
<tr>
<td>i0</td>
<td><strong>Input Method Engine transform:</strong> Used to indicate an input method transformation, such as one used by
a client-side input method. The first subfield in a sequence would
typically be a 'platform' or vendor designation.</td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform_ime.xml">​transform_ime.xml</a></td>
</tr>
<tr>
<td>k0</td>
<td><strong>Keyboard transform:</strong> Used to indicate a keyboard transformation, such as one used by a client-side virtual keyboard. The first subfield in a sequence would typically be a 'platform' designation, representing the platform that the keyboard is intended for. The keyboard might or might not correspond to a keyboard mapping shipped by the vendor for the platform. One or more subsequent fields may occur, but are only added where needed to distinguish from others.</td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform_keyboard.xml">​transform_keyboard.xml</a></td>
</tr>
<tr>
<td>t0</td>
<td><strong>Machine Translation:</strong> Used to indicate content that has been machine translated, or a request for a particular type of machine translation of content. The first subfield in a sequence would typically be a 'platform' or vendor designation.</td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform_mt.xml">​transform_mt.xml</a></td>
</tr>
<tr>
<td nowrap>h0</td>
<td><strong>Hybrid Locale Identifiers:</strong> h0 with the value 'hybrid' indicates that the -t- value is a language that is mixed into the main language tag to form a hybrid. For more information, and examples, see <em>Section 3.10.2 <a href="#Hybrid_Locale">Hybrid Locale Identifiers</a>.</em></td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform_hybrid.xml">​transform_hybrid.xml</a></td>
</tr>
<tr>
<td>x0</td>
<td><strong>Private use transform</strong></td>
<td><a href="http://unicode.org/repos/cldr/tags/latest/common/bcp47/transform_private_use.xml">​transform_private_use.xml</a></td>
</tr>
</tbody>
</table>
<h4>
<a href="#Transformed_Content_Data_File"
name="Transformed_Content_Data_File">3.7.1 T Extension Data
Files</a>
</h4>
<p>The overall structure of the data files is the similar to the U
Extension, with the following exceptions.</p>
<p>In the transformed content 't' data file, the name attribute in
a &lt;key&gt; element defines a valid field separator subtag. The
name attribute in an enclosed &lt;type&gt; element defines a valid
field subtag for the field separator subtag. For example:</p>
<pre>
&lt;key extension="t" name="m0"
description="Transform extension mechanism"&gt;
&lt;type name="ungegn"
description="United Nations Group of Experts on Geographical Names"
since="21"/&gt;
&lt;key&gt;
</pre>
The data above indicates:
<ul>
<li>"m0" is a valid field separator for the transformed content
extension 't'.</li>
<li>field subtag "ungegn" is valid for field separator "m0".</li>
<li>field subtag "ungegn" was introduced in CLDR 21.</li>
</ul>
<p>The attributes are:</p>
<dl>
<dt>
<b>name</b>
</dt>
<dd>
The name of the mechanism, limited to 3-8 characters (or sequences
of them). Any indirect type names are
listed in 3.6.4 <a href="#Unicode_Locale_Extension_Data_Files">U
Extension Data Files</a>.
</dd>
<dt>
<b>description</b>
</dt>
<dd>A description of the name, with all and only that
information necessary to distinguish one name from | American
Library others with which it might be confused. Descriptions are not
intended to provide general background information.</dd>
<dt>
<b>since</b>
</dt>
<dd>Indicates the first version of CLDR where the name appears.
(Required for new items.)</dd>
<dt>&nbsp;</dt>
<dt>
<b>alias</b>
</dt>
<dd>
Alternative name, not limited in number of characters. Aliases are
intended for compatibility, not to provide all possible alternate
names or designations. <em>(Optional)</em>
</dd>
</dl>
<p>
For information about the registration process, meaning, and usage of
the 't' extension, see [<a href="#RFC6497">RFC6497</a>].
</p>
<h3>
<a name="Compatibility_with_Older_Identifiers"
href="#Compatibility_with_Older_Identifiers">3.8 Compatibility
with Older Identifiers</a>
</h3>
<p>LDML version before 1.7.2 used slightly different syntax for
variant subtags and locale extensions. Implementations of LDML may
provide backward compatible identifier support as described in
following sections.</p>
<h4>
<a name="Old_Locale_Extension_Syntax"
href="#Old_Locale_Extension_Syntax">3.8.1 Old Locale Extension
Syntax </a>
</h4>
<p>LDML 1.7 or older specification used different syntax for
representing unicode locale extensions. The previous definition of
Unicode locale extensions had the following structure:</p>
<table border="0">
<tr>
<th>&nbsp;</th>
<th><div align="center">EBNF</div></th>
<th><div align="center">ABNF</div></th>
</tr>
<tr>
<td>old_unicode_locale_extensions</td>
<td><pre>= "@" old_key "=" old_type
(";" old_key "=" old_type)*</pre></td>
<td><pre>= "@" old_key "=" old_type
*(";" old_key "=" old_type)</pre></td>
</tr>
</table>
<p>The new specification mandates keys to be two alphanumeric
characters and types to be three to eight alphanumeric characters. As
the result, new codes were assigned to all existing keys and some
types. For example, a new key "co" replaced the previous key
"collation", a new type "phonebk" replaced the previous type
"phonebook". However, the existing collation type "big5han" already
satisfied the new requirement, so no new type code was assigned to
the type. All new keys and types introduced after LDML 1.7 satisfy
the new requirement, so they do not have aliases dedicated for the
old syntax, except time zone types. The conversion between old types
and new types can be done regardless of key, with one known exception
(old type "traditional" is mapped to new type "trad" for collation
and "traditio" for numbering system), and this relationship will be
maintained in the future versions unless otherwise noted.</p>
<p>
The new specification introduced a new field
<code>attribute</code>
in addition to key/type pairs in the Unicode locale extension. When
it is necessary to map a new Unicode locale identifier with
<code>attribute</code>
field to a well-formed old locale identifier, a special key name <i>attribute</i>
with the value of entire
<code>attribute</code>
subtags in the new identifier is used. For example, a new identifier
<code>ja-u-xxx-yyy-ca-japanese</code>
is mapped to an old identifier
<code>ja@attribute=xxx-yyy;calendar=japanese</code>
.
</p>
<p>The chart below shows some example mappings between the new
syntax and the old syntax.</p>
<table>
<caption>
<a name="Locale_Extension_Mappings"
href="#Locale_Extension_Mappings">Locale Extension Mappings</a>
</caption>
<tr>
<th>Old (LDML 1.7 or older)</th>
<th>New</th>
</tr>
<tr>
<td>de_DE@collation=phonebook</td>
<td>de_DE_u_co_phonebk</td>
</tr>
<tr>
<td>zh_Hant_TW@collation=big5han</td>
<td>zh_Hant_TW_u_co_big5han</td>
</tr>
<tr>
<td>th_TH@calendar=gregorian;numbers=thai</td>
<td>th_TH_u_ca_gregory_nu_thai</td>
</tr>
<tr>
<td>en_US_POSIX@timezone=America/Los_Angeles</td>
<td>en_US_u_tz_uslax_va_posix</td>
</tr>
</table>
<p>Where the old API is supplied the bcp47 language code, or vice
versa, the recommendation is to:</p>
<ol>
<li>Have all methods that take the old syntax also take the new
syntax, interpreted correctly. For example,
&quot;zh-TW-u-co-pinyin&quot; and &quot;zh_TW@collation=pinyin&quot;
would both be interpreted as meaning the same.</li>
<li>Have all methods (both for old and new syntax) accept all
possible aliases for keywords and types. For example,
&quot;ar-u-ca-islamicc&quot; would be equivalent to
&quot;ar-u-ca-islamic-civil&quot;.
<ul>
<li>The one exception is where an alias would only be
well-formed with the old syntax, such as &quot;gregorian&quot;
(for &quot;gregory&quot;).</li>
</ul>
</li>
<li>Where an API cannot successfully accept the alternate
syntax, throw an exception (or otherwise indicate an error) so that
people can detect that they are using the wrong method (or wrong
input).</li>
<li>Provide a method that tests a purported locale ID string to
determine its status:
<ol>
<li><strong>well-formed</strong> - syntactically correct</li>
<li><strong>valid</strong> - well-formed and only uses
registered language subtags, extensions, keywords, types...</li>
<li><strong>canonical</strong> - valid and no deprecated codes
or structure.</li>
</ol>
</li>
</ol>
<h4>
<a name="Legacy_Variants" href="#Legacy_Variants">3.8.2 Legacy
Variants </a>
</h4>
<p>
Old LDML specification allowed codes other than registered [<a
href="#BCP47">BCP47</a>] variant subtags used in Unicode language
and locale identifiers for representing variations of locale data.
Unicode locale identifiers including such variant codes can be
converted to the new [<a href="#BCP47">BCP47</a>] compatible
identifiers by following the descriptions below:
</p>
<table>
<caption>
<a name="Legacy_Variant_Mappings" href="#Legacy_Variant_Mappings">Legacy
Variant Mappings</a>
</caption>
<tr>
<th>Variant Code</th>
<th>Description</th>
</tr>
<tr>
<td>AALAND</td>
<td>Åland, variant of "sv" Swedish used in Finland. Use "sv_AX"
to indicate this.</td>
</tr>
<tr>
<td>BOKMAL</td>
<td>Bokmål, variant of "no" Norwegian. Use primary language
subtag "nb" to indicate this.</td>
</tr>
<tr>
<td>NYNORSK</td>
<td>Nynorsk, variant of "no" Norwegian. Use primary language
subtag "nn" to indicate this.</td>
</tr>
<tr>
<td>POSIX</td>
<td>POSIX variation of locale data. Use Unicode locale
extension "-u-va-posix" to indicate this.</td>
</tr>
<tr>
<td>POLYTONI</td>
<td>Polytonic, variant of "el" Greek. Use [<a href="#BCP47">BCP47</a>]
variant subtag "polyton" to indicate this.
</td>
</tr>
<tr>
<td>SAAHO</td>
<td>The Saaho variant of Afar. Use primary language subtag
"ssy" to indicated this.</td>
</tr>
</table>
<p>
When converting to old syntax, the Unicode locale extension
"-u-va-posix" should be converted to the "POSIX" variant, <i>not</i>
to old extension syntax like "@va=posix". This is an exception: The
other mappings above should not be reversed.
</p>
<p>Examples:</p>
<ul>
<li>en_US_POSIX ↔ en-US-u-va-posix</li>
<li>en_US_POSIX@colNumeric=yes ↔ en-US-u-kn-va-posix</li>
<li>en-US-POSIX-u-kn-true → en-US-u-kn-va-posix</li>
<li>en-US-POSIX-u-kn-va-posix → en-US-u-kn-va-posix</li>
</ul>
<h4>
<a name="Relation_to_OpenI18n" href="#Relation_to_OpenI18n">3.8.3
Relation to OpenI18n</a>
</h4>
<p>
The locale id format generally follows the description in the <i>OpenI18N
Locale Naming Guideline</i> [<a href="#NamingGuideline">NamingGuideline</a>],
with some enhancements. The main differences from the those
guidelines are that the locale id:
</p>
<ol type="a">
<li style="margin-top: 0.5em; margin-bottom: 0.5em">does not
include a charset (since the data in LDML format always provides a
representation of all Unicode characters. The repository is stored
in UTF-8, although that can be transcoded to other encodings as
well.),</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">adds the
ability to have a variant, as in Java</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">adds the
ability to discriminate the written language by script (or script
variant).</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">is a
superset of [<a href="#BCP47">BCP47</a>] codes.
</li>
</ol>
<h3>
<a name="Transmitting_Locale_Information"
href="#Transmitting_Locale_Information">3.9 Transmitting Locale
Information</a>
</h3>
<p>
In a world of on-demand software components, with arbitrary
connections between those components, it is important to get a sense
of where localization should be done, and how to transmit enough
information so that it can be done at that appropriate place.
End-users need to get messages localized to their languages, messages
that not only contain a translation of text, but also contain
variables such as date, time, number formats, and currencies
formatted according to the users&#39; conventions. The strategy for
doing the so-called <i>JIT localization </i>is made up of two parts:
</p>
<ol>
<li>Store and transmit <i>neutral-format</i> data wherever
possible.
<ul>
<li>Neutral-format data is data that is kept in a standard
format, no matter what the local user&#39;s environment is.
Neutral-format is also (loosely) called <i>binary data</i>, even
though it actually could be represented in many different ways,
including a textual representation such as in XML.
</li>
<li>Such data should use accepted standards where possible,
such as for currency codes.</li>
<li>Textual data should also be in a uniform character set
(Unicode/10646) to avoid possible data corruption problems when
converting between encodings.</li>
</ul>
</li>
<li>Localize that data as &quot;<i>close</i>&quot; to the
end-user as possible.
</li>
</ol>
<p>There are a number of advantages to this strategy. The longer
the data is kept in a neutral format, the more flexible the entire
system is. On a practical level, if transmitted data is
neutral-format, then it is much easier to manipulate the data, debug
the processing of the data, and maintain the software connections
between components.</p>
<p>Once data has been localized into a given language, it can be
quite difficult to programmatically convert that data into another
format, if required. This is especially true if the data contains a
mixture of translated text and formatted variables. Once information
has been localized into, say, Romanian, it is much more difficult to
localize that data into, say, French. Parsing is more difficult than
formatting, and may run up against different ambiguities in
interpreting text that has been localized, even if the original
translated message text is available (which it may not be).</p>
<p>Moreover, the closer we are to end-user, the more we know about
that user&#39;s preferred formats. If we format dates, for example,
at the user&#39;s machine, then it can easily take into account any
customizations that the user has specified. If the formatting is done
elsewhere, either we have to transmit whatever user customizations
are in play, or we only transmit the user&#39;s locale code, which
may only approximate the desired format. Thus the closer the
localization is to the end user, the less we need to ship all of the
user&#39;s preferences around to all the places that localization
could possibly need to be done.</p>
<p>Even though localization should be done as close to the
end-user as possible, there will be cases where different components
need to be aware of whatever settings are appropriate for doing the
localization. Thus information such as a locale code or time zone
needs to be communicated between different components.</p>
<h4>
<a name="Message_Formatting_and_Exceptions"
href="#Message_Formatting_and_Exceptions">3.9.1 Message
Formatting and Exceptions</a>
</h4>
<p>
Windows (<a
href="http://msdn.microsoft.com/en-us/library/ms679351.aspx">FormatMessage</a>,
<a href="http://msdn.microsoft.com/en-us/library/aa331875.aspx">String.Format</a>),
Java (<a
href="http://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html">MessageFormat</a>)
and ICU (<a
href="http://www.icu-project.org/apiref/icu4c/classMessageFormat.html">MessageFormat</a>,
<a href="http://www.icu-project.org/apiref/icu4c/umsg_8h.html">umsg</a>)
all provide methods of formatting variables (dates, times, etc) and
inserting them at arbitrary positions in a string. This avoids the
manual string concatenation that causes severe problems for
localization. The question is, where to do this? It is especially
important since the original code site that originates a particular
message may be far down in the bowels of a component, and passed up
to the top of the component with an exception. So we will take that
case as representative of this class of issues.
</p>
<p>There are circumstances where the message can be communicated
with a language-neutral code, such as a numeric error code or
mnemonic string key, that is understood outside of the component. If
there are arguments that need to accompany that message, such as a
number of files or a datetime, those need to accompany the numeric
code so that when the localization is finally at some point, the full
information can be presented to the end-user. This is the best case
for localization.</p>
<p>More often, the exact messages that could originate from within
the component are not known outside of the component itself; or at
least they may not be known by the component that is finally
displaying text to the user. In such a case, the information as to
the user&#39;s locale needs to be communicated in some way to the
component that is doing the localization. That locale information
does not necessarily need to be communicated deep within the
component; ideally, any exceptions should bundle up some
language-neutral message ID, plus the arguments needed to format the
message (for example, datetime), but not do the localization at the
throw site. This approach has the advantages noted above for JIT
localization.</p>
<p>In addition, exceptions are often caught at a higher level;
they do not end up being displayed to any end-user at all. By
avoiding the localization at the throw site, it the cost of doing
formatting, when that formatting is not really necessary. In fact, in
many running programs most of the exceptions that are thrown at a low
level never end up being presented to an end-user, so this can have
considerable performance benefits.</p>
<h3>
<a name="Language_and_Locale_IDs" href="#Language_and_Locale_IDs">3.10
Unicode Language and Locale IDs</a>
</h3>
<p>People have very slippery notions of what distinguishes a
language code versus a locale code. The problem is that both are
somewhat nebulous concepts.</p>
<p>
In practice, many people use [<a href="#BCP47">BCP47</a>] codes to
mean locale codes instead of strictly language codes. It is easy to
see why this came about; because [<a href="#BCP47">BCP47</a>]
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 [<a href="#BCP47">BCP47</a>] 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
&quot;-&quot; versus &quot;_&quot; (for example, <i>zh-TW</i> for
language code, <i>zh_TW</i> 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
&quot;-&quot; as a separator in its locale codes. So pragmatically
one is forced to treat &quot;-&quot; and &quot;_&quot; as equivalent
when interpreting either one on input.
</p>
<p>
Another reason for the conflation of these codes is that <i>very</i>
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 does not make much sense. If people see the sentence &quot;You
will have to adjust the value to १,२३४.५६७ from ૭૧,૨૩૪.૫૬&quot;
(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
&quot;2003年4月1日&quot; (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.
</p>
<p>
As far as we are concerned — <i>as a completely practical matter</i>
— 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 [<a href="#ISO639">ISO639</a>], which has
the fairly unproductive notion (for data interchange) that only
spoken language matters (it is also not completely consistent about
this, however).
</p>
<p>
[<a href="#BCP47">BCP47</a>] <i><b>can</b></i> express a difference
if the use of written languages happens to correspond to region
boundaries expressed as [<a href="#ISO3166">ISO3166</a>] region
codes, and has recently added codes that allow it to express some
important cases that are not distinguished by [<a href="#ISO3166">ISO3166</a>]
codes. These written languages include simplified and traditional
Chinese (both used in Hong Kong S.A.R.); Serbian in Latin script;
Azerbaijani in Arab script, and so on.
</p>
<p>
Notice also that <i>currency codes</i> are different than <i>currency
localizations</i>. The currency localizations should largely be in the
language-based resource bundles, not in the territory-based resource
bundles. Thus, the resource bundle <i>en</i> contains the localized
mappings in English for a range of different currency codes: USD →
US$, RUR → Rub, AUD → $A and so on. Of course, some currency symbols
are used for more than one currency, and in such cases
specializations appear in the territory-based bundles. Continuing the
example, <i>en_US</i> would have USD → $, while <i>en_AU</i> would
have AUD → $. (In protocols, the currency codes should always
accompany any currency amounts; otherwise the data is ambiguous, and
software is forced to use the user&#39;s territory to guess at the
currency. For some informal discussion of this, see <a
href="http://source.icu-project.org/repos/icu/icuhtml/trunk/design/jit_localization.html">JIT
Localization</a>.)
</p>
<h4>
<a name="Written_Language" href="#Written_Language">3.10.1
Written Language</a>
</h4>
<p>
Criteria for what makes a written language should be purely
pragmatic; <i>what would copy-editors say? </i>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:
</p>
<ol>
<li type="A">&quot;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.&quot;</li>
</ol>
<p>So one would change it to either B or C below, depending on
which orthographic variant of English was the target for the
publication:</p>
<ol type="A" start="2">
<li>&quot;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.&quot;</li>
<li>&quot;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.&quot;</li>
</ol>
<p>
Clearly there are many acceptable variations on this text. For
example, copy editors might still quibble with the use of first
versus last name sorting in the list, but clearly the first list was
<i>not</i> acceptable English alphabetical order. And in quoting a
name, like &quot;Theatre Centre News&quot;, 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 &quot;2003年3月20日&quot;, for example,
is <i>not</i>.
</p>
<p>Note that the language of locale data may differ from the
language of localized software or web sites, when those latter are
not localized into the user&#39;s preferred language. In such cases,
the kind of incongruous juxtapositions described above may well
appear, but this situation is usually preferable to forcing
unfamiliar date or number formats on the user as well.</p>
<h4>
<a name="Hybrid_Locale" href="#Hybrid_Locale">3.10.2
Hybrid Locale Identifiers</a>
</h4>
<p>Hybrid locales have intermixed content from 2 (or more) languages, often with one language's grammatical structure applied to words in another. These are commonly referred to with portmanteau words such as <em>Franglais, <a href="https://en.oxforddictionaries.com/definition/spanglish">​Spanglish</a> </em>or<em> Denglish</em>. Hybrid locales do not <em>not</em> reference text simply containing two languages: a book of parallel text containing English and French, such as the following, is not Franglais:</p>
<table style='margin-left:2em; margin-right:2em'>
<tbody>
<tr>
<td width='50%' style='font-family:serif'>On the 24th of May, 1863, my uncle, Professor Liedenbrock, rushed into his little house, No. 19 Königstrasse, one of the oldest streets in the oldest portion of the city of Hamburg…</td>
<td style='font-family:serif'>Le 24 mai 1863, un dimanche, mon oncle, le professeur Lidenbrock, revint précipitamment vers sa petite maison située au numéro 19 de Königstrasse, l’une des plus anciennes rues du vieux quartier de Hambourg…</td>
</tr>
</tbody>
</table>
<p>While text in a document can be tagged as partly in one language and partly in another, that is not the same having a hybrid locale. There is a difference between having a Spanglish document, and a Spanish document that has some passages quoted in English. Fine-grained tagging doesn't handle grammatical combinations like Denglisch “<a href="http://www.duden.de/rechtschreibung/downloaden">​gedownloadet</a>”, which is neither English nor German — similarly the Franglais “<a href='http://www.le-dictionnaire.com/definition.php?mot=downloader'>downloadé</a>”. More importantly, it doesn’t work for the very common use case for a <a href="#unicode_locale_id">unicode_locale_id</a>: <i>locale selection</i>. </p>
<p>To communicate requests for localized content and internationalization services, locales are used. When people pick a language from a menu, internally they are picking a locale (en-GB, es-419, etc.). To allow an application to support Spanglish or Hinglish locale selection, <a href="#unicode_locale_id">unicode_locale_id</a>s can represent hybrid locales using the T extension key-value 'h0-hybrid'. (For more information on the T extension, see <em>Section 3.7 <a href="#t_Extension">Unicode BCP 47 T Extension</a>.</em>)
</p>
<p>Examples:</p>
<table class='simple'>
<tbody>
<tr>
<td>hi-t-<u>en-h0-hybrid</u></td>
<td>Hinglish</td>
<td>Hindi-English hybrid locale</td>
</tr>
<tr>
<td>ta-t-<u>en-h0-hybrid</u></td>
<td>Tanglish</td>
<td>Tamil-English hybrid locale</td>
</tr>
<tr>
<td>ba-t-<u>en-h0-hybrid</u></td>
<td>Banglish</td>
<td>Bangla-English hybrid locale</td>
</tr>
<tr><td colspan="3">…</td></tr>
<tr>
<td>en-t-<u>hi-h0-hybrid</u></td>
<td>Hinglish</td>
<td>English-Hindi hybrid locale</td>
</tr>
<tr>
<td>en-t-<u>zh-h0-hybrid</u></td>
<td>Chinglish</td>
<td>English-Chinese hybrid locale</td>
</tr>
<tr><td colspan="3">…</td></tr>
</tbody>
</table>
<blockquote>
<p><em>Note: The <a href="#unicode_language_id">unicode_language_id</a> should be the language used as the ‘scaffold’: for the fallback locale for internationalization services, typically used for more of the core vocabulary/structure in the content. Thus Hinglish should be represented as hi-t-h0-en where Hindi is the scaffold, and as en-t-h0-hi where English is.</em></p>
</blockquote>
<p>The value of -t- is a full <em><a href="#unicode_language_id">unicode_language_id</a></em>, and can contain subtags for script or region where it is important to include them, as in the following. It may be useful in order to emphasize the script, even where it is the default script for the language, if it is not the same as the script of the main language tag.</p>
<table class='simple'>
<tbody>
<tr>
<td>ru-t<u>-en-latn-gb-h0-hybrid</u></td>
<td>Runglish</td>
<td>Russian with an admixture of British English in Latin script</td>
</tr>
<tr>
<td>ru-t-<u>en-cyrl-gb-h0-hybrid</u></td>
<td>Runglish</td>
<td>Russian with an admixture of British English in Cyrillic script</td>
</tr>
</tbody>
</table>
<p>Should there ever be strong need for hybrids of more than two languages or for other purposes such as hybrid languages as the source of translated content, additional structure could be added.</p>
<h3>
<a name="Validity_Data" href="#Validity_Data">3.11 Validity Data</a>
</h3>
<p class='dtd'>
&lt;!ELEMENT idValidity (id*) &gt;<br> &lt;!ELEMENT id ( #PCDATA
) &gt;<br> &lt;!ATTLIST id type NMTOKEN #REQUIRED &gt; <br>
&lt;!ATTLIST id idStatus NMTOKEN #REQUIRED &gt;
</p>
<p>
The directory <a
href='http://unicode.org/repos/cldr/tags/latest/common/validity/'>common/validity</a>
contains machine-readable data for validating the language, region,
script, and variant subtags, as well as currency, subdivisions and
measure units. Each file contains a number of subtags with the
following <strong>idStatus</strong> values:
</p>
<ul>
<li><strong>regular</strong> — the standard codes used for the
specific type of subtag</li>
<li><strong>special</strong> — certain
exceptional language codes like 'mul'<em> (languages only)</em></li>
<li><strong>unknown</strong> — the code used to indicate the
&quot;unknown&quot;, &quot;undetermined&quot; or &quot;invalid&quot;
values. For more information, see <em>Section 3.5.1 <a
href="#Unknown_or_Invalid_Identifiers">Unknown or Invalid
Identifiers</a></em>.</li>
<li><strong>macroregion</strong> — the standard codes that are
macroregions<em> (for regions only).</em>
<ul>
<li>Note that some two-letter region codes are macroregions,
and (in the future) some three-digit codes may be regular codes.</li>
<li>For details as to which regions are contained within which
macroregions, see the <strong>&lt;containment&gt;</strong> element
of the supplemental data.
</li>
</ul></li>
<li><strong>deprecated</strong> — codes that should not be used.
The <strong>&lt;alias&gt;</strong> element in the supplementalMeta
file contains more information about these codes, and which codes
should be used instead.</li>
<li><strong>private_use</strong> — codes that, for CLDR, are
considered private use. Note that some BCP 47 private-use codes have
defined CLDR semantics, and are considered regular codes. For more
information, see <em>Section 3.5.3 <a href="#Private_Use">Private
Use Codes</a>.
</em></li>
</ul>
<p>
The list of subtags for each idStatus use a compact format as a
space-delimited list of StringRanges, as defined in <em>Section
<a href="#String_Range">5.3.4 String Range</a>.
</em> The separator for each StringRange is a &quot;~&quot;.
</p>
<p>Each measure unit is a sequence of subtags, such as
“angle-arc-minute”. The first subtag provides a general “category” of
the unit.</p>
<p>
In version 28.0, the subdivisions in the
validity files used the ISO format, uppercase with a hyphen separating two
components, instead of the BCP 47 format.
</p>
<h2>
<a name="Locale_Inheritance" href="#Locale_Inheritance">4 Locale
Inheritance and Matching</a>
</h2>
<p>
The XML format relies on an inheritance model, whereby the resources
are collected into <i>bundles</i>, and the bundles organized into a
tree. Data for the many Spanish locales does not need to be
duplicated across all of the countries having Spanish as a national
language. Instead, common data is collected in the Spanish language
locale, and territory locales only need to supply differences. The
parent of all of the language locales is a generic locale known as <i>root</i>.
Wherever possible, the resources in the root are language &amp;
territory neutral. For example, the collation (sorting) order in the
root is based on the [<a href="#DUCET">DUCET</a>] (see<em><a
href="tr35-collation.html#Root_Collation">Root Collation</a></em>). Since
English language collation has the same ordering as the root locale,
the &#39;en&#39; locale data does not need to supply any collation
data, nor do the &#39;en_US&#39;, &#39;en_GB&#39; or the any of the
various other locales that use English.
</p>
<p>Given a particular locale id &quot;en_US_someVariant&quot;, the
search chain for a particular resource is the following.</p>
<blockquote>
<pre>en_US_someVariant
en_US
en
root</pre>
</blockquote>
<p>
<em>The inheritance is often not simple truncation, as will be
seen later in this section.</em>
</p>
<p>If a type and key are supplied in the locale id, then logically
the chain from that id to the root is searched for a resource tag
with a given type, all the way up to root. If no resource is found
with that tag and type, then the chain is searched again without the
type.</p>
<p>
Thus the data for any given locale will only contain resources that
are different from the parent locale. For example, most territory
locales will inherit the bulk of their data from the language locale:
&quot;en&quot; will contain the bulk of the data: &quot;en_IE&quot;
will only contain a few items like currency. All data that is
inherited from a parent is presumed to be valid, just as valid as if
it were physically present in the file. This provides for much
smaller resource bundles, and much simpler (and less error-prone)
maintenance. At the script or region level, the &quot;primary&quot;
child locale will be empty, since its parent will contain all of the
appropriate resources for it. For more information see <i>CLDR
Information : Section 9.3 <a href="tr35-info.html#Default_Content">Default
Content</a>.
</i>
</p>
<p>
Certain data items depend only on the region specified in a locale id
(by a <a
href="#unicode_region_subtag_validity">unicode_region_subtag</a> or
an “rg” <a href="#RegionOverride">Region Override</a> key)
, and are obtained from supplemental data rather than through locale
resources. For example:
</p>
<ul>
<li>The currency for the specified region (see <a
href="tr35-numbers.html#Supplemental_Currency_Data">Supplemental
Currency Data</a>)
</li>
<li>The measurement system for the specified region (see <a
href="tr35-general.html#Measurement_System_Data">Measurement
System Data</a>)
</li>
<li>The week conventions for the specified region (see <a
href="tr35-dates.html#Week_Data">Week Data</a>)
</li>
</ul>
<p>
(For more information on the specific
items handled this way, see <a
href="tr35-info.html#Territory_Based_Preferences">Territory-Based
Preferences</a>.)
These items will be correct for the specified region regardless of
whether a locale bundle actually exists with the same combination of
language and region as in the locale id. For example, suppose data is
requested for the locale id "fr_US" and there is no bundle for that
combination. Data obtained via locale inheritance, such as currency
patterns and currency symbols, will be obtained from the parent
locale "fr". However, currency amounts would be formatted by default
using US dollars, just displayed in the manner governed by the locale
"fr". When a locale id does not specify a region, the region-specific
items such as those above are obtained from the likely region for the
locale (obtained via <a href="#Likely_Subtags">Likely Subtags</a>).</p>
<p>For the relationship between Inheritance, DefaultContent, LikelySubtags, and LocaleMatching, see Section 4.2.6 <a
href="tr35.html#Inheritance_vs_Related">Inheritance vs Related Information</a>.</p>
<h3>
<a href="#Lookup" name="Lookup">4.1 Lookup</a>
</h3>
<p>If a language has more than one script in customary modern use,
then the CLDR file structure in common/main follows the following
model:</p>
<blockquote>
<p>
lang<br> lang_script<br> lang_script_region<br>
lang_region<i> (aliases to lang_script_region)</i>
</p>
</blockquote>
<h4>
<a href="#Bundle_vs_Item_Lookup" name="Bundle_vs_Item_Lookup">4.1.1
Bundle vs Item Lookup</a>
</h4>
<p>
There are actually two different kinds of inheritance fallback: <em>resource&nbsp;bundle&nbsp;lookup</em>
and <em>resource&nbsp;item&nbsp;lookup</em>. For the former, a
process is looking to find the first, best resource bundle it can;
for the later, it is fallback&nbsp;within&nbsp;bundles on individual
items, like the translated name for the region &quot;CN&quot; in
Breton.
</p>
<p>
These are closely related, but distinct, processes. They are
illustrated in the table <a href="#Lookup-Differences">Lookup
Differences</a>, where &quot;key&quot; stands for zero or more key/type
pairs. Logically speaking, when looking up an item for a given
locale, you first do a resource bundle lookup to find the best bundle
for the locale, then you do a inherited item lookup starting with
that resource bundle.
</p>
<p>
The table <a href="#Lookup-Differences">Lookup Differences</a> uses
the naïve resource bundle lookup for illustration. More sophisticated
systems will get far better results for resource bundle lookup if
they use the algorithm described in <em>Section 4.4 <a
href="#LanguageMatching">Language Matching</a></em>. That algorithm takes
into account both the user’s desired locale(s) and the application’s
supported locales, in order to get the best match.
</p>
<p>
If the naïve resource bundle lookup is used, the desired locale needs
to be canonicalized using 4.3 <a href="#Likely_Subtags">Likely
Subtags</a> and the supplemental alias information, so that locales that
CLDR considers identical are treated as such. Thus eng-Latn-GB should
be mapped to en-GB, and cmn-TW mapped to zh-Hant-TW.
</p>
<p>For the purposes of CLDR, everything with the &lt;ldml&gt; dtd
is treated logically as if it is one resource bundle, even if the
implementation separates data into separate physical resource
bundles. For example, suppose that there is a main XML file for Nama
(naq), but there are no &lt;unit&gt; elements for it because the
units are all inherited from root. If the &lt;unit&gt; elements are
separated into a separate data tree for modularity in the
implementation, the Nama &lt;unit&gt; resource bundle would be empty.
However, for purposes of resource-bundle lookup the resource bundle
lookup still stops at naq.xml.</p>
<div id="iqaw2" style="margin-top: 0px; margin-bottom: 0px;">
<table class='simple' id="a1bn" border="1" cellpadding="3" cellspacing="0">
<caption>
<a href="#Lookup-Differences" name="Lookup-Differences">Lookup
Differences</a>
</caption>
<tbody id="iqaw3">
<tr id="x40y0">
<th id="x40y1" style="vertical-align: top;" nowrap>Lookup
Type</th>
<th id="x40y3" style="vertical-align: top;" nowrap>Example</th>
<th id="x40y5" style="vertical-align: top;">Comments</th>
</tr>
<tr id="iqaw4">
<td id="iqaw5" style="vertical-align: top;" nowrap>
<p id="rkc40">
<strong>Resource bundle</strong> lookup
</p>
</td>
<td id="iqaw7" style="vertical-align: top;" nowrap>
<p>se-FI&nbsp;→</p>
<p>se&nbsp; →</p>
<p>
<em>default-locale*&nbsp;&nbsp;→</em>
</p>
<p>root</p>
</td>
<td id="rkc41" style="vertical-align: top;">
<p>* The default-locale may have its own inheritance change;
for example, it may be &quot;en-GB&nbsp;→&nbsp;en&quot; In that
case, the chain is expanded by inserting the chain, resulting
in:</p>
<blockquote>
<p>se-FI →</p>
<p>se →</p>
<p>fi →</p>
<p>
<em>en-GB →</em>
</p>
<p>
<em>en →</em>
</p>
<p>root</p>
</blockquote>
</td>
</tr>
<tr id="iqaw9">
<td id="iqaw10" style="vertical-align: top;" nowrap>
<p>
<strong>Inherited item</strong> lookup
</p>
</td>
<td id="iqaw12" style="vertical-align: top;" nowrap>
<p>se-FI+key&nbsp;→</p>
<p>se+key →</p>
<p>
<em>root_alias*+key&nbsp;</em>
</p>
<p>→&nbsp;root+key</p>
</td>
<td id="rkc43" style="vertical-align: top;">
<p>* If there is a root_alias to another key or locale, then
insert that entire chain. For example, suppose that months for
another calendar system have a root alias to Gregorian months.
In that case, the root alias would change the key, and retry
from se-FI downward. This can happen multiple times.</p>
<blockquote>
<p>se-FI+key&nbsp;→</p>
<p>se+key →</p>
<p>root_alias*+key →</p>
<p>
<em>se-FI+key2&nbsp;→</em>
</p>
<p>
<em>se+key2 →</em>
</p>
<p>root_alias*+key2 →</p>
<p>root+key2</p>
</blockquote>
</td>
</tr>
</tbody>
</table>
</div>
<p>Both the resource bundle inheritance and the inherited item
inheritance use the parentLocale data, where available, instead of
simple trunctation.</p>
<p>The fallback is a bit different for these two cases; internal
aliases and keys are are not involved in the bundle lookup, and the
default locale is not involved in the item lookup. If the
default-locale were used in the resource-item lookup, then strange
results will occur. For example, suppose that the default locale is
Swedish, and there is a Nama locale but no specific inherited item
for collation. If the default-locale were used in resource-item
lookup, it would produce odd and unexpected results for Nama sorting.
</p>
<p>The default locale is not even always used in resource bundle
inheritance. For the following services, the fallback is always
directly to the root locale rather than through default locale.</p>
<ul>
<li>collation</li>
<li>break iteration</li>
<li>case mapping</li>
<li>transliteration
<ul>
<li>The lookup for transliteration is yet more complicated
because of the interplay of source and target locales: see <em>Part
2 General, Section 10.1 <a
href="http://www.unicode.org/reports/tr35/tr35-general.html#Inheritance">Inheritance.</a>
</em>
</li>
</ul>
</li>
</ul>
<p>
Thus if there is no Akan locale, for example, asking for a collation
for Akan should produce the root collation, <em>not the Swedish
collation.</em>
</p>
<p>The inherited item lookup must remain stable, because the
resources are built with a certain fallback in mind; changing the
core fallback order can render the bundle structure incoherent.</p>
<p>
Resource bundle lookup, on the other hand, is more flexible; changes
in the view of the &quot;best&quot; match between the input request
and the output bundle are more tolerant, when represent overall
improvements for users. For more information, see <i> <a
href="#Fallback_Elements">A.1 Element fallback</a></i>.
</p>
<p>
Where the LDML inheritance relationship does not match a target
system, such as POSIX, the data logically should be fully resolved in
converting to a format for use by that system, by adding <i>all</i>
inherited data to each locale data set.
</p>
<p>
For a more complete description of how inheritance applies to data,
and the use of keywords, see <i><a
href="#Inheritance_and_Validity">Section 4.2 Inheritance </a></i>.
</p>
<p>
The locale data does not contain general character properties that
are derived from the <i>Unicode Character Database</i> [<a
href="http://unicode.org/reports/tr41/#UAX44">UAX44</a>]. That data
being common across locales, it is not duplicated in the bundles.
Constructing a POSIX locale from the CLDR data requires use of UCD
data. In addition, POSIX locales may also specify the character
encoding, which requires the data to be transformed into that target
encoding.
</p>
<p>
<b>Warning: </b>If a locale has a different script than its parent
(for example, sr_Latn), then special attention must be paid to make
sure that all inheritance is covered. For example, auxiliary exemplar
characters may need to be empty (&quot;[]&quot;) to block
inheritance.
</p>
<p>
<strong>Empty Override:</strong> There is one special value reserved
in LDML to indicate that a child locale is to have no value for a
path, even if the parent locale has a value for that path. That value
is &quot;∅∅∅&quot;. For example, if there is no phrase for &quot;two
days ago&quot; in a language, that can be indicated with:
</p>
<pre>&lt;field type="day"&gt;
&lt;relative type="-2"&gt;∅∅∅&lt;/relative&gt;
</pre>
<h4>
<a name="Multiple_Inheritance"></a><a name="Lateral_Inheritance"
href="#Lateral_Inheritance">4.1.2 Lateral Inheritance </a>
</h4>
<p>
In clearly specified instances, resources may inherit from within the
same locale. For example, currency format symbols inherit from the
number format symbols; the Buddhist calendar inherits from the
Gregorian calendar. This <i>only</i> happens where documented in this
specification. In these special cases, the inheritance functions as
normal, up to the root. If the data is not found along that path,
then a second search is made, logically changing the
element/attribute to the alternate values.
</p>
<p>
For example, for the locale &quot;en_US&quot; the month data in
&lt;calendar class=&quot;<span style="color: blue">buddhist</span>&quot;&gt;
inherits first from &lt;calendar class=&quot;<span
style="color: blue">buddhist</span>&quot;&gt; in &quot;en&quot;,
then in &quot;root&quot;. If not found there, then it inherits from
&lt;calendar type=&quot;<span style="color: blue">gregorian</span>&quot;&gt;
in &quot;en_US&quot;, then &quot;en&quot;, then in &quot;root&quot;.
</p>
<p>There is one special case, for items with a &quot;count&quot;
parameter (used to select a plural form). In that case, the
inheritance works as follows:</p>
<p>If there is no value for a path, and that path has a
[@count=&quot;x&quot;] attribute and value, then:</p>
<ol>
<li>If &quot;x&quot; is anything but &quot;other&quot;, it falls
back to [@count=&quot;other&quot;], within that the same locale.</li>
<li>In the special case of currencies, if the
[@count=&quot;other&quot;] value is missing, it falls back to the
path that is completely missing the count item.</li>
<li>If there is no value within the same locale, the same
process is used in the parent locale, and so on.</li>
</ol>
<p>
<em>Examples:</em>
</p>
<table class='simple' border="1" cellpadding="3" cellspacing="0" id="a1bn3">
<caption>
<a name="Count_Fallback_normal" href="#Count_Fallback_normal">Count
Fallback: normal</a>
</caption>
<tbody>
<tr>
<th nowrap style="vertical-align: top;">Locale</th>
<th nowrap style="vertical-align: top;">Path</th>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr-CA</td>
<td nowrap id="iqaw" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr-CA</td>
<td nowrap id="iqaw16" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="other"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr</td>
<td nowrap id="iqaw19" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr</td>
<td nowrap id="iqaw18" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="other"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">root</td>
<td nowrap id="iqaw21" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">root</td>
<td nowrap id="iqaw20" style="vertical-align: top;"><code>
//ldml/units/unitLength[@type="<strong>narrow</strong>"]/unit[@type="mass-gram"]/unitPattern<strong>[@count="other"]</strong>
</code></td>
</tr>
</tbody>
</table>
<p>Note that there may be an alias in root that changes the path
and starts again from the requested locale, such as:</p>
<p>
<code>
&lt;unitLength type=&quot;<strong>narrow</strong>&quot;&gt;<br>
   &lt;alias source=&quot;locale&quot;
path=&quot;../unitLength[@type='<strong>short</strong>']&quot;/&gt;<br>
&lt;/unitLength&gt;
</code>
</p>
<table class='simple' border="1" cellpadding="3" cellspacing="0" id="a1bn2">
<caption>
<a name="Count_Fallback_currency" href="#Count_Fallback_currency">Count
Fallback: currency</a>
</caption>
<tbody>
<tr>
<th nowrap style="vertical-align: top;">Locale</th>
<th nowrap style="vertical-align: top;">Path</th>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr-CA</td>
<td nowrap id="iqaw11" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr-CA</td>
<td nowrap id="iqaw6" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="other"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr-CA</td>
<td nowrap id="iqaw8" style="vertical-align: top;"><code>//ldml/numbers/currencies/currency[@type="CAD"]/displayName</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr</td>
<td nowrap id="iqaw15" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr</td>
<td nowrap id="iqaw14" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="other"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">fr</td>
<td nowrap id="iqaw13" style="vertical-align: top;"><code>//ldml/numbers/currencies/currency[@type="CAD"]/displayName</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">root</td>
<td nowrap id="iqaw25" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="x"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">root</td>
<td nowrap id="iqaw24" style="vertical-align: top;"><code>
//ldml/numbers/currencies/currency[@type="CAD"]/displayName<strong>[@count="other"]</strong>
</code></td>
</tr>
<tr>
<td nowrap style="vertical-align: top;">root</td>
<td nowrap id="iqaw23" style="vertical-align: top;"><code>//ldml/numbers/currencies/currency[@type="CAD"]/displayName</code></td>
</tr>
</tbody>
</table>
<br>
<h4>
<a name="Parent_Locales" href="#Parent_Locales">4.1.3 Parent
Locales</a>
</h4>
<p class="dtd">
&lt;!ELEMENT parentLocales ( parentLocale* ) &gt;<br>
&lt;!ELEMENT parentLocale EMPTY &gt;<br> &lt;!ATTLIST
parentLocale parent NMTOKEN #REQUIRED
&gt;<br> &lt;!ATTLIST parentLocale locales NMTOKENS #REQUIRED &gt;
</p>
<p>In some cases, the normal truncation inheritance does not
function well. This happens when:</p>
<ol>
<li>The child locale is of a different script. In this case,
mixing elements from the parent into the child data results in a
mishmash.</li>
<li>A large number of child locales behave similarly, and
differently from the truncation parent.</li>
</ol>
<p>
The <span class="element">parentLocale</span> element is used to
override the normal inheritance when accessing CLDR data.
</p>
<p>For case 1, the children are script locales, and the parent is
&quot;root&quot;. For example:</p>
<pre> &lt;parentLocale parent=&quot;root&quot; locales=&quot;az_Cyrl ha_Arab … zh_Hant&quot;/&gt;</pre>
<p>For case 2, the children and parent share the same primary
language, but the region is changed. For example:</p>
<pre> &lt;parentLocale parent=&quot;es_419&quot; locales=&quot;es_AR es_BO … es_UY es_VE&quot;/&gt;</pre>
<p>Collation data, however, is an exception. Since collation rules
do not truly inherit data from the parent, the parentLocale element
is not necessary and not used for collation. Thus, for a locale like
zh_Hant in the example above, the parentLocale element would dictate
the parent as &quot;root&quot; when referring to main locale data,
but for collation data, the parent locale would still be
&quot;zh&quot;, even though the parentLocale element is present for
that locale.</p>
<p>
Since parentLocale information is not localizable on a per locale
basis, the parentLocale information is contained in CLDR’s <a
href="tr35-info.html">supplemental data.</a>
</p>
<p>
When a <span class="element">parentLocale</span> element is used to
override normal inheritance, the following invariants must always be
true:
</p>
<ol>
<li>If X is the parentLocale of Y, then either X is the root
locale, or X has the same base language code as Y. For example, the
parent of &quot;en&quot; cannot be &quot;fr&quot;, and the parent of
&quot;en_YY&quot; cannot be &quot;fr&quot; or &quot;fr_XX&quot;.</li>
<li>If X is the parentLocale of Y, Y must not be a base language
locale. For example, the parent of &quot;en&quot; cannot be
&quot;en_XX&quot;.</li>
<li>There can never be cycles, such as: X parent of Y ... parent
of X.</li>
</ol>
<h3>
<a name="Inheritance_and_Validity" href="#Inheritance_and_Validity">4.2
Inheritance and Validity</a>
</h3>
<p>The following describes in more detail how to determine the
exact inheritance of elements, and the validity of a given element in
LDML.</p>
<h4>
<a name="Definitions" href="#Definitions">4.2.1 Definitions</a>
</h4>
<p>
<i>Blocking</i> elements are those whose subelements do not inherit
from parent locales. For example, a &lt;collation&gt; element is a
blocking element: everything in a &lt;collation&gt; element is
treated as a single lump of data, as far as inheritance is concerned.
For more information, see <a href="#Valid_Attribute_Values">Section
5.5 Valid Attribute Values</a>.
</p>
<p>
Attributes that serve to distinguish multiple elements at the same
level are called <i>distinguishing</i> attributes. For example, the <i>type</i>
attribute distinguishes different elements in lists of translations,
such as:
</p>
<pre>&lt;language type=&quot;aa&quot;&gt;Afar&lt;/language&gt;
&lt;language type=&quot;ab&quot;&gt;Abkhazian&lt;/language&gt;</pre>
<p>
Distinguishing attributes affect inheritance; two elements with
different distinguishing attributes are treated as different for
purposes of inheritance. For more information, see <a
href="#Valid_Attribute_Values">Section 5.5 Valid Attribute
Values</a>. Other attributes are called nondistinguishing (or
informational) attributes. These carry separate information, and do
not affect inheritance.
</p>
<p>
For any element in an XML file, <i>an element chain</i> is a resolved
[<a href="#XPath">XPath</a>] leading from the root to an element,
with attributes on each element in alphabetical order. So in, say, <a
href="http://unicode.org/cldr/data/common/main/el.xml">http://unicode.org/cldr/data/common/main/el.xml</a>
we may have:
</p>
<pre>&lt;ldml&gt;
&lt;identity&gt;
&lt;version number=&quot;1.1&quot; /&gt;
&lt;language type=&quot;el&quot; /&gt;
&lt;/identity&gt;
&lt;localeDisplayNames&gt;
&lt;languages&gt;
&lt;language type=&quot;ar&quot;&gt;Αραβικά&lt;/language&gt;
...</pre>
<p>Which gives the following element chains (among others):</p>
<ul>
<li>//ldml/identity/version[@number=&quot;1.1&quot;]</li>
<li>//ldml/localeDisplayNames/languages/language[@type=&quot;ar&quot;]</li>
</ul>
<p>
An element chain A is an <i>extension</i> 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
&quot;identical to&quot;. See below for an example.)
</p>
<ol>
<li>//ldml/localeDisplayNames</li>
<li>//ldml/localeDisplayNames/languages/language[@type=&quot;ar&quot;]</li>
</ol>
<p>
An LDML file can be thought of as an ordered list of <i>element
pairs</i>: &lt;element chain, data&gt;, 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 does not allow mixed
content.) The ordering is the ordering that the element chains are
found in the file, and thus determined by the DTD.
</p>
<p>For example, some of those pairs would be the following. Notice
that the first has the null string as element contents.</p>
<ul>
<li><b>&lt;</b>//ldml/identity/version[@number=&quot;1.1&quot;]<b>,
</b>&quot;&quot;<b>&gt;</b></li>
<li><b>&lt;</b>//ldml/localeDisplayNames/languages/language[@type=&quot;ar&quot;]<b>,
</b>&quot;Αραβικά&quot;<b>&gt;</b></li>
</ul>
<blockquote>
<p>
<b>Note: </b>There are two exceptions to this:
</p>
<ol>
<li>Blocking nodes and their contents are treated as a single
end node.</li>
<li>In terms of computing inheritance, the element pair
consists of the element chain plus all distinguishing attributes;
the value consists of the value (if any) plus any nondistinguishing
attributes.</li>
</ol>
<blockquote>
<p>Thus instead of the element pair being (a) below, it is (b):</p>
<ol type="a">
<li><b>&lt;</b>//ldml/dates/calendars/calendar[@type=&#39;gregorian&#39;]/week/weekendStart[@day=&#39;sun&#39;][@time=&#39;00:00&#39;]<b>,</b><br>
<b>&quot;&quot;&gt;</b></li>
<li><b>&lt;</b>//ldml/dates/calendars/calendar[@type=&#39;gregorian&#39;]/week/weekendStart<b>,</b><br>
[@day=&#39;sun&#39;][@time=&#39;00:00&#39;]<b>&gt;</b></li>
</ol>
</blockquote>
</blockquote>
<p>
Two LDML element chains are <i>equivalent</i> when they would be
identical if all attributes and their values were removed — except
for distinguishing attributes. Thus the following are equivalent:
</p>
<ul>
<li><code>//ldml/localeDisplayNames/languages/language[@type=&quot;ar&quot;]</code></li>
<li><code>//ldml/localeDisplayNames/languages/language[@type=&quot;ar&quot;][@draft=&quot;unconfirmed&quot;]</code></li>
</ul>
<p>
For any locale ID, an <i>locale chain</i> is an ordered list starting
with the root and leading down to the ID. For example:
</p>
<blockquote>
<p>&lt;root, de, de_DE, de_DE_xxx&gt;</p>
</blockquote>
<h4>
<a name="Resolved_Data_File" href="#Resolved_Data_File">4.2.2
Resolved Data File</a>
</h4>
<p>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.</p>
<ol>
<li>Let Result be initially L.</li>
<li>For each Li in the locale chain for L, starting at L and
going up to root:
<ol>
<li>Let Temp be a copy of the pairs in the LDML file for Li</li>
<li>Replace each alias in Temp by the resolved list of pairs
it points to.
<ol>
<li>The resolved list of pairs is obtained by recursively
applying this procedure.</li>
<li>That alias now blocks any inheritance from the parent.
(See <i><a href="#Common_Elements">Section 5.1 Common
Elements</a></i> for an example.)
</li>
</ol>
</li>
<li>For each element pair P in Temp:
<ol>
<li>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.</li>
</ol>
</li>
</ol>
</li>
</ol>
<p>
<b>Notes:</b>
</p>
<ul>
<li>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.</li>
<li>The identity element and its children are unaffected by
resolution.</li>
<li>The LDML data must be constructed so as to avoid circularity
in step 2.2.</li>
</ul>
<h4>
<a name="Valid_Data" href="#Valid_Data">4.2.3 Valid Data</a>
</h4>
<p>
The attribute <i>draft=&quot;x&quot; </i>in LDML means that the data
has not been approved by the subcommittee. (For more information, see
<a href="http://cldr.unicode.org/index/process">Process</a>).
However, some data that is not explicitly marked as <i>draft </i>may
be implicitly <i>draft</i>, either because it inherits it from a
parent, or from an enclosing element.
</p>
<p>
<b>Example 2. </b>Suppose that new locale data is added for af
(Afrikaans). To indicate that all of the data is <i>unconfirmed</i>,
the attribute can be added to the top level.
</p>
<p>
<code>
&lt;ldml version=&quot;1.1&quot; draft=&quot;unconfirmed&quot;&gt;<br>
&nbsp;&lt;identity&gt;<br> &nbsp; &lt;version
number=&quot;1.1&quot; /&gt; <br> &nbsp; &lt;language
type=&quot;af&quot; /&gt; <br> &nbsp;&lt;/identity&gt;<br>
&nbsp;&lt;characters&gt;...&lt;/characters&gt;<br>
&nbsp;&lt;localeDisplayNames&gt;...&lt;/localeDisplayNames&gt;<br>
&lt;/ldml&gt;
</code>
</p>
<p>
Any data can be added to that file, and the status will all be draft=<i>unconfirmed</i>.
Once an item is vetted—<i>whether it is inherited or explicitly
in the file</i>—then its status can be changed to <i>approved</i>. This
can be done either by leaving draft=&quot;unconfirmed&quot; on the
enclosing element and marking the child with
draft=&quot;approved&quot;, such as:
</p>
<p>
<code>
&lt;ldml version=&quot;1.1&quot; draft=&quot;unconfirmed&quot;&gt;<br>
&nbsp;&lt;identity&gt;<br> &nbsp; &lt;version
number=&quot;1.1&quot; /&gt; <br> &nbsp; &lt;language
type=&quot;af&quot; /&gt; <br> &nbsp;&lt;/identity&gt;<br>
&nbsp;&lt;characters
draft=&quot;approved&quot;&gt;...&lt;/characters&gt;<br>
&nbsp;&lt;localeDisplayNames&gt;...&lt;/localeDisplayNames&gt;<br>
&nbsp;&lt;dates/&gt;<br> &nbsp;&lt;numbers/&gt;<br>
&nbsp;&lt;collations/&gt;<br> &lt;/ldml&gt;
</code>
</p>
<p>
However, normally the draft attributes should be canonicalized, which
means they are pushed down to leaf nodes as described in <i><a
href="#Canonical_Form">Section 5.6 Canonical Form</a></i>. If an LDML
file does has draft attributes that are not on leaf nodes, the file
should be interpreted as if it were the canonicalized version of that
file.
</p>
<p>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.</p>
<h4>
<a name="Checking_for_Draft_Status" href="#Checking_for_Draft_Status">4.2.4
Checking for Draft Status</a>
</h4>
<ol>
<li><b>Parent Locale Inheritance</b>
<ol>
<li>Walk through the locale chain until you find a locale ID
L&#39; with a data file D. (L&#39; may equal L).</li>
<li>Produce the fully resolved data file D&#39; for D.</li>
<li>In D&#39;, find the first element pair whose element chain
E&#39; is either equivalent to or an extension of E.</li>
<li>If there is no such E&#39;, return <i>true</i></li>
<li>If E&#39; is not equivalent to E, truncate E&#39; to the
length of E.</li>
</ol></li>
<li><b>Enclosing Element Inheritance</b>
<ol>
<li>Walk through the elements in E&#39;, from back to front.
<ol>
<li>If you ever encounter draft=<i>x</i>, return <i>x</i></li>
</ol>
</li>
<li>If L&#39; = L, return <i>false</i></li>
</ol></li>
<li><b>Missing File Inheritance</b>
<ol>
<li>Otherwise, walk again through the elements in E&#39;, from
back to front.
<ol>
<li>If you encounter a validSubLocales attribute
(deprecated):
<ol>
<li>If L is in the attribute value, return <i>false</i></li>
<li>Otherwise return <i>true</i></li>
</ol>
</li>
</ol>
</li>
</ol></li>
<li><b>Otherwise</b>
<ol>
<li>Return <i>true</i></li>
</ol></li>
</ol>
<p>The validSubLocales in the most specific (farthest from root
file) locale file &quot;wins&quot; through the full resolution step
(data from more specific files replacing data from less specific
ones).</p>
<h4>
<a name="Keyword_and_Default_Resolution"
href="#Keyword_and_Default_Resolution">4.2.5 Keyword and Default
Resolution</a>
</h4>
<p>When accessing data based on keywords, the following process is
used. Consider the following example:</p>
<ul>
<li>The locale &#39;de&#39; has collation types A, B, C, and no
&lt;default&gt; element</li>
<li>The locale &#39;de_CH&#39; has &lt;default
type=&#39;B&#39;&gt;</li>
</ul>
<p>Here are the searches for various combinations.</p>
<table class='simple' border="1" cellpadding="0" cellspacing="0">
<tr>
<td><strong>User Input</strong></td>
<td><strong>Lookup in Locale</strong></td>
<td><strong>For</strong></td>
<td><strong>Comment</strong></td>
</tr>
<tr>
<td rowspan="3">de_CH<br> <em>no keyword</em></td>
<td>de_CH</td>
<td>default collation type</td>
<td>finds &quot;B&quot;</td>
</tr>
<tr>
<td>de_CH</td>
<td>collation type=B</td>
<td>not found</td>
</tr>
<tr>
<td>de</td>
<td>collation type=B</td>
<td><em>found</em></td>
</tr>
<tr>
<td rowspan="4">de<br> <em>no keyword</em></td>
<td>de</td>
<td>default collation type</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>default collation type</td>
<td>finds &quot;standard&quot;</td>
</tr>
<tr>
<td>de</td>
<td>collation type=standard</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>collation type=standard</td>
<td><i>found</i></td>
</tr>
<tr>
<td>de_u_co_A</td>
<td>de</td>
<td>collation type=A</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="2">de_u_co_standard</td>
<td>de</td>
<td>collation type=standard</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>collation type=standard</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="6">de_u_co_foobar</td>
<td>de</td>
<td>collation type=foobar</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>collation type=foobar</td>
<td>not found, starts looking for default</td>
</tr>
<tr>
<td>de</td>
<td>default collation type</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>default collation type</td>
<td>finds &quot;standard&quot;</td>
</tr>
<tr>
<td>de</td>
<td>collation type=standard</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>collation type=standard</td>
<td><i>found</i></td>
</tr>
</table>
<p>Examples of &quot;search&quot; collator lookup; 'de' has a
language-specific version, but 'en' does not:</p>
<table class='simple' border="1" cellpadding="0" cellspacing="0">
<tr>
<td><strong>User Input</strong></td>
<td><strong>Lookup in Locale</strong></td>
<td><strong>For</strong></td>
<td><strong>Comment</strong></td>
</tr>
<tr>
<td rowspan="2">de_CH_u_co_search</td>
<td>de_CH</td>
<td>collation type=search</td>
<td>not found</td>
</tr>
<tr>
<td>de</td>
<td>collation type=search</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="3">en_US_u_co_search</td>
<td>en_US</td>
<td>collation type=search</td>
<td>not found</td>
</tr>
<tr>
<td>en</td>
<td>collation type=search</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>collation type=search</td>
<td><i>found</i></td>
</tr>
</table>
<p>Examples of lookup for Chinese collation types. Note:</p>
<ul>
<li>All of the Chinese-specific collation types are provided in
the 'zh' locale</li>
<li>For 'zh' the &lt;default&gt; element specifies
&quot;pinyin&quot;; for 'zh_Hant' the &lt;default&gt; element
specifies &quot;stroke&quot;. However any of the available Chinese
collation types can be explicitly requested for any Chinese locale.</li>
</ul>
<table class='simple' border="1" cellpadding="0" cellspacing="0">
<tr>
<td><strong>User Input</strong></td>
<td><strong>Lookup in Locale</strong></td>
<td><strong>For</strong></td>
<td><strong>Comment</strong></td>
</tr>
<tr>
<td rowspan="3">zh_Hant<br> <em>no keyword</em></td>
<td>zh_Hant</td>
<td>default collation type</td>
<td>finds &quot;stroke&quot;</td>
</tr>
<tr>
<td>zh_Hant</td>
<td>collation type=stroke</td>
<td>not found</td>
</tr>
<tr>
<td>zh</td>
<td>collation type=stroke</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="3">zh_Hant_HK_u_co_pinyin</td>
<td>zh_Hant_HK</td>
<td>collation type=pinyin</td>
<td>not found</td>
</tr>
<tr>
<td>zh_Hant</td>
<td>collation type=pinyin</td>
<td>not found</td>
</tr>
<tr>
<td>zh</td>
<td>collation type=pinyin</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="2">zh<br> <em>no keyword</em></td>
<td>zh</td>
<td>default collation type</td>
<td>finds &quot;pinyin&quot;</td>
</tr>
<tr>
<td>zh</td>
<td>collation type=pinyin</td>
<td><i>found</i></td>
</tr>
</table>
<blockquote>
<p>
<b>Note: </b>It is an invariant that the default in root for a given
element must<br> always be a value that exists in root. So you
can not have the following in root:
</p>
</blockquote>
<p>
<code>
&lt;someElements&gt;<br> &nbsp; &lt;default
type=&#39;a&#39;/&gt;<br> &nbsp; &lt;someElement
type=&#39;b&#39;&gt;...&lt;/someElement&gt;<br> &nbsp;
&lt;someElement type=&#39;c&#39;&gt;...&lt;/someElement&gt;<br>
<b>&nbsp; &lt;!-- no &#39;a&#39; --&gt;</b><br>
&lt;/someElements&gt;
</code>
</p>
<p>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 &#39;QA&#39; in root, then the display name is simply
&#39;QA&#39;. </p>
<h4>
<a name="Inheritance_vs_Related" href="#Inheritance_vs_Related">4.2.6 Inheritance vs Related Information</a>
</h4>
<p>There are related types of data and processing that are easy to confuse:</p>
<table class='simple'>
<tr>
<td rowspan="4"><p><strong>Inheritance</strong></p></td>
<td colspan="2">Part of the internal mechanism used by CLDR to organize and manage locale data.
This is used to share common resources, and ease maintenance, and provide the best fallback behavior in the absence of data. <em>Should not be used for locale matching or likely subtags.</em></td>
</tr>
<tr>
<td><em>Example:</em></td>
<td>parent(en_AU) ⇒ en_001<br>
parent(en_001) ⇒ en<br>
parent(en) ⇒ root</td>
</tr>
<tr>
<td><em>Data: </em></td>
<td>supplementalData.xml &lt;parentLocale&gt;</td>
</tr>
<tr>
<td><em>Spec:</em></td>
<td><strong>Section <a href="#Inheritance_and_Validity">4.2 Inheritance and Validity</a></strong></td>
</tr>
<tr>
<td rowspan="4"><strong>DefaultContent</strong></td>
<td colspan="2">Part of the internal mechanism used by CLDR to manage locale data. A particular sublocale is designated the defaultContent for a parent, so that the parent exhibits consistent behavior. <em>Should not be used for locale matching or likely subtags.</em></td>
</tr>
<tr>
<td><em>Example:</em></td>
<td>addLikelySubtags(sr-ME) ⇒ sr-Latn-ME, minimize(de-Latn-DE) ⇒ de</td>
</tr>
<tr>
<td><em>Data: </em></td>
<td>supplementalMetadata.xml &lt;defaultContent&gt;</td>
</tr>
<tr>
<td><em>Spec:</em></td>
<td><strong>Part 6: Section 9.3 <a href="tr35-info.html#Default_Content">Default Content</a>
</strong></td>
</tr>
<tr>
<td rowspan="4"><strong>LikelySubtags</strong></td>
<td colspan="2">Provides most likely full subtag (script and region) in the absence of other information. A core component of LocaleMatching.</td>
</tr>
<tr>
<td><em>Example:</em></td>
<td>addLikelySubtags(zh) ⇒ zh-Hans-CN<br>
addLikelySubtags(zh-TW) ⇒ zh-Hant-TW <br>
minimize(zh-Hans, favorRegion) ⇒ zh-TW</td>
</tr>
<tr>
<td><em>Data: </em></td>
<td>likelySubtags.xml &lt;likelySubtags&gt;</td>
</tr>
<tr>
<td><em>Spec:</em></td>
<td><strong>Section <a href="#Likely_Subtags">4.3 Likely
Subtags</a></strong></td>
</tr>
<tr>
<td rowspan="4"><strong>LocaleMatching</strong></td>
<td colspan="2">Provides the best match for the user’s language(s) among an application’s supported languages. </td>
</tr>
<tr>
<td><em>Example:</em></td>
<td>bestLocale(userLangs=&lt;en, fr&gt;, appLangs=&lt;fr-CA, ru&gt;) ⇒ fr-CA</td>
</tr>
<tr>
<td><em>Data: </em></td>
<td>languageInfo.xml &lt;languageMatching&gt;</td>
</tr>
<tr>
<td><em>Spec:</em></td>
<td><strong>Section
<a href="#LanguageMatching">4.4 Language Matching</a></strong></td>
</tr>
</table>
<h3>
<a name="Likely_Subtags" href="#Likely_Subtags">4.3 Likely
Subtags</a>
</h3>
<p class="dtd">
&lt;!ELEMENT likelySubtag EMPTY &gt;<br> &lt;!ATTLIST
likelySubtag from NMTOKEN #REQUIRED&gt;<br> &lt;!ATTLIST
likelySubtag to NMTOKEN #REQUIRED&gt;
</p>
<p>There are a number of situations where it is useful to be able
to find the most likely language, script, or region. For example,
given the language &quot;zh&quot; and the region &quot;TW&quot;, what
is the most likely script? Given the script &quot;Thai&quot; what is
the most likely language or region? Given the region TW, what is the
most likely language and script?</p>
<p>Conversely, given a locale, it is useful to find out which
fields (language, script, or region) may be superfluous, in the sense
that they contain the likely tags. For example, &quot;en_Latn&quot;
can be simplified down to &quot;en&quot; since &quot;Latn&quot; is
the likely script for &quot;en&quot;; &quot;ja_Jpan_JP&quot; can be
simplified down to &quot;ja&quot;.</p>
<p>
The <i>likelySubtag</i> supplemental data provides default
information for computing these values. This data is based on the
default content data, the population data, and the the
suppress-script data in [<a href="#BCP47">BCP47</a>]. It is
heuristically derived, and may change over time.
</p>
<p>For the relationship between Inheritance, DefaultContent, LikelySubtags, and LocaleMatching, see <strong><em>Section 4.2.6 <a
href="tr35.html#Inheritance_vs_Related">Inheritance vs Related Information</a></em></strong>.</p>
<p>
To look up data in the table, see if a locale matches one of the <b>from</b>
attribute values. If so, fetch the corresponding <b>to</b> attribute
value. For example, the Chinese data looks like the following:
</p>
<blockquote>
<p class="example">
&lt;likelySubtag from=&quot;zh&quot; to=&quot;zh_Hans_CN&quot;/&gt;<br>
&lt;likelySubtag from=&quot;zh_HK&quot;
to=&quot;zh_Hant_HK&quot;/&gt;<br> &lt;likelySubtag
from=&quot;zh_Hani&quot; to=&quot;zh_Hani_CN&quot;/&gt;<br>
&lt;likelySubtag from=&quot;zh_Hant&quot;
to=&quot;zh_Hant_TW&quot;/&gt;<br> &lt;likelySubtag
from=&quot;zh_MO&quot; to=&quot;zh_Hant_MO&quot;/&gt;<br>
&lt;likelySubtag from=&quot;zh_TW&quot;
to=&quot;zh_Hant_TW&quot;/&gt;
</p>
</blockquote>
<p>So looking up &quot;zh_TW&quot; returns &quot;zh_Hant_TW&quot;,
while looking up &quot;zh&quot; returns &quot;zh_Hans_CN&quot;.</p>
<p>In more detail, the data is designed to be used in the
following operations.</p>
<p>
Note that as of CLDR v24, any field present in the 'from' field, is
also present in the 'to' field, so an input field will not change in
&quot;Add Likely Subtags&quot; operation. The data and operations can
also be used with language tags using [<a href="#BCP47">BCP47</a>]
syntax, with the appropriate changes. In addition, certain common
'denormalized' language subtags such as 'iw' (for 'he') may occur in
both the 'from' and 'to' fields. This allows for implementations that
use those denormalized subtags to use the data with only minor
changes to the operations.
</p>
<p>&nbsp;</p>
<p>
<i><b>Add Likely Subtags: </b></i><em>Given a source locale X,
to return a locale Y where the empty subtags have been filled in by
the most likely subtags.</em> This is written as X ⇒ Y (&quot;X maximizes
to Y&quot;).
</p>
<p>
A subtag is called <em>empty</em> if it is a missing script or region
subtag, or it is a base language subtag with the value
&quot;und&quot;. In the description below, a subscript on a subtag <em>x</em>
indicates which tag it is from: <em>x<sub>s</sub></em> is in the
source, <em>x<sub>m</sub></em>is in a match, and <em>x<sub>r</sub></em>
is in the final result.
</p>
<p>This operation is performed in the following way.</p>
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><strong>Canonicalize.</strong>
<ol>
<li>Make sure the input locale is in canonical form: uses the
right separator, and has the right casing.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Replace
any deprecated subtags with their canonical values using the
&lt;alias&gt; data in supplemental metadata. Use the first value
in the replacement list, if it exists. Language tag replacements
may have multiple parts, such as &quot;sh&quot; ➞
&quot;sr_Latn&quot; or mo&quot; ➞ &quot;ro_MD&quot;. In such a
case, the original script and/or region are retained if there is
one. Thus &quot;sh_Arab_AQ&quot; ➞ &quot;sr_Arab_AQ&quot;, not
&quot;sr_Latn_AQ&quot;.</li>
<li>If the tag is grandfathered (see &lt;variable
id=&quot;$grandfathered&quot; type=&quot;choice&quot;&gt; in the
supplemental data), then return it.</li>
<li>Remove the script code &#39;Zzzz&#39; and the region code
&#39;ZZ&#39; if they occur.</li>
<li>Get the components of the cleaned-up source tag <em>(language<sub>s</sub>,
script<sub>s</sub>,
</em>and<em> region<sub>s</sub></em>), plus any variants and extensions.
</li>
</ol></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><strong>Lookup.
</strong>Lookup each of the following in order, and stop on the first match:
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><em>language<sub>s</sub>_script<sub>s</sub>_region<sub>s</sub></em></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><em>language<sub>s</sub>_region<sub>s</sub></em></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><em>language<sub>s</sub>_script<sub>s</sub></em></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><em><em>language<sub>s</sub></em></em></li>
<li>und<em>_script<sub>s</sub></em></li>
</ol></li>
<li><strong>Return</strong>
<ol>
<li>If there is no match,either return
<ol>
<li>an error value, or</li>
<li>the match for &quot;und&quot; (in APIs where a valid
language tag is required).</li>
</ol>
</li>
<li>Otherwise there is a match = <span
style="margin-top: 0.5em; margin-bottom: 0.5em"><em>language<sub>m</sub>_script<sub>m</sub>_region<sub>m</sub></em></span></li>
<li>Let x<sub>r</sub> = x<sub>s</sub> if x<sub>s</sub> is not
empty, and x<sub>m</sub> otherwise.
</li>
<li>R<span style="margin-top: 0.5em; margin-bottom: 0.5em">eturn
the language tag composed of <em>language<sub>r</sub> _
script<sub>r</sub> _ region<sub>r</sub></em> + variants + extensions
</span>.
</li>
</ol></li>
</ol>
<p>The lookup can be optimized. For example, if any of the tags in
Step 2 are the same as previous ones in that list, they do not need
to be tested.</p>
<p>
<i>Example1:</i>
</p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>Input is ZH-ZZZZ-SG.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>Normalize to zh_SG.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>Lookup in table. No match.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>Lookup zh, and get the match (zh_Hans_CN). Substitute SG, and
return zh_Hans_SG.</p>
</li>
</ul>
<p>To find the most likely language for a country, or language for
a script, use &quot;und&quot; as the language subtag. For example,
looking up &quot;und_TW&quot; returns zh_Hant_TW.</p>
<p>A goal of the algorithm is that if X ⇒ Y, and X' results from
replacing an empty subtag in X by the the corresponding subtag in Y,
then X' ⇒ Y. For example, if und_AF ⇒ fa_Arab_AF, then:</p>
<ul>
<li>fa_Arab_AF ⇒ fa_Arab_AF</li>
<li>und_Arab_AF ⇒ fa_Arab_AF</li>
<li>fa_AF ⇒ fa_Arab_AF</li>
</ul>
<p>There are a small number of exceptions to this goal in the
current data, where X ∈ {und_Bopo, und_Brai, und_Cakm, und_Limb,
und_Shaw}.</p>
<p>
<b><i>Remove</i></b><i><b> Likely Subtags: </b>Given a locale,
remove any fields that Add Likely Subtags would add.</i>
</p>
<p>The reverse operation removes fields that would be added by the
first operation.</p>
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">First get
max = AddLikelySubtags(inputLocale). If an error is signaled, return
it.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Remove the
variants from max.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Then for <i>trial</i>
in {language, language _ region, language _ script}
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">If
AddLikelySubtags(<i>trial</i>) = max, then return <i>trial</i> +
variants.
</li>
</ul>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">If you do
not get a match, return max + variants.</li>
</ol>
<p>Example:</p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>Input is zh_Hant. Maximize to get zh_Hant_TW.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>zh =&gt; zh_Hans_CN. No match, so continue.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>zh_TW =&gt; zh_Hant_TW. Matches, so return zh_TW.</p>
</li>
</ul>
<p>A variant of this favors the script over the region, thus using
{language, language_script, language_region} in the above. If that
variant is used, then the result in this example would be zh_Hant
instead of zh_TW. </p>
<h3>
<a name="LanguageMatching" href="#LanguageMatching">4.4 Language
Matching</a>
</h3>
<p class="dtd">
&lt;!ELEMENT languageMatching ( languageMatches* ) &gt;<br>
&lt;!ELEMENT languageMatches ( paradigmLocales*, matchVariable*, languageMatch* ) &gt;<br>
&lt;!ATTLIST languageMatches type NMTOKEN #REQUIRED &gt;</p>
<p class="dtd">&lt;!ELEMENT languageMatch EMPTY &gt;<br> &lt;!ATTLIST
languageMatch desired CDATA #REQUIRED &gt;<br> &lt;!ATTLIST
languageMatch supported CDATA #REQUIRED &gt;<br> &lt;!ATTLIST
languageMatch percent NMTOKEN #REQUIRED &gt;<br>
&lt;!ATTLIST languageMatch distance NMTOKEN #IMPLIED &gt;<br>
&lt;!ATTLIST languageMatch oneway ( true | false ) #IMPLIED &gt;</p>
<p class="dtd">&lt;!ELEMENT languageMatches ( paradigmLocales*, matchVariable*, languageMatch* ) &gt;<br>
&lt;!ATTLIST languageMatches type NMTOKEN #REQUIRED &gt;</p>
<p class="dtd">&lt;!ELEMENT paradigmLocales EMPTY &gt;<br>
&lt;!ATTLIST paradigmLocales locales NMTOKENS #REQUIRED &gt;
</p>
<p>
Implementers are often faced with the issue of how to match the
user's requested languages with their product's supported languages.
For example, suppose that a product supports {ja-JP, de, zh-TW}. If
the user understands written American English, German, French, Swiss
German, and Italian, then <strong>de</strong> would be the best
match; if s/he understands only Chinese (zh), then zh-TW would be the
best match.
</p>
<p>The standard truncation-fallback algorithm does not work well
when faced with the complexities of natural language. The language
matching data is designed to fill that gap. Stated in those terms,
language matching can have the effect of a more complex fallback,
such as:</p>
<p>
sr-Cyrl-RS<br> sr-Cyrl<br> sr-Latn-RS<br> sr-Latn<br>
sr<br> hr-Latn<br> hr
</p>
<p>Language matching is used to find the best supported locale ID
given a requested list of languages. The requested list could come
from different sources, such as such as the user's list of preferred
languages in the OS Settings, or from a browser Accept-Language list.
For example, if my native tongue is English, I can understand Swiss
German and German, my French is rusty but usable, and Italian basic,
ideally an implementation would allow me to select {gsw, de, fr} as
my preferred list of languages, skipping Italian because my
comprehension is not good enough for arbitrary content.</p>
<p>Language Matching can also be used to get fallback data elements. In
many cases, there may not be full data for a particular locale. For
example, for a Breton speaker, the best fallback if data is
unavailable might be French. That is, suppose we have found a Breton
bundle, but it does not contain translation for the key &quot;CN&quot;
(for the country China). It is best to return &quot;chine&quot;,
rather than falling back to the value default language such as Russian
and getting &quot;Кітай&quot;.&nbsp; The language matching data can be
used to get the closest fallback locales (of those supported) to a
given language.
</p>
<p>For the relationship between Inheritance, DefaultContent, LikelySubtags, and LocaleMatching, see <strong><em>Section 4.2.6 <a
href="tr35.html#Inheritance_vs_Related">Inheritance vs Related Information</a></em></strong>.</p> <p>
When such fallback is used for inherited item lookup, the normal
order of inheritance is used for inherited item lookup, except that
before using any data from <strong>root</strong>, the data for the
fallback locales would be used if available. Language matching does
not interact with the fallback of resources <em>within the
locale-parent chain</em>. For example, suppose that we are looking for
the value for a particular path <strong>P</strong> in <strong>nb-NO</strong>.
In the absence of aliases, normally the following lookup is used.
</p>
<blockquote>
<p>
<strong>nb-NO</strong> → <strong>nb</strong> → <strong>root</strong>
</p>
</blockquote>
<p>
That is, we first look in <strong>nb-NO</strong>. If there is no
value for <strong>P</strong> there, then we look in <strong>nb</strong>.
If there is no value for <strong>P</strong> there, we return the
value for <strong>P</strong> in root (or a code value, if there is
nothing there). Remember that if there is an alias element along this
path, then the lookup may restart with a different path in <strong>nb-NO</strong>
(or another locale).
</p>
<p>
However, suppose that <strong>nb-NO</strong> has the fallback values
<strong>[nn da sv en]</strong>, derived from language matching. In
that case, an implementation <em>may</em> progressively lookup each
of the listed locales, with the appropriate substitutions, returning
the first value that is not found in <strong>root</strong>. This
follows roughly the following pseudocode:
</p>
<ul>
<li>value = lookup(P, nb-NO); if (locationFound != root) return
value;</li>
<li>value = lookup(P, nn-NO); if (locationFound != root) return
value;</li>
<li>value = lookup(P, da-NO); if (locationFound != root) return
value;</li>
<li>value = lookup(P, sv-NO); if (locationFound != root) return
value;</li>
<li>value = lookup(P, en-NO); return value;</li>
</ul>
<p>
The locales in the fallback list are not used recursively. For
example, for the lookup of a path in nb-NO, if <strong>fr</strong>
were a fallback value for <strong>da</strong>, it would not matter
for the above process. Only the original language matters.
</p>
<p>The language matching data is intended to be used according to
the following algorithm. This is a logical description, and can be
optimized for production in many ways. In this algorithm, the
languageMatching data is interpreted as an ordered list.</p>
<p>The language matching algorithm takes a list of a user’s
desired languages, and a list of the application’s supported
languages.</p>
<ul>
<li>Set the best weighted distance BWD to ∞</li>
<li>Set the best desired language BD to null</li>
<li>For each desired language D
<ul>
<li>Compute a discount factor F, based on the position in the
list.
<ul>
<li>This discount factor is up to the implementation, but is
typically a positive value that increases according to how far D
is from the start of the desired language list.</li>
</ul>
</li>
<li>For each supported language S
<ul>
<li>Find the matching distance MD as described below.</li>
<li>Compute the weighted distance as F + MD</li>
<li>If WD &lt; BD
<ul>
<li>BWD = WD</li>
<li>BD = D</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>If the BWD is less than a threshold, return BD.
<ul>
<li>The threshold is implementation-defined, typically set to
greater than a default region difference, and less than a default
script difference.</li>
</ul>
</li>
<li>Otherwise return a default supported language (like
English).</li>
</ul>
<p>To find the matching distance MD between any two languages,
perform the following steps.</p>
<ol>
<li>Maximize each language using Section 4.3 <a
href="#Likely_Subtags">Likely Subtags</a>.
<ul>
<li>und is a special case: see below.</li>
</ul>
</li>
<li>Set the match-distance MD to 0</li>
<li>For each subtag in the list, starting from the end: region,
script, base-language
<ol>
<li>If respective subtags in each language tag are identical,
remove the subtag from each (logically) and continue.</li>
<li>Traverse the languageMatching data until a match is found.
<ul>
<li>* matches any field.</li>
<li>If the oneway flag is false, then the match is
symmetric.</li>
</ul>
</li>
<li>Add 100 minus the <strong>percent</strong> attribute value
to MD.
</li>
<li>Remove the subtag from each (logically)</li>
</ol>
</li>
<li>Return MD</li>
</ol>
<p>
It is typically useful to set the discount factor between successive
elements of the desired languages list to be slightly greater than
the default region difference. That avoids the following problem:<br>
</p>
<p>
<em>Supported languages:</em> "de, fr, ja"<br>
</p>
<p>
<em>User's desired languages:</em> "de-AT, fr"
</p>
<p>This user would expect to get "de", not "fr". In practice, when
a user selects a list of preferred languages, they don't include all
the regional variants ahead of their second base language. Yet while
the user's desired languages really doesn't tell us the priority
ranking among their languages, normally the fall-off between the
user's languages is substantially greater than regional variants. But
unless F is greater than the distance between de-AT and de-DE, then
the user’s second-choice language would be returned.</p>
<p>The base language subtag &quot;und&quot; is a special case.
Suppose we have the following situation:</p>
<ul>
<li>desired languages: {und, it}</li>
<li>supported languages: {en, it}</li>
<li>resulting language: en<br>
</li>
</ul>
<p>Part of this is because 'und' has a special function in BCP 47;
it stands in for 'no supplied base language'. To prevent this from
happening, if the desired base language is und, the language matcher
should not apply likely subtags to it. </p>
<p>Examples:</p>
<p>For example, suppose that nn-DE and nb-FR are being compared.
They are first maximized to nn-Latn-DE and nb-Latn-FR, respectively.
The list is searched. The first match is with &quot;*-*-*&quot;, for
a match of 96%. The languages are truncated to nn-Latn and nb-Latn,
then to nn and nb. The first match is also for a value of 96%, so the
result is 92%.</p>
<p>Note that language matching is orthogonal to the how closely
two languages are related linguistically. For example, Breton is more
closely related to Welsh than to French, but French is the better
match (because it is more likely that a Breton reader will understand
French than Welsh). This also illustrates that the matches are often
asymmetric: it is not likely that a French reader will understand
Breton.</p>
<p>The &quot;*&quot; acts as a wild card, as shown in the
following example:</p>
<p class="example">
&lt;languageMatch desired=&quot;es-*-ES&quot;
supported=&quot;es-*-ES&quot; percent=&quot;100&quot;/&gt;<br>
&lt;!-- Latin American Spanishes are closer to each other.
Approximate by having es-ES be further from everything else.--&gt;
</p>
<p>&nbsp;</p>
<p class="example">&lt;languageMatch desired=&quot;es-*-ES&quot;
supported=&quot;es-*-*&quot; percent=&quot;93&quot;/&gt;</p>
<p class="example">
<br> &lt;languageMatch desired=&quot;*&quot;
supported=&quot;*&quot; percent=&quot;1&quot;/&gt;<br> &lt;!--
[Default value - must be at end!] Normally there is no comprehension
of different languages.--&gt;
</p>
<p class="example">
<br> &lt;languageMatch desired=&quot;*-*&quot;
supported=&quot;*-*&quot; percent=&quot;20&quot;/&gt;<br>
&lt;!-- [Default value - must be at end!] Normally there is little
comprehension of different scripts.--&gt;
</p>
<p class="example">
<br> &lt;languageMatch desired=&quot;*-*-*&quot;
supported=&quot;*-*-*&quot; percent=&quot;96&quot;/&gt;<br>
&lt;!-- [Default value - must be at end!] Normally there are small
differences across regions.--&gt;
</p>
<p>When the language+region is not matched, and there is otherwise
no reason to pick among the supported regions for that language, then
some measure of geographic &quot;closeness&quot; can be used. The
results may be more understandable by users. Looking for en-SK, for
example, should fall back to something within Europe (eg en-GB) in
preference to something far away and unrelated (eg en-SG). Such a
closeness metric does not need to be exact; a small amount of data
can be used to give an approximate distance between any two regions.
However, any such data must be used carefully; although Hong Kong is
closer to India than to the UK, it is unlikely that en-IN would be a
better match to en-HK than en-GB would.</p>
<h4><a name="EnhancedLanguageMatching" href="#EnhancedLanguageMatching">4.4.1 Enhanced Language Matching</a></h4>
<p>The enhanced format for language matching adds structure to enable better matching of languages. It is distinguished by having a suffix &quot;_new&quot; on the type, as in the example below. The extended structure allows matching to take into account broad similarities that would give better results. For example, for English the regions that are or inherit from US (AS|GU|MH|MP|PR|UM|VI|US) form a &ldquo;cluster&rdquo;. Each region in that cluster should be closer to each other than to any other region. And a region outside the cluster should be closer to another region outside that cluster than to one inside. We get this issue with the &ldquo;world languages&rdquo; like English, Spanish, Portuguese, Arabic, etc.</p>
<p><em>Example:</em></p>
<pre> &lt;languageMatches type=&quot;written_new&quot;&gt;<br> &lt;paradigmLocales locales=&quot;en en-GB es es-419 pt-BR pt-PT&quot;/&gt;<br> &lt;matchVariable id=&quot;$enUS&quot; value=&quot;AS+GU+MH+MP+PR+UM+US+VI&quot;/&gt;<br> &lt;matchVariable id=&quot;$cnsar&quot; value=&quot;HK+MO&quot;/&gt;<br> &lt;matchVariable id=&quot;$americas&quot; value=&quot;019&quot;/&gt;<br> &lt;matchVariable id=&quot;$maghreb&quot; value=&quot;MA+DZ+TN+LY+MR+EH&quot;/&gt;<br> &lt;languageMatch desired=&quot;no&quot; supported=&quot;nb&quot; distance=&quot;1&quot;/&gt;&lt;!-- no ⇒ nb --&gt;<br>…
&lt;languageMatch desired=&quot;ar_*_$maghreb&quot; supported=&quot;ar_*_$maghreb&quot; distance=&quot;4&quot;/&gt;
&lt;!-- ar; *; $maghreb ⇒ ar; *; $maghreb --&gt;
&lt;languageMatch desired=&quot;ar_*_$!maghreb&quot; supported=&quot;ar_*_$!maghreb&quot; distance=&quot;4&quot;/&gt;
&lt;!-- ar; *; $!maghreb ⇒ ar; *; $!maghreb --&gt;<br>…</pre>
<p>The <strong>matchVariable</strong> allows for a rule to matche to multiple regions, as illustrated by <strong>$maghreb</strong>. The syntax is simple: it allows for + for <em>union</em> and - for <em>set difference</em>, but no precedence. So A+B-A+D is interpreted as (((A+B)-A)+D), not as (A+B)-(A+D). The variable <strong>id</strong> has a value of the form [$][a-zA-Z0-9]+. If $X is defined, then $!X automatically means all those regions that are not in $X. </p>
<p dir="ltr">When the set is interpreted, then macrolanguages are (logically) transformed into a list of their contents, so &ldquo;053+GB&rdquo; → &ldquo;AU+GB+NF+NZ&rdquo;. This is done recursively, so 009 → &ldquo;053+054+057+061+QO&rdquo; → &ldquo;AU+NF+NZ+FJ+NC+PG+SB +VU...&rdquo;. Note that we use 019 for all of the Americas in the variables above, because en-US should be in the same cluster as es-419 and its contents. </p>
<p>In the rules, the percent value (100..0) is replaced by a <strong>distance</strong> value, which is the inverse (0..100).</p>
<p dir="ltr">These new variables and rules divide up the world into clusters, where items in the same clusters (for specific languages) get the normal regional difference, and items in different clusters get different weights.</p>
<br>
<p dir="ltr">Each cluster can have one or more associated <strong>paradigmLocales</strong>. These are locales that are preferred within a cluster. So when matching desired=[en-SA] against [en-GU en en-IN en-GB], the value en-GB is returned. Both of {en-GU en} are in a different cluster. While {en-IN en-GB} are in the same cluster, and the same distance from en-SA, the preference is given to en-GB because it is in the paradigm locales. It would be possible to express this in rules, but using this mechanism handles these very common cases without bulking up the tables.<br>
</p>
<p dir="ltr">The <strong>paradigmLocales</strong> also allow matching to macroregions. For example, desired=[es-419] should match to {es-MX} more closely than to {es}, and vice versa: {es-MX} should match more closely to {es-419} than to {es}. But es-MX should match more closely to es-419 than to any of the other es-419 sublocales. In general, in the absence of other distance data, there is a &lsquo;paradigm&rsquo; in each cluster that the others should match more closely to: en(-US), en-GB, es(-ES), es-419, ru(-RU)... </p>
<h2>
<a name="XML_Format" href="#XML_Format">5 XML Format</a>
</h2>
<p>There are two kinds of data that can be expressed in LDML:
language-dependent data and supplementary data. In either case, data
can be split across multiple files, which can be in multiple
directory trees.</p>
<p>For example, the language-dependent data for Japanese in CLDR
is present in the following files:</p>
<ul>
<li>common/collation/ja.xml</li>
<li>common/main/ja.xml</li>
<li>common/rbnf/ja.xml</li>
<li>common/segmentations/ja.xml</li>
</ul>
<p>Data for cased languages such as French are in files like:</p>
<ul>
<li>common/casing/fr.xml</li>
</ul>
<p>The status of the data is the same, whether or not data is
split. That is, for the purpose of validation and lookup, all of the
data for the above ja.xml files is treated as if it was in a single
file. These files have the &lt;ldml&gt; root element and use
ldml.dtd. The file name must match the identity element. For example,
the &lt;ldml&gt; file pa_Arab_PK.xml must contain the following
elements:</p>
<pre>
<strong>&lt;ldml&gt;</strong><br> &lt;identity&gt;<br> …<br> <strong>&lt;language type=&quot;pa&quot;/&gt;<br> &lt;script type=&quot;Arab&quot;/&gt;<br> &lt;territory type=&quot;PK&quot;/&gt;</strong><br> &lt;/identity&gt;
…</pre>
<p>Supplemental data can have different root elements, currently:
ldmlBCP47, supplementalData, keyboard, and platform. Keyboard and
platform files are considered distinct. The ldmlBCP47 files and
supplementalData files that have the same root are all logically part
of the same file; they are simply split into separate files for
convenience. Implementations may split the files in different ways,
also for their convenience. The files in /properties are also
supplemental data files, but are structured like UCD properties.</p>
<p>For example, supplemental data relating to Japan or the
Japanese writing are in:</p>
<ul>
<li>common/supplemental/ (in many files, such as
supplementalData.xml)</li>
<li>common/transforms/Hiragana-Katakana.xml</li>
<li>common/transforms/Hiragana-Latin.xml</li>
<li>common/properties/scriptMetadata.txt</li>
<li>common/bcp47/calendar.xml</li>
<li>uca/allkeys_CLDR.txt (sorting)</li>
<li>/keyboards/chromeos/ja-t-k0-chromeos.xml</li>
<li>...</li>
</ul>
<p>Like the &lt;ldml&gt; files, the keyboard file names must match
internal data: in particular, the locale attribute on the keyboard
element must have a value that corresponds to the file name, such as
&lt;keyboard locale=&quot;af-t-k0-android&quot;&gt; for the file
af-t-k0-android.xml.</p>
<p>
The following sections describe the structure of the XML format for
language-dependent data. The more precise syntax is in the ldml.dtd
file<i>; however, the DTD does not describe all the constraints
on the structure.</i>
</p>
<p>To start with, the root element is &lt;ldml&gt;, with the
following DTD entry:</p>
<p class='dtd'>
&lt;!ELEMENT ldml
(identity,(alias|(fallback*,localeDisplayNames?,layout?,contextTransforms?,characters?,<br>
delimiters?,measurement?,dates?,numbers?,units?,listPatterns?,collations?,posix?,<br>
segmentations?,rbnf?,annotations?,metadata?,references?,special*)))&gt;
</p>
<p>The XML structure is stable over releases. Elements and
attributes may be deprecated: they are retained in the DTD but their
usage is strongly discouraged. In most cases, an alternate structure
is provided for expressing the information. There is only one
exception: newer DTDs cannot be used with version 1.1 files, without
some modification.</p>
<p>In general, all translatable text in this format is in element
contents, while attributes are reserved for types and non-translated
information (such as numbers or dates). The reason that attributes
are not used for translatable text is that spaces are not preserved,
and we cannot predict where spaces may be significant in translated
material.</p>
<p>
There are two kinds of elements in LDML: <i>rule</i> elements and <i>structure</i>
elements. For structure elements, there are restrictions to allow for
effective inheritance and processing:
</p>
<ol>
<li>There is no &quot;mixed&quot; content: if an element has
textual content, then it cannot contain any elements.</li>
<li>The [<a href="#XPath">XPath</a>] leading to the content is
unique; no two different pieces of textual content have the same [<a
href="#XPath">XPath</a>].
</li>
</ol>
<p>
Rule elements do not have this restriction, but also do not inherit,
except as an entire block. The rule elements are listed in
serialElements in the supplemental metadata. See also <i><a
href="#Inheritance_and_Validity">Section 4.2 Inheritance and
Validity</a></i>. For more technical details, see <a
href="http://cldr.unicode.org/development/updating-dtds">Updating-DTDs</a>.
</p>
<p>
Note that the data in examples given below is purely illustrative,
and does not match any particular language. For a more detailed
example of this format, see [<a href="#LDML">Example</a>]. There is
also a DTD for this format, but <i>remember that the DTD alone is
not sufficient to understand the semantics, the constraints,
nor&nbsp; the interrelationships between the different elements and
attributes</i>. You may wish to have copies of each of these to hand as
you proceed through the rest of this document.
</p>
<p>In particular, all elements allow for draft versions to coexist
in the file at the same time. Thus most elements are marked in the
DTD as allowing multiple instances. However, unless an element is
listed as a serialElement, or has a distinguishing attribute, it can
only occur once as a subelement of a given element. Thus, for
example, the following is illegal even though allowed by the DTD:</p>
<p>
&lt;languages&gt;<br> &nbsp; &lt;language
type=&quot;aa&quot;&gt;...&lt;/language&gt;<br> &nbsp;
&lt;language type=&quot;aa&quot;&gt;..&lt;/language&gt;
</p>
<p>There must be only one instance of these per parent, unless
there are other distinguishing attributes (such as an alt element).</p>
<p>In general, LDML data should be in NFC format. However, certain
elements may need to contain characters that are not in NFC,
including exemplars, transforms, segmentations, and
p/s/t/i/pc/sc/tc/ic rules in collation. These elements must not be
normalized (either to NFC or NFD), or their meaning may be changed.
Thus LDML documents must not be normalized as a whole. To prevent
problems with normalization, no element value can start with a
combining slash (U+0338 COMBINING LONG SOLIDUS OVERLAY).</p>
<p>
Lists, such as <span class="attribute">singleCountries</span> are
space-delimited. That means that they are separated by one or more
XML whitespace characters,
</p>
<ul>
<li>singleCountries</li>
<li>preferenceOrdering</li>
<li>references</li>
</ul>
<h3>
<a name="Common_Elements" href="#Common_Elements">5.1 Common
Elements</a>
</h3>
<p>At any level in any element, two special elements are allowed.</p>
<h4>
<a name="special" href="#special">5.1.1 Element special</a>
</h4>
<p>
This element is designed to allow for arbitrary additional annotation
and data that is product-specific. It has one required attribute <span
class="attribute">xmlns</span>, which specifies the XML <a
href="http://www.w3.org/TR/REC-xml-names/">namespace</a> of the
special data. For example, the following used the version 1.0 POSIX
special element.
</p>
<pre>&lt;!DOCTYPE ldml SYSTEM &quot;<span style="color: blue">http://unicode.org/cldr/dtd/1.0/ldml.dtd</span>&quot; [
&lt;!ENTITY % posix SYSTEM &quot;<span style="color: blue">http://unicode.org/cldr/dtd/1.0/ldmlPOSIX.dtd</span>&quot;&gt;
<span style="color: blue">%posix;</span>
]&gt;
&lt;ldml&gt;
...
&lt;special xmlns:posix=&quot;<span style="color: blue">http://www.opengroup.org/regproducts/xu.htm</span>&quot;&gt;
<span style="color: green">&lt;!-- old abbreviations for pre-GUI days --&gt;</span>
&lt;posix:messages&gt;
&lt;posix:yesstr&gt;<span style="color: blue">Yes</span>&lt;/posix:yesstr&gt;
&lt;posix:nostr&gt;<span style="color: blue">No</span>&lt;/posix:nostr&gt;
&lt;posix:yesexpr&gt;<span style="color: blue">^[Yy].*</span>&lt;/posix:yesexpr&gt;
&lt;posix:noexpr&gt;<span style="color: blue">^[Nn].*</span>&lt;/posix:noexpr&gt;
&lt;/posix:messages&gt;
&lt;/special&gt;
&lt;/ldml&gt;
</pre>
<h5>
<a name="Sample_Special_Elements" href="#Sample_Special_Elements">5.1.1.1
Sample Special Elements</a>
</h5>
<p>
The elements in this section are <i><b>not</b></i> part of the Locale
Data Markup Language 1.0 specification. Instead, they are special
elements used for application-specific data to be stored in the
Common Locale Repository. They may change or be removed future
versions of this document, and are present her more as examples of
how to extend the format. (Some of these items may move into a future
version of the Locale Data Markup Language specification.)
</p>
<ul>
<li><a href="http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd">http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd</a></li>
<li><a href="http://unicode.org/cldr/dtd/1.1/ldmlOpenOffice.dtd">http://unicode.org/cldr/dtd/1.1/ldmlOpenOffice.dtd</a></li>
</ul>
<p>The above examples are old versions: consult the documentation
for the specific application to see which should be used.</p>
<p>These DTDs use namespaces and the special element. To include
one or more, use the following pattern to import the special DTDs
that are used in the file:</p>
<pre>&lt;?xml version=&quot;<span style="color: blue">1.0</span>&quot; encoding=&quot;<span
style="color: blue">UTF-8</span>&quot; ?&gt;
&lt;!DOCTYPE ldml SYSTEM &quot;<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldml.dtd</span>&quot; [
&lt;!ENTITY % <span style="color: blue">icu</span> SYSTEM &quot;<span
style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd</span>&quot;&gt;
&lt;!ENTITY % <span style="color: blue">openOffice</span> SYSTEM &quot;<span
style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlOpenOffice.dtd</span>&quot;&gt;
<span style="color: blue">%icu;
%openOffice;
</span>]&gt;</pre>
<p>Thus to include just the ICU DTD, one uses:</p>
<pre>&lt;?xml version=&quot;<span style="color: blue">1.0</span>&quot; encoding=&quot;<span
style="color: blue">UTF-8</span>&quot; ?&gt;
&lt;!DOCTYPE ldml SYSTEM &quot;<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldml.dtd</span>&quot; [
&lt;!ENTITY % icu SYSTEM &quot;<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd</span>&quot;&gt;
<span style="color: blue">%icu;
</span>]&gt;</pre>
<blockquote>
<p>
<b>Note: </b>A previous version of this document contained a special
element for <a
href="http://www.open-std.org/jtc1/sc22/wg20/docs/n897-14652w25.pdf">ISO
TR 14652</a> compatibility data. That element has been withdrawn,
pending further investigation, since<b><i> </i></b>14652 is a Type 1
TR: &quot;when the required support cannot be obtained for the
publication of an International Standard, despite repeated
effort&quot;. See the ballot comments on <a
href="http://www.open-std.org/jtc1/sc22/wg20/docs/n948-J1N6769-14652.pdf">14652
Comments</a> for details on the 14652 defects. For example, most of
these patterns make little provision for substantial changes in
format when elements are empty, so are not particularly useful in
practice. Compare, for example, the mail-merge capabilities of
production software such as Microsoft Word or OpenOffice.
</p>
<p>
<b>Note: </b>While the CLDR specification guarantees backwards
compatibility, the definition of specials is up to other
organizations. Any assurance of backwards compatibility is up to
those organizations.
</p>
</blockquote>
<p>
A number of the elements above can have extra information for <a
name="OpenOffice" href="#OpenOffice">openoffice.org</a>, such as the
following example:
</p>
<pre> &lt;special xmlns:openOffice=&quot;<span
style="color: blue">http://www.openoffice.org</span>&quot;&gt;
&lt;openOffice:search&gt;
&lt;openOffice:searchOptions&gt;
&lt;openOffice:transliterationModules&gt;<span
style="color: blue">IGNORE_CASE</span>&lt;/openOffice:transliterationModules&gt;
&lt;/openOffice:searchOptions&gt;
&lt;/openOffice:search&gt;
&lt;/special&gt;
</pre>
<h4>
<a name="Alias_Elements" href="#Alias_Elements">5.1.2 Element
alias</a>
</h4>
<p class="dtd">
&lt;!ELEMENT alias (special*) &gt;<br> &lt;!ATTLIST alias source
NMTOKEN #REQUIRED &gt;<br> &lt;!ATTLIST alias path CDATA
#IMPLIED&gt;
</p>
<p>The contents of any element in root can be replaced by an
alias, which points to the path where the data can be found.</p>
<p>Aliases will only ever appear in root with the form
//ldml/.../alias[@source=&quot;locale&quot;][@path=&quot;...&quot;].</p>
<p>Consider the following example in root:</p>
<pre>
&lt;calendar type=&quot;gregorian&quot;&gt;<br> &lt;months&gt;<br> &lt;default choice=&quot;format&quot;/&gt;<br> &lt;monthContext type=&quot;format&quot;&gt;<br> &lt;default choice=&quot;wide&quot;/&gt;<br> &lt;monthWidth type=&quot;abbreviated&quot;&gt;<br> <strong>&lt;alias source=&quot;locale&quot; path=&quot;../monthWidth[@type='wide']&quot;/&gt;</strong><br> &lt;/monthWidth&gt;</pre>
<p>
If the locale &quot;de_DE&quot; is being accessed for a month name
for format/abbreviated, then a resource bundle at &quot;de_DE&quot;
will be searched for a resource element at the that path. If not
found there, then the resource bundle at &quot;de&quot; will be
searched, and so on. When the alias is found in root, then the search
is restarted, but searching for format/<strong>wide</strong> element
instead of format/abbreviated.
</p>
<p>
If the <b>path</b> attribute is present, then its value is an [<a
href="#XPath">XPath</a>] that points to a different node in the
tree. For example:
</p>
<pre>&lt;alias source=&quot;locale&quot; path=&quot;../monthWidth[@type=&#39;wide&#39;]&quot;/&gt;</pre>
<p>
The default value if the path is not present is the same position in
the tree. All of the attributes in the [<a href="#XPath">XPath</a>]
must be <i>distinguishing</i> elements. For more details, see <a
href="#Inheritance_and_Validity">Section 4.2 Inheritance and
Validity</a>.
</p>
<p>
There is a special value for the source attribute, the constant <b>source=&quot;locale&quot;</b>.
This special value is equivalent to the locale being resolved. For
example, consider the following example, where locale data for
&#39;de&#39; is being resolved:
</p>
<div align="center">
<center>
<table border="1" cellpadding="0" cellspacing="1">
<caption>
<a name="Inheritance_with_source_locale_"
href="#Inheritance_with_source_locale_">Inheritance with
source=&quot;locale&quot;</a>
</caption>
<tr>
<th>Root</th>
<th>de</th>
<th bgcolor="#C0C0C0">Resolved</th>
</tr>
<tr>
<td><code>
&lt;x&gt;<br> &nbsp; &lt;a&gt;1&lt;/a&gt;<br> &nbsp;
&lt;b&gt;2&lt;/b&gt;<br> &nbsp; &lt;c&gt;3&lt;/c&gt;<br>
<br> &lt;/x&gt;
</code></td>
<td><code>
&lt;x&gt;<br> &nbsp;&lt;a&gt;11&lt;/a&gt;<br>
&nbsp;&lt;b&gt;12&lt;/b&gt;<br> <br>
&nbsp;&lt;d&gt;14&lt;/d&gt;<br> &lt;/x&gt;
</code></td>
<td bgcolor="#C0C0C0"><code>
&lt;x&gt;<br> &nbsp;&lt;a&gt;11&lt;/a&gt;<br>
&nbsp;&lt;b&gt;12&lt;/b&gt;<br> &nbsp;<span
style="background-color: #FFFF00"><span
class="inherited"><span style="font-weight: 400;">&lt;c&gt;3&lt;/c&gt;</span></span></span><br>
&nbsp;&lt;d&gt;14&lt;/d&gt;<br> &lt;/x&gt;
</code></td>
</tr>
<tr>
<td><code>
&lt;y&gt;<br> &nbsp;&lt;alias source=&quot;locale&quot;
path=&quot;../x&quot;&gt;<br> &lt;/y&gt;
</code></td>
<td><code>
&lt;y&gt;<br> <br> &nbsp;&lt;b&gt;22&lt;/b&gt;<br>
<br> <br> &nbsp;&lt;e&gt;25&lt;/e&gt;<br>
&lt;/y&gt;
</code></td>
<td bgcolor="#C0C0C0"><code>
&lt;y&gt;<br> &nbsp;<span style="background-color: #FFFF00"><span
class="inherited"><span style="font-weight: 400;">&lt;a&gt;11&lt;/a&gt;</span></span></span><br>
&nbsp;&lt;b&gt;22&lt;/b&gt;<br> &nbsp;<span
style="background-color: #FFFF00"><span
class="inherited"><span style="font-weight: 400;">&lt;c&gt;3&lt;/c&gt;</span></span></span><br>
&nbsp;<span style="background-color: #FFFF00"><span
class="inherited"><span style="font-weight: 400;">&lt;d&gt;14&lt;/d&gt;</span></span></span><br>
&nbsp;&lt;e&gt;25&lt;/e&gt;<br> &lt;/y&gt;
</code></td>
</tr>
</table>
</center>
</div>
<p>The first row shows the inheritance within the &lt;x&gt;
element, whereby &lt;c&gt; is inherited from root. The second shows
the inheritance within the &lt;y&gt; element, whereby &lt;a&gt;,
&lt;c&gt;, and &lt;d&gt; are inherited also from root, but from an
alias there. The alias in root is logically replaced not by the
elements in root itself, but by elements in the &#39;target&#39;
locale.</p>
<p>
For more details on data resolution, see <a
href="#Inheritance_and_Validity">Section 4.2 Inheritance and
Validity</a>.
</p>
<p>
Aliases must be resolved recursively. An alias may point to another
path that results in another alias being found, and so on. For
example, looking up Thai buddhist abbreviated months for the locale <strong>xx-YY</strong>
may result in the following chain of aliases being followed:
</p>
<blockquote>
<p>../../calendar[@type=&quot;buddhist&quot;]/months/monthContext[@type=&quot;format&quot;]/monthWidth[@type=&quot;abbreviated&quot;]
</p>
<p>xx-YY → xx → root // finds alias that changes path to:</p>
<p>../../calendar[@type=&quot;gregorian&quot;]/months/monthContext[@type=&quot;format&quot;]/monthWidth[@type=&quot;abbreviated&quot;]
</p>
<p>xx-YY → xx → root // finds alias that changes path to:</p>
<p>../../calendar[@type=&quot;gregorian&quot;]/months/monthContext[@type=&quot;format&quot;]/monthWidth[@type=&quot;wide&quot;]
</p>
<p>xx-YY → xx // finds value here</p>
</blockquote>
<p>It is an error to have a circular chain of aliases. That is, a
collection of LDML XML documents must not have situations where a
sequence of alias lookups (including inheritance and lateral
inheritance) can be followed indefinitely without terminating.</p>
<h4>
<a name="Element_displayName" href="#Element_displayName">5.1.3
Element displayName</a>
</h4>
<p>Many elements can have a display name. This is a translated
name that can be presented to users when discussing the particular
service. For example, a number format, used to format numbers using
the conventions of that locale, can have translated name for
presentation in GUIs.</p>
<pre> &lt;numberFormat&gt;
&lt;displayName&gt;<span style="color: blue">Prozentformat</span>&lt;/displayName&gt;
...
&lt;numberFormat&gt;</pre>
<p>
Where present, the display names must be unique; that is, two
distinct code would not get the same display name.&nbsp; (There is
one exception to this: in time zones, where parsing results would
give the same GMT offset, the standard and daylight display names can
be the same across different time zone IDs.) Any translations should
follow customary practice for the locale in question. For more
information, see [<a href="#DataFormats">Data Formats</a>].
</p>
<h4>
<a name="Escaping_Characters" href="#Escaping_Characters">5.1.4
Escaping Characters</a>
</h4>
<p>Unfortunately, XML does not have the capability to contain all
Unicode code points. Due to this, in certain instances extra syntax
is required to represent those code points that cannot be otherwise
represented in element content. The escaping syntax is only defined
on a few types of elements, such as in collation or exemplar sets,
and uses the appropriate syntax for that type.</p>
<p>The element &lt;cp&gt;, which was formerly used for this
purpose, has been deprecated.</p>
<h3>
<a name="Common_Attributes" href="#Common_Attributes">5.2 Common
Attributes</a>
</h3>
<h4>
<a name="Attribute_type" href="#Attribute_type">5.2.1 Attribute
type</a>
</h4>
<p>
The attribute <i>type</i> is also used to indicate an alternate
resource that can be selected with a matching type=option in the
locale id modifiers, or be referenced by a default element. For
example:
</p>
<pre>&lt;ldml&gt;
...
&lt;currencies&gt;
&lt;currency&gt;<span style="color: blue">...</span>&lt;/currency&gt;
&lt;currency type=&quot;<span style="color: blue">preEuro</span>&quot;&gt;<span
style="color: blue">...</span>&lt;/currency&gt;
&lt;/currencies&gt;
&lt;/ldml&gt;</pre>
<h4>
<a name="Attribute_draft" href="#Attribute_draft">5.2.2 Attribute
draft</a>
</h4>
<p>
If this attribute is present, it indicates the status of all the data
in this element and any subelements (unless they have a contrary <i>draft</i>
value), as per the following:
</p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><i>approved:</i>
fully approved by the technical committee (equals the CLDR 1.3 value
of <i>false</i>, or an absent <i>draft</i> attribute). This does not
mean that the data is guaranteed to be error-free—this is the best
judgment of the committee.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><i>contributed</i>:
partially approved by the technical committee.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><i>provisional</i>:
partially confirmed. Implementations may choose to accept the
provisional data, especially if there is no translated alternative.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><i>unconfirmed</i>:
no confirmation available.</li>
</ul>
<p>
For more information on precisely how these values are computed for
any given release, see <a
href="http://cldr.unicode.org/index/process#TOC-Data-Submission-and-Vetting-Process">Data
Submission and Vetting Process</a> on the CLDR website.
</p>
<p>
The draft attribute should only occur on &quot;leaf&quot; elements, and is deprecated elsewhere. For a more
formal description of how elements are inherited, and what their
draft status is, see <i><a href="#Inheritance_and_Validity">Section
4.2 Inheritance and Validity</a></i>.
</p>
<h4>
<a name="alt_attribute" href="#alt_attribute">5.2.3 Attribute alt</a>
</h4>
<p>
This attribute labels an alternative value for an element. The value
is a <i>descriptor</i> indicates what kind of alternative it is, and
takes one of the following
</p>
<ul>
<li><i>variantname</i> meaning that the value is a variant of
the normal value, and may be used in its place in certain
circumstances. If a variant value is absent for a particular locale,
the normal value is used. The variant mechanism should only be used
when such a fallback is acceptable.</li>
<li><span style="color: blue">proposed</span>, optionally
followed by a number, indicating that the value is a proposed
replacement for an existing value.</li>
<li><i>variantname</i><span style="color: blue">-proposed</span>,
optionally followed by a number, indicating that the value is a
proposed replacement variant value.</li>
</ul>
<p>
&quot;<span style="color: blue">proposed</span>&quot; should only be
present if the draft status is not &quot;approved&quot;. It indicates
that the data is proposed replacement data that has been added
provisionally until the differences between it and the other data can
be vetted. For example, suppose that the translation for September
for some language is &quot;Settembru&quot;, and a bug report is filed
that that should be &quot;Settembro&quot;. The new data can be
entered in, but marked as <i>alt=&quot;proposed&quot;</i> until it is
vetted.
</p>
<pre>...
&lt;month type=&quot;9&quot;&gt;Settembru&lt;/month&gt;
&lt;month type=&quot;9&quot; draft=&quot;unconfirmed&quot; alt=&quot;proposed&quot;&gt;Settembro&lt;/month&gt;
&lt;month type=&quot;10&quot;&gt;...</pre>
<p>Now assume another bug report comes in, saying that the correct
form is actually &quot;Settembre&quot;. Another alternative can be
added:</p>
<pre>...
&lt;month type=&quot;9&quot; draft=&quot;unconfirmed&quot; alt=&quot;proposed2&quot;&gt;Settembre&lt;/month&gt;
...</pre>
<p>
The values for <i>variantname</i> at this time include &quot;<span
style="color: blue">variant</span>&quot;, &quot;<span
style="color: blue">list</span>&quot;, &quot;<span
style="color: blue">email</span>&quot;, &quot;<span
style="color: blue">www</span>&quot;, &quot;<span
class="attributeValue">short</span>&quot;, and &quot;<span
style="color: blue">secondary</span>&quot;.
</p>
<p>
For a more complete description of how draft applies to data, see <i><a
href="#Inheritance_and_Validity">Section 4.2 Inheritance and
Validity</a></i>.
</p>
<p class="element2">
Attribute <a name="references_attribute" href="#references_attribute">references</a>
</p>
<p>The value of this attribute is a token representing a reference
for the information in the element, including standards that it may
conform to. &lt;references&gt;. (In older versions of CLDR, the value
of the attribute was freeform text. That format is deprecated.)</p>
<p>
<i>Example:</i>
</p>
<p class="example">&lt;territory type=&quot;UM&quot;
references=&quot;R222&quot;&gt;USAs yttre öar&lt;/territory&gt;</p>
<p>The reference element may be inherited. Thus, for example, R222
may be used in sv_SE.xml even though it is not defined there, if it
is defined in sv.xml.</p>
<p>&lt;... allow=&quot;verbatim&quot; ...&gt; (deprecated)</p>
<p>This attribute was originally intended for use in marking
display names whose capitalization differed from what was indicated
by the now-deprecated &lt;inText&gt; element (perhaps, for example,
because the names included a proper noun). It was never supported in
the dtd and is not needed for use with the new
&lt;contextTransforms&gt; element.</p>
<h3>
<a name="Common_Structures" href="#Common_Structures">5.3 Common
Structures</a>
</h3>
<h4>
<a name="Date_Ranges" href="#Date_Ranges">5.3.1 Date and Date
Ranges</a>
</h4>
<p>
When attribute specify date ranges, it is usually done with
attributes <i>from</i> and <i>to</i>. The <i>from</i> attribute
specifies the starting point, and the <i>to</i> attribute specifies
the end point. The deprecated <i>time</i> attribute was formerly used
to specify time with the deprecated weekEndStart and weekEndEnd
elements, which were themselves inherently <i>from</i> or <i>to</i>.
</p>
<p>
The data format is a restricted ISO 8601 format, restricted to the
fields <i>year, month, day, hour, minute, </i>and<i> second</i> in
that order, with &quot;-&quot; used as a separator between date
fields, a space used as the separator between the date and the time
fields, and &quot;:&quot; used as a separator between the time
fields. If the minute or minute and second are absent, they are
interpreted as zero. If the hour is also missing, then it is
interpreted based on whether the attribute is <i>from</i> or <i>to</i>.
</p>
<ul>
<li>
<p class="note">
<i>from</i> defaults to &quot;00:00:00&quot; (midnight at the start
of the day).
</p>
</li>
<li>
<p class="note">
<i>to </i>defaults to &quot;24:00:00&quot; (midnight at the end of
the day).
</p>
</li>
</ul>
<p class="note">
That is, Friday at 24:00:00 is the same time as Saturday at 00:00:00.
Thus when the hour is missing, the <i>from and to</i> are interpreted
inclusively: the range includes all of the day mentioned.
</p>
<p class="note">For example, the following are equivalent:</p>
<table style="margin-top: 0.5em; margin-bottom: 0.5em" id="table25">
<tr>
<td>&lt;usesMetazone from=&quot;1991-10-27&quot;
to=&quot;2006-04-02&quot; .../&gt;</td>
</tr>
<tr>
<td>&lt;usesMetazone from=&quot;1991-10-27 00:00:00&quot;
to=&quot;2006-04-02 24:00:00&quot; .../&gt;</td>
</tr>
<tr>
<td>&lt;usesMetazone from=&quot;1991-10-<font color="#FF0000"><b>26
24</b></font>:00:00&quot; to=&quot;2006-04-<font color="#FF0000"><b>03
00</b></font>:00:00&quot; .../&gt;
</td>
</tr>
</table>
<p>
If the <i>from</i> element is missing, it is assumed to be as far
backwards in time as there is data for; if the <i>to</i> element is
missing, then it is from this point onwards, with no known end point.
</p>
<p>The dates and times are specified in local time, unless
otherwise noted. (In particular, the metazone values are in UTC (also
known as GMT).</p>
<h4>
<a name="Text_Directionality" href="#Text_Directionality">5.3.2
Text Directionality</a>
</h4>
<p>The content of certain elements, such as date or number
formats, may consist of several sub-elements with an inherent order
(for example, the year, month, and day for dates). In some cases, the
order of these sub-elements may be changed depending on the
bidirectional context in which the element is embedded.</p>
<p>For example, short date formats in languages such as Arabic may
contain neutral or weak characters at the beginning or end of the
element content. In such a case, the overall order of the
sub-elements may change depending on the surrounding text.</p>
<p>Element content whose display may be affected in this way
should include an explicit direction mark, such as U+200E
LEFT-TO-RIGHT MARK or U+200F RIGHT-TO-LEFT MARK, at the beginning or
end of the element content, or both.</p>
<h4>
<a name="Unicode_Sets" href="#Unicode_Sets">5.3.3 Unicode Sets</a>
</h4>
<p>
Some attribute values or element contents use <em>UnicodeSet</em>
notation. A UnicodeSet represents a finite set of Unicode code points
and strings, and is defined by lists of code points and strings,
Unicode property sets, and set operators, all bounded by square
brackets. In this context, a code point means a string consisting of
exactly one code point.
</p>
<p>
A UnicodeSet implements the semantics in <i>UTS
#18: Unicode Regular Expressions</i> [<a
href="http://www.unicode.org/reports/tr41/#UTS18">UTS18</a>] Levels 1 &amp; 2 that are relevant to determining sets of characters. Note however that it may deviate from the syntax provided in [<a
href="http://www.unicode.org/reports/tr41/#UTS18">UTS18</a>], which is illustrative rather than a requirement. There is one exception to the supported semantics, Section <a href="http://unicode.org/reports/tr18/#RL2.6">RL2.6</a> <em>Wildcards in Property Values</em>. That feature can be supported in clients such as ICU by implementing a “hook” as is done in the <a href="https://unicode.org/cldr/utility/list-unicodeset.jsp?a=\p{name=/APPLE/}">online UnicodeSet utilities</a>.</p>
<p>A UnicodeSet may be cited in specifications
outside of the domain of LDML. In such a case, the specification may
specify a subset of the syntax provided here.</p>
<p>The following provides EBNF syntax for a UnicodeSet:</p>
<div align='center'>
<table class='simple'>
<tr>
<th>Symbol</th>
<th>Expression</th>
<th>Examples</th>
</tr>
<tr><th>root</th>
<td><code>= prop <br>| '[-]' <br>| '[' [\-\^]? s seq+ ']'</code></td>
<td>\p{x=y},<br>
[abc]</td>
</tr>
<tr><th>seq</th>
<td><code>= root (s [\&amp;\-] s root)* s <br>| range s</code></td>
<td>[abc]-[cde], a <br></td>
</tr>
<tr><th>range</th>
<td><code>= char ('-' char)? <br>| '{' (s char)+ s '}'</code></td>
<td>a, a-c, {abc}</td>
</tr>
<tr><th>prop</th>
<td><code>= '\\' [pP] '{' propName ([≠=] s value1+)? '}' <br>| '[:' '^'? propName ([≠=] s value2+)? ':]'</code></td>
<td>\p{x=y}, [:x=y:]<br></td>
</tr>
<tr><th>propName</th>
<td><code>= s [A-Za-z0-9] [A-Za-z0-9_\x20]* s</code></td>
<td>General_Category,<br>
General Category</td>
</tr>
<tr><th>value1</th>
<td><code>= [^\}] <br>
| '\\' quoted </code></td>
<td>Lm,<br>
\n,<br>
\}</td>
</tr>
<tr><th>value2</th>
<td><code>= [^:] <br>
| '\\' quoted</code></td>
<td>Lm,<br>
\n,<br>
\:</td>
</tr>
<tr><th>char</th>
<td><code>= [^\&amp; \- \[ \[ \] \\ \} \{ [:Pat_WS:]] <br>
| '\\' quoted</code></td>
<td>a, b, c, \n</td>
</tr>
<tr><th>quoted</th>
<td><code>= 'u' (hex{4} | bracketedHex) <br>
| 'x' (hex{2} | bracketedHex) <br> | 'U00' ('0' hex{5} | '10' hex{4}) <br>| 'N{' propName '}' <br>| [\u0000-\U00010FFFF]</code></td>
<td>&nbsp;</td>
</tr>
<tr><th>bracketedHex</th>
<td><code>= '{' s hexCodePoint (s hexCodePoint)* s '}'</code></td>
<td>{61 2019 62}</td>
</tr>
<tr><th>hexCodePoint</th>
<td><code>= hex{1,5} | '10' hex{4}</code></td>
<td>&nbsp;</td>
</tr>
<tr><th>hex</th>
<td><code>= [0-9A-Fa-f]</code></td>
<td>&nbsp;</td>
</tr>
<tr><th>s</th>
<td><code>= [:Pattern_White_Space:]*</code></td>
<td>optional whitespace</td>
</tr>
</table>
</div>
<p>Some constraints on UnicodeSet syntax are not captured by this EBNF. Notably, property names and values are restricted to those supported by the implementation.</p>
<p>The syntax characters are listed in the table below:</p>
<table>
<tbody>
<tr>
<th>Char</th>
<th>Hex</th>
<th>Name</th>
<th>Usage</th>
</tr>
<tr>
<td>$</td>
<td>U+0024</td>
<td>DOLLAR SIGN</td>
<td>Equivalent of \uFFFF (This is for implementations that return \uFFFF when accessing before the first or after the last character)</td>
</tr>
<tr>
<td>&amp;</td>
<td>U+0026</td>
<td>AMPERSAND</td>
<td>Intersecting UnicodeSets</td>
</tr>
<tr>
<td>-</td>
<td>U+002D</td>
<td>HYPHEN-MINUS</td>
<td>Ranges of characters; also set difference.</td>
</tr>
<tr>
<td>:</td>
<td>U+003A</td>
<td>COLON</td>
<td>POSIX-style property syntax</td>
</tr>
<tr>
<td>[</td>
<td>U+005B</td>
<td>LEFT SQUARE BRACKET</td>
<td>Grouping; POSIX property syntax</td>
</tr>
<tr>
<td>]</td>
<td>U+005D</td>
<td>RIGHT SQUARE BRACKET</td>
<td>Grouping; POSIX property syntax</td>
</tr>
<tr>
<td>\</td>
<td>U+005C</td>
<td>REVERSE SOLIDUS</td>
<td>Escaping</td>
</tr>
<tr>
<td>^</td>
<td>U+005E</td>
<td>CIRCUMFLEX ACCENT</td>
<td>Posix negation syntax</td>
</tr>
<tr>
<td>{</td>
<td>U+007B</td>
<td>LEFT CURLY BRACKET</td>
<td>Strings in set; Perl property syntax</td>
</tr>
<tr>
<td>}</td>
<td>U+007D</td>
<td>RIGHT CURLY BRACKET</td>
<td>Strings in set; Perl property syntax</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>U+0020 U+0009..U+000D U+0085<br>
U+200E U+200F<br>
U+2028 U+2029</td>
<td>ASCII whitespace,<br>
LRM, RLM,<br>
LINE/PARAGRAPH SEPARATOR</td>
<td>Ignored except when escaped</td>
</tr>
</tbody>
</table>
<br>
<h5>
<a href="#Lists_of_Code_Points" name="Lists_of_Code_Points">5.3.3.1
Lists of Code Points</a>
</h5>
<p>
Lists are a sequence of strings that may include ranges, which are
indicated by a &#39;-&#39; between two code points, as in
&quot;a-z&quot;. The sequence<em> start-end</em> specifies the range
of all code points from the start to end, inclusive, in Unicode
order. For example, <b>[a c d-f m]</b> is equivalent to <b>[a c d
e f m]</b>. Whitespace can be freely used for clarity, as <b>[a c
d-f m]</b> means the same as <b>[acd-fm]</b>.
</p>
<p>
A string with multiple code points is represented in a list by being
surrounded by curly braces, such as in <strong>[a-z {ch}]</strong>.
It can be used with the range notation, as described in <em>Section
<a href="#String_Range">5.3.4 String Range</a>
</em>. There is an additional restriction on string ranges in a
UnicodeSet: the number of codepoints in the first string of the range
must be identical to the number in the second. Thus [{ab}-{c}] and
[{ab}-c] are invalid.
</p>
<p>In UnicodeSets, there are two ways to quote syntax code points:
</p>
<p>
<a name="Backslash_Escapes"></a>Outside of single quotes, certain
backslashed code point sequences can be used to quote code points:
</p>
<table class='simple'>
<tr>
<td>\x{h...h}<br>
\u{h...h}</td>
<td>list of 1-6 hex digits ([0-9A-Fa-f]), separated by spaces</td>
</tr>
<tr>
<td>\xhh</td>
<td>1-2 hex digits</td>
</tr>
<tr>
<td>\uhhhh</td>
<td>Exactly 4 hex digits</td>
</tr>
<tr>
<td>\Uhhhhhhhh</td>
<td>Exactly 8 hex digits</td>
</tr>
<tr>
<td>\a</td>
<td>U+0007 (BEL / ALERT)</td>
</tr>
<tr>
<td>\b</td>
<td>U+0008 (BACKSPACE)</td>
</tr>
<tr>
<td>\t</td>
<td>U+0009 (TAB / CHARACTER TABULATION)</td>
</tr>
<tr>
<td>\n</td>
<td>U+000A (LINE FEED)</td>
</tr>
<tr>
<td>\v</td>
<td>U+000B (LINE TABULATION)</td>
</tr>
<tr>
<td>\f</td>
<td>U+000C (FORM FEED)</td>
</tr>
<tr>
<td>\r</td>
<td>U+000D (CARRIAGE RETURN)</td>
</tr>
<tr>
<td>\\</td>
<td>U+005C (BACKSLASH / REVERSE SOLIDUS)</td>
</tr>
<tr>
<td>\N{name}</td>
<td>The Unicode code point named &quot;name&quot;.</td>
</tr>
<tr>
<td>\p{…},\P{…}</td>
<td>Unicode property (see below)</td>
</tr>
</table><br>
<p>Anything else following a backslash is mapped to itself, except
the property syntax described below, or in an environment where it is
defined to have some special meaning. </p>
<p>
Any code point formed as the result of a backslash escape loses any
special meaning and is treated as a literal. In particular, note that
\x, \u and \U escapes create literal code points. (In contrast, Java
treats Unicode escapes as just a way to represent arbitrary code
points in an ASCII source file, and any resulting code points are <i><b>not</b></i>
tagged as literals.)
</p>
<p>
Unicode property sets are defined as described as described in <i>UTS
#18: Unicode Regular Expressions</i> [<a
href="http://www.unicode.org/reports/tr41/#UTS18">UTS18</a>], Level
1 and RL2.5, including the syntax where given. For an example of a
concrete implementation of this, see [<a href="#ICUUnicodeSet">ICUUnicodeSet</a>].
</p>
<h5>
<a href="#Unicode_Properties" name="Unicode_Properties">5.3.3.2
Unicode Properties</a>
</h5>
<p>
Briefly, Unicode property sets are specified by any Unicode property
and a value of that property, such as <b>[:General_Category=Letter:]</b>.
for Unicode letters or <b>\p{uppercase}</b> is the set of upper case
letters in Unicode. The property names are defined by the
PropertyAliases.txt file and the property values by the
PropertyValueAliases.txt file. For more information, see [<a
href="http://unicode.org/reports/tr41/#UAX44">UAX44</a>]. The syntax
for specifying the property sets is an extension of either POSIX or
Perl syntax, by the addition of &quot;=&lt;value&gt;&quot;. For
example, you can match letters by using the POSIX-style syntax:
</p>
<p>
<b>[:General_Category=Letter:]</b>
</p>
<p>or by using the Perl-style syntax</p>
<p>
<b>\p{General_Category=Letter}</b>.
</p>
<p>
Property names and values are case-insensitive, and whitespace,
&quot;-&quot;, and &quot;_&quot; are ignored. The property name can
be omitted for the <strong>General_Category</strong> and <strong>Script</strong>
properties, but is required for other properties. If the property
value is omitted, it is assumed to represent a boolean property with
the value &quot;true&quot;. Thus <b>[:Letter:]</b> is equivalent to <b>[:General_Category=Letter:]</b>,
and <b>[:Wh-ite-s pa_ce:]</b> is equivalent to <b>[:Whitespace=true:]</b>.
</p>
<p>
The table below shows the two kinds of syntax: POSIX and Perl style.
Also, the table shows the &quot;Negative&quot; version, which is a
property that excludes all code points of a given kind. For example,
<b>[:^Letter:]</b> matches all code points that are not <b>[:Letter:]</b>.
</p>
<table>
<tr>
<th>&nbsp;</th>
<th>Positive</th>
<th>Negative</th>
</tr>
<tr>
<td>POSIX-style Syntax</td>
<td>[:type=value:]</td>
<td>[:^type=value:]</td>
</tr>
<tr>
<td>Perl-style Syntax</td>
<td>\p{type=value}</td>
<td>\P{type=value}</td>
</tr>
</table>
<h5>
<a href="#Boolean_Operations" name="Boolean_Operations">5.3.3.3
Boolean Operations</a>
</h5>
<p>The low-level lists or properties then can be freely combined
with the normal set operations (union, inverse, difference, and
intersection):</p>
<ul>
<li>To union two sets, simply concatenate them. For example, <b>[[:letter:]
[:number:]]</b></li>
<li>To intersect two sets, use the &#39;&amp;&#39; operator. For
example, <b>[[:letter:] &amp; [a-z]] </b>
</li>
<li>To take the set-difference of two sets, use the &#39;-&#39;
operator. For example, <b>[[:letter:] - [a-z]]</b>
</li>
<li>To invert a set, place a &#39;^&#39; immediately after the
opening &#39;[&#39;. For example, <b>[^a-z]</b>. In any other
location, the &#39;^&#39; does not have a special meaning. The
inversion [^X] is equivalent to [[\x{0}-\x{10FFFF}]-[X]]. Thus
multi-code point strings are discarded.
</li>
<li>Symmetric difference (~) is not supported.</li>
</ul>
<p>
The binary operators &#39;&amp;&#39;, &#39;-&#39;, and the implicit
union have equal precedence and bind left-to-right. Thus <b>[[:letter:]-[a-z]-[\u0100-\u01FF]]</b>
is equal to <b>[[[:letter:]-[a-z]]-[\u0100-\u01FF]]</b>. Another
example is the set <b>[[ace][bdf] - [abc][def]]</b>, which is not the
empty set, but instead equal to <b>[[[[ace] [bdf]] - [abc]]
[def]]</b>, which equals <b>[[[abcdef] - [abc]] [def]]</b>, which equals
<b>[[def] [def]]</b>, which equals <b>[def]</b>.
</p>
<p>
<strong>One caution:</strong> the &#39;&amp;&#39; and &#39;-&#39;
operators operate between sets. That is, they must be immediately
preceded and immediately followed by a set. For example, the pattern
<b>[[:Lu:]-A]</b> is illegal, since it is interpreted as the set <b>[:Lu:]</b>
followed by the incomplete range <b>-A</b>. To specify the set of
upper case letters except for &#39;A&#39;, enclose the &#39;A&#39; in
brackets: <b>[[:Lu:]-[A]]</b>.
</p>
<h5>
<a href="#UnicodeSet_Examples" name="UnicodeSet_Examples">5.3.3.4
UnicodeSet Examples</a>
</h5>
<p>The following table summarizes the syntax that can be used.</p>
<table style="margin-top: 0.5em; margin-bottom: 0.5em" id="table18">
<tr>
<th>Example</th>
<th>Description</th>
</tr>
<tr>
<td nowrap>[a]</td>
<td>The set containing &#39;a&#39; alone</td>
</tr>
<tr>
<td nowrap>[a-z]</td>
<td>The set containing &#39;a&#39; through &#39;z&#39; and all
letters in between, in Unicode order.<br> Thus it is the same
as [\u0061-\u007A].
</td>
</tr>
<tr>
<td nowrap>[^a-z]</td>
<td>The set containing all code points but &#39;a&#39; through
&#39;z&#39;.<br> Thus it is the same as [\u0000-\u0060
\u007B-\x{10FFFF}].
</td>
</tr>
<tr>
<td nowrap>[[pat1][pat2]]</td>
<td>The union of sets specified by pat1 and pat2</td>
</tr>
<tr>
<td nowrap>[[pat1]&amp;[pat2]]</td>
<td>The intersection of sets specified by pat1 and pat2</td>
</tr>
<tr>
<td nowrap>[[pat1]-[pat2]]</td>
<td>The asymmetric difference of sets specified by pat1 and
pat2</td>
</tr>
<tr>
<td nowrap>[a {ab} {ac}]</td>
<td>The code point &#39;a&#39; and the multi-code point strings
&quot;ab&quot; and &quot;ac&quot;</td>
</tr>
<tr>
<td nowrap>[x\u{61 2019 62}y]</td>
<td>Equivalent to [x\u0061\u201\u0062y] (= [xa’by])</td>
</tr>
<tr>
<td nowrap>[{ax}-{bz}]</td>
<td>The set containing [{ax} {ay} {az} {bx} {by} {bz}], using
the range syntax to get all the strings from {ax} to {bz} as
described in <em>Section <a href="#String_Range">5.3.4
String Range</a></em>.
</td>
</tr>
<tr>
<td nowrap>[:Lu:]</td>
<td>The set of code points with a given property value, as
defined by PropertyValueAliases.txt. In this case, these are the
Unicode upper case letters. The long form for this is <b>[:General_Category=Uppercase_Letter:]</b>.
</td>
</tr>
<tr>
<td nowrap>[:L:]</td>
<td>The set of code points belonging to all Unicode categories
starting with &#39;L&#39;, that is, <b>[[:Lu:][:Ll:][:Lt:][:Lm:][:Lo:]]</b>.
The long form for this is <b>[:General_Category=Letter:]</b>.
</td>
</tr>
</table>
<br>
<h4>
<a name="String_Range" href="#String_Range">5.3.4 String Range</a>
</h4>
<p>A String Range is a compact format for specifying a list of
strings.</p>
<p>
<strong>Syntax:<br>
</strong>
</p>
<blockquote>
<p>
X <em>sep</em> Y<br>
</p>
</blockquote>
<p>The separator and the format of strings X, Y may vary depending
on the domain. For example,</p>
<ul>
<li>for the validity files the separator is ~,</li>
<li>for UnicodeSet the separator is
-, and any multi-codepoint string is
enclosed in {…}.
</li>
</ul>
<p>
<strong>Validity: <br>
</strong>
</p>
<blockquote>
<p>
A string range X <em>sep</em> Y is valid iff len(X) ≥ len(Y) &gt; 0,
where len(X) is the length of X in code points.
</p>
<p>
<em>There may be additional, domain-specific requirements for
validity of the expansion of the string range.</em>
</p>
</blockquote>
<p>
<strong>Interpretation:<br>
</strong>
</p>
<ol>
<li>Break X into P and S, where len(S) = len(Y)
<ul>
<li>Note that P will be an empty string if the lengths of X
and Y are equal.</li>
</ul>
</li>
<li>Form the combinations of all P+(s₀..y₀)+(s₁..y₁)+...(sₙ..yₙ)
<ul>
<li>s₀ is the first code point in S, etc.</li>
</ul>
</li>
</ol>
<p>
<strong>Examples:</strong>
</p>
<table>
<tbody>
<tr>
<td>ab-ad</td>
<td>→</td>
<td>ab ac ad</td>
</tr>
<tr>
<td>ab-d</td>
<td>→</td>
<td>ab ac ad</td>
</tr>
<tr>
<td>ab-cd</td>
<td>→</td>
<td>ab ac ad bb bc bd cb cc cd</td>
</tr>
<tr>
<td>👦🏻-👦🏿</td>
<td>→</td>
<td>👦🏻 👦🏼 👦🏽 👦🏾 👦🏿</td>
</tr>
<tr>
<td>👦🏻-🏿</td>
<td>→</td>
<td>👦🏻 👦🏼 👦🏽 👦🏾 👦🏿</td>
</tr>
</tbody>
</table>
<br>
<h3>
<a name="Identity_Elements" href="#Identity_Elements">5.4
Identity Elements</a>
</h3>
<p class="dtd">&lt;!ELEMENT identity (alias | (version,
generation?, language, script?, territory?, variant?, special*) )
&gt;</p>
<p>The identity element contains information identifying the
target locale for this data, and general information about the
version of this data.</p>
<p class="element2">
&lt;version number=&quot;<u>$</u>Revision: 1.227 <u>$</u>&quot;&gt;
</p>
<p>The version element provides, in an attribute, the version of
this file.&nbsp; The contents of the element can contain textual
notes about the changes between this version and the last. For
example:</p>
<blockquote>
<pre>&lt;version number=&quot;<span style="color: blue">1.1</span>&quot;&gt;<span
style="color: blue">Various notes and changes in version 1.1</span>&lt;/version&gt;</pre>
<p>This is not to be confused with the version attribute on the
ldml element, which tracks the dtd version.</p>
</blockquote>
<p class="element2">
&lt;generation date=&quot;<u>$</u>Date: 2007/07/17 23:41:16 <u>$</u>&quot;
/&gt;
</p>
<p>The generation element is now deprecated. It was used to
contain the last modified date for the data. This could be in two
formats: ISO 8601 format, or CVS format (illustrated by the example
above).</p>
<p class="element2">
&lt;language type=&quot;<span style="color: blue">en</span>&quot;/&gt;
</p>
<p>The language code is the primary part of the specification of
the locale id, with values as described above.</p>
<p class="element2">
&lt;script type=&quot;<span style="color: blue">Latn</span>&quot;
/&gt;
</p>
<p>The script code may be used in the identification of written
languages, with values described above.</p>
<p class="element2">
&lt;territory type=&quot;<span style="color: blue">US</span>&quot;/&gt;
</p>
<p>The territory code is a common part of the specification of the
locale id, with values as described above.</p>
<p class="element2">
&lt;variant type=&quot;<span class="attributeValue">NYNORSK</span>&quot;/&gt;
</p>
<p>The variant code is the tertiary part of the specification of
the locale id, with values as described above.</p>
<p>
When combined according to the rules described in <i> <a
href="#Unicode_Language_and_Locale_Identifiers">Section 3,
Unicode Language and Locale Identifiers</a></i>, the language element,
along with any of the optional script, territory, and variant
elements, must identify a known, stable locale identifier. Otherwise,
it is an error.
</p>
<h3>
<a name="Valid_Attribute_Values" href="#Valid_Attribute_Values">5.5
Valid Attribute Values</a>
</h3>
<p>The valid attribute values, as well as other validity
information is contained in the supplementalMetadata.xml file. (Some,
but not all, of this information could have been represented in XML
Schema or a DTD.) Most of this is primarily for internal tool use.</p>
<p>The &lt;elementOrder&gt; and &lt;attributeOrder&gt; elements
are now deprecated, since the information regarding element and
attribute ordering is now contained in the DTD.</p>
<p>
<i>The suppress elements are those that are suppressed in
canonicalization.</i>
</p>
<p>
<i>The serialElements are those that do not inherit, and may have
ordering</i>
</p>
<blockquote>
<pre>&lt;serialElements&gt;attributeValues base comment extend first_non_ignorable first_primary_ignorable
first_secondary_ignorable first_tertiary_ignorable first_trailing first_variable i ic languagePopulation
last_non_ignorable last_primary_ignorable last_secondary_ignorable last_tertiary_ignorable last_trailing
last_variable optimize p pc reset rules s sc settings suppress_contractions t tRule tc variable x
&lt;/serialElements&gt;</pre>
</blockquote>
<p>
<i>The validity elements give the possible attribute values. They
are in the format of a series of variables, followed by
attributeValues. </i>
</p>
<blockquote>
<pre>&lt;variable id=&quot;$calendar&quot; type=&quot;choice&quot;&gt;
buddhist coptic ethiopic ethiopic-amete-alem chinese gregorian hebrew indian islamic islamic-civil
japanese arabic civil-arabic thai-buddhist persian roc&lt;/variable&gt;</pre>
</blockquote>
<p>The types indicate the style of match:</p>
<ul>
<li>choice: for a list of possible values</li>
<li>regex: for a regular expression match</li>
<li>notDoneYet: for items without matching criteria</li>
<li>locale: for locale IDs</li>
<li>list: for a space-delimited list of values</li>
<li>path: for a valid [<a href="#XPath">XPath</a>]
</li>
</ul>
<p>If the attribute order=&quot;given&quot; is supplied, it
indicates the order of elements when canonicalizing (see below).</p>
<p>The variable values are intended for internal testing, and the
definition and usage may change between releases. They do not
necessarily include all valid elements. For example, for primary
language codes, they include the subset that occur in CLDR locale
data. They are intended for a particular version of CLDR, and may
omit codes that were present in earlier versions, such as deprecated
codes.</p>
<p>The &lt;deprecated&gt; element lists elements, attributes, and
attribute values that are deprecated. If any deprecatedItems element
contains more than one attribute, then only the listed combinations
are deprecated. Thus the following means not that the draft attribute
is deprecated, but that the true and false values for that attribute
are:</p>
<blockquote>
<pre>&lt;deprecatedItems attributes=&quot;draft&quot; values=&quot;true false&quot;/&gt; </pre>
</blockquote>
<p>
Similarly, the following means that the <i>type</i> attribute is
deprecated, but only for the listed elements:
</p>
<blockquote>
<pre>&lt;deprecatedItems elements=&quot;abbreviationFallback default ... preferenceOrdering&quot; attributes=&quot;type&quot;/&gt; </pre>
</blockquote>
<p class="dtd">
&lt;!ELEMENT blockingItems EMPTY &gt;<br> &lt;!ATTLIST
blockingItems elements NMTOKENS #IMPLIED &gt;
</p>
<p>
The blockingItems were used to indicate which elements (and their child elements)
do not inherit. For example, because supplementalData is a blocking
item, all paths containing the element <span class="element">supplementalData</span>
do not inherit. However, <strong>the &lt;blockingItems&gt; element is now deprecated,</strong>
having been replaced by the annotations in the DTD and the DTDData classes in CLDR tooling.
</p>
<pre class="dtd">&lt;!ELEMENT distinguishingItems EMPTY &gt;
&lt;!ATTLIST distinguishingItems exclude ( true | false ) #IMPLIED &gt;
&lt;!ATTLIST distinguishingItems elements NMTOKENS #IMPLIED &gt;
&lt;!ATTLIST distinguishingItems attributes NMTOKENS #IMPLIED &gt;</pre>
<p>
The distinguishing items were used to indicate which combinations of elements and
attributes (in unblocked environments) are <i>distinguishing</i> in
performing inheritance. For example, the attribute type is
distinguishing <i>except</i> in combination with certain elements,
such as in the following. However, <strong>the &lt;distinguishingItems&gt; element is now deprecated,</strong>
having been replaced by the annotations in the DTD and the DTDData classes in CLDR tooling.
</p>
<pre>&lt;distinguishingItems
exclude=&quot;true&quot;
elements=&quot;default measurementSystem mapping abbreviationFallback preferenceOrdering&quot;
attributes=&quot;type&quot;/&gt;
</pre>
<h3>
<a name="Canonical_Form" href="#Canonical_Form">5.6 Canonical
Form</a>
</h3>
<p>The following are restrictions on the format of LDML files to
allow for easier parsing and comparison of files.</p>
<p>Peer elements have consistent order. That is, if the DTD or
this specification requires the following order in an element foo:</p>
<pre>&lt;foo&gt;
&lt;pattern&gt;
&lt;somethingElse&gt;
&lt;/foo&gt;</pre>
<p>It can never require the reverse order in a different element
bar.</p>
<pre>&lt;foo&gt;
&lt;somethingElse&gt;
&lt;pattern&gt;
&lt;/foo&gt;</pre>
<p>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:</p>
<pre class="dtd">&lt;!ELEMENT currency (alias | (pattern*, displayName?, symbol?, pattern*,
decimal?, group?, special*)) &gt;</pre>
<p>
<a href="http://www.w3.org/TR/REC-xml/">XML</a> 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.
</p>
<h4>
<a name="Content" href="#Content">5.6.1 Content</a>
</h4>
<ol>
<li>All start elements are on their own line, indented by <i>depth</i>
tabs.
</li>
<li>All end elements (except for leaf nodes) are on their own
line, indented by <i>depth</i> tabs.
</li>
<li>Any leaf node with empty content is in the form
&lt;foo/&gt;.</li>
<li>There are no blank lines except within comments or content.</li>
<li>Spaces are used within a start element. There are no extra
spaces within elements.
<ul>
<li><code>&lt;version number=&quot;1.2&quot;/&gt;</code>, not
<code>&lt;version&nbsp; number = &quot;1.2&quot; /&gt;</code></li>
<li><code>&lt;/identity&gt;</code>, not <code>&lt;/identity
&gt;</code></li>
</ul>
</li>
<li>All attribute values use double quote (&quot;), not single
(&#39;).</li>
<li>There are no CDATA sections, and no escapes except those
absolutely required.
<ul>
<li>no &amp;apos; since it is not necessary</li>
<li>no &#39;&amp;#x61;&#39;, it would be just &#39;a&#39;</li>
</ul>
</li>
<li>All attributes with defaulted values are suppressed.</li>
<li>The draft and alt=&quot;proposed.*&quot; attributes are only
on leaf elements.</li>
<li>The tzid are canonicalized in the following way:
<ol>
<li type="a">All tzids as of as CLDR 1.1 (2004.06.08) in
zone.tab are canonical.</li>
<li>After that point, the first time a tzid is introduced,
that is the canonical form.</li>
</ol>
<p>
That is, new IDs are added, but existing ones keep the original
form. The <i>TZ</i> timezone database keeps a set of equivalences
in the &quot;backward&quot; file. These are used to map other tzids
to the canonical form. For example, when
<code>America/Argentina/Catamarca</code>
was introduced as the new name for the previous
<code>America/Catamarca</code>
, a link was added in the backward file.
</p>
<p>
<code>Link America/Argentina/Catamarca America/Catamarca</code>
</p>
</li>
</ol>
<p>
<i>Example:</i>
</p>
<pre>&lt;ldml draft=&quot;unconfirmed&quot; &gt;
&lt;identity&gt;
&lt;version number=&quot;1.2&quot;/&gt;
&lt;language type=&quot;en&quot;/&gt;
&lt;territory type=&quot;AS&quot;/&gt;
&lt;/identity&gt;
&lt;numbers&gt;
&lt;currencyFormats&gt;
&lt;currencyFormatLength&gt;
&lt;currencyFormat&gt;
&lt;pattern&gt;¤#,##0.00;(¤#,##0.00)&lt;/pattern&gt;
&lt;/currencyFormat&gt;
&lt;/currencyFormatLength&gt;
&lt;/currencyFormats&gt;
&lt;/numbers&gt;
&lt;/ldml&gt;</pre>
<h4>
<a name="Ordering" href="#Ordering">5.6.2 Ordering</a>
</h4>
<p>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. For the latter, compare the first pair in each (in sorted
order by attribute pair). If not identical, go to the second pair,
and so on.</p>
<p>Elements and attributes are ordered according to their order in
the respective DTDs. Attribute value comparison is a bit more
complicated, and may depend on the attribute and type. This is
currently done with specific ordering tables.</p>
<p>
Any future additions to the DTD must be structured so as to allow
compatibility with this ordering. See also <a
href="#Valid_Attribute_Values">Section 5.5 Valid Attribute
Values.</a>
</p>
<h4>
<a name="Comments" href="#Comments">5.6.3 Comments</a>
</h4>
<ol>
<li>Comments are of the form &lt;!-- <i>stuff</i> --&gt;.
</li>
<li>They are logically attached to a node. There are 4 kinds:
<ol>
<li>Inline always appear after a leaf node, on the same line
at the end. These are a single line.</li>
<li>Preblock comments always precede the attachment node, and
are indented on the same level.</li>
<li>Postblock comments always follow the attachment node, and
are indented on the same level.</li>
<li>Final comment, after &lt;/ldml&gt;</li>
</ol>
</li>
<li>Multiline comments (except the final comment) have each line
after the first indented to one deeper level.</li>
</ol>
<p>
<b>Examples:</b>
</p>
<pre>&lt;eraAbbr&gt;
&lt;era type=&quot;0&quot;&gt;BC&lt;/era&gt; &lt;!-- might add alternate BDE in the future --&gt;
...
&lt;timeZoneNames&gt;
&lt;!-- Note: zones that do not use daylight time need further work --&gt;
&lt;zone type=&quot;America/Los_Angeles&quot;&gt;
...
&lt;!-- Note: the following is known to be sparse,
and needs to be improved in the future --&gt;
&lt;zone type=&quot;Asia/Jerusalem&quot;&gt;</pre>
<h3>
<a name="DTD_Annotations" href="#DTD_Annotations">5.7 DTD Annotations</a>
</h3>
<p>The information in a standard DTD is insufficient for use in CLDR. To make up for that, DTD annotations are added. These are of the form<br>
&lt;!--@...--&gt;<br>
and are included below the !ELEMENT or !ATTLIST line that they apply to. The current annotations are:</p>
<table>
<tr><th>Type</th><th>Description</th></tr>
<tr>
<td>&lt;!--@VALUE--&gt;</td>
<td>The attribute is not distinguishing, and is treated like an element value</td></tr>
<tr>
<td>&lt;!--@METADATA--&gt;</td>
<td>The attribute is a “comment” on the data, like the draft status. It is not typically used in implementations.</td>
</tr>
<tr>
<td>&lt;!--@ORDERED--&gt;</td>
<td>The element's children are ordered, and do not inherit.</td>
</tr>
<tr>
<td>&lt;!--@DEPRECATED--&gt;</td>
<td>The element or attribute is deprecated, and should not be used.</td>
</tr>
<tr>
<td>&lt;!--@DEPRECATED: attribute-value1, attribute-value2--&gt;</td>
<td>The attribute values are deprecated, and should not be used. Spaces
between tokens are not significant.</td>
</tr>
</table>
<p> There is additional information in the attributeValueValidity.xml
file that is used internally for testing. For example, the following
line indicates that the 'currency' element in the ldml dtd must have
values from the bcp47 'cu' type.</p>
<p class='example'> &lt;attributeValues dtds='ldml' elements='currency'
attributes='type'&gt;$_bcp47_cu&lt;/attributeValues&gt;</p>
<p>The element values may be literals, regular expressions, or variables
(some of which are set programmatically according to other CLDR data,
such as the above. However, the information as this point does not
cover all attribute values, is used only for testing, and should not
be used in implementations since the structure may change without
notice.</p>
<h2>
<a name="Property_Data" href="#Property_Data">6 Property Data</a>
</h2>
<p>Some data in CLDR does not use an XML format, but rather a
semicolon-delimited format derived from that of the Unicode Character
Database. That is because the data is more likely to be parsed by
implementations that already parse UCD data. Those files are present
in the common/properties directory.</p>
<p>Each file has a header that explains the format and usage of
the data.</p>
<h3><a name="Script_Metadata" href="#Script_Metadata">6.1 Script Metadata</a></h3>
<p><code>scriptMetadata.txt</code>: </p>
<p>This file provides general information about scripts that may be useful to implementations processing text. The information is the best currently available, and may change between versions of CLDR. The format is similar to Unicode Character Database property file, and is documented in the header of the data file.</p>
<h3><a name="Extended_Pictographic" href="#Extended_Pictographic">6.2 Extended Pictographic</a> </h3>
<p><code>ExtendedPictographic.txt</code></p>
<p>This file was used to define the ExtendedPictographic data used for “future-proofing” emoji behavior, especially in segmentation. As of Emoji version 11.0, the set of Extended_Pictographic is incorporated into the emoji data files found at <a href="https://unicode.org/Public/emoji/">unicode.org/Public/emoji/</a>.</p>
<h3><a name="Labels.txt" href="#Labels.txt">6.3 Labels.txt</a> </h3>
<p><code>labels.txt</code>: </p>
<p>This file provides general information about associations of labels to characters that may be useful to implementations of character-picking applications. The information is the best currently available, and may change between versions of CLDR. The format is similar to Unicode Character Database property file, and is documented in the header of the data file.</p>
<p>Initially, the contents are focused on emoji, but may be expanded in the future to other types of characters. Note that a character may have multiple labels.</p>
<h2>
<a name="Format_Parse_Issues" href="#Format_Parse_Issues">7
Issues in Formatting and Parsing</a>
</h2>
<h3>
<a name="Lenient_Parsing" href="#Lenient_Parsing">7.1 Lenient Parsing</a>
</h3>
<h4>
<a name="Motivation" href="#Motivation">7.1.1 Motivation</a>
</h4>
<p>User input is frequently messy. Attempting to parse it by
matching it exactly against a pattern is likely to be unsuccessful,
even when the meaning of the input is clear to a human being. For
example, for a date pattern of &quot;MM/dd/yy&quot;, the input
&quot;June 1, 2006&quot; will fail.</p>
<p>The goal of lenient parsing is to accept user input whenever it
is possible to decipher what the user intended. Doing so requires
using patterns as data to guide the parsing process, rather than an
exact template that must be matched. This informative section
suggests some heuristics that may be useful for lenient parsing of
dates, times, and numbers.</p>
<h4>
<a name="Loose_Matching" href="#Loose_Matching">7.1.2 Loose Matching</a>
</h4>
<p>Loose matching ignores attributes of the strings being compared
that are not important to matching. It involves the following steps:</p>
<ul>
<li>Remove &quot;.&quot; from currency symbols and other fields
used for matching, and also from the input string unless:
<ul>
<li>&quot;.&quot; is in the decimal set, and</li>
<li>its position in the input string is immediately before a
decimal digit</li>
</ul>
</li>
<li>Ignore all format characters: in particular, ignore any
RLM, LRM or ALM used to control BIDI formatting.</li>
<li>Ignore all characters in [:Zs:] unless they occur between
letters. (In the heuristics below, even those between letters are
ignored except to delimit fields)</li>
<li>Map all characters in [:Dash:] to U+002D HYPHEN-MINUS</li>
<li>Use the data in the &lt;character-fallback&gt; element to
map equivalent characters (for example, curly to straight
apostrophes). Other apostrophe-like characters should also be
treated as equivalent, especially if the character actually used in
a format may be unavailable on some keyboards. For example:
<ul>
<li>U+02BB MODIFIER LETTER TURNED COMMA (ʻ) might be typed
instead as U+2018 LEFT SINGLE QUOTATION MARK (‘).</li>
<li>U+02BC MODIFIER LETTER APOSTROPHE (ʼ) might be typed
instead as U+2019 RIGHT SINGLE QUOTATION MARK (’), U+0027
APOSTROPHE, etc.</li>
<li>U+05F3 HEBREW PUNCTUATION GERESH (‎׳) might be typed
instead as U+0027 APOSTROPHE.</li>
</ul>
</li>
<li>Apply mappings particular to the domain (i.e., for dates or
for numbers, discussed in more detail below)</li>
<li>Apply case folding (possibly including language-specific
mappings such as Turkish i)</li>
<li>Normalize to NFKC; thus <i>no-break space</i> will map to <i>
space</i>; half-width <i>katakana</i> will map to full-width.
</li>
</ul>
<p>Loose matching involves (logically) applying the above
transform to both the input text and to each of the field elements
used in matching, before applying the specific heuristics below. For
example, if the input number text is &quot; - NA f. 1,000.00&quot;,
then it is mapped to &quot;-naf1,000.00&quot; before processing. The
currency signs are also transformed, so &quot;NA f.&quot; is
converted to &quot;naf&quot; for purposes of matching. As with other
Unicode algorithms, this is a logical statement of the process;
actual implementations can optimize, such as by applying the
transform incrementally during matching.</p>
<h3>
<a name="Invalid_Patterns" href="#Invalid_Patterns">7.2 Handling
Invalid Patterns</a>
</h3>
<p>Processes sometimes encounter invalid number or
date patterns, such as a number pattern with “¤¤¤¤¤” (valid pattern
character but invalid length in current CLDR), a date pattern with
“nn” (invalid pattern character in current CLDR), or a date pattern
with “MMMMMM” (invalid length in current CLDR). The recommended
behavior for handling such an invalid pattern field is:</p>
<ul>
<li>For a field using a currently-invalid length for a valid
pattern character:
<ul>
<li>In <strong>formatting, </strong>emit U+FFFD REPLACEMENT
CHARACTER for the invalid field.
</li>
<li>In <strong>parsing, </strong>the field may be parsed as if
it had a valid length.
</li>
</ul>
</li>
<li>For a pattern that contains a currently-invalid pattern
character (applies only to date patterns, for which A-Za-z are
reserved as pattern characters but not all defined as valid):
<ul>
<li>Produce an error (set an error code or throw an exception)
when an attempt is made to create a formatter with such a pattern
or to apply such a pattern to an existing formatter.</li>
</ul>
</li>
</ul>
<h2>
<a name="Deprecated_Structure" href="#Deprecated_Structure">Annex A
Deprecated Structure</a>
</h2>
<p>The deprecated elements, attributes, and values are listed in
the supplementalMetadata.xml file, under &lt;deprecatedItems&gt;.
While valid LDML, it is strongly discouraged, and no longer used in
CLDR.</p>
<p>The remainder of this section describes selected cases of
deprecated structure that were present in previous versions of CLDR.
</p>
<h3>
<a name="Fallback_Elements" href="#Fallback_Elements">A.1 Element
fallback</a>
</h3>
<p class="dtd">&lt;!ELEMENT fallback (#PCDATA) &gt;</p>
<p>
The fallback element is deprecated. Implementations should use
instead the information in <em><a href="#LanguageMatching">Section
4.4 Language Matching</a></em> for doing language fallback.
</p>
<h3>
<a name="BCP47_Keyword_Mapping" href="#BCP47_Keyword_Mapping">A.2
BCP 47 Keyword Mapping</a>
</h3>
<p>
<b>Note:</b> <i>This structure is deprecated and replaced with <a
href="#Unicode_Locale_Extension_Data_Files">Section 3.6.4 U
Extension Data Files</a>.
</i>
</p>
<p class="dtd">
&lt;!ELEMENT bcp47KeywordMappings ( mapKeys?, mapTypes* ) &gt;<br>
&lt;!ELEMENT mapKeys ( keyMap* ) &gt;<br> &lt;!ELEMENT keyMap
EMPTY &gt;<br> &lt;!ATTLIST keyMap type NMTOKEN #REQUIRED &gt;<br>
&lt;!ATTLIST keyMap bcp47 NMTOKEN #REQUIRED &gt;<br>
&lt;!ELEMENT mapTypes ( typeMap* ) &gt;<br> &lt;!ATTLIST
mapTypes type NMTOKEN #REQUIRED &gt;<br> &lt;!ELEMENT typeMap
EMPTY &gt;<br> &lt;!ATTLIST typeMap type CDATA #REQUIRED &gt;<br>
&lt;!ATTLIST typeMap bcp47 NMTOKEN #REQUIRED &gt;<br>
</p>
<p>
This section defines mappings between old Unicode locale identifier
key/type values and their BCP 47 'u' extension subtag
representations. The 'u' extension syntax described in <a
href="#u_Extension">Section 3.6 Unicode BCP 47 U Extension</a>
restricts a key to two ASCII alphanumerics and a type to three to
eight ASCII alphanumerics. A key or a type which does not meet that
syntax requirement is converted according to the mapping data defined
by the mapKeys or mapTypes elements. For example, a keyword
"collation=phonebook" is converted to BCP 47 'u' extension subtags
"co-phonebk" by the mapping data below:
</p>
<pre> &lt;mapKeys&gt;
...
&lt;keyMap type="collation" bcp47="co"/&gt;
...
&lt;/mapKeys&gt;
&lt;mapTypes type="collation"&gt;
...
&lt;typeMap type="phonebook" bcp47="phonebk"/&gt;
...
&lt;/mapTypes&gt;
</pre>
<h3>
<a name="Choice_Patterns" href="#Choice_Patterns">A.3 Choice
Patterns</a>
</h3>
<p>
<b>Note:</b> <i>This structure is deprecated and replaced with
count attributes.</i>
</p>
<p>A choice pattern is a string that chooses among a number of
strings, based on numeric value. It has the following form:</p>
<p>
&lt;choice_pattern&gt; = &lt;choice&gt; ( &#39;|&#39; &lt;choice&gt;
)*<br> &lt;choice&gt; =
&lt;number&gt;&lt;relation&gt;&lt;string&gt;<br> &lt;number&gt;
= (&#39;+&#39; | &#39;-&#39;)? (<font size="3">&#39;∞&#39; |
[0-9]+ (&#39;.&#39; [0-9]+)?)<br> &lt;relation&gt; =
&#39;&lt;&#39; | &#39;
</font><span style="color: blue">≤&#39;</span>
</p>
<p>The interpretation of a choice pattern is that given a number
N, the pattern is scanned from right to left, for each choice
evaluating &lt;number&gt; &lt;relation&gt; N. The first choice that
matches results in the corresponding string. If no match is found,
then the first string is used. For example:</p>
<table border="1" cellpadding="0" cellspacing="0">
<tr>
<td width="33%">Pattern</td>
<td width="33%">N</td>
<td width="34%">Result</td>
</tr>
<tr>
<td width="33%" rowspan="4">0≤Rf|1≤Ru|1&lt;Re</td>
<td width="33%">-<font size="3">∞, </font>-3, -1, -0.000001
</td>
<td width="34%">Rf (defaulted to first string)</td>
</tr>
<tr>
<td width="33%">0, 0.01, 0.9999</td>
<td width="34%">Rf</td>
</tr>
<tr>
<td width="33%">1</td>
<td width="34%">Ru</td>
</tr>
<tr>
<td width="33%">1.00001, 5, 99, <font size="3">∞</font></td>
<td width="34%">Re</td>
</tr>
</table>
<p>Quoting is done using &#39; characters, as in date or number
formats.</p>
<h3>
<a name="Element_default" href="#Element_default">A.4 Element
default</a>
</h3>
<p>
<b>Note:</b> <i>This structure is deprecated. </i> Use replacement
structure instead, for example:
</p>
<ul>
<li>For &lt;collations&gt;, now use the &lt;defaultCollation&gt;
element.</li>
<li>For &lt;calendars&gt;, the default calendar type for a
locale is now specified by <i><a
href="tr35-dates.html#Calendar_Preference_Data">Calendar
Preference Data</a></i>.
</li>
</ul>
<p>In some cases, a number of elements are present. The default
element can be used to indicate which of them is the default, in the
absence of other information. The value of the choice attribute is to
match the value of the type attribute for the selected item.</p>
<pre>&lt;timeFormats&gt;
&lt;default choice=&quot;<span style="color: red">medium</span>&quot; /&gt;
&lt;timeFormatLength type=&quot;<span style="color: blue">full</span>&quot;&gt;
&lt;timeFormat type=&quot;<span style="color: blue">standard</span>&quot;&gt;
&lt;pattern type=&quot;<span style="color: blue">standard</span>&quot;&gt;<span
style="color: blue">h:mm:ss a z</span>&lt;/pattern&gt;
&lt;/timeFormat&gt;
&lt;/timeFormatLength&gt;
&lt;timeFormatLength type=&quot;<span style="color: blue">long</span>&quot;&gt;
&lt;timeFormat type=&quot;<span style="color: blue">standard</span>&quot;&gt;
&lt;pattern type=&quot;<span style="color: blue">standard</span>&quot;&gt;<span
style="color: blue">h:mm:ss a z</span>&lt;/pattern&gt;
&lt;/timeFormat&gt;
&lt;/timeFormatLength&gt;
&lt;timeFormatLength type=&quot;<span style="color: red">medium</span>&quot;&gt;
&lt;timeFormat type=&quot;<span style="color: blue">standard</span>&quot;&gt;
&lt;pattern type=&quot;<span style="color: blue">standard</span>&quot;&gt;<span
style="color: blue">h:mm:ss a</span>&lt;/pattern&gt;
&lt;/timeFormat&gt;
&lt;/timeFormatLength&gt;
...</pre>
<p>Like all other elements, the &lt;default&gt; element is
inherited. Thus, it can also refer to inherited resources. For
example, suppose that the above resources are present in fr, and that
in fr_BE we have the following:</p>
<pre>&lt;timeFormats&gt;
&lt;default choice=&quot;<span style="color: red">long</span>&quot;/&gt;
&lt;/timeFormats&gt;</pre>
<p>In that case, the default time format for fr_BE would be the
inherited &quot;long&quot; resource from fr. Now suppose that we had
in fr_CA:</p>
<pre> &lt;timeFormatLength type=&quot;<span style="color: red">medium</span>&quot;&gt;
&lt;timeFormat type=&quot;<span style="color: blue">standard</span>&quot;&gt;
&lt;pattern type=&quot;<span style="color: blue">standard</span>&quot;&gt;<span
style="color: blue">...</span>&lt;/pattern&gt;
&lt;/timeFormat&gt;
&lt;/timeFormatLength&gt;
</pre>
<p>In this case, the &lt;default&gt; is inherited from fr, and has
the value &quot;medium&quot;. It thus refers to this new
&quot;medium&quot; pattern in this resource bundle.</p>
<h3>
<a name="Deprecated_Common_Attributes"
href="#Deprecated_Common_Attributes">A.5 Deprecated Common
Attributes</a>
</h3>
<h4>
<a name="Attribute_standard" href="#Attribute_standard">A.5.1 Attribute standard</a>
</h4>
<p class="element2">
<b>Note: </b>This attribute is deprecated. Instead, use a reference
element with the attribute standard=&quot;true&quot;.
</p>
<p>The value of this attribute is a list of strings representing
standards: international, national, organization, or vendor
standards. The presence of this attribute indicates that the data in
this element is compliant with the indicated standards. Where
possible, for uniqueness, the string should be a URL that represents
that standard. The strings are separated by commas; leading or
trailing spaces on each string are not significant. Examples:</p>
<p>
<code>
&lt;collation standard=&quot;<span style="color: blue">MSA
200:2002</span>&quot;&gt;<br> ...<br> &lt;dateFormatStyle
standard=”http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780&amp;amp;ICS1=1&amp;amp;ICS2=140&amp;amp;ICS3=30”&gt;
</code>
</p>
<h4>
<a name="Attribute_draft_nonLeaf" href="#Attribute_draft_nonLeaf">A.5.2
Attribute draft in non-leaf elements</a>
</h4>
<p>The draft attribute is deprecated except in
leaf elements (elements that do not have any subelements)</p>
<h3>
<a name="Element_base" href="#Element_base">A.6 Element base</a>
</h3>
<p>
<b>Note:</b> <i>This element is deprecated.</i> Use the collation
&lt;import&gt; element instead.
</p>
<p>
The optional base element
<code>
&lt;base&gt;<span style="color: blue">...</span>&lt;/base&gt;
</code>
, contains an alias element that points to another data source that
defines a <i>base </i>collation. If present, it indicates that the
settings and rules in the collation are modifications applied on <i>top
of the</i> respective elements in the base collation. That is, any
successive settings, where present, override what is in the base as
described in <a href="tr35-collation.html#Setting_Options">Setting
Options</a>. Any successive rules are concatenated to the end of the
rules in the base. The results of multiple rules applying to the same
characters is covered in <a href="tr35-collation.html#Orderings">Orderings</a>.
</p>
<h3>
<a name="Element_rules" href="#Element_rules">A.7 Element rules</a>
</h3>
<p>
<b>Note:</b> <i>The XML collation syntax is deprecated; this
includes the &lt;rules&gt; element and its subelements, except that
the &lt;import&gt; element has been moved up to be a subelement of
&lt;collation&gt;.</i> Use the basic collation syntax with the <a
href="tr35-collation.html#Rules">&lt;cr&gt; element</a> instead.
</p>
<p class="dtd">&lt;!ELEMENT rules (alias | ( ( reset | import ), (
reset | import | p | pc | s | sc | t | tc | i | ic | x)* )) &gt;</p>
<h3>
<a name="Deprecated_subelements_of_dates"
href="#Deprecated_subelements_of_dates">A.8 Deprecated
subelements of &lt;dates&gt;</a>
</h3>
<ul>
<li>&lt;localizedPatternChars&gt;</li>
<li>&lt;dateRangePattern&gt;, replaced by
&lt;intervalFormats&gt;.</li>
</ul>
<h3>
<a name="Deprecated_subelements_of_calendars"
href="#Deprecated_subelements_of_calendars">A.9 Deprecated
subelements of &lt;calendars&gt;</a>
</h3>
<ul>
<li>&lt;monthNames&gt; and &lt;monthAbbr&gt;; month name forms
are specified in the &lt;months&gt; element. The older monthNames,
monthAbbr are equivalent to: using the months element with the
context type=&quot;<span style="color: blue">format</span>&quot; and
the width type=&quot;<span style="color: blue">wide</span>&quot;
(for ...Names) and type=&quot;<span style="color: blue">narrow</span>&quot;
(for ...Abbr), respectively.
</li>
<li>&lt;dayNames&gt; and &lt;dayAbbr&gt;; weekday name forms are
specified in the &lt;days&gt; element. The older dayNames, dayAbbr
are equivalent to: using the days element with the context
type=&quot;<span style="color: blue">format</span>&quot; and the
width type=&quot;<span style="color: blue">wide</span>&quot; (for
...Names) and type=&quot;<span style="color: blue">narrow</span>&quot;
(for ...Abbr), respectively.
</li>
<li><a name="week" href="#week">&lt;week&gt;</a> is deprecated
in the main LDML files, because the data is more appropriately
organized as connected to territories, not to linguistic data. Use
the supplemental &lt;weekData&gt; element instead.</li>
<li>&lt;am&gt; and &lt;pm&gt;; these are now included as part of
the &lt;dayPeriods&gt; element</li>
<li>&lt;fields&gt; is deprecated as a subelement of
&lt;calendars&gt; instead, a &lt;fields&gt; element should be
located just under a &lt;dates&gt; element. See <a
href="tr35-dates.html#Calendar_Fields">Calendar Fields</a>.
</li>
</ul>
<h3>
<a name="Deprecated_subelements_of_timeZoneNames"
href="#Deprecated_subelements_of_timeZoneNames">A.10 Deprecated
subelements of &lt;timeZoneNames&gt;</a>
</h3>
<ul>
<li>&lt;hoursFormat&gt; e.g. &quot;{0}/{1}&quot; for
&quot;-0800/-0700&quot;</li>
<li><a name="fallbackRegionFormat" href="#fallbackRegionFormat">&lt;fallbackRegionFormat&gt;</a>
(deprecated), e.g. &quot;{0} Time ({1})&quot; for &quot;United
States Time (New York)&quot;</li>
<li>&lt;abbreviationFallback&gt;</li>
<li>&lt;preferenceOrdering&gt;, a preference ordering among
modern zones; use metazones instead.</li>
<li>&lt;singleCountries&gt;, use <a
href="tr35-dates.html#Primary_Zones">Primary Zones</a></li>
</ul>
<h3>
<a name="Deprecated_subelements_of_zone_metazone"
href="#Deprecated_subelements_of_zone_metazone">A.11 Deprecated
subelements of &lt;zone&gt; and &lt;metazone&gt;</a>
</h3>
<ul>
<li>&lt;commonlyUsed&gt;, formerly used to indicate whether a
zone was commonly used in the locale.</li>
</ul>
<h3>
<a name="Renamed_attribute_values_for_contextTransformUsage"
href="#Renamed_attribute_values_for_contextTransformUsage">A.12
Renamed attribute values for &lt;contextTransformUsage&gt; element</a>
</h3>
<p>
The &lt;contextTransformUsage&gt; element was introduced in CLDR 21.
The values for its <em>type</em> attribute are documented in <a
href="tr35-general.html#contextTransformUsage_type_attribute_values">
&lt;contextTransformUsage&gt; type attribute values</a>. In CLDR 25,
some of these values were renamed from their previous values for
improved clarity:
</p>
<ul>
<li>"type" was renamed to "keyValue"</li>
<li>"displayName" was renamed to "currencyName"</li>
<li>"displayName-count" was renamed to "currencyName-count"</li>
<li>"tense" was renamed to "relative"</li>
</ul>
<h3>
<a name="Deprecated_subelements_of_segmentations"
href="#Deprecated_subelements_of_segmentations">A.13 Deprecated
subelements of &lt;segmentations&gt;</a>
</h3>
<ul>
<li>&lt;exceptions&gt; and &lt;exceptions&gt; were deprecated
and replaced with &lt;suppressions&gt; and &lt;suppression&gt;.</li>
</ul>
<h3>
<a name="Element_cp" href="#Element_cp">A.14 Element cp</a>
</h3>
<p>The cp element was used to escape characters that cannot be
represented in XML, even with NCRs. These escapes were only allowed
in certain elements, according to the DTD.</p>
<p>However, this mechanism is very clumsy, and was replaced by
specialized syntax.</p>
<table>
<tr>
<th>Code Point</th>
<th>XML Example</th>
</tr>
<tr>
<td><code>U+0000</code></td>
<td><code>&lt;cp hex=&quot;0&quot;&gt;</code></td>
</tr>
</table>
<p>&nbsp;</p>
<h3>
<a name="validSubLocales" href="#validSubLocales">A.15 Attribute
validSubLocales</a>
</h3>
<p>
The attribute <i>validSubLocales</i> allowed sublocales in a given
tree to be treated as though a file for them were present when there
was not one. It only had an effect for locales that inherit from the
current file where a file is missing.
</p>
<p>
<b>Example 1. </b>Suppose that in a particular LDML tree, there are
no region locales for German, for example, 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.
</p>
<p>
<code>
&lt;ldml version=&quot;1.1&quot;&gt;<br> &nbsp;&lt;identity&gt;<br>
&nbsp; &lt;version number=&quot;1.1&quot; /&gt; <br> &nbsp; &lt;language type=&quot;de&quot; /&gt; <br> &nbsp;
&lt;territory type=&quot;AT&quot; /&gt; <br>
&nbsp;&lt;/identity&gt;<br> &lt;/ldml&gt;
</code>
</p>
<p>
With the <i>validSubLocales</i> attribute, instead of adding the
empty files for de_AT.xml, de_CH.xml, and de_DE.xml, in the de file
we could add to the parent locale a list of the child locales that
should behave as if files were present.
</p>
<p>
<code>
&lt;ldml version=&quot;1.1&quot; validSubLocales=&quot;de_AT de_CH
de_DE&quot;&gt;<br> &nbsp;&lt;identity&gt;<br> &nbsp;
&lt;version number=&quot;1.1&quot; /&gt; <br> &nbsp;
&lt;language type=&quot;de&quot; /&gt; <br>
&nbsp;&lt;/identity&gt;<br> ...<br> &lt;/ldml&gt;
</code>
</p>
<p>
Now that the <i>validSubLocales</i> attribute has been deprecated, it
is recommended to simply add empty files to specify which sublocales
are valid. This convention is used throughout the CLDR.
</p>
<h3>
<a name="postCodeElements" href="#postCodeElements">A.16 Elements
postalCodeData, postCodeRegex</a>
</h3>
<p>The postal code validation data has been deprecated. Please see
other services that are kept up to date, such as:</p>
<ul>
<li><a href="http://i18napis.appspot.com/address/data/US">http://i18napis.appspot.com/address/data/US</a></li>
<li><a href="http://i18napis.appspot.com/address/data/CH">http://i18napis.appspot.com/address/data/CH</a></li>
<li>...</li>
</ul>
<p>
See <a href="tr35-info.html#Postal_Code_Validation">Postal Code
Validation</a>
</p>
<h3>
<a name="telephoneCodeData" href="#telephoneCodeData">A.17 Element
telephoneCodeData</a>
</h3>
<p>The element &lt;telephoneCodeData&gt; and its subelements have
been deprecated and the data removed.</p>
<hr>
<h2>
<a name="Links_to_Other_Parts" href="#Links_to_Other_Parts">Annex B
Links to Other Parts</a>
</h2>
<p>
The LDML specification is split into several <a href="#Parts">parts</a>
by topic, with one HTML document per part. The following tables
provide redirects for links to specific topics. Please update your
links and bookmarks.
</p>
<p>Part 1 Links: Core (this document): No redirects needed.</p>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_2_Links" name="Part_2_Links">Part 2 Links</a>: <a
href="tr35-general.html">General</a> (display names &amp;
transforms, etc.)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td>5.4 <a name="Display_Name_Elements"
href="#Display_Name_Elements">Display Name Elements</a></td>
<td>1 <a href="tr35-general.html#Display_Name_Elements">Display
Name Elements</a></td>
</tr>
<tr>
<td>5.5 <a name="Layout_Elements" href="#Layout_Elements">Layout
Elements</a></td>
<td>2 <a href="tr35-general.html#Layout_Elements">Layout
Elements</a></td>
</tr>
<tr>
<td>5.6 <a name="Character_Elements" href="#Character_Elements">Character
Elements</a></td>
<td>3 <a href="tr35-general.html#Character_Elements">Character
Elements</a></td>
</tr>
<tr>
<td>5.6.1 <a name="ExemplarSyntax" href="#ExemplarSyntax">Exemplar
Syntax</a></td>
<td>3.1 <a href="tr35-general.html#ExemplarSyntax">Exemplar
Syntax</a></td>
</tr>
<tr>
<td>5.6.2 Restrictions</td>
<td>3.1 <a href="tr35-general.html#ExemplarSyntax">Exemplar
Syntax</a></td>
</tr>
<tr>
<td>5.6.3 Mapping</td>
<td>3.2 <a href="tr35-general.html#Character_Mapping">Mapping</a></td>
</tr>
<tr>
<td>5.6.4 <a name="IndexLabels" href="#IndexLabels">Index
Labels</a></td>
<td>3.3 <a href="tr35-general.html#IndexLabels">Index
Labels</a></td>
</tr>
<tr>
<td>5.6.5 Ellipsis</td>
<td>3.4 <a href="tr35-general.html#Ellipsis">Ellipsis</a></td>
</tr>
<tr>
<td>5.6.6 More Information</td>
<td>3.5 <a href="tr35-general.html#Character_More_Info">More
Information</a></td>
</tr>
<tr>
<td>5.7 <a name="Delimiter_Elements" href="#Delimiter_Elements">Delimiter
Elements</a></td>
<td>4 <a href="tr35-general.html#Delimiter_Elements">Delimiter
Elements</a></td>
</tr>
<tr>
<td>C.6 <a name="Measurement_System_Data"
href="#Measurement_System_Data">Measurement System Data</a></td>
<td>5 <a href="tr35-general.html#Measurement_System_Data">Measurement
System Data</a></td>
</tr>
<tr>
<td>5.8 <a name="Measurement_Elements"
href="#Measurement_Elements">Measurement Elements (deprecated)</a></td>
<td>5.1 <a href="tr35-general.html#Measurement_Elements">Measurement
Elements (deprecated)</a></td>
</tr>
<tr>
<td>5.11 <a name="Unit_Elements" href="#Unit_Elements">Unit
Elements</a></td>
<td>6 <a href="tr35-general.html#Unit_Elements">Unit
Elements</a></td>
</tr>
<tr>
<td>5.12 <a name="POSIX_Elements" href="#POSIX_Elements">POSIX
Elements</a></td>
<td>7 <a href="tr35-general.html#POSIX_Elements">POSIX
Elements</a></td>
</tr>
<tr>
<td>5.13 <a name="Reference_Elements"
href="#Reference_Elements">Reference Element</a></td>
<td>8 <a href="tr35-general.html#Reference_Elements">Reference
Element</a></td>
</tr>
<tr>
<td>5.15 <a name="Segmentations" href="#Segmentations">Segmentations</a></td>
<td>9 <a href="tr35-general.html#Segmentations">Segmentations</a></td>
</tr>
<tr>
<td>5.15.1 <a name="Segmentation_Inheritance"
href="#Segmentation_Inheritance">Segmentation Inheritance</a></td>
<td>9.1 <a href="tr35-general.html#Segmentation_Inheritance">Segmentation
Inheritance</a></td>
</tr>
<tr>
<td>5.16 <a name="Transforms" href="#Transforms">Transforms</a></td>
<td>10 <a href="tr35-general.html#Transforms">Transforms</a></td>
</tr>
<tr>
<td>N <a name="Transform_Rules" href="#Transform_Rules">Transform
Rules</a></td>
<td>10.3 <a href="tr35-general.html#Transform_Rules_Syntax">Transform
Rules Syntax</a></td>
</tr>
<tr>
<td>5.18 <a name="ListPatterns" href="#ListPatterns">List
Patterns</a></td>
<td>11 <a href="tr35-general.html#ListPatterns">List
Patterns</a></td>
</tr>
<tr>
<td>C.20 <a name="List_Gender" href="#List_Gender">Gender
of Lists</a></td>
<td>11.1 <a href="tr35-general.html#List_Gender">Gender of
Lists</a></td>
</tr>
<tr>
<td>5.19 <a name="Context_Transform_Elements"
href="#Context_Transform_Elements">ContextTransform Elements</a></td>
<td>12 <a href="tr35-general.html#Context_Transform_Elements">ContextTransform
Elements</a></td>
</tr>
<tr>
<td></td>
<td><a href="tr35-general.html#"></a></td>
</tr>
</table>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_3_Links" name="Part_3_Links">Part 3 Links</a>: <a
href="tr35-numbers.html">Numbers</a> (number &amp; currency
formatting)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td>C.13 <a name="Numbering_Systems" href="#Numbering_Systems">Numbering
Systems</a></td>
<td>1 <a href="tr35-numbers.html#Numbering_Systems">Numbering
Systems</a></td>
</tr>
<tr>
<td>5.10 <a name="Number_Elements" href="#Number_Elements">Number
Elements</a></td>
<td>2 <a href="tr35-numbers.html#Number_Elements">Number
Elements</a></td>
</tr>
<tr>
<td>5.10.1 <a name="Number_Symbols" href="#Number_Symbols">Number
Symbols</a></td>
<td>2.3 <a href="tr35-numbers.html#Number_Symbols">Number
Symbols</a></td>
</tr>
<tr>
<td>G <a name="Number_Format_Patterns"
href="#Number_Format_Patterns">Number Format Patterns</a></td>
<td>3 <a href="tr35-numbers.html#Number_Format_Patterns">Number
Format Patterns</a></td>
</tr>
<tr>
<td>5.10.2 <a name="Currencies" href="#Currencies">Currencies</a></td>
<td>4 <a href="tr35-numbers.html#Currencies">Currencies</a></td>
</tr>
<tr>
<td>C.1 <a name="Supplemental_Currency_Data"
href="#Supplemental_Currency_Data">Supplemental Currency Data</a></td>
<td>4.1 <a href="tr35-numbers.html#Supplemental_Currency_Data">Supplemental
Currency Data</a></td>
</tr>
<tr>
<td>C.11 <a name="Language_Plural_Rules"
href="#Language_Plural_Rules">Language Plural Rules</a></td>
<td>5 <a href="tr35-numbers.html#Language_Plural_Rules">Language
Plural Rules</a></td>
</tr>
<tr>
<td>5.17 <a name="Rule-Based_Number_Formatting"
href="#Rule-Based_Number_Formatting">Rule-Based Number
Formatting</a></td>
<td>6 <a href="tr35-numbers.html#Rule-Based_Number_Formatting">Rule-Based
Number Formatting</a></td>
</tr>
</table>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_4_Links" name="Part_4_Links">Part 4 Links</a>: <a
href="tr35-dates.html">Dates</a> (date, time, time zone formatting)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td><a name="Date_Elements" href="#Date_Elements">5.9 Date
Elements</a></td>
<td>1 <a
href="tr35-dates.html#Overview_Dates_Element_Supplemental">Overview:
Dates Element, Supplemental Date and Calendar Information</a></td>
</tr>
<tr>
<td><a name="Calendar_Elements" href="#Calendar_Elements">5.9.1
Calendar Elements</a></td>
<td>2 <a href="tr35-dates.html#Calendar_Elements">Calendar
Elements</a></td>
</tr>
<tr>
<td><a name="months_days_quarters_eras"
href="#months_days_quarters_eras">Elements months, days,
quarters, eras</a></td>
<td>2.1 <a href="tr35-dates.html#months_days_quarters_eras">Elements
months, days, quarters, eras</a></td>
</tr>
<tr>
<td><a name="monthPatterns_cyclicNameSets"
href="#monthPatterns_cyclicNameSets">Elements monthPatterns,
cyclicNameSets</a></td>
<td>2.2 <a href="tr35-dates.html#monthPatterns_cyclicNameSets">Elements
monthPatterns, cyclicNameSets</a></td>
</tr>
<tr>
<td><a name="dayPeriods" href="#dayPeriods">Element
dayPeriods</a></td>
<td>2.3 <a href="tr35-dates.html#dayPeriods">Element
dayPeriods</a></td>
</tr>
<tr>
<td><a name="dateFormats" href="#dateFormats">Element
dateFormats</a></td>
<td>2.4 <a href="tr35-dates.html#dateFormats">Element
dateFormats</a></td>
</tr>
<tr>
<td><a name="timeFormats" href="#timeFormats">Element
timeFormats</a></td>
<td>2.5 <a href="tr35-dates.html#timeFormats">Element
timeFormats</a></td>
</tr>
<tr>
<td><a name="dateTimeFormats" href="#dateTimeFormats">Element
dateTimeFormats</a></td>
<td>2.6 <a href="tr35-dates.html#dateTimeFormats">Element
dateTimeFormats</a></td>
</tr>
<tr>
<td><a name="Calendar_Fields" href="#Calendar_Fields">5.9.2
Calendar Fields</a></td>
<td>3 <a href="tr35-dates.html#Calendar_Fields">Calendar
Fields</a></td>
</tr>
<tr>
<td>5.9.3 <a name="Timezone_Names" href="#Timezone_Names">Time
Zone Names</a></td>
<td>5 <a href="tr35-dates.html#Time_Zone_Names">Time Zone
Names</a></td>
</tr>
<tr>
<td><a name="Supplemental_Calendar_Data"
href="#Supplemental_Calendar_Data">C.5 Supplemental Calendar
Data</a></td>
<td>4 <a href="tr35-dates.html#Supplemental_Calendar_Data">Supplemental
Calendar Data</a></td>
</tr>
<tr>
<td><a name="Supplemental_Timezone_Data"
href="#Supplemental_Timezone_Data">C.7 Supplemental Time Zone
Data</a></td>
<td>6 <a href="tr35-dates.html#Supplemental_Time_Zone_Data">Supplemental
Time Zone Data</a></td>
</tr>
<tr>
<td><a name="Calendar_Preference_Data"
href="#Calendar_Preference_Data">C.15 Calendar Preference Data</a></td>
<td>4.2 <a href="tr35-dates.html#Calendar_Preference_Data">Calendar
Preference Data</a></td>
</tr>
<tr>
<td><a name="DayPeriodRules" href="#DayPeriodRules">C.17
DayPeriod Rules</a></td>
<td>4.5 <a href="tr35-dates.html#Day_Period_Rules">Day
Period Rules</a></td>
</tr>
<tr>
<td><a name="Date_Format_Patterns" href="#Date_Format_Patterns">Appendix
F: Date Format Patterns</a></td>
<td>8 <a href="tr35-dates.html#Date_Format_Patterns">Date
Format Patterns</a></td>
</tr>
<tr>
<td><a name="Date_Field_Symbol_Table"
href="#Date_Field_Symbol_Table">Date Field Symbol Table</a></td>
<td><a href="tr35-dates.html#Date_Field_Symbol_Table">Date
Field Symbol Table</a></td>
</tr>
<tr>
<td><a name="Localized_Pattern_Characters"
href="#Localized_Pattern_Characters">F.1 Localized Pattern
Characters (deprecated)</a></td>
<td>8.1 <a href="tr35-dates.html#Localized_Pattern_Characters">Localized
Pattern Characters (deprecated)</a></td>
</tr>
<tr>
<td><a name="Time_Zone_Fallback" href="#Time_Zone_Fallback">Appendix
J: Time Zone Display Names</a></td>
<td>7 <a href="tr35-dates.html#Using_Time_Zone_Names">Using
Time Zone Names</a></td>
</tr>
<tr>
<td><a name="fallbackFormat" href="#fallbackFormat"><b>fallbackFormat</b>:</a></td>
<td><a href="tr35-dates.html#fallbackFormat"><b>fallbackFormat</b>:</a></td>
</tr>
<tr>
<td>O.4 Parsing Dates and Times</td>
<td>9 <a href="tr35-dates.html#Parsing_Dates_Times">Parsing
Dates and Times</a></td>
</tr>
</table>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_5_Links" name="Part_5_Links">Part 5 Links</a>: <a
href="tr35-collation.html">Collation</a> (sorting, searching,
grouping)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td>5.14 <a name="Collation_Elements"
href="#Collation_Elements">Collation Elements</a></td>
<td>3 <a href="tr35-collation.html#Collation_Tailorings">Collation
Tailorings</a></td>
</tr>
<tr>
<td>5.14.1 <a name="Collation_Version"
href="#Collation_Version">Version</a></td>
<td>3.1 <a href="tr35-collation.html#Collation_Version">Version</a></td>
</tr>
<tr>
<td>5.14.2 <a name="Collation_Element"
href="#Collation_Element">Collation Element</a></td>
<td>3.2 <a href="tr35-collation.html#Collation_Element">Collation
Element</a></td>
</tr>
<tr>
<td>5.14.3 <a name="Setting_Options" href="#Setting_Options">Setting
Options</a></td>
<td>3.3 <a href="tr35-collation.html#Setting_Options">Setting
Options</a></td>
</tr>
<tr>
<td>Table <a name="Collation_Settings"
href="#Collation_Settings">Collation Settings</a></td>
<td>Table <a href="tr35-collation.html#Collation_Settings">Collation
Settings</a></td>
</tr>
<tr>
<td>5.14.4 <a name="Rules" href="#Rules">Collation Rule
Syntax</a></td>
<td>3.4 <a href="tr35-collation.html#Rules">Collation Rule
Syntax</a></td>
</tr>
<tr>
<td>5.14.5 <a name="Orderings" href="#Orderings">Orderings</a></td>
<td>3.5 <a href="tr35-collation.html#Orderings">Orderings</a></td>
</tr>
<tr>
<td>5.14.6 <a name="Contractions" href="#Contractions">Contractions</a></td>
<td>3.6 <a href="tr35-collation.html#Contractions">Contractions</a></td>
</tr>
<tr>
<td>5.14.7 <a name="Expansions" href="#Expansions">Expansions</a></td>
<td>3.7 <a href="tr35-collation.html#Expansions">Expansions</a></td>
</tr>
<tr>
<td>5.14.8 <a name="Context_Before" href="#Context_Before">Context
Before</a></td>
<td>3.8 <a href="tr35-collation.html#Context_Before">Context
Before</a></td>
</tr>
<tr>
<td>5.14.9 <a name="Placing_Characters_Before_Others"
href="#Placing_Characters_Before_Others">Placing Characters
Before Others</a></td>
<td>3.9 <a
href="tr35-collation.html#Placing_Characters_Before_Others">Placing
Characters Before Others</a></td>
</tr>
<tr>
<td>5.14.10 <a name="Logical_Reset_Positions"
href="#Logical_Reset_Positions">Logical Reset Positions</a></td>
<td>3.10 <a href="tr35-collation.html#Logical_Reset_Positions">Logical
Reset Positions</a></td>
</tr>
<tr>
<td>5.14.11 <a name="Special_Purpose_Commands"
href="#Special_Purpose_Commands">Special-Purpose Commands</a></td>
<td>3.11 <a href="tr35-collation.html#Special_Purpose_Commands">Special-Purpose
Commands</a></td>
</tr>
<tr>
<td>5.14.12 <a name="Script_Reordering"
href="#Script_Reordering">Collation Reordering</a></td>
<td>3.12 <a href="tr35-collation.html#Script_Reordering">Collation
Reordering</a></td>
</tr>
<tr>
<td>5.14.13 <a name="Case_Parameters" href="#Case_Parameters">Case
Parameters</a></td>
<td>3.13 <a href="tr35-collation.html#Case_Parameters">Case
Parameters</a></td>
</tr>
<tr>
<td>Definition: <a name="UncasedExceptions"
href="#UncasedExceptions">UncasedExceptions</a></td>
<td>removed: see 3.13 <a
href="tr35-collation.html#Case_Parameters">Case Parameters</a></td>
</tr>
<tr>
<td>Definition: <a name="LowerExceptions"
href="#LowerExceptions">LowerExceptions</a></td>
<td>removed: see 3.13 <a
href="tr35-collation.html#Case_Parameters">Case Parameters</a></td>
</tr>
<tr>
<td>Definition: <a name="UpperExceptions"
href="#UpperExceptions">UpperExceptions</a></td>
<td>removed: see 3.13 <a
href="tr35-collation.html#Case_Parameters">Case Parameters</a></td>
</tr>
<tr>
<td>5.14.14 <a name="Visibility" href="#Visibility">Visibility</a></td>
<td>3.14 <a href="tr35-collation.html#Visibility">Visibility</a></td>
</tr>
</table>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_6_Links" name="Part_6_Links">Part 6 Links</a>: <a
href="tr35-info.html">Supplemental</a> (supplemental data)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td>C <a name="Supplemental_Data" href="#Supplemental_Data">Supplemental
Data</a></td>
<td>Introduction <a href="tr35-info.html#Supplemental_Data">Supplemental
Data</a></td>
</tr>
<tr>
<td>C.2 <a name="Supplemental_Territory_Containment"
href="#Supplemental_Territory_Containment">Supplemental
Territory Containment</a></td>
<td>1.1 <a
href="tr35-info.html#Supplemental_Territory_Containment">Supplemental
Territory Containment</a></td>
</tr>
<tr>
<td>C.4 <a name="Supplemental_Territory_Information"
href="#Supplemental_Territory_Information">Supplemental
Territory Information</a></td>
<td>1.2 <a
href="tr35-info.html#Supplemental_Territory_Information">Supplemental
Territory Information</a></td>
</tr>
<tr>
<td>C.3 <a name="Supplemental_Language_Data"
href="#Supplemental_Language_Data">Supplemental Language Data</a></td>
<td>2 <a href="tr35-info.html#Supplemental_Language_Data">Supplemental
Language Data</a></td>
</tr>
<tr>
<td>C.9 <a name="Supplemental_Code_Mapping"
href="#Supplemental_Code_Mapping">Supplemental Code Mapping</a></td>
<td>4 <a href="tr35-info.html#Supplemental_Code_Mapping">Supplemental
Code Mapping</a></td>
</tr>
<tr>
<td>C.12 <a name="Telephone_Code_Data"
href="#Telephone_Code_Data">Telephone Code Data</a></td>
<td>5 <a href="tr35-info.html#Telephone_Code_Data">Telephone
Code Data</a></td>
</tr>
<tr>
<td>C.14 <a name="Postal_Code_Validation"
href="#Postal_Code_Validation">Postal Code Validation</a></td>
<td>6 <a href="tr35-info.html#Postal_Code_Validation">Postal
Code Validation</a></td>
</tr>
<tr>
<td>C.8 <a name="Supplemental_Character_Fallback_Data"
href="#Supplemental_Character_Fallback_Data">Supplemental
Character Fallback Data</a></td>
<td>7 <a
href="tr35-info.html#Supplemental_Character_Fallback_Data">Supplemental
Character Fallback Data</a></td>
</tr>
<tr>
<td>M <a name="Coverage_Levels" href="#Coverage_Levels">Coverage
Levels</a></td>
<td>8 <a href="tr35-info.html#Coverage_Levels">Coverage
Levels</a></td>
</tr>
<tr>
<td>5.20 <a name="Metadata_Elements"
href="tr35-info.html#Metadata_Elements">Metadata Elements</a></td>
<td>10 <a href="tr35-info.html#Metadata_Elements">Locale
Metadata Element</a></td>
</tr>
<tr>
<td>P <a name="Appendix_Supplemental_Metadata"
href="tr35-info.html#Appendix_Supplemental_Metadata">Supplemental
Metadata</a><br> P.1 <a name="Supplemental_Alias_Information"
href="tr35-info.html#Supplemental_Alias_Information">Supplemental
Alias Information</a><br> P.2 <a
name="Supplemental_Deprecated_Information"
href="tr35-info.html#Supplemental_Deprecated_Information">Supplemental
Deprecated Information</a><br> P.3 <a name="Default_Content"
href="tr35-info.html#Default_Content">Default Content</a>
</td>
<td>9 <a href="tr35-info.html#Appendix_Supplemental_Metadata">Supplemental
Metadata</a> <br> 9.1 <a
href="tr35-info.html#Supplemental_Alias_Information">Supplemental
Alias Information</a><br> 9.2 <a
href="tr35-info.html#Supplemental_Deprecated_Information">Supplemental
Deprecated Information</a><br> 9.3 <a
href="tr35-info.html#Default_Content">Default Content</a>
</td>
</tr>
</table>
<table cellspacing="0" cellpadding="2" border="1" width="100%">
<caption>
<a href="#Part_7_Links" name="Part_7_Links">Part 7 Links</a>: <a
href="tr35-keyboards.html">Keyboards</a> (keyboard mappings)
</caption>
<tr>
<th>Old section</th>
<th>Section in new part</th>
</tr>
<tr>
<td>S <a name="Keyboards" href="#Keyboards">Keyboards</a></td>
<td>1 <a href="tr35-keyboards.html#Keyboards">Keyboards</a></td>
</tr>
<tr>
<td>S <a name="Goals_and_Nongoals" href="#Goals_and_Nongoals">Goals
and Nongoals</a></td>
<td><a href="tr35-keyboards.html#Goals_and_Nongoals">Goals
and Nongoals</a></td>
</tr>
<tr>
<td>S <a name="File_and_Dir_Structure"
href="#File_and_Dir_Structure">File and Directory Structure</a></td>
<td><a href="tr35-keyboards.html#File_and_Dir_Structure">File
and Directory Structure</a></td>
</tr>
<tr>
<td>S <a name="Element_Heirarchy_Layout_File"
href="#Element_Heirarchy_Layout_File">Element Hierarchy -
Layout File</a></td>
<td><a href="tr35-keyboards.html#Element_Heirarchy_Layout_File">Element
Hierarchy - Layout File</a></td>
</tr>
<tr>
<td>S <a name="Element_Heirarchy_Platform_File"
href="#Element_Heirarchy_Platform_File">Element Hierarchy -
Platform File</a></td>
<td><a
href="tr35-keyboards.html#Element_Heirarchy_Platform_File">Element
Hierarchy - Platform File</a></td>
</tr>
<tr>
<td>S <a name="Invariants" href="#Invariants">Invariants</a></td>
<td><a href="tr35-keyboards.html#Invariants">Invariants</a></td>
</tr>
<tr>
<td>S <a name="Data_Sources" href="#Data_Sources">Data
Sources</a></td>
<td><a href="tr35-keyboards.html#Data_Sources">Data Sources</a></td>
</tr>
<tr>
<td>S <a name="Keyboard_IDs" href="#Keyboard_IDs">Keyboard
IDs</a></td>
<td><a href="tr35-keyboards.html#Keyboard_IDs">Keyboard IDs</a></td>
</tr>
<tr>
<td>S <a name="Platform_Behaviors_in_Edge_Cases"
href="#Platform_Behaviors_in_Edge_Cases">Platform Behaviors in
Edge Cases</a></td>
<td><a
href="tr35-keyboards.html#Platform_Behaviors_in_Edge_Cases">Platform
Behaviors in Edge Cases</a></td>
</tr>
<tr>
<td>S <a name="Element_Keyboard" href="#Element_Keyboard">Element:
keyboard</a></td>
<td><a href="tr35-keyboards.html#Element_Keyboard">Element:
keyboard</a></td>
</tr>
<tr>
<td>S <a name="Element_version" href="#Element_version">Element:
version</a></td>
<td><a href="tr35-keyboards.html#Element_version">Element:
version</a></td>
</tr>
<tr>
<td>S <a name="Element_generation" href="#Element_generation">Element:
generation</a></td>
<td><a href="tr35-keyboards.html#Element_generation">Element:
generation</a></td>
</tr>
<tr>
<td>S <a name="Element_names" href="#Element_names">Element:
names</a></td>
<td><a href="tr35-keyboards.html#Element_names">Element:
names</a></td>
</tr>
<tr>
<td>S <a name="Element_name" href="#Element_name">Element:
name</a></td>
<td><a href="tr35-keyboards.html#Element_name">Element:
name</a></td>
</tr>
<tr>
<td>S <a name="Element_settings" href="#Element_settings">Element:
settings</a></td>
<td><a href="tr35-keyboards.html#Element_settings">Element:
settings</a></td>
</tr>
<tr>
<td>S <a name="Element_keyMap" href="#Element_keyMap">Element:
keyMap</a></td>
<td><a href="tr35-keyboards.html#Element_keyMap">Element:
keyMap</a></td>
</tr>
<tr>
<td>S <a name="Element_map" href="#Element_map">Element:
map</a></td>
<td><a href="tr35-keyboards.html#Element_map">Element: map</a></td>
</tr>
<tr>
<td>S <a name="Element_transforms" href="#Element_transforms">Element:
transforms</a></td>
<td><a href="tr35-keyboards.html#Element_transforms">Element:
transforms</a></td>
</tr>
<tr>
<td>S <a name="Element_transform" href="#Element_transform">Element:
transform</a></td>
<td><a href="tr35-keyboards.html#Element_transform">Element:
transform</a></td>
</tr>
<tr>
<td>S <a name="Element_platform" href="#Element_platform">Element:
platform</a></td>
<td><a href="tr35-keyboards.html#Element_platform">Element:
platform</a></td>
</tr>
<tr>
<td>S <a name="Element_hardwareMap" href="#Element_hardwareMap">Element:
hardwareMap</a></td>
<td><a href="tr35-keyboards.html#Element_hardwareMap">Element:
hardwareMap</a></td>
</tr>
<tr>
<td>S <a name="Principles_for_Keyboard_Ids"
href="#Principles_for_Keyboard_Ids">Principles for Keyboard Ids</a></td>
<td><a href="tr35-keyboards.html#Principles_for_Keyboard_Ids">Principles
for Keyboard Ids</a></td>
</tr>
</table>
<hr>
<h2>
<a name="References" href="#References">References</a>
</h2>
<table cellpadding="4" cellspacing="0" class="noborder" border="0">
<tr>
<th class="noborder" width="148">Ancillary Information</th>
<td class="noborder" width="730"><i>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:<br> &nbsp;
</i></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Bugs" href="#Bugs">Bugs</a>]
</td>
<td class="noborder" width="730">CLDR Bug Reporting form<br>
<a href="http://cldr.unicode.org/index/bug-reports">
http://cldr.unicode.org/index/bug-reports</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Charts"
href="#Charts">Charts</a>]
</td>
<td class="noborder" width="730">The online code charts can be
found at <a href="http://unicode.org/charts/">http://unicode.org/charts/</a>
An index to character names with links to the corresponding chart
is found at <a href="http://unicode.org/charts/charindex.html">http://unicode.org/charts/charindex.html</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="DUCET" href="#DUCET">DUCET</a>]
</td>
<td class="noborder" width="730">The Default Unicode Collation
Element Table (DUCET)<br> For the base-level collation, of
which all the collation tables in this document are tailorings.<br>
<a
href="http://unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table">http://unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="FAQ" href="#FAQ">FAQ</a>]
</td>
<td class="noborder" valign="top" width="730">Unicode
Frequently Asked Questions<br> <a
href="http://unicode.org/faq/">http://unicode.org/faq/<br>
</a><i>For answers to common questions on technical issues.</i>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="FCD" href="#FCD">FCD</a>]
</td>
<td class="noborder" width="730">As defined in UTN #5 Canonical
Equivalences in Applications<br> <a
href="http://unicode.org/notes/tn5/">http://unicode.org/notes/tn5/</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Glossary"
href="#Glossary">Glossary</a>]
</td>
<td class="noborder" width="730">Unicode Glossary<a
href="http://unicode.org/glossary/"><br>
http://unicode.org/glossary/<br> </a><i>For explanations of
terminology used in this and other documents.</i></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="JavaChoice"
href="#JavaChoice">JavaChoice</a>]
</td>
<td class="noborder" width="730">Java ChoiceFormat<br> <a
href="http://docs.oracle.com/javase/7/docs/api/java/text/ChoiceFormat.html">
http://docs.oracle.com/javase/7/docs/api/java/text/ChoiceFormat.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Olson" href="#Olson">Olson</a>]
</td>
<td class="noborder" width="730">The <i>TZ</i>ID Database (aka
Olson timezone database)<br> Time zone and daylight savings
information.<br> <a href="http://www.iana.org/time-zones">http://www.iana.org/time-zones</a><br>
For archived data, see <br> <a
href="ftp://ftp.iana.org/tz/releases/">ftp://ftp.iana.org/tz/releases/</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Reports"
href="#Reports">Reports</a>]
</td>
<td class="noborder" width="730">Unicode Technical Reports<br>
<a href="http://unicode.org/reports/">http://unicode.org/reports/<br>
</a><i>For information on the status and development process for
technical reports, and for a list of technical reports.</i></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Unicode"
href="#Unicode">Unicode</a>]
</td>
<td class="noborder" width="730">The Unicode Consortium. <em>The
Unicode Standard, Version 7.0.0</em>,&nbsp;(Mountain View, CA: The
Unicode Consortium, 2014. ISBN 978-1-936213-09-2)<br> <a
href="http://www.unicode.org/versions/Unicode7.0.0/">
http://www.unicode.org/versions/Unicode7.0.0/</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Versions"
href="#Versions">Versions</a>]
</td>
<td class="noborder" width="730">Versions of the Unicode
Standard<br> <a href="http://www.unicode.org/versions/">
http://www.unicode.org/versions/</a><br> <i>For information
on version numbering, and citing and referencing the Unicode
Standard, the Unicode Character Database, and Unicode Technical
Reports.</i>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="XPath" href="#XPath">XPath</a>]
</td>
<td class="noborder" width="730"><a
href="http://www.w3.org/TR/xpath/"> http://www.w3.org/TR/xpath/</a></td>
</tr>
<tr>
<th class="noborder" width="148">Other Standards</th>
<td class="noborder" width="730"><i>Various standards
define codes that are used as keys or values in Locale Data Markup
Language. These include:</i></td>
</tr>
<tr>
<td class="noborder">[<a name="BCP47" href="#BCP47">BCP47</a>]
</td>
<td class="noborder"><a
href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">
http://www.rfc-editor.org/rfc/bcp/bcp47.txt</a>
<p>
The Registry<br> <a
href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>
</p></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO639"
href="#ISO639">ISO639</a>]
</td>
<td class="noborder" width="730">ISO Language Codes<br> <a
href="http://www.loc.gov/standards/iso639-2/">http://www.loc.gov/standards/iso639-2/</a><br>
Actual List<br> <a
href="http://www.loc.gov/standards/iso639-2/langcodes.html">http://www.loc.gov/standards/iso639-2/langcodes.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO1000"
href="#ISO1000">ISO1000</a>]
</td>
<td class="noborder" width="730">ISO 1000: SI units and
recommendations for the use of their multiples and of certain other
units, International Organization for Standardization, 1992.<br>
<a href="http://www.iso.org/iso/catalogue_detail?csnumber=5448">http://www.iso.org/iso/catalogue_detail?csnumber=5448</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO3166"
href="#ISO3166">ISO3166</a>]
</td>
<td class="noborder" width="730">ISO Region Codes<br> <a
href="http://www.iso.org/iso/country_codes">http://www.iso.org/iso/country_codes</a><br>
Actual List<br> <a
href="http://www.iso.org/iso/country_names_and_code_elements">http://www.iso.org/iso/country_names_and_code_elements</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO4217"
href="#ISO4217">ISO4217</a>]
</td>
<td class="noborder" width="730">ISO Currency Codes<br> <a
href="http://www.iso.org/iso/home/standards/currency_codes.htm">http://www.iso.org/iso/home/standards/currency_codes.htm</a>
<p>
<i>(Note that as of this point, there are significant problems
with this list. The supplemental data file contains the best
compendium of currency information available.)</i>
</p>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO8601"
href="#ISO8601">ISO8601</a>]
</td>
<td class="noborder" width="730">ISO Date and Time Format<br>
<a href="http://www.iso.org/iso/iso8601">http://www.iso.org/iso/iso8601</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ISO15924"
href="#ISO15924">ISO15924</a>]
</td>
<td class="noborder" width="730">ISO Script Codes<br> <a
href="http://www.unicode.org/iso15924/standard/index.html">http://www.unicode.org/iso15924/standard/index.html</a><br>
Actual List<br> <a
href="http://www.unicode.org/iso15924/codelists.html">http://www.unicode.org/iso15924/codelists.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="LOCODE"
href="#LOCODE">LOCODE</a>]
</td>
<td class="noborder" width="730">United Nations Code for Trade
and Transport Locations, commonly known as "UN/LOCODE"<br> <a
href="http://www.unece.org/cefact/locode/welcome.html">
http://www.unece.org/cefact/locode/welcome.html</a><br> Download
at: <a
href="http://www.unece.org/cefact/codesfortrade/codes_index.htm"> http://www.unece.org/cefact/codesfortrade/codes_index.htm</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="RFC6067"
href="#RFC6067">RFC6067</a>]
</td>
<td class="noborder" width="730">BCP 47 Extension U<br> <a
href="http://www.ietf.org/rfc/rfc6067.txt">http://www.ietf.org/rfc/rfc6067.txt</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="RFC6497"
href="#RFC6497">RFC6497</a>]
</td>
<td class="noborder" width="730">BCP 47 Extension T -
Transformed Content<br> <a
href="http://www.ietf.org/rfc/rfc6497.txt">http://www.ietf.org/rfc/rfc6497.txt</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="UNM49" href="#UNM49">UNM49</a>]
</td>
<td class="noborder" width="730">UN M.49: UN Statistics
Division
<p>
Country or area &amp; region codes<br> <a
href="http://unstats.un.org/unsd/methods/m49/m49.htm">http://unstats.un.org/unsd/methods/m49/m49.htm</a>
</p>
<p>
Composition of macro geographical (continental) regions,
geographical sub-regions, and selected economic and other
groupings<br> <a
href="http://unstats.un.org/unsd/methods/m49/m49regin.htm">http://unstats.un.org/unsd/methods/m49/m49regin.htm</a>
</p>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="XMLSchema"
href="#XMLSchema">XML Schema</a>]
</td>
<td class="noborder" width="730">W3C XML Schema<br> <a
href="http://www.w3.org/XML/Schema">http://www.w3.org/XML/Schema</a></td>
</tr>
<tr>
<th class="noborder" width="148">General</th>
<td class="noborder" width="730"><i>The following are
general references from the text:</i></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ByType"
href="#ByType">ByType</a>]
</td>
<td class="noborder" width="730">CLDR Comparison Charts<br>
<a href="http://www.unicode.org/cldr/comparison_charts.html">http://www.unicode.org/cldr/comparison_charts.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Calendars"
href="#Calendars">Calendars</a>]
</td>
<td class="noborder" width="730">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.</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="Comparisons"
href="#Comparisons">Comparisons</a>]
</td>
<td class="noborder" width="730">Comparisons between locale
data from different sources<br> <a
href="http://unicode.org/cldr/data/diff/">http://unicode.org/cldr/data/diff/</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="CurrencyInfo"
href="#CurrencyInfo">CurrencyInfo</a>]
</td>
<td class="noborder" width="730">UNECE Currency Data<br> <a
href="http://www.currency-iso.org/en/home/tables.html">http://www.currency-iso.org/en/home/tables.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="DataFormats"
href="#DataFormats">DataFormats</a>]
</td>
<td class="noborder" width="730">CLDR Translation Guidelines<br>
<a href="http://cldr.unicode.org/translation">http://cldr.unicode.org/translation</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="LDML" href="#LDML">Example</a>]
</td>
<td class="noborder" width="730">A sample in Locale Data Markup
Language<br> <a
href="http://unicode.org/cldr/dtd/1.1/ldml-example.xml">http://unicode.org/cldr/dtd/1.1/ldml-example.xml</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ICUCollation"
href="#ICUCollation">ICUCollation</a>]
</td>
<td class="noborder" width="730">ICU rule syntax<br> <a
href="http://www.icu-project.org/userguide/Collate_Customization.html">http://www.icu-project.org/userguide/Collate_Customization.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ICUTransforms"
href="#ICUTransforms">ICUTransforms</a>]
</td>
<td class="noborder" width="730">Transforms<br> <a
href="http://www.icu-project.org/userguide/Transformations.html">http://www.icu-project.org/userguide/Transformations.html</a><br>
Transforms Demo<br> <a
href="http://demo.icu-project.org/icu-bin/translit/">http://demo.icu-project.org/icu-bin/translit/</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ICUUnicodeSet"
href="#ICUUnicodeSet">ICUUnicodeSet</a>]
</td>
<td class="noborder" width="730">ICU UnicodeSet<br> <a
href="http://www.icu-project.org/userguide/unicodeSet.html">http://www.icu-project.org/userguide/unicodeSet.html<br>
</a>API<br> <a
href="http://www.icu-project.org/apiref/icu4j/com/ibm/icu/text/UnicodeSet.html">http://www.icu-project.org/apiref/icu4j/com/ibm/icu/text/UnicodeSet.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="ITUE164"
href="#ITUE164">ITUE164</a>]
</td>
<td class="noborder" width="730">International
Telecommunication Union: List Of ITU Recommendation E.164 Assigned
Country Codes<br> available at <a
href="http://www.itu.int/opb/publications.aspx?parent=T-SP&amp;view=T-SP2">http://www.itu.int/opb/publications.aspx?parent=T-SP&amp;view=T-SP2</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="LocaleExplorer"
href="#LocaleExplorer">LocaleExplorer</a>]
</td>
<td class="noborder" width="730">ICU Locale Explorer<br> <a
href="http://demo.icu-project.org/icu-bin/locexp">http://demo.icu-project.org/icu-bin/locexp</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="localeProject"
href="#localeProject">LocaleProject</a>]
</td>
<td class="noborder" width="730">Common Locale Data Repository
Project<br> <a href="http://unicode.org/cldr/">http://unicode.org/cldr/</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="NamingGuideline"
href="#NamingGuideline">NamingGuideline</a>]
</td>
<td class="noborder" width="730">OpenI18N Locale Naming
Guideline<br> formerly at
http://www.openi18n.org/docs/text/LocNameGuide-V10.txt
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="RBNF" href="#RBNF">RBNF</a>]
</td>
<td class="noborder" width="730">Rule-Based Number Format<br>
<a
href="http://www.icu-project.org/apiref/icu4c/classRuleBasedNumberFormat.html">http://www.icu-project.org/apiref/icu4c/classRuleBasedNumberFormat.html#_details</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="RBBI" href="#RBBI">RBBI</a>]
</td>
<td class="noborder" width="730">Rule-Based Break Iterator<br>
<a
href="http://www.icu-project.org/userguide/boundaryAnalysis.html">http://www.icu-project.org/userguide/boundaryAnalysis.html</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="RFC5234"
href="#RFC5234">RFC5234</a>]
</td>
<td class="noborder" width="730">RFC5234 Augmented BNF for
Syntax Specifications: ABNF<br> <a
href="http://www.ietf.org/rfc/rfc5234.txt">http://www.ietf.org/rfc/rfc5234.txt</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="UCAChart"
href="#UCAChart">UCAChart</a>]
</td>
<td class="noborder" width="730">Collation Chart<a
href="http://unicode.org/charts/collation/"><br>
http://unicode.org/charts/collation/</a></td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="UTCInfo"
href="#UTCInfo">UTCInfo</a>]
</td>
<td class="noborder" width="730">NIST Time and Frequency
Division Home Page<br> <a href="http://tf.nist.gov/">http://tf.nist.gov/<br>
</a>U.S. Naval Observatory: What is Universal Time?<br> <a
href="http://aa.usno.navy.mil/faq/docs/UT.php">http://aa.usno.navy.mil/faq/docs/UT.php</a>
</td>
</tr>
<tr>
<td class="noborder" width="148">[<a name="WindowsCulture"
href="#WindowsCulture">WindowsCulture</a>]
</td>
<td class="noborder" width="730">Windows Culture Info
(with&nbsp; mappings from [<a href="#BCP47">BCP47</a>]-style codes
to LCIDs)<br> <a
href="http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspx">http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspx</a>
</td>
</tr>
</table>
<h2>
<a name="Acknowledgments" href="#Acknowledgments">Acknowledgments</a>
</h2>
<p>Special thanks to the following people for their continuing
overall contributions to the CLDR project, and for their specific
contributions in the following areas. These descriptions only touch
on the many contributions that they have made.</p>
<ul>
<li><a
href="https://plus.google.com/114199149796022210033?rel=author">Mark
Davis</a> for creating the initial version of LDML, and adding to and
maintaining this specification, and for his work on the LDML code
and tests, much of the supplemental data and overall structure, and
transforms and keyboards.</li>
<li>John Emmons for the POSIX conversion tool and metazones.</li>
<li>Deborah Goldsmith for her contributions to LDML architecture
and this specification.</li>
<li>Chris Hansten for coordinating and managing data submissions
and vetting.</li>
<li>Erkki Kolehmainen and his team for their work on Finnish.</li>
<li>Steven R. Loomis for development of the survey tool and
database management.</li>
<li>Peter Nugent for his contributions to the POSIX tool and
from Open Office, and for coordinating and managing data submissions
and vetting.</li>
<li>George Rhoten for his work on currencies.</li>
<li>Roozbeh Pournader (روزبه پورنادر) for his work on South
Asian countries.</li>
<li>Ram Viswanadha (రఘురామ్ విశ్వనాధ) for all of his work on
LDML code and data integration, and for coordinating and managing
data submissions and vetting.</li>
<li>Vladimir Weinstein (Владимир Вајнштајн) for his work on
collation.</li>
<li>Yoshito Umaoka (馬岡 由人) for his work on the timezone
architecture.</li>
<li>Rick McGowan for his work gathering language, script and
region data.</li>
<li>Xiaomei Ji (吉晓梅) for her work on time intervals and plural
formatting.</li>
<li>David Bertoni for his contributions to the conversion tools.</li>
<li>Mike Tardif for reviewing this specification and for
coordinating and vetting data submissions.</li>
<li>Peter Edberg for work on this specification, telephone code
data, monthPatterns, cyclicNameSets and contextTransforms.</li>
<li>Raymond Wainman and Cibu Johny for their work on keyboards.</li>
<li>Jennifer Chye for her contributions to the conversion tools.</li>
<li><a
href="https://plus.google.com/117587389715494866571?rel=author">Markus
Scherer</a> for a major rewrite of Part 5, Collation.</li>
</ul>
<p>
Other contributors to CLDR are listed on the <a
href="http://www.unicode.org/cldr/">CLDR Project Page</a>.
</p>
<h2>
<a name="Modifications" href="#Modifications">Modifications</a>
</h2>
<p><b>Revision 53</b></p>
<p><strong>Part 1: <a href="tr35.html#Contents">Core</a> (languages,
locales, basic structure)
</strong></p>
<ul>
<li><strong>Section 3.2 <a
href="#Unicode_locale_identifier">Unicode Locale Identifier</a></strong>
[<a href="http://unicode.org/cldr/trac/ticket/11435">#11435</a>]
[<a href="http://unicode.org/cldr/trac/ticket/11434">#11434</a>]
<ul>
<li>Fixed cases of "-" in the syntax that should have been <em>sep</em>, and note that &quot;-&quot; is the canonical (preferred) form.</li>
<li>Fixed &quot;u&quot; and &quot;t&quot; in the syntax to [uU] and [tT], resp., to reflect that case is ignored when parsing.</li>
<li>Included specific syntax rather than just noting &quot;Although not shown in the syntax above, Unicode locale identifiers may also have [BCP47] extensions (other than &quot;u&quot; and &quot;t&quot;) and private use subtags.&quot;</li>
<li>Reformated and fleshed out the canonical form description; listed where CLDR uses non-canonical forms.</li>
<li>Added missing details about how Unicode Locale Identifiers differ from BCP 47, and how to convert between them.</li>
</ul>
</li>
<li><strong>Section 3.3 <a href="#BCP_47_Conformance">BCP
47 Conformance</a> </strong>
<ul>
<li>Reorganized for clarity, introduced new terms <em>Unicode BCP 47 locale identifier</em> and <em>Unicode CLDR locale identifier</em>. [<a href="http://unicode.org/cldr/trac/ticket/11451">#11451</a>]</li>
</ul>
</li>
<li><strong>Section 3.3.1 <a href="http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#BCP_47_Language_Tag_Conversion">BCP 47 Language Tag Conversion</a>
[<a href="http://unicode.org/cldr/trac/ticket/11451">#11451</a>]</strong>
<ul>
<li>Now handles private-use extensions and grandfathered tags.</li>
<li>Added more examples.</li>
<li>Separated into three conversions.
<ul>
<li> <a href="http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Language_Tag_to_Locale_Identifier">BCP 47 Language Tag to Unicode BCP 47 Locale Identifier</a> </li>
<li> <a href="http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Unicode_Locale_Identifier_CLDR_to_BCP_47">Unicode Locale Identifier: CLDR to BCP 47</a> </li>
<li> <a href="http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Unicode_Locale_Identifier_BCP_47_to_CLDR">Unicode Locale Identifier: BCP 47 to CLDR</a> </li>
</ul>
</li>
</ul>
</li>
<li><strong>Section 3.4
<a href="#Field_Definitions">Language Identifier Field Definitions </a>
</strong>
<ul>
<li>Added another macrolanguage example ku (used for kmr), and link to Aliases chart
[<a href="http://unicode.org/cldr/trac/ticket/11470">#11470</a>]</li>
<li>Documented special language subtags mis, mul, zxx [<a href="http://unicode.org/cldr/trac/ticket/11451">#11451</a>]</li>
<li>Added special script code Qaag [<a href="http://unicode.org/cldr/trac/ticket/11408">#11408</a>]</li>
<li>Documented special region subtags XA and XB [<a href="http://unicode.org/cldr/trac/ticket/11451">#11451</a>]</li>
</ul>
</li>
<li><strong>Section 3.5.3 <a href="#Private_Use">Private Use Codes</a></strong>
<ul>
<li>Adjusted table to move Qaag, XA, and XB into <em>defined</em>. The XA and XB were correct in the identity file (a change in a previous release), but had not been added to that table. [<a href="http://unicode.org/cldr/trac/ticket/11408">#11408</a>]</li>
</ul>
</li>
<li><strong>Section 3.6.4 <a href="#Unicode_Locale_Extension_Data_Files" >U Extension Data Files</a>
</strong>
<ul>
<li>Qualified valueType, since a key's value may be empty (if &quot;true&quot;). [<a href="http://unicode.org/cldr/trac/ticket/11408">#11408</a>]</li>
</ul>
</li>
<li><strong>Section 3.6.5.1 <a href="#Validity">Validity</a></strong>
<ul>
<li>Softened the requirement that there be region code matching the first 2 letters of the subdivision code. ​That was needlessly strict, and introduces a dependency on <em>likely subtags</em> that should not be there. [<a href="http://unicode.org/cldr/trac/ticket/11397">#11397</a>]</li>
</ul>
</li>
<li><strong>Section 4.2.6 <a
href="#Inheritance_vs_Related">Inheritance vs Related Information</a>
</strong>
<ul>
<li>Added table to explain the relationship between Inheritance, DefaultContent, LikelySubtags, and LocaleMatching.</li>
</ul>
</li>
<li><strong>Section 5.3.3
<a href="#Unicode_Sets">Unicode Sets</a>
</strong>
<ul>
<li>Clarified the relation between UnicodeSet and <a
href="http://www.unicode.org/reports/tr41/#UTS18">UTS #18</a> [<a href="http://unicode.org/cldr/trac/ticket/11232">#11232</a>]</li>
</ul>
</li>
</ul>
<p><strong>Part 2: <a href="tr35-general.html#Contents">General</a>
(display names &amp; transforms, etc.)
</strong></p>
<ul>
<li><strong>Section 6 <a href="tr35-general.html#Unit_Elements">Unit Elements</a> </strong>
<ul>
<li>Added &lt;displayName&gt; element for &lt;coordinateUnit&gt;.
[<a href="http://unicode.org/cldr/trac/ticket/9986">#9986</a>]</li>
<li>Noted that unitPatterns can use explicit count values “0” and “1”.
[<a href="http://unicode.org/cldr/trac/ticket/10922">#10922</a>]</li>
<li>Defined the syntax of unit identifiers [<a href="http://unicode.org/cldr/trac/ticket/11271">#11271</a>]</li>
<li>Added several new units: percent and permille, petabyte, and atmosphere.
[<a href="http://unicode.org/cldr/trac/ticket/10632">#10632</a>]
[<a href="http://unicode.org/cldr/trac/ticket/10410">#10410</a>]
[<a href="http://unicode.org/cldr/trac/ticket/10600">#10600</a>]</li>
</ul>
</li>
<li><strong>Section 10.1.1 <a href="tr35-general.html#Pivots">Pivots</a></strong>
<ul>
<li>Described the use of private use characters in Interindic. [<a href="http://unicode.org/cldr/trac/ticket/10962">#10962</a>]</li>
</ul>
</li>
</ul>
<p><strong>Part 3: <a href="tr35-numbers.html#Contents">Numbers</a>
(number &amp; currency formatting)
</strong></p>
<ul>
<li><strong>Section 2.5 <a href="tr35-numbers.html#Miscellaneous_Patterns">Miscellaneous Patterns</a></strong>
<ul>
<li>Documented <strong>approximately</strong> and <strong>atMost</strong>. [<a href="http://unicode.org/cldr/trac/ticket/11354">#11354</a>]</li>
</ul>
</li>
<li><strong>Section 3.2 <a
href="tr35-numbers.html##Special_Pattern_Characters">Special Pattern Characters</a></strong><a
href="tr35-numbers.html##Special_Pattern_Characters"></a>
<ul>
<li>Documented edge cases for negative subpatterns (and whitespace) [<a href="http://unicode.org/cldr/trac/ticket/10703">#10703</a>]</li>
</ul>
</li>
<li><strong>Section 3.4 <a href="tr35-numbers.html#sci">Scientific Notation</a> </strong>
<ul>
<li>Specify the special formats used for the integer parts. [<a href="http://unicode.org/cldr/trac/ticket/10103">#10103</a>]</li>
</ul>
</li>
<li><strong>Section 5 <a href="tr35-numbers.html#Language_Plural_Rules">Language Plural Rules</a></strong>
<ul>
<li>Added a new section <a href="tr35-numbers.html#Explicit_0_1_rules">Explicit 0 and
1 rules</a> covering the language-independent explicit plural cases “0” and “1”.
[<a href="http://unicode.org/cldr/trac/ticket/10922">#10922</a>]</li>
</ul>
</li>
</ul>
<p><strong>Part 4: <a href="tr35-dates.html#Contents">Dates</a> (date,
time, time zone formatting)
</strong></p>
<ul>
<li><strong>Section 2.6.3 <a href="tr35-dates.html#intervalFormats">Element intervalFormats</a></strong>
<ul>
<li>Described how to synthesize intervalFormatItems for skeletons that combine date and time fields.
[<a href="http://unicode.org/cldr/trac/ticket/10133">#10133</a>] </li>
</ul>
</li>
<li><strong>Section 4.4 <a href="tr35-dates.html#Time_Data">Time Data</a></strong>
<ul>
<li>Documented the relation between @allowed and @preferred. [<a href="http://unicode.org/cldr/trac/ticket/9930">#9930</a>]</li>
</ul>
</li>
</ul>
<p><strong>Part 5: <a href="tr35-collation.html#Contents">Collation</a>
(sorting, searching, grouping)
</strong></p>
<ul>
<li><em>no changes</em></li>
</ul>
<p><strong>Part 6: <a href="tr35-info.html#Contents">Supplemental</a>
(supplemental data)
</strong></p>
<ul>
<li> <strong>Section 4 <a href="tr35-info.html#Supplemental_Code_Mapping">Supplemental
Code Mapping</a></strong>
<ul>
<li>For the element &lt;territoryCodes&gt;, deprecated the internet attribute.
[<a href="http://unicode.org/cldr/trac/ticket/11072">#11072</a>]</li>
</ul>
</li>
<li> <strong>Section 5 <a href="tr35-info.html#Telephone_Code_Data">Telephone
Code Data</a></strong>
<ul>
<li>Now deprecated, and data removed. [<a href="http://unicode.org/cldr/trac/ticket/10383">#10383</a>]</li>
</ul>
</li>
<li> <strong>Section 9.3 <a href="tr35-info.html#Default_Content">Default
Content</a></strong>
<ul>
<li>Added pointer to <strong>Section 4.2.6 <a
href="#Inheritance_vs_Related">Inheritance vs Related Information</a> </strong></li>
</ul>
</li>
</ul>
<p><strong>Part 7: <a href="tr35-keyboards.html#Contents">Keyboards</a>
(keyboard mappings)
</strong> </p>
<ul>
<li><em>no changes</em></li>
</ul>
<p>&nbsp;</p>
<p>Modifications in previous versions are listed in those respective versions. Click on <strong>Previous Version</strong> in the header until you get to the desired version.</p>
<hr>
<p class="copyright">
Copyright © 2001–2018 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 <a href="http://unicode.org/copyright.html">Terms
of Use</a> apply.
</p>
<p class="copyright">Unicode and the Unicode logo are trademarks
of Unicode, Inc., and are registered in some jurisdictions.</p>
</div>
</body>
</html>