dojo / dojo/framework

Remove Globalize.js in favor of `Intl` (and `MessageFormat`)

Open
#250 7 comments 0 reactions 0 assignees View on GitHub
breaking change discussion
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.