Repository navigation
[Due for payment 2026-08-19] [Intl] Native Intl polyfills only load en/es locale data — pluralization wrong for non-en/es locales (e.g. Polish) #96335
Description
Activity
@shubham1206agra do you want to work on this?
Yes
Great! Thanks @shubham1206agra!
PR deployed to staging
- changed the title
[-]Native Intl polyfills only load en/es locale data — pluralization wrong for non-en/es locales (e.g. Polish)[/-][+][Intl] Native Intl polyfills only load en/es locale data — pluralization wrong for non-en/es locales (e.g. Polish)[/+]on Aug 12, 2026 1 remaining item
- changed the title
[-][Intl] Native Intl polyfills only load en/es locale data — pluralization wrong for non-en/es locales (e.g. Polish)[/-][+][Due for payment 2026-08-19] [Intl] Native Intl polyfills only load en/es locale data — pluralization wrong for non-en/es locales (e.g. Polish)[/+]on Aug 12, 2026 The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.52-11 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-08-19. 🎊
Waiting for payment now
Reacted by Rory AbrahamTriggered auto assignment to @mallenexpensify (
Awaiting Payment)Payment Summary
Resolving PRs:
-
Fixed locale specific polyfills by installing it in IntlStore #97786
-
Reviewer: @shubham1206agra owed $250 via NewDot
BugZero Checklist (@mallenexpensify)
- I have confirmed assignees, roles, and Upwork contracts look correct
- I have paid out Upwork contracts / manual NewDot requests
-
Payment Summary
Contributor+: @shubham1206agra due $250 via NewDot
Problem
On native (iOS/Android), the
Intlpolyfills only load locale data forenandes, but the app supports 9 beta locales (de,el,fr,it,ja,nl,pl,pt-BR,zh-hans). This gap affects every locale other than English and Spanish — it is not specific to Greek. Greek just surfaced it during review of Expensify/App#95655.The hardcoded
en/esdata loads:src/libs/IntlPolyfill/index.android.ts:15-17—Intl.PluralRulesis force-polyfilled (polyfill-force) with onlyen/esdatasrc/libs/IntlPolyfill/index.ios.ts:16-18— same for iOSsrc/libs/IntlPolyfill/polyfillNumberFormat.ts:32-34—Intl.NumberFormatpolyfill, onlyen/esdataPluralization is exercised at
src/libs/Localize/index.ts:81vianew Intl.PluralRules(language).Actual impact (narrower than a crash)
@formatjs/intl-pluralrulespolyfill-forcedoes not throw on a missing locale — itsResolveLocalefalls back to the default locale, which is the first one loaded (en). So:en/eslocales silently use English plural categorization.one/otherare effectively unaffected:de,el(Greek isone/other),fr,it,nl,pt-BR, andja/zh-hans(otheronly).pl), which hasone/few/many/other. With English rules it can only ever resolve toone/other, sofew/manyplural forms inpl.tsare never selected → wrong grammatical number on native. Any future locale with non-English plural categories (e.g. Russian, Arabic, Czech) would hit the same problem.formatToParts(polyfillNumberFormat.ts:26); on modern devices nativeIntl.NumberFormatis used with full locale support. So this only bites older devices, and again only for non-en/eslocales.Suggested fix
Load the
pluralrules(andnumberformat) locale data for the active locale dynamically, the same wayIntlStorealready wires up translations,date-fns, andIntl.ListFormatdata per locale — rather than hardcodingen/es. This keeps bundle size down (only load the selected locale's data) and closes the gap for all beta locales at once.Filed at the request of
roryabrahamfrom the review thread on Expensify/App#95655.Issue Owner
Current Issue Owner: @mallenexpensify