[l10n] Prepare iteration on number formatting #20656
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Details of bundle changes.Comparing: 15854b9...13a3692 Details of page changes
|
imcvampire
reviewed
Apr 21, 2020
|
Not a related question: Do this file is tree-shakable? I suppose it's not and it needs to be split on a file per locale. |
eps1lon
previously requested changes
Apr 21, 2020
@dmtrKovalenko Looking at the output of rollup yes, it seems to be tree-shakable. Maybe we should add a test case in our size-snapshot to prevent regression. I can look into that.
@eps1lon This discussion echos back to #19542. In hindsight, a simplification of the arguments was:
We have a new use case for date/number formatting in the library. @dtassone on the data grid, I imagine we will need to format numbers and dates? How do you envision a solution to this problem? |
1 task
1 task
1 task
This is only an issue if you expose each context object. You can still expose a single config provider that renders multiple context providers. You're talking about the basic use case that has a single config for the whole app. The amount of work you do in these one-time setups is negligible since it's done once. It would only be an issue if we don't have sensible defaults. That argument is also self-evident. However, as long as context selectors are not available in react unrelated data should go into separate context slices. |
DDDDDanica
reviewed
Apr 21, 2020
github-actions
bot
added
the
PR: out-of-date
1 task
1 task
Co-Authored-By: Quoc-Anh Nguyen <[email protected]>
Co-Authored-By: Dmitriy Kovalenko <[email protected]>
Co-Authored-By: Dmitriy Kovalenko <[email protected]>
Co-Authored-By: Danica Shen <[email protected]>
oliviertassinari
force-pushed
the
improve-translations
branch
2 times, most recently
from
d89ab28
to
2434199
Compare
oliviertassinari
force-pushed
the
improve-translations
branch
from
2434199
to
13a3692
Compare
oliviertassinari
changed the title
oliviertassinari
removed
the
PR: out-of-date
oliviertassinari
dismissed
eps1lon’s stale review
I have reduced the ambition of the pull request. No new API.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea started with https://github.com/mui-org/material-ui/pull/20543/files#diff-4f0ea089313629267bec25abe661453fR431. In the pagination components, we don't format the numbers, we should. For instance: ant-design/ant-design#19337.
I suspect that we will get reports about SSR hydration mismatch if we land the changes as is. The support of Intl.NumberFormat isn't always consistent between browsers and servers. Since node v13, the full ICU module is loaded by default: https://nodejs.org/api/intl.html#intl_internationalization_support, it helps.
A couple of alternatives it the mismatch issue gets out of hand:
en-USlogicI'm not very fond of the idea to put the localization inside the theme, especially with the
LocalizationProvidercomponent we have for the pickers, that we should/could bring into the core. However, maybe we should defer the problem to v5?cc @mui-org/core