Indeed, if only it were as simple as “{n} rows”.

I18n / l10n is full of things like this, important details that couldn’t be more boring or fiddly to implement.

Gettext has everything, it just takes knowing five languages to understand what to use for

Yeah, some sort of pluralization support is pretty much the second most important feature in any message localization tool, right after the ability to substitute externally-defined strings in the first place. Even in a monolingual application, spamming plural formatting logic in application code isn't exactly the best practice.

This confused me too but the formula and rules for variants are specified by the configured language out-of-band, so there is support for this.

Let's take your example. In English, counting files looks like this:

    You have {file_count, plural,
       =0 {no files}
       one {1 file}
       other {# files}
    }

    Masz 1 plik
    Masz 2,3,4 pliki
    Masz 5-21 pliko'w
    Masz 22-24 pliki
    Masz 25-31 pliko'w

    Masz {file_count, plural,
       one {# plik}
       few {# pliki}
       other {# pliko'w}
    }

The point is that it's supported, it simplifies developer logic, and your translators know how to work with it.

See https://www.unicode.org/cldr/charts/48/supplemental/language...

(Apologies if I got the above translation strings wrong, I don't speak Polish. Just working from the GNU gettext example.)

Yeah it's actually MessageFormat 2 [1] that's very informed by Fluent's design I believe; I think that comparison is to "normal" MessageFormat.

[1] https://messageformat.unicode.org/

I can't speak for the status quo, but for at least the first ~5 years (so until 3 years ago when I last attempted to use it), the JS implementation of Fluent was a mess. Constant issues with incomplete API, wrong TS typings (which at that point were external) and build/bundling issues to the point where we opted for a homebrew solution.

I imagine that I probably wasn't the only one driven away by that (and I gave it many attempts!).

The standard is, for better or worse, gettext; it's good enough that any attempt to replace it runs into the problem that people can't agree on how much better an alternative needs to be to be worth migrating to; so you get a constant churn that so far hasn't seen any clear winner.

Oh, the language aspect gets a lot worse than that. They explicitly have a non-goal of "all grammatical features of all languages", but the "common" cases are hard enough. From https://github.com/unicode-org/message-format-wg/blob/main/s... :

  .local $hasCase = {$userName :ns:hasCase}
  .match $hasCase
  vocative {{Hello, {$userName :ns:person case=vocative}!}}
  accusative {{Please welcome {$userName :ns:person case=accusative}!}}
  * {{Hello!}}

> why you think it's infeasible?

GP based his opinion on the assumption that this spec new and no implementations for it exist.