Allow to disable pluralization

[Nemo64]

🚀 Feature Proposal

I would like to be able to disable all pluralization features in the extractor.

Motivation

I use the Intl (icu message format) implementation for placeholders, pluralization, numbers, dates etc., since that is a standard we can use everywhere consistently.

[Elindorath]

I don't know if this answers your needs, but starting from v5.0, this extractor uses the native Intl API

[Nemo64]

I just noticed how unspecific I described my issue, sorry for that.

So the issue is that, when i have a translation key like: t('ns:hello_world', {count: 1}), it'll extract the keys like this:

{
  "hello_world_one": "",
  "hello_world_other": ""
}

But, since I use the ICU message format, what I actually want is this:

{
  "hello_world": "{count, plural, one {Singular text} other {Plural text}}"
}

But the extractor will remove the 1:1 key every time and instead creates those 2 rule based keys.

And this is still the case with v5. It actually got worse since in v4, the generated result was:

{
  "hello_world": "",
  "hello_world_plural": ""
}

Where we could just ignore the plural key.

[karellm]

I'll happily review a PR for this!

[boredland]

What would we expect here? a global flag to disable pluralization is probably not it. Perhaps a "if key exists without _suffix, don't assume _suffixes"? if I get it, its an either or. either _suffixes or none.

[karellm]

@boredland I think a flag to disable it entirely would work. Do you need this feature too?

[boredland]

@boredland I think a flag to disable it entirely would work. Do you need this feature too?

Well, not sure if disabling it would do the trick for me. We use pluralization in places, but have one particular place, where we only use one variant and have i18n formatting it. No problem for our i18n lib, but i18n parser doesn't like that.

[karellm]

I don't think what you need is related to the original issue. I'm ok to introduce a flag to disable the entire pluralization but I'm not keen to add more complexity for specific needs (like yours) in the project. What I would consider is to introduce a post-processing hook for people to modify the files before they are written.

[ghost]

I don't think what you need is related to the original issue. I'm ok to introduce a flag to disable the entire pluralization but I'm not keen to add more complexity for specific needs (like yours) in the project. What I would consider is to introduce a post-processing hook for people to modify the files before they are written.

understood. probably would use that, but on the other hand: duplicating a key is not the worst thing.

[Bertg]

I've just started experimenting with this tool, and ran into this issue.

Is someone already creating a PR for this? Or is it still open for someone of the community to pick up?

[Bertg]

I haven't had the time to write a proper PR (mostly no time to figure out the test right now), but I think this can be done quite simple.

There is one location where the locale rules are added: https://github.com/i18next/i18next-parser/blob/3435168b8fb782ccea5c3cb7df526879902bf80d/src/transform.js#L193

So the code could become:

// generates plurals according to i18next rules: key_zero, key_one, key_two, key_few, key_many and key_other
for (const entry of this.entries) {
  if (this.options.pluralSeparator !== false && entry.count !== undefined) {
    this.i18next.services.pluralResolver
      .getSuffixes(locale, { ordinal: entry.ordinal })
      .forEach((suffix) => {
        transformEntry(entry, suffix)
      })
  } else {
    transformEntry(entry)
  }
}

I'm reusing pluralSeparator here. When it is false, we could very well assume the developer doesn't want any pluralisation in their keys. Alternatively it can be made a completely separate option as well, to ensure backwards compatibility.

[karellm]

Added as of 8.1.0