> why you think it's infeasible?

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

This is the one. Think of all the "misconceptions developer have about X" lists, I trust Unicode to have encountered (if not written) all of them. The people behind unicode are thorough.

I mean they have hieroglyphs, some of which have plurals: https://www.unicode.org/charts/nameslist/n_13000.html

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!}}

But if anyone can find a good compromise, it's the Unicode team.

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.

Feels like it's That XKCD page; there were standards like gettext, then web development came along and a load of people (...present company included) rediscovered localization and pluralization through trial, error, half-building one's own localization library, then the JS world reinvented it, etc etc etc.

We are targeting MF2.0 for inclusion in JavaEcript stdlib (ECMA-402). And later maybe with its own format into DOM for DOM L10n.

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/

The site behind that link gives answers to only 2 out of 6 question. If your goal was to promote and teach, then you have failed. If your goal was to demoralise the HN readers and grind the conversation to a stop, then you have succeeded.

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.

gettext have everything, plus a huge ecosystem like tools to coordinate collaboration from thousand of contributors etc.

if alternatives don't start with a very strong case why gettext wasn't a good option, it's already a good indicator of not-invented-here syndrome.

No, gettext scales very badly, both vertically (larger systems) and horizontally (locales with rich grammatical forms like declensions etc.)

We (authors of Fluent and collaborators on MessageFormat 2.0) wrote this explainer which you may find informative - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...

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}
    }

In Polish, there are several possible variants depending on the count:

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

Your Polish translators would write:

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

The library (and your translators) know that in Polish, the `few` variant kicks in when `i%10 = 2..4 && i%100 != 12..14`, etc. I think the library just knows these rules for each language as part of the standard. Mozilla says that it was an explicit design goal to put "variant selection logic in the hands of localizers rather than developers"

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.)

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.