Html程序
|
2181行
|
39.85 KB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Language" content="en-us">
<meta name="VI60_defaultClientScript" content="JavaScript">
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
<meta name="keywords" content="Unicode, common locale data repository">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Unicode CLDR Process</title>
<link rel="stylesheet" type="text/css" href="http://www.unicode.org/webscripts/standard_styles.css">
</head>
<body style="color: rgb(51, 0, 0);">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td colspan="2">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tbody>
<tr>
<td class="icon"><a href="http://www.unicode.org/"> <img src="http://www.unicode.org/webscripts/logo60s2.gif" alt="[Unicode]" align="middle" border="0" height="33" width="34"></a>
<a class="bar" href="index.html"><font size="3">Common Locale Data Repository</font></a></td>
<td class="bar"><a href="http://www.unicode.org" class="bar">Home</a>
| <a href="http://www.unicode.org/sitemap/" class="bar">Site
Map</a> | <a href="http://www.unicode.org/search/" class="bar">Search</a></td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td colspan="2" class="gray"> </td>
</tr>
<tr>
<td class="navCol" valign="top" width="25%">
<table class="navColTable" border="0" cellpadding="0" cellspacing="4" width="100%">
<tbody>
<tr>
<td class="navColTitle" colspan="2">Contents</td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#introduction">Introduction</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#specification_changes">Specification
Changes</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#data_vetting_process">Data
Submission and Vetting Process</a></td>
</tr>
<tr>
<td class="navColCell" valign="top" width="1em"> </td>
<td class="navColCell" valign="top"><a href="#resolution_procedure">Resolution Procedure</a></td>
</tr>
<tr>
<td class="navColCell" valign="top"> </td>
<td class="navColCell" valign="top"><a href="#Voting_Process">Voting Process</a></td>
</tr>
<tr>
<td class="navColCell" valign="top"> </td>
<td class="navColCell" valign="top"><a href="#prioritization">Prioritization</a></td>
</tr>
<tr>
<td class="navColCell" valign="top"> </td>
<td class="navColCell" valign="top"><a href="#Dot-Dot_Releases">Dot-Dot Releases</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#public_feedback">Public
Feedback</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#data_release_process">Data
Release Process</a></td>
</tr>
<tr>
<td class="navColCell" valign="top"> </td>
<td class="navColCell" valign="top"><a href="#version_numbering">Version Numbering</a></td>
</tr>
<tr>
<td class="navColCell" valign="top"> </td>
<td class="navColCell" valign="top"><a href="#release_schedule">Release Schedule</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#meetings">Meetings and
Communication</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="#officers">Officers</a></td>
</tr>
<tr>
<td class="navColTitle" colspan="2">Unicode
CLDR</td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="index.html">CLDR Project</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="repository_access.html">CLDR
Releases (Downloads)</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="survey_tool.html">CLDR
Survey Tool</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="filing_bug_reports.html">CLDR
Bug Reports</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="comparison_charts.html">CLDR
Charts</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="process.html">CLDR Process</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/reports/tr35/">UTS #35: Locale
Data Markup Language (LDML)</a></td>
</tr>
<tr>
<td class="navColTitle" colspan="2">Related
Links</td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top">Join the <a href="http://www.unicode.org/consortium/consort.html">Unicode
Consortium</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/reports/">Unicode
Technical Reports</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/faq/reports_process.html">Technical
Reports Development and Maintenance Process</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/consortium/utc.html">Unicode
Technical Committee</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/versions/">Versions
of the Unicode Standard</a></td>
</tr>
<tr>
<td class="navColTitle" colspan="2">Other
Publications</td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/standard/standard.html">The
Unicode Standard</a></td>
</tr>
<tr>
<td class="navColCell" colspan="2" valign="top"><a href="http://www.unicode.org/notes/">Unicode
Technical Notes</a></td>
</tr>
</tbody>
</table>
<!-- BEGIN CONTENTS --></td>
<td>
<table>
<tbody>
<tr>
<td class="contents" valign="top">
<div class="body">
<h1>Unicode CLDR Technical Committee Process</h1>
<h2><a name="introduction"></a>1.
Introduction</h2>
<p>This document describes the Unicode CLDR Technical
Committee, and its process for data collection, resolution, public
feedback and release. The process is designed to be light-weight: in
particular, the meetings are frequent, short, and informal. Most of the
work is by email or phone, with a database recording requested changes
in data.</p>
<p>When gathering data for a region and language, it
is important to have multiple sources for that data to produce the most
widely acceptable data. Initial versions of data were based on the best
available sources, but CLDR data will be modified and improved, in
successive versions, by more input from the contributors inside and
outside of the Unicode Consortium.</p>
<p>It is important to note that CLDR is a Repository,
not a Registration. That is, contributors should not expect that their
contributions will simply be adopted into the repository; instead, it
will be vetted against the best available information.</p>
<p>All inputs are open, and gathered via the <a href="survey_tool.html">CLDR Survey Tool</a> or
recorded in a bug/feature request database (<a href="filing_bug_reports.html">CLDR Bug Reports</a>).
Changes in response to requests in the database may be entered into the
repository snapshot over time by the maintainers of the repository, but
the final approval of the release of any version of CLDR is up to the
decision of the CLDR Technical Committee.</p>
<p>For more information on the formal procedures for
the Unicode CLDR Technical Committee, see the <a href="http://www.unicode.org/consortium/tc-procedures.html">Technical
Committee Procedures for the Unicode Consortium</a>.</p>
<h2><a name="specification_changes"></a>2.
Specification Changes</h2>
<p>The <a href="http://www.unicode.org/reports/tr35/">UTS #35: Locale
Data Markup Language (LDML)</a> specification may be changed to
add structure for new kinds of data or other features. Requests for
changes are entered in the bug/feature request database (<a href="filing_bug_reports.html">CLDR Bug Reports</a>).</p>
<p>Structural changes are always
backwards-compatible. That is, previous files will continue to work.
Deprecated elements remain and can be used, although their usage is
strongly discouraged.</p>
<p>There is a standing policy for structural changes
that require non-trivial code for proper implementation, such as time
zone fallback or alias mechanisms. These require the existence of at
least a prototype implementation that demonstrates correct function
according to the proposed specification.</p>
<h2><a name="data_vetting_process"></a>3.
Data Submission and Vetting Process</h2>
<p>Once data for a country and language has been
received, the data from the different sources will be compared to show
agreements and differences. Initial data contributions are normally
marked as draft; this may be changed once the data is
vetted.</p>
<p>Note that there are two types of data in the
repository:</p>
<ol>
<li><b>Common Data: </b>The contents
is decided upon by the CLDR Technical Committee, following its
procedures and this process.</li>
<li><b>Comparison data: </b>The
contributor can be an individual or an organization. Data is normally
gathered by calling public APIs, to ensure that the data matches what
is actually in use. The data is only for comparison, and will not be
changed except where necessary to update the data to match the external
source. The only requirement is that all changed data be versioned, and
the Version Numbering Scheme be used.</li>
</ol>
<p>Contributors are encouraged to use local language
and country contacts, inside and outside their organization, to help
vet current common data and any new proposals for addition or amendment
of common data. In particular, national standards organizations are
encouraged to be involved in the data vetting process.</p>
<p>For CLDR to add a new language just requires that
the proposer to commit to providing at least the minimal localization
(exemplar characters, months, days, date/time formats, translations for
a few countries, languages, currencies, etc.). <span style="font-style: italic;">The exemplar characters,
however, are required before the new locale can be added: see also <a href="filing_bug_reports.html#Exemplar_Characters">Exemplar
Character Sources</a>. </span>The new locale then becomes
available for additional translations and vetting during the next
review cycle.</p>
<h3>3.1 <a name="resolution_procedure">Resolution
Procedure</a></h3>
<p>The following procedure is used when resolving
differences in submitted data. At the end, for each field a single
value will be chosen as optimal, while the others will have an <i>alt=proposed</i>
attribute. The <i>draft</i> attribute on all the values
will be set to one of 4 states:</p>
<ul>
<li><i><span style="font-weight: 700;">unconfirmed</span></i></li>
<li><b><i>provisional</i></b></li>
<li><b><i>contributed (= minimally approved)</i></b></li>
<li><i><b>approved</b>
(equivalent to an absent draft attribute)</i></li>
</ul>
<p>Implementations may choose the level at which they
wish to accept data. They may choose to accept even <b>unconfirmed</b>
data, especially if there is no translated alternative. Approved data
is approved by the Technical Committee, as described by the resolution
process below. This does not mean that the data is guaranteed to be
error-free -- this is simply the best judgment of the committee
according to the process.</p>
<h4>User Levels</h4>
<p>There are multiple levels of access and control:</p>
<table style="text-align: left;" border="1" cellpadding="1" cellspacing="0">
<tbody>
<tr>
<th style="font-weight: bold;">Vetter Level</th>
<td style="font-weight: bold; text-align: center;">Vote</td>
<th style="text-align: left; font-weight: bold;">Description</th>
</tr>
<tr>
<td style="font-style: italic;"><i>Committee Vetters</i></td>
<td style="text-align: center;">8</td>
<td style="text-align: left;">
<ul>
<li>Can vet and submit data for all locales </li>
<li>Can manage users in their organization</li>
<li>Can see the email addresses for all vetters</li>
<li><i>Technical Committee
(TC) members</i></li>
</ul>
</td>
</tr>
<tr>
<td style="font-style: italic;"><i>Expert Vetters</i></td>
<td style="text-align: center;">8</td>
<td style="text-align: left;">
<ul>
<li>Can vet and submit data for a particular set of
locales</li>
<li>Cannot manage other users.</li>
<li>Can see the email addresses for submitted data
in their locales.</li>
</ul>
</td>
</tr>
<tr>
<td><i>Regular Vetters </i></td>
<td style="text-align: center;">4</td>
<td>
<ul>
<li>Can vet and submit data for a particular set of
locales</li>
<li>Cannot manage other users.</li>
<li>Can see the email addresses for submitted data
in their locales.</li>
</ul>
</td>
</tr>
<tr>
<td style="font-style: italic;"><i>Guest Vetters</i></td>
<td style="text-align: center;">1</td>
<td style="text-align: left;">
<ul>
<li>Can vet and submit data for a particular set of
locales</li>
<li>Cannot manage other users. </li>
<li>Cannot see email addresses.</li>
</ul>
</td>
</tr>
<tr>
<td><span style="font-style: italic;">Locked Vetters</span></td>
<td style="text-align: center;">0</td>
<td>
<ul>
<li>If a user is locked or removed, then his/er
vote is zero.</li>
</ul>
</td>
</tr>
</tbody>
</table>
<i> </i>
<ul>
</ul>
<ul>
</ul>
<ul>
</ul>
<p>These levels are decided by the technical committee and the TC representative
for the respective organizations. </p>
<ul>
<li>Unicode TC members (full/institutional/supporting)
can assign its users to Regular or Guest level, and with approval of the TC, users at the Expert level. </li>
<li>Liaison or associate members can assign to Guest, or to other levels with approval of the TC.
<ul>
<li>The liaison/associate member him/erself
gets TC status in order to manage users, but gets a Guest status in
terms of voting, unless the committee approves a higher level.</li>
</ul>
</li>
<li>Users assigned to "<a href="http://unicode.org">unicode.org</a>" are
normally assigned as Guest, but the committee can assign a different
level.</li>
</ul>
<h4><a name="Voting_Process"></a>Voting Process</h4>
<ul>
<li>Each user gets one vote on each value, but the <i>strength</i>
of the vote varies according to the user level according to the table above.
</li>
<li>All values with survey tool errors get <span style="font-style: italic;">zero</span> votes
<ul>
<li>For example, a date pattern of "14.
september" instead of "dd MMM".</li>
<li>They cannot be voted for, and show a
visible error.</li>
<li>Collision errors are an exception. They get normal votes, but are handled below.</li>
</ul>
</li>
<li>For each value, each organization gets a vote
based on the <i>maximum</i> (not cumulative) strength of
the votes of its users who voted on that item.
<ul>
<li>That is, even if an organization has 10
Vetters voting for an value, if the highest level is regular vetter, then the vote count attributed to the
organization as a whole is 4.</li>
</ul>
</li>
<li>If there is a dispute (votes for different
values) within an organization, then the majority vote for that
organization is chosen. If there is a tie, then no vote is counted for
the organization.</li>
<li>Batch data (marked with x999, for example) gets
a status based on committee decision.</li>
</ul>
<p style="font-style: italic;">All fields are then assessed as follows:</p>
<h4><span style="font-weight: bold;">Optimal
Field Value</span></h4>
<p>For each release, there is one optimal field value
determined by the following:</p>
<ul>
<li>Add up the votes for each value from each
organization.</li>
<li>Out of all the possible alternative values for
a given field, pick the one with the most votes, the <span style="font-style: italic;">optimal value</span>.</li>
<li>If there was a tie, pick the least one (in UCA
order).</li>
</ul>
<h4><span style="font-weight: bold;">Draft
Status of Optimal Field Value</span></h4>
<ul>
</ul>
<ol>
<li>Let <span style="font-weight: bold;">O</span>
be the optimal value's vote<span style="font-weight: bold;"></span>,
<span style="font-weight: bold;">N</span>
be the vote of the next best value, and <font size="3"><span style="font-weight: bold;">G</span> be the number of
organizations that voted for the optimal value</font>.</li>
<li>Assign the draft status according to the first
of the conditions below that applies:<font size="3"><br>
</font>
<table style="text-align: left;" border="1" cellpadding="1" cellspacing="0">
<tbody>
<tr>
<th>Resulting Draft Status</th>
<th style="text-align: center;">Condition</th>
</tr>
<tr>
<td style="font-style: italic;"><span style="font-weight: 400;"></span>approved</td>
<td style="text-align: center;"><span style="font-weight: 400;">O <font face="Times New Roman">≥</font>
8 and </span><span style="font-weight: 400;">O
<font face="Times New Roman">≥</font>
2<font face="Arial">×</font>N </span></td>
</tr>
<tr>
<td style="font-style: italic;">contributed</td>
<td style="text-align: center;"><span style="color: black;">O ≥
4 and O > N</span><br style="color: black;">
<span style="font-weight: bold; font-style: italic; color: black;">OR</span><br>
O ≥ 2 and O > N and G ≥ 2</td>
</tr>
<tr>
<td style="font-style: italic;">provisional</td>
<td style="text-align: center;">O <font face="Times New Roman">≥</font> 2 and O <span style="font-weight: 400;"> <font face="Times New Roman">≥</font></span>
N </td>
</tr>
<tr>
<td style="font-style: italic;">unconfirmed</td>
<td style="text-align: center;"><span style="font-style: italic;">otherwise</span></td>
</tr>
</tbody>
</table>
</li>
<li style="color: black;">If the draft status of the previously released
value is better than the new draft status, then no change is made.
Otherwise, the optimal value and its draft status are made part of the
new release.</li>
<ul>
<li>For example, if the new optimal value does
not have the status of <b>approved</b>, and the previous
release had an <span style="font-weight: bold;">approved </span>value
(one that does not have an error and is not a fallback), then that
previously-released value stays <b>approved</b> and
replaces the optimal value in the following steps.</li>
</ul>
<li>If there was an <i>alt=proposed</i>
on the optimal value, the <i>alt=proposed</i> is removed.</li>
</ol>
<ul>
</ul>
<h4>Further Processing</h4>
<br>
<p>After the optimal value is chosen:</p>
<ul>
<li>Collisions errors are resolved by retaining one of the values and
removing the other(s).</li>
<ul>
<li>The choice is based
on the judgment of the committee, typically according to which field is most commonly used.
When an item is removed, an alternate may then become the new optimal
value.</li>
</ul>
<li>All other values with errors are removed.</li>
<li>Non-optimal values are handled as follows:</li>
<ul>
<li>Those with no votes are removed.</li>
<li>Those with votes are marked with <i>alt=proposed
</i>and given the draft status:<span style="font-weight: bold;"> unconfirmed</span></li>
</ul>
</ul>
<p>If a locale does not have minimal data (at least
at a provisional level), then it may be excluded from the release.
Where this is done, it may be restored to the repository for the next
submission cycle.</p>
<p><span style="font-weight: bold;">Note: </span>Starting
with CLDR 1.7, we are planning to save votes across releases, for any
active (unlocked) voters. However, where there are English changes, old
votes will be discarded.</p>
<p>This process can be fine-tuned by the Technical
Committee as needed, to resolve any problems that turn up. A committee
decision can also override any of the above process for any specific
values.</p>
<p>For
more information see the key links in <a href="survey_tool.html">CLDR Survey Tool</a> (especially the Vetting Phase).<br>
<span style="font-weight: 700;"></span></p>
<p><span style="font-weight: 700;">Notes:</span></p>
<ul>
<li>If data has a formal problem, it can be fixed
directly (in CVS) without going through the above process. Examples
include:
<ul>
<li>syntactic problems in pattern, extra
trailing spaces, inconsistent decimals, mechanical sweeps to change
attributes, translatable characters not quoted in patterns, changing '
(punctuation mark) to curly apostrophe or s-cedilla to s-comma-below,
removing disallowed exemplar characters (non-letter, number, mark,
uppercase when there is a lowercase).</li>
<li>These are changed in-place, without
changing the draft status.</li>
</ul>
</li>
<li>Linguistically-sensitive data should always go
through the survey tool. Examples include:
<ul>
<li>names of months, territories, number
formats, changing ASCII apostrophe to U+02BC modifier letter apostrophe
or U+02BB modifier letter turned comma, or U+02BD modifier letter
reversed comma, adding/removing normal exemplar characters.</li>
</ul>
</li>
<li>The TC committee can authorize bulk submissions
of new data directly (CVS), with all new data marked
draft="unconfirmed" (or other status decided by the committee), but
only where the data passes the CheckCLDR console tests.</li>
<li>The survey tool does not currently handle all
CLDR data. For data it doesn't cover, the regular bug system is used to
submit new data or ask for revisions of this data. In particular:
<ul>
<li>Collation, transforms, or text
segmentation, which are more complex.
<ul>
<li>For collation data, see the comparison
charts at <a href="http://www.unicode.org/cldr/comparison_charts.html">http://www.unicode.org/cldr/comparison_charts.html</a>
or the XML data at <a href="http://unicode.org/cldr/data/common/collation/">http://unicode.org/cldr/data/common/collation/</a>
</li>
<li>For transforms, see the XML data at <a href="http://unicode.org/cldr/data/common/transforms/">http://unicode.org/cldr/data/common/transforms/</a>
</li>
</ul>
</li>
<li>Non-linguistic locale data:
<ul>
<li>XML data: <a href="http://unicode.org/cldr/data/common/supplemental/">http://unicode.org/cldr/data/common/supplemental/</a>
</li>
<li>HTML view: <a href="http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html">http://www.unicode.org/cldr/data/diff/supplemental/supplemental.html</a>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>3.3 <a name="prioritization">Prioritization</a></h3>
<p>There may be conflicting common practices or
standards for a given country and language. Thus LDML provides keyword
variants to reflect the different practices. For example, for German it
allows the distinction between PHONEBOOK and DICTIONARY collation.</p>
<p>When there is an existing national standard for a
country that is widely accepted in practice, the goal is to follow that
standard as much as possible. Where the common practice in the country
deviates from the national standard, or if there are multiple
conflicting common practices, or options in conforming to the national
standard, or conflicting national standards, multiple variants may be
entered into the CLDR, distinguished by keyword variants or variant
locale identifiers.</p>
<p>Where a data value is identified as following a
particular national standard (or other reference), the goal is to keep
that data aligned with that standard. There is, however, no guarantee
that data will be tagged with any or all of the national standards that
it follows.</p>
<h3>3.4 <a name="Dot-Dot_Releases">Dot-Dot
Releases</a></h3>
<p>Dot-dot releases, such as 1.4.1, are issued
whenever the standard identifiers change (that is, BCP 47 identifiers,
Time zone identifiers, or ISO 4217 Currency identifiers).
Updates to identifiers will also mean updating the English names for
those identifiers.</p>
<p>Corrigenda may also be included in dot-dot
releases. Dot-dot releases may also be issued if there are substantive
changes to supplemental (non-language) data. An example of supplemental
data additions would be adding more transforms, or adding more
script-language info.<br>
<br>
Normally there are no dot-dot releases for language data, but the
committee may decide to issue one if the situation warrants. Normally
there are no major changes in the specification. </p>
<p>The structure and DTD may change, but except for
additions or for small bug fixes, data will not be changed in a way
that would affect the content of resolved data.</p>
<h2>4. <a name="public_feedback">Public
Feedback Process</a></h2>
<p>The public can supply formal feedback into CLDR
via the <a href="http://unicode.org/cldr/apps/survey/">Survey
Tool</a> or by filing a <a href="filing_bug_reports.html">Bug
Report or Feature Request</a>. There is also a public forum for
questions at <a href="http://www.unicode.org/consortium/distlist.html#cldr_list">CLDR
Mailing List</a> (details on archives are found there).</p>
<p>Anyone can also asked to be added to a list that
will receive notification of new CLDR bugs, so they can track issues if
they want. Anyone can also to reply to any bug report to add comments
or questions.</p>
<ul>
<li>To subscribe, send a note to
"ecartis+unicode.org" (use an <i>at sign</i> instead of
the +) and put "subscribe cldr-bugrfe" in the subject line.</li>
<li>To unsubscribe, put "unsubscribe cldr-bugrfe"
in the subject line instead.</li>
</ul>
<p>There is also a members-only <a href="http://www.unicode.org/members/index.html#cldr"> CLDR
mailing list</a> for members of the CLDR Technical Committee.</p>
<p><a href="http://www.unicode.org/review/">Public
Review Issues</a> may be posted in cases where broader public
feedback is desired on a particular issue.</p>
<p>Be aware that changes and updates to CLDR will
only be taken in response to information entered in the <a href="http://unicode.org/cldr/apps/survey/">Survey Tool</a>
or by filing a <a href="filing_bug_reports.html">Bug
Report or Feature Request</a>. Discussion on public mailing lists
is <i>not</i> monitored; no actions will be taken in
response to such discussion -- only in response to filed bugs. The
process of checking and entering data takes time and effort; so even
when bugs/feature requests are accepted, it may take some time before
they are in a release of CLDR.</p>
<h2><a name="data_release_process"></a>5.
Data Release Process</h2>
<h3>5.1 <a name="version_numbering">Version
Numbering</a></h3>
<p>The locale data is frozen per version. Once a
version is released, it is never modified. Any changes, however minor,
will mean a newer version of the locale data being released. The
versioning scheme is x.y.z, where z is incremented for bug fixes, y is
incremented for any additions (such as new locale data or LDML
elements), and x is incremented for any major changes in format.</p>
<h3>5.2 <a name="release_schedule">Release
Schedule</a></h3>
<p>Early releases of a version of the common locale
data will be issued as either alpha or beta releases, available for
public feedback. The dates for the next scheduled release will be on <a href="index.html">CLDR Project</a>.</p>
<p>The schedule milestones are:</p>
<table style="border-collapse: collapse;" id="AutoNumber1" border="1" bordercolor="#111111" cellpadding="2" cellspacing="0">
<tbody>
<tr>
<td><b>Design (p1)</b></td>
<td>All the proposed design changes have been
accepted in place for changes in structure, and tools. All the DTD and specification changes are
made according to proposed design. The tools are updated to support the
new structure, including the survey tool for displaying, collecting,
and vetting data.</td>
</tr>
<tr>
<td style="white-space: nowrap;"><b>Survey Tool Beta (p2)</b></td>
<td>Users can try out the survey tool and supply feedback</td>
</tr>
<tr>
<td><span style="font-weight: bold;">Data Submission</span></td>
<td>Users can add data and vet (vote for) for data</td>
</tr>
<tr>
<td><b>Data Vetting</b></td>
<td>Users can vet (vote for) data, and can add in certain disputed cases</td>
</tr>
<tr>
<td><span style="font-weight: bold;">Data Resolution</span></td>
<td>Data resolution, data/structure verification and correction by the committee.</td>
</tr>
<tr>
<td><span style="font-weight: bold;">Final Candidate</span></td>
<td>Final Candidate available for testing. Only showstoppers fixed.</td>
</tr>
<tr>
<td><b>Release</b></td>
<td>Released, stable, referenceable version.</td>
</tr>
</tbody>
</table>
<p>Each phase ends at 24:00 (midnight) on the day in question.</p>
<h2><a name="meetings"></a>6.
Meetings and Communication</h2>
<p>The currently-scheduled meetings are listed on the
<a href="http://www.unicode.org/timesens/calendar.html">Unicode
Calendar</a>. Meetings are held by phone, every week at 8:00
Pacific Time (-08:00 GMT in winter, -07:00 GMT in summer). Some
meetings may be skipped if they conflict with holidays or other Unicode
meetings.</p>
<p>There is an internal email list for the Unicode
CLDR Technical Committee, open to Unicode members and invited experts.
All national standards bodies who are interested in locale data are
also invited to become involved by establishing a <a href="http://www.unicode.org/consortium/join.html">Liaison
membership</a> in the Unicode Consortium, to gain access to this
list.</p>
<p>Notification of the telephone numbers and
passcode, and agenda, and any change in schedule are sent out on the
this email list.</p>
<h2><a name="officers"></a>7.
Officers</h2>
<p>The current Technical Committee Officers are:</p>
<ul>
<li>Chair: Mark Davis (Google)</li>
<li>Vice-Chair: John Emmons (IBM)</li>
</ul>
<blockquote> </blockquote>
</div>
</td>
</tr>
</tbody>
</table>
<hr width="50%">
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td><a href="http://www.unicode.org/copyright.html">
<img src="http://www.unicode.org/img/hb_notice.gif" alt="Access to Copyright and terms of use" border="0" height="50" width="216"></a></td>
</tr>
</tbody>
</table>
<script language="Javascript" type="text/javascript" src="http://www.unicode.org/webscripts/lastModified.js">
</script>
</center>
</div>
</td>
</tr>
</tbody>
</table>
</body>
</html>