So we had a discussion with @tstrachota and here's our conclusion:
1) using intl for date/time format localization is long term a good idea, supported by all modern browsers, intl library that causes the big bundle is only used for legacy browsers and with this patch, we only bundle date strings which adds "only" 0.5 MB to ~1 MB we had before intl was merged, right now, the bundle.js in develop has 18.3 MB for vendor.js, see more info at
2) the internationalization of strings such as "seconds", "months", "ago" is provided by modern browser intl API and it sounds reasonable to rely on that, not trying to mix it into our gettext
3) further internationalization of JS stack is subject of discussion, so far the plan is to continue extracting strings using `__()` but a discussion about other solutions could be held, it's orthogonal to this PR, my personal opinion is that no matter what we chose, the native intl browser support should be used where applicable
4) loading of just the language that is required would be good addition, if you think it's a hard dependency of this, we should revert the original PR as it will take longer time, if you're fine with adding this later, we'd prefer to merge this PR and keep dates components in for 1.17