Remove Globalize.js in favor of `Intl` (and `MessageFormat`)
- Dominant language
- TypeScript
- Stars
- 623
- Forks
- 78
- PR merge metrics
- No merged PRs in 30d
Description
**Enhancement**
Dojo currently uses [Globalize.js](https://github.com/globalizejs/globalize) for the bulk of its internationalization/localization functionality, but at this point `Intl` is well-supported and robust enough that it can handle most use cases. For supported browsers that lack `Intl` support, there are shims available ([`Intl`](https://github.com/andyearnshaw/Intl.js) and [`Intl.RelativeFormat`](https://github.com/yahoo/intl-relativeformat)). With that in mind, we can remove Globalize.js, use [MessageFormat](https://messageformat.github.io/messageformat/) internally for managing ICU message formatting, and recommend the native `Intl` for anything else.
This would be a breaking change, and applications that use functions like `formatCurrency` would need to update to their native equivalents like `Intl.NumberFormat`. Perhaps `@dojo/cli-upgrade-app` could help mitigate any manual updates
With regard to the build, conditional polyfill loading should help reduce the bundle size, but it would also be possible to pre-compile any messages and therefore eliminate most of the bulk from the MessageFormat library as well. However, doing so will be difficult without a standard means of differentiating message bundles from other files. Just as Dojo uses `m.css` to distinguish CSS module files from other CSS files, perhaps a similar approach could be used for localized message files. The build would then pre-compile the messages in these files and `MessageFormat` could be ignored entirely. More discussion is needed here.
Contributor guide
Assessment
This issue has not been assessed yet.