CLDR-18963 Allow numberSystem attribute for currency element

[btangmu]

-Revise ldml.dtd to allow numberSystem attribute for currency element

-Delete the (disabled) check for numberSystem in CheckNumbers.java

CLDR-18963

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[btangmu]

I think this PR is between essentially the same rock and hard place as the previous PR (#5149). Here we're adding numberSystem for currency not for pattern, but otherwise it's the same problem.

Per testAttributeOrder status (distinguished before value before metadata), we need numberSystem (distinguished) before draft (metadata). See:

public enum AttributeStatus {
    distinguished("§d"),
    value("§v"),
    metadata("§m︎");

But, per MergeLists, we need draft before numberSystem for consistency with, e.g.,

<!ELEMENT decimal ( #PCDATA ) >
<!ATTLIST decimal alt NMTOKENS #IMPLIED >
    <!--@MATCH:literal/variant, us, official-->
<!ATTLIST decimal draft (approved | contributed | provisional | unconfirmed | true | false) #IMPLIED >
    <!--@METADATA-->
    <!--@DEPRECATED:true, false-->
<!ATTLIST decimal references CDATA #IMPLIED >
    <!--@METADATA-->
<!ATTLIST decimal numberSystem CDATA #IMPLIED >
    <!--@MATCH:bcp47/nu-->

A most ingenious paradox.

[macchiati]

A refinement of my previous advice.

The order is vital among distinguishing attributes (no @metadata and no @value) and @value attributes, but not with @metadata attributes. So you can move the @metadata items (keeping their same relative order) to the end of the items.

[macchiati]

It is still good that we tripped across this in the first PR, because having (optional) numberSystem attributes for currency elements is the better structure.

[btangmu]

move the @metadata items (keeping their same relative order) to the end of the items

I've just tried that locally. Starting with

<!ATTLIST currency type NMTOKEN "standard" >
    <!--@MATCH:validity/currency-->
<!ATTLIST currency alt NMTOKENS #IMPLIED >
    <!--@MATCH:literal/variant-->
<!ATTLIST currency draft (approved | contributed | provisional | unconfirmed | true | false) #IMPLIED >
    <!--@METADATA-->
    <!--@DEPRECATED-->
<!ATTLIST currency references CDATA #IMPLIED >
    <!--@METADATA-->
<!ATTLIST currency validSubLocales CDATA #IMPLIED >
    <!--@VALUE-->
    <!--@DEPRECATED-->

The item to be added is

<!ATTLIST currency numberSystem CDATA #IMPLIED >
    <!--@MATCH:bcp47/nu-->

The two metadata items to be moved are draft and references. So I have tried this:

<!ATTLIST currency type NMTOKEN "standard" >
    <!--@MATCH:validity/currency-->
<!ATTLIST currency alt NMTOKENS #IMPLIED >
    <!--@MATCH:literal/variant-->
<!ATTLIST currency validSubLocales CDATA #IMPLIED >
    <!--@VALUE-->
    <!--@DEPRECATED-->
<!ATTLIST currency numberSystem CDATA #IMPLIED >
    <!--@MATCH:bcp47/nu-->
<!ATTLIST currency draft (approved | contributed | provisional | unconfirmed | true | false) #IMPLIED >
    <!--@METADATA-->
    <!--@DEPRECATED-->
<!ATTLIST currency references CDATA #IMPLIED >
    <!--@METADATA-->

The test result is:

java.lang.IllegalArgumentException: Inconsistent requested ordering: cannot merge if we have [...A...B...] and [...B...A...]: {references=[draft, references], standard=[draft, standard, references, validSubLocales], validSubLocales=[draft, standard, references, validSubLocales], numberSystem=[draft, validSubLocales, numberSystem], draft=[validSubLocales, numberSystem, draft, references]}
	at org.unicode.cldr.util.MergeLists.merge(MergeLists.java:68)

That is:

references     =[draft, references]
standard       =[draft, standard, references, validSubLocales]
validSubLocales=[draft, standard, references, validSubLocales]
numberSystem   =[draft, validSubLocales, numberSystem]
draft          =[validSubLocales, numberSystem, draft, references]

Meaning, I think, that MergeLists won't accept validSubLocales before draft since elsewhere there is validSubLocales after draft. Am I understanding your instructions and the result correctly?

It would help if the algorithm and error reporting of MergeLists were less mysterious. Would it be worthwhile to add some comments and debugging output to make it unambiguous what A and B are in "cannot merge if we have [...A...B...] and [...B...A...]"? Here it seems A and B could be validSubLocales and draft, or draft and numberSystem, or references and validSubLocales...

[macchiati]

You can leave validSubLocales where it was. Since it is depreciated, it doesn't matter.

…

On Wed, Nov 26, 2025, 14:15 Tom Bishop ***@***.***> wrote: *btangmu* left a comment (unicode-org/cldr#5205) <#5205 (comment)> move the @metadata <https://github.com/metadata> items (keeping their same relative order) to the end of the items I've just tried that locally. Starting with <!ATTLIST currency type NMTOKEN "standard" > ***@***.***:validity/currency--> <!ATTLIST currency alt NMTOKENS #IMPLIED > ***@***.***:literal/variant--> <!ATTLIST currency draft (approved | contributed | provisional | unconfirmed | true | false) #IMPLIED > ***@***.***> ***@***.***> <!ATTLIST currency references CDATA #IMPLIED > ***@***.***> <!ATTLIST currency validSubLocales CDATA #IMPLIED > ***@***.***> ***@***.***> The item to be added is <!ATTLIST currency numberSystem CDATA #IMPLIED > ***@***.***:bcp47/nu--> The two metadata items to be moved are draft and references. So I have tried this: <!ATTLIST currency type NMTOKEN "standard" > ***@***.***:validity/currency--> <!ATTLIST currency alt NMTOKENS #IMPLIED > ***@***.***:literal/variant--> <!ATTLIST currency validSubLocales CDATA #IMPLIED > ***@***.***> ***@***.***> <!ATTLIST currency numberSystem CDATA #IMPLIED > ***@***.***:bcp47/nu--> <!ATTLIST currency draft (approved | contributed | provisional | unconfirmed | true | false) #IMPLIED > ***@***.***> ***@***.***> <!ATTLIST currency references CDATA #IMPLIED > ***@***.***> The test result is: java.lang.IllegalArgumentException: Inconsistent requested ordering: cannot merge if we have [...A...B...] and [...B...A...]: {references=[draft, references], standard=[draft, standard, references, validSubLocales], validSubLocales=[draft, standard, references, validSubLocales], numberSystem=[draft, validSubLocales, numberSystem], draft=[validSubLocales, numberSystem, draft, references]} at org.unicode.cldr.util.MergeLists.merge(MergeLists.java:68) That is: references =[draft, references] standard =[draft, standard, references, validSubLocales] validSubLocales=[draft, standard, references, validSubLocales] numberSystem =[draft, validSubLocales, numberSystem] draft =[validSubLocales, numberSystem, draft, references] Meaning, I think, that MergeLists won't accept validSubLocales before draft since elsewhere there is validSubLocales after draft. Am I understanding your instructions and the result correctly? It would help if the algorithm and error reporting of MergeLists were less mysterious. Would it be worthwhile to add some comments and debugging output to make it unambiguous what A and B are in "cannot merge if we have [...A...B...] and [...B...A...]"? Here it seems A and B could be validSubLocales and draft, or draft and numberSystem, or references and validSubLocales... — Reply to this email directly, view it on GitHub <#5205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMDRR2UWSXNRUT6IN2T36YQ7HAVCNFSM6AAAAACNFQW2SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBTGM4DQOBYGE> . You are receiving this because your review was requested.Message ID: ***@***.***>