-
Notifications
You must be signed in to change notification settings - Fork 16
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
fix(deps): update i18next-scanner version to support old plurals format again [LIBS-641] #861
Conversation
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 tested and agree that this works to extract strings with {{count}}
in them and also picks up the defaultValue
and defaultValue_plural
🎉
I find it a bit weird that i18next's plural updates broke the i18next scanner, given that their documentation for the current plural handling still use the {{count}}
in their strings 🙃. But glad they fixed it!
I also can't get the new format, e.g. defaultValue_other
to populate correctly into our .pot files, though I would guess that has to do with our old i18next-conv dependency (we're on major version 9, and the package seems to now be on major version 15). So maybe they've now updated to use the Intl.PluralRules terminology too?
Looking at that, I did also see that we seem to be using some default config with i18next-conv that seems to result in plural interpretation that doesn't seem to let us provide more differentiated plurals other than 1 vs plural ("Plural-Forms: nplurals=2; plural=(n != 1)\n"
in the generated po file). So I assume we also want to update that to allow us to define more nuanced plurals (e.g. for Arabic, Russian) where that's relevant.
Thanks for looking into that @tomzemp! I added your comments to a ticket for the follow-up work to support the new plurals format: https://dhis2.atlassian.net/browse/LIBS-643 |
## [11.6.3](v11.6.2...v11.6.3) (2024-07-16) ### Bug Fixes * **deps:** update i18next-scanner version to support old plurals format again ([#861](#861)) ([d0e433b](d0e433b))
🎉 This PR is included in version 11.6.3 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
# [12.0.0-alpha.4](v12.0.0-alpha.3...v12.0.0-alpha.4) (2024-07-23) ### Bug Fixes * use i18next-scanner v3 for better i18next compatibility ([#864](#864)) ([84a5a59](84a5a59)) * **deps:** update i18next-scanner version to support old plurals format again ([#861](#861)) ([d0e433b](d0e433b)) * plugin boundary retry if plugin logic is skipped ([#862](#862)) ([01a3160](01a3160)) ### Features * update boilerplate app code for init command [LIBS-644] ([#866](#866)) ([bd6cfc0](bd6cfc0))
🎉 This PR is included in version 12.0.0-alpha.4 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
See LIBS-641 and its related issue for more context (tl;dr:
i18next-scanner
has a dependency oni18next
with*
as the version, andi18next
v21 broke it. Version 3.0.1+ ofi18next-scanner
adapts to the changes and makes it backwards-compatible, fixing the break it introduced for us)We’re currently on v2, and the latest version is v4
i18next-scanner
now also seems to support the new plural format too (called "compatibilityJSON v4"), when we’re ready to migrate to thatHere are some test plurals to make sure they're extracted correctly: (I added them to the simple example app, then ran
yarn start
to extract the strings, generate the translation JSON files, and start the app -- the plurals also worked when viewing the app in the browser)