-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i18n: Use Intl.NumberFormat
internally in i18n-calypso
#98405
Conversation
Jetpack Cloud live (direct link)
Automattic for Agencies live (direct link)
|
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: App Entrypoints (~481 bytes removed 📉 [gzipped])
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used. Sections (~1688 bytes removed 📉 [gzipped])
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to. Async-loaded Components (~602 bytes removed 📉 [gzipped])
React components that are loaded lazily, when a certain part of UI is displayed for the first time. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
number_fornat
function with use of Intl.NumberFormat
in i18n-calypso packageIntl.NumberFormat
internally in i18n-calypso
This PR modifies the release build for the following Calypso Apps: For info about this notification, see here: PCYsg-OT6-p2
To test WordPress.com changes, run |
return Intl.NumberFormat( browserSafeLocale, { | ||
minimumFractionDigits: decimals, // default is 0 | ||
maximumFractionDigits: decimals, // default is the greater between minimumFractionDigits and 3 | ||
// TODO clk numberFormat this may be the only difference, where some cases use 2 (they can just pass the option to Intl.NumberFormat) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leaving some TODOs withclk
/initials. I intend to immediately come back to and address in next 1-2 PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something to think about: the Intl.NumberFormat
is designed to have two steps: 1. create the formatter (once); 2. use it to format numbers (many times).
It's like if creating the formatter was expensive: find the translation resources and initialize everything. And the actual formatting is cheap.
Can we somehow cache the formatter? Create it just once and then in numberFormat
just call its .format
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I like the idea, and it's definitely doable. If we keep numberFormat
going forward, we can explore a caching layer, assuming it brings any real benefits I guess.
It might be the case that we also expose a hook around this.
For now, I think we can proceed with the current form and rework it as we go. WDYT? I intend to have a few more PRs before we make the final call, whether to deprecate or not (and from there do the additional cleanup).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ffe786c
to
ba48722
Compare
6957664
to
c671734
Compare
Thank you all for reviewing! 🎉 ![]() ![]() p.s. While testing, I noticed in the stats page popup the numbers shown aren't following proper translation e.g. ![]() It's the same in production, so I will create an issue and add it to the board. cc @dlind1 |
https://github.com/Automattic/i18n-issues/issues/918 |
Fixes Automattic/i18n-issues#795
Related to https://github.com/Automattic/i18n-issues/issues/923
Proposed Changes
numberFormat
method ini18n-calypso
to utiliseIntl.NumberFormat
internallygetBrowserSafeLocale
methodnumber_fornat
internally and Tannin may have introduced for HE locale (Automattic/i18n-issues#795)Notes on approach/direction:
numberFormat
(or alternatively a general refactor around it)Intl.NumberFormatOptions
(and from there consider full deprecation or not). This is therefore an incremental change (in a way that best works for the author pursuing the refactor).Media
/me/purchases
ES
EN
/start/day/:site
EN
Why are these changes being made?
Fixes Automattic/i18n-issues#795
Related to https://href.li/?https://github.com/Automattic/i18n-issues/issues/923
We only really need one way of formatting numbers in the codebase. Maybe one wrapper, or maybe one straight-up use of a vanilla API. Unless there is a good reason to not do so, we will pursue this path.
Testing Instructions
We use the
numberFormat
in several places andformatNumberCompact
in just a few. The latter is affected by the changes more prominently./me/purchases
thereafter and confirm the "views" shown in the description show the correct formatting (see media above). Confirm with HE locale specifically for Automattic/i18n-issues#795/stats/day/:fieldguide
and confirm the media above. All the stats like "views", "posts", etc. use theformatNumberCompact
wrapperPre-merge Checklist