This commit adds an initial implementation (without any real locale
support) of Collator Compare Functions, as well as the matching
CompareStrings AO. These two are used to implement the ECMA402 version
of String.localeCompare() and Int.Collator.compare().
We have a fair amount of hard-coded keywords / aliases that can now be
replaced with real data from BCP 47. As a result, the also changes the
awkward way we were previously generating keys. Before, we were more or
less generating keywords as a CSV list of keys, e.g. for the "nu" key,
we'd generate "latn,arab,grek" (ordered by locale preference). Then at
runtime, we'd split on the comma. We now just generate spans of keywords
directly.
Intl.NumberFormat is meant to format both Number and BigInt types. To
prepare for formatting BigInt types, this generalizes our NumberFormat
implementation to operate on Value instances rather than doubles. All
arithmetic is moved to static helpers that can now be updated with
BigInt semantics.
Other Intl objects, such as PluralRules, are to be treated as a
NumberFormat object in some AOs. There's only a handful of fields which
are to be shared between those objects - move them to a base class for
shared reuse.
This also updates the couple of NumberFormat AOs that are meant to
operate on these NumberFormat-like objects.
Alternatively, we could just have objects like PluralRules inherit from
NumberFormat directly. But that messes up the is<NumberFormat> runtime
checks, so this feels safer.
In the one place this will be used, we will know that the NumberFormat
object is non-null. So return a reference, as the AO it is passed off to
also expects a reference.
This is supposed to work as follows (grabbed from SpiderMonkey):
> opt = { type: "language", languageDisplay: "dialect" };
> new Intl.DisplayNames([], opt).of("en-US");
"American English"
> opt = { type: "language", languageDisplay: "standard" };
> new Intl.DisplayNames([], opt).of("en-US");
"English (United States)"
We currently display the "dialect" variant. We will need to figure out
how to display the "standard" variant. I think the way it works is that
we take the display names of "en" (language) and "US" (region) and
format them according to this pattern in localeDisplayNames.json:
"localeDisplayNames": {
"localeDisplayPattern": {
"localePattern": "{0} ({1})",
},
},
But I'd like to confirm this before implementing it.
