Add Intl.Locale

[Elchi3]

I've created two features here.

• First, the initial Intl.Locale class as shipped broadly in all browsers as specified originally under https://github.com/tc39/proposal-intl-locale
• Second, the Intl.Local additions as shipped in Safari only as of now and specified in https://github.com/tc39/proposal-intl-locale-info

[petele]

I would suggest merging these two as they provide effectively the same functionality. In this case, to make sure it is baseline, add:

status:
  compute_from: javascript.builtins.Intl.Locale

@ddbeck - review the reviewer

[Elchi3]

Long term, I would say yes, this is just one feature, but I thought that it would be useful to think about this as two features for now and merge them only once both features are baseline high. This has generally been my approach in this repo (see array features), so I wonder if we have any general guidelines for making the call in situations like this.

I'm aware of compute_from, but to me that essentially hides all of the features defined in https://github.com/tc39/proposal-intl-locale-info. So, I guess if we are doing that we're saying no one needs to care about these new Intl.Locale functionalities at all and just look at Intl.Locale as a whole with the "baseline high" story dating back to 2023? In other words, when Chrome and Firefox decide to ship this in the future, no web-features feature will take notice. Is that desired?

[ddbeck]

so I wonder if we have any general guidelines for making the call in situations like this

I guess I need to write this down somewhere (probably in the "what makes a feature" section) but I think the foremost question is: do (or do we expect) developers to recognize this as a distinct feature?

Direct evidence of developer interest is the single best tool for deciding this (e.g., blog and social media posts from or for developers, Stack Overflow questions, polyfills, etc.), but that won't always be available, especially for the newest things. We need to make a prediction about what developers might think of these items in the future.

That will leave us with lots of cases that are situational. I think I'm coming down on the side of this being two separate features. Here's how I got there:

• In general, the ECMAScript proposals process makes feature creation more likely. ECMAScript proposals tend to be narrow in scope, use stages to communicate maturity, have decent documentation apart from the spec language, etc. TC39 does a better-than-most job of making spec changes legible to developers.

• Ignoring the spec, we still have a cluster of methods that look like a thematic unit, with similar names, similar return types, etc.

• The methods have a support history that looks the same, as a unit. We also have a weird support history, where the API looked to have a different shape. Looking at the compat table on MDN is instructive, in this case.

That said, if Safari hadn't actually shipped this yet I'd probably have been OK with leaving it as a part of the Intl.Locale feature, then cleaving it off later once the dust settled. In that scenario, the story you'd be telling is that there are some messy, unsettled, and only semi-standardized additions to Intl.Locale. Thankfully, it looks like a better organized future is ahead.

[ddbeck]

@petele Newer JS stuff is harder and weirder. 😅 I wrote a lengthy review which might be informative.