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
Upgrade react-intl #24906
Upgrade react-intl #24906
Conversation
a8a027d
to
b0707b7
Compare
@Quenty31 I see you contributed to the Occitan translation before, do you have an opinion on the custom plural issue I described above? |
Added polyfills for |
This pull request has merge conflicts that must be resolved before it can be merged. |
b373caf
to
8757f0e
Compare
This pull request has resolved merge conflicts and is ready for review. |
This pull request has merge conflicts that must be resolved before it can be merged. |
8757f0e
to
8000415
Compare
This pull request has resolved merge conflicts and is ready for review. |
This pull request has merge conflicts that must be resolved before it can be merged. |
8000415
to
9b96d67
Compare
This pull request has resolved merge conflicts and is ready for review. |
This pull request has merge conflicts that must be resolved before it can be merged. |
9b96d67
to
28bb148
Compare
This pull request has resolved merge conflicts and is ready for review. |
This pull request has merge conflicts that must be resolved before it can be merged. |
Doesn't seem that
They maybe can contribute the rules to CLDR, otherwise this warning about locale data is probably OK to ignore. It shouldn't cause any issues and Intl should resort to using default locale rules. |
- It now uses the browser's built-in plural rules, no longer need to load them - Translations are loaded using dynamic import, this is more future-proof
Its now supported by `FormattedMessage` using the Rich Text feature: https://formatjs.io/docs/react-intl/components#rich-text-formatting
The `intl` package has been deprecated, so let's replace it with FormatJS polyfills. It also allows to properly load the locale data for every locale, before it always loaded `en` from the polyfill. This created a Webpack chunk for every locale, but this is needed if we want per-locale loading. I chose to only enable the polyfill for `Intl.PluralRules`, as the browser support for the others is good noaways. `RelativeTimeFormat` will need to use its own polyfill once we use it in the codebase, but as its not used for now, its commented. I left the other polyfills commented out, if we notice they are really needed somehow. The change in `tsconfig.json` is needed for dynamic imports, it has no impact for Webpack/Babel
…or our locale For example, `oc` locale in Google Chrome When this happens, the browser will select another "best" locale.
Those no longer works for the newer `react-intl` (and last commit was 5 years ago)
It will now extract the JS translations, and exit if it changed any files, meaning the author forgot to run `yarn i18n:extract` to handle I18n key changes
For example, keys with 2 different `defaultMessage`
a2c712a
to
263f8b9
Compare
This pull request has resolved merge conflicts and is ready for review. |
Note that this breaks cross-origin loading of the assets because of the missing |
See the various commits for details of what is does.
TODO:
manage:translations
<RelativeTimestamp>
with something simpler based onreact-intl
components or helpers, but I am not sure what all the props do. status: should be in a future PR, not really needed right nowoc
andsa
locales (see below)oc
). status:shoudPolyfillPluralRules
has a built-in list of supported locales, and fallbacks toen
, so all here.Custom plural rules issue
Currently we are using
sa
andoc
as custom plural rules, but they are not supported by the Javascript Intl API, resulting is this message on page load:formatjs/intl Error MISSING_DATA] Missing locale data for locale: "oc" in Intl.NumberFormat. Using default locale: "en" as fallback. See https://formatjs.io/docs/react-intl#runtime-requirements for more details
I am not sure how to properly handle this.
The browser is supposed to pick the best fit for the provided locale, so I guess we could just make FormatJS not print this message (using
onError
) for those 2 locales?✅ Solution
oc
is not supported in Chrome & Firefox,sa
is not supported in Chrome, both are supported in Safari. According to the JS spec, the browsers should pick the best available locale here, so we can simply silence the message.Fixes