Currently at stage 2

Only a draft patch for now until the various issues I've reported at https://github.com/tc39/proposal-intl-locale-info/issues have been resolved resp. clarified.

LocaleObject doesn't use a reserved slot to store the [[Calendar]] internal
slot, so we have to extract any Unicode "ca" extension sequences directly
from the locale identifier via GetUnicodeExtension().

If no "ca" Unicode keyword is present in the locale, we're calling into ICU
to retrieve all commonly used calendars of the locale (via
ucal_getKeywordValuesForLocale()).

ICU has certain internal limits on how large the input locale can be, so to make
sure we don't run into these limits, the LocaleLSR helper class extracts the
language, script, and region subtags of a locale. The LSR-subtags are guaranteed
to fit into the ICU limits.

Depends on D115223

Similar to part 2, but this time for collations instead of calendars.

Depends on D116467

Unfortunately support for hour cycles is more convoluted, because ICU doesn't
have public APIs to get the complete set of supported hour cycles for a locale:

There is udatpg_getDefaultHourCycle(), but that function only returns the
default hour cycle, but not any additionally allowed hour cycles. So we have to
do it the hard way and directly read ICU resource bundles to get the data we
need for this feature.

Depends on D116468

There is no way to figure out which numbering systems are commonly used by a
specific locale (because this data isn't even recorded in CLDR), so we can
only return the default numbering system.

Depends on D116469

Time zone names are canonicalised and sorted alphabetically. Canonicalisation
has the usual problem that ICU uses CLDR time zone canonicalisation, whereas
the spec requires IANA canonicalisation, so we have to perform some extra
steps here.

Depends on D116470

Depends on D116471

This code is based on the existing code in js::intl_GetCalendarInfo() with
the exception of gracefully handling UCAL_WEEKEND_{ONSET,CEASE} instead of
throwing an error.

Depends on D116472

Patches split for review, but I'm still waiting for the open spec issues to be resolved before actually requesting review.

Pass through the "commonlyUsed" parameter to ICU to be able to filter any
uncommon keyword values.

ICU's public API only provides a function to return the preferred hour cycle
(udatpg_getDefaultHourCycle()), whereas for Intl.Locale we want to be able
to determine all allowed hour cycles. So we have to do it the hard way and
directly read ICU resource bundles to get the data we need for this feature.

Depends on D125570

Depends on D125571

Use the new NumberingSystem class to replace UNumberingSystem in SpiderMonkey.

Depends on D125572

Time zone functions being part of UCalendar is an internal implementation
detail of ICU4C. For the public unified Intl API we should rather follow
Temporal (or ICU4C's C++ API) and have a separate TimeZone class.

The files were moved using hg cp to preserve the file history.

Depends on D125573

• TimeZone objects can be created with any time zone identifier, so the "Default"
  part in the name isn't correct.
• The "TimeZone" part is no longer needed, now that there's a distinct class for
  TimeZone objects.

Therefore let's rename GetDefaultTimeZoneOffsetMs() to GetRawOffsetMs().

Depends on D125574

The filter type is UCAL_ZONE_TYPE_ANY to ensure all possible time zones are
returned, and not just CLDR canonical time zones. (CLDR canonical time zones
are different from IANA canonical time zones.)

Depends on D125575

Currently only provides a single method to retrieve the character orientation.

The default constructor was deleted because all methods are static.

Depends on D125576

The last addition for the "Intl Locale Info API" proposal.

Depends on D125577

Move CreateArrayFromList to intl/CommonFunctions so later patches in this
patch stack can use it.

https://hg.mozilla.org/mozilla-central/rev/5518e046d03a
https://hg.mozilla.org/mozilla-central/rev/4fb2491acf41
https://hg.mozilla.org/mozilla-central/rev/91c7f73689b3
https://hg.mozilla.org/mozilla-central/rev/a56309fdebdd
https://hg.mozilla.org/mozilla-central/rev/2478cae35f36
https://hg.mozilla.org/mozilla-central/rev/afb87d21b97b
https://hg.mozilla.org/mozilla-central/rev/3e6b7914038c
https://hg.mozilla.org/mozilla-central/rev/5c5ea857c3d9

The leave-open keyword is there and there is no activity for 6 months.
:sdetar, maybe it's time to close this bug?
For more information, please visit auto_nag documentation.

The spec for the proposal didn't progress in the last months.

Hi Anba, Frank is hoping to advance this to stage 4 in the near term, and he is wondering if you are waiting on any information from him prior to you being able to continue with the implementation. Thanks!

Issues like https://github.com/tc39/proposal-intl-locale-info/issues/30 still need to be resolved. The last comment seems to be confused about the meaning of [[RelevantExtensionKeys]] for Intl.Locale: While it is true that Intl.Locale has a [[RelevantExtensionKeys]] internal slot, Intl.Locale isn't an Intl service constructor, so Intl.Locale.[[RelevantExtensionKeys]] doesn't imply that Intl.Locale instances have to care about any extension keys.

Issues like https://github.com/tc39/proposal-intl-locale-info/issues/30 still need to be resolved.

It looks like this issue was resolved on 2024-11-24. Are there any other blockers?

This implements the accessor property textInfo, but keep in mind it's now a method called getTextInfo to prevent the situation of locale.textInfo === locale.textInfo returning false: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale/getTextInfo

I think we're waiting on https://github.com/tc39/proposal-intl-locale-info/issues/76 before we can finish this off.

(In reply to Dan Minor [:dminor] from comment #33)

I think we're waiting on https://github.com/tc39/proposal-intl-locale-info/issues/76 before we can finish this off.

This seems resolved, are there still any blockers?

Hi Anba, are you planning on finishing this off, or would you like me to have a look? It's no problem either way, just would like to know for planning purposes. Thanks :)

I was planing to look into this again next month. There are still some other Intl and Temporal related things I'd like to tackle first.

Great, thank you for working on this :)

New Intl.Locale methods will return arrays and objects, so we now need to
handle these types here.

For now we only need to access LocaleDirectionality from the icu_locale crate.

ICU4C doesn't have information for additional numbering systems per locale, so
getNumberingSystems will always return an array with a single element.

Used in part 10.

Used in part 12-14.

Used in part 12.

Backed out for causing bustage @ Locale.cpp

Backout link

Push with failures

Failure log

https://hg.mozilla.org/mozilla-central/rev/84a6690e5d25
https://hg.mozilla.org/mozilla-central/rev/313d4c4c5a70
https://hg.mozilla.org/mozilla-central/rev/3c20b54a8332
https://hg.mozilla.org/mozilla-central/rev/bf47a8739a14
https://hg.mozilla.org/mozilla-central/rev/c33d244e638f
https://hg.mozilla.org/mozilla-central/rev/dd423fda0778
https://hg.mozilla.org/mozilla-central/rev/edfebd30076a
https://hg.mozilla.org/mozilla-central/rev/b881fccf10d5
https://hg.mozilla.org/mozilla-central/rev/b65263c12398
https://hg.mozilla.org/mozilla-central/rev/0351d8300630
https://hg.mozilla.org/mozilla-central/rev/39ddc2b7a87e
https://hg.mozilla.org/mozilla-central/rev/2e7046c6a91a
https://hg.mozilla.org/mozilla-central/rev/52c4257c2c82
https://hg.mozilla.org/mozilla-central/rev/d6b9d2985593
https://hg.mozilla.org/mozilla-central/rev/cffe3dbfd93a

Is this something we should call out in the Fx152 relnotes? Please add a relnote-firefox? nomination if yes.

The feature is still behind a flag + Nightly-only. The current plan is to ship it in Firefox 153 (bug 2037069), so I guess relnote-firefox? should be added to that bug?

Yeah, we can wait. Sorry, I missed that it was still disabled by default. FYI, we can add a Nightly-only release note too if/when it's enabled there before it's ready to ride the trains.

FF152 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/44172 (update to experimental features and a compatibility data update).

Bug was resolved, but the web-feature intl-locale-info (definition file) is not yet marked as supported in Firefox.

Feature bugs are usually automatically closed once the corresponding web-features are marked as supported; this typically happens after the feature reaches release.