Unicode CLDR Bug Reports

Most proposed data (new or corrections) should be entered via the CLDR Survey Tool.

Bugs may be filed for defects in the survey tool, for adding or changing non-language data (such as currency usage), for additions or changes to data that is not yet handled by the survey tool (collation, segmentation, and transliteration), and for feature requests in CLDR or UTS #35: Locale Data Markup Language (LDML).

To file such a bug, go to Locale Bugs. Try to give as much information as possible to help address the issue, and please group related bugs (such as a list of problems with the LDML specification) into a single bug report. Some specific cases are covered below.

Collation Bugs

The exact collation sequence for a given language may be difficult to determine. The base ordering of characters can be fairly straightforward, but there are quite a few other complications involved.

Most standards that specify collation, such as DIN or CS, are not targeted at algorithmic sorting, and are not complete algorithmic specifications. For example, CSN 97 6030 requires transliteration of foreign scripts, but there are many choices as to how to transliterate, and the exact mechanism is not specified. It also specifies that geometric shapes are sorted by the number of vertices and edges, which is, at a minimum, difficult to determine; and are subject to variation in glyphs. The CLDR goals are to match the sorting of exemplar letters and common punctuation and leave everything else to the standard UCA ordering. For more information, see UTS #10: Unicode Collation Algorithm (UCA).

For readability, the rules are presented here in Java/ICU rule format, rather than XML; for the same reason, we prefer the bug reports to also use that format, even though the end result will be in XML. For more information, see ICU Collation Customization.

Please supply some short test cases that illustrate the correct sorting behavior as a list of lines in sorted order. Try to include cases that show the boundary behavior by including high suffixes, such as the following:

Rules:
- & c < cs
- & cs <<< ccs / cs
Test Data:
- c
  cy
  cs
  cscs
  ccs
  cscsy
  ccsy
  csy
  d

Please test out any suggested rules before filing a bug, using Locale Explorer:

Go to the ICU Locale Explorer
Pick the appropriate locale
Follow the instructions at the bottom to use your suggested rules on your suggested test data.
Verify that the proper order results.

Pitfalls

There are a number of pitfalls with collation, so be careful. In some cases, such as Hungarian or Japanese, the rules can be fairly complicated (of course, reflecting that the sorting sequence for those languages is complicated).

Only tailor expected data. We focus on the required collation sequence for a given language with normal data. So we don't include full-width characters for a European collation sequence, such as
- ... CSCS <<< ＣＳＣＳ ...
- ... CSCS <<< \uFF23\uFF33\uFF23\uFF33 ... (equivalently)
Tailor trailing contractions. If a sequence of characters is treated as a unit for collation, it should be entered as a contraction.
& c < ch

One might think that sequence like "dz" doesn't require that, since it would always come after "d" followed by any other letter; it is a "trailing contraction". But in unusual cases, that wouldn't be true; if "dz" is a unit sorted as if it were a distinct letter after "d", one should get the ordering "dα" < "dz". This will only happen if "dz" is a contraction, such as

& d < dz

Watch out for Expansions. If you have a rule like &cs < d, and "cs" has not occurred in a previous rule as a contraction, then this is automatically considered to be the same as &c < d / s; that is, the d expands as if it were a "cs" (actually, primary greater than a "cs", since we wrote "<"). This expansion takes effect until the next primary difference.

So suppose that "ccs" is to behave as if it were "cscs", and take case differences into account. You might try to do this with the rules on the left:

Rules (Wrong)	Actual Effect
& C < cs <<< Cs <<< CS & cscs <<< ccs <<< Cscs <<< Ccs <<< CSCS <<< CCS	& C < cs <<< Cs <<< CS & cs <<< ccs / cs <<< Cscs / cs <<< Ccs / cs <<< CSCS / cs <<< CCS / cs

But since the CSCS has not been made a contraction in previous rules, this produces an automatic expansion, one that continues through the entire sequence of non-primary differences, as shown on the right. This is not what is wanted: each item acts like it expands compared to the previous item. So CCS, for example, will act like it expands to CSCScs!

What you actually want is the following:

Rules (Right)	Actual Effect
& C < cs <<< Cs <<< CS & cscs <<< ccs & Cscs <<< Ccs & CSCS <<< CCS	& C < cs <<< Cs <<< CS & cs <<< ccs / cs & Cs <<< Ccs / cs & CS <<< CCS / CS

In short, when you have expansions, it is always safer and clearer to express them with separate resets. There are only a few exceptions to this, notably when CJK characters are interleaved with Hangul Syllables.

Don't tailor what you don't have to. Example: Maltese was sorting character sequences before a base character using the following style:
& B
< ċ
<<<Ċ
< c
<<<C

This works, but is sub-optimal for two reasons.
1. it tailors c/C when it doesn't need to be; any extra tailoring generally makes for longer sort keys.
2. by tailoring c/C, it puts other those things that are after b/B after c/C instead. See http://www.unicode.org/charts/collation/ for examples.
The correct rules should be:

& [before 1] c < ċ <<< Ċ

This finds the highest primary (that's what the 1 is for) character less than c, and uses that as the reset point. For Maltese, the same technique needs to be used for ġ and ż.
Contractions can be blocked with CGJ, as described in the Unicode Standard and in the Characters and Combining Marks FAQ.
Normally all combinations of case need to be supplied for contractions. That is, if ch is a contraction, then you would have the rules ... ch < cH < Ch < CH. The reason for this is so that all case variants sort at the same primary level: thus lowercasing a string will not affect its primary order. Cases such as McHugh are handled like other instances where contractions should be blocked.

Possible Comparison Sources

Sources and references may be standards or can also be dictionaries, journal style guides (such as The Economist Style Guide for English), and other available sources that provide guidance as to common practice. Online sources are preferred where available, since they can be more easily checked.

The goal is to follow common, customary practice. For example, language or territory display names should use the most recognizable name in common usage. This is generally not the official name. For example, one would use "Switzerland" not "Swiss Confederation".

Here are some possible resources for comparison of locale data. This is not an endorsement of the sources, merely a collation of possibly-useful links. To suggest additions, file a Bug Report.