Add Intl

[Elchi3]

So, I'm encountering two tricky things here.

1. (As you might have noticed already), I'm not a fan of compute_from, but I used it here.
   Over the years, a lot of things have been added to Intl. When the additions are entirely new built-ins, I added separate features for them (see my PRs from earlier this week). It gets more tricky with additions to existing built-ins, though, because it is harder to describe them as a package.
   So, this is again a question of how/if to split things out or not. A list of proposals can be found here: https://github.com/tc39/proposals/blob/HEAD/ecma402/finished-proposals.md which provides some hints towards packaging things up in more features. Maybe we want to do that for the baseline low features at least? Otherwise, as it is recorded now, Intl will just be baseline high and we're done.

2. I'd like to move some keys to the intl feature. I currently commented them out:

#- javascript.builtins.Array.toLocaleString
#- javascript.builtins.BigInt.toLocaleString
#- javascript.builtins.TypedArray.toLocaleString

I believe I have to remove the tags from BCD for this to happen? (Definitely an interesting learning for our syncing work for BCD<->web-features.)

[Elchi3]

I opened mdn/browser-compat-data#24148 for the second point.

[ddbeck]

I believe I have to remove the tags from BCD for this to happen? (Definitely an interesting learning for our syncing work for BCD<->web-features.)

The compat_features key in web-features takes priority over the BCD tag, so you don't have to remove a tag before editing the feature here. That said, you may end up overriding several tags with compat_features at once to make key movements work out.

Edit: Also, we only get tag changes here when there's a BCD release.

[Elchi3]

hm, but when I add the keys here, the tests fail due to key assignments to more than one group.

[ddbeck]

Right. You'll need to have compat_features in all of the features that require changes, unfortunately. This is a limitation of having keys in a single feature right now (getting more feedback from the MDN folks is high on my list, so we can potentially move forward on that one).

[ddbeck]

So I've been looking at this one and getting a bit frustrated. There's some evidence that developers see Intl as a big unit—the caniuse feature or reading various Intl tutorials. But looking through, for example, the caniuse issues on this subject (i.e., https://github.com/Fyrd/caniuse/issues?q=is%3Aissue+intl) or polyfills for Intl show a different picture: developers care about the individual pieces that make up Intl too.

I suspect this is a case where Intl is actually a composite feature, like Web Components, which has, inside it, several small but distinct features. Right now, we can only capture the smaller units.

I'm not sure the finished proposals are especially helpful in this either, though, since they're also a messy set of incremental steps. I wonder: what would this look like if we broke it up thematically (approximately one feature per Intl namespace member, e.g., Intl.NumberFormat, Intl.DateTimeFormat, etc., plus the primitive type additions)?

[Elchi3]

Yeah, this is not trivial.

I wonder: what would this look like if we broke it up thematically (approximately one feature per Intl namespace member, e.g., Intl.NumberFormat, Intl.DateTimeFormat, etc., plus the primitive type additions)?

I think I did this already. The rest of the Intl API has seen separate pull requests with their own features. This PR has three namespaces together as I think the initial Intl API with the basic functionality is Collator, DateTimeFormat and NumberFormat.

The tricky part now is that these namespaces (and others) have seen certain incremental enhancements with cannot be summarized easily. (sometimes you see things like "NumberFormat v3" but that doesn't seem to be very useful to web developers either and is more a snapshot than a feature per se).

I'm leaning towards keeping this as is and splitting things out later if needed. https://web-platform-dx.github.io/web-features-explorer/groups/ (Groups -> JavaScript -> Intl) looks okay to me if it gains an "Intl" feature for now.

[ddbeck]

OK, thank you, Florian!

I have two suggestions for you and you're welcome to merge this after resolving them, one way or another. 😄

[Elchi3]

Thanks Daniel, I will leave this open until we have a BCD in main that includes mdn/browser-compat-data#24148.