Normative: Allow Locale.p.getNumberingSystems to return >1 item

[ptomato]

This seems to be a regression from tc39/proposal-intl-locale-info#92 that went unnoticed, accidentally removing the ability to return more than one numbering system from Intl.Locale.prototype.getNumberingSystems.

The sorting criterion added here matches the one that was removed in that change.

Closes: #1071

[ptomato]

Tests in tc39/test262#5067

[anba]

foundLocaleData.[[nu]] returns the numbering systems supported for a specific locale, but not necessarily also in common use. I think the list should be restricted to those in common use, not just a copy sorted according to common use.

For example new Intl.Locale("en").getNumberingSystems().includes("mlym") should return false, because English doesn't use Malayalam digits.

[sffc]

Good point. Perhaps it should be allowed to return a subset of the full list.

https://tc39.es/ecma402/#sec-intl.numberformat-internal-slots

[sffc]

TG2 agreement: https://github.com/tc39/ecma402/blob/main/meetings/notes-2026-06-11.md#normative-allow-localepgetnumberingsystems-to-return-1-item

[ptomato]

@anba Where are you finding the data for numbering systems not in common use? I don't see anywhere in CLDR that "en" supports Malayalam digits. CLDR only exposes "default", "native", and optional "traditional" and "finance" numbering systems for a language ID. For that matter the optional ones are a bit ambiguous how to sort them.

[anba]

NumberingSystemsOfLocale uses %Intl.NumberFormat%.[[LocaleData]] because that allows to get the default numbering system for a locale. The first element of foundLocaleData.[[nu]] is guaranteed to contain the default numbering system per https://tc39.es/ecma402/#sec-internal-slots:

[...] The value of each such locale-named field is a Record in which each element of [[RelevantExtensionKeys]] identifies the name of a field whose value is a non-empty List of Strings representing the type values that are supported by the implementation in the relevant locale for the corresponding Unicode locale extension sequence key, with the first element providing the default value for that key in the locale.

If not just the default numbering system should be returned, then a similar wording as in CalendarsOfLocale can be used. "native", "traditio", or "finance" should be explicitly excluded, because these aren't allowed for Intl.NumberFormat per https://tc39.es/ecma402/#sec-intl.numberformat-internal-slots.

If the numbering systems should be returned which are in common use and additionally also supported by Intl.NumberFormat, then the intersection of %Intl.NumberFormat%.[[LocaleData]].[[<foundLocale>]].[[nu]] and the numbering systems in common use needs to be computed:

1. Let numberingSystems be foundLocaleData.[[nu]].
2. Let numberingSystemsInUse be a List of unique numbering system identifiers in common use for number formatting in locale foundLocale, sorted by descending preference of use in foundLocale.
3. Let list be a new empty List.
4. For each element identifier of numberingSystemsInUse, do
   1. If numberingSystems contains identifier, then
      1. Append identifier to list.
5. Assert: list[0] is numberingSystems[0].

The assertion list[0] is numberingSystems[0] must hold because %Intl.NumberFormat%.[[LocaleData]].[[<foundLocale>]].[[nu]] contains the default numbering system, which is the numbering system most commonly used.

Returning all elements of %Intl.NumberFormat%.[[LocaleData]].[[<foundLocale>]].[[nu]] is incorrect, because implementations (or at least ICU4C-based implementations) support formatting in numbering systems which aren't in common use. For example new Intl.NumberFormat("en-u-nu-mlym").format(123) works in all browsers and returns "൧൨൩", even though Malayalam digits aren't in common use for English.

---

Also: ICU4C doesn't provide any public API to get all numbering systems in common use. There's only unumsys_open which returns the default numbering system. I haven't yet checked if it's possible to retrieve other numbering systems through the UResourceBundle API, similar to how Firefox supports returning all hour-cycles for a locale, so that new Intl.Locale("en-CA").getHourCycles() returns [ "h12", "h23" ] instead of just [ "h12" ].

[ptomato]

I'm talking about data like https://github.com/unicode-org/cldr/blob/2ae632be7a630983fa454e4202ab8ca388e304f8/common/main/ar.xml#L5875-L5879

The structure of the data in CLDR is generally

<defaultNumberingSystem>XXXX</defaultNumberingSystem>
<otherNumberingSystems>
  <native>XXXX</native>
  <traditional>XXXX</traditional>
  <finance>XXXX</finance>
</otherNumberingSystems>

(specified in https://www.unicode.org/reports/tr35/tr35-numbers.html#Number_Elements)

So my question still stands, but let me ask it differently: is there anything in CLDR that specifically says new Intl.NumberFormat("en-u-nu-mlym").format(123) is supported? If so, where?

If yes, then we indeed have a problem with the text in this PR and we need to adjust it to distinguish between "supported" and "in common use" systems.

If no, then I'm assuming that all combinations of new Intl.NumberFormat("LOCALE-u-nu-NUMBERINGSYSTEM").format(123) will produce "123" in the given numbering system. In that case, I think this change is correct, but additionally it's probably not sensible to have the spec talk about "supported" numbering systems for %Intl.NumberFormat%.[[LocaleData]].[[...]].[[nu]], because evidently that field is always the list of all known numbering systems.

[anba]

• new Intl.Locale(...).getNumberingSystems() must only return the numbering systems which are in common use (according to CLDR data).
• Intl.NumberFormat is allowed to support additional numbering systems, even if they aren't in common use.

We don't want new Intl.Locale(...).getNumberingSystems() to return all numbering systems which are supported by Intl.NumberFormat for a specific locale. This a strict requirement.

---

ICU4C-based implementations support all numbering systems with simple digit mappings for any locale. IIRC no browser currently supports algorithmic numbering systems, cf. https://github.com/unicode-org/cldr/blob/main/common/bcp47/number.xml. But ECMA-402 allows that implementations support for example new Intl.NumberFormat("en-u-nu-roman").format(123) to return "CXXIII".

[ptomato]

I've updated the language based on Anba's suggested text, to treat "supported numbering systems" and "numbering systems in common use" as two different sets, of which potentially the only shared element is the default numbering system.

I've kept it in a separate commit for now so that it's clear what changed relative to the text that previously went through the consensus process. I'm not sure if this needs to go through the consensus process again.

[sffc]

TG2 approval: https://github.com/tc39/ecma402/blob/main/meetings/notes-2026-09-17.md#pr-1074-allow-localepgetnumberingsystems-to-return-1-item--consensus-on-updated-text-distinguishing-supported-systems-from-those-in-common-use