CLDR/ICU proposal: collation rules for import only

Markus Scherer markus.icu at gmail.com
Mon Apr 21 12:14:41 CDT 2014


On Mon, Apr 21, 2014 at 8:51 AM, John Emmons <emmo at us.ibm.com> wrote:

> I would prefer that we have an attribute for it, so that it is crystal
> clear to everyone exactly what is going on.  I really don't like the idea
> of "0" + ruleset naming convention.
>
Well, the attribute approach has problems, as I said:
- I don't want to have to load the data just to find out if it's
"available".
- I want it to be clear which collation types we add to bcp47/collation.xml
and which we don't.
- I want it to be clear for which collation types to collect display names.

If the CLDR committee feels strongly, then maybe we can use both an
attribute and a naming convention, and make sure that they are used
together (both or neither).

> We have a similar situation in the RBNF rules.  There we use:
>
> <ruleset type="and-feminine" access="private">
>
> I would think that the most logical thing would be to extend the use of
> the access attribute, such that we have:
>
> <rules access="private">
>
Well, <rules> is deprecated and not used any more.

The design doc says <settings private="true">

However, if it's an attribute, then it should really be on the <collation>
element -- and I don't care if it's <collation type="0kana" private="true">
or <collation type="0kana" access="private">.

Or maybe it should be an element, to avoid adding a non-distinguishing
attribute<http://cldr.unicode.org/development/updating-dtds#TOC-Attributes->
.

(All <settings> change collation behavior, but "private" is something
totally different.)

markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20140421/5b466064/attachment.html>


More information about the CLDR-Users mailing list