I have experimented with adding support for it (i18next JSON v3, v4), it seems to work nicely. Please note that in order for i18next to apply plurals, the number placeholder must be named count.
There are some issues/unanswered questions:
Not sure which i18next JSON version to use. I have found v4 plural suffixes a bit easier to understand (here is a JSFiddle which displays the plural suffixes for a given language/i18next JSON version). It might also make sense to bite the bullet and switch to v4 before adding plurals so as not to have to migrate the keys afterwards. I am not sure if there are any issues (unrelated to plurals) from switching from v3 -> v4, though.
How would GitLocalize handle plural translations? Different languages may have different plural forms, so the key suffixes might also differ, e.g. in i18next JSON v4 the en keys would be: foo_one and foo_other, the lt (Lithuanian) keys would be foo_one, foo_few, foo_other. How would GitLocalize handle the foo_few key (what would it display as the "source" value?) when translating en -> lt?
IIUC, GitLocalize does not support adding new strings manually, so in order to add missing plural forms, it would have to be done via PR?
i18next, the library used by Thorium for translations, supports plurals, but it is currently not used in Thorium.
I think it would be nice to display the correctly pluralized strings instead of appending all the possible variations at the end (e.g. 42 match(es)).
IIUC, there are a few strings that would benefit from plurals in Thorium:
reader.picker.search.foundsdialog.annotations.descListdialog.annotations.descNewerdialog.annotations.descOlderdialog.deleteAnnotationsTextI have experimented with adding support for it (i18next JSON v3, v4), it seems to work nicely. Please note that in order for i18next to apply plurals, the number placeholder must be named
count.There are some issues/unanswered questions:
i18next-json-sync(the CLI tool to extract translatable strings) does not support plural keys (it simply removes them), although there are alternatives, e.g. https://github.com/felixmosh/i18next-locales-sync.enkeys would be:foo_oneandfoo_other, thelt(Lithuanian) keys would befoo_one,foo_few,foo_other. How would GitLocalize handle thefoo_fewkey (what would it display as the "source" value?) when translatingen->lt?