fix(i18n): restore extraction of plural strings with i18next v24+

[HendrikThePendric]

d2-app-scripts i18n extract silently drops every i18n.t() call that passes count. Those strings never reach en.pot or Transifex, and at runtime English always shows the singular form. There is no error or warning.

This is a regression

Plural extraction was fixed in July 2024 in #861 (LIBS-641) by moving to i18next-scanner v3, verified manually at the time. It broke again without any change in this repo:

• i18next-scanner v3 depends on "i18next": "*" and builds its plural suffixes from the rules of whichever i18next it resolves. This only works with compatibilityJSON: 'v3'.
• i18next v24.0.0 (22 November 2024) removed compatibilityJSON: 'v3'. Its plural rule is now a plain Intl.PluralRules with no .numbers, so the scanner computes pluralSuffixes.en = [] and writes no key at all for strings with count.
• Any app whose lockfile resolved i18next@* after that date gets v24+ and is affected. Apps with an older lockfile entry keep working, which is why this looks intermittent.

Lockfile bump

No automated test covered plural extraction (#861 only changed dependencies, and the existing extract tests mock the scanner). Even with one, it would have passed here: our yarn.lock still resolved i18next@* to 21.8.10. This PR adds that test and updates the lockfile entry to 26.4.2, the version a fresh install of an app gets today, so the test runs against the same i18next that apps do. Only the scanner uses this entry; the runtime (@dhis2/d2-i18n) has its own i18next@^10.3 entry.

The fix

After creating the parser in cli/src/lib/i18n/extract.js, set the English suffixes by hand:

parser.pluralSuffixes.en = ['', '_plural']

These are exactly the values scanner v3 computed for English before i18next v24, so the output is the same as before the regression:

msgid "And {{count}} other"
msgid_plural "And {{count}} other"
msgstr[0] "And {{count}} other"
msgstr[1] "And {{count}} others"

Only en is scanned. Other languages get their plural forms from the Plural-Forms header of their .po files during i18n generate, so they are not affected.

Alternatives considered

• Upgrade to i18next-scanner v4. It extracts plurals in the newer i18next format (_one/_other), which the runtime in apps (@dhis2/d2-i18n, on i18next 10) cannot read. Every app would need changes, plus a migration of existing plural translations. Out of scope for a regression fix.
• Pin i18next in cli's dependencies. Package managers don't make the scanner use that copy: with yarn 1, a fresh install still gives the scanner the latest i18next, so it would keep breaking. Forcing it would take resolutions/overrides in every app. The problem is here, in a repo we don't own...

Testing

• New test in cli/src/lib/i18n/extract.test.js runs the real scanner and i18nextToPot on i18n.t('And {{count}} other', { count: n, defaultValue_plural: 'And {{count}} others' }) and checks for a msgid_plural entry with the plural text in msgstr[1]. With i18next 26 it fails without the fix.
• The existing extract tests mock the Parser, so that mock now includes a pluralSuffixes field.
• yarn test in cli: 44/44 pass on Node 22 and on Node 18 (the version CI uses).

Apps affected by this need to run i18n extract again after upgrading, so the missing plural strings reach en.pot and Transifex.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kabaros]

Tested on the data-entry app - Before the fix, the plural translation resource didn't end up in the pot file. And they do afterwards.

[dhis2-bot]

🎉 This PR is included in version 12.11.7 🎉

The release is available on:

• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀