Return to
tr35.html
CVS log
Up to [Development] / draft / reports / tr35
|
Return to
tr35.html
CVS log
|
Up to [Development] / draft / reports / tr35
|
|
File: [Development] / draft / reports / tr35 / tr35.html
(download)
/
(as text)
Revision: 1.357, Mon Oct 5 05:40:49 2009 UTC (6 weeks, 6 days ago) by pedberg Branch: MAIN Changes since 1.356: +12 -5 lines cldrbug 2317: Update group description in G.8 to match G.2 |
<!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">
<!--
span.dtd { font-family: monospace; font-size:90%; background-color:#CCCCFF; border-style: dotted; border-width: 1px;}
.xmlExample { font-family: monospace; font-size: 80% }
span.blockedInherited { font-style: italic; font-weight: bold; border-style: dashed; border-width: 1px;
background-color: #FF0000 }
span.inherited { font-weight: bold; border-style: dashed; border-width: 1px; background-color:
#00FF00 }
span.element { font-weight: bold; color: red; }
span.attribute { font-weight: bold; color: maroon; }
span.attributeValue { font-weight: bold; color: blue; }
li, p { margin-top: 0.5em; margin-bottom: 0.5em }
h2, h3, h4, table { margin-top: 1.5em; margin-bottom: 0.5em; }
-->
</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>
<a class="bar" href="http://www.unicode.org/reports/">Technical Reports</a></td>
</tr>
<tr>
<td class="gray"> </td>
</tr>
</table>
<div class="body">
<h2 style="text-align: center">Unicode Technical Standard #35</h2>
<h1 style="text-align: center"><span class="changed">PROPOSED UPDATE </span>Unicode Locale Data Markup Language (LDML)</h1>
<table border="1" cellpadding="2" cellspacing="0" width="90%">
<tr>
<td>Version</td>
<td><span class="changed">1.8</span></td>
</tr>
<tr>
<td>Authors</td>
<td>Mark Davis (<a href="mailto:markdavis@google.com">markdavis@google.com</a>)
and other CLDR committee members</td>
</tr>
<tr>
<td>Date</td>
<td>2009-<span class="changed">10-04</span></td>
</tr>
<tr>
<td>This Version</td>
<td>
<a href="http://unicode.org/reports/tr35/tr35-13.html" class="changed">http://unicode.org/reports/tr35/tr35-13.html</a></td>
</tr>
<tr>
<td>Previous Version</td>
<td>
<a href="http://unicode.org/reports/tr35/tr35-12.html" class="changed">http://unicode.org/reports/tr35/tr35-12.html</a></td>
</tr>
<tr>
<td>Latest Version</td>
<td><a href="http://unicode.org/reports/tr35/">http://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 Working Draft</td>
<td><a href="http://unicode.org/draft/reports/tr35/tr35.html">http://unicode.org/draft/reports/tr35/tr35.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>
<span class="changed">
<a href="http://unicode.org/cldr/dtd/1.8/ldml.dtd">http://unicode.org/cldr/dtd/1.8/ldml.dtd</a><br>
<a href="http://unicode.org/cldr/dtd/1.8/ldmlSupplemental.dtd">http://unicode.org/cldr/dtd/1.8/ldmlSupplemental.dtd</a></span></td>
</tr>
<tr>
<td>Revision</td>
<td><a href="#Modifications" class="changed">13</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://unicode.org/cldr/">Unicode Common Locale Data Repository</a>.</p>
<h3><i>Status</i></h3>
<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>
<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="#Bugs">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="#Unicode">Unicode</a>]. For
a list of current Unicode Technical Reports see [<a href="#Reports">Reports</a>]. For more information about versions of the Unicode Standard, see [<a href="#Versions">Versions</a>].
</i></p>
<h2><a name="Contents">Contents</a></h2>
<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="#Unicode_Language_and_Locale_Identifiers">Unicode Language and Locale Identifiers</a>
<ul class="toc">
<li>3.1 <a href="#Unknown_or_Invalid_Identifiers">Unknown or Invalid Identifiers</a></li>
<li>3.2 <a href="#BCP_47_Tag_Conversion">
BCP 47 Tag Conversion</a></li>
<li>3.3
<a href="#Relation_to_OpenI18n">Relation to OpenI18n</a></li>
</ul>
</li>
<li>4 <a href="#Locale_Inheritance">Locale Inheritance</a><ul class="toc">
<li>4.1 <a href="#Multiple_Inheritance">Multiple Inheritance</a></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="#Escaping_Characters">Escaping Characters</a></li>
<li>5.1.2 <a href="#Text_Directionality">Text Directionality</a></li>
</ul>
</li>
<li>5.2 <a href="#Common_Attributes">Common Attributes</a><ul class="toc">
<li>5.2.1 <a href="#Date_Ranges">Dates and Date Ranges</a></li>
</ul>
</li>
<li>5.3 <a href="#Identity_Elements">Identity Elements</a><ul class="toc">
<li>5.3.1 <a href="#Fallback_Elements">Fallback Elements</a></li>
</ul>
</li>
<li>5.4 <a href="#Display_Name_Elements">Display Name Elements</a></li>
<li>5.5 <a href="#Layout_Elements">Layout Elements</a></li>
<li>5.6 <a href="#Character_Elements">Character Elements</a></li>
<li>5.7 <a href="#Delimiter_Elements">Delimiter Elements</a></li>
<li>5.8 <a href="#Measurement_Elements">Measurement Elements</a></li>
<li>5.9 <a href="#Date_Elements">Date Elements</a>
<ul class="toc">
<li>5.9.1 <a href="#Calendar_Elements">Calendar Elements</a></li>
<li>5.9.2 <a href="#Timezone_Names">Time Zone Names</a></li>
</ul>
</li>
<li>5.10 <a href="#Number_Elements">Number Elements</a><ul class="toc">
<li>5.10.1 <a href="#Number_Symbols">Number Symbols</a></li>
<li>5.10.2 <a href="#Currencies">Currencies</a></li>
</ul>
</li>
<li>5.11 <a href="#Unit_Elements">Unit Elements</a></li>
<li>5.12 <a href="#POSIX_Elements">POSIX Elements</a></li>
<li>5.13 <a href="#Reference_Elements">Reference Elements</a></li>
<li>5.14 <a href="#Collation_Elements">Collation Elements</a> </li>
<li>5.15 <a href="#Segmentations">Segmentations</a></li>
<li>5.16 <a href="#Transforms">Transforms</a></li>
<li>5.17
<a href="#Rule-Based_Number_Formatting">Rule-Based Number Formatting</a></li>
</ul>
<p>Appendix A: <a href="#Sample_Special_Elements">Sample Special Elements</a> </p>
<ul class="toc">
<li>A.1 <a href="#OpenOffice">openoffice.org</a></li>
</ul>
</li>
<li>Appendix B: <a href="#Transmitting_Locale_Information">Transmitting Locale Information</a>
<ul class="toc">
<li>B.1 <a href="#Message_Formatting_and_Exceptions">Message Formatting and Exceptions</a></li>
</ul>
</li>
<li>Appendix C: <a href="#Supplemental_Data">Supplemental Data</a>
<ul class="toc">
<li>C.1 <a href="#Supplemental_Currency_Data">Supplemental Currency Data</a></li>
<li>C.2 <a href="#Supplemental_Territory_Containment">Supplemental Territory Containment</a></li>
<li>C.3 <a href="#Supplemental_Language_Data">Supplemental Language Data</a></li>
<li>C.4 <a href="#Supplemental_Territory_Information">Supplemental Territory Information</a></li>
<li>C.5 <a href="#Supplemental_Calendar_Data">Supplemental Calendar Data</a></li>
<li>C.6 <a href="#Measurement_System_Data">Measurement System Data</a></li>
<li>C.7 <a href="#Supplemental_Timezone_Data">Supplemental Time Zone Data</a></li>
<li>C.8 <a href="#Supplemental_Character_Fallback_Data">Supplemental Character Fallback Data</a></li>
<li>C.9 <a href="#Supplemental_Code_Mapping">Supplemental Code Mapping</a></li>
<li>C.10 <a href="#Likely_Subtags">Likely Subtags</a></li>
<li>C.11 <a href="#Language_Plural_Rules">Language Plural Rules</a></li>
<li>C.12 <a href="#Telephone_Code_Data">Telephone Code Data</a></li>
<li>C.13 <a href="#Numbering_Systems">Numbering Systems</a></li>
<li>C.14 <a href="#Postal_Code_Validation">Postal Code Validation</a></li>
<li>C.15 <a href="#Calendar_Preference_Data">Calendar Preference Data</a></li>
<li>C.16 <a href="#BCP47_Keyword_Mapping">BCP 47 Keyword Mapping</a></li>
</ul>
</li>
<li>Appendix D: <a href="#Language_and_Locale_IDs">Language and Locale IDs</a></li>
<li>Appendix E: <a href="#Unicode_Sets">Unicode Sets</a></li>
<li>Appendix F: <a href="#Date_Format_Patterns">Date Format Patterns</a></li>
<li>Appendix G: <a href="#Number_Format_Patterns">Number Format Patterns</a></li>
<li>Appendix H: <a href="#Choice_Patterns">Choice Patterns</a></li>
<li>Appendix I: <a href="#Inheritance_and_Validity">Inheritance and Validity</a></li>
<li>Appendix J: <a href="#Time_Zone_Fallback">Time Zone Display Names</a></li>
<li>Appendix K: <a href="#Valid_Attribute_Values">Valid Attribute Values</a></li>
<li>Appendix L: <a href="#Canonical_Form">Canonical Form</a></li>
<li>Appendix M: <a href="#Coverage_Levels">Coverage Levels</a></li>
<li>Appendix N: <a href="#Transform_Rules">Transform Rules</a></li>
<li>Appendix O: <a href="#Lenient_Parsing">Lenient Parsing</a></li>
<li>Appendix P: <a href="#Appendix_Supplemental_Metadata">
Supplemental Metadata</a></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><a href="#References">References</a></li>
<li><a href="#Acknowledgments">Acknowledgments</a></li>
<li><a href="#Modifications">Modifications</a></li>
</ul>
<h2>1. <a name="Introduction">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'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 "Abbot, Cosmo" and "Arnold, James", 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 "correct" 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
(see [<a href="#UCA">UCA</a>]). 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><span>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.</span></p>
<h3>1.1 <a name="Conformance">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> </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="#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>2. <a name="Locale">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'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'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">Appendix D: Language and Locale IDs</a></i>.</p>
<p>We will speak of data as being "in locale X". That does not imply that a locale <i>is</i> a collection of data; it is simply shorthand for "the set of data
associated with the locale id X". 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"></a>3.
<a name="Unicode_Language_and_Locale_Identifiers">
Unicode Language and Locale Identifiers</a></h2>
<p>Unicode LDML uses stable identifiers 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>A <i><a name="Unicode_language_identifier">Unicode language identifier</a></i> has the
following structure:</p>
<blockquote>
<table border="1" cellpadding="4" cellspacing="0" style="border-collapse: collapse" id="table26" class="noborder">
<tr>
<td class="noborder"><code>
unicode_language_id </code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>root<br>
|(unicode_language_subtag<br>
([-_] unicode_script_subtag)?<br>
([-_] unicode_region_subtag)?<br>
([-_] unicode_variant_subtag)*)</code></td>
</tr>
<tr>
<td class="noborder"><code>
unicode_language_subtag</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>
BCP47_language_subtag<br>
| ISO_639_3_code<br>
| ISO_639_5_code</code></td>
</tr>
<tr>
<td class="noborder"><code>
unicode_script_subtag</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>
BCP47_script_subtag</code></td>
</tr>
<tr>
<td class="noborder"><code>
unicode_region_subtag</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>
BCP47_region_subtag</code></td>
</tr>
<tr>
<td class="noborder"><code>
unicode_variant_subtag</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>
BCP47_variant_subtag<br>
| grandfathered_variant_subtags</code></td>
</tr>
</table>
<p>As usual, x? means that x is optional; x* means that x occurs zero or more times.</p>
</blockquote>
<p>For example, "en-US" (American English), "en_GB" (British English),
"es-419" (Latin American Spanish), and "uz-Cyrl" (Uzbek in Cyrillic) are all
Unicode language identifiers.</p>
<p>As for terminology, the term <i>code</i> may also be used instead of "subtag",
and "territory" instead of "region". The primary language subtag is also
called the <i>base language code</i>. For example, the base language code
for "en-US" (American English) is "en" (English).</p>
<p>A <i><a name="Unicode_locale_identifier">Unicode locale identifier</a></i> is composed of a Unicode language identifier plus
(optional) locale extensions. It has the following
structure:</p>
<blockquote>
<table border="1" cellpadding="4" cellspacing="0" style="border-collapse: collapse" id="table27" class="noborder">
<tr>
<td class="noborder"><code>unicode_locale_id
</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>
unicode_language_id<br>
(unicode_locale_extensions)?</code></td>
</tr>
<tr>
<td class="noborder"><code>
unicode_locale_extensions</code></td>
<td class="noborder"><code>:=</code></td>
<td class="noborder"><code>"@" key "=" type<br>
(";" key "=" type )*</code></td>
</tr>
</table>
</blockquote>
<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 "locale" data loosely to encompass
both types of data: for more information, see
<i><a href="#Language_and_Locale_IDs">Appendix D: Language and Locale IDs</a></i>.
Note that the <i>
type</i> may also be referred to as a <i>key-value</i></p>
<p>The Unicode language identifier is based on [<a href="#BCP47">BCP47</a>].
However, it differs in the following ways:</p>
<ul>
<li>It does not allow for the full syntax of [<a href="#BCP47">BCP47</a>]:<ul>
<li>No irregular or
BCP47 grandfathered tags are allowed</li>
<li>No extlang subtags are allowed</li>
</ul>
</li>
<li>It allows for
certain additions:<ul>
<li>Grandfathered variants that are not present in [<a href="#BCP47">BCP47</a>]</li>
<li>Certain ISO 639-3 and ISO 639-5 codes; these are expected to be
added to [<a href="#BCP47">BCP47</a>] in the future.</li>
<li>Defined semantics of certain private use codes, and some "macrolanguage"
codes.</li>
<li>For field separator
characters, the "_" character can be used as well as the "-" used in [<a href="#BCP47">BCP47</a>].</li>
</ul>
</li>
</ul>
<p>The identifiers can vary in case and in the
separator characters. The "-" and "_" separators are
treated as equivalent. All identifier field values are case-insensitive, except for the <i>type</i>, which is case-sensitive. However, customarily
the language subtag is in lower case, the territory and variant subtags are
in upper case, the script subtag is title case (that is, the first character
is upper case and other characters are lower case), and variants are upper
case. These conventions are used in the CLDR file names, which may be case-sensitive depending on the operating system. The normal form of a locale ID in the CLDR data uses "_".
Implementations can choose an alternate canonical form in terms of casing
and separator characters.</p>
<p>Customarily
the currency IDs are upper case and time zone IDs are title cased by field (as defined in the
time zone database); other key and type subtags are lower case.</p>
<p>The Unicode language and locale identifier field values are given in the
following table. Note that some private-use field values may be given
specific values.</p>
<table>
<caption><a name="Locale_Field_Definitions">Locale Field Definitions</a></caption>
<tr>
<th>Field</th>
<th>Allowable Characters</th>
<th>Allowable values</th>
</tr>
<tr>
<td>unicode_language_subtag<p>(also known as a <i>Unicode base
language code)</i></td>
<td>ASCII letters</td>
<td>[<a href="#BCP47">BCP47</a>] subtag values marked as <b>Type: language</b><p>
ISO 639-3 and ISO 639-5 codes are also allowed, where they do not
have ISO 639-1 equivalents. At publication time, these were slated
to be added to the next version of [<a href="#BCP47">BCP47</a>],
but it is unclear when that version will be approved.</p>
<p>ISO 639-3 introduces the notion of "macrolanguages", 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. That is, the following table
lists these cases:</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>zh</td>
<td>cmn</td>
</tr>
<tr>
<td>Standard Arabic</td>
<td>ar</td>
<td>arb</td>
</tr>
<tr>
<td>Standard Malay</td>
<td>ms</td>
<td>zsm</td>
</tr>
<tr>
<td>Standard Swahili</td>
<td>sw</td>
<td>swh</td>
</tr>
<tr>
<td>Standard Uzbek</td>
<td>uz</td>
<td>uzn</td>
</tr>
<tr>
<td>Standard Kokani</td>
<td>kok</td>
<td>knn</td>
</tr>
</table>
<p>Thus Unicode language identifiers use "ar-EG" for Standard Arabic
(Egypt), not "arb-EG"; they use "zh-TW" for Mandarin Chinese
(Taiwan), not "cmn-TW".</p>
<p>The private use codes from qfz..qtz will never be used by Unicode
identifiers, and are thus safe for use for other purposes by
applications.</p>
</td>
</tr>
<tr>
<td>unicode_script_subtag<p>(also known as a <i>Unicode
script code)</i></td>
<td>ASCII letters</td>
<td>[<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>az_Arab</td>
<td>Azerbaijani in Arabic script</td>
</tr>
<tr>
<td>az_Cyrl</td>
<td>Azerbaijani in Cyrillic script</td>
</tr>
<tr>
<td>az_Latn</td>
<td>Azerbaijani in Latin script</td>
</tr>
<tr>
<td>zh_Hans</td>
<td>Chinese, in simplified script</td>
</tr>
<tr>
<td>zh_Hant</td>
<td>Chinese, in traditional script</td>
</tr>
</table>
<p>Unicode allows for the use of the Unicode Script values [<a href="#UAX24">UAX24</a>]:</p>
<table cellspacing="0" cellpadding="2" border="1" style="margin: 0.5em">
<tr>
<td><code><i><b>Common</b></i></code></td>
<td><code><i>Zyyy</i></code></td>
</tr>
<tr>
<td><code><i><b>Inherited</b></i></code></td>
<td><code><i>Qaai</i></code></td>
</tr>
<tr>
<td><code><i>Unknown</i></code></td>
<td><code>Zzzz</code></td>
</tr>
</table>
<p>The private use subtags from Qaaq..Qabx will never be used by
Unicode identifiers, and are thus safe for use for other purposes by
applications.</p>
</td>
</tr>
<tr>
<td>unicode_region_subtag<p>(also known as a <i>Unicode region code,
</i>or<i> a Unicode territory code)</i></td>
<td>ASCII letters, numbers</td>
<td>[<a href="#BCP47">BCP47</a>] subtag values marked as <b>Type: region</b>, or any UN
M.49 [<a href="#UNM49">UNM49</a>] code that does not correspond to a [<a href="#BCP47">BCP47</a>]
region subtag.<p>There are two types of
region subtags:</p>
<ul>
<li><i>country or area</i> codes. These
are ISO 3166 codes, but in unusually cases may be UN
M.49 codes.</li>
<li><i>grouping codes</i>: These are UN
macro geographical (continental) regions, geographical
sub-regions, and selected economic and other groupings, and always
represented by UN M.49 codes.</li>
</ul>
<p>There are three private use subtags defined for Unicode
identifiers:</p>
<table border="1" cellspacing="0" cellpadding="2" style="margin: 0.5em">
<tr>
<td>QO</td>
<td>Outlying Oceania</td>
</tr>
<tr>
<td>QU</td>
<td>European Union</td>
</tr>
<tr>
<td>ZZ</td>
<td>Unknown or Invalid Territory</td>
</tr>
</table>
<p>The private use subtags from XA..XZ will never be used by Unicode
identifiers, and are thus safe for use for other purposes by
applications.</p>
</td>
</tr>
<tr>
<td>unicode_variant_subtag<p>(also known as a <i>Unicode language
variant code)</i></td>
<td>ASCII letters</td>
<td rowspan="3">Values used in Unicode are discussed below.<b> </b>For information on the process for adding new standard variants or element/type
pairs, see [<a href="#localeProject">LocaleProject</a>].</td>
</tr>
<tr>
<td><i>key</i></td>
<td>ASCII letters and digits</td>
</tr>
<tr>
<td><i>type</i></td>
<td>ASCII letters, <span class="removed">and </span>digits, <span class="removed">and </span>'-'<span class="changed">, and '/' in some cases</span></td>
</tr>
</table>
<p><i>Examples:</i></p>
<blockquote>
<pre>en
fr_BE
de_DE@collation=phonebook;currency=DDM</pre>
</blockquote>
<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>
<p>The variant codes specify particular variants of the locale, typically with special options. They cannot overlap with script or territory codes, so they
must have more than four letters. The currently defined variants include:</p>
<center>
<table style="border-collapse: collapse" cellpadding="0" cellspacing="0">
<caption><a name="Variant_Definitions">Variant Definitions</a></caption>
<tr>
<th>variant</th>
<th>Description</th>
</tr>
<tr>
<td><BCP47 variants></td>
<td>As defined in [<a href="#BCP47">BCP47</a>], plus:</td>
</tr>
<tr>
<td>BOKMAL</td>
<td>Bokmål, variant of "no" Norwegian (deprecated: use "nb" to indicate this</td>
</tr>
<tr>
<td>NYNORSK</td>
<td>Nynorsk, variant of "no" Norwegian (deprecated: use "nn" to indicate this)</td>
</tr>
<tr>
<td>AALAND</td>
<td>Åland, variant of "sv" Swedish used in Finland (deprecated: use "sv_AX" to indicate this) </td>
</tr>
<tr>
<td>POSIX</td>
<td>A POSIX-style invariant locale.</td>
</tr>
<tr>
<td>REVISED</td>
<td>For revised orthography</td>
</tr>
<tr>
<td>SAAHO</td>
<td>The Saaho variant of <b>Afar</b></td>
</tr>
</table>
</center>
<blockquote>
<p><b>Note: </b>BOKMAL, NYNORSK and AALAND are for backwards compatibility. Typically the entire contents of these are defined by an <alias> element
pointing at locale IDs nb (Norwegian Bokmål), nn (Norwegian Nynorsk), or sv_AX (Swedish for Åland Islands). See also <i><a href="#Valid_Attribute_Values">Appendix K: Valid Attribute
Values</a></i>.</p>
</blockquote>
<p>The currently defined optional key/type combinations include the following. Additional type values are defined in the detail sections of this document or
in <a href="#Valid_Attribute_Values">Appendix K: Valid Attribute Values</a>. The assignment of values needs to ensure that they are unique if truncated to
eight
letters and digits.</p>
<table>
<caption><a name="Key_Type_Definitions">Key/Type Definitions</a></caption>
<tr>
<th>key</th>
<th>type</th>
<th>Description</th>
</tr>
<tr>
<td rowspan="12">collation</td>
<td>standard</td>
<td>The default ordering for each
language. For root it is [<a href="#UCA">UCA</a>] order; for each
other locale it is the same as UCA ordering except for appropriate
modifications to certain characters for that language. The following
are additional choices for certain locales; <i>they only have effect
in certain locales.</i></td>
</tr>
<tr>
<td>phonebook</td>
<td>For a phonebook-style ordering (used in German).</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>traditional</td>
<td>For a traditional-style sort (as in Spanish)</td>
</tr>
<tr>
<td>stroke</td>
<td>Pinyin ordering for Latin, stroke order for CJK characters (used in Chinese)</td>
</tr>
<tr>
<td>direct</td>
<td>Hindi variant</td>
</tr>
<tr>
<td>posix</td>
<td>A "C"-based locale.
(no longer in CLDR data)</td>
</tr>
<tr>
<td>big5han</td>
<td>Pinyin ordering for Latin, big5 charset ordering for CJK characters. (used in Chinese)</td>
</tr>
<tr>
<td>gb2312han</td>
<td>Pinyin ordering for Latin, gb2312han charset ordering for CJK characters. (used in Chinese)</td>
</tr>
<tr>
<td>unihan</td>
<td>Pinyin ordering for Latin, Unihan radical-stroke ordering for CJK characters. (used in Chinese)</td>
</tr>
<tr>
<td>reformed</td>
<td>Reformed collation (such as in Swedish)</td>
</tr>
<tr>
<td>digits-after</td>
<td>Used for digits after letters (such as in Czech)</td>
</tr>
<tr>
<td rowspan="13">calendar<p><i>(For information on most of the calendar
algorithms associated with the data used with these, see [<a href="#Calendars">Calendars</a>].)</i></td>
<td>gregorian</td>
<td>(default)</td>
</tr>
<tr>
<td>islamic
<p><i>alias:</i> arabic</p>
</td>
<td>Astronomical Arabic</td>
</tr>
<tr>
<td>chinese</td>
<td>Traditional Chinese calendar</td>
</tr>
<tr>
<td>islamic-civil
<p><i>alias:</i> civil-arabic</p>
</td>
<td>Civil (algorithmic) Arabic calendar</td>
</tr>
<tr>
<td>hebrew</td>
<td>Traditional Hebrew Calendar</td>
</tr>
<tr>
<td>japanese</td>
<td>Imperial Calendar (same as Gregorian except for the year, with one era for each Emperor)</td>
</tr>
<tr>
<td>buddhist
<p><i>alias:</i> thai-buddhist</p>
</td>
<td>Thai Buddhist Calendar (same as Gregorian except for the year)</td>
</tr>
<tr>
<td>persian</td>
<td>Persian Calendar</td>
</tr>
<tr>
<td>coptic</td>
<td>Coptic Calendar</td>
</tr>
<tr>
<td>ethiopic</td>
<td>Ethiopic Calendar, Amete Mihret (epoch approx. 8 C.E.)</td>
</tr>
<tr>
<td>ethiopic-amete-alem</td>
<td>Ethiopic Calendar, Amete Alem (epoch approx. 5493 B.C.E.)</td>
</tr>
<tr>
<td>indian</td>
<td>Indian Calendar</td>
</tr>
<tr>
<td>roc</td>
<td>Republic of China Calendar</td>
</tr>
<tr>
<td>collation parameters defined as in <i>5.14.1 <a href="#Collation_Element"><collation></a>,</i>
plus "col" <blockquote>
<p>colStrength<br>
colAlternate<br>
colBackwards<br>
colNormalization<br>
colCaseLevel<br>
colCaseFirst,<br>
colHiraganaQuaternary<br>
colNumeric<br>
variableTop</p>
</blockquote>
</td>
<td><i>Associated types as defined as
values in: 5.14.1 <a href="#Collation_Element"><collation></a></i></td>
<td>Semantics as defined in: 5.14.1 <a href="#Collation_Element"><collation></a></td>
</tr>
<tr>
<td>currency<p> </td>
<td><i>ISO 4217 code,</i><p><i>plus others in common use</i></td>
<td>Currency value identified by ISO 4217 code, plus others in common use.
Also uses XXX as <i>Unknown or Invalid Currency</i>.
A <i>Unicode currency code</i> is defined
as this set of values.<p>For more
information, see C.1 <a href="#Supplemental_Currency_Data">Supplemental Currency Data</a>.</td>
</tr>
<tr>
<td>numbers</td>
<td>Unicode script subtag, plus extensions</td>
<td>Four-letter types indicate the decimal numbering
system using digits [:GeneralCategory=Nd:] for the script
represented in Unicode. Extension types have more than 4 letters,
and are defined below. Where the type is related to a script, the
first four letters are the script code.<table style="margin-top: 1.5em; margin-bottom: 0.5em">
<tr>
<td><b>type</b></td>
<td><b>Description</b></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>fullwide </td>
<td>Full Width Digits</td>
</tr>
<tr>
<td>greklow </td>
<td>Greek Lowercase Numerals</td>
</tr>
<tr>
<td>hansfin </td>
<td>Simplified Chinese Financial Numerals</td>
</tr>
<tr>
<td>hantfin </td>
<td>Traditional Chinese Financial Numerals</td>
</tr>
<tr>
<td>jpanfin </td>
<td>Japanese Financial Numerals</td>
</tr>
<tr>
<td>roman </td>
<td>Roman Numerals</td>
</tr>
<tr>
<td>romanlow </td>
<td>Roman Lowercase Numerals</td>
</tr>
</table>
<p class="note">For more information, see
Section C.13 <a href="#Numbering_Systems">Numbering Systems</a>.</p>
</td>
</tr>
<tr>
<td>timezone</td>
<td><i>TZID, plus the value:</i><p><i>Etc/Unknown</i></td>
<td>Identification for time zone according to the <i>TZ </i>Database,
plus the value <i>Etc/Unknown</i>. A <i>Unicode time zone code</i>
is defined to be this set.<p>Unicode LDML supports all of the time zone IDs by mapping all equivalent
time zone IDs to a canonical ID for translation. This canonical
time zone ID is <i>not</i> the same as the zone.tab time zone ID found in [<a href="#Olson">Olson</a>].</p>
<p>For more information, see <a href="#Timezone_Names"><i>Section </i>
</a><i><a href="#Timezone_Names">5.9.2 Time Zone Names</a>,
<a href="#Date_Format_Patterns">Appendix F: Date Format Patterns</a></i>,
and <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
</table>
<p class="note">For more information on the allowed attribute values, see the specific elements below, and <a href="#Valid_Attribute_Values">Appendix K: Valid
Attribute Values</a>.</p>
<h3>3.1 <a name="Unknown_or_Invalid_Identifiers">Unknown or Invalid Identifiers</a></h3>
<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</td>
</tr>
<tr>
<td>Script</td>
<td><code>Zzzz</code></td>
<td>Code for uncoded script, Unknown [<a href="#UAX24">UAX24</a>]</td>
</tr>
<tr>
<td>Region </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>Etc/Unknown</code></td>
<td>Unknown or Invalid Time Zone</td>
</tr>
</table>
<p>When only the script or region are known, then a locale ID will use "und" as the language subtag portion. Thus the locale tag "und_Grek" represents the Greek
script; "und_US" represents the US territory.</p>
<h4>3.1.1 <a name="Numeric_Codes">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)<span class="removed"> </span>.
Unicode identifiers supply a standard mapping<span class="removed">s</span> 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>
<h3>3.2 <a name="BCP_47_Tag_Conversion">BCP 47 Tag
Conversion</a></h3>
<p>Unicode language and locale IDs can be converted to valid [<a href="#BCP47">BCP47</a>] language tags by performing the following transformation.</p>
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Convert any deprecated codes into the regular equivalents (thus no...BOKMAL is replaced by nb...)</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Convert the "_" separators into "-"</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Convert "root" into "und"</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">If there are any
keyword-type pairs:<ol>
<li>convert the keys to corresponding
subtags consisting of two alphanumeric letters using <i>Appendix
C.16 <a href="#BCP47_Keyword_Mapping">BCP 47 Keyword Mapping</a></i></li>
<li>sort the resulting two-letter keys in
alphabetical order</li>
<li>convert the corresponding types to
subtags of 3..8 alphanumeric letters using <i>Appendix C.16 <a href="#BCP47_Keyword_Mapping">
BCP 47 Keyword Mapping</a></i></li>
<li>append the BCP extension subtag 'u'*,
followed by all of the converted key/value subtags, each separated
by '-'.</li>
</ol>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
Any fields that cannot be validly represented in [<a href="#BCP47">BCP47</a>]
are appended at the end, after inserting "x-ldml-".</li>
</ol>
<blockquote>
<p>* The extension subtag is anticipated to be
'u'. Until such time as that registration is complete, for a fully valid
BCP 47 language tag, 'x' would be used instead.</p>
</blockquote>
<p><span>Thus for example, we get the following conversion:</span></p>
<table border="1" cellspacing="0" cellpadding="4" style="margin-top: 0.5em; margin-bottom: 0.5em" id="table28">
<tr>
<td>Unicode</td>
<td><span>en_Latn_US@calendar=islamic;collation=digits-after;colStrength=secondary</span></td>
</tr>
<tr>
<td><span>[<a href="#BCP47">BCP47</a>]</span></td>
<td><span>
en-Latn-US-u-ca-islamic-co-digitaft-ks-level2</span></td>
</tr>
</table>
<p><span>In older versions of LDML, Step 5 was instead:</span></p>
<ol>
<li><span>Remove any non-alphanumerics from
identifiers (thus islamic-civil is replaced by islamiccivil)</span></li>
<li><span>Truncate the lengths of each subtag to 8
characters</span></li>
<li><span>Insert "x-ldml-" if not already present</span></li>
<li><span>Replace "@" and "," by "-k-", and</span></li>
<li><span>Change "=" to "-"</span></li>
</ol>
<p>Thus for example, we got the following conversion:</p>
<table border="1" cellspacing="0" cellpadding="4" style="margin-top: 0.5em; margin-bottom: 0.5em" id="table3">
<tr>
<td>Unicode</td>
<td>en_US_POSIX@calendar=islamic;collation=digits;colStrength=secondary</td>
</tr>
<tr>
<td>[<a href="#BCP47">BCP47</a>]</td>
<td>en-US-x-ldml-POSIX-k-calendar-islamic-k-collation-digits-k-colStren-secondar</td>
</tr>
</table>
<p><span>Implementations of LDML may or may not choose
to support the older formulation for backwards compatibility.</span></p>
<h3>3.3 <a name="Relation_to_OpenI18n">Relation to
OpenI18n</a></h3>
<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>
<h2>4. <a name="Locale_Inheritance">Locale Inheritance</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 & territory neutral. For example, the collation (sorting) order in the root is the default
Unicode Collation Algorithm order (see [<a href="#UCA">UCA</a>]). Since English language collation has the same ordering, the 'en' locale data does not need
to supply any collation data, nor does either the 'en_US' or the 'en_IE' locale data.</p>
<p>Given a particular locale id "en_IE_someVariant", the search chain for a particular resource is the following.</p>
<blockquote>
<pre>en_IE_someVariant
en_IE
en
root</pre>
</blockquote>
<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: "en" will contain the bulk of the data: "en_IE" 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 "primary" child locale will be empty, since its
parent will contain all of the appropriate resources for it. For more
information see <i>Appendix P.3 <a href="#Default_Content">Default Content</a>.</i></p>
<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>
<p>There are actually two different kinds of
fallback: resource bundle lookup and resource item lookup. For the former, a
process is looking to find the first, best resource bundle it can; for the
later, it is fallback within bundles on individual items, like a the
translated name for the region "CN" in Breton. These are closely related,
but distinct, processes. Below "key" stands for zero or more key/type pairs.</p>
<div id="iqaw2" style="margin-top: 0px; margin-bottom: 0px; ">
<table id="a1bn" border="1" cellpadding="3" cellspacing="0" style="font-size: 1em; line-height: inherit; border-collapse: collapse">
<caption>Lookup Differences</caption>
<tbody id="iqaw3">
<tr id="x40y0">
<th id="x40y1" style="vertical-align: top; " nowrap>
<p >
Lookup Type<br id="x40y2">
</th>
<th id="x40y3" style="vertical-align: top; " nowrap>
<p >
Example<br id="x40y4">
</th>
<th id="x40y5" style="vertical-align: top; ">
<p >
Comments<br id="x40y6">
</th>
</tr>
<tr id="iqaw4">
<td id="iqaw5" style="vertical-align: top; " nowrap>
<p id="rkc40" >
Resource <b>bundle</b> lookup</td>
<td id="iqaw7" style="vertical-align: top; " nowrap>
<p >
se-FI → se<br>
→ default*<br>
→ root</td>
<td id="rkc41" style="vertical-align: top; ">
<p >
* default may have its own inheritance change; for example, it may be "en-GB → en" In that case, the chain is expanded
by inserting the chain, resulting in:<br>
se-FI → se<br>
→ fi → en-GB →
en<br>
→ root </td>
</tr>
<tr id="iqaw9">
<td id="iqaw10" style="vertical-align: top; " nowrap>
<p >
Resource <b>item</b> lookup</td>
<td id="iqaw12" style="vertical-align: top; " nowrap>
<p >
se-FI+key → se+key<br>
→ root_alias*+key → root+key</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.<br>
se-FI+key → se+key<br>
→ root_alias*+key<br>
→ se-FI+key2 → se+key2<br>
→ root_alias*+key2 → root+key2</td>
</tr>
</table>
</div>
<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. Moreover, the resource
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. Resource bundle lookup, on the other hand, is
more flexible; changes in the view of the "best" 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">Section 5.3.1 Fallback_Elements</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">Appendix I: Inheritance
and Validity</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/Public/UNIDATA/UCD.html">UCD</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 ("[]") to block inheritance.</p>
<h3>4.1 <a name="Multiple_Inheritance">Multiple Inheritance</a></h3>
<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 "en_US" the month data in <calendar class="<span style="color: blue">buddhist</span>"> inherits first from <calendar class="<span style="color: blue">buddhist</span>">
in "en", then in "root". If not found there, then it inherits from <calendar type="<span style="color: blue">gregorian</span>"> in "en_US", then "en", then
in "root".</p>
<h2>5 <a name="XML_Format">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/segmentations/ja.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.</p>
<p>Supplemental data relating to Japan or the Japanese writing system can be found in:</p>
<ul>
<li>common/supplemental/supplementalData.xml</li>
<li>common/transforms/Hiragana-Katakana.xml</li>
<li>common/transforms/Hiragana-Latin.xml</li>
<li>...</li>
</ul>
<p>The following sections describe the structure of the XML format for language-dependent data. The more precise syntax is in the DTD, listed at the top of
this document<i>; however, the DTD does not describe all the constraints on the structure.</i></p>
<p>To start with, the root element is <ldml>, with the following DTD entry:</p>
<span class="dtd"><!ELEMENT ldml (identity, (alias |(fallback?, localeDisplayNames?, layout?, characters?, delimiters?, measurement?, dates?, numbers?, units?, collations?, posix?, segmentations?, references?, special*))) ></span><p>That element contains the following elements:</p>
<ul>
<li><a href="#Identity_Elements"><identity></a></li>
<li><a href="#Fallback_Elements"><fallback></a></li>
<li><a href="#Display_Name_Elements"><localeDisplayNames></a></li>
<li><a href="#Layout_Elements"><layout></a></li>
<li><a href="#Character_Elements"><characters></a></li>
<li><a href="#Delimiter_Elements"><delimiters></a></li>
<li><a href="#Measurement_Elements"><measurement></a></li>
<li><a href="#Date_Elements"><dates></a></li>
<li><a href="#Number_Elements"><numbers></a></li>
<li><a href="#Unit_Elements"><units></a></li>
<li><a href="#Collation_Elements"><collations></a></li>
<li><a href="#POSIX_Elements"><posix></a></li>
<li><a href="#Reference_Elements"><references></a></li>
</ul>
<p>The structure of each of these elements and their contents will be described below. The first few elements have little structure, while dates, numbers, and
collations are more involved.</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.</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 "mixed" 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 structure elements are listed in serialElements
in the supplemental metadata. See also <i><a href="#Inheritance_and_Validity">Appendix I: 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 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><languages><br>
<language type="aa">...</language><br>
<language type="aa">..</language></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, data should be in NFC format. Exceptions to this include transforms, segmentations, and pc/sc/tc/qc/ic rules in collation. 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,
and that leading and trailing spaces are to be ignored (that is, they behave like NMTOKENS). These include:</p>
<ul>
<li>singleCountries</li>
<li>preferenceOrdering</li>
<li>references</li>
<li>validSubLocales</li>
</ul>
<h3>5.1 <a name="Common_Elements">Common Elements</a></h3>
<p>At any level in any element, two special elements are allowed.</p>
<p class="element2"><<a name="special">special</a> xmlns:yyy="<span style="color: blue">xxx</span>"></p>
<p>This element is designed to allow for arbitrary additional annotation and data that is product-specific. It has one required attribute, 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><!DOCTYPE ldml SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.0/ldml.dtd</span>" [
<!ENTITY % posix SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.0/ldmlPOSIX.dtd</span>">
<span style="color: blue">%posix;</span>
]>
<ldml>
...
<special xmlns:posix="<span style="color: blue">http://www.opengroup.org/regproducts/xu.htm</span>">
<span style="color: green"><!-- old abbreviations for pre-GUI days --></span>
<posix:messages>
<posix:yesstr><span style="color: blue">Yes</span></posix:yesstr>
<posix:nostr><span style="color: blue">No</span></posix:nostr>
<posix:yesexpr><span style="color: blue">^[Yy].*</span></posix:yesexpr>
<posix:noexpr><span style="color: blue">^[Nn].*</span></posix:noexpr>
</posix:messages>
</special>
</ldml></pre>
<p class="element2"><b><span class="dtd"><!ELEMENT alias (special*) ><br>
<!ATTLIST alias source NMTOKEN #REQUIRED ><br>
<!ATTLIST alias path CDATA #IMPLIED></span></b></p>
<p>The contents of any element can be replaced by an alias, which points to another source for the data. The elements in that source
(a locale ID) are to be fetched from
the corresponding location in the other source based on the path. Normal resource searching is to be used; take the following example:</p>
<pre><ldml>
<collations>
<collation type="<span style="color: blue">phonebook</span>">
<alias source="<span style="color: blue">de_DE</span>">
</collation>
</collations>
</ldml></pre>
<p>The resource bundle at "de_DE" will be searched for a resource element at the same position in the tree with type "collation". If not found there, then the
resource bundle at "de" will be searched, and so on. For an example of how this works with inheritance, look at the following table (where <span class="inherited">
green</span> indicates inherited items). <i>Note in particular that an alias "reroutes" the inheritance; nothing in the parent affects the contents of an item
with an alias. Thus the </i><span class="blockedInherited">red</span><i> item below is blocked.</i></p>
<table border="1" cellpadding="0" cellspacing="1" class="noborder">
<caption>Inheritance with Aliases</caption>
<tr>
<th width="20%">en</th>
<th width="20%">en_US</th>
<th width="20%" bgcolor="#C0C0C0">Resolved</th>
</tr>
<tr>
<td width="20%"><code><x><br>
<a>01</a><br>
<b>02</a><br>
<c>03</a><br>
</x></code></td>
<td width="20%"><code><x><br>
<br>
<b>12</b><br>
<br>
</x></code></td>
<td width="20%" bgcolor="#C0C0C0"><code><x><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><a>01</a></span></span></span><br>
<b>12</b><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><c>03</c></span></span></span><br>
</x></code></td>
</tr>
<tr>
<th width="20%">de</th>
<th width="20%">de_DE</th>
<th width="20%" bgcolor="#C0C0C0">Resolved</th>
<th width="20%">de_DE_1901</th>
<th width="20%" bgcolor="#C0C0C0">Resolved</th>
</tr>
<tr>
<td width="20%"><code><x><br>
<a>21</a><br>
<b>22</b><br>
<c>23</c><br>
<span style="background-color: #FFFF00"><span class="blockedInherited"><span style="font-weight: 400; "><d>23</d></span></span></span><br>
</x></code></td>
<td width="20%"><code><x><br>
<alias source="en_US"><br>
<br>
<br>
</x></code></td>
<td width="20%" bgcolor="#C0C0C0"><code><x><br>
<a>01</a><br>
<b>12</b><br>
<c>03</c><br>
<br>
</x></code></td>
<td width="20%"><code><x><br>
<a>41</a><br>
<br>
<br>
<br>
</x></code></td>
<td width="20%" bgcolor="#C0C0C0"><code><x><br>
<a>41</a><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><b>12</b></span></span></span><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><c>03</c><br>
</span></span></span><br>
</x></code></td>
</tr>
</table>
<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><alias source="root" path="../monthWidth[@type='wide']"/></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">Appendix I: Inheritance and Validity</a>.</p>
<p>There is a special value for the source attribute, the constant <b>source="locale"</b>. This special value is equivalent to the
locale being resolved. For example, consider the following example, where locale data for 'de' is being resolved:</p>
<div align="center">
<center>
<table border="1" cellpadding="0" cellspacing="1">
<caption>Inheritance with source="locale"</caption>
<tr>
<th>Root</th>
<th>de</th>
<th bgcolor="#C0C0C0">Resolved</th>
</tr>
<tr>
<td><code><x><br>
<a>1</a><br>
<b>2</b><br>
<c>3</c><br>
<br>
</x></code></td>
<td><code><x><br>
<a>11</a><br>
<b>12</b><br>
<br>
<d>14</d><br>
</x></code></td>
<td bgcolor="#C0C0C0"><code><x><br>
<a>11</a><br>
<b>12</b><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><c>3</c></span></span></span><br>
<d>14</d><br>
</x></code></td>
</tr>
<tr>
<td><code><y><br>
<alias source="locale" path="../x"><br>
</y></code></td>
<td><code><y><br>
<br>
<b>22</b><br>
<br>
<br>
<e>25</e><br>
</y></code></td>
<td bgcolor="#C0C0C0"><code><y><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><a>11</a></span></span></span><br>
<b>22</b><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><c>3</c></span></span></span><br>
<span style="background-color: #FFFF00"><span class="inherited"><span style="font-weight: 400; "><d>14</d></span></span></span><br>
<e>25</e><br>
</y></code></td>
</tr>
</table>
</center></div>
<p>The first row shows the inheritance within the <x> element, whereby <c> is inherited from root. The second shows the inheritance within the <y> element,
whereby <a>, <c>, and <d> 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 'target' locale.</p>
<p>For more details on data resolution, see <a href="#Inheritance_and_Validity">Appendix I: Inheritance and Validity</a>.</p>
<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 multiple inheritance) can be followed indefinitely without terminating.</p>
<p class="element2"><span class="dtd"><displayName></span></p>
<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> <numberFormat>
<displayName><span style="color: blue">Prozentformat</span></displayName>
...
<numberFormat></pre>
<p>Where present, the display names must be unique; that is, two distinct code would not get the same display name. (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>
<p class="element2"><span class="dtd"><default type="<span style="color: blue">someID</span>"/></span></p>
<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 type attribute is to match the value of the type attribute for the selected item.</p>
<pre><timeFormats>
<default type="<span style="color: red">medium</span>" />
<timeFormatLength type="<span style="color: blue">full</span>">
<timeFormat type="<span style="color: blue">standard</span>">
<pattern type="<span style="color: blue">standard</span>"><span style="color: blue">h:mm:ss a z</span></pattern>
</timeFormat>
</timeFormatLength>
<timeFormatLength type="<span style="color: blue">long</span>">
<timeFormat type="<span style="color: blue">standard</span>">
<pattern type="<span style="color: blue">standard</span>"><span style="color: blue">h:mm:ss a z</span></pattern>
</timeFormat>
</timeFormatLength>
<timeFormatLength type="<span style="color: red">medium</span>">
<timeFormat type="<span style="color: blue">standard</span>">
<pattern type="<span style="color: blue">standard</span>"><span style="color: blue">h:mm:ss a</span></pattern>
</timeFormat>
</timeFormatLength>
...</pre>
<p>Like all other elements, the <default> 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><timeFormats>
<default type="<span style="color: red">long</span>"/>
</timeFormats></pre>
<p>In that case, the default time format for fr_BE would be the inherited "long" resource from fr. Now suppose that we had in fr_CA:</p>
<pre> <timeFormatLength type="<span style="color:red">medium</span>">
<timeFormat type="<span style="color: blue">standard</span>">
<pattern type="<span style="color: blue">standard</span>"><span style="color: blue">...</span></pattern>
</timeFormat>
</timeFormatLength>
</pre>
<p>In this case, the <default> is inherited from fr, and has the value "medium". It thus refers to this new "medium" pattern in this resource bundle.</p>
<h4>5.1.1 <a name="Escaping_Characters">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. These escapes are only allowed in certain elements, according to the DTD.</p>
<table>
<caption>Escaping Characters</caption>
<tr>
<th>Code Point</th>
<th>XML Example</th>
</tr>
<tr>
<td><code>U+0000</code></td>
<td><code><cp hex="0"></code></td>
</tr>
</table>
<h4>5.1.2 <a name="Text_Directionality">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>
<h3>5.2 <a name="Common_Attributes">Common Attributes</a></h3>
<p class="element2"><... type="<span style="color: blue">stroke</span>" ...></p>
<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><ldml>
...
<currencies>
<currency><span style="color: blue">...</span></currency>
<currency type="<span style="color: blue">preEuro</span>"><span style="color: blue">...</span></currency>
</currencies>
</ldml></pre>
<p class="element2"><... draft="<span style="color: #0000FF">unconfirmed</span>" ...></p>
<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://unicode.org/cldr/process.html#data_vetting_process">Data Submission and
Vetting Process</a> on the CLDR website.</p>
<p>Normally draft attributes should only occur on "leaf" elements. For a more formal description of how elements are inherited, and what their draft status
is, see <i><a href="#Inheritance_and_Validity">Appendix I: Inheritance and Validity</a></i>.</p>
<p><... <a name="alt_attribute">alt</a>="<i>descriptor</i>" ...></p>
<p>This attribute labels an alternative value for an element. The <i>descriptor</i> indicates what kind of alternative it is, and takes one of the following
forms: </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>"<span style="color: blue">proposed</span>" should only be present if the draft status is not "approved". 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 "Settembru", and a bug report is filed that that should be "Settembro". The new data can be entered in, but marked as <i>alt="proposed"</i>
until it is vetted. </p>
<pre>...
<month type="9">Settembru</month>
<month type="9" draft="unconfirmed" alt="proposed">Settembro</month>
<month type="10">...</pre>
<p>Now assume another bug report comes in, saying that the correct form is actually "Settembre". Another alternative can be added: </p>
<pre>...
<month type="9" draft="unconfirmed" alt="proposed2">Settembre</month>
...</pre>
<p>The allowable values for <i>variantname</i> at this time are "<span style="color: blue">variant</span>", "<span style="color: blue">list</span>", "<span style="color: blue">email</span>",
"<span style="color: blue">www</span>", and "<span style="color : blue">secondary</span>". This may be expanded in the future.</p>
<p><... validSubLocales="de_AT de_CH de_DE" ...></p>
<p>The attribute <i>validSubLocales</i> allows sublocales in a given tree to be treated as though a file for them were present when there
is not one. It can
be applied to any element. It only has an effect for locales that inherit from the current file where a file is missing, and the elements would
not otherwise
be draft.</p>
<p>For a more complete description of how draft applies to data, see <i><a href="#Inheritance_and_Validity">Appendix I: Inheritance and Validity</a></i>.</p>
<p class="element2"><... standard="<span style="color: blue">...</span>" ...></p>
<blockquote>
<p class="element2"><b>Note: </b>This attribute is deprecated. Instead, use a reference element with the attribute standard="true". See Section 5.13
<a href="#Reference_Elements"><references>.</a></p>
</blockquote>
<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><collation standard="<span style="color: blue">MSA 200:2002</span>"><br>
...<br>
<dateFormatStyle standard=”http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780&amp;ICS1=1&amp;ICS2=140&amp;ICS3=30”></code></p>
<p><... <a name="references_attribute">references</a>="<span style="color: blue">...</span>" ...></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. See Section 5.13
<a href="#Reference_Elements"><references></a>. (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"><territory type="UM" references="R222">USAs yttre öar</territory></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><br>
<... allow="verbatim" ...><br>
<br>
In certain circumstances, one or more elements do not follow the rule of the majority. as indicated by the inText element. In this case, the allow attribute
is used:<br>
The example below indicates that variant names are normally lower case with one exception.<br>
</p>
<p><code><inText type="languages">lowercase-words</inText><br>
<variants><br>
<variant type="1901">ortografia tradizionale tedesca</variant><br>
<variant type="1996">ortografia tedesca del 1996</variant><br>
<variant type="NEDIS" allow="verbatim">dialetto del Natisone</variant><br>
</variants></code><br>
</p>
<h4>5.2.1 <a name="Date_Ranges">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. <i>In</i> some cases, the attribute is <i>
time</i>, and the element itself specifies whether it is equivalent to a <i>from</i> or a <i>to</i>.
For example, this is done with the weekEndStart and weekEndEnd elements. xxxx</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 "-" used as
a separator between date fields, a space used as the separator between the date and the time
fields, and ":" 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 "00:00:00" (midnight at the start of the day).</p>
</li>
<li>
<p class="note"><i>to </i>defaults to "24:00:00" (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><usesMetazone from="1991-10-27" to="2006-04-02"
.../></td>
</tr>
<tr>
<td><usesMetazone from="1991-10-27 00:00:00" to="2006-04-02
24:00:00" .../></td>
</tr>
<tr>
<td><usesMetazone from="1991-10-<font color="#FF0000"><b>26
24</b></font>:00:00" to="2006-04-<font color="#FF0000"><b>03 00</b></font>:00:00"
.../></td>
</tr>
</table>
<p class="note">as are the following:</p>
<table style="margin-top: 0.5em; margin-bottom: 0.5em" id="table24">
<tr>
<td><weekendStart day="<span style="color: blue">sat</span>"/><br>
<weekendEnd day="<span style="color: blue">sun</span>"/></td>
</tr>
<tr>
<td><weekendStart day="<span style="color: blue">sat</span>" time="<span style="color: blue">00:00</span>"/><br>
<weekendEnd day="<span style="color: blue">sun</span>" time="<span style="color: blue">24:00</span>"/></td>
</tr>
<tr>
<td><weekendStart day="<span style="color: blue">fri</span>" time="<span style="color: blue">24:00</span>"/><br>
<weekendEnd day="<span style="color: blue">mon</span>" time="<span style="color: blue">00:00</span>"/></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>
<h3>5.3 <a name="Identity_Elements">Identity Elements</a></h3>
<p><span class="dtd"><!ELEMENT identity (alias | (version, generation, language, script?, territory?, variant?, special*) ) ></span></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"><version number="<u>$</u>Revision: 1.227 <u>$</u>"></p>
<p>The version element provides, in an attribute, the version of this file. The contents of the element can contain textual notes about the changes between
this version and the last. For example:</p>
<blockquote>
<pre><version number="<span style="color: blue">1.1</span>"><span style="color: blue">Various notes and changes in version 1.1</span></version></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"><generation date="<u>$</u>Date: 2007/07/17 23:41:16 <u>$</u>" /></p>
<p>The generation element contains the last modified date for the data. This can be in two formats: ISO 8601 format, or CVS format (illustrated by the example
above).</p>
<p class="element2"><language type="<span style="color: blue">en</span>"/></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"><script type="<span style="color: blue">Latn</span>" /></p>
<p>The script code
may be used in the identification of written languages, with values described above.</p>
<p class="element2"><territory type="<span style="color: blue">US</span>"/></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"><variant type="<span class="attributeValue">NYNORSK</span>"/></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>
<h4>5.3.1 <a name="Fallback_Elements">Fallback Elements</a></h4>
<p><span class="dtd"><!ELEMENT fallback (#PCDATA) ><br>
<!ATTLIST fallback draft ( approved | contributed | provisional | unconfirmed ) #IMPLIED ><br>
<!ATTLIST fallback references CDATA #IMPLIED ></span></p>
<p>In many cases, there may not be full data for a particular locale. The fallback element
provides a mechanism to indicate what the best available fallback locales would be. 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 "CN" (for the country China).
It is best to return "chine", rather than falling back to the value default
language such as Russian and getting "Кітай" . </p>
<p>The contents are
a list of locales (languages) in priority order, separated by spaces.</p>
<p>When a fallback is used for resource item
lookup, the normal order of inheritance is used for resource item
lookup, except that before using
any data from Root, the data for the fallback locales would be used if available. That is,
normally we get the following fallback:</p>
<blockquote>
<p>sms-FI → sms → root.</p>
</blockquote>
<p>If the fallback values are (se-FI fi-FI), then instead the inheritance is:</p>
<blockquote>
<p>sms-FI → sms → se_FI → se → fi_FI → fi → root</p>
</blockquote>
<p>The fallback list is only a default list. It is recommended that any
implementation provide a mechanism for overriding the fallbacks,
by allowing users to specify a <i>language priority list</i> of acceptable
languages, instead of just a single language. For example, if my native
tongue is English, I can understand Swiss German and German, my French is
rusty but usable, and Italian basic, I might choose "gsw, de, fr" as my list
of languages, skipping Italian because my comprehension is not good enough
for arbitrary content. An example of such a list is the Accept-Language list
supplied by browsers.</p>
<p>With such information, the fallback list would
not be used. Instead, the priority list would be used both for bundle
fallback and for item fallback instead of root (see <i>
<a href="#Locale_Inheritance">Section 4, Locale Inheritance</a></i>). </p>
<h3>5.4 <a name="Display_Name_Elements">Display Name Elements</a></h3>
<p><span class="dtd"><!ELEMENT localeDisplayNames (alias | (localeDisplayPattern?, languages?, scripts?, territories?, variants?,
keys?, types?, measurementSystemNames?, codePatterns?, special*))
></span></p>
<p>Display names for scripts, languages, countries, currencies, and variants in this locale are supplied by this element. They supply localized names for these items for use in user-interfaces for displaying menu lists. In addition, the localized names for currency items may also be suitable for use in user-interfaces involving flowing text.
Examples are given below. </p>
<blockquote>
<p class="note"><b>Note:</b> The "<span style="color: blue">en</span>" locale may contain translated names for deprecated codes for debugging purposes.
Translation of deprecated codes into other languages is discouraged.</p>
</blockquote>
<p>Where present, the display names must be unique; that is, two distinct code would not get the same display name. (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.)</p>
<p>Any translations should follow customary practice for the locale in question. For more information, see [<a href="#DataFormats">Data Formats</a>].</p>
<p class="element2"><localeDisplayPattern></p>
<p>For compound language (locale) IDs such as "pt_BR" which contain additional subtags beyond the initial language code:
When the <languages> data does not explicitly specify a display name such as "Brazilian Portuguese" for a given compound language ID,
this element specifies how to assemble a fallback display name such as "Portuguese (Brazil)" from the display names of the subtags.</p>
<p>It includes two sub-elements:</p>
<ul>
<li>The <localePattern> element specifies a pattern such as "{0} ({1})" in which {0} is replaced by the display name for the primary
language subtag and {1} is replaced by a list of the display names for the remaining subtags.</li>
<li>The <localeSeparator> element specifies the list separator for the display names in {1}.</li>
</ul>
<p class="element2"><languages></p>
<p>This contains a list of elements that provide the user-translated names for language codes, as described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section 3, Unicode Language and Locale Identifiers</a></i>.</p>
<blockquote>
<pre><language type="<span style="color: blue">ab</span>"><span style="color: blue">Abkhazian</span></language>
<language type="<span style="color: blue">aa</span>"><span style="color: blue">Afar</span></language>
<language type="<span style="color: blue">af</span>"><span style="color: blue">Afrikaans</span></language>
<language type="<span style="color: blue">sq</span>"><span style="color: blue">Albanian</span></language></pre>
</blockquote>
<p>The type can actually be any locale ID as specified above. The set of which locale IDs is not fixed, and depends on the locale. For example, in one language
one could translate the following locale IDs, and in another, fall back on the normal composition.</p>
<table border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="33%">type</th>
<th width="33%">translation</th>
<th width="34%">composition</th>
</tr>
<tr>
<td width="33%">nl_BE</td>
<td width="33%">Flemish</td>
<td width="34%">Dutch (Belgium)</td>
</tr>
<tr>
<td width="33%">zh_Hans</td>
<td width="33%">Simplified Chinese</td>
<td width="34%">Chinese (Simplified Han)</td>
</tr>
<tr>
<td width="33%">en_GB</td>
<td width="33%">British English</td>
<td width="34%">English (United Kingdom)</td>
</tr>
</table>
<p class="element2">Thus when a complete locale ID is formed by composition, the longest match in the language type is used, and the remaining fields (if any)
added using composition.</p>
<p class="element2"><scripts></p>
<p>This element can contain an number of script elements. Each script element provides the localized name for a script code, as described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section 3, Unicode Language and Locale Identifiers</a> </i>(see also <i>UAX #24: Script Names</i> [<a href="#Scripts">Scripts</a>]). For example, in the language
of this locale, the name for the Latin script might be "Romana", and for the Cyrillic script is "Kyrillica". That would be expressed with the following.</p>
<blockquote>
<p><script type="<span style="color: blue">Latn</span>"><span style="color: blue">Romana</span></script><br>
<script type="<span style="color: blue">Cyrl</span>"><span style="color: blue">Kyrillica</span></script></p>
</blockquote>
<p class="element2"><territories></p>
<p>This contains a list of elements that provide the user-translated names for territory codes, as described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section 3, Unicode Language and Locale Identifiers</a></i>.</p>
<blockquote>
<p><territory type="<span style="color: blue">AF</span>"><span style="color: blue">Afghanistan</span></territory><br>
<territory type="<span style="color: blue">AL</span>"><span style="color: blue">Albania</span></territory><br>
<territory type="<span style="color: blue">DZ</span>"><span style="color: blue">Algeria</span></territory><br>
<territory type="<span style="color: blue">AD</span>"><span style="color: blue">Andorra</span></territory><br>
<territory type="<span style="color: blue">AO</span>"><span style="color: blue">Angola</span></territory><br>
<territory type="<span style="color: blue">US</span>"><span style="color: blue">United States</span></territory></p>
</blockquote>
<p class="element2"><variants></p>
<p>This contains a list of elements that provide the user-translated names for the <i>variant_code</i> values described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section
3, Unicode Language and Locale Identifiers</a></i>.</p>
<blockquote>
<p><variant type="<span style="color: blue">nynorsk</span>"><span style="color: blue">Nynorsk</span></variant></p>
</blockquote>
<p class="element2"><keys></p>
<p>This contains a list of elements that provide the user-translated names for the <i>key</i> values described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section 3, Unicode Language and Locale Identifiers</a></i>.</p>
<blockquote>
<p><key type="<span style="color: blue">collation</span>"><span style="color: blue">Sortierung</span></key></p>
</blockquote>
<p class="element2"><types></p>
<p>This contains a list of elements that provide the user-translated names for the <i>type</i> values described in <i>
<a href="#Unicode_Language_and_Locale_Identifiers">Section 3, Unicode Language and Locale Identifiers</a></i>. Since the translation of an option name may depend on the <i>key</i> it is used with, the latter is optionally supplied.</p>
<blockquote>
<p><type type="<span style="color: blue">phonebook</span>" key="<span style="color: blue">collation</span>"><span style="color: blue">Telefonbuch</span></type></p>
</blockquote>
<p class="element2"><measurementSystemNames></p>
<p>This contains a list of elements that provide the user-translated names for systems of measurement. The types currently supported are "<span style="color: blue">US</span>",
"<span style="color: blue">metric</span>", and "<span style="color: blue">UK</span>".</p>
<blockquote>
<p><measurementSystemName type="<span style="color: blue">US</span>"><span style="color: blue">U.S.</span></type></p>
<p> </p>
<p class="note"><b>Note:</b> In the future, we may need to add display names for the particular measurement units (millimeter
versus millimetre versus whatever
the Greek, Russian, etc are), and a message format for positioning those with respect to numbers.
for example, "{number} {unitName}" in some languages, but "{unitName}
{number}" in others.</p>
</blockquote>
<h3>5.5 <a name="Layout_Elements">Layout Elements</a></h3>
<p><span class="dtd"><!ELEMENT layout ( alias | (orientation*, inList*, inText*, special*) ) ></span></p>
<p>This top-level element specifies general layout features. It currently only has one possible element (other than <special>, which is always permitted).</p>
<p class="element2"><orientation lines="<span style="color: blue">top-to-bottom</span>" characters="<span style="color: blue">left-to-right</span>" /></p>
<p>The lines and characters attributes specify the default general ordering of lines within a page, and characters within a line. The values are:</p>
<table>
<caption>Orientation Attributes</caption>
<tr>
<td rowspan="2">Vertical</td>
<td>top-to-bottom</td>
</tr>
<tr>
<td>bottom-to-top</td>
</tr>
<tr>
<td rowspan="2">Horizontal</td>
<td>left-to-right</td>
</tr>
<tr>
<td>right-to-left</td>
</tr>
</table>
<p>If the lines value is one of the vertical attributes, then the characters value must be one of the horizontal attributes, and vice versa. For example, for
English the lines are top-to-bottom, and the characters are left-to-right. For Mongolian (in the Mongolian Script) the lines are right-to-left, and the characters
are top to bottom. This does not override the ordering behavior of bidirectional text; it does, however, supply the paragraph direction for that text (for more
information, see <i>UAX #9: The Bidirectional Algorithm</i> [<a href="#BIDI">BIDI</a>]).</p>
<p>For dates, times, and other data to appear in the right order, the display for them should be set to the orientation of the locale.</p>
<p><inList></p>
<p>The following element controls whether display names (language, territory, etc) are
title cased in GUI menu lists and the like. It is only used in languages
where the normal display is lower case, but title case is used in lists. There are two options:</p>
<pre><inList casing="titlecase-words"></pre>
<pre><inList casing="titlecase-firstword"></pre>
<p>In both cases, the title case operation is the default title case function defined by Chapter 3 of <i>[<a href="#Unicode">Unicode</a>]</i>. In the second case,
only the first word (using the word boundaries for that locale) will be
title cased. The results can be fine-tuned by using alt="list" on any element where titlecasing
as defined by the Unicode Standard will produce the wrong value. For example, suppose that "turc de Crimée" is a value, and the
title case should be "Turc de
Crimée". Then that can be expressed using the alt="list" value.</p>
<p><inText></p>
<p>This element indicates the casing of the data in the category identified by the inText type attribute, when that data is written in text or how it would
appear in a dictionary. For example :</p>
<pre><inText type="languages">lowercase-words</inText></pre>
<p>indicates that language names embedded in text are normally written in lower case. The possible values and their meanings are :</p>
<ul>
<li>titlecase-words : all words in the phrase should be title case</li>
<li>titlecase-firstword : the first word should be title case</li>
<li>lowercase-words : all words in the phrase should be lower case</li>
<li>mixed : a mixture of upper and lower case is permitted. generally used when the correct value is unknown.<br>
</li>
</ul>
<h3>5.6 <a name="Character_Elements">Character Elements</a></h3>
<p><span class="dtd"><!ELEMENT characters (alias | (exemplarCharacters*, mapping*, special*)) ></span></p>
<p>The <characters> element provides optional information about characters that are in common use in the locale, and information that can be helpful in picking
resources or data appropriate for the locale, such as when choosing among character encodings that are typically used to transmit data in the language of the
locale. It typically only occurs in a language locale, not in a language/territory locale.</p>
<p class="element2"><exemplarCharacters><span style="color: blue">[a-zåæø]</span></exemplarCharacters></p>
<p>The exemplar character set contains the commonly used letters for a given modern form of a language, which can be for testing and for determining the appropriate
repertoire of letters for charset conversion or collation. ("Letter" is interpreted broadly, as anything having the property Alphabetic in the [<a href="#UCD">UCD</a>],
which also includes syllabaries and ideographs.) It is not a complete set of letters used for a language, nor should it be considered to apply to multiple languages
in a particular country. Punctuation and other symbols should not be included. In particular, format characters like CGJ are not included.</p>
<p>There are three sets: main, auxiliary, and currency. The <i>main</i> set should contain the minimal set required for users of the language, while the <i>auxiliary</i> exemplar set is designed
to encompass additional characters: those non-native or historical characters that would customarily occur in common publications, dictionaries, and so on.
So, for example, if Irish newspapers and magazines would commonly have Danish names using å, for example, then it would be appropriate to include å in the auxiliary
exemplar characters; just not in the main exemplar set. Note also that
all of the main exemplars should be typeable with normal keyboards for that language. Major style guidelines are good references for the auxiliary set. Thus for English we have [a-z] in
the main set, and [á à ă â å ä ā æ ç é è ĕ ê ë ē í ì ĭ î ï ī ñ ó ò ŏ ô ö ø ō œ ß ú ù ŭ û ü ū ÿ] in the auxiliary set.</p>
<p>In general, the test to see whether or not a letter belongs in the main set is based on whether it is acceptable in that language to always use spellings
that avoid that character. For example, the exemplar character set for en (English) is the set [a-z]. This set does not contain the accented letters that are
sometimes seen in words like "résumé" or "naïve", because it is acceptable in common practice to spell those words without the accents. The exemplar character
set for fr (French), on the other hand, must contain those characters: [a-z é è ù ç à â ê î ô û æ œ ë ï ÿ]. The main set typically includes those letters commonly
taught in schools as the "alphabet".</p>
<p>The <i>currency</i> set allows other characters in currency symbols (like
USD).</p>
<p>The list of characters is in the <a href="#Unicode_Sets">Unicode Set</a> format, which allows boolean combinations of sets of letters, including those specified
by Unicode properties.</p>
<p>Sequences of characters that act like a single letter in the language — especially in collation — are included within braces, such as [a-z á é í ó ú ö ü
ő ű {cs} {dz} {dzs} {gy} ...]. The characters should be in normalized form (NFC). Where combining marks are used generatively, and apply to a large number of
base characters (such as in Indic scripts), the individual combining marks should be included. Where they are used with only a few base characters, the specific
combinations should be included. Wherever there is not a precomposed character (for
example, single codepoint) for a given combination, that must be included within
braces. For example, to include sequences from the <a href="http://unicode.org/standard/where/">Where is my Character?</a> page on the Unicode site, one would
write: [{ch} {tʰ} {x̣} {ƛ̓} {ą́} {i̇́} {ト゚}], but for French one would just write [a-z é è ù ...]. When in doubt use braces, since it does no harm to included
them around single code points: for example, [a-z {é} {è} {ù} ...].</p>
<p>If the letter 'z' were only ever used in the combination 'tz', then we might have [a-y {tz}] in the main set. (The language would probably have plain 'z'
in the auxiliary set, for use in foreign words.) If combining characters can be used productively in combination with a large number of others (such as say
Indic matras), then they are not listed in all the possible combinations, but separately, such as: </p>
<blockquote>
<p>[ ॐ ०-९ ऄ-ऋ ॠ ऌ ॡ ऍ-क क़ ख ख़ ग ग़ घ-ज ज़ झ-ड ड़ ढ ढ़ ण-फ फ़ ब-य य़ र-ह ़ ँ-ः ॑-॔ ऽ ् ॽ ा-ॄ ॢ ॣ ॅ-ौ] </p>
</blockquote>
<p>The exemplar character set for Han characters is composed somewhat differently. It is even harder to draw a clear line for Han characters, since usage is
more like a frequency curve that slowly trails off to the right in terms of decreasing frequency. So for this case, the exemplar characters simply contain a
set of reasonably frequent characters for the language.</p>
<p>The ordering of the characters in the set is irrelevant, but for readability in the XML file the characters should be in sorted order according to the locale's
conventions. The set should only contain lower case characters (except for the special case of Turkish and similar languages, where the dotted capital I should
be included); the upper case letters are to be mechanically added when the set is used. For more information
on casing, see the discussion of Special Casing in the Unicode Character Database.</p>
<h4>5.6.1. Restrictions</h4>
<ol>
<li>The sets are normally restricted to those letters with a specific <a href="http://unicode.org/Public/UNIDATA/Scripts.txt">Script </a>character property
(that is, not the values Common or Inherited) or required <a href="http://unicode.org/Public/UNIDATA/DerivedCoreProperties.txt">Default_Ignorable_Code_Point</a>
characters (such as a non-joiner), or combining marks, or the <a href="http://www.unicode.org/Public/UNIDATA/auxiliary/WordBreakProperty.txt">Word_Break</a>
properties <a name="Katakana">Katakana</a>, <a name="ALetter">ALetter</a>, or <a name="MidLetter">MidLetter</a>.</li>
<li>The auxiliary set should not overlap with the main set. There is one exception to this: Hangul Syllables and CJK Ideographs can overlap between the
sets.</li>
<li>Any <a href="http://unicode.org/Public/UNIDATA/DerivedCoreProperties.txt">Default_Ignorable_Code_Point</a>s should be in the auxiliary set , or, if they are only needed for currency formatting, in the currency set. These can include characters such as
U+200E LEFT-TO-RIGHT MARK and U+200F RIGHT-TO-LEFT MARK which may be needed in bidirectional text in order for date, currency or other formats
to display correctly.</li>
</ol>
<p class="element2"><mapping registry="<span style="color: blue">iana</span>" type="<span style="color:blue">iso-2022-jp utf-8</span>" alt="<span style="color : blue">email</span>"
/></p>
<p>The mapping element describes character conversion mapping tables that are commonly used to encode data in the language of this locale for a particular purpose.
Each encoding is identified by a name from the specified registry. If more than one encoding is used for a particular purpose, the encodings are listed in the
type attribute in order, from most preferred to least. An alt tag is used to indicate the purpose ("email" or "www" being the most frequent); if it is absent,
then the encoding(s) may be used for all purposes not explicitly specified.</p>
<p>Each locale may have at most one mapping element tagged with a particular purpose, and at most one general-purpose mapping element. Inheritance is on an
element basis; an element in a sub-locale overrides an inherited element with the same purpose.</p>
<p><span>For email usage (alt="email") the list begins with encodings that should be tried for outgoing mail; these encodings should
be tried in order until one is found that can represent the message text. Typically, this section of the encoding list terminates with encoding "utf-8",
which can represent any message text. Any encodings listed after "utf-8" may be encountered in incoming messages (along with the encodings in the first
section) and should be handled for incoming messages, but should not be used for outgoing messages.</span></p>
<p>Currently the only registry that can be used is "iana", which specifies use of an <a href="http://www.iana.org/assignments/character-sets">IANA name</a>.
</p>
<blockquote>
<p><b>Note:</b> While IANA names are not precise for conversion (see <i>UTR #22: Character Mapping Tables</i> [<a href="#CharMapML">CharMapML</a>]), they
are sufficient for this purpose.</p>
</blockquote>
<h3>5.7 <a name="Delimiter_Elements">Delimiter Elements</a></h3>
<p><span class="dtd"><!ELEMENT delimiters (alias | (quotationStart*, quotationEnd*, alternateQuotationStart*, alternateQuotationEnd*, special*)) ></span></p>
<p>The delimiters supply common delimiters for bracketing quotations. The quotation marks are used with simple quoted text, such as:</p>
<blockquote>
<p>He said, “Don’t be absurd!”</p>
</blockquote>
<p>When quotations are nested, the quotation marks and alternate marks are used in an alternating fashion:</p>
<blockquote>
<p>He said, “Remember what the Mad Hatter said: ‘Not the same thing a bit! Why you might just as well say that “I see what I eat” is the same thing as “I
eat what I see”!’”</p>
</blockquote>
<p><code><quotationStart></code><span style="color: blue">“</span><code></quotationStart></code><br>
<code><quotationEnd></code><span style="color: blue">”</span><code></quotationEnd></code><br>
<code><alternateQuotationStart></code><span style="color: blue">‘</span><code></alternateQuotationStart></code><br>
<code><alternateQuotationEnd></code><span style="color: blue">’</span><code></alternateQuotationEnd></code></p>
<h3>5.8 <a name="Measurement_Elements">Measurement Elements (deprecated)</a></h3>
<p><span class="dtd"><!ELEMENT measurement (alias | (measurementSystem?, paperSize?, special*)) ></span></p>
<p>The measurement element is deprecated in the main LDML files, because the data is more appropriately organized as connected to territories, not to linguistic
data. Instead, the similar element in the supplemental data file should be used.</p>
<h3>5.9 <a name="Date_Elements">Date Elements</a></h3>
<p><span class="dtd"><!ELEMENT dates (alias | (localizedPatternChars*, calendars?, timeZoneNames?, special*)) ></span></p>
<p>This top-level element contains information regarding the format and parsing of dates and times. The data format is based on the Java/ICU format. Most of
these are fairly self-explanatory, except the<i> week </i>elements<i>,</i> <i>localizedPatternChars</i>, and the meaning of the pattern characters. For information
on this, and more information on other elements and attributes, see <i><a href="#Date_Format_Patterns">Appendix F: Date Format Patterns</a></i>.</p>
<h4>5.9.1 <a name="Calendar_Elements">Calendar Elements</a></h4>
<p><span class="dtd">
<!ELEMENT calendars (alias | (default*, calendar*, special*)) ><br>
<!ELEMENT calendar (alias | (months?, monthNames?, monthAbbr?, days?, dayNames?, dayAbbr?, quarters?, week?, am*, pm*,
eras?, dateFormats?, timeFormats?, dateTimeFormats?, fields*, special*))>
</span></p>
<p>This element contains multiple <calendar> elements, each of which specifies the fields used for formatting and parsing dates and times according to the given
calendar. The month and quarter names are identified numerically, starting at 1. The day (of the week) names are identified with short strings, since there
is no universally-accepted numeric designation.</p>
<p><b>Note: </b>The default attribute in the calendars element is deprecated. The default calendar type for a locale is specified by
<i>C.15 <a href="#Calendar_Preference_Data">Calendar Preference Data</a></i>.</p>
<p>Many calendars will only differ from the Gregorian Calendar in the year and era values. For example, the Japanese calendar will have many more eras (one
for each Emperor), and the years will be numbered within that era. All calendar data inherits from the Gregorian calendar in the same locale data (if not present
in the chain up to root), so only the differing data will be present. See <i>Section 4.1 <a href="#Multiple_Inheritance">Multiple Inheritance</a></i>.</p>
<p><span class="dtd">
<!ELEMENT months ( alias | (default*, monthContext*, special*)) ><br>
<!ELEMENT monthContext ( alias | (default*, monthWidth*, special*)) ><br>
<!ATTLIST monthContext type ( format | stand-alone ) #REQUIRED ><br>
<!ELEMENT monthWidth ( alias | (month*, special*)) ><br>
<!ATTLIST monthWidth type ( abbreviated| narrow | wide) #REQUIRED ><br>
<!ELEMENT month ( #PCDATA | cp )* ><br>
<!ATTLIST month type ( 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ) #REQUIRED >
</span></p>
<p><span class="dtd">
<!ELEMENT days ( alias | (default*, dayContext*, special*)) ><br>
<!ELEMENT dayContext ( alias | (default*, dayWidth*, special*)) ><br>
<!ATTLIST dayContext type ( format | stand-alone ) #REQUIRED ><br>
<!ELEMENT dayWidth ( alias | (day*, special*)) ><br>
<!ATTLIST dayWidth type NMTOKEN #REQUIRED ><br>
<!ELEMENT day ( #PCDATA ) ><br>
<!ATTLIST day type ( sun | mon | tue | wed | thu | fri | sat ) #REQUIRED >
</span></p>
<p><span class="dtd">
<!ELEMENT quarters ( alias | (default*, quarterContext*, special*)) ><br>
<!ELEMENT quarterContext ( alias | (default*, quarterWidth*, special*)) ><br>
<!ATTLIST quarterContext type ( format | stand-alone ) #REQUIRED ><br>
<!ELEMENT quarterWidth ( alias | (quarter*, special*)) ><br>
<!ATTLIST quarterWidth type NMTOKEN #REQUIRED ><br>
<!ELEMENT quarter ( #PCDATA ) ><br>
<!ATTLIST quarter type ( 1 | 2 | 3 | 4 ) #REQUIRED >
</span></p>
<p>Month, day, and quarter names may vary along two axes: the width and the context. The context is either <i>format</i> (the default), the form used within
a date format string (such as "Saturday, November 12<sup>th</sup>", or <i>stand-alone</i>, the form used independently, such as in Calendar headers. The width
can be <i>wide</i> (the default), <i>abbreviated</i>, or <i>narrow</i>. The format values must be distinct; that is, "S" could not be used both for Saturday
and for Sunday. The same is not true for stand-alone values; they might only be distinguished by context, especially in the narrow format. That format is typically
used in calendar headers; it must be the shortest possible width, no more than one character (or grapheme cluster) in stand-alone values, and the shortest possible
widths (in terms of grapheme clusters) in format values.</p>
<p>Due to aliases in root, the forms inherit
"sideways". (See <i>Section 4.1
<a href="#Multiple_Inheritance">Multiple Inheritance</a></i>.)
For example, if the abbreviated format data for Gregorian does not exist in
a language X (in the chain up to root), then it inherits from the wide
format data in that same language X. </p>
<pre id="line369"><monthContext type="format">
<default choice="wide"/>
<monthWidth type="abbreviated">
<alias source="locale" path="../monthWidth[@type='wide']"/>
</monthWidth>
<monthWidth type="narrow">
<alias source="locale" path="../../monthContext[@type='<b>stand-alone</b>']/monthWidth[@type='narrow']"/>
</monthWidth>
<monthWidth type="wide">
<month type="1">1</month>
...
<month type="12">12</month>
</monthWidth>
</monthContext>
<monthContext type="stand-alone">
<monthWidth type="abbreviated">
<alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='abbreviated']"/>
</monthWidth>
<monthWidth type="narrow">
<month type="1">1</month>
...
<month type="12">12</month>
</monthWidth>
<monthWidth type="wide">
<alias source="locale" path="../../monthContext[@type='<b>format</b>']/monthWidth[@type='wide']"/>
</monthWidth>
</monthContext></pre>
<p>The older monthNames, dayNames, and monthAbbr, dayAbbr are maintained for backwards compatibility. They are equivalent to: using the months element with
the context type="<span style="color: blue">format</span>" and the width type="<span style="color: blue">wide</span>" (for ...Names) and type="<span style="color: blue">narrow</span>"
(for ...Abbr), respectively. The minDays, firstDay, weekendStart, and weekendEnd elements are also deprecated; there are new elements in supplemental data for
this data.</p>
<p class="example">Example:</p>
<pre> <calendar type="<span style="color: blue">gregorian</span>">
<months>
<default type="<span style="color: blue">format</span>"/>
<monthContext type="<span style="color: blue">format</span>">
<default type="<span style="color: blue">wide</span>"/>
<monthWidth type="<span style="color: blue">wide</span>">
<month type="<span style="color: blue">1</span>"><span style="color: blue">January</span></month>
<month type="<span style="color: blue">2</span>"><span style="color: blue">February</span></month>
...
<month type="<span style="color: blue">11</span>"><span style="color: blue">November</span></month>
<month type="<span style="color: blue">12</span>"><span style="color: blue">December</span></month>
</monthWidth>
<monthWidth type="<span style="color: blue">abbreviated</span>">
<month type="<span style="color: blue">1</span>"><span style="color: blue">Jan</span></month>
<month type="<span style="color: blue">2</span>"><span style="color: blue">Feb</span></month>
...
<month type="<span style="color: blue">11</span>"><span style="color: blue">Nov</span></month>
<month type="<span style="color: blue">12</span>"><span style="color: blue">Dec</span></month>
</monthWidth>
<monthContext type="<span style="color: blue">stand-alone</span>">
<default type="<span style="color: blue">wide</span>"/>
<monthWidth type="<span style="color: blue">wide</span>">
<month type="<span style="color: blue">1</span>"><span style="color: blue">Januaria</span></month>
<month type="<span style="color: blue">2</span>"><span style="color: blue">Februaria</span></month>
...
<month type="<span style="color: blue">11</span>"><span style="color: blue">Novembria</span></month>
<month type="<span style="color: blue">12</span>"><span style="color: blue">Decembria</span></month>
</monthWidth>
<monthWidth type="<span style="color: blue">narrow</span>">
<month type="<span style="color: blue">1</span>"><span style="color: blue">J</span></month>
<month type="<span style="color: blue">2</span>"><span style="color: blue">F</span></month>
...
<month type="<span style="color: blue">11</span>"><span style="color: blue">N</span></month>
<month type="<span style="color: blue">12</span>"><span style="color: blue">D</span></month>
</monthWidth>
</monthContext>
</months>
<days>
<default type="<span style="color: blue">format</span>"/>
<dayContext type="<span style="color: blue">format</span>">
<default type="<span style="color: blue">wide</span>"/>
<dayWidth type="<span style="color: blue">wide</span>">
<day type="<span style="color: blue">sun</span>"><span style="color: blue">Sunday</span></day>
<day type="<span style="color: blue">mon</span>"><span style="color: blue">Monday</span></day>
...
<day type="<span style="color: blue">fri</span>"><span style="color: blue">Friday</span></day>
<day type="<span style="color: blue">sat</span>"><span style="color: blue">Saturday</span></day>
</dayWidth>
<dayWidth type="<span style="color: blue">abbreviated</span>">
<day type="<span style="color: blue">sun</span>"><span style="color: blue">Sun</span></day>
<day type="<span style="color: blue">mon</span>"><span style="color: blue">Mon</span></day>
...
<day type="<span style="color: blue">fri</span>"><span style="color: blue">Fri</span></day>
<day type="<span style="color: blue">sat</span>"><span style="color: blue">Sat</span></day>
</dayWidth>
<dayWidth type="<span style="color: blue">narrow</span>">
<day type="<span style="color: blue">sun</span>"><span style="color: blue">Su</span></day>
<day type="<span style="color: blue">mon</span>"><span style="color: blue">M</span></day>
...
<day type="<span style="color: blue">fri</span>"><span style="color: blue">F</span></day>
<day type="<span style="color: blue">sat</span>"><span style="color: blue">Sa</span></day>
</dayWidth>
</dayContext>
<dayContext type="<span style="color: blue">stand-alone</span>">
<dayWidth type="<span style="color: blue">narrow</span>">
<day type="<span style="color: blue">sun</span>"><span style="color: blue">S</span></day>
<day type="<span style="color: blue">mon</span>"><span style="color: blue">M</span></day>
...
<day type="<span style="color: blue">fri</span>"><span style="color: blue">F</span></day>
<day type="<span style="color: blue">sat</span>"><span style="color: blue">S</span></day>
</dayWidth>
</dayContext>
</days>
<quarters>
<default type="<span style="color: blue">format</span>"/>
<quarterContext type="<span style="color: blue">format</span>">
<default type="<span style="color: blue">abbreviated</span>"/>
<quarterWidth type="<span style="color: blue">abbreviated</span>">
<quarter type="<span style="color: blue">1</span>"><span style="color: blue">Q1</span></quarter>
<quarter type="<span style="color: blue">2</span>"><span style="color: blue">Q2</span></quarter>
<quarter type="<span style="color: blue">3</span>"><span style="color: blue">Q3</span></quarter>
<quarter type="<span style="color: blue">4</span>"><span style="color: blue">Q4</span></quarter>
</quarterWidth>
<quarterWidth type="<span style="color: blue">wide</span>">
<quarter type="<span style="color: blue">1</span>"><span style="color: blue">1st quarter</span></quarter>
<quarter type="<span style="color: blue">2</span>"><span style="color: blue">2nd quarter</span></quarter>
<quarter type="<span style="color: blue">3</span>"><span style="color: blue">3rd quarter</span></quarter>
<quarter type="<span style="color: blue">4</span>"><span style="color: blue">4th quarter</span></quarter>
</quarterWidth>
</quarterContext>
</quarters>
<am><span style="color: blue">AM</span></am>
<pm><span style="color: blue">PM</span></pm>
<eras>
<eraAbbr>
<era type="<span style="color: blue">0</span>"><span style="color: blue">BC</span></era>
<era type="<span style="color: blue">1</span>"><span style="color: blue">AD</span></era>
</eraAbbr>
<eraNames>
<era type="<span style="color: blue">0</span>"><span style="color: blue">Before Christ</span></era>
<era type="<span style="color: blue">1</span>"><span style="color: blue">Anno Domini</span></era>
</eraNames>
<eraNarrow>
<era type="<span style="color: blue">0</span>"><span style="color: blue">B</span></era>
<era type="<span style="color: blue">1</span>"><span style="color: blue">A</span></era>
</eraNarrow>
</eras></pre>
<p><a name="dateFormats"><dateFormats></a></p>
<p><span class="dtd">
<!ELEMENT dateFormats (alias | (default*, dateFormatLength*, special*)) ><br>
<!ELEMENT dateFormatLength (alias | (default*, dateFormat*, special*)) ><br>
<!ATTLIST dateFormatLength type ( full | long | medium | short ) #REQUIRED ><br>
<!ELEMENT dateFormat (alias | (pattern*, displayName*, special*)) >
</span></p>
<p>Date formats have the following form:</p>
<pre> <dateFormats>
<default type=”<span style="color: blue">medium</span>”/>
<dateFormatLength type=”<span style="color: blue">full</span>”>
<dateFormat>
<pattern><span style="color: blue">EEEE, MMMM d, yyyy</span></pattern>
</dateFormat>
</dateFormatLength>
<dateFormatLength type="<span style="color: blue">medium</span>">
<default type="<span style="color: blue">DateFormatsKey2</span>">
<dateFormat type="<span style="color: blue">DateFormatsKey2</span>">
<pattern><span style="color: blue">MMM d, yyyy</span></pattern>
</dateFormat>
<dateFormat type="<span style="color: blue">DateFormatsKey3</span>">
<pattern><span style="color: blue">MMM dd, yyyy</span></pattern>
</dateFormat>
</dateFormatLength>
<dateFormats></pre>
<p> The patterns for date formats and time formats are
defined in <i>
<a href="#Date_Format_Patterns">Appendix F: Date Format Patterns</a>.</i></p>
<p><a name="timeFormats"><timeFormats></a></p>
<p><span class="dtd">
<!ELEMENT timeFormats (alias | (default*, timeFormatLength*, special*)) ><br>
<!ELEMENT timeFormatLength (alias | (default*, timeFormat*, special*)) ><br>
<!ATTLIST timeFormatLength type ( full | long | medium | short ) #REQUIRED ><br>
<!ELEMENT timeFormat (alias | (pattern*, displayName*, special*)) >
</span></p>
<p>Time formats have the following form:</p>
<pre> <timeFormats>
<default type="<span style="color: blue">medium</span>"/>
<timeFormatLength type=”<span style="color: blue">full</span>”>
<timeFormat>
<displayName><span style="color: blue">DIN 5008 (EN 28601)</span></displayName>
<pattern><span style="color: blue">h:mm:ss a z</span></pattern>
</timeFormat>
</timeFormatLength>
<timeFormatLength type="<span style="color: blue">medium</span>">
<timeFormat>
<pattern><span style="color: blue">h:mm:ss a</span></pattern>
</timeFormat>
</timeFormatLength>
</timeFormats></pre>
<p>The preference of 12 hour versus 24 hour for the locale should be derived from the short timeFormat. If the hour symbol is "h" or "K" (of various lengths) then
the format is 12 hour; otherwise it is 24 hour.</p>
<p>Time formats use the specific non-location format (z or zzzz) for the time zone name. This
is the format that should be used when formatting a specific time for presentation.
When formatting a time referring to a recurring time (such as a meeting in a calendar),
applications should substitute the generic non-location format (v or vvvv) for the time zone in the time format pattern.
See <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i> for a complete description of available time zone formats and their uses.</p>
<p>Date/Time formats have the following form:</p>
<pre> <dateTimeFormats>
<default type="<span style="color: blue">medium</span>"/>
<dateTimeFormatLength type=”<span style="color: blue">full</span>”>
<dateTimeFormat>
<pattern><span style="color: blue">{0} {1}</span></pattern>
</dateTimeFormat>
</dateTimeFormatLength>
<availableFormats>
<dateFormatItem id="Hm"><span style="color: blue">HH:mm</span></dateFormatItem>
<dateFormatItem id="Hms"><span style="color: blue">HH:mm:ss</span></dateFormatItem>
<dateFormatItem id="M"><span style="color: blue">L</span></dateFormatItem>
<dateFormatItem id="MEd"><span style="color: blue">E, M/d</span></dateFormatItem>
<dateFormatItem id="MMM"><span style="color: blue">LLL</span></dateFormatItem>
<dateFormatItem id="MMMEd"><span style="color: blue">E, MMM d</span></dateFormatItem>
<dateFormatItem id="MMMMEd"><span style="color: blue">E, MMMM d</span></dateFormatItem>
<dateFormatItem id="MMMMd"><span style="color: blue">MMMM d</span></dateFormatItem>
<dateFormatItem id="MMMd"><span style="color: blue">MMM d</span></dateFormatItem>
<dateFormatItem id="Md"><span style="color: blue">M/d</span></dateFormatItem>
<dateFormatItem id="d"><span style="color: blue">d</span></dateFormatItem>
<dateFormatItem id="hm"><span style="color: blue">h:mm a</span></dateFormatItem>
<dateFormatItem id="ms"><span style="color: blue">mm:ss</span></dateFormatItem>
<dateFormatItem id="y"><span style="color: blue">yyyy</span></dateFormatItem>
<dateFormatItem id="yM"><span style="color: blue">M/yyyy</span></dateFormatItem>
<dateFormatItem id="yMEd"><span style="color: blue">EEE, M/d/yyyy</span></dateFormatItem>
<dateFormatItem id="yMMM"><span style="color: blue">MMM yyyy</span></dateFormatItem>
<dateFormatItem id="yMMMEd"><span style="color: blue">EEE, MMM d, yyyy</span></dateFormatItem>
<dateFormatItem id="yMMMM"><span style="color: blue">MMMM yyyy</span></dateFormatItem>
<dateFormatItem id="yQ"><span style="color: blue">Q yyyy</span></dateFormatItem>
<dateFormatItem id="yQQQ"><span style="color: blue">QQQ yyyy</span></dateFormatItem>
. . .
</availableFormats>
<appendItems>
<appendItem request="<span style="color: blue">G</span>"><span style="color: blue">{0} {1}</span></appendItem>
<appendItem request="<span style="color: blue">w</span>"><span style="color: blue">{0} ({2}: {1})</span></appendItem>
. . .
</appendItems>
</dateTimeFormats></pre>
<pre> </calendar>
<calendar type="<span style="color: blue">buddhist</span>">
<eras>
<eraAbbr>
<era type="<span style="color: blue">0</span>"><span style="color: blue">BE</span></era>
</eraAbbr>
</eras>
</calendar></pre>
<p><a name="dateTimeFormats"><dateTimeFormats></a></p>
<p>These formats allow for date and time formats to be composed in various ways.</p>
<p><span class="dtd">
<!ELEMENT dateTimeFormats (alias | (default*, dateTimeFormatLength*, availableFormats*, appendItems*, intervalFormats*, special*)) ><br>
<!ELEMENT dateTimeFormatLength (alias | (default*, dateTimeFormat*, special*))><br>
<!ATTLIST dateTimeFormatLength type ( full | long | medium | short ) #IMPLIED ><br>
<!ELEMENT dateTimeFormat (alias | (pattern*, displayName*, special*))>
</span></p>
<p>The dateTimeFormat element works like the dateFormats and timeFormats, except
that the pattern is of the form "{1} {0}", where {0} is replaced by the time format, and {1} is replaced by the date format, with results such as "8/27/06 7:31
AM".</p>
<p><span class="dtd">
<!ELEMENT availableFormats (alias | (dateFormatItem*, special*))><br>
<!ELEMENT dateFormatItem ( #PCDATA ) ><br>
<!ATTLIST dateFormatItem id CDATA #REQUIRED >
</span></p>
<p>The availableFormats element and its subelements provide a more flexible formatting mechanism than the predefined list of patterns represented by dateFormatLength,
timeFormatLength, and dateTimeFormatLength. Instead, there is an open-ended list of patterns (represented by dateFormatItem elements as well as the predefined
patterns mentioned above) that can be matched against a requested set of calendar fields and field lengths. Software can look through the list and find the
pattern that best matches the original request, based on the desired calendar fields and lengths. For example, the full month and year may be needed for a calendar
application; the request is MMMMyyyy, but the best match may be "yyyy MMMM" or even "G yy MMMM", depending on the locale and calendar.</p>
<p>For some calendars, such as Japanese, a displayed year must have an associated era, so for these calendars dateFormatItem patterns with a year field should also include an era field.
When matching availableFormats patterns: If a client requests a format string containing a year, and all the availableFormats patterns with a year also contain an era,
then include the era as part of the result.</p>
<p>The id attribute is a so-called "skeleton", containing only field information, and in a canonical order. Examples are "yyyyMMMM" for year + full month, or
"MMMd" for abbreviated month + day. In
particular:</p>
<ul>
<li>The fields are from the
<a href="#Date_Field_Symbol_Table">Date Field Symbol Table</a> in <i>
<a href="#Date_Format_Patterns">Appendix F: Date Format Patterns</a></i>.</li>
<li>The canonical order is from top to bottom in
that table; that is, "yM" not "My".</li>
<li>Only one field of each type is allowed; that
is "Hh" is not valid.</li>
<li>The 'a' field is not allowed in the
skeleton.</li>
</ul>
<p><span class="dtd">
<!ELEMENT appendItems (alias | (appendItem*, special*))><br>
<!ELEMENT appendItem ( #PCDATA ) ><br>
<!ATTLIST appendItem request CDATA >
</span></p>
<p>In case the best match does not include all the requested calendar fields, the appendItems element describes how to append needed fields to one of the existing
formats. Each appendItem element covers a single calendar field. In the pattern, {0} represents the format string, {1} the data content of the field, and {2}
the display name of the field (see <a href="#Calendar_Fields">Calendar Fields</a>). </p>
<p><span class="dtd"><!ELEMENT intervalFormats (alias | (intervalFormatFallback*, intervalFormatItem*, special*)) ><br>
<br>
<!ELEMENT intervalFormatFallback ( #PCDATA ) ><br>
<br>
<!ELEMENT intervalFormatItem (alias | (greatestDifference*, special*)) ><br>
<!ATTLIST intervalFormatItem id NMTOKEN #REQUIRED ><br>
<br>
<!ELEMENT greatestDifference ( #PCDATA ) ><br>
<!ATTLIST greatestDifference id NMTOKEN #REQUIRED > </span></p>
<p>Interval formats allow for software to format
intervals like "Jan 10-12, 2008" as a shorter and more natural format than
"Jan 10, 2008 - Jan 12, 2008". They are designed to take a "skeleton"
pattern (like the one used in availableFormats) plus start and end datetime,
and use that information to produce a localized format.<br>
<br>
The data supplied in CLDR requires the software to determine the calendar field with
the greatest difference before using the format pattern. For example, the
greatest difference in "Jan 10-12, 2008" is the day field, while the
greatest difference in "Jan 10 - Feb 12, 2008" is the month field. This is
used to pick the exact pattern. The pattern is then designed to be broken up
into two pieces by determining the first repeating field. For example, "MMM
d-d, y" would be broken up into "MMM d-" and "d, y". The two parts are
formatted with the first and second datetime, as described in more detail
below.<br>
<br>
In case there is no matching pattern, the intervalFormatFallback defines the
fallback pattern. The fallback pattern is of the form "{0} - {1}" or "{1} -
{0}", where {0} is replaced by the start datetime, and {1} is replaced by
the end datetime. The fallback pattern determines the default order of the
interval pattern. "{0} - {1}" means the first part of the interval patterns
in current local are formatted with the start datetime, while "{1} - {0}"
means the first part of the interval patterns in current locale are formatted
with the end datetime. <br>
<br>
The id attribute of intervalFormatItem is the "skeleton" pattern (like the
one used in availableFormats) on which the format pattern is based.
The id attribute of greatestDifference is the calendar field letter, for
example 'M', which is the greatest difference between start and end datetime.<br>
<br>
The greatest difference defines a specific interval pattern of start and end
datetime on a "skeleton" and a greatestDifference. As stated above, the
interval pattern is designed to be broken up into two pieces. Each piece is
similar to the pattern defined in date format. Also, each interval pattern
could override the default order defined in fallback pattern. If an interval
pattern starts with "latestFirst:", the first part of this particular
interval pattern is formatted with the end datetime. If an interval pattern
starts with "earliestFirst:", the first part of this particular interval
pattern is formatted with the start datetime. Otherwise, the order is the
same as the order defined in intervalFormatFallback.<br>
<br>
For example, the English rules that produce "Jan 10–12, 2008", "Jan 10 – Feb
12, 2008", and "Jan 10, 2008 – Feb. 12, 2009" are as follows:</p>
<p class="example"><intervalFormatItem id="yMMMd"><br>
<greatestDifference id="M">MMM d – MMM d, yyyy</greatestDifference><br>
<greatestDifference id="d">MMM d–d, yyyy</greatestDifference><br>
<greatestDifference id="y">MMM d, yyyy – MMM d, yyyy</greatestDifference><br>
</intervalFormatItem></p>
<p>To format a start and end datetime, given a
particular "skeleton":</p>
<ol>
<li>Look for the intervalFormatItem element that
matches the "skeleton", starting in the current locale and then following
the locale fallback chain up to, but not including root (better results are obtained by following steps 2-6 below
with locale- or language- specific data than by using matching intervalFormats from root).</li>
<li>If no match was found from the previous
step, check what the closest match is in the fallback locale chain, as in availableFormats. That is, this allows for adjusting the string value
field's width, including adjusting between "MMM" and "MMMM", and using
different variants of the same field, such as 'v' and 'z'.</li>
<li>If a match is found from previous steps,
compute the calendar field with the greatest difference between start and
end datetime. If there is no difference among any of the fields in the
pattern, format as a single date using availableFormats, and return.</li>
<li>Otherwise, look for greatestDifference
element that matches this particular greatest difference.</li>
<li>If there is a match, use the pieces of the
corresponding pattern to format the start and end datetime, as above.</li>
<li>Otherwise, format the start and end datetime
using the fallback pattern.</li>
</ol>
<p><a name="week"><week></a></p>
<p><span class="dtd"><!ELEMENT week (alias | (minDays?, firstDay?, weekendStart?, weekendEnd?, special*))></span></p>
<p class="note">The week element is deprecated in the main LDML files, because the data is more appropriately organized as connected to territories, not to
linguistic data. Instead, the similar element in the supplemental data file should be used.</p>
<p class="note"><a name="Calendar_Fields">Calendar Fields</a></p>
<p><span class="dtd"><!ELEMENT fields ( alias | (field*, special*)) ><br>
<!ELEMENT field ( alias | (displayName?, relative*, special*)) ></span></p>
<p>Translations may be supplied for names of calendar fields (elements of a calendar, such as Day, Month, Year, Hour,
and so on), and for relative values for those
fields (for example, the day with
relative value -1 is "Yesterday"). Where there is not a convenient, customary word or phrase in a particular language for a relative value, it should be omitted.</p>
<p>Here are examples for English and German. Notice that the German has more fields than the English does.</p>
<pre><calendar>
<fields>
...
<field type='day'>
<displayName>Day</displayName>
<relative type='-1'>Yesterday</relative>
<relative type='0'>Today</relative>
<relative type='1'>Tomorrow</relative>
</field>
...
</fields>
</calendars></pre>
<pre><calendar>
<fields>
...
<field type='day'>
<displayName>Tag</displayName>
<relative type='-2'>Vorgestern</relative>
<relative type='-1'>Gestern</relative>
<relative type='0'>Heute</relative>
<relative type='1'>Morgen</relative>
<relative type='2'>Übermorgen</relative>
</field>
...
</fields>
</calendars></pre>
<p><span class="dtd"><!ELEMENT dateRangePattern ( #PCDATA ) ></span></p>
<p>The dateRangePattern allows the specification of a date range, such as "May 7 - Aug. 3". For
example, here is the format for English:</p>
<pre><dateRangePattern>{0} - {1}</dateRangePattern></pre>
<h4>5.9.2 <a name="Timezone_Names">Time Zone Names</a></h4>
<p><span class="dtd"><!ELEMENT timeZoneNames (alias | (hourFormat*, hoursFormat*, gmtFormat*,
gmtZeroFormat*, </span>regionFormat*, fallbackFormat*, abbreviationFallback*, preferenceOrdering*,
singleCountries*, default*, zone*, metazone*, special*)) ><br>
<!ELEMENT zone (alias | ( long*, short*, commonlyUsed*, exemplarCity*, special*)) ></p>
<p>The time zone IDs (tzid) are language-independent, and follow the <i>TZ
time zone database</i> [<a href="#Olson">Olson</a>] and naming conventions. However, the display names for
those IDs can vary by locale. The generic time is so-called <i>wall-time</i>; what clocks use when they are correctly switched from standard to daylight time
at the mandated time of the year.</p>
<p>Unfortunately, the canonical tzid's (those in zone.tab) are not stable: may change in each release of the <i>TZ</i>
Time Zone database. In CLDR, however,
stability of identifiers is very important. So the canonical IDs in CLDR are kept stable as described in Appendix L: <a href="#Canonical_Form">Canonical Form</a>.</p>
<p>The following is an example of time zone data. Although this is an example of possible data, in most cases only the exemplarCity needs translation. And
that does not even need to be present, if a country only has a single time
zone. As always, the <i>type</i> field for each zone is the identification of that
zone. It is not to be translated.</p>
<pre><zone type="<span style="color: blue">America/Los_Angeles</span>">
<long>
<generic><span style="color: blue">Pacific Time</span></generic>
<standard><span style="color: blue">Pacific Standard Time</span></standard>
<daylight><span style="color: blue">Pacific Daylight Time</span></daylight>
</long>
<short>
<generic><span style="color: blue">PT</span></generic>
<standard><span style="color: blue">PST</span></standard>
<daylight><span style="color: blue">PDT</span></daylight>
</short>
<exemplarCity><span style="color: blue">San Francisco</span></exemplarCity>
</zone>
<zone type="<span style="color: blue">Europe/London</span>">
<long>
<generic><span style="color: blue">British Time</span></generic>
<standard><span style="color: blue">British Standard Time</span></standard>
<daylight><span style="color: blue">British Daylight Time</span></daylight>
</long>
<exemplarCity><span style="color: blue">York</span></exemplarCity>
</zone></pre>
<p>In a few cases, some time zone IDs do not designate a city, as in:</p>
<pre><zone type="<span style="color: blue">America/Puerto_Rico</span>">
...
</zone>
<zone type="<span style="color: blue">America/Guyana</span>">
...
</zone>
<zone type="<span style="color: blue">America/Cayman</span>">
...
</zone>
<zone type="<span style="color: blue">America/St_Vincent</span>">
...
</zone></pre>
<p>They may designate countries or territories;
their actual capital city may be a name that is too common, or, too
uncommon. CLDR time zone IDs follow the <a href="#Olson">Olson</a> naming conventions.</p>
<blockquote>
<p class="note"><b>Note: </b>CLDR does not allow "GMT", "UT", or "UTC" as translations (short or long) of time zones other than
GMT itself.</p>
</blockquote>
<blockquote>
<p class="note"><b>Note: </b>Transmitting "14:30" with no other context is incomplete unless it contains information about the time zone. Ideally one would
transmit neutral-format date/time information, commonly in UTC (GMT), and localize as close to the user as possible. (For more about UTC, see [<a href="#UTCInfo">UTCInfo</a>].)</p>
</blockquote>
<p class="note">The conversion from local time into UTC depends on the particular time zone rules, which will vary by location. The standard data used for converting
local time (sometimes called <i>wall time</i>) to UTC and back is the <i>TZ Data</i> [<a href="#Olson">Olson</a>], used by Linux, UNIX, Java, ICU, and others.
The data includes rules for matching the laws for time changes in different countries. For example, for the US it is:</p>
<blockquote>
<p class="note">"During the period commencing at 2 o'clock antemeridian on the first Sunday of April of each year and ending at 2 o'clock antemeridian on
the last Sunday of October of each year, the standard time of each zone established by sections 261 to 264 of this title, as modified by section 265 of
this title, shall be advanced one hour..." (United States Law - 15 U.S.C. §6(IX)(260-7)).</p>
</blockquote>
<p class="note">Each region that has a different time zone or daylight savings time rules, either now or at any time back to 1970, is given a unique internal
ID, such as <code>Europe/Paris</code>. (Some IDs are also distinguished on the basis of differences before 1970.) As with currency codes, these are internal
codes. A localized string associated with these is provided for users (such as in the Windows<i> Control Panels>Date/Time>Time Zone</i>).</p>
<p class="note">Unfortunately, laws change over time, and will continue to change in the future, both for the boundaries of time
zone regions and the rules for
daylight savings. Thus the <i>TZ</i> data is continually being augmented. Any two implementations using the same version of the <i>TZ</i> data will get the
same results for the same IDs (assuming a correct implementation). However, if implementations use different versions of the data they may get different results.
So if precise results are required then both the <i>TZ</i> ID and the <i>TZ</i> data version must be transmitted between the different implementations.</p>
<p class="note">For more information, see [<a href="#DataFormats">Data Formats</a>].</p>
<p>The following subelements of time zoneNames are used to control the fallback process described in <a href="#Time_Zone_Fallback">Appendix J: Time Zone Display
Names</a>.</p>
<table cellspacing="0" cellpadding="4" border="1">
<tr>
<th>Element Name</th>
<th>Data Examples</th>
<th>Results/Comment</th>
</tr>
<tr>
<td rowspan="2">hourFormat</td>
<td rowspan="2">"+HHmm;-HHmm"</td>
<td>"+1200"</td>
</tr>
<tr>
<td>"-1200"</td>
</tr>
<tr>
<td>hoursFormat</td>
<td>"{0}/{1}"</td>
<td>"-0800/-0700"</td>
</tr>
<tr>
<td rowspan="2">gmtFormat</td>
<td>"GMT{0}"</td>
<td>"GMT-0800"</td>
</tr>
<tr>
<td>"{0}ВпГ"</td>
<td>"-0800ВпГ"</td>
</tr>
<tr>
<td>gmtZeroFormat</td>
<td>"GMT"</td>
<td>Specifies how GMT/UTC with no explicit offset (implied 0
offset) should be represented.</td>
</tr>
<tr>
<td rowspan="2">regionFormat</td>
<td>"{0} Time"</td>
<td>"Japan Time"</td>
</tr>
<tr>
<td>"Tiempo de {0}"</td>
<td>"Tiempo de Japón"</td>
</tr>
<tr>
<td rowspan="2">fallbackFormat</td>
<td>"{1} ({0})"</td>
<td>"Japan (Tokyo) Time"</td>
</tr>
<tr>
<td>"{1}（{0}）" [fullwidth parentheses]</td>
<td>"Tiempo de Japón （Tokyo） Time"</td>
</tr>
<tr>
<td>abbreviationFallback</td>
<td>type="GMT"</td>
<td>causes any "long" match to be skipped in Time Zone fallbacks</td>
</tr>
<tr>
<td>preferenceOrdering</td>
<td>type="America/Mexico_City America/Chihuahua America/New_York"</td>
<td>a preference ordering among modern zones (deprecated)</td>
</tr>
<tr>
<td>singleCountries</td>
<td>list="America/Godthab America/Santiago America/Guayaquil Europe/Madrid Pacific/Auckland Pacific/Tahiti Europe/Lisbon..."</td>
<td>uses country name alone</td>
</tr>
</table>
<p>When referring to the abbreviated (short) form of the time zone
name, there are often situations where the location-based (city or country) time zone
designation for a particular
language may not be in common usage in a particular territory. The commonlyUsed attribute
is to designate which time zone or metazone terms are in common usage and can be displayed when formatting dates. </p>
<h4>Section 5.9.2.1 Metazones </h4>
<p>A metazone is an grouping of one or more internal TZIDs that
share a common display name in current customary usage, or that have shared a common display name during some particular
time period. For example, the zones <i>Europe/Paris, Europe/Andorra, Europe/Tirane, Europe/Vienna,
Europe/Sarajevo, Europe/Brussels, Europe/Zurich, Europe/Prague, Europe/Berlin</i>, and so on are
often simply designated <i>Central European Time</i> (or translated equivalent).<br>
</p>
<p>A metazone's display fields become a secondary fallback if an appropriate data field
cannot be found in the explicit time zone data. The <i>usesMetazone</i> field indicates that the
target metazone is active for a particular time. This also provides a mechanism to effectively deal
with situations where the time zone in use has changed for some reason. For example, consider
the TZID "America/Indiana/Knox", which observed Central time (GMT-6:00) prior to October 27,
1991, and has currently observed Central time since April 2, 2006, but has observed Eastern time
( GMT-5:00 ) between these two dates. This is denoted as follows (in
the supplemental data file
<a href="http://unicode.org/cldr/data/common/supplemental/metazoneInfo.xml">metazoneInfo.xml</a>—in previous versions they were in root.xml).</p>
<pre><timezone type="America/Indiana/Knox">
<usesMetazone to="1991-10-27 07:00" mzone="America_Central"/>
<usesMetazone to="2006-04-02 07:00" from="1991-10-27 07:00" mzone="America_Eastern"/>
<usesMetazone from="2006-04-02 07:00" mzone="America_Central"/>
</timezone></pre>
<p>Note that the dates and times are specified in UTC, not local time.</p>
<p>The metazones can then have translations in different locale files,
such as the following.</p>
<pre><metazone type="America_Central">
<long>
<generic>Central Time</generic>
<standard>Central Standard Time</standard>
<daylight>Central Daylight Time</daylight>
</long>
<short>
<generic>CT</generic>
<standard>CST</standard>
<daylight>CDT</daylight>
</short>
</metazone>
<metazone type="America_Eastern">
<long>
<generic>Eastern Time</generic>
<standard>Eastern Standard Time</standard>
<daylight>Eastern Daylight Time</daylight>
</long>
<short>
<generic>ET</generic>
<standard>EST</standard>
<daylight>EDT</daylight>
</short>
</metazone></pre>
<pre><metazone type="America_Eastern">
<long>
<generic>Heure de l’Est</generic>
<standard>Heure normale de l’Est</standard>
<daylight>Heure avancée de l’Est</daylight>
</long>
<short>
<generic>HE</generic>
<standard>HNE</standard>
<daylight>HAE</daylight>
</short>
</metazone></pre>
<p>When formatting a date and time value using this data, an
application can properly be able to display "Eastern Time" for dates between 1991-10-27 and
2006-04-02, but display "Central Time" for current dates. (See
also <i>Section 5.2.1 <a href="#Date_Ranges">Dates and Date Ranges</a></i>).</p>
<p>Metazones are used with the 'z', 'zzzz', 'v', 'vvvv', and 'V'
date time pattern characters, and not with the 'Z', 'ZZZZ', 'VVVV'
pattern characters. For more information, see Appendix F: <a href="#Date_Format_Patterns">Date Format Patterns</a>.</p>
<h3>5.10 <a name="Number_Elements">Number Elements</a></h3>
<p><span class="dtd"><!ELEMENT numbers (alias | (symbols?, decimalFormats?, scientificFormats?, percentFormats?, currencyFormats?, currencies?, special*)) ></span></p>
<p>The numbers element supplies information for formatting and parsing numbers and currencies. It has the following sub-elements: <symbols>, <decimalFormats>,
<scientificFormats>, <percentFormats>, <currencyFormats>, and <currencies>. The currency IDs are from [<a href="#ISO4217">ISO4217</a>] (plus some additional
common-use codes). For more information, including the pattern structure, see <i><a href="#Number_Format_Patterns">Appendix G: Number Pattern Format</a></i>.</p>
<p><span class="dtd"><!ELEMENT defaultNumberingSystem ( #PCDATA
) ><br>
</span>This element indicates which numbering system should be used for
presentation of numeric quantities in the given locale. For more information
on numbering systems and their definitions, see <i>Section
C.13 <a href="#Numbering_Systems">Numbering Systems</a></i>. </p>
<h4>5.10.1 <a name="Number_Symbols">Number Symbols</a></h4>
<p><span class="dtd"><!ELEMENT symbols (alias | (decimal*, group*, list*,
percentSign*, nativeZeroDigit*, patternDigit*,
plusSign*, minusSign*, exponential*,
perMille*, infinity*, nan*, currencyDecimal*, currencyGroup*, special*)) ></span></p>
<pre><symbols>
<decimal><span style="color: blue">.</span></decimal>
<group><span style="color: blue">,</span></group>
<list><span style="color: blue">;</span></list>
<percentSign><span style="color: blue">%</span></percentSign>
<nativeZeroDigit><span style="color: blue">0</span></nativeZeroDigit>
<patternDigit><span style="color: blue">#</span></patternDigit>
<plusSign><span style="color: blue">+</span></plusSign>
<minusSign><span style="color: blue">-</span></minusSign>
<exponential><span style="color: blue">E</span></exponential>
<perMille><span style="color: blue">‰</span></perMille>
<infinity><span style="color: blue">∞</span></infinity>
<nan><span style="color: blue">☹</span></nan>
</symbols></pre>
<p><span class="dtd"><!ELEMENT decimalFormats (alias | (default*, decimalFormatLength*, special*))><br>
<!ELEMENT decimalFormatLength (alias | (default*, decimalFormat*, special*))><br>
<!ATTLIST decimalFormatLength type ( full | long | medium | short ) #IMPLIED ><br>
<!ELEMENT decimalFormat (alias | (pattern*, special*)) ><br>
</span>(scientificFormats, percentFormats have the same structure)</p>
<pre><decimalFormats>
<decimalFormatLength type="<span style="color: blue">long</span>">
<decimalFormat>
<pattern><span style="color: blue">#,##0.###</span></pattern>
</decimalFormat>
</decimalFormatLength>
</decimalFormats></pre>
<pre><scientificFormats>
<default type="<span style="color: blue">long</span>"/>
<scientificFormatLength type="<span style="color: blue">long</span>">
<scientificFormat>
<pattern><span style="color: blue">0.000###E+00</span></pattern>
</scientificFormat>
</scientificFormatLength>
<scientificFormatLength type="<span style="color: blue">medium</span>">
<scientificFormat>
<pattern><span style="color: blue">0.00##E+00</span></pattern>
</scientificFormat>
</scientificFormatLength>
</scientificFormats></pre>
<pre><percentFormats>
<percentFormatLength type="<span style="color: blue">long</span>">
<percentFormat>
<pattern><span style="color: blue">#,##0%</span></pattern>
</percentFormat>
</percentFormatLength>
</percentFormats></pre>
<p><span class="dtd">
<!ELEMENT currencyFormats (alias | (default*, currencySpacing*, currencyFormatLength*, unitPattern*, special*)) ><br>
<!ELEMENT currencySpacing (alias | (beforeCurrency*, afterCurrency*, special*)) ><br>
<!ELEMENT beforeCurrency (alias | (currencyMatch*, surroundingMatch*, insertBetween*)) ><br>
<!ELEMENT afterCurrency (alias | (currencyMatch*, surroundingMatch*, insertBetween*)) ><br>
<!ELEMENT currencyMatch ( #PCDATA ) ><br>
<!ELEMENT surroundingMatch ( #PCDATA )) ><br>
<!ELEMENT insertBetween ( #PCDATA ) ><br>
<!ELEMENT currencyFormatLength (alias | (default*, currencyFormat*, special*)) ><br>
<!ATTLIST currencyFormatLength type ( full | long | medium | short ) #IMPLIED ><br>
<!ELEMENT currencyFormat (alias | (pattern*, special*)) >
</span></p>
<pre><currencyFormats>
<currencyFormatLength type="<span style="color: blue">long</span>">
<currencyFormat>
<pattern><span style="color: blue">¤ #,##0.00;(¤ #,##0.00)</span></pattern>
</currencyFormat>
</currencyFormatLength>
</currencyFormats></pre>
<h4>5.10.2 <a name="Currencies">Currencies</a></h4>
<p><span class="dtd">
<!ELEMENT currencies (alias | (default?, currency*, special*)) ><br>
<!ELEMENT currency (alias | (((pattern+, displayName*, symbol*) | (displayName+, symbol*, pattern*) | (symbol+, pattern*))?,
decimal*, group*, special*)) ><br>
<!ELEMENT symbol ( #PCDATA ) ><br>
<!ATTLIST symbol choice ( true | false ) #IMPLIED >
</span></p>
<blockquote>
<p><b>Note:</b> The term "pattern" appears twice in the above. The first is for consistency with all other cases of pattern + displayName; the second is for backwards
compatibility.</p>
</blockquote>
<pre><currencies>
<currency type="<span style="color: blue">USD</span>">
<displayName><span style="color: blue">Dollar</span></displayName>
<symbol><span style="color: blue">$</span></symbol>
</currency>
<currency type ="<span style="color: blue">JPY</span>">
<displayName><span style="color: blue">Yen</span></displayName>
<symbol><span style="color: blue">¥</span></symbol>
</currency>
<currency type ="<span style="color: blue">INR</span>">
<displayName><span style="color: blue">Rupee</span></displayName>
<symbol choice="<span style="color: blue">true</span>"><span style="color: blue">0≤Rf|1≤Ru|1&lt;Rf</span></symbol>
</currency>
<currency type="PTE">
<displayName><span style="color: blue">Escudo</span></displayName>
<symbol><span style="color: blue">$</span></symbol>
</currency>
</currencies></pre>
<p>In formatting currencies, the currency number format is used with the appropriate symbol from <currencies>, according to the currency code. The <currencies>
list can contain codes that are no longer in current use, such as PTE. The choice attribute can be used to indicate that the value uses a pattern interpreted
as in <a href="#Choice_Patterns">Appendix H: Choice Patterns</a>.</p>
<p>The count attribute distinguishes the different
plural forms, such as in the following:</p>
<pre><currencyFormats>
<unitPattern count="other">{0} {1}</unitPattern>
...
<currencies></pre>
<pre><currency type="ZWD">
<displayName>Zimbabwe Dollar</displayName>
<displayName count="one">Zimbabwe dollar</displayName>
<displayName count="other">Zimbabwe dollars</displayName>
<symbol>Z$</symbol>
</currency></pre>
<p>To format a particular currency value "ZWD" for a particular numeric value <em>n</em>:</p>
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">First determine the count value that corresponds to <em>n</em> using the rules in
<i>Appendix C.11 <a href="#Language_Plural_Rules">Language Plural Rules</a></i></li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Next,
get the currency unitPattern.<ol>
<li>Look for a unitPattern element that matches the count value, starting in the current
locale and then following the locale fallback chain up to, but not including root.</li>
<li>If no matching unitPattern element was found in the previous step, then look for a unitPattern element that matches
count="other", starting in the current locale and then following the locale fallback chain up to root
(which has a unitPattern element with count="other" for every unit type).</li>
<li>The resulting unitPattern element indicates the appropriate
positioning of the numeric value and the currency display name.</li>
</ol>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Next,
get the displayName element for the currency.<ol>
<li>Look for a displayName element that matches the count value, starting in the current
locale and then following the locale fallback chain up to, but not including root.</li>
<li>If no matching displayName element was found in the previous step, then look for a
displayName element that matches
count="other", starting in the current locale and then following the locale fallback chain up
to, but not including root.</li>
<li>If no matching displayName element was found in the previous step, then look for a
displayName element that with no count, starting in the current locale and then following the locale fallback chain up to root.</li>
<li>If there is no displayName element, use
the currency code itself (for example, "ZWD").</li>
</ol>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
The numeric value, formatted according to the
locale with the number of decimals appropriate for the currency, is
substituted for {0} in the unitPattern, while the currency display name
is substituted for the {1}.</li>
</ol>
<p>While for English this may seem overly complex, for some other languages different plural forms are used for different unit
types; the plural forms for certain unit types may not use all of the plural-form tags defined for the language.</p>
<p>For example, if the the currency is ZWD and the
number is 1234, then the latter maps to count="other" for English. The unit
pattern for that is "{0} {1}", and the display name is "Zimbabwe dollars".
The final formatted number is then "1,234 Zimbabwe dollars".</p>
<p>When the currency symbol is substituted into a pattern, there may be some further modifications, according to the following.</p>
<pre><currencySpacing>
<beforeCurrency>
<currencyMatch>[:letter:]</currencyMatch>
<surroundingMatch>[:digit:]</surroundingMatch>
<insertBetween>&#x00a0;</insertBetween>
</beforeCurrency>
<afterCurrency>
<currencyMatch>[:letter:]</currencyMatch>
<surroundingMatch>[:digit:]</surroundingMatch>
<insertBetween>&#x00a0;</insertBetween>
</afterCurrency>
</currencySpacing>
</pre>
<p>This element controls whether additional characters are inserted on the boundary between the symbol and the pattern. For example,
with the above <i>currencySpacing</i>, inserting
the symbol "US$" into the pattern "#,##0.00¤" would result in an extra <i>no-break space</i> inserted before the symbol,
for example, "#,##0.00 US$".
The <i>beforeCurrency</i> element governs this case, since we are
looking <i>before</i> the "¤" symbol. The <i>currencyMatch</i> is positive, since the "U" in "US$" is
at the start of the currency symbol being substituted. The <i>surroundingMatch</i> is positive, since
the character just before the "¤" will be a digit. Because these
two conditions are true, the insertion is made.</p>
<p>Conversely, look at the
pattern "¤#,##0.00" with the symbol "US$". In this case, there is no insertion; the
result is simply "US$#,##0.00". The <i>afterCurrency</i> element governs this case,
since we are looking <i>after</i> the "¤" symbol. The surroundingMatch is positive, since the
character just after the "¤" will be a digit. However, the currencyMatch is <b>not</b> positive,
since the "$" in "US$" is at the end of the currency symbol being substituted. So the insertion
is not made. </p>
<p>For more information
on the matching used in the currencyMatch and surroundingMatch elements, see <i><a href="#Unicode_Sets">Appendix E: Unicode Sets</a></i>.</p>
<p>Currencies can also contain optional grouping, decimal data, and pattern elements. This data is inherited from the <symbols> in the same locale data (if
not present in the chain up to root), so only the <i>differing</i> data will be present. See <i>Section 4.1 <a href="#Multiple_Inheritance">Multiple Inheritance</a></i>.</p>
<blockquote>
<p class="note"><b>Note: </b><i>Currency values should <b>never</b> be interchanged without a known currency code. You never want the number 3.5 interpreted
as $3.5 by one user and ¥3.5 by another. </i>Locale data contains localization information for currencies, not a currency value for a country. A currency
amount logically consists of a numeric value, plus an accompanying currency code (or equivalent). The currency code may be implicit in a protocol, such
as where USD is implicit. But if the raw numeric value is transmitted without any context, then it has no definitive interpretation.</p>
</blockquote>
<p class="note">Notice that the currency code is completely independent of the end-user's language or locale. For example, RUR is the code for Russian Rubles.
A currency amount of <RUR, 1.23457×10³> would be localized for a Russian user into "1 234,57р." (using U+0440 (р) <span style="FONT-VARIANT: small-caps">cyrillic
small letter er</span>). For an English user it would be localized into the string "Rub 1,234.57" The end-user's language is needed for doing this last localization
step; but that language is completely orthogonal to the currency code needed in the data. After all, the same English user could be working with dozens of currencies.Notice
also that the currency code is also independent of whether currency values are inter-converted, which requires more interesting financial processing: the rate
of conversion may depend on a variety of factors.</p>
<p class="note">Thus logically speaking, once a currency amount is entered into a system, it should be logically accompanied by a currency code in all processing.
This currency code is independent of whatever the user's original locale was. Only in badly-designed software is the currency code (or equivalent) not present,
so that the software has to "guess" at the currency code based on the user's locale.</p>
<blockquote>
<p class="note"><b>Note: </b>The number of decimal places <b>and</b> the rounding for each currency is not locale-specific data, and is not contained in
the Locale Data Markup Language format. Those values override whatever is given in the currency numberFormat. For more information, see <i>
<a href="#Supplemental_Data">Appendix C: Supplemental Data</a></i>.</p>
</blockquote>
<p>For background information on currency names, see [<a href="#CurrencyInfo">CurrencyInfo</a>].</p>
<h3>5.11 <a name="Unit_Elements">Unit Elements</a></h3>
<p><span class="dtd"><!ELEMENT units (alias | (unit*, special*)) ><br>
<!ELEMENT unit (alias | (unitPattern*, special*)) ><br>
<!ATTLIST unit type NMTOKEN #REQUIRED ><br>
<!ELEMENT unitPattern ( #PCDATA ) ><br>
<!ATTLIST unitPattern count (zero | one | two | few | many | other) #REQUIRED ><br>
</span></p>
<p>These elements specify the localized way of formatting quantities of units such as years, months, days, hours, minutes and seconds—
for example, in English, "1 day" or "3 days". The English rules that produce this example are as follows ({0} indicates the position of the
formatted numeric value):</p>
<pre><unit type="day">
<unitPattern count="one"><span style="color: blue">{0} day</span></unitName>
<unitPattern count="other"><span style="color: blue">{0} days</span></unitName>
</unit></pre>
<p>To format a particular unit type such as "day" for a particular numeric value <em>n</em>:</p>
<ol>
<li>First determine the count value that corresponds to <em>n</em> using the rules in
<i>Appendix C.11 <a href="#Language_Plural_Rules">Language Plural Rules</a></i></li>
<li>Next, for unit type="day", look for a unitPattern element that matches the count value, starting in the current
locale and then following the locale fallback chain up to, but not including root.</li>
<li>If no matching unitPattern element was found in the previous step, then look for a unitPattern element that matches
count="other" (still for unit type="day"), starting in the current locale and then following the locale fallback chain up to root
(which has a unitPattern element with count="other" for every unit type).</li>
<li>The resulting unitPattern element indicates the appropriate form of the unit name and its position with respect to the
numeric value.</li>
</ol>
<p>While for English this may seem overly complex, for some other languages different plural forms are used for different unit
types; the plural forms for certain unit types may not use all of the plural-form tags defined for the language.</p>
<h3>5.12 <a name="POSIX_Elements">POSIX Elements</a></h3>
<p><span class="dtd"><!ELEMENT posix (alias | (messages*, special*)) ><br>
<!ELEMENT messages (alias | ( yesstr?, nostr?)) ></span></p>
<p>The following are included for compatibility with POSIX.</p>
<p> <posix><br>
<posix:messages><br>
<posix:yesstr><span style="color: #0000FF">ja</span></posix:yesstr><br>
<posix:nostr><span style="color: #0000FF">nein</span></posix:nostr><br>
</posix:messages><br>
<posix></p>
<ol>
<li>The values for yesstr and nostr contain a colon-separated list of strings that would normally be recognized as "yes" and "no" responses. For cased languages,
this shall include only the lower case version. POSIX locale generation tools must generate the
upper case equivalents, and the abbreviated versions, and
add the English words wherever they do not conflict. Examples:<ul>
<li>ja → ja:Ja:j:J:yes:Yes:y:Y</li>
<li>ja → ja:Ja:j:J:yes:Yes // exclude y:Y if it conflicts with the native "no".</li>
</ul>
</li>
<li>The older elements yesexpr and noexpr are deprecated. They should instead be generated from yesstr and nostr so that they match all the responses.</li>
</ol>
<p>So for English, the appropriate strings and expressions would be as follows:</p>
<p>yesstr "yes:y"<br>
nostr "no:n"</p>
<p>The generated yesexpr and noexpr would be:</p>
<p><code>yesexpr "^([yY]([eE][sS])?)" <br>
</code>This would match y,Y,yes,yeS,yEs,yES,Yes,YeS,YEs,YES.<br>
<br>
<code>noexpr "^([nN][oO]?)"</code><br>
This would match n,N,no,nO,No,NO.</p>
<h3>5.13 <a name="Reference_Elements">Reference Element</a></h3>
<p><!ELEMENT references ( reference* ) ><br>
<!ELEMENT reference ( #PCDATA ) ><br>
<!ATTLIST reference type NMTOKEN #REQUIRED><br>
<!ATTLIST reference standard ( true | false ) #IMPLIED ><br>
<!ATTLIST reference uri CDATA #IMPLIED ></p>
<p>The references section supplies a central location for specifying references and standards. The uri should be supplied if at all possible. If not online,
then a ISBN number should be supplied, such as in the following example:</p>
<p class="example"><reference type="R2" uri="http://www.ur.se/nyhetsjournalistik/3lan.html">Landskoder på Internet</reference><br>
<reference type="R3" uri="URN:ISBN:91-47-04974-X">Svenska skrivregler</reference></p>
<h3>5.14 <a name="Collation_Elements">Collation Elements</a></h3>
<p><span class="dtd"><!ELEMENT collations (alias | (default?, collation*, special*)) ></span></p>
<p>This section contains one or more collation elements, distinguished by type. Each collation contains rules that specify a certain sort-order, as a tailoring
of the UCA table defined in UTS #10: Unicode Collation Algorithm [<a href="#UCA">UCA</a>]. (For a chart view of the UCA, see Collation Chart [<a href="#UCAChart">UCAChart</a>].)
This syntax is an XMLized version of the Java/ICU syntax. For illustration, the rules are accompanied by the corresponding <i>basic</i> <i>ICU rule syntax</i>
[<a href="#ICUCollation">ICUCollation</a>] (used in ICU and Java) and/or the ICU parameterizations, and the basic syntax may be used in examples.</p>
<blockquote>
<p class="note"><b>Note: </b>ICU provides a concise format for specifying orderings, based on tailorings to the UCA. For example, to specify that k and
q follow 'c', one can use the rule: "& c < k < q". The rules also allow people to set default general parameter values, such as whether
upper case is before lower case or not. (Java contains an earlier version of ICU, and has not been updated recently. It does not support any of the basic syntax marked with [...],
and its default table is not the UCA.)</p>
</blockquote>
<p class="note">However, it is <b>not</b> necessary for ICU to be used in the underlying implementation. The features are simply related to the ICU capabilities,
since that supplies more detailed examples.</p>
<blockquote>
<p class="note"><b>Note: </b>there is an on-line demonstration of collation at [<a href="#LocaleExplorer">LocaleExplorer</a>] (pick the locale and scroll
to "Collation Rules").</p>
</blockquote>
<h4>5.14.1 <a name="Collation_Version">Version</a></h4>
<p>The version attribute is used in case a specific version of the UCA is to be specified. It is optional, and is specified if the results are to be identical
on different systems. If it is not supplied, then the version is assumed to be the same as the Unicode version for the system as a whole. In general, tailorings
should be defined so as to minimize dependence on the underlying UCA version, by explicitly specifying the behavior of all characters used to write the language
in question.</p>
<blockquote>
<p><b>Note: </b>For version 3.1.1 of the UCA, the version of Unicode must also be specified with any versioning information; an example would be "3.1.1/3.2"
for version 3.1.1 of the UCA, for version 3.2 of Unicode. This was changed by decision of the UTC,
so that dual versions were no longer necessary. So for UCA 4.0 and beyond, the version just has a single number.</p>
</blockquote>
<h4>5.14.2 <a name="Collation_Element">Collation Element</a></h4>
<p><span class="dtd"><!ELEMENT collation (alias | (base?, settings?, suppress_contractions?, optimize?, rules?, special*)) ></span></p>
<p>Like the ICU rules, the tailoring syntax is designed to be independent of the actual weights used in any particular UCA table. That way the same rules can
be applied to UCA versions over time, even if the underlying weights change. The following describes the overall document structure of a collation:</p>
<p><code><collation><br>
<settings caseLevel="<span style="color: blue">on</span>"/><br>
<rules><br>
<font color="green"> <!-- rules go here --><br>
</font> </rules><br>
</collation></code></p>
<p>The optional base element <code><base><span style="color: blue">...</span></base></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="#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="#Orderings">Orderings</a>.</p>
<h4>5.14.3 <a name="Setting_Options">Setting Options</a></h4>
<p>In XML, these are attributes of <settings>. For example, <setting strength="secondary"> will only compare strings based on their primary and secondary weights.</p>
<p>If the attribute is not present, the default (or for the base url's attribute, if there is one) is used. The default is listed in italics.</p>
<table>
<caption><a name="Collation_Settings">Collation Settings</a></caption>
<tr>
<th>Attribute</th>
<th>Options</th>
<th>Basic Example </th>
<th>XML Example</th>
<th>Description</th>
</tr>
<tr>
<td><font color="#000000">strength</font></td>
<td>primary (1)<br>
secondary (2)<br>
tertiary (3)<br>
quaternary (4)<br>
identical (5)</td>
<td><code>[strength 1]</code></td>
<td><code>strength = "<span style="color: blue">primary</span>"</code></td>
<td>Sets the default strength for comparison, as described in the UCA.</td>
</tr>
<tr>
<td>alternate</td>
<td><i>non-ignorable</i><br>
shifted</td>
<td><code>[alternate non-ignorable]</code></td>
<td><code>alternate = "<span style="color: blue">non-ignorable</span>"</code></td>
<td>Sets alternate handling for variable weights, as described in UCA</td>
</tr>
<tr>
<td>backwards</td>
<td>on<br>
<i>off</i></td>
<td><code>[backwards 2] </code></td>
<td><code>backwards = "<span style="color: blue">on</span>"</code></td>
<td>Sets the comparison for the second level to be backwards ("French"), as described in UCA</td>
</tr>
<tr>
<td>normalization</td>
<td>on<br>
off</td>
<td><code>[normalization on] </code></td>
<td><code>normalization = "<span style="color: blue">off</span>"</code></td>
<td>If <i>on</i>, then the normal UCA algorithm is used. If <i>off</i>, then all strings that are in [<a href="#FCD">FCD</a>] will sort correctly, but
others will not necessarily sort correctly. So should only be set <i>off</i> if the the strings to be compared are in FCD.</td>
</tr>
<tr>
<td>caseLevel</td>
<td>on<br>
off</td>
<td><code>[caseLevel on]</code></td>
<td><code>caseLevel = "<span style="color: blue">off</span>"</code></td>
<td>If set to <i>on,</i> a level consisting only of case characteristics will be inserted in front of tertiary level. To ignore accents but take cases
into account, set strength to primary and case level to <i>on</i>. </td>
</tr>
<tr>
<td>caseFirst</td>
<td>upper<br>
lower<br>
off</td>
<td><code>[caseFirst off]</code></td>
<td><code>caseFirst = "<span style="color: blue">off</span>"</code></td>
<td>If set to <i>upper</i>, causes upper case to sort before lower case. If set to <i>lower</i>, lower case will sort before upper case. Useful for
locales that have already supported ordering but require different order of cases. Affects case and tertiary levels.</td>
</tr>
<tr>
<td>hiraganaQuaternary</td>
<td>on<br>
off</td>
<td><code>[hiraganaQ on]</code></td>
<td><code>hiraganaQuaternary = "<span style="color: blue">on</span>"</code></td>
<td>Controls special treatment of Hiragana code points on quaternary level. If turned <i>on</i>, Hiragana codepoints will get lower values than all
the other non-variable code points. The strength must be greater or equal than quaternary if you want this attribute to take effect.</td>
</tr>
<tr>
<td>numeric</td>
<td>on<br>
off</td>
<td><code>[numeric on]</code></td>
<td><code>numeric = "<span style="color: blue">on</span>"</code></td>
<td>If set to <i>on</i>, any sequence of Decimal Digits (General_Category = Nd in the [<a href="#UCD">UCD</a>]) is sorted at a primary level with its
numeric value. For example, "A-21" < "A-123".</td>
</tr>
<tr>
<td>variableTop</td>
<td><i>uXXuYYYY</i></td>
<td><code>& \u00XX\uYYYY < [variable top]</code></td>
<td><code>variableTop = "uXXuYYYY"</code></td>
<td>The parameter value is an encoded Unicode string, with code points in hex, leading zeros removed, and 'u' inserted between successive elements.<p>
Sets the default value for the variable top. All the code points with primary strengths less than variable top will be considered variable, and thus
affected by the alternate handling.</p>
</td>
</tr>
<tr>
<td>match-boundaries:</td>
<td nowrap>none<br>
whole-character<br>
whole-word</td>
<td>n/a</td>
<td><code>match-boundaries = "whole-word"</code></td>
<td>The meaning is according to the descriptions in UTS #10
<a href="http://unicode.org/reports/tr10/#Searching">Searching</a>.</td>
</tr>
<tr>
<td>match-style</td>
<td>minimal<br>
medial<br>
maximal</td>
<td>n/a</td>
<td><code>match-style = "medial"</code></td>
<td>The meaning is according to the descriptions in UTS #10
<a href="http://unicode.org/reports/tr10/#Searching">Searching</a>.</td>
</tr>
</table>
<h4>5.14.4 <a name="Rules">Collation Rule Syntax</a></h4>
<p><span class="dtd"><!ELEMENT rules (alias | ( reset, ( reset | p | pc | s | sc | t | tc | q | qc | i | ic | x)* )) ></span></p>
<p>The goal for the collation rule syntax is to have clearly expressed rules with a concise format, that parallels the Basic syntax as much as possible.
The rule syntax uses abbreviated element names for primary (level 1), secondary (level 2), tertiary (level 3), and identical, to be as short as possible. The
reason for this is because the tailorings for CJK characters are quite large (tens of thousands of elements), and the extra overhead would have been considerable.
Other elements and attributes do not occur as frequently, and have longer names.</p>
<blockquote>
<p><b>Note: </b>The rules are stated in terms of actions that cause characters to change their ordering relative to other characters. This is for
stability; assigning characters specific weights would not work, since the exact weight assignment in UCA (or ISO 14651) is not required for conformance
— only the relative ordering of the weights. In addition, stating rules in terms of relative order is much less sensitive to changes over time in the UCA
itself.</p>
</blockquote>
<h4>5.14.5 <a name="Orderings">Orderings</a></h4>
<p>The following are the normal ordering actions used for the bulk of characters. Each rule contains a string of ordered characters that starts with an anchor
point or a reset value. The reset value is an absolute point in the UCA that determines the order of other characters. For example, the rule & a < g, places
"g" after "a" in a tailored UCA: the "a" does not change place. Logically, subsequent rule after a reset indicates a change to the ordering (and comparison
strength) of the characters in the UCA. For example, the UCA has the following sequence (abbreviated for illustration):</p>
<blockquote>
<p>... a <<sub>3</sub> ａ <<sub>3</sub> ⓐ <<sub>3</sub> A <<sub>3</sub> Ａ <<sub>3</sub> Ⓐ <<sub>3</sub> ª <<sub>2</sub> á <<sub>3</sub> Á <<sub>1</sub> æ <<sub>3</sub>
Æ <<sub>1</sub> ɐ <<sub>1</sub> ɑ <<sub>1</sub> ɒ <<sub>1</sub> b <<sub>3</sub> ｂ <<sub>3</sub> ⓑ <<sub>3</sub> B <<sub>3</sub> Ｂ <<sub>3</sub> ℬ ...</p>
</blockquote>
<p>Whenever a character is inserted into the UCA sequence, it is inserted at the first point where the strength difference will not disturb the other characters
in the UCA. For example, & a < g puts <i>g</i> in the above sequence with a strength of L1. Thus the <i>g</i> must go in after any lower strengths, as
follows:</p>
<blockquote>
<p>... a <<sub>3</sub> ａ <<sub>3</sub> ⓐ <<sub>3</sub> A <<sub>3</sub> Ａ <<sub>3</sub> Ⓐ <<sub>3</sub> ª <<sub>2</sub> á <<sub>3</sub> Á
<b><font color="red"><<sub>1</sub> g </font></b><<sub>1</sub> æ <<sub>3</sub> Æ <<sub>1</sub> ɐ <<sub>1</sub> ɑ <<sub>1</sub> ɒ <<sub>1</sub> b <<sub>3</sub> ｂ
<<sub>3</sub> ⓑ <<sub>3</sub> B <<sub>3</sub> Ｂ <<sub>3</sub> ℬ ...</p>
</blockquote>
<p>The rule & a << g, which uses a level-2 strength, would produce the following sequence:</p>
<blockquote>
<p>... a <<sub>3</sub> ａ <<sub>3</sub> ⓐ <<sub>3</sub> A <<sub>3</sub> Ａ <<sub>3</sub> Ⓐ <<sub>3</sub> ª
<b><font color="red"><<sub>2</sub> g</font></b> <<sub>2</sub>
á <<sub>3</sub> Á<b><font color="red"> </font></b><<sub>1</sub> æ <<sub>3</sub> Æ <<sub>1</sub> ɐ <<sub>1</sub> ɑ <<sub>1</sub> ɒ <<sub>1</sub> b <<sub>3</sub>
ｂ <<sub>3</sub> ⓑ <<sub>3</sub> B <<sub>3</sub> Ｂ <<sub>3</sub> ℬ ...</p>
</blockquote>
<p>And the rule & a <<< g, which uses a level-3 strength, would produce the following sequence:</p>
<blockquote>
<p>... a <b><font color="red"><<sub>3</sub> g</font></b> <<sub>3</sub> ａ <<sub>3</sub> ⓐ <<sub>3</sub> A <<sub>3</sub> Ａ <<sub>3</sub> Ⓐ <<sub>3</sub> ª <<sub>2</sub>
á <<sub>3</sub> Á<b><font color="red"> </font></b><<sub>1</sub> æ <<sub>3</sub> Æ <<sub>1</sub> ɐ <<sub>1</sub> ɑ <<sub>1</sub> ɒ <<sub>1</sub> b <<sub>3</sub>
ｂ <<sub>3</sub> ⓑ <<sub>3</sub> B <<sub>3</sub> Ｂ <<sub>3</sub> ℬ ...</p>
</blockquote>
<p>Since resets always work on the existing state, the rule entries must be in the proper order. A character or sequence may occur multiple times; each subsequent
occurrence causes a different change. The following shows the result of serially applying a three rules.</p>
<table>
<tr>
<th> </th>
<th>Rules </th>
<th>Result</th>
<th>Comment </th>
</tr>
<tr>
<td>1</td>
<td>& a < g</td>
<td>... a<font color="red"> <<sub>1</sub> g</font> ...</td>
<td>Put g after a.</td>
</tr>
<tr>
<td>2</td>
<td>& a < h < k</td>
<td>... a<font color="red"> <<sub>1</sub> h <<sub>1</sub> k</font> <<sub>1</sub> g ...</td>
<td>Now put h and k after a (inserting before the g).</td>
</tr>
<tr>
<td>3</td>
<td>& h << g</td>
<td>... a <<sub>1</sub> h<font color="red"> <<sub>1</sub> g</font> <<sub>1</sub> k ...</td>
<td>Now put g after h (inserting before k).</td>
</tr>
</table>
<p>Notice that characters can occur multiple times, and thus override previous rules.</p>
<p>Except for the case of expansion sequence syntax, every sequence after a reset is equivalent in action to breaking up the sequence into an <i>atomic</i>
rule: a reset + relation pair. The tailoring is then equivalent to applying each of the atomic rules to the UCA in order, according to the above description.</p>
<p><i>Example:</i></p>
<table>
<tr>
<th>Rules</th>
<th>Equivalent Atomic Rules</th>
</tr>
<tr>
<td>& b < q <<< Q<br>
& a < x <<< X << q <<< Q < z</td>
<td>& b < q<br>
& q <<< Q<br>
& a < x<br>
& x <<< X<br>
& X << q<br>
& q <<< Q<br>
& Q < z</td>
</tr>
</table>
<p>In the case of expansion sequence syntax, the equivalent atomic sequence can be derived by first transforming the expansion sequence syntax into normal expansion
syntax. (See <a href="#Expansions">Expansions</a>.)</p>
<p><span class="dtd"><!ELEMENT reset ( #PCDATA | cp | ... )* ><br>
<!ELEMENT p ( #PCDATA | cp | last_variable )* ><br>
</span>(Elements pc, s, sc, t, tc, q, qc, i, and ic have the same structure as p.)</p>
<table>
<caption>Specifying Collation Ordering</caption>
<tr>
<th>Basic Symbol</th>
<th>Basic Example</th>
<th>XML Symbol</th>
<th>XML Example</th>
<th>Description</th>
</tr>
<tr>
<td><code>& </code></td>
<td><code>& Z </code></td>
<td><code><reset></code></td>
<td><code><reset><span style="color: blue">Z</span></reset></code></td>
<td>Do not change the ordering of Z, but place subsequent characters relative to it.</td>
</tr>
<tr>
<td><code>< </code></td>
<td><code>& a<br>
< b </code></td>
<td><code><p></code></td>
<td><code><reset><span style="color: blue">a</span><reset><br>
<p><span style="color: blue">b</span></p></code></td>
<td>Make 'b' sort after 'a', as a <i>primary</i> (base-character) difference</td>
</tr>
<tr>
<td><code><< </code></td>
<td><code>& a<br>
<< ä </code></td>
<td><code><s></code></td>
<td><code><reset><span style="color: blue">a</span><reset><br>
<s><span style="color: blue">ä</span></s></code></td>
<td>Make 'ä' sort after 'a' as a <i>secondary</i> (accent) difference</td>
</tr>
<tr>
<td><code><<< </code></td>
<td><code>& a<br>
<<< A </code></td>
<td><code><t></code></td>
<td><code><reset><span style="color: blue">a</span><reset><br>
<t><span style="color: blue">A</span></t></code></td>
<td>Make 'A' sort after 'a' as a <i>tertiary</i> (case/variant) difference</td>
</tr>
<tr>
<td><code>= </code></td>
<td><code>& x<br>
= y </code></td>
<td><code><i></code></td>
<td><code><reset><span style="color: blue">v</span><reset><br>
<i><span style="color: blue">w</span></i></code></td>
<td>Make 'w' sort <i>identically</i> to 'v'</td>
</tr>
</table>
<p>Resets only need to be at the start of a sequence, to position the characters relative a character that is in the UCA (or has already occurred in the tailoring).
For example: <reset>z</reset><p>a</p><p>b</p><p>c</p><p>d</p>.</p>
<p>Some additional elements are provided to save space with large tailorings. The addition of a 'c' to the element name indicates that each of the characters
in the contents of that element are to be handled as if they were separate elements with the corresponding strength:</p>
<table>
<caption>Abbreviating Ordering Specifications</caption>
<tr>
<th>XML Symbol</th>
<th>XML Example</th>
<th>Equivalent</th>
</tr>
<tr>
<td><code><pc></code></td>
<td><code><pc><span style="color: blue">bcd</span></pc></code></td>
<td><code><p><span style="color: blue">b</span></p><p><span style="color: blue">c</span></p><p><span style="color: blue">d</span></p></code></td>
</tr>
<tr>
<td><code><sc></code></td>
<td><code><sc><span style="color: blue">àáâã</span></sc></code></td>
<td><code><s><span style="color: blue">à</span></s><s><span style="color: blue">á</span></s><s><span style="color: blue">â</span></s><s>ã</s></code></td>
</tr>
<tr>
<td><code><tc></code></td>
<td><code><tc><span style="color: blue">PｐＰ</span></tc></code></td>
<td><code><t><span style="color: blue">P</span></t><t><span style="color: blue">ｐ</span></t><t><span style="color: blue">Ｐ</span></t></code></td>
</tr>
<tr>
<td><code><ic></code></td>
<td><code><ic><span style="color: blue">VwW</span></ic></code></td>
<td><code><i><span style="color: blue">V</span></i><i><span style="color: blue">w</span></i><i><span style="color: blue">W</span></i></code></td>
</tr>
</table>
<h4>5.14.6 <a name="Contractions">Contractions</a></h4>
<p>To sort a sequence as a single item (contraction), just use the sequence,
for example,</p>
<table>
<caption>Specifying Contractions</caption>
<tr>
<th>BASIC Example</th>
<th>XML Example</th>
<th>Description</th>
</tr>
<tr>
<td><code>& k<br>
< ch</code></td>
<td><code><reset><span style="color: blue">k</span></reset><br>
<p><span style="color: blue">ch</span></p></code></td>
<td>Make the sequence 'ch' sort after 'k', as a primary (base-character) difference</td>
</tr>
</table>
<h4>5.14.7 <a name="Expansions">Expansions</a></h4>
<p><span class="dtd"><!ELEMENT x (context?, ( p | pc | s | sc | t | tc | q | qc | i | ic )*, extend? ) ></span></p>
<p>There are two ways to handle expansions (where a character sorts as a sequence) with both the basic syntax and the XML syntax. The first method is to reset
to the sequence of characters. This is called <i>sequence expansion syntax. </i>The second is to use the extension sequence. Both are equivalent in practice
(unless the reset sequence happens to be a contraction). This is called <i>normal expansion syntax</i>.</p>
<table>
<caption>Specifying Expansions</caption>
<tr>
<th>Basic</th>
<th>XML</th>
<th>Description</th>
</tr>
<tr>
<td><code>& c <br>
<< k / h</code></td>
<td><code><reset><span style="color: blue">c</span></reset><br>
<x><s><span style="color: blue">k</span></s> <extend><span style="color: blue">h</span></extend></x></code></td>
<td><i>normal expansion syntax:<br>
</i>Make 'k' sort after the sequence 'ch'; thus 'k' will behave as if it expands to a character after 'c' followed by an 'h'.</td>
</tr>
<tr>
<td><code>& ch<br>
<< k</code></td>
<td><code><reset><span style="color: blue">ch</span></reset><br>
<s><span style="color: blue">k</span></s></code></td>
<td><i>sequence expansion syntax:<br>
</i>Make 'k' sort after the sequence 'ch'; thus 'k' will behave as if it expands to a character after 'c' followed by an 'h'.
<p><i>(unless 'ch' is defined beforehand as a contraction).</i></p>
</td>
</tr>
</table>
<p>If an <code><extend></code> element is necessary, it requires the rule to be embedded in an <x> element.</p>
<p>The sequence expansion syntax can be quite tricky, so it should be avoided where possible. In particular:</p>
<ul>
<li>The expansion is <i>only</i> in effect up to — but not including — the first primary rule. Thus<br>
<code> <reset><span style="COLOR: blue">ch</span></reset><br>
<s><span style="color: blue">x</span></x><br>
<t><span style="color: blue">y</span></t><br>
<p><span style="color: blue">z</span></p><br>
</code>is the same as<br>
<code> <reset><span style="COLOR: blue">c</span></reset><br>
<x><s><span style="color: blue">x</span></s><extend><span style="COLOR: blue">h</span></extend></x><br>
<x><t><span style="color: blue">y</span></t><extend><span style="COLOR: blue">h</span></extend></x><br>
<p><span style="color: blue">z</span></p></code></li>
<li>In accordance with the UCA, all strings are interpreted as being in NFD form. In other rules, this has no effect, but syntax such as <code><reset></code><b>ä</b><code></reset></code>,
the <b>ä</b> will be treated as two characters <b>a + ¨</b>, <i>unless</i> the <b>ä</b> has previously been used as a contraction. Thus the <b>¨</b>
will be used as an expansion for following characters (up to the next primary).</li>
</ul>
<p>Each extension replaces the one before it; it does not append to it. So </p>
<blockquote>
<p>& ab << c<br>& cd << e</p>
</blockquote>
<p>is equivalent to:</p>
<blockquote>
<p>& a << c / b << e / d</p>
</blockquote>
<p>and produces the following weights (where <i>p(x)</i> is the primary weight and <i>s(a)</i> is the secondary weight):</p>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse">
<tr>
<td>Character</td>
<td>Weights</td>
</tr>
<tr>
<td>c</td>
<td>p(a), p(b); s(a)+1, s(b); ...</td>
</tr>
<tr>
<td>e</td>
<td>p(a), p(d); s(a)+2, s(d); ...</td>
</tr>
</table>
<p>When expressing rules as atomic rules, the sequences must first be transformed into normal expansion syntax:</p>
<table>
<tr>
<th>Expansion Sequence</th>
<th>Normal Expansion</th>
<th>Equivalent Atomic Rules</th>
</tr>
<tr>
<td>& a<u>b</u> << q <<< Q<br>
& a<u>d</u> <<< AD < x <<< X</td>
<td>& a << q <u>/ b</u> <<< Q <u>/ b</u><br>
& a <<< AD <u>/ d</u> < x <<< X</td>
<td>& a << q <u>/ b</u><br>
& q <<< Q <u>/ b</u><br>
& a <<< AD <u>/ d</u><br>
& AD < x<br>
& x<<< X</td>
</tr>
</table>
<h4>5.14.8 <a name="Context_Before">Context Before</a></h4>
<p>The context before a character can affect how it is ordered, such as in Japanese. This could be expressed with a combination of contractions and expansions,
but is faster using a context. (The actual weights produced are different, but the resulting string comparisons are the same.) If a context element occurs,
it must be the first item in the rule, and requires an <x> element.</p>
<p>For example, suppose that "-" is sorted like the previous vowel. Then one could have rules that take "a-", "e-", and so on. However, that means that every
time a very common character (a, e, ...) is encountered, a system will slow down as it looks for possible contractions. An alternative is to indicate that when
"-" is encountered,<i> </i>and it comes after an 'a', it sorts
like an 'a', and so on. </p>
<table>
<caption>Specifying Previous Context</caption>
<tr>
<th>Basic</th>
<th>XML</th>
</tr>
<tr>
<td><code>& a <<< a | - <br>
& e <<< e | - <br>
...</code></td>
<td><code><reset><span style="color: #0000FF">a</span></reset><x><context><span style="color: #0000FF">a</span></context><s><span style="color: #0000FF">-</span></s></x><br>
<reset><span style="color: #0000FF">e</span></reset><x><context><span style="color: #0000FF">e</span></context><s><span style="color: #0000FF">-</span></s></x><br>
...</code></td>
</tr>
</table>
<p>Both the context and extend elements can occur in an <x> element. For example, the following are allowed:</p>
<ul>
<li><code><x><context><span style="color: blue">abc</span></context><p><span style="color: blue">def</span></p><extend><span style="color: blue">ghi</span></extend></x></code></li>
<li><code><x><p><span style="color: blue">def</span></p><extend><span style="color: blue">ghi</span></extend></x></code></li>
<li><code><x><context><span style="color: blue">abc</span></context><p><span style="color: blue">def</span></p></x></code></li>
</ul>
<h4>5.14.9 <a name="Placing_Characters_Before_Others">Placing Characters Before Others</a></h4>
<p>There are certain circumstances where characters need to be placed before a given character, rather than after. This is the case with Pinyin, for example,
where certain accented letters are positioned before the base letter. That is accomplished with the following syntax.</p>
<table>
<caption>Placing Characters <i>Before</i> Others</caption>
<tr>
<th>Item</th>
<th>Options</th>
<th>Basic Example </th>
<th>XML Example</th>
</tr>
<tr>
<td>before </td>
<td>primary<br>
secondary<br>
tertiary</td>
<td><code>& [before 2] a<br>
<< à</code></td>
<td><code><reset before="<span style="color: blue; ">secondary</span>"><span style="color: blue">a</span></reset><br>
<s><span style="color: blue">à</span></s></code></td>
</tr>
</table>
<p>It is an error if the strength of the before relation is not identical to the relation after the reset. Thus the following are errors, since the value of
the <i>before</i> attribute does not agree with the relation <s>.</p>
<table>
<tr>
<th>Basic Example </th>
<th>XML Example</th>
<th></th>
</tr>
<tr>
<td><code>& [before 2] a<br>
< à</code></td>
<td><code><reset before="<span style="color: blue; ">primary</span>"><span style="color: blue">a</span></reset><br>
<s><span style="color: blue">à</span></s></code></td>
<td><code>Error</code></td>
</tr>
<tr>
<td><code>& [before 2] a<br>
<<< à</code></td>
<td><code><reset before="<span style="color: blue; ">tertiary</span>"><span style="color: blue">a</span></reset><br>
<s><span style="color: blue">à</span></s></code></td>
<td><code>Error</code></td>
</tr>
</table>
<h4>5.14.10 <a name="Logical_Reset_Positions">Logical Reset Positions</a></h4>
<p><span class="dtd"><!ELEMENT reset ( ... | first_variable| last_variable | first_tertiary_ignorable | last_tertiary_ignorable | first_secondary_ignorable
| last_secondary_ignorable | first_primary_ignorable | last_primary_ignorable | first_non_ignorable | last_non_ignorable | first_trailing | last_trailing )*
></span></p>
<p>The UCA has the following overall structure for weights, going from low to high.</p>
<table>
<caption>Specifying Logical Positions</caption>
<tr>
<th>Name</th>
<th>Description</th>
<th>UCA Examples</th>
</tr>
<tr>
<td>first tertiary ignorable<br>
...<br>
last tertiary ignorable</td>
<td>p, s, t = ignore</td>
<td>Control Codes<br>
Format Characters<br>
Hebrew Points<br>
Tibetan Signs<br>
...</td>
</tr>
<tr>
<td>first secondary ignorable<br>
...<br>
last secondary ignorable</td>
<td>p, s = ignore</td>
<td>None in UCA</td>
</tr>
<tr>
<td>first primary ignorable<br>
...<br>
last primary ignorable</td>
<td>p = ignore</td>
<td>Most combining marks</td>
</tr>
<tr>
<td>first variable<br>
...<br>
last variable</td>
<td><i><b>if</b> alternate = non-ignorable<br>
</i>p != ignore,<br>
<i><b>if</b> alternate = shifted</i><br>
p, s, t = ignore</td>
<td>Whitespace,<br>
Punctuation,<br>
Symbols</td>
</tr>
<tr>
<td>first non-ignorable<br>
...<br>
last non-ignorable</td>
<td>p != ignore</td>
<td>Small number of exceptional symbols<br>
[for example, U+02D0 MODIFIER LETTER TRIANGULAR COLON]<br>
Numbers<br>
Latin<br>
Greek<br>
...</td>
</tr>
<tr>
<td><i>implicits</i></td>
<td>p != ignore, assigned automatically</td>
<td>CJK, CJK compatibility (those that are not decomposed)<br>
CJK Extension A, B<br>
Unassigned</td>
</tr>
<tr>
<td>first trailing<br>
...<br>
last trailing</td>
<td>p != ignore,<br>
used for trailing syllable components</td>
<td>Jamo Trailing<br>
Jamo Leading</td>
</tr>
</table>
<p>Each of the above Names (except <i>implicits</i>) can be used with a reset to position characters relative to that logical position. That allows characters
to be ordered before or after a <i>logical</i> position rather than a specific character.</p>
<blockquote>
<p class="note"><b>Note: </b>The reason for this is so that tailorings can be more stable. A future version of the UCA might add characters at any
point in the above list. Suppose that you set character X to be after Y. It could be that you want X to come after Y, no matter what future characters are
added; or it could be that you just want Y to come after a given logical position,
for example, after the last primary ignorable.</p>
</blockquote>
<p>Here is an example of the syntax:</p>
<table>
<caption>Sample Logical Position</caption>
<tr>
<th>Basic</th>
<th>XML</th>
</tr>
<tr>
<td><code>& [first tertiary ignorable]<br>
<< à </code></td>
<td><code><reset><first_tertiary_ignorable/></reset><br>
<s><span style="color: blue">à</span></s></code></td>
</tr>
</table>
<p>For example, to make a character be a secondary ignorable, one can make it be immediately after (at a secondary level) a specific character (like a combining
dieresis), or one can make it be immediately after the last secondary ignorable.</p>
<p>The <i>last-variable</i> element indicates the "highest" character that is treated as punctuation with alternate handling. Unlike the other logical positions,
it can be reset as well as referenced. For example, it can be reset to be just above spaces if all visible punctuation are to be treated as having distinct
primary values.</p>
<table>
<caption>Specifying Last-Variable</caption>
<tr>
<th>Attribute</th>
<th>Options</th>
<th>Basic Example </th>
<th>XML Example</th>
</tr>
<tr>
<td rowspan="3">variableTop</td>
<td><font color="#000000">at</font></td>
<td><code>& x<br>
= [last variable]</code></td>
<td><code><reset><span style="color: blue">x</span></reset><br>
<i><last_variable/></i></code></td>
</tr>
<tr>
<td><font color="#000000">after</font></td>
<td><code>& x<br>
< [last variable]</code></td>
<td><code><reset><span style="color: blue">x</span></reset><br>
<p><last_variable/></p></code></td>
</tr>
<tr>
<td><font color="#000000">before</font></td>
<td><code>& [before 1] x<br>
< [last variable]</code></td>
<td><code><reset before="<span style="color: blue">primary</span>"><span style="color: blue">x</span></reset><br>
<p><last_variable/></p></code></td>
</tr>
</table>
<p>The default value for <i>variable-top</i> depends on the UCA setting. For example, in 3.1.1, the value is at:</p>
<blockquote>
<p>U+1D7C3 MATHEMATICAL SANS-SERIF BOLD ITALIC PARTIAL DIFFERENTIAL</p>
</blockquote>
<p>The <code><last_variable/></code> cannot occur inside an <x> element, nor can there be any element content. Thus there can be no <context> or <extend> or
text data in the rule. For example, the following are all disallowed:</p>
<ul>
<li><code><x><context><span style="color: blue">a</span></context><p><last_variable/></p></x></code></li>
<li><code><x><p><last_variable/></p><extend><span style="color: blue">a</span></extend></x></code></li>
<li><code><p><last_variable/><span style="color: blue">a</span></p></code></li>
<li><code><p><span style="color: blue">a</span><last_variable/></p></code></li>
</ul>
<h4>5.14.11 <a name="Special_Purpose_Commands">Special-Purpose Commands</a></h4>
<p>The <i>suppress contractions</i> tailoring command turns off any existing contractions that begin with those characters. It is typically used to turn off
the Cyrillic contractions in the UCA, since they are not used in many languages and have a considerable performance penalty. The argument is a
<a href="#Unicode_Sets">Unicode Set</a>.</p>
<p>The <i>optimize</i> tailoring command is purely for performance. It indicates that those characters are sufficiently common in the target language for the
tailoring that their performance should be enhanced.</p>
<table>
<caption>Special-Purpose Commands</caption>
<tr>
<th>Basic</th>
<th>XML</th>
</tr>
<tr>
<td>[suppress contractions [Љ-ґ]]</td>
<td><code><suppress_contractions></code><span style="color: blue">[Љ-ґ]</span><code></suppress_contractions></code></td>
</tr>
<tr>
<td>[optimize [Ά-ώ]]</td>
<td><code><optimize></code><span style="color: blue">[Ά-ώ]</span><code></optimize></code></td>
</tr>
</table>
<p><br>
The reason that these are not settings is so that their contents can be arbitrary characters. </p>
<p><i>Example:</i></p>
<p>The following is a simple example that takes portions of the Swedish tailoring plus part of a Japanese tailoring, for illustration. For more
complete examples, see the actual locale data: Japanese, Chinese, Swedish, Traditional German are particularly illustrative.</p>
<pre><collation version="<span style="color: blue">3.1.1</span>">
<settings caseLevel="<span style="color: blue">on</span>"/>
<rules>
<reset><span style="color: blue">Z</span></reset>
<p><span style="color: blue">æ</span></p>
<t><span style="color: blue">Æ</span></t>
<p><span style="color: blue">å</span></p>
<t><span style="color: blue">Å</span></t>
<t><span style="color: blue">aa</span></t>
<t><span style="color: blue">aA</span></t>
<t><span style="color: blue">Aa</span></t>
<t><span style="color: blue">AA</span></t>
<p><span style="color: blue">ä</span></p>
<t><span style="color: blue">Ä</span></t>
<p><span style="color: blue">ö</span></p>
<t><span style="color: blue">Ö</span></t>
<s><span style="color: blue">ű</span></s>
<t><span style="color: blue">Ű</span></t>
<p><span style="color: blue">ő</span></p>
<t><span style="color: blue">Ő</span></t>
<s><span style="color: blue">ø</span></s>
<t><span style="color: blue">Ø</span></t>
<reset><span style="color: blue">V</span></reset>
<tc><span style="color: blue">wW</span></tc>
<reset><span style="color: blue">Y</span></reset>
<tc><span style="color: blue">üÜ</span></tc>
<reset><last_non_ignorable/></reset>
<span style="color:green"> <!-- following is equivalent to <p>亜</p><p>唖</p><p>娃</p>... -->
</span> <pc><span style="color: blue">亜唖娃阿哀愛挨姶逢葵茜穐悪握渥旭葦芦</span></pc>
<pc><span style="color: blue">鯵梓圧斡扱</span></pc>
</rules>
</collation></pre>
<h3>5.15 <span><a name="Segmentations">Segmentations</a></span></h3>
<p>The segmentations element provides for segmentation of text into words, lines, or other segments. The structure is based on [<a href="#UAX29">UAX29</a>]
notation, but adapted to be machine-readable. It uses a list of variables (representing character classes) and a list of rules. Each must have an id attribute.</p>
<p>The rules in <i>root</i> implement the segmentations found in [<a href="#UAX29">UAX29</a>] and [<a href="#UAX14">UAX14</a>], for grapheme clusters, words,
sentences, and lines. They can be overridden by rules in child locales. </p>
<p>Here is an example:</p>
<pre><segmentations>
<segmentation type="GraphemeClusterBreak">
<variables>
<variable id="$CR">\p{Grapheme_Cluster_Break=CR}</variable>
<variable id="$LF">\p{Grapheme_Cluster_Break=LF}</variable>
<variable id="$Control">\p{Grapheme_Cluster_Break=Control}</variable>
<variable id="$Extend">\p{Grapheme_Cluster_Break=Extend}</variable>
<variable id="$L">\p{Grapheme_Cluster_Break=L}</variable>
<variable id="$V">\p{Grapheme_Cluster_Break=V}</variable>
<variable id="$T">\p{Grapheme_Cluster_Break=T}</variable>
<variable id="$LV">\p{Grapheme_Cluster_Break=LV}</variable>
<variable id="$LVT">\p{Grapheme_Cluster_Break=LVT}</variable>
</variables>
<segmentRules>
<rule id="3"> $CR × $LF </rule>
<rule id="4"> ( $Control | $CR | $LF ) ÷ </rule>
<rule id="5"> ÷ ( $Control | $CR | $LF ) </rule>
<rule id="6"> $L × ( $L | $V | $LV | $LVT ) </rule>
<rule id="7"> ( $LV | $V ) × ( $V | $T ) </rule>
<rule id="8"> ( $LVT | $T) × $T </rule>
<rule id="9"> × $Extend </rule>
</segmentRules>
</segmentation>
...</pre>
<p><b>Variables: </b>All variable ids must start with a $, and otherwise be valid identifiers according to the Unicode definitions in [<a href="#UAX31">UAX31</a>].
The contents of a variable is a regular expression using variables and <a href="#Unicode_Sets">UnicodeSet</a>s. The ordering of variables is important; they
are evaluated in order from first to last (see <i><a href="#Segmentation_Inheritance">Section 5.15.1 Segmentation Inheritance</a></i>). It is an error to use
a variable before it is defined.</p>
<p><b>Rules: </b>The contents of a rule uses the syntax of [<a href="#UAX29">UAX29</a>]. The rules are evaluated in numeric id order (which may not be the order
in which the appear in the file). The first rule that matches determines the status of a boundary position, that is, whether it breaks or not. Thus ÷ means
a break is allowed; × means a break is forbidden. It is an error if the rule does not contain exactly one of these characters (except where a rule has no contents
at all, or if the rule uses a variable that has not been defined.</p>
<p>There are some implicit rules: </p>
<ul>
<li>The implicit initial rules are always "start-of-text ÷" and "÷ end-of-text"; these are not to be included explicitly.</li>
<li>The implicit final rule is always "Any ÷ Any". This is not to be included explicitly.</li>
</ul>
<blockquote>
<p><b>Note: </b>A rule like X Format* -> X in [<a href="#UAX29">UAX29</a>] and [<a href="#UAX14">UAX14</a>] is not supported. Instead, this needs to be
expressed as normal regular expressions. The normal way to support this is to modify the variables, such as in the following example:</p>
<pre id="line870"><variable id="$Format">\p{Word_Break=Format}</variable>
<variable id="$Katakana">\p{Word_Break=Katakana}</variable>
...
<!-- In place of rule 3, add format and extend to everything -->
<variable id="$X">[$Format $Extend]*</variable>
<variable id="$Katakana">($Katakana $X)</variable>
<variable id="$ALetter">($ALetter $X)</variable>
...</pre>
</blockquote>
<h4>5.15.1 <a name="Segmentation_Inheritance">Segmentation Inheritance</a></h4>
<p>Variables and rules both inherit from the parent. </p>
<p><b>Variables: </b>The child's variable list is logically appended to the parent's, and evaluated in that order. For example:</p>
<p><font color="#0000FF"><code>// in parent</code></font><code><br>
<variable id="$AL">[:linebreak=AL:]</variable><br>
<variable id="$YY">[[:linebreak=XX:]$AL]</variable>
</code> <font color="#0000FF"><code>// adds $AL</code></font></p>
<p><font color="#0000FF"><code>// in child</code></font><code><br>
<variable id="$AL">[$AL && [^a-z]]</variable> <font color="#0000FF">// changes $AL,
does not affect $YY</font><br>
<variable id="$ABC">[abc]</variable> </code> <font color="#0000FF">
<code>// adds new rule</code></font></p>
<p><b>Rules:</b> The rules are also logically appended to the parent's. Because rules are evaluated in numeric id order, to insert a rule in between others
just requires using an intermediate number. For example, to insert a rule before id="10.1" and after id="10.2", just use id="10.15". To delete a rule, use empty
contents, such as:</p>
<p><code><rule id="3"/></code><font color="#0000FF"><code> // deletes rule 3</code></font></p>
<h3>5.16 <a name="Transforms">Transforms</a></h3>
<p>Transforms provide a set of rules for transforming text via a specialized set of context-sensitive matching rules. They are commonly used for transliterations
or transcriptions, but also other transformations such as full-width to half-width (for <i>katakana</i> characters). The rules can be simple one-to-one relationships
between characters, or involve more complicated mappings. Here is an example:</p>
<pre><transform source="Greek" target="Latin" variant="UNGEGN" direction="both">
...
<comment>Useful variables</comment>
<tRule>$gammaLike = [ΓΚΞΧγκξχϰ] ;</tRule>
<tRule>$egammaLike = [GKXCgkxc] ;</tRule>
...
<comment>Rules are predicated on running NFD first, and NFC afterwards</comment>
<tRule>::NFD (NFC) ;</tRule>
...
<tRule>λ ↔ l ;</tRule>
<tRule>Λ ↔ L ;</tRule>
...
<tRule>γ } $gammaLike ↔ n } $egammaLike ;</tRule>
<tRule>γ ↔ g ;</tRule>
...
<tRule>::NFC (NFD) ;</tRule>
...
</transform></pre>
<p>The source and target values are valid locale identifiers, where 'und' means an unspecified language, plus some additional extensions.</p>
<ul>
<li>The long names of a script according to [<a href="#Scripts">Scripts</a>] may also be used instead of the und_script codes.</li>
<li>The long names of the English languages may also be used instead of the languages.</li>
<li>The term "Any" may be used instead of a solitary "und".</li>
<li>Other identifiers may be used for special purposes. In CLDR, these include: Accents, Digit, Fullwidth, Halfwidth, Jamo, NumericPinyin, Pinyin, Publishing,
Tone. (Other than these values, valid private use locale identifiers should be used, such as "x-Special".)</li>
<li>When presenting localizing transform names, the "und_" is normally omitted. Thus for a
transliterator with the ID "und_Latn-und_Grek" (or the equivalent "Latin-Greek"), the
translated name for Greek would be Λατινικό-Ελληνικό.</li>
</ul>
<p>There are currently two variants used in CLDR: UNGEGN and BGN, both indicating sources for
transliterations. There is an additional attribute <code>private="true" </code>which is used to indicate that the transform
is used in other transforms, but should not be listed when presented to users.</p>
<p>There are many different systems of transliteration. The goal for the "unqualified" script transliterations are</p>
<ol>
<li>to be lossless when going to Latin and back</li>
<li>to be as lossless as possible when going to other scripts</li>
<li>to abide by a common standard as much as possible (possibly supplemented to meet goals 1 and 2).</li>
</ol>
<p>Additional transliterations may also be defined, such as customized language-specific transliterations (such as between Russian and French), or those that
match a particular transliteration standard, such as </p>
<ul>
<li>UNGEGN - United Nations Group of Experts on Geographical Names</li>
<li>BGN - United States Board on Geographic Names</li>
<li>ISO9 - ISO/IEC 9</li>
<li>ISO15915 - ISO/IEC 15915</li>
<li>ISCII91 - ISCII 91</li>
<li>KMOCT - South Korean Ministry of Culture & Tourism</li>
<li>USLC - US Library of Congress</li>
<li>UKPCGN - Permanent Committee on Geographical Names for British Official Use</li>
<li>RUGOST - Russian Main Administration of Geodesy and Cartography</li>
</ul>
<p>The rules for transforms are described in Appendix N: <a href="#Transform_Rules">Transform Rules</a>.
For more information on Transliteration, see
<a href="http://cldr.unicode.org/index/cldr-spec/transliteration-guidelines">
Transliteration Guidelines</a>.</p>
<h3>5.17 <a name="Rule-Based_Number_Formatting">
Rule-Based Number Formatting</a></h3>
<p><span class="dtd"><!ELEMENT rbnf ( alias |
rulesetGrouping*) ><br>
<br>
<!ELEMENT rulesetGrouping ( alias | ruleset*) ><br>
<!ATTLIST rulesetGrouping type NMTOKEN #REQUIRED><br>
<br>
<!ELEMENT ruleset ( alias | rbnfrule*) ><br>
<!ATTLIST ruleset type NMTOKEN #REQUIRED><br>
<!ATTLIST ruleset access ( public | private ) #IMPLIED ><br>
<br>
<!ELEMENT rbnfrule ( #PCDATA ) ><br>
<!ATTLIST rbnfrule value CDATA #REQUIRED ><br>
<!ATTLIST rbnfrule radix CDATA #IMPLIED ><br>
<!ATTLIST rbnfrule decexp CDATA #IMPLIED ></span></p>
<p>The rule-based number format (RBNF)
encapsulates a set of rules for mapping binary numbers to and from a
readable representation. They are typically used for spelling out numbers,
but can also be used for other number systems like roman numerals, Chinese
numeals, or for ordinal numbers (1st, 2nd, 3rd,...). The syntax used in the
CLDR representation of rules is intended to be simply a transcription of ICU
based RBNF rules into an XML compatible syntax. The rules are fairly
sophisticated; for details see <i>Rule-Based Number Formatter</i> [<a href="#RBNF">RBNF</a>].
</p>
<p><span class="dtd"><ruleSetGrouping></span></p>
<p>Used to group rules into functional sets for
use with ICU. Currently, the valid types of rule set groupings are "SpelloutRules",
"OrdinalRules", and "NumberingSystemRules".</p>
<p><span class="dtd"><ruleset></span></p>
<p>This element denotes a specific rule set to the
number formatter. The ruleset is assumed to be a public ruleset unless the
attribute type="private" is specified.</p>
<p><span class="dtd"><rule></span></p>
<p>Contains the actual formatting rule for a
particular number or sequence of numbers. The "value" attribute is used to
indicate the starting number to which the rule applies. The actual text of
the rule is identical to the ICU syntax, with the exception that Unicode
left and right arrow characters are used to replace < and > in the rule
text, since < and > are reserved characters in XML. The "radix" attribute is
used to indicate an alternate radix to be used in calculating the prefix and
postfix values for number formatting. Alternate radix values are typically
used for formatting year numbers in formal documents, such as "nineteen
hundred seventy-six" instead of "one thousand nine hundred seventy-six".</p>
<h2>Appendix A: <a name="Sample_Special_Elements">Sample Special Elements</a></h2>
<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><?xml version="<span style="color: blue">1.0</span>" encoding="<span style="color: blue">UTF-8</span>" ?>
<!DOCTYPE ldml SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldml.dtd</span>" [
<!ENTITY % <span style="color: blue">icu</span> SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd</span>">
<!ENTITY % <span style="color: blue">openOffice</span> SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlOpenOffice.dtd</span>">
<span style="color: blue">%icu;
%openOffice;
</span>]></pre>
<p>Thus to include just the ICU DTD, one uses:</p>
<pre><?xml version="<span style="color: blue">1.0</span>" encoding="<span style="color: blue">UTF-8</span>" ?>
<!DOCTYPE ldml SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldml.dtd</span>" [
<!ENTITY % icu SYSTEM "<span style="color: blue">http://unicode.org/cldr/dtd/1.1/ldmlICU.dtd</span>">
<span style="color: blue">%icu;
</span>]></pre>
<blockquote>
<p><b>Note: </b>A previous version of this document contained a special element for
<a href="http://anubis.dkuug.dk/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: "when the required support cannot be obtained for the publication of an International Standard,
despite repeated effort". See the ballot comments on <a href="http://anubis.dkuug.dk/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>
<h3>A.1 <a name="OpenOffice">openoffice.org</a></h3>
<p>A number of the elements above can have extra information for openoffice.org, such as the following example:</p>
<pre> <special xmlns:openOffice="<span style="color: blue">http://www.openoffice.org</span>">
<openOffice:search>
<openOffice:searchOptions>
<openOffice:transliterationModules><span style="color: blue">IGNORE_CASE</span></openOffice:transliterationModules>
</openOffice:searchOptions>
</openOffice:search>
</special>
</pre>
<h2>Appendix B: <a name="Transmitting_Locale_Information">Transmitting Locale Information</a></h2>
<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' 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'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 "<i>close</i>" 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's preferred formats. If we format dates, for example, at the user'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'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's preferences arond 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>
<h3>B.1 <a name="Message_Formatting_and_Exceptions">Message Formatting and Exceptions</a></h3>
<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://java.sun.com/j2se/1.4.2/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'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>
<h2>Appendix C: <a name="Supplemental_Data">Supplemental Data</a></h2>
<p>The following represents the format for supplemental information. This is information that is important for
internationalization and proper use of CLDR, but is not contained in the locale hierarchy. It is
not localizable, nor is it overridden by locale data. The current CLDR
data can be viewed in the
<a href="http://www.unicode.org/cldr/data/charts/supplemental/index.html">Supplemental Charts</a>.
</p>
<p>The data in CLDR is split into multiple files: supplementalData.xml, supplementalMetadata.xml, characters.xml, likelySubtags.xml, plurals.xml, telephoneCodeData.xml, plus transforms (see <i>Section 5.16 <a href="#Transforms">Transforms</a>
</i>and<i> Appendix N: <a href="#Transform_Rules">Transform Rules</a></i>). The split is just
for convenience: logically, they are treated as though they were a single file. Future versions
of CLDR may split the data in a different fashion.</p>
<h3>C.1 <a name="Supplemental_Currency_Data">Supplemental Currency Data</a></h3>
<p><span class="dtd"><!ELEMENT currencyData ( fractions*, region+ ) ><br>
<!ELEMENT fractions ( info+ ) ><br>
<br>
<!ELEMENT info EMPTY ><br>
<!ATTLIST info iso4217 NMTOKEN #REQUIRED ><br>
<!ATTLIST info digits NMTOKEN #IMPLIED ><br>
<!ATTLIST info rounding NMTOKEN #IMPLIED ><br>
<br>
<!ELEMENT region ( currency* ) ><br>
<!ATTLIST region iso3166 NMTOKEN #REQUIRED ><br>
<br>
<!ELEMENT currency ( alternate* ) ><br>
<!ATTLIST currency from NMTOKEN #IMPLIED ><br>
<!ATTLIST currency to NMTOKEN #IMPLIED ><br>
<!ATTLIST currency iso4217 NMTOKEN #REQUIRED ><br>
<!ATTLIST currency tender ( true | false ) #IMPLIED ></span></p>
<p>Each currencyData element contains one fractions element followed by one or more region elements.
Here is an example for illustration.</p>
<pre class="xmlExample"><supplementalData>
<currencyData>
<fractions>
...
<info iso4217="CHF" digits="2" rounding="5"/>
...
<info iso4217="<span style="color: blue">ITL</span>" digits="<span style="color: blue">0</span>"/>
...
</fractions>
...
<region iso3166="IT">
<currency iso4217="EUR" from="1999-01-01"/>
<currency iso4217="ITL" from="1862-8-24" to="2002-02-28"/>
</region>
...
<region iso3166="CS">
<currency iso4217="EUR" from="2003-02-04"/>
<currency iso4217="CSD" from="2002-05-15"/>
<currency iso4217="YUM" from="1994-01-24" to="2002-05-15"/>
</region>
...
</currencyData>
...
</supplementalData></pre>
<p>The fractions element contains any number of info elements,
with the following attributes:</p>
<ul>
<li><b>iso4217: </b>the ISO 4217 code for the currency in question. If a particular currency does not occur in the fractions list, then it is given the
defaults listed for the next two attributes.</li>
<li><b>digits: </b>the number of decimal digits normally formatted. The default is 2.</li>
<li><b>rounding: </b>the rounding increment, in units of 10<sup>-digits</sup>. The default is 1. Thus with fraction digits of 2 and rounding increment of
5, numeric values are rounded to the nearest 0.05 units in formatting. With fraction digits of 0 and rounding increment of 50, numeric values are rounded
to the nearest 50.</li>
</ul>
<p>Each region element contains one attribute:</p>
<ul>
<li><b>iso3166:</b> the ISO 3166 code for the region in question. The special value <i>XXX</i> can be used to indicate that the region has no valid currency
or that the circumstances are unknown (usually used in conjunction with <i>before</i>, as described below).</li>
</ul>
<p>And can have any number of currency elements, with the ordered subelements.</p>
<pre> <region iso3166="IT"> <!-- Italy -->
<currency iso4217="EUR" from="2002-01-01"/>
<currency iso4217="ITL" to="2001-12-31"/>
</region></pre>
<ul>
<li><b>iso4217: </b>the ISO 4217 code for the currency in question</li>
<li><b>from: </b>the currency was valid from to the datetime indicated by the value.
See <i>Section 5.2.1 <a href="#Date_Ranges">Dates and Date Ranges</a></i>. </li>
<li><b>to: </b>the currency was valid up to the datetime indicated by the value of <i>before</i>.
See <i>Section 5.2.1 <a href="#Date_Ranges">Dates and Date Ranges</a></i>.</li>
<li>
<p><b>tender: </b>indicates whether or not the ISO
currency code represents a currency that was or is legal tender in some
country. The default is "true". Certain ISO codes represent things like
financial instruments or precious metals, and do not represent normally
interchanged currencies. </li>
</ul>
<p>That is, each currency element will list an interval in which it was valid. The<i>ordering</i> of the elements in the list tells us which was the primary
currency during any period in time. Here is an example of such an overlap:</p>
<pre><currency iso4217="CSD" to="2002-05-15"/>
<currency iso4217="YUD" from="1994-01-24" to="2002-05-15"/>
<currency iso4217="YUN" from="1994-01-01" to="1994-07-22"/></pre>
<p>The <i>from</i> element is limited by the fact that ISO 4217 does not go very far back in time, so there may be no ISO code for
the previous currency.</p>
<p>Currencies change relatively frequently. There are different types of changes:</p>
<ol>
<li>YU=>CS (name change)</li>
<li>CS=>RS+ME (split, different names) </li>
<li>US=>US+NC (split, same name for one // Northern California secedes)
</li>
<li>NC+CA=>CX (Union, new name // Northern Calif later joins with Canada to form Canadornia)
</li>
<li>DE+DD=>DE (Union, reuses one name) </li>
</ol>
<p>The <a href="http://unstats.un.org/unsd/methods/m49/m49chang.htm#ftnq">UN Information</a>
is used to determine dates due to country changes.</p>
<p>When a code is no longer in use, it is terminated (see #1, #2, #4, #5)</p>
<blockquote>
<p>Example:</p>
<ul>
<li><currency iso4217="EUR" from="2003-02-04" to="2006-06-03"/> </li>
</ul>
</blockquote>
<p>When codes split, each of the new codes inherits (see #2, #3) the previous data. However,
some modifications can be made if it is clear that currencies were only in use in one of the
parts. </p>
<p>When codes merge, the data is copied from the most populous part.
</p>
<blockquote>
<p>Example. When CS split into RS and ME:</p>
<ul>
<li>RS & ME copy the former CS, except that the line for EUR is dropped from RS
</li>
<li>CS now terminates on Jun 3, 2006 (following the UN info) </li>
</ul>
</blockquote>
<h3>C.2 <a name="Supplemental_Territory_Containment">Supplemental Territory Containment</a></h3>
<p><span class="dtd"><!ELEMENT territoryContainment ( group* ) ><br>
<!ELEMENT group EMPTY ><br>
<!ATTLIST group type NMTOKEN #REQUIRED ><br>
<!ATTLIST group contains NMTOKENS #IMPLIED ></span></p>
<p>The following data provides information that allows GUIs to break up a very long list of country names into a progressive list. The data is based on the
information found at [<a href="#UNM49">UNM49</a>]. There is one special code, QO, which is used for outlying areas that are typically uninhabited.</p>
<pre><territoryContainment></pre>
<blockquote>
<blockquote>
<pre><group type="001" contains="002 009 019 142 150"/> <!--World -->
<group type="011" contains="BF BJ CI CV GH GM GN GW LR ML MR NE NG SH SL SN TG"/> <!--Western Africa -->
<group type="013" contains="BZ CR GT HN MX NI PA SV"/> <!--Central America -->
<group type="014" contains="BI DJ ER ET KE KM MG MU MW MZ RE RW SC SO TZ UG YT ZM ZW"/> <!--Eastern Africa -->
<group type="142" contains="030 035 062 145"/> <!--Asia -->
<group type="145" contains="AE AM AZ BH CY GE IL IQ JO KW LB OM PS QA SA SY TR YE"/> <!--Western Asia -->
<group type="015" contains="DZ EG EH LY MA SD TN"/> <!--Northern Africa -->
...</pre>
</blockquote>
</blockquote>
<h3>C.3 <a name="Supplemental_Language_Data">Supplemental Language Data</a></h3>
<p><span class="dtd"><!ELEMENT languageData ( language* ) ><br>
<!ELEMENT language EMPTY ><br>
<!ATTLIST language type NMTOKEN #REQUIRED ><br>
<!ATTLIST language scripts NMTOKENS #IMPLIED ><br>
<!ATTLIST language territories NMTOKENS #IMPLIED ><br>
<!ATTLIST language variants NMTOKENS #IMPLIED ><br>
<!ATTLIST language alt NMTOKENS #IMPLIED ><br>
</span></p>
<p>The language data is used for consistency checking and testing. It
provides a list of which languages are used with which scripts and in which countries. To a
large extent, however, the territory list has been superseded by the <i>territoryInfo</i> data
discussed below.</p>
<pre> <languageData>
<language type="af" scripts="Latn" territories="ZA"/>
<language type="am" scripts="Ethi" territories="ET"/>
<language type="ar" scripts="Arab" territories="AE BH DZ EG IN IQ JO KW LB
LY MA OM PS QA SA SD SY TN YE"/>
...</pre>
<p>If the language is not a modern language, or the script is
not a modern script, or the language not a major language of the territory, then the alt
attribute is set to secondary. </p>
<pre> <language type="fr" scripts="Latn" territories="IT US" alt="secondary" />
...</pre>
<h3>C.4 <a name="Supplemental_Territory_Information">Supplemental Territory Information</a></h3>
<p><span class="dtd"><!ELEMENT territory ( languagePopulation* ) ><br>
<!ATTLIST territory type NMTOKEN #REQUIRED ><br>
<!ATTLIST territory gdp NMTOKEN #REQUIRED ><br>
<!ATTLIST territory literacyPercent NMTOKEN #REQUIRED ><br>
<!ATTLIST territory population NMTOKEN #REQUIRED ><br>
<br>
<!ELEMENT languagePopulation EMPTY ><br>
<!ATTLIST languagePopulation type NMTOKEN #REQUIRED ><br>
<!ATTLIST languagePopulation writingPercent NMTOKEN #IMPLIED ><br>
<!ATTLIST languagePopulation populationPercent NMTOKEN #REQUIRED ><br>
<!ATTLIST languagePopulation officialStatus (de_facto_official | official | official_regional |
official_minority) #IMPLIED ></span></p>
<p>This data provides testing information for language and territory
populations. The main goal is to provide approximate figures for the literate, functional
population for each language in each territory: that is, the population that is able to read and
write each language, and is comfortable enough to use it with computers.
</p>
<p>The GDP and Literacy figures are taken from the World Bank where
available, otherwise supplemented by FactBook data and other sources. Much of the per-language
data is taken from the Ethnologue, but is supplemented and processed using many other sources,
including per-country census data. (The focus of the Ethnologue is native speakers, which
includes people who are not literate, and excludes people who are functional second-langauge
users.) </p>
<p>The percentages may add up to more than 100% due to multilingual
populations, or may be less than 100% due to illiteracy or because the data has not yet been
gathered or processed. Languages with a small population may be omitted. </p>
<h3>C.5 <a name="Supplemental_Calendar_Data">Supplemental Calendar Data</a></h3>
<pre><span class="dtd"><!ELEMENT calendarData ( calendar* ) >
<!ELEMENT calendar ( calendarSystem?, eras? ) >
<!ATTLIST calendar type NMTOKENS #REQUIRED >
<!ATTLIST calendar territories NMTOKENS #IMPLIED > <!-- territories are deprectead. use ordering attribute in calendarPreference element instead. -->
<!ELEMENT calendarSystem EMPTY >
<!ATTLIST calendarSystem type (solar | lunar | lunisolar | other) #REQUIRED >
<!ELEMENT eras ( era* ) >
<!ELEMENT era EMPTY >
<!ATTLIST era type NMTOKENS #REQUIRED >
<!ATTLIST era start CDATA #IMPLIED >
<!ATTLIST era end CDATA #IMPLIED >
<!ELEMENT weekData ( minDays*, firstDay*, weekendStart*, weekendEnd* ) >
<!ELEMENT minDays EMPTY >
<!ATTLIST minDays count (1 | 2 | 3 | 4 | 5 | 6 | 7) #REQUIRED >
<!ATTLIST minDays territories NMTOKENS #REQUIRED >
<!ELEMENT firstDay EMPTY >
<!ATTLIST firstDay day (sun | mon | tue | wed | thu | fri | sat) #REQUIRED >
<!ATTLIST firstDay territories NMTOKENS #REQUIRED >
<!ELEMENT weekendStart EMPTY >
<!ATTLIST weekendStart day (sun | mon | tue | wed | thu | fri | sat) #REQUIRED >
<!ATTLIST weekendStart territories NMTOKENS #REQUIRED >
<!ELEMENT weekendEnd EMPTY >
<!ATTLIST weekendEnd day (sun | mon | tue | wed | thu | fri | sat) #REQUIRED >
<!ATTLIST weekendEnd territories NMTOKENS #REQUIRED ></span></pre>
<p>The calendar data provides locale-independent data about calendars and usage. Example:</p>
<pre><calendarData>
<!-- gregorian is assumed, so these are all in addition -->
<calendar type="japanese" territories="JP"/>
<calendar type="islamic-civil" territories="AE BH DJ DZ EG EH ER IL IQ JO KM KW
LB LY MA MR OM PS QA SA SD SY TD TN YE AF IR"/>
...</pre>
<p>The common values provide a list of the calendars that are in common use, and thus should be shown in UIs that provide choice of calendars. (An 'Other...'
button could give access to the other available calendars.)</p>
<p><b>Note: </b>The territories attribute in the calendar element is deprecated.
Calendar types used by each territory is provided by <i>C.15 <a href="#Calendar_Preference_Data">Calendar Preference Data</a></i>.</p>
<pre><weekData>
<minDays count="1" territories="001"/>
<minDays count="4" territories="AT BE CA CH DE DK FI FR IT LI LT LU MC MT NL NO SE SK"/>
<minDays count="4" territories="CD" draft="true"/>
<firstDay day="mon" territories="001"/>
...</pre>
<p class="note">These values provide information on how a calendar is used in a particular territory. It may also be used in computing week boundaries for other
purposes. The default is provided by the element with territories="001". </p>
<p class="note">The minDays indicates the minimum number of days to count as the first week (of a month or year). The first day of the week is typically used
for calendar presentation. </p>
<p>What is meant by the weekend varies from country to country. It is typically when most non-retail businesses are closed. The time should not be specified
unless it is a well-recognized part of the day.</p>
<p class="note">The weekendStart day defaults to "sat", and weekendEnd day defaults to "sun".
For more information, see <i>Section 5.2.1 <a href="#Date_Ranges">Dates and Date Ranges</a></i>.</p>
<h3>C.6 <a name="Measurement_System_Data">Measurement System Data</a></h3>
<p><span class="dtd"><!ELEMENT measurementData ( measurementSystem*, paperSize* ) ><br>
<br>
<!ELEMENT measurementSystem EMPTY ><br>
<!ATTLIST measurementSystem type ( metric | US | UK ) #REQUIRED ><br>
<!ATTLIST measurementSystem territories NMTOKENS #REQUIRED ><br>
<br>
<!ELEMENT paperSize EMPTY ><br>
<!ATTLIST paperSize type ( A4 | US-Letter ) #REQUIRED ><br>
<!ATTLIST paperSize territories NMTOKENS #REQUIRED ></span></p>
<p>The measurement system is the normal measurement system in common everyday use (except for
date/time). For example:</p>
<pre><measurementData>
<measurementSystem type="metric" territories="001"/>
<measurementSystem type="US" territories="US"/>
<paperSize type="A4" territories="001"/>
<paperSize type="US-Letter" territories="US"/>
</measurementData></pre>
<p>The values are "metric", "US", or "UK";
others may be added over time. The "metric" value indicates the use of SI [<a href="#ISO1000">ISO1000</a>] base or derived units,
or non-SI units accepted for use with SI: For example, meters, kilograms, liters, and degrees Celsius.
The "US" value indicates the customary system of measurement as
used in the United States: feet, inches, pints, quarts, degrees Fahrenheit,
and so on. The "UK" value indicates the customary system of measurement
as used in the United Kingdom: feet, inches, pints, quarts, and so on.
It is also called the Imperial system: the pint, quart, and so on are different sizes than in "US".</p>
<p>The paperSize attribute gives the height and width of paper used for normal business letters. The values are "A4" and "US-Letter".</p>
<p>For both measurementSystem entries and paperSize entries, later entries for specific territories such as "US" will override the
value assigned to that territory by earlier entries for more inclusive territories such as "001".</p>
<p>The measurement information was formerly in the main LDML file, and had a somewhat different format.</p>
<h3>C.7 <a name="Supplemental_Timezone_Data">Supplemental Time Zone Data</a></h3>
<p><span class="dtd"><!ELEMENT timezoneData ( mapTimezones*, zoneFormatting* ) ><br>
<!ELEMENT mapTimezones ( mapZone* ) ><br>
<!ATTLIST mapTimezones type NMTOKEN #REQUIRED ><br>
<br>
<!ELEMENT mapZone EMPTY ><br>
<!ATTLIST mapZone type CDATA #REQUIRED ><br>
<!ATTLIST mapZone other CDATA #REQUIRED ><br>
<!ATTLIST mapZone territory CDATA #IMPLIED ><br>
<br>
<!ELEMENT zoneFormatting ( zoneItem* ) ><br>
<!ATTLIST zoneFormatting multizone NMTOKENS #REQUIRED ><br>
<!ATTLIST zoneFormatting tzidVersion CDATA #IMPLIED ><br>
<br>
<!ELEMENT zoneItem EMPTY ><br>
<!ATTLIST zoneItem type CDATA #REQUIRED ><br>
<!ATTLIST zoneItem territory NMTOKEN #REQUIRED ><br>
<!ATTLIST zoneItem aliases CDATA #IMPLIED ><br>
</span></p>
<p>The following is data that can be used to get a single timezone id from a set of modern equivalents.
It provides a stable identifier for use with the standard timezone database.</p>
<pre><timezoneData>
<size ordering="America/New_York America/Detroit America/Louisville
America/Kentucky/Monticello">
...</pre>
<p>The following subelement of <timezoneData> supplies information used by Appendix J: <a href="#Time_Zone_Fallback">Time Zone Display Names</a>.</p>
<pre><zoneFormatting multizone="001 AQ AR AU BR CA CD CL CN EC ES FM GB GL ID KI KZ MH ML MN MX MY NZ PF PT RU SJ UA UM US UZ">
<zoneItem type="Africa/Abidjan" territory="CI"/>
<zoneItem type="Africa/Accra" territory="GH"/>
<zoneItem type="America/Adak" territory="US" aliases="America/Atka US/Aleutian"/>
<zoneItem type="Africa/Addis_Ababa" territory="ET"/>
<zoneItem type="Australia/Adelaide" territory="AU" aliases="Australia/South"/></pre>
<p>The multizone attribute lists the territories that that have multiple TZIDs, which is used in step #5 of Appendix J: <a href="#Time_Zone_Fallback">Time Zone
Display Names</a>. The zoneItem type is the canonical ID for CLDR. The aliases map to that canonical ID; this is used in step #1 in Appendix J:
<a href="#Time_Zone_Fallback">Time Zone Display Names</a>. The territory is also used in step #5.</p>
<p>The following data can be used to provide mappings between <i>TZ</i> IDs and other platforms. The purpose is to assist with migration and vetting.</p>
<pre><mapTimezones type="windows">
<mapZone other="Dateline" type="Etc/GMT+12">
<mapZone other="Samoa" type="Pacific/Midway">
<mapZone other="Hawaiian" type="Pacific/Honolulu"></pre>
<pre>...</pre>
<h3>C.8 <a name="Supplemental_Character_Fallback_Data">Supplemental Character Fallback Data</a></h3>
<p><span class="dtd"><!ELEMENT characters ( character-fallback*) ><br>
<br>
<!ELEMENT character-fallback ( character* ) ><br>
<!ELEMENT character (substitute*) ><br>
<!ATTLIST character value CDATA #REQUIRED ><br>
<br>
<!ELEMENT substitute (#PCDATA) ></span></p>
<p>The characters element provides a way for non-Unicode systems, or systems that only support a subset of Unicode characters, to transform CLDR data. It gives
a list of characters with alternative values that can be used if the main value is not available. For example:</p>
<pre><characters>
<character-fallback>
<character value = "ß">
<substitute>ss</substitute>
</character>
<character value = "Ø">
<substitute>Ö</substitute>
<substitute>O</substitute>
</character>
<character value = "<span style="font-size:150%">₧</span>">
<substitute>Pts</substitute>
</character>
<character value = "<span style="font-size:150%">₣</span>">
<substitute>Fr.</substitute>
</character>
</character-fallback>
</characters></pre>
<p>The ordering of the substitute elements indicates the preference among them. </p>
That is, this data provides recommended fallbacks for use when a charset or supported repertoire
does not contain a desired character. There is more than one possible
fallback: the recommended usage is that when a character <i>value</i> is not in the desired repertoire
the following process is used, whereby the first value that is wholly in the desired repertoire
is used.<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><code>toNFC</code>(<i>value</i>)</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">other canonically equivalent sequences, if there are any</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">the explicit <i>substitutes</i> value (in order)</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><code>toNFKC</code>(<i>value</i>)</li>
</ul>
<h3>C.9 <a name="Supplemental_Code_Mapping">Supplemental Code Mapping</a></h3>
<p><span class="dtd"><!ELEMENT languageCodes EMPTY ><br>
<!ATTLIST languageCodes type NMTOKEN #REQUIRED><br>
<!ATTLIST languageCodes alpha3 NMTOKEN #REQUIRED><br>
<br>
<!ELEMENT territoryCodes EMPTY ><br>
<!ATTLIST territoryCodes type NMTOKEN #REQUIRED><br>
<!ATTLIST territoryCodes numeric NMTOKEN #REQUIRED><br>
<!ATTLIST territoryCodes alpha3 NMTOKEN #REQUIRED><br>
<!ATTLIST territoryCodes fips10 NMTOKEN #IMPLIED><br>
<!ATTLIST territoryCodes internet NMTOKENS #IMPLIED></span></p>
<p>The code mapping information provides mappings between the subtags
used in the CLDR locale IDs (from BCP 47) and other coding systems or related information. The
language codes are only provided for those codes that have two letters in BCP 47 to their ISO
three-letter equivalents. The territory codes provide mappings to numeric (UN
M.49 [<a href="#UNM49">UNM49</a>] codes,
equivalent to ISO numeric codes), ISO three-letter codes, FIPS 10 codes, and the internet
top-level domain codes. The alphabetic codes are only provided where different from the type.
For example:</p>
<pre><territoryCodes type="AA" numeric="958" alpha3="AAA"/>
<territoryCodes type="AD" numeric="020" alpha3="AND" fips10="AN"/>
<territoryCodes type="AE" numeric="784" alpha3="ARE"/>
...
<territoryCodes type="GB" numeric="826" alpha3="GBR" fips10="UK" internet="UK GB"/>
...
<territoryCodes type="QU" numeric="967" alpha3="QUU" internet="EU"/></pre>
<h3>C.10 <a name="Likely_Subtags">Likely Subtags</a></h3>
<p><span class="dtd"><!ELEMENT likelySubtag EMPTY ><br>
<!ATTLIST likelySubtag from NMTOKEN #REQUIRED><br>
<!ATTLIST likelySubtag to NMTOKEN #REQUIRED></span></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 "zh" and the
region "TW", what is the most likely script? Given the script "Thai" 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, "en_Latn" can be simplified down
to "en" since "Latn" is the likely script for "en"; "ja_Japn_JP"
can be simplified down to "ja".</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. 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"><likelySubtag from="zh" to="zh_Hans_CN"/><br>
<likelySubtag from="zh_HK" to="zh_Hant_HK"/><br>
<likelySubtag from="zh_Hani" to="zh_Hans_CN"/><br>
<likelySubtag from="zh_Hant" to="zh_Hant_TW"/><br>
<likelySubtag from="zh_MO" to="zh_Hant_MO"/><br>
<likelySubtag from="zh_TW" to="zh_Hant_TW"/></p>
</blockquote>
<p>So looking up "zh_TW" returns "zh_Hant_TW", while looking up "zh"
returns "zh_Hans_CN". In the following text, the components of such a result will be
be designated with language<font face="Lucida Sans Unicode">², region², and script².</font></p>
<p>The data is designed to be used in the following operations. It can
also be used with language tags using [<a href="#BCP47">BCP47</a>] syntax, with a few changes.</p>
<p> </p>
<p><i><b>Add Likely Subtags: </b>Given a locale, to fill in the most
likely other fields.</i></p>
<p>This operation is performed in the following way. </p>
<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Canonicalize.<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 <alias> data in supplemental
metadata. Use the first value in the replacement list, if it exists.</li>
<li>If the tag is grandfathered (see <variable id="$grandfathered"
type="choice"> in the supplemental data), then return it.</li>
<li>Remove the script code 'Zzzz' and the region code 'ZZ' if they occur; change an empty language subtag to
'und'.</li>
<li>Get the components of the cleaned-up tag (language<font face="Lucida Sans Unicode">¹</font>,
script<font face="Lucida Sans Unicode">¹, and </font>region<font face="Lucida Sans Unicode">¹</font>), plus any variants
if they exist
(including keywords).</li>
</ol>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Try each of
the following in order (where the fields exist). The notation field<font face="Lucida Sans Unicode">³
means field¹ if it exists, otherwise field².</font><ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Lookup
language<font face="Lucida Sans Unicode">¹ </font>_ script<font face="Lucida Sans Unicode">¹
</font>_ region<font face="Lucida Sans Unicode">¹</font>. If in the table, return the language<font face="Lucida Sans Unicode">²
</font>_ script<font face="Lucida Sans Unicode">² </font>_ region<font face="Lucida Sans Unicode">²
</font>+ variants.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Lookup
language<font face="Lucida Sans Unicode">¹ </font>_ script<font face="Lucida Sans Unicode">¹</font>.
If in the table, return language<font face="Lucida Sans Unicode">² </font>_ script<font face="Lucida Sans Unicode">²
</font>_ region<font face="Lucida Sans Unicode">³</font> + variants.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Lookup
language<font face="Lucida Sans Unicode">¹ </font>_ region<font face="Lucida Sans Unicode">¹</font>. If in the table, return language<font face="Lucida Sans Unicode">²
</font>_ script<font face="Lucida Sans Unicode">³ </font>_ region<font face="Lucida Sans Unicode">²</font> + variants.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Lookup
language<font face="Lucida Sans Unicode">¹</font>. If in the table, return language<font face="Lucida Sans Unicode">²
</font>_ script<font face="Lucida Sans Unicode">³ </font>_ region<font face="Lucida Sans Unicode">³</font> + variants.</li>
</ol>
</li>
<li>If none of these succeed, signal an error.</li>
</ol>
<p><i>Example:</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>Remove SG, but remember it. 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 "und" as the language subtag. For example, looking up "und_TW" returns zh_Hant_TW.</p>
<p> </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 => zh_Hans_CN. No match, so continue.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">
<p>zh_TW => 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.<br>
</p>
<h3>C.11 <a name="Language_Plural_Rules">Language Plural Rules</a></h3>
<p><span class="dtd"><!ELEMENT plurals (pluralRules*) ><br>
<br>
<!ELEMENT pluralRules (pluralRule*) ><br>
<!ATTLIST pluralRules locales NMTOKENS #REQUIRED ><br>
<br>
<!ELEMENT pluralRule ( #PCDATA ) ><br>
<!ATTLIST pluralRule count (zero | one | two | few | many) #REQUIRED ></span></p>
<p>This section defines certain plural forms that exist in a language—specifically, just the plural forms for nouns that express units such
as time, currency or distance, used in conjunction with a number expressed in decimal digits (i.e. "2", not "two", and not an indefinite number
such as "some" or "many"). For example, English has two forms:</p>
<ul>
<li>form "one": 1 day</li>
<li>form "other": 0 days, 2 days, 10 days, 0.3 days</li>
</ul>
<p>Other languages may have additional forms or only one form. CLDR provides the following tags for designating the various plural forms
of a language; for a given language, only the tags necessary for that language are defined, along with the specific numeric ranges covered by each tag (for
example,
the plural form "few" may be used for the numeric range 2-4 in one language and 3-9 in another):</p>
<ul>
<li><span style="font-family: monospace;">zero</span></li>
<li><span style="font-family: monospace;">one</span></li>
<li><span style="font-family: monospace;">two</span></li>
<li><span style="font-family: monospace;">few</span></li>
<li><span style="font-family: monospace;">many</span></li>
</ul>
<p>In addition, an "other" tag is always implicitly defined to cover the forms not explicitly designated by the tags defined
for a language. This "other" tag is also used for languages that only have a single form (in which case no plural-form tags are explicitly defined for
the language). For a more complex example, consider the rules for Russian and certain other languages:</p>
<pre><pluralRules locales="hr ru sr uk">
<pluralRules count="one"><span style="color: blue">n mod 10 is 1 and n mod 100 is not 11</span></pluralRule>
<pluralRules count="few"><span style="color: blue">n mod 10 in 2..4 and n mod 100 not in 12..14</span></pluralRule>
</pluralRules></pre>
<p>These rules specify that Russian has a "one" form (for 1, 21, 31, 41, 51, …), a "few" form (for 2-4, 22-24, 32-34, …),
and implicitly an "other" form (for everything else: 0, 5-20, 25-30, 35-40, …, decimals). Russian does not need additional separate forms for zero, two, or
many, so these are not defined.</p>
<h4>Plural rules syntax</h4>
<p>The xml value for each pluralRule is a <em>condition</em> with a boolean result that specifies whether that rule
(i.e. that plural form) applies to a given numeric value <em>n</em>, where n can be expressed as a decimal fraction. Conditions have the following syntax:</p>
<pre>condition = and_condition ('or' and_condition)*
and_condition = relation ('and' relation)*
relation = is_relation | in_relation | within_relation | 'n' <EOL>
is_relation = expr 'is' ('not')? value
in_relation = expr ('not')? 'in' range
within_relation = expr ('not')? 'within' range
expr = 'n' ('mod' value)?
value = digit+
digit = 0|1|2|3|4|5|6|7|8|9
range = value'..'value</pre>
<ul>
<li>Whitespace (defined as Unicode Pattern_White_Space) can occur between or around any of the above tokens.</li>
<li>Rules should be mutually exclusive; for a given numeric value, only one rule should apply (i.e. the condition should only be
true for one of the pluralRule elements.</li>
<li>The difference between 'in' and 'within' is that 'in' only includes integers in the specified range,
while 'within' includes all values.</li>
<li>'mod' (modulus) is a remainder operation as defined in Java; for example, the result of "4.3 mod 3" is 1.3.</li>
</ul>
<p>Examples:</p>
<table border>
<tr>
<td nowrap><span style="font-family: monospace;">
one: n is 1<br>
few: n in 2..4
</span></td>
<td>This defines two rules, for 'one' and 'few'. The condition for 'one' is "n is 1"
which means that the number must be equal to 1 for this condition to pass. The
condition for 'few' is "n in 2..4" which means that the number must be between 2
and 4 inclusive for this condition to pass. All other numbers are assigned the
keyword 'other' by the default rule. </td>
</tr>
<tr>
<td nowrap><span style="font-family: monospace;">
zero: n is 0 or n is not 1 and n mod 100 in 1..19<br>
one: n is 1
</span></td>
<td>Each rule must not overlap with other rules. Also note that a modulus is
applied to n in the last rule, thus its condition holds for 119, 219, 319... </td>
</tr>
<tr>
<td nowrap><span style="font-family: monospace;">
one: n is 1<br>
few: n mod 10 in 2..4 and n mod 100 not in 12..14
</span></td>
<td>This illustrates conjunction and negation. The condition for 'few' has two
parts, both of which must be met: "n mod 10 in 2..4" and "n mod 100 not in
12..14". The first part applies a modulus to n before the test as in the
previous example. The second part applies a different modulus and also uses
negation, thus it matches all numbers <em>not</em> in 12, 13, 14, 112, 113, 114, 212,
213, 214... </td>
</tr>
</table>
<h4>Using the plural rules</h4>
<p>Elements such as <currencyFormats>, <currency> and <unit> provide selection among subelements designating various
localized plural forms by tagging each of the relevant subelements with a different count value, or with no count value in some cases. Note that the plural forms
for a specific currencyFormat, unit type, or currency type may not use all of the different plural-form tags defined for the language. To format a currency or
unit type for a particular numeric value, determine the count value according to the plural rules for the language, then select the appropriate display form for
the currency format, currency type or unit type using the rules in those sections:</p>
<ul>
<li>5.10.1 <a href="#Number_Symbols">Number Symbols</a> (for currencyFormats elements)</li>
<li>5.10.2 <a href="#Currencies">Currencies</a> (for currency elements)</li>
<li>5.11 <a href="#Unit_Elements">Unit Elements</a></li>
</ul>
<h3>C.12 <a name="Telephone_Code_Data">Telephone Code Data</a></h3>
<p><span class="dtd"><!ELEMENT telephoneCodeData ( codesByTerritory* ) ><br>
<br>
<!ELEMENT codesByTerritory ( telephoneCountryCode+ ) ><br>
<!ATTLIST codesByTerritory territory NMTOKEN #REQUIRED ><br>
<br>
<!ELEMENT telephoneCountryCode EMPTY ><br>
<!ATTLIST telephoneCountryCode code NMTOKEN #REQUIRED ><br>
<!ATTLIST telephoneCountryCode from NMTOKEN #IMPLIED ><br>
<!ATTLIST telephoneCountryCode to NMTOKEN #IMPLIED ></span></p>
<p>This data specifies the mapping between ITU telephone country codes [<a href="#ITUE164">ITUE164</a>] and CLDR-style territory codes (ISO 3166 2-letter codes or
non-corresponding UN
M.49 [<a href="#UNM49">UNM49</a>] 3-digit codes). There are several things to note:</p>
<ul>
<li>A given telephone country code may map to multiple CLDR territory codes; +1 (North America Numbering Plan) covers the US
and Canada, as well as many islands in the Caribbean and some in the Pacific</li>
<li>Some telephone country codes are for global services (for example, some satellite services), and thus correspond to territory code 001.</li>
<li>The mappings change over time (territories move from one telephone code to another). These changes are usually planned
several years in advance, and there may be a period during which either telephone code can be used to reach the territory. While the CLDR telephone code data
is not intended to include past changes, it is intended to incorporate known information on planned future changes, using "from" and "to"
date attributes to indicate when mappings are valid.</li>
</ul>
<p>A subset of the telephone code data might look like the following (showing a past mapping change to illustrate the from and to
attributes):</p>
<pre><codesByTerritory territory="001">
<telephoneCountryCode code="800"/> <!-- International Freephone Service -->
<telephoneCountryCode code="808"/> <!-- International Shared Cost Services (ISCS) -->
<telephoneCountryCode code="870"/> <!-- Inmarsat Single Number Access Service (SNAC) -->
</codesByTerritory>
<codesByTerritory territory="AS"> <!-- American Samoa -->
<telephoneCountryCode code="1" from="2004-10-02"/> <!-- +1 684 in North America Numbering Plan -->
<telephoneCountryCode code="684" to="2005-04-02"/> <!-- +684 now a spare code -->
</codesByTerritory>
<codesByTerritory territory="CA">
<telephoneCountryCode code="1"/> <!-- North America Numbering Plan -->
</codesByTerritory></pre>
<h3>C.13 <a name="Numbering_Systems">Numbering Systems</a></h3>
<p><span class="dtd"><!ELEMENT numberingSystems ( numberingSystem* ) ><br>
<!ELEMENT numberingSystem EMPTY ><br>
<!ATTLIST numberingSystem id NMTOKEN #REQUIRED ><br>
<!ATTLIST numberingSystem type ( numeric | algorithmic ) #REQUIRED ><br>
<!ATTLIST numberingSystem radix NMTOKEN #IMPLIED ><br>
<!ATTLIST numberingSystem digits CDATA #IMPLIED ><br>
<!ATTLIST numberingSystem rules CDATA #IMPLIED ><br></span></p>
<p>Numbering systems information is used to define different
representations for numeric values to an end user. Numbering systems are
defined in CLDR as one of two different types: algorithmic and numeric.
Numeric systems are simply a decimal based system that uses a predefined set
of digits to represent numbers. Examples are Western ( ASCII digits ), Thai
digits, Devanagari digits. Algorithmic systems are more complex in nature,
since the proper formatting and presentation of a numeric quantity is based
on some algorithm or set of rules. Examples are Chinese numerals, Hebrew
numerals, or Roman numerals. In CLDR, the rules for presentation of numbers
in an algorithmic system are defined using the RBNF syntax described in
Section 5.17
<a href="#Rule-Based_Number_Formatting">Rule-Based Number Formatting</a>.
</p>
<p>Attributes for the <numberingSystem> element are as
follows:</p>
<blockquote>
<p><span class="attribute">id</span> - Specifies the
name of the numbering system that can be used to designate its use in
formatting.</p>
<p><span class="attribute">type</span> - Specifies
whether the numbering system is algorithmic or numeric.</p>
<p><span class="attribute">digits</span> - For numeric
systems, specifies the digits used to represent numbers, in order,
starting from zero.</p>
<p><span class="attribute">rules</span> - Specifies the
RBNF ruleset to be used for formatting numbers from this numbering
system. The rules specifier can contain simply a ruleset name, in which
case the ruleset is assumed to be found in the rule set grouping "NumberingSystemRules".
Alternatively, the specifier can denote a specific locale, ruleset
grouping, and ruleset name, separated by slashes.</p>
</blockquote>
<p>Examples:</p>
<pre><numberingSystem id="latn" type="numeric" digits="0123456789"/>
<!-- ASCII digits - A numeric system --></pre>
<pre><numberingSystem id="thai" type="numeric" digits="๐๑๒๓๔๕๖๗๘๙"/>
<!-- A numeric system using Thai digits --></pre>
<pre><numberingSystem id="geor" type="algorithmic" rules="georgian"/>
<!-- An algorithmic system - Georgian numerals , rules found in NumberingSystemRules --></pre>
<pre><numberingSystem id="hant" type="algorithmic" rules="zh_Hant/SpelloutRules/spellout-cardinal"/>
<!-- An algorithmic system. Traditional Chinese Numerals --> </pre>
<h3>C.14 <a name="Postal_Code_Validation">Postal Code Validation</a></h3>
<p><span class="dtd"><!ELEMENT postalCodeData (postCodeRegex*) ><br>
<!ELEMENT postCodeRegex (#PCDATA) ><br>
<!ATTLIST postCodeRegex territoryId NMTOKEN #REQUIRED><br></span></p>
<p>The Postal Code regex information can be used to validate
postal codes used in different countries. In some cases, the regex is quite
simple, such as for Germany:</p>
<pre><postCodeRegex territoryId="DE" >\d{5}</postCodeRegex></pre>
<p>The US code is slightly more complicated, since there is
an optional portion:</p>
<pre><postCodeRegex territoryId="US" >\d{5}([ \-]\d{4})?</postCodeRegex></pre>
<p>The most complicated currently is the UK.</p>
<h3>C.15 <a name="Calendar_Preference_Data">Calendar Preference Data</a></h3>
<p><span class="dtd"><!ELEMENT calendarPreferenceData ( calendarPreference* ) ><br>
<!ELEMENT calendarPreference EMPTY ><br>
<!ATTLIST calendarPreference territories NMTOKENS #REQUIRED ><br>
<!ATTLIST calendarPreference ordering NMTOKENS #REQUIRED ><br></span></p>
<p>The calendarPreference element provides a list of commonly used calendar types in a territory.
The ordering attribute indicates the list of calendar types in preferred order. The first calendar type in the
list is the default calendar type for the territory. For example:</p>
<pre><calendarPreference territories="TH" ordering="buddhist gregorian"/></pre>
<p>The calendarPreference element above indicates both Buddhist calendar and Gregorian calendar are
commonly used in Thailand and Buddhist calendar is most preferred.</p>
<h3>C.16 <a name="BCP47_Keyword_Mapping">BCP 47 Keyword Mapping</a></h3>
<p><span class="dtd"><!ELEMENT bcp47KeywordMappings ( mapKeys?, mapTypes* ) ><br>
<!ELEMENT mapKeys ( keyMap* ) ><br>
<!ELEMENT keyMap EMPTY ><br>
<!ATTLIST keyMap type NMTOKEN #REQUIRED ><br>
<!ATTLIST keyMap bcp47 NMTOKEN #REQUIRED ><br>
<!ELEMENT mapTypes ( typeMap* ) ><br>
<!ATTLIST mapTypes type NMTOKEN #REQUIRED ><br>
<!ELEMENT typeMap EMPTY ><br>
<!ATTLIST typeMap type CDATA #REQUIRED ><br>
<!ATTLIST typeMap bcp47 NMTOKEN #REQUIRED ><br></span></p>
<p>
This section defines mappings between Unicode locale identifier key/type
values and their BCP 47 LDML extension
subtag representations. The LDML extension syntax described in section <i>
Section 3.2
<a href="#BCP_47_Tag_Conversion">BCP 47 Tag Conversion</a></i> 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 LDML extension subtags "co-phonebk" by the mapping data below:</p>
<pre> <mapKeys>
...
<keyMap type="collation" bcp47="co"/>
...
</mapKeys>
<mapTypes type="collation">
...
<typeMap type="phonebook" bcp47="phonebk"/>
...
</mapTypes></pre>
<h2>Appendix D: <a name="Language_and_Locale_IDs">Unicode Language and Locale IDs</a></h2>
<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 "-"
versus "_" (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 "-" as a separator in its locale codes. So pragmatically one is forced to treat "-" and "_" 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
"You will have to adjust the value to १,२३४.५६७ from ૭૧,૨૩૪.૫૬" (using Indic digits), they would say that sentence is simply not English. Number format is far
more closely associated with language than it is with region. The same is true for date formats: people would never expect to see intermixed a date in the format
"2003年4月1日" (using Kanji) in text purporting to be purely English. There are regional differences in date and number format — differences which can be important
— but those are different in kind than other language differences between regions.</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'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>
<h3>D.1 <a name="Written_Language">Written Language</a></h3>
<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">"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."</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>"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."</li>
<li>"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."</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 "Theatre Centre News", one may leave it in
the source orthography even if it differs from the publication target orthography. And so on. However, just as clearly, there limits on what is acceptable English,
and "2003年3月20日", for example, is <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'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>
<h2>Appendix E: <a name="Unicode_Sets">Unicode Sets</a></h2>
<p>A UnicodeSet is a set of Unicode characters (and possibly strings) determined by a pattern, following <i>UTS #18: Unicode Regular Expressions</i> [<a href="#URegex">URegex</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>
<p>Patterns are a series of characters bounded by square brackets that contain lists of characters and Unicode property sets. Lists are a sequence of characters
that may have ranges indicated by a '-' between two characters, as in "a-z". The sequence specifies the range of all characters from the left to the right,
in Unicode order. For example, <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>Unicode property sets are specified by any Unicode property and a value of that property, such as <b>[:General_Category=Letter:]</b>. 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="#UCD">UCD</a>].
The syntax for specifying the property sets is an extension of either POSIX or Perl syntax, by the addition of "=<value>". 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, "-", and "_" are ignored. The property name can be omitted for the Category and Script properties,
but is required for other properties. If the property value is omitted, it is assumed to represent a boolean property with the value "true". 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 "Negative", which is a property that excludes all characters
of a given kind. For example, <b>[:^Letter:]</b> matches all characters that are not <b>[:Letter:]</b>.</p>
<table>
<tr>
<th> </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>
<p>These following 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 '&' operator. For example, <b>[[:letter:] & [a-z]] </b></li>
<li>To take the set-difference of two sets, use the '-' operator. For example, <b>[[:letter:] - [a-z]]</b> </li>
<li>To invert a set, place a '^' immediately after the opening '['. For example, <b>[^a-z]</b>. In any other location, the '^' does not have a special meaning.</li>
</ul>
<p>The binary operators '&', '-', 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>One caution: the '&' and '-' 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 'A', enclose the 'A' in a set: <b>[[:Lu:]-[A]]</b>.</p>
<p>A multi-character string can be in a Unicode set, to represent a tailored grapheme cluster for a particular language. The syntax uses curly braces for that
case.</p>
<p>In Unicode Sets, there are two ways to quote syntax characters and whitespace:</p>
<h3>E.1 Single Quote</h3>
<p>Two single quotes represents a single quote, either inside or outside single quotes. Text within single quotes is not interpreted in any way (except for
two adjacent single quotes). It is taken as literal text (special characters become non-special).</p>
<h3>E.2 Backslash Escapes</h3>
<p>Outside of single quotes, certain backslashed characters have special meaning:</p>
<table>
<tr>
<td>\uhhhh </td>
<td>Exactly 4 hex digits; h in [0-9A-Fa-f] </td>
</tr>
<tr>
<td>\Uhhhhhhhh </td>
<td>Exactly 8 hex digits </td>
</tr>
<tr>
<td>\xhh </td>
<td>1-2 hex digits </td>
</tr>
<tr>
<td>\ooo </td>
<td>1-3 octal digits; o in [0-7] </td>
</tr>
<tr>
<td>\a </td>
<td>U+0007 (BELL) </td>
</tr>
<tr>
<td>\b </td>
<td>U+0008 (BACKSPACE) </td>
</tr>
<tr>
<td>\t </td>
<td>U+0009 (HORIZONTAL TAB) </td>
</tr>
<tr>
<td>\n </td>
<td>U+000A (LINE FEED) </td>
</tr>
<tr>
<td>\v </td>
<td>U+000B (VERTICAL TAB) </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) </td>
</tr>
<tr>
<td>\N{name}</td>
<td>The Unicode character named "name".</td>
</tr>
</table>
<p>Anything else following a backslash is mapped to itself, except in an environment where it is defined to have some special meaning. For example, <b>\p{uppercase}</b>
is the set of upper case letters in Unicode.</p>
<p>Any character formed as the result of a backslash escape loses any special meaning and is treated as a literal. In particular, note that \u and \U escapes
create literal characters. (In contrast, Java treats Unicode escapes as just a way to represent arbitrary characters in an ASCII source file, and any resulting
characters are <i><b>not</b></i> tagged as literals.)</p>
<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 'a' alone </td>
</tr>
<tr>
<td nowrap>[a-z] </td>
<td>The set containing 'a' through 'z' 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 characters but 'a' through 'z'.<br>
Thus it is the same as [\u0000-\u0061 \u007B..\U0010FFFF].</td>
</tr>
<tr>
<td nowrap>[[pat1][pat2]] </td>
<td>The union of sets specified by pat1 and pat2 </td>
</tr>
<tr>
<td nowrap>[[pat1]&[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 character 'a' and the multi-character strings "ab" and "ac"</td>
</tr>
<tr>
<td nowrap>[:Lu:] </td>
<td>The set of characters 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 characters belonging to all Unicode categories starting with 'L', that is, <b>[[:Lu:][:Ll:][:Lt:][:Lm:][:Lo:]]</b>. The long form for
this is <b>[:General_Category=Letter:]</b>. </td>
</tr>
</table>
<h2>Appendix F: <a name="Date_Format_Patterns">Date Format Patterns</a></h2>
<p>A date pattern is a string of characters, where specific strings of characters are replaced
with date and time data from a calendar when formatting or used to generate data for a calendar
when parsing. The following
are examples:</p>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse">
<tr>
<th width="50%">Pattern</th>
<th width="50%">Result (in a particular locale)</th>
</tr>
<tr>
<td width="50%">yyyy.MM.dd G 'at' HH:mm:ss zzz</td>
<td width="50%">1996.07.10 AD at 15:08:56 PDT</td>
</tr>
<tr>
<td width="50%">EEE, MMM d, ''yy</td>
<td width="50%">Wed, July 10, '96</td>
</tr>
<tr>
<td width="50%">h:mm a</td>
<td width="50%">12:08 PM</td>
</tr>
<tr>
<td width="50%">hh 'o''clock' a, zzzz</td>
<td width="50%">12 o'clock PM, Pacific Daylight Time</td>
</tr>
<tr>
<td width="50%">K:mm a, z</td>
<td width="50%">0:00 PM, PST</td>
</tr>
<tr>
<td width="50%">yyyyy.MMMM.dd GGG hh:mm aaa</td>
<td width="50%">01996.July.10 AD 12:08 PM</td>
</tr>
</table>
<p><i>When parsing using a pattern, a lenient parse should
be used; see <a href="#Lenient_Parsing">Lenient Parsing</a>.</i></p>
<p>The Date Field Symbol Table below contains the characters used in
patterns to show the appropriate formats for a given locale, such as yyyy for the year. Characters may be used multiple times. For example, if y is used for the year, 'yy' might produce '99', whereas 'yyyy' produces '1999'. For most numerical
fields, the number of characters specifies the field width. For example, if h is the hour, 'h' might produce '5', but 'hh' produces '05'. For some characters,
the count specifies whether an abbreviated or full form should be used, but may have other choices, as given below.</p>
<p><span class="dtd"><!ATTLIST pattern numbers CDATA
#IMPLIED ></span></p>
<p>The numbers attribute is used to indicate that numeric
quantities in the pattern are to be rendered using a numbering system other
than then default numbering system defined for the given locale. The
attribute can be in one of two forms. If the alternate numbering system is
intended to apply to ALL numeric quantities in the pattern, then simply use
the numbering system ID as found in Section C.13 <a href="#Numbering_Systems">Numbering Systems</a>.
To apply the alternate numbering system only to a single field, the syntax
"<letter>=<numberingSystem>" can be used one or more times, separated by
semicolons.</p>
<p class="xmlExample">Examples:<br>
<pattern numbers="hebr">dd/mm/yyyy</pattern><br>
<!-- Use Hebrew numerals to represent numbers in the Hebrew calendar, where
"latn" numbering system is the default --><br>
<br>
<pattern numbers="y=hebr">dd/mm/yyyy</pattern><br>
<!-- Same as above, except that ONLY the year value would be rendered in
Hebrew --><br>
<br>
<pattern numbers="d=thai;m=hans;y=deva">dd/mm/yyyy</pattern><br>
<!-- Illustrates use of multiple numbering systems for a single pattern. -->
</p>
<p>In patterns, two single quotes represents a literal single quote, either inside or outside single quotes. Text within single quotes is not interpreted in any way (except
for two adjacent single quotes). Otherwise all ASCII letter from a to z and A to Z are reserved as syntax characters, and require quoting if they are to represent
literal characters. In addition, certain ASCII punctuation characters may become variable in the future (for
example, ":" being interpreted as the time separator and
'/' as a date separator, and replaced by respective locale-sensitive characters in display).</p>
<blockquote>
<p>Note: the counter-intuitive use of 5 letters for the narrow form of weekdays and months is forced by backwards compatibility.</p>
</blockquote>
<table cellspacing="0" cellpadding="2" border="1">
<caption><a name="Date_Field_Symbol_Table">Date Field Symbol Table</a></caption>
<tr>
<th>Field</th>
<th style="text-align: center">Sym.</th>
<th style="text-align: center">No.</th>
<th>Example</th>
<th>Description</th>
</tr>
<tr>
<th rowspan="3" style="vertical-align: top; text-align: left">era</th>
<td style="text-align: center; vertical-align: top" rowspan="3">G</td>
<td style="text-align: center; vertical-align: top">1..3</td>
<td style="vertical-align: top; text-align: left">AD</td>
<td rowspan="3" style="vertical-align: top; text-align: left">Era - Replaced with the Era string for the current date. One to three letters for the
abbreviated form, four letters for the long form, five for the narrow form.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">Anno Domini</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">A</td>
</tr>
<tr>
<th rowspan="3">year</th>
<td style="text-align: center">y</td>
<td style="text-align: center">1..n</td>
<td>1996</td>
<td>Year. Normally the length specifies the padding, but for two letters it also specifies the maximum length. Example:<div align="center">
<center>
<table border="0" cellpadding="2" cellspacing="0">
<tr>
<th>Year</th>
<th style="text-align: right">y</th>
<th style="text-align: right">yy</th>
<th style="text-align: right">yyy</th>
<th style="text-align: right">yyyy</th>
<th style="text-align: right">yyyyy</th>
</tr>
<tr>
<td>AD 1</td>
<td style="text-align: right">1</td>
<td style="text-align: right">01</td>
<td style="text-align: right">001</td>
<td style="text-align: right">0001</td>
<td style="text-align: right">00001</td>
</tr>
<tr>
<td>AD 12</td>
<td style="text-align: right">12</td>
<td style="text-align: right">12</td>
<td style="text-align: right">012</td>
<td style="text-align: right">0012</td>
<td style="text-align: right">00012</td>
</tr>
<tr>
<td>AD 123</td>
<td style="text-align: right">123</td>
<td style="text-align: right">23</td>
<td style="text-align: right">123</td>
<td style="text-align: right">0123</td>
<td style="text-align: right">00123</td>
</tr>
<tr>
<td>AD 1234</td>
<td style="text-align: right">1234</td>
<td style="text-align: right">34</td>
<td style="text-align: right">1234</td>
<td style="text-align: right">1234</td>
<td style="text-align: right">01234</td>
</tr>
<tr>
<td>AD 12345</td>
<td style="text-align: right">12345</td>
<td style="text-align: right">45</td>
<td style="text-align: right">12345</td>
<td style="text-align: right">12345</td>
<td style="text-align: right">12345</td>
</tr>
</table>
</center></div>
</td>
</tr>
<tr>
<td style="text-align: center">Y</td>
<td style="text-align: center">1..n</td>
<td>1997</td>
<td>Year (in "Week of Year" based calendars). This year designation is used in ISO year-week calendar as defined by ISO 8601, but can be used in non-Gregorian based calendar systems where week date processing is desired. May not always be the same value as calendar year.</td>
</tr>
<tr>
<td style="text-align: center">u</td>
<td style="text-align: center">1..n</td>
<td>4601</td>
<td>Extended year. This is a single number designating the year of this calendar system, encompassing all supra-year fields. For example, for the Julian
calendar system, year numbers are positive, with an era of BCE or CE. An extended year value for the Julian calendar system assigns positive values
to CE years and negative values to BCE years, with 1 BCE being year 0.</td>
</tr>
<tr>
<th rowspan="6" style="vertical-align: top; text-align: left">quarter</th>
<td style="text-align: center; vertical-align: top" rowspan="3">Q</td>
<td style="text-align: center; vertical-align: top">1..2</td>
<td style="vertical-align: top; text-align: left">02</td>
<td rowspan="3" style="vertical-align: top; text-align: left">Quarter - Use one or two for the numerical quarter, three for the abbreviation, or four
for the full name.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Q2</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">2nd quarter</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top" rowspan="3">q</td>
<td style="text-align: center; vertical-align: top">1..2</td>
<td style="vertical-align: top; text-align: left">02</td>
<td rowspan="3" style="vertical-align: top; text-align: left"><b>Stand-Alone</b> Quarter - Use one or two for the numerical quarter, three for the abbreviation,
or four for the full name.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Q2</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">2nd quarter</td>
</tr>
<tr>
<th rowspan="9" style="vertical-align: top; text-align: left">month</th>
<td rowspan="4" style="text-align: center; vertical-align: top">M</td>
<td style="text-align: center; vertical-align: top">1..2</td>
<td style="vertical-align: top; text-align: left">09</td>
<td rowspan="4" style="vertical-align: top; text-align: left">Month - Use one or two for the numerical month, three for the abbreviation, or four for
the full name, or five for the narrow name.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Sept</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">September</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">S</td>
</tr>
<tr>
<td rowspan="4" style="text-align: center; vertical-align: top">L</td>
<td style="text-align: center; vertical-align: top">1..2</td>
<td style="vertical-align: top; text-align: left">09</td>
<td rowspan="4" style="vertical-align: top; text-align: left"><b>Stand-Alone</b> Month - Use one or two for the numerical month, three for the abbreviation,
or four for the full name, or 5 for the narrow name.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Sept</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">September</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">S</td>
</tr>
<tr>
<td style="text-align: center">l</td>
<td style="text-align: center">1</td>
<td>*</td>
<td>Special symbol for Chinese leap month, used in combination
with M. Only used with the Chinese calendar.</td>
</tr>
<tr>
<th rowspan="2">week</th>
<td style="text-align: center">w</td>
<td style="text-align: center">1..2</td>
<td>27</td>
<td>Week of Year.</td>
</tr>
<tr>
<td style="text-align: center">W</td>
<td style="text-align: center">1</td>
<td>3</td>
<td>Week of Month</td>
</tr>
<tr>
<th rowspan="4">day</th>
<td style="text-align: center">d</td>
<td style="text-align: center">1..2</td>
<td>1</td>
<td>Date - Day of the month</td>
</tr>
<tr>
<td style="text-align: center">D</td>
<td style="text-align: center">1..3</td>
<td>345</td>
<td>Day of year</td>
</tr>
<tr>
<td style="text-align: center">F</td>
<td style="text-align: center">1</td>
<td>2<br>
</td>
<td>Day of Week in Month. The example is for the 2nd Wed in July</td>
</tr>
<tr>
<td style="text-align: center">g</td>
<td style="text-align: center">1..n</td>
<td>2451334</td>
<td>Modified Julian day. This is different from the conventional Julian day number in two regards. First, it demarcates days at local zone midnight,
rather than noon GMT. Second, it is a local number; that is, it depends on the local time zone. It can be thought of as a single number that encompasses
all the date-related fields.</td>
</tr>
<tr>
<th rowspan="11" style="vertical-align: top; text-align: left">week<br>
day</th>
<td rowspan="3" style="text-align: center; vertical-align: top">E</td>
<td style="text-align: center; vertical-align: top">1..3</td>
<td style="vertical-align: top; text-align: left">Tues</td>
<td rowspan="3" style="vertical-align: top; text-align: left">Day of week - Use one through three letters for the short day, or four for the full name,
or five for the narrow name.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">Tuesday</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">T</td>
</tr>
<tr>
<td rowspan="4" style="text-align: center; vertical-align: top">e</td>
<td style="text-align: center; vertical-align: top">1..2</td>
<td style="vertical-align: top; text-align: left">2</td>
<td rowspan="4" style="vertical-align: top; text-align: left">Local day of week. Same as E except adds a numeric value that will depend on the local
starting day of the week, using one or two letters. For this example, Monday is the first day of the week.</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Tues</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">Tuesday</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">T</td>
</tr>
<tr>
<td rowspan="4" style="text-align: center; vertical-align: top">c</td>
<td style="text-align: center; vertical-align: top">1</td>
<td style="vertical-align: top; text-align: left">2</td>
<td rowspan="4" style="vertical-align: top; text-align: left"><b>Stand-Alone</b> local day of week - Use one letter for the local numeric value (same
as 'e'), three for the short day, or four for the full name, or five for the narrow name. </td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">3</td>
<td style="vertical-align: top; text-align: left">Tues</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">4</td>
<td style="vertical-align: top; text-align: left">Tuesday</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: top">5</td>
<td style="vertical-align: top; text-align: left">T</td>
</tr>
<tr>
<th>period</th>
<td style="text-align: center">a</td>
<td style="text-align: center">1</td>
<td>AM</td>
<td>AM or PM</td>
</tr>
<tr>
<th rowspan="5">hour</th>
<td style="text-align: center">h</td>
<td style="text-align: center">1..2</td>
<td>11</td>
<td>Hour [1-12]. </td>
</tr>
<tr>
<td style="text-align: center">H</td>
<td style="text-align: center">1..2</td>
<td>13</td>
<td>Hour [0-23].</td>
</tr>
<tr>
<td style="text-align: center">K</td>
<td style="text-align: center">1..2</td>
<td>0</td>
<td>Hour [0-11].</td>
</tr>
<tr>
<td style="text-align: center">k</td>
<td style="text-align: center">1..2</td>
<td>24</td>
<td>Hour [1-24].</td>
</tr>
<tr>
<td style="text-align: center">j</td>
<td style="text-align: center">1..2</td>
<td>n/a</td>
<td>This is a special-purpose symbol. It must not occur in pattern or skeleton data. Instead, it is reserved for use
in APIs doing flexible date pattern generation. In such a context, it requests the preferred format (12 versus 24 hour)
for the language in question, as determined by whether h, H, K, or k is used in the standard short time format for the locale,
and should be replaced by h, H, K, or k before beginning a match against availableFormats data.</td>
</tr>
<tr>
<th>minute</th>
<td style="text-align: center">m</td>
<td style="text-align: center">1..2</td>
<td>59</td>
<td>Minute. Use one or two for zero padding.</td>
</tr>
<tr>
<th rowspan="3">second</th>
<td style="text-align: center">s</td>
<td style="text-align: center">1..2</td>
<td>12</td>
<td>Second. Use one or two for zero padding.</td>
</tr>
<tr>
<td style="text-align: center">S</td>
<td style="text-align: center">1..n</td>
<td>3457</td>
<td>Fractional Second - rounds to the count of letters. (example is for 12.34567)</td>
</tr>
<tr>
<td style="text-align: center">A</td>
<td style="text-align: center">1..n</td>
<td>69540000</td>
<td>Milliseconds in day. This field behaves <i>exactly</i> like a composite of all time-related fields, not including the zone fields. As such, it also
reflects discontinuities of those fields on DST transition days. On a day of DST onset, it will jump forward. On a day of DST cessation, it will jump
backward. This reflects the fact that is must be combined with the offset field to obtain a unique local time value.</td>
</tr>
<tr>
<th rowspan="8" style="vertical-align: top; text-align: left">zone</th>
<td rowspan="2" style="vertical-align: top; text-align: left">z</td>
<td style="vertical-align: top; text-align: left">1..3</td>
<td style="vertical-align: top; text-align: left">PDT<p><i>fallbacks:</i></p>
HPG-8:00<p>GMT-08:00</td>
<td rowspan="2" style="vertical-align: top; text-align: left">Time
Zone -
with
the s<i>pecific non-location format</i>. Where that is unavailable, falls back to <i>
localized GMT format</i>. Use one to three letters for the short
format
or four for the full format. In the short format,
metazone names are not used unless the commonlyUsed flag is on in the locale.<p>For more
information about timezone formats, see <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
<tr>
<td style="vertical-align: top; text-align: left">4</td>
<td style="vertical-align: top; text-align: left">Pacific Daylight Time<p><i>
fallbacks:</i></p>
HPG-8:00<p>GMT-08:00</td>
</tr>
<tr>
<td rowspan="2" style="vertical-align: top; text-align: left">Z</td>
<td style="vertical-align: top; text-align: left">1..3</td>
<td style="vertical-align: top; text-align: left">-0800</td>
<td rowspan="2" style="vertical-align: top; text-align: left">Time
Zone - Use one to three letters for RFC 822
format, four letters for
the localized GMT format.<p>For more information about
timezone formats, see <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
<tr>
<td style="vertical-align: top; text-align: left">4</td>
<td style="vertical-align: top; text-align: left">HPG+8:00<p>
<i>fallbacks:</i></p>
<p>GMT-08:00</td>
</tr>
<tr>
<td rowspan="2" style="vertical-align: top; text-align: left">v</td>
<td style="vertical-align: top; text-align: left">1</td>
<td style="vertical-align: top; text-align: left">PT</td>
<td rowspan="2" style="vertical-align: top; text-align: left">
Time Zone - with the <i>generic</i> <i>non-location format</i>. Where that is unavailable,
uses special fallback rules given in <i><a href="#Time_Zone_Fallback">Appendix J</a></i>.
Use one letter for short format, four for long
format.<p>For more information about timezone formats, see <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
<tr>
<td style="vertical-align: top; text-align: left">4</td>
<td style="vertical-align: top; text-align: left">Pacific Time<p><i>
fallbacks:</i></p>
<p>Pacific Time (Canada)</p>
<p>Pacific Time (Whitehorse)<p>United States (Los Angeles) Time<p>
HPG-8:35</p>
<p>GMT-08:35</td>
</tr>
<tr>
<td rowspan="2" style="vertical-align: top; text-align: left">V</td>
<td style="vertical-align: top; text-align: left">1</td>
<td style="vertical-align: top; text-align: left">PST<p><i>fallbacks:</i></p>
HPG-8:00<p>GMT-08:00</td>
<td style="vertical-align: top; text-align: left">Time Zone -
with the same format as z,
except that metazone timezone abbreviations are to be displayed
if available, regardless of the value of commonlyUsed.<p>
For more information about timezone formats, see <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
<tr>
<td style="vertical-align: top; text-align: left">4</td>
<td style="vertical-align: top; text-align: left">United
States (Los Angeles) Time<p><i>fallbacks:</i></p>
<p>HPG-8:35</p>
<p>GMT-08:35</td>
<td style="vertical-align: top; text-align: left">Time Zone -
with the <i>generic</i> <i>location format</i>. Where that is unavailable,
falls back to the localized GMT format. (Fallback is only necessary with a GMT-style
Time Zone ID, like Etc/GMT-830.)<p>This is especially
useful when presenting possible timezone choices for user selection,
since the naming is more uniform than the v format.</p>
<p>For more information about timezone formats, see <i><a href="#Time_Zone_Fallback">Appendix J: Time Zone Display Names</a>.</i></td>
</tr>
</table>
<p>All non-letter character represent themselves in a pattern, except for the single quote. It is used to 'escape' letters. Two single quotes in a row, whether
inside or outside a quoted sequence, represent a 'real' single quote.</p>
<h3>F.1 <a name="Localized_Pattern_Characters">Localized Pattern Characters</a> (deprecated)</h3>
<p>These are characters that can be used when displaying a date pattern to an end user. This can occur, for example, when a spreadsheet allows users to specify
date patterns. Whatever is in the string is substituted one-for-one with the characters "<span class="tx">GyMdkHmsSEDFwWahKzYe", with the above meanings</span>.
Thus, for example, if "J" is to be used instead of "Y" to mean Year, then the string would be: "<span class="tx">GyMdkHmsSEDFwWahKz<u>J</u>e".</span></p>
<p>This element is deprecated. It is recommended instead that a more sophisticated UI be used for localization, such as using icons to represent the different
formats (and lengths) in the <a href="#Date_Field_Symbol_Table">Date Field Symbol Table</a>.</p>
<h3>F.2 AM / PM</h3>
<p>Even for countries where the customary date format only has a 24 hour format, both the am and pm localized strings must be present and must be distinct from
one another. Note that as long as the 24 hour format is used, these strings will normally never be used, but for testing and unusual circumstances they must
be present.</p>
<h3>F.3 Eras</h3>
<p>There are only two values for an era in a Gregorian calendar, "BC" and "AD". These values can be translated into other languages, like "a.C." and and "d.C."
for Spanish, but there are no other eras in the Gregorian calendar. Other calendars have a different numbers of eras. Care should be taken when translating
the era names for a specific calendar.</p>
<h3>F.4 Week of Year</h3>
<p>Values calculated for the Week of Year field range from 1 to 53 for the Gregorian calendar (they may have different ranges for other calendars). Week 1 for
a year is the first week that contains at least the specified minimum number of days from that year. Weeks between week 1 of one year and week 1 of the following
year are numbered sequentially from 2 to 52 or 53 (if needed). For example, January 1, 1998 was a Thursday. If the first day of the week is MONDAY and the minimum
days in a week is 4 (these are the values reflecting ISO 8601 and many national standards), then week 1 of 1998 starts on December 29, 1997, and ends on January
4, 1998. However, if the first day of the week is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998. The first three days
of 1998 are then part of week 53 of 1997.</p>
<p>Values are similarly calculated for the Week of Month.</p>
<h3>F.5 Week Elements</h3>
<dl>
<dt><b>firstDay</b> </dt>
<dd>A number indicating which day of the week is considered the 'first' day, for calendar purposes. Because the ordering of days may vary between calendar,
keywords are used for this value, such as sun, mon,... These values will be replaced by the localized name when they are actually used. </dd>
<dt><b>minDays (Minimal Days in First Week)</b> </dt>
<dd>Minimal days required in the first week of a month or year. For example, if the first week is defined as one that contains at least one day, this value
will be 1. If it must contain a full seven days before it counts as the first week, then the value would be 7. </dd>
<dt><b>weekendStart, weekendEnd</b> </dt>
<dd>Indicates the day and time that the weekend starts or ends. As with firstDay, keywords are used instead of numbers.</dd>
</dl>
<h2>Appendix G: <a name="Number_Format_Patterns">Number Format Patterns</a></h2>
<h3>G.1 Number Patterns</h3>
<p>The <a href="#NumberElements">NumberElements</a> resource affects how these patterns are interpreted in a localized context. Here are some examples, based
on the French locale. The "." shows where the decimal point should go. The "," shows where the thousands separator should go. A "0" indicates zero-padding:
if the number is too short, a zero (in the locale's numeric set) will go there. A "#" indicates no padding: if the number is too short, nothing goes there.
A "¤" shows where the currency sign will go. The following illustrates the effects of different patterns for the French locale, with the number "1234.567".
Notice how the pattern characters ',' and '.' are replaced by the characters appropriate for the locale.</p>
<blockquote>
<table cellspacing="0" cellpadding="4" border="1">
<tr>
<th width="17%">Pattern</th>
<th width="16%">Currency</th>
<th width="33%">Text</th>
</tr>
<tr>
<td width="17%">#,##0.##</td>
<td width="16%"><i>n/a</i></td>
<td width="33%">1 234,57</td>
</tr>
<tr>
<td width="17%">#,##0.###</td>
<td width="16%"><i>n/a</i></td>
<td width="33%">1 234,567</td>
</tr>
<tr>
<td width="17%">###0.#####</td>
<td width="16%"><i>n/a</i></td>
<td width="33%">1234,567</td>
</tr>
<tr>
<td width="17%">###0.0000#</td>
<td width="16%"><i>n/a</i></td>
<td width="33%">1234,5670</td>
</tr>
<tr>
<td width="17%">00000.0000</td>
<td width="16%"><i>n/a</i></td>
<td width="33%">01234,5670</td>
</tr>
<tr>
<td width="17%" rowspan="2"># ##0.00 ¤</td>
<td width="16%">EUR</td>
<td width="33%">1 234,57 €</td>
</tr>
<tr>
<td width="16%">JPY</td>
<td width="33%">1 235 ¥</td>
</tr>
</table>
</blockquote>
<p>The number of # placeholder characters before the decimal do not matter, since no limit is placed on the maximum number of digits. There should, however,
be at least one zero someplace in the pattern. In currency formats, the number of digits after the decimal also do not matter, since the information in the
supplemental data (see <i><a href="#Supplemental_Data">Appendix C: Supplemental Data</a>)</i> is used to override the number of decimal places — and the rounding
— according to the currency that is being formatted. That can be seen in the above chart, with the difference between Yen and Euro formatting.</p>
<p><i>When parsing using a pattern, a lenient parse should
be used; see <a href="#Lenient_Parsing">Lenient Parsing</a>.</i></p>
<h3>G.2 Special Pattern Characters</h3>
<p>Many characters in a pattern are taken literally; they are matched during parsing and output unchanged during formatting. Special characters, on the other
hand, stand for other characters, strings, or classes of characters. For example, the '#' character is replaced by a localized digit. Often the replacement
character is the same as the pattern character; in the U.S. locale, the ',' grouping character is replaced by ','. However, the replacement is still happening,
and if the symbols are modified, the grouping character changes. Some special characters affect the behavior of the formatter by their presence; for example,
if the percent character is seen, then the value is multiplied by 100 before being displayed. </p>
<p>To insert a special character in a pattern as a literal, that is, without any special meaning, the character must be quoted. There are some exceptions to
this which are noted below. </p>
<blockquote>
<table cellspacing="3" cellpadding="0" summary="Chart showing symbol,
location, localized, and meaning." border="0">
<tr bgcolor="#ccccff">
<th align="left">Symbol </th>
<th align="left">Location </th>
<th align="left">Localized? </th>
<th align="left">Meaning </th>
</tr>
<tr valign="top">
<td>0 </td>
<td>Number </td>
<td>Yes </td>
<td>Digit </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>1-9 </td>
<td>Number </td>
<td>Yes </td>
<td>'1' through '9' indicate rounding. </td>
</tr>
<tr valign="top">
<td>@ </td>
<td>Number </td>
<td>No </td>
<td>Significant digit </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td># </td>
<td>Number </td>
<td>Yes </td>
<td>Digit, zero shows as absent </td>
</tr>
<tr valign="top">
<td>. </td>
<td>Number </td>
<td>Yes </td>
<td>Decimal separator or monetary decimal separator </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>- </td>
<td>Number </td>
<td>Yes </td>
<td>Minus sign </td>
</tr>
<tr valign="top">
<td>, </td>
<td>Number </td>
<td>Yes </td>
<td>Grouping separator </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>E </td>
<td>Number </td>
<td>Yes </td>
<td>Separates mantissa and exponent in scientific notation. <em>Need not be quoted in prefix or suffix.</em> </td>
</tr>
<tr valign="top">
<td>+ </td>
<td>Exponent </td>
<td>Yes </td>
<td>Prefix positive exponents with localized plus sign. <em>Need not be quoted in prefix or suffix.</em> </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>; </td>
<td>Subpattern boundary </td>
<td>Yes </td>
<td>Separates positive and negative subpatterns </td>
</tr>
<tr valign="top">
<td>% </td>
<td>Prefix or suffix </td>
<td>Yes </td>
<td>Multiply by 100 and show as percentage </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>‰<br>
(\u2030)</td>
<td>Prefix or suffix </td>
<td>Yes </td>
<td>Multiply by 1000 and show as per mille </td>
</tr>
<tr valign="top">
<td>¤ (\u00A4) </td>
<td>Prefix or suffix </td>
<td>No </td>
<td>Currency sign, replaced by currency symbol. If doubled, replaced by international currency symbol. If tripled, uses the long form of the decimal
symbol. If present in a pattern, the monetary decimal separator and grouping separators (if available) are used instead of the numeric ones.</td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td>' </td>
<td>Prefix or suffix </td>
<td>No </td>
<td>Used to quote special characters in a prefix or suffix, for example, <code>"'#'#"</code> formats 123 to <code>"#123"</code>. To create a single
quote itself, use two in a row: <code>"# o''clock"</code>. </td>
</tr>
<tr valign="top">
<td>* </td>
<td>Prefix or suffix boundary </td>
<td>Yes </td>
<td>Pad escape, precedes pad character </td>
</tr>
</table>
</blockquote>
<p>A pattern contains a postive and may contain a negative subpattern, for example, "#,##0.00;(#,##0.00)". Each subpattern has a prefix, a numeric part, and
a suffix. If there is no explicit negative subpattern, the negative subpattern is the localized minus sign prefixed to the positive subpattern. That is, "0.00"
alone is equivalent to "0.00;-0.00". If there is an explicit negative subpattern, it serves only to specify the negative prefix and suffix; the number of digits,
minimal digits, and other characteristics are ignored in the negative subpattern. That means that "#,##0.0#;(#)" has precisely the same result as "#,##0.0#;(#,##0.0#)".</p>
<blockquote>
<p><b>Note: </b>The thousands separator and decimal separator in this pattern are always ',' and '.'. They are substituted by the code with the correct
local values according to other fields in CLDR.</p>
</blockquote>
<p>The prefixes, suffixes, and various symbols used for infinity, digits, thousands separators, decimal separators,
and so on may be set to arbitrary values, and
they will appear properly during formatting. <i>However, care must be taken that the symbols and strings do not conflict, or parsing will be unreliable. </i>
For example, either the positive and negative prefixes or the suffixes must be distinct for any parser using this data to be able to distinguish positive from
negative values. Another example is that the decimal separator and thousands separator should be distinct characters, or parsing will be impossible. </p>
<p>The <em>grouping separator</em> is a character that separates clusters of integer digits to make large numbers more legible. It <span class="changed">is </span>commonly used for thousands,
but in some locales it separates ten-thousands. The <em>grouping size</em> is the number of digits between the grouping separators, such as 3 for "100,000,000"
or 4 for "1 0000 0000". There are actually two different grouping sizes: One used for the least significant integer digits, the <em>primary grouping size</em>,
and one used for all others, the <em>secondary grouping size</em>. In most locales these are the same, but sometimes they are different. For example, if the
primary grouping interval is 3, and the secondary is 2, then this corresponds to the pattern "#,##,##0", and the number 123456789 is formatted as "12,34,56,789".
If a pattern contains multiple grouping separators, the interval between the last one and the end of the integer defines the primary grouping size, and the
interval between the last two defines the secondary grouping size. All others are ignored, so "#,##,###,####" == "###,###,####" == "##,#,###,####".</p>
<p>For consistency in the CLDR data, the following conventions should be observed so as to have a canonical representation:</p>
<ul>
<li>All number patterns should be minimal: there should be no leading # marks except to specify the position of the grouping separators (for
example, avoid
##,##0.###).</li>
<li>All formats should have one 0 before the decimal point (for example, avoid #,###.##) </li>
<li>Decimal formats should have three hash marks in the fractional position (for
example, #,##0.###).</li>
<li>Currency formats should have two zeros in the fractional position (for
example, ¤ #,##0.00).<ul>
<li>The exact number of decimals is overridden with the decimal count in supplementary data.</li>
</ul>
</li>
<li>The only time two thousands separators needs to be used is when the number of digits varies, such as for Hindi: #,##,##0.</li>
</ul>
<h3>G.3 Formatting</h3>
<p>Formatting is guided by several parameters, all of which can be specified either using a pattern or using the API. The following description applies to formats
that do not use <a href="#sci">scientific notation</a> or <a href="#sigdig">significant digits</a>. </p>
<ul>
<li>If the number of actual integer digits exceeds the <em>maximum integer digits</em>, then only the least significant digits are shown. For example, 1997
is formatted as "97" if the maximum integer digits is set to 2. </li>
<li>If the number of actual integer digits is less than the <em>minimum integer digits</em>, then leading zeros are added. For example, 1997 is formatted
as "01997" if the minimum integer digits is set to 5. </li>
<li>If the number of actual fraction digits exceeds the <em>maximum fraction digits</em>, then half-even rounding it performed to the maximum fraction digits.
For example, 0.125 is formatted as "0.12" if the maximum fraction digits is 2. This behavior can be changed by specifying a rounding increment and a rounding
mode. </li>
<li>If the number of actual fraction digits is less than the <em>minimum fraction digits</em>, then trailing zeros are added. For example, 0.125 is formatted
as "0.1250" if the mimimum fraction digits is set to 4. </li>
<li>Trailing fractional zeros are not displayed if they occur <em>j</em> positions after the decimal, where <em>j</em> is less than the maximum fraction
digits. For example, 0.10004 is formatted as "0.1" if the maximum fraction digits is four or less. </li>
</ul>
<p><strong>Special Values</strong> </p>
<p><code>NaN</code> is represented as a single character, typically <code>(\uFFFD)</code>. This character is determined by the localized number symbols. This
is the only value for which the prefixes and suffixes are not used. </p>
<p>Infinity is represented as a single character, typically <font size="3">∞ </font><code>(\u221E)</code>, with the positive or negative prefixes and suffixes
applied. The infinity character is determined by the localized number symbols. </p>
<h3>G.4 <a name="sci">Scientific Notation</a></h3>
<p>Numbers in scientific notation are expressed as the product of a mantissa and a power of ten, for example, 1234 can be expressed as 1.234 x 10<sup>3</sup>.
The mantissa is typically in the half-open interval [1.0, 10.0) or sometimes [0.0, 1.0), but it need not be. In a pattern, the exponent character immediately
followed by one or more digit characters indicates scientific notation. Example: "0.###E0" formats the number 1234 as "1.234E3". </p>
<ul>
<li>The number of digit characters after the exponent character gives the minimum exponent digit count. There is no maximum. Negative exponents are formatted
using the localized minus sign, <em>not</em> the prefix and suffix from the pattern. This allows patterns such as "0.###E0 m/s". To prefix positive exponents
with a localized plus sign, specify '+' between the exponent and the digits: "0.###E+0" will produce formats "1E+1", "1E+0", "1E-1",
and so on. (In localized
patterns, use the localized plus sign rather than '+'.) </li>
<li>The minimum number of integer digits is achieved by adjusting the exponent. Example: 0.00123 formatted with "00.###E0" yields "12.3E-4". This only happens
if there is no maximum number of integer digits. If there is a maximum, then the minimum number of integer digits is fixed at one. </li>
<li>The maximum number of integer digits, if present, specifies the exponent grouping. The most common use of this is to generate <em>engineering notation</em>,
in which the exponent is a multiple of three, for example, "##0.###E0". The number 12345 is formatted using "##0.####E0" as "12.345E3". </li>
<li>When using scientific notation, the formatter controls the digit counts using significant digits logic. The maximum number of significant digits limits
the total number of integer and fraction digits that will be shown in the mantissa; it does not affect parsing. For example, 12345 formatted with "##0.##E0"
is "12.3E3". See the section on significant digits for more details. </li>
<li>Exponential patterns may not contain grouping separators. </li>
</ul>
<h3>G.5 <a name="sigdig">Significant Digits</a></h3>
<p>There are two ways of controlling how many digits are shows: (a) significant digits counts, or (b) integer and fraction digit counts. Integer and fraction
digit counts are described above. When a formatter is using significant digits counts, the number of integer and fraction digits is not specified directly,
and the formatter settings for these counts are ignored. Instead, the formatter uses however many integer and fraction digits are required to display the specified
number of significant digits. Examples: </p>
<blockquote>
<table cellspacing="3" cellpadding="0" border="0">
<tr bgcolor="#ccccff">
<th align="left">Pattern </th>
<th align="left">Minimum significant digits </th>
<th align="left">Maximum significant digits </th>
<th align="left">Number </th>
<th align="left">Output</th>
</tr>
<tr valign="top">
<td><code>@@@</code> </td>
<td>3 </td>
<td>3 </td>
<td>12345 </td>
<td><code>12300</code> </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td><code>@@@</code> </td>
<td>3 </td>
<td>3 </td>
<td>0.12345 </td>
<td><code>0.123</code> </td>
</tr>
<tr valign="top">
<td><code>@@##</code> </td>
<td>2 </td>
<td>4 </td>
<td>3.14159 </td>
<td><code>3.142</code> </td>
</tr>
<tr valign="top" bgcolor="#eeeeff">
<td><code>@@##</code> </td>
<td>2 </td>
<td>4 </td>
<td>1.23004 </td>
<td><code>1.23</code> </td>
</tr>
</table>
</blockquote>
<ul>
<li>In order to enable significant digits formatting, use a pattern containing the <code>'@'</code> pattern character. In order to disable significant digits
formatting, use a pattern that does not contain the <code>'@'</code> pattern character.</li>
<li>Significant digit counts may be expressed using patterns that specify a minimum and maximum number of significant digits. These are indicated by the
<code>'@'</code> and <code>'#'</code> characters. The minimum number of significant digits is the number of <code>'@'</code> characters. The maximum number
of significant digits is the number of <code>'@'</code> characters plus the number of <code>'#'</code> characters following on the right. For example, the
pattern <code>"@@@"</code> indicates exactly 3 significant digits. The pattern <code>"@##"</code> indicates from 1 to 3 significant digits. Trailing zero
digits to the right of the decimal separator are suppressed after the minimum number of significant digits have been shown. For example, the pattern
<code>"@##"</code> formats the number 0.1203 as <code>"0.12"</code>. </li>
<li>If a pattern uses significant digits, it may not contain a decimal separator, nor the <code>'0'</code> pattern character. Patterns such as <code>"@00"</code>
or <code>"@.###"</code> are disallowed. </li>
<li>Any number of <code>'#'</code> characters may be prepended to the left of the leftmost <code>'@'</code> character. These have no effect on the minimum
and maximum significant digits counts, but may be used to position grouping separators. For example, <code>"#,#@#"</code> indicates a minimum of one significant
digits, a maximum of two significant digits, and a grouping size of three. </li>
<li>The number of significant digits has no effect on parsing. </li>
<li>Significant digits may be used together with exponential notation. Such patterns are equivalent to a normal exponential pattern with a minimum and maximum
integer digit count of one, a minimum fraction digit count of <code>Minimum Significant Digits - 1</code>, and a maximum fraction digit count of <code>Maximum
Significant Digits - 1</code>. For example, the pattern <code>"@@###E0"</code> is equivalent to <code>"0.0###E0"</code>. </li>
</ul>
<h3>G.6 Padding</h3>
<p>Patterns support padding the result to a specific width. In a pattern the pad escape character, followed by a single pad character, causes padding to be
parsed and formatted. The pad escape character is '*'. For example, <code>"$*x#,##0.00"</code> formats 123 to <code>"$xx123.00"</code>, and 1234 to <code>"$1,234.00"</code>.
</p>
<ul>
<li>When padding is in effect, the width of the positive subpattern, including prefix and suffix, determines the format width. For example, in the pattern
<code>"* #0 o''clock"</code>, the format width is 10. </li>
<li>Some parameters which usually do not matter have meaning when padding is used, because the pattern width is significant with padding. In the pattern
"*<font face="Lucida Sans Unicode"> </font>##,##,#,##0.##", the format width is 14. The initial characters "##,##," do not affect the grouping size or maximum
integer digits, but they do affect the format width. </li>
<li>Padding may be inserted at one of four locations: before the prefix, after the prefix, before the suffix, or after the suffix. No padding can be specified
in any other location. If there is no prefix, before the prefix and after the prefix are equivalent, likewise for the suffix. </li>
<li>When specified in a pattern, the code point immediately following the pad escape is the pad character. This may be any character, including a special
pattern character. That is, the pad escape <em>escapes</em> the following character. If there is no character after the pad escape, then the pattern is
illegal. </li>
</ul>
<p><strong>Rounding</strong> </p>
<p>Patterns support rounding to a specific increment. For example, 1230 rounded to the nearest 50 is 1250. Mathematically, rounding to specific increments is
performed by multiplying by the increment, rounding to an integer, then dividing by the increment. To take a more bizarre example, 1.234 rounded to the nearest
0.65 is 1.3, as follows:</p>
<table border="1" cellpadding="0" cellspacing="0" style="border-collapse: collapse">
<tr>
<th>Original:</th>
<td>1.234</td>
</tr>
<tr>
<th>Divide by increment (0.65):</th>
<td>1.89846...</td>
</tr>
<tr>
<th>Round:</th>
<td>2</td>
</tr>
<tr>
<th>Multiply by increment (0.65):</th>
<td>1.3</td>
</tr>
</table>
<p>To specify a rounding increment in a pattern, include the increment in the pattern itself. "#,#50" specifies a rounding increment of 50. "#,##0.05" specifies
a rounding increment of 0.05. </p>
<ul>
<li>Rounding only affects the string produced by formatting. It does not affect parsing or change any numerical values. </li>
<li>An implementation may allow the specification of a <em>rounding mode</em> to determine how values are rounded. In the absence of such choices, the default
is to round "half-even", as described in IEEE arithmetic. That is, it rounds towards the "nearest neighbor" unless both neighbors are equidistant, in which
case, it rounds towards the even neighbor. Behaves as for round "half-up" if the digit to the left of the discarded fraction is odd; behaves as for round
"half-down" if it's even. Note that this is the rounding mode that minimizes cumulative error when applied repeatedly over a sequence of calculations.</li>
<li>Some locales use rounding in their currency formats to reflect the smallest currency denomination. </li>
<li>In a pattern, digits '1' through '9' specify rounding, but otherwise behave identically to digit '0'. </li>
</ul>
<dl>
<dt> </dt>
<dt><b>decimalFormats</b></dt>
<dd>The normal locale specific way to write a base 10 number.</dd>
<dt><b>currencyFormats</b> </dt>
<dd>Use \u00A4 where the local currency symbol should be. Doubling the currency symbol (\u00A4\u00A4) will output the international currency symbol (a 3-letter
code). </dd>
<dt><b>percentFormats</b> </dt>
<dd>Pattern for use with percentage formatting </dd>
<dt><b>scientificFormats</b> </dt>
<dd>Pattern for use with scientific (exponent) formatting. </dd>
</dl>
<h3>G.7 <a name="Quoting_Rules">Quoting Rules</a></h3>
<blockquote>
<p>Single quotes, (<b>'</b>), enclose bits of the pattern that should be treated literally. Inside a quoted string, two single quotes ('') are replaced
with a single one ('). For example: <tt><u>'X '</u>#<u>' Q '</u></tt> -> <b>X 1939 Q </b>(Literal strings <u>underlined</u>.)</p>
</blockquote>
<h3>G.8 <a name="NumberElements">Number Elements</a></h3>
<blockquote>
<p>Localized symbols used in number formatting and parsing.</p>
</blockquote>
<dl>
<dt><b>decimal</b> </dt>
<dd>- separates the integer and fractional part of the number. </dd>
<dt><b>group</b> </dt>
<dd>-<span class="removed"> groups (for example) units of thousands: 10<sup>6</sup> = 1,000,000. The grouping separator is commonly used for thousands, but in some countries
for ten-thousands. The interval is a constant number of digits between the grouping characters, such as 100,000,000 or 1,0000,0000. If you supply a pattern
with multiple grouping characters, the interval between the last one and the end of the integer is the one that is used. So "#,##,###,####" == "######,####"
== "##,####,####".</span><span class="changed"> separates clusters of integer digits to make large numbers more legible; commonly used for thousands
(grouping size 3, e.g. "100,000,000") or in some locales, ten-thousands (grouping size 4, e.g. "1,0000,0000"). There may be two different
grouping sizes: The <em>primary grouping size</em> used for the least significant integer group, and the <em>secondary grouping size</em> used for more
significant groups; these are not the same in all locales (e.g. "12,34,56,789"). If a pattern contains multiple grouping separators, the interval
between the last one and the end of the integer defines the primary grouping size, and the interval between the last two defines the secondary grouping size.
All others are ignored, so "#,##,###,####" == "###,###,####" == "##,#,###,####".</span> </dd>
<dt><b>list</b> </dt>
<dd>- separates lists of numbers </dd>
<dt><b>percentSign</b> </dt>
<dd>- symbol used to indicate a percentage (1/100th) amount. (If present, the value is also multiplied by 100 before formatting. That way 1.23 → 123%)
</dd>
<dt><b>nativeZeroDigit</b> </dt>
<dd>- Symbol used to indicate a digit in the pattern, or zero if that place would otherwise be empty. For example, with the digit of '0', the pattern "000"
would format "34" as "034", but the pattern "0" would format "34" as just "34". As well, the digits 1-9 are expected to follow the code point of this specified
0 value. </dd>
<dt><b>patternDigit</b> </dt>
<dd>- Symbol used to indicate any digit value, typically #. When that digit is zero, then it is not shown. </dd>
<dt><b>minusSign</b> </dt>
<dd>- Symbol used to denote negative value. </dd>
<dt><b>plusSign</b> </dt>
<dd>- Symbol used to denote positive value. </dd>
<dt><b>exponential</b> </dt>
<dd>- Symbol separating the mantissa and exponent values. </dd>
<dt><b>perMille</b> </dt>
<dd>- symbol used to indicate a per-mille (1/1000th) amount. (If present, the value is also multiplied by 1000 before formatting. That way 1.23 → 1230 [1/000])
</dd>
<dt><b>infinity</b> </dt>
<dd>- The infinity sign. Corresponds to the IEEE infinity bit pattern. </dd>
<dt><b>nan - Not a number</b> </dt>
<dd>- The NaN sign. Corresponds to the IEEE NaN bit pattern. </dd>
<dt><b>currencyDecimal</b> </dt>
<dd>This is used as the decimal separator in currency formatting/parsing, instead of the DecimalSeparator from the <a href="#NumberElements">NumberElements</a>
list. This item is optional in the CLDR. </dd>
<dt><b>currencyGroup</b> </dt>
<dd>This is used as the grouping separator in currency formatting/parsing, instead of the DecimalSeparator from the <a href="#NumberElements">NumberElements</a>
list. This item is optional in the CLDR. </dd>
</dl>
<h2>Appendix H: <a name="Choice_Patterns">Choice Patterns</a></h2>
<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><choice_pattern> = <choice> ( '|' <choice> )*<br>
<choice> = <number><relation><string><br>
<number> = ('+' | '-')? (<font size="3">'∞' | [0-9]+ ('.' [0-9]+)?)<br>
<relation> = '<' | '</font><span style="color: blue">≤'</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 <number> <relation>
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"><span style="color: blue">0≤Rf|1≤Ru|1<Re</span></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 ' characters, as in date or number formats.</p>
<h2>Appendix I: <a name="Inheritance_and_Validity">Inheritance and Validity</a></h2>
<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>
<h3>I.1 Definitions</h3>
<p><i>Blocking</i> elements are those whose subelements do not inherit from parent locales. For example, a <collation> element is a blocking element: everything
in a <collation> element is treated as a single lump of data, as far as inheritance is concerned.
For more information, see <a href="#Valid_Attribute_Values">Appendix K: 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><language type="aa">Afar</language>
<language type="ab">Abkhazian</language></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">Appendix K: 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><ldml version="1.1">
<identity>
<version number="1.1" />
<generation date="2004-06-04" />
<language type="el" />
</identity>
<localeDisplayNames>
<languages>
<language type="ar">Αραβικά</language>
...</pre>
<p>Which gives the following element chains (among others):</p>
<ul>
<li>//ldml[@version="1.1"]/identity/version[@number="1.1"]</li>
<li>//ldml[@version="1.1"]/localeDisplayNames/languages/language[@type="ar"]</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 "identical to". See below for an example.)</p>
<ol>
<li>//ldml[@version="1.1"]/localeDisplayNames</li>
<li>//ldml[@version="1.1"]/localeDisplayNames/languages/language[@type="ar"]</li>
</ol>
<p>An LDML file can be thought of as an ordered list of <i>element pairs</i>: <element chain, data>, 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><</b>//ldml[@version="1.1"]/identity/version[@number="1.1"]<b>, </b>""<b>></b></li>
<li><b><</b>//ldml[@version="1.1"]/localeDisplayNames/languages/language[@type="ar"]<b>, </b>"Αραβικά"<b>></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><</b>//ldml[@version="1.1"]/dates/calendars/calendar[@type='gregorian']/week/weekendStart[@day='sun'][@time='00:00']<b>,</b><br>
<b>""></b></li>
<li><b><</b>//ldml[@version="1.1"]/dates/calendars/calendar[@type='gregorian']/week/weekendStart<b>,</b><br>
[@day='sun'][@time='00:00']<b>></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<font face="Times New Roman"> —</font>except
for distinguishing attributes. Thus the following are equivalent:</p>
<ul>
<li><code>//ldml[@version="1.1"]/localeDisplayNames/languages/language[@type="ar"]</code></li>
<li><code>//ldml[@version="1.1"]/localeDisplayNames/languages/language[@type="ar"][@draft="unconfirmed"]</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><root, de, de_DE, de_DE_xxx></p>
</blockquote>
<h3>I.2 Resolved Data File</h3>
<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 empty.</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 list of pairs it points to.<ol>
<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>
<blockquote>
<p><b>Note:</b> 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.</p>
</blockquote>
<h3>I.3 <b>Valid Data</b></h3>
<p>The attribute <i>draft="x" </i>in LDML means that the data has not been approved by the
subcommittee. (For more information, see
<a href="http://www.unicode.org/cldr/process.html">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 (Afrikans). To indicate that all of the data is <i>unconfirmed</i>, the attribute can be added
to the top level.</p>
<p><code><ldml version="1.1" draft="unconfirmed"><br>
<identity><br>
<version number="1.1" /> <br>
<generation date="2004-06-04" /> <br>
<language type="af" /> <br>
</identity><br>
<characters>...</characters><br>
<localeDisplayNames>...</localeDisplayNames><br>
</ldml></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="unconfirmed" on the enclosing element and marking
the child with draft="approved", such as:</p>
<p><code><ldml version="1.1" draft="unconfirmed"><br>
<identity><br>
<version number="1.1" /> <br>
<generation date="2004-06-04" /> <br>
<language type="af" /> <br>
</identity><br>
<characters draft="approved">...</characters><br>
<localeDisplayNames>...</localeDisplayNames><br>
<dates/><br>
<numbers/><br>
<collations/><br>
</ldml></code></p>
<p>However, normally the draft status should be canonicalized, which means it is pushed down to leaf nodes: see <i><a href="#Canonical_Form">Appendix L: Canonical
Form</a></i>.</p>
<blockquote>
<p><b>Note: </b>A missing draft attribute is <i>not</i> the same as either a true or false value. A missing attribute means instead: <i>inherit</i> the
draft status from enclosing elements and parent locales.</p>
</blockquote>
<p>The attribute <i>validSubLocales</i> allows sublocales in a given tree to be treated as though a file for them were present when there
is not one. It can
be applied to any element. It only has an effect for locales that inherit from the current file where a file is missing, and the elements would
not otherwise
be draft.</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><ldml version="1.1"><br>
<identity><br>
<version number="1.1" /> <br>
<generation date="2004-06-04" /> <br>
<language type="de" /> <br>
<territory type="AT" /> <br>
</identity><br>
</ldml></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 can add to the parent
locale a list of the child locales that should behave as if files were present.</p>
<p><code><ldml version="1.1" validSubLocales="de_AT de_CH de_DE"><br>
<identity><br>
<version number="1.1" /> <br>
<generation date="2004-06-04" /> <br>
<language type="de" /> <br>
</identity><br>
...<br>
</ldml></code></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>I.4 Checking for Draft Status:</h4>
<ol>
<li><b>Parent Locale Inheritance</b><ol>
<li>Walk through the locale chain until you find a locale ID L' with a data file D. (L' may equal L). </li>
<li>Produce the fully resolved data file D' for D.</li>
<li>In D', find the first element pair whose element chain E' is either equivalent to or an extension of E.</li>
<li>If there is no such E', return <i>true</i></li>
<li>If E' is not equivalent to E, truncate E' to the length of E.</li>
</ol>
</li>
<li><b>Enclosing Element Inheritance</b><ol>
<li>Walk through the elements in E', from back to front.<ol>
<li>If you ever encounter draft=<i>x</i>, return <i>x</i></li>
</ol>
</li>
<li>If L' = L, return <i>false</i></li>
</ol>
</li>
<li><b>Missing File Inheritance</b><ol>
<li>Otherwise, walk again through the elements in E', from back to front.<ol>
<li>If you encounter a validSubLocales attribute:<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 "wins" through the full resolution step (data from more specific files replacing
data from less specific ones).</p>
<h3>I.5 Keyword and Default Resolution</h3>
<p>When accessing data based on keywords, the following process is used. Consider the following example:<br>
<br>
The locale 'de' has collation types A, B, C, and no <default> element<br>
The locale 'de_CH' has <default type='B'><br>
<br>
Here are the searches for various combinations.</p>
<table border="1" cellpadding="0" cellspacing="0">
<tr>
<td rowspan="4">1.</td>
<td>de_CH</td>
<td>not found</td>
</tr>
<tr>
<td>de</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>not found: so get the default type in de_CH</td>
</tr>
<tr>
<td>de@collation=B</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="4">2.</td>
<td>de</td>
<td>not found</td>
</tr>
<tr>
<td>root</td>
<td>not found: so get the default type in de, which itself falls back to root</td>
</tr>
<tr>
<td>de@collation=standard</td>
<td>not found</td>
</tr>
<tr>
<td>root@collation=standard</td>
<td><i>found</i></td>
</tr>
<tr>
<td>3.</td>
<td>de@collation=A</td>
<td><i>found</i></td>
</tr>
<tr>
<td rowspan="2">4.</td>
<td>de@collation=standard</td>
<td>not found</td>
</tr>
<tr>
<td>root@collation=standard</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><someElements><br>
<default type='a'/><br>
<someElement type='b'>...</someElement><br>
<someElement type='c'>...</someElement><br>
<b> <!-- no 'a' --></b><br>
</someElements></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 'QA' in root, then the display
name is simply 'QA'. </p>
<h2>Appendix J: <a name="Time_Zone_Fallback">Time Zone Display Names</a></h2>
<p>There are three main types of formats for zone identifiers: GMT, generic (wall time), and standard/daylight. Standard and daylight are equivalent to a particular
offset from GMT, and can be represented by a GMT offset as a fallback. In general, this is not true for the generic format, which is used for picking
timezones or for conveying a timezone for specifying a recurring time (such as a meeting in a calendar). For either purpose, a GMT offset would lose information.</p>
<div style="text-align: left;">
<h4><b>Time Zone Format Terminology</b></h4>
</div>
<div style="text-align: left;">
<p>The following
terminology defines more precisely the formats that are used.</p></div>
<p><b>Generic
non-location format: </b>Reflects "wall
time" (what is on a clock on the wall): used for recurring events, meetings, or anywhere people do
not want to be overly
specific. For example, "10 am Pacific Time" will be GMT-8 in the winter, and GMT-7 in the
summer.</p>
<ul>
<li>"Pacific Time"</li>
<li>"PT" </li>
</ul>
<p><b>Generic
partial location format: </b>Reflects "wall
time": used as a fallback format when the generic non-location format is not specific
enough.</p>
<ul>
<li>"Pacific Time (Canada)"</li>
<li>"Pacific Time (Whitehorse)"</li>
</ul>
<p><b>Generic
location format:</b> Reflects "wall
time": mostly used in populating choice lists for timezones, since the naming is more uniform
than the generic non-location format. It is also a fallback format when there is no translation
for the generic non-location format.</p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">"United States (Los Angeles) Time"</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">"Italy Time". </li>
</ul>
<p><b>Specific
non-location format:</b> Reflects a specific standard or daylight time, which may or may not
be the wall time. For example, "10 am Pacific Standard Time" will be GMT-8 in the winter and in
the summer.</p>
<ul>
<li>"Pacific Standard Time"</li>
<li>"PST"</li>
<li>"Pacific Daylight Time"</li>
<li>"PDT" </li>
</ul>
<p><b>Localized
GMT format:</b> A constant, specific offset from GMT (or UTC), which may be in a translated
form.</p>
<ul>
<li>"HMG+03.30"</li>
<li>"GMT+03:30"</li>
<li>"<span title="Griinuič{0}">Гриинуич</span>+03:30</li>
</ul>
<p><span><b>Localized GMT-zero format:</b> The name for GMT (or UTC) itself
(i.e. an offset of 0 from GMT), which may be in a translated form.</span></p>
<p><b>RFC 822 GMT
format:</b> A constant, specific offset from GMT (or UTC), which always has the same format.</p>
<ul>
<li>"-0800" </li>
</ul>
<p><b><i>Raw Offset </i></b>- an offset from GMT that does not include any daylight savings behavior. For
example, the raw offset for Pacific Time is -8, even though the <i>observed offset</i> may be -8
or -7.</p>
<p><b><i>Metazone
</i></b>- a collection of time zones that share the same behavior and same name during some
period. They may differ in
daylight behavior (whether they have it and when).</p>
<p>For example, the TZID America/Cambridge_Bay is in the following
metazones during various periods:</p>
<blockquote>
<p><font size="2"><timezone type="America/Cambridge_Bay"><br>
<usesMetazone to="1999-10-31 08:00" mzone="America_Mountain"/><br>
<usesMetazone to="2000-10-29 07:00" from="1999-10-31 08:00" mzone="America_Central"/><br>
<usesMetazone to="2000-11-05 05:00" from="2000-10-29 07:00" mzone="America_Eastern"/><br>
<usesMetazone to="2001-04-01 09:00" from="2000-11-05 05:00" mzone="America_Central"/><br>
<usesMetazone from="2001-04-01 09:00" mzone="America_Mountain"/><br>
</timezone></font></p>
</blockquote>
<p> Zones may join or leave a metazone over
time. The data relating between zones and metazones is in the supplemental information; the
locale data is restricted to translations of metazones and zones, with one extra flag for usage
of abbreviations (commonlyUsed).</p>
<p><b>Invariants:</b></p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">At any given
point in time, each zone belongs to exactly one metazone.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em"><i>Except for daylight
savings</i>, at any given time, all zones in a metazone have the same offset at that time.</li>
</ul>
<p><b><i>Golden Zone</i> </b>- the TZDB zone that exemplifies a metazone.
For example, America/New_York is the golden zone for the metazone America_Eastern:</p>
<blockquote>
<p><font size="2"><mapZone other="America_Eastern" territory="001"
type="America/New_York"/></font></p>
</blockquote>
<p><b>Invariants:</b></p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">The golden zones
are those in mapZone supplemental data under the territory "001".</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Every metazone has exactly one golden zone.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Each zone has
at most one metazone for which it is golden.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">The golden zone is in that metazone
during the entire life of the metazone. (The raw offset of the golden zone may change over
time.)</li>
<li>Each other zone must have the same raw offset as the golden
zone, for the entire period that it is in the metazone. (It might not have the same offset
when daylight savings is in effect.)</li>
<li>A golden zone in mapTimezones (supplementalData.xml) must have
reverse mapping in metazoneInfo (metazoneInfo.xml)</li>
</ul>
<p><b><i>Preferred
Zone</i></b> - for a given TZID, the "best" zone out of a metazone for a given country or language.</p>
<p><b>Invariants:</b></p>
<ul>
<li>The preferred zone for a given country XX
are those in mapZone supplemental data under the territory XX.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Every metazone has
at most one preferred zone for a given territory XX.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Each zone has
at most one metazone for which it is preferred for a territory XX.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">The preferred zone
for a given metazone and territory XX is in a metazone M during any time when any other zone
in XX is also in M</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">A preferred
zone in mapTimezones (supplementalData.xml) must have reverse mapping in metazoneInfo (metazoneInfo.xml)</li>
</ul>
<p>For example, for America_Pacific the preferred zone for Canada is
America/Vancouver, and the preferred zone for Mexico is America/Tijuana. The golden zone is
America/Los_Angeles, which is also also the preferred zone for any other country.</p>
<blockquote>
<p><font size="2"><mapZone other="America_Pacific" territory="001"
type="America/Los_Angeles"/><br>
<mapZone other="America_Pacific" territory="CA" type="America/Vancouver"/><br>
<mapZone other="America_Pacific" territory="MX" type="America/Tijuana"/></font></p>
</blockquote>
<p><a name="fallbackFormat"><b>fallbackFormat</b>:</a> a formatting string such as "{1} ({0})",
which is used to combine two pieces of zone information.</p>
<p><b>regionFormat:</b> a formatting string such as "{0} Time".
May use constructed pieces, such as where the {0} is produced from the fallbackFormat. </p>
<h4>Goals</h4>
<p>The timezones are designed so that:</p>
<blockquote>
For any given locale, every <i>time </i>round trips with all
patterns Z, ZZZZ, z, zzzz, v, vvvv, V, VVVV (but not necessarily every timezone). That is,
given a time and a format pattern with a zone string, you can format, then parse, and get
back the same time.<p>Note that the round-tripping is not just important for parsing; it
provides for formatting dates and times in an unambiguous way for users. It is also
important for testing.<br>
<br>
There are exceptions to the above for transition times.</p>
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">With
generic, during the transition when the local time maps to two possible GMT times.
<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">For
example, Java works as follows, favoring standard time:</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Source: Sun Nov 04 01:30:00 PDT 2007 </li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">=>
Formatted: "Sunday, November 4, 2007 1:30:00 AM" </li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">=>
Parsed: Sun Nov 04 01:30:00 PST 2007</li>
</ul>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">When the
timezone changes offset, say from GMT+4 to GMT+5, there can also be a gap. </li>
</ul>
<p>The VVVV format will roundtrip not only the time, but the
canonical timezone.</p>
</blockquote>
When the data for a given format is not available, a fallback format
is used. The fallback order is given in the following by a list.<ol>
<li><b>Specifics</b>
<ul>
<li>z - [short form] specific non-location (but only if
commonlyUsed)<ul>
<li>falling back to localized GMT </li>
</ul>
</li>
<li>zzzz - [long form] specific non-location<ul>
<li>falling back to localized GMT </li>
</ul>
</li>
<li>Z - RFC 822 (no fallback necessary) </li>
<li>ZZZZ - Localized GMT (no fallback necessary) </li>
<li>V - specific non-location (ignores commonlyUsed)<ul>
<li>falling
back to
localized GMT </li>
</ul>
</li>
</ul>
</li>
<li><b>Generics</b>
<ul>
<li>v - [short form] generic non-location, if commonlyUsed<br>
<i>(however, the rules are more complicated, see #4 below)</i><ul>
<li>falling back to generic location</li>
<li>falling back to localized GMT </li>
</ul>
</li>
<li>vvvv - [long form] generic non-location<br>
<i>(however, the rules are more complicated, see #4 below)</i><ul>
<li>falling back to generic location</li>
<li>falling back to localized GMT </li>
</ul>
</li>
<li>VVVV - generic location<ul>
<li>falling back to localized GMT </li>
</ul>
</li>
</ul>
</li>
</ol>
<p>The following process is used for the particular formats, with the
fallback rules as above.</p>
<p>Some of the examples are drawn from real data, while others are for illustration. For illustration the region format is "Hora
de {0}".
The fallback format in the examples is "{1} ({0})", which is what is in root. </p>
<ol>
<li>In <b>all</b> cases, first canonicalize the <i>TZ</i> ID according to the <timezoneData> table in supplemental data. Use that canonical TZID in each of the following steps.<ul>
<li>America/Atka → America/Adak</li>
<li>Australia/ACT → Australia/Sydney</li>
</ul>
</li>
<li>For RFC 822 format ("Z") return the results according to the RFC.<ul>
<li>America/Los_Angeles → "-0800"</li>
</ul>
<p><b>Note: </b>The digits in this case are always from the western digits, 0..9.</p>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">For the localized GMT format,
use the gmtFormat (such as "GMT{0}" or "HMG{0}") with the hourFormat (such as "+HH:mm;-HH:mm"
or "+HH.mm;-HH.mm").<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">America/Los_Angeles → "GMT-08:00" // standard time</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">America/Los_Angeles → "HMG-07:00" // daylight time</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Etc/GMT+3 → "GMT-03.00" // note that <i>TZ</i> tzids have inverse polarity!</li>
</ul>
<p><b>Note:</b> The digits should be whatever are appropriate for the locale used to format the time zone, not necessarily from the western digits, 0..9.
For example, they might be from ०..९.</p>
</li>
<li>For the non-location formats (generic or specific),
<ol>
<li>if there is an explicit translation for the TZID in
timeZoneNames according to type (generic, standard, or daylight) in the resolved locale, return it.<ul>
<li>America/Los_Angeles → "Heure du Pacifique (ÉUA)" // generic</li>
<li>America/Los_Angeles → 太平洋標準時 // standard</li>
<li>America/Los_Angeles → Yhdysvaltain Tyynenmeren kesäaika // daylight</li>
<li>Europe/Dublin → Am Samhraidh na hÉireann // daylight</li>
</ul>
<p><b>Note: </b>This translation may not at all be literal: it would be what is most recognizable for people using the target language.</p>
</li>
<li>Otherwise, if there is a metazone standard format, and the offset
and daylight offset do not change within 184 day +/- interval around the exact
formatted time, use the metazone standard format ("Mountain Standard Time" for
Phoenix). (184 is the smallest number that is at least 6 months AND the smallest
number that is more than 1/2 year (Gregorian)). </li>
<li>Otherwise, if there is a metazone generic format, then do the
following:<ol>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">Compare offset at the requested time with the
preferred zone for the current locale; if same, we use the metazone generic
format. "Pacific Time" for Vancouver if the locale is en-CA, or for Los Angeles
if locale is en-US. Note that the fallback is the golden zone.<ul>
<li>The metazone data actually supplies the preferred zone for a country. If the locale
does not have a country
the likelySubtags supplemental data is used
to get the most likely country.</li>
</ul>
</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">If the zone is the preferred zone for its country
but not for the country of the locale, use the metazone generic format +
(country)<p><b>[Generic partial location] </b>"Pacific Time (Canada)" for the zone
Vancouver in the locale en_MX.</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">If all else fails, use metazone generic format +
(city).<p><b>[Generic partial location]: </b>"Mountain Time (Phoenix)", "Pacific
Time (Whitehorse)"</li>
</ol></li>
<li>Otherwise, fall back.<p><b>
Note:</b> In composing the metazone + city or country: use the <a name="fallbackFormat0">fallbackFormat</a><ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">{1} will
be the city or country</li>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">{0} will be the generic metazone<p>
<i>Example:
</i>United States (Phoenix) Time </li>
</ul></li>
</ol>
</li>
<li>For the generic location format:<ol>
<li>Use as the country name, the explicitly localized country if available,
otherwise the raw country code. If the localized exemplar city is not available, use as the exemplar city the last field of the raw TZID, stripping off
the prefix and turning _ into space.<ul>
<li>CU → "CU" // no localized country name for Cuba</li>
<li>America/Los_Angeles → "Los Angeles" // no localized exemplar city</li>
</ul></li>
<li>From <timezoneData> get the country code for the zone, and determine whether there is only one timezone in the country. If there is only one timezone
or the zone id is in the singleCountries list, format the country name with the regionFormat
(for example, "{0} Time"), and return it.<ul>
<li>Europe/Rome → IT → Italy Time // for English</li>
<li>Africa/Monrovia → LR → "Hora de Liberja"</li>
<li>America/Havana → CU → "Hora de CU" // if CU is not localized</li>
</ul>
<p><b>Note: </b>If a language does require grammatical changes when composing strings, then it should either use a neutral format such as what is in root,
or put all exceptional cases in explicitly translated strings.</p>
<p><span><b>Note: </b><timezoneData> may not have data for new TZIDs. If the country for the zone cannot be resolved,
format the exemplar city (it is unlikely that the localized exemplar city is available in this case, so the exemplar city might be composed
by the last field of the raw TZID as described above) with the regionFormat (for example, "{0} Time"), and return it.</span></p></li>
<li>Otherwise, get both the exemplar city and country name. Format them with the fallbackFormat (for
example, "{1} ({0})"),
and substitute that in the regionFormat (for example, "{0} Time").<ul>
<li style="margin-top: 0.5em; margin-bottom: 0.5em">America/Buenos_Aires → "Argentina (Buenos Aires)" Time<br>
// if the regionFormat is "{0} Time".</li>
<li>America/Buenos_Aires → "Аргентина (Буэнос-Айрес)"<br>
// if both are translated, and the regionFormat is "{0}".</li>
<li>America/Buenos_Aires → "AR (Буэнос-Айрес)"<br>
// if Argentina is not translated.</li>
<li>America/Buenos_Aires → "Аргентина (Buenos Aires)"<br>
// if Buenos Aires is not translated.</li>
<li>America/Buenos_Aires → "AR (Buenos Aires)"<br>
// if both are not translated.</li>
</ul>
<p><b>Note: </b>As with the regionFormat, exceptional cases need to be explicitly translated.</p>
</li>
</ol>
</li>
</ol>
<h3 style="background-color: rgb(255, 255, 255);">
<font color="#000000"><i><b>Parsing</b></i></font></h3>
<p>In parsing, an implementation will be able to either determine the zone id, or a simple offset from GMT for anything formatting according to the above process.</p>
<p>The following is a sample process for how this might be done. It is
only a sample; implementations may use different methods for parsing.</p>
The sample describes the parsing of a zone as if it were an isolated string. In
implementations, the zone may be mixed in with other data (like the time), so the parsing
actually has to look for the longest match, and then allow the remaining text to be parsed for
other content. That requires certain adaptions to the following process.<ol style="background-color: rgb(255, 255, 255);">
<li><font color="#000000">Start with a string S.</font>
</li>
<li><font color="#000000">If S matches the RFC 822 GMT format,
return it.</font>
<ul>
<li>F<font color="#000000">or example, "-0800" => Etc/GMT+8</font>
</li>
</ul>
</li>
<li>If S matches the English or localized
GMT format, return the corresponding TZID
<ul>
<li>Matching should be lenient. Thus
allow for the number formats like: 03, 3, 330, 3:30, 33045 or 3:30:45. Allow +, -, or
nothing. Allow spaces after GMT, +/-, and before number. Allow non-Latin numbers. Allow
UTC or UT (per RFC 788) as synonyms for GMT (GMT, UT, UTC are global formats, always allowed in parsing regardless of locale).
</li>
<li>For example, "GMT+3" or "UT+3" or "HPG+3" =>
Etc/GMT-3</li>
<li><span>When parsing, the absence of a numeric offset should be interpreted as offset 0,
whether in localized or global formats. For example, "GMT" or "UT" or "UTC+0" or
"HPG" => Etc/GMT</span></li>
</ul>
</li>
<li><font color="#000000">If S matches the fallback format,
extract P = {0} [ie, the part in parens in the root format] and N = {1}.<br>
If S does not match, set P = "" and N = S<br>
If N matches the region format, then M = {0} from that format, otherwise M = N.</font>
<ul>
<li><font color="#000000">For example, "United States (Los
Angeles) Time" => N = "United States Time", M = "United States", P = "Los Angeles".</font>
</li>
<li><font color="#000000">For example, "United States Time" => N =
"United States Time", M = "United States", P = "".</font> </li>
<li><font color="#000000">For example, "United States" => N = M =
"United States", P = "".</font> </li>
</ul>
</li>
<li><font color="#000000">If P, N, or M is a localized country,
set C to that value. If C has only one zone, return it.</font>
<ul>
<li><font color="#000000">For example, "Italy Time (xxx)" or "xxx
(Italy)" => Europe/Rome</font> </li>
<li><font color="#000000">For example, "xxx (Canada)" or "Canada Time
(xxx)" => Sets C = CA and continues</font> </li>
</ul>
</li>
<li><font color="#000000">If P is a localized TZID (and not
metazone), return it.</font>
<ul>
<li><font color="#000000">For example, "xxxx (Phoenix)" or "Phoenix
(xxx)" => America/Phoenix</font> </li>
</ul>
</li>
<li><font color="#000000">If N, or M is a localized TZID (and not
metazone), return it.</font>
<ul>
<li><font color="#000000">For example, "Pacific Standard Time (xxx)" =>
"America/Los_Angeles" // this is only if "Pacific Standard Time" is not a metazone
localization.</font></li>
</ul>
</li>
<li><font color="#000000">If N or M is a localized metazone</font><ul>
<li><font color="#000000">If it corresponds to only one TZID,
return it.</font> </li>
<li><font color="#000000">If C is set, look up the Metazone +
Country => TZID mapping, and return that value if it exists</font></li>
<li><font color="#000000">Get the locale's language, and get
the default country from that. Look up the Metazone + DefaultCountry => TZID mapping,
and return that value if it exists.</font> </li>
<li><font color="#000000">Otherwise, lookup Metazone + 001 =>
TZID and return it (that will always exist)</font> </li>
</ul>
</li>
<li><font color="#000000">If you get this far, return an error.</font></li>
</ol>
<blockquote>
<p><span><b>Note: </b>This CLDR date parsing recommendation does not fully handle all
RFC 788 date/time formats, nor is it intended to.</span></p>
</blockquote>
<p>Parsing can be more lenient than the above, allowing for different spacing, punctuation, or other variation.
A
stricter parse would check for consistency between the xxx portions above and the rest, so
"Pacific Standard Time (India)" would give an error.<font color="#000000"><br>
</font></p>
<p>Using this process, a correct parse will roundtrip the location
format (VVVV) back to the canonical zoneid.</p>
<ul>
<li>Australia/ACT → Australia/Sydney → “Sydney (Australia)” → Australia/Sydney</li>
</ul>
<p>The GMT formats (Z and ZZZZ) will return back an offset, and thus lose the original canonical zone id.</p>
<ul>
<li>Australia/ACT → Australia/Sydney → "GMT+11:00" → GMT+11</li>
</ul>
<p>The daylight and standard time formats, and the non-location
formats (z, zzzz, v, and vvvv) may either roundtrip back to the original canonical zone id,
to a zone in the same metazone that time, or to just an offset, depending on the available
translation data. Thus:</p>
<ul>
<li>Australia/ACT → Australia/Sydney → "GMT+11:00" → GMT+11</li>
<li>PST8PDT → America/Los_Angeles → “PST” → America/Los_Angeles</li>
<li>America/Vancouver → “Pacific Time (Canada)” →
America/Vancouver</li>
</ul>
<blockquote>
<p><b>Note: </b>The hoursFormat, preferenceOrdering, and abbreviationFallback
items used in earlier versions of this appendix are deprecated. </p>
</blockquote>
<h2><a name="Valid_Attribute_Values">Appendix K: Valid Attribute Values</a></h2>
<p>The valid attribute values, as well as other validity information is contained in the metadata.xml file. (Some, but not all, of this information could have
been represented in XML Schema or a DTD.)</p>
<p><i>The following specify the ordering of elements / attributes in the file</i></p>
<p> <elementOrder>ldml identity alias localeDisplayNames layout ...</elementOrder><br>
<attributeOrder>type key registry alt source path day date...</attributeOrder></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>
<p><serialElements>variable comment tRule reset p pc s sc t tc q qc i ic x extend first_variable last_variable first_tertiary_ignorable last_tertiary_ignorable
first_secondary_ignorable last_secondary_ignorable first_primary_ignorable last_primary_ignorable first_non_ignorable last_non_ignorable first_trailing
last_trailing</serialElements></p>
</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>
<p><variable id="$calendar" type="choice"><br>
buddhist coptic ethiopic chinese gregorian hebrew islamic islamic-civil japanese arabic civil-arabic thai-buddhist persian<br>
</variable></p>
</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="given" is supplied, it indicates the order of elements when canonicalizing (see below).</p>
<p>The <deprecated> 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><deprecatedItems attributes="draft" values="true false"/> </pre>
</blockquote>
<p> Similarly, the following means that the <i>type</i> attribute is deprecated, but only for the listed elements:</p>
<blockquote>
<pre><deprecatedItems elements="abbreviationFallback default ... preferenceOrdering" attributes="type"/> </pre>
</blockquote>
<p><span class="dtd"><!ELEMENT blockingItems EMPTY ><br>
<!ATTLIST blockingItems elements NMTOKENS #IMPLIED ></span></p>
<p>The blockingItems 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.</p>
<pre><span class="dtd"><!ELEMENT distinguishingItems EMPTY >
<!ATTLIST distinguishingItems exclude ( true | false ) #IMPLIED >
<!ATTLIST distinguishingItems elements NMTOKENS #IMPLIED >
<!ATTLIST distinguishingItems attributes NMTOKENS #IMPLIED ></span></pre>
<p>The distinguishing items 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:</p>
<p> <distinguishingItems<br>
exclude="true"<br>
elements="default measurementSystem mapping abbreviationFallback preferenceOrdering"
attributes="type"/></p>
<h2>Appendix L: <a name="Canonical_Form">Canonical Form</a></h2>
<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><foo>
<pattern>
<somethingElse>
</foo></pre>
<p>It can never require the reverse order in a different element bar.</p>
<pre><foo>
<somethingElse>
<pattern>
</foo></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><span class="dtd"><!ELEMENT currency (alias | (pattern*, displayName?, symbol?, pattern*,
decimal?, group?, special*)) ></span></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>
<h3>L.1 Content</h3>
<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 <foo/>.</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><version number="1.2"/></code>, not <code><version number = "1.2" /></code></li>
<li><code></identity></code>, not <code></identity ></code></li>
</ul>
</li>
<li>All attribute values use double quote ("), not single (').</li>
<li>There are no CDATA sections, and no escapes except those absolutely required.<ul>
<li>no &apos; since it is not necessary</li>
<li>no '&#x61;', it would be just 'a'</li>
</ul>
</li>
<li>All attributes with defaulted values are suppressed. See the <a href="#Defaulted_Values_Table">Defaulted Attributes Table</a>XXX</li>
<li>The draft and alt="proposed.*" 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 "backward" 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><ldml draft="unconfirmed" >
<identity>
<version number="1.2"/>
<generation date="2004-06-04"/>
<language type="en"/>
<territory type="AS"/>
</identity>
<numbers>
<currencyFormats>
<currencyFormatLength>
<currencyFormat>
<pattern>¤#,##0.00;(¤#,##0.00)</pattern>
</currencyFormat>
</currencyFormatLength>
</currencyFormats>
</numbers>
</ldml></pre>
<h3>L.2 Ordering</h3>
<ol>
<li>Element names are ordered by the <a href="http://www.unicode.org/cldr/data/docs/design/ldml_canonical_form.html#Element_Order_Table">Element Order Table</a></li>
<li>Attribute names are ordered by the <a href="http://www.unicode.org/cldr/data/docs/design/ldml_canonical_form.html#Attribute_Order_Table">Attribute Order
Table</a></li>
<li>Attribute value comparison is a bit more complicated, and may depend on the attribute and type. Compare two values by using the following steps:<ol>
<li>If two values are in the <a href="http://www.unicode.org/cldr/data/docs/design/ldml_canonical_form.html#Value_Order_Table">Value Order Table</a>,
compare according to the order in the table. Otherwise if just one is, it goes first.</li>
<li>If two values are numeric [0-9], compare numerically (2 < 12). Otherwise if just one is numeric, it goes first.</li>
<li>Otherwise values are ordered alphabetically</li>
</ol>
</li>
<li>An attribute-value pair is ordered first by attribute name, and then if the attribute names are identical, by the value.</li>
<li>An element is ordered first by the element name, and then if the
element names are identical, by the sorted set of attribute-value pairs
(sorted by #4). For the latter, compare the first pair in each (in
sorted order by attribute pair). If not identical, go to the second
pair, and so on.</li>
<li>Any future additions to the DTD must be structured so as to allow compatibility with this ordering.</li>
<li>See also Appendix K: <a href="#Valid_Attribute_Values">Valid Attribute Values</a></li>
</ol>
<h3>L.3 Comments</h3>
<ol>
<li>Comments are of the form <!-- <i>stuff</i> -->.</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 </ldml></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><eraAbbr>
<era type="0">BC</era> <!-- might add alternate BDE in the future -->
...
<timeZoneNames>
<!-- Note: zones that do not use daylight time need further work -->
<zone type="America/Los_Angeles">
...
<!-- Note: the following is known to be sparse,
and needs to be improved in the future -->
<zone type="Asia/Jerusalem"></pre>
<h3><b>L.4 Canonicalization</b></h3>
<p>The process of canonicalization is fairly straightforward, except for comments. Inline comments will have any linebreaks replaced by a space. There may be
cases where the attachment node is not permitted, such as the following.</p>
<pre> </dayWidth>
<!-- some comment -->
</dayContext>
</days></pre>
<p>In those cases, the comment will be