[troad]

I wish you guys the best, but I think you’re being a little self-congratulatory here.

The first feature is not optional - it has been a feature of i18n systems since the 1990s, possibly earlier. I’ve seen cludged-together in-house solutions that can do it without breaking a sweat. It is currently not feasible to use Fluent to localise any substantive, dynamic content in languages with case or gender - which is the main challenge an i18n package exists to solve. (I note the issue you link is five years old, dismisses the problem as not significant, and flat out states it is not being worked on.)

Translation files are generally made by translators, not programmers, and the fact that Fluent falls over in a slight breeze makes it difficult to imagine a translator being able to produce working Fluent files. This is not a ”subjective” problem. Translators do not, and should not, work for free. Using Fluent adds considerable (and needless!) complexity and therefore expense.

As you point out, you’re working on a new data format, so it’s unclear why anyone should adopt (and pay for translations in) the current moribund format.

I genuinely do wish you guys the best, and I apologise if I spoke too bluntly above, but it is not merely a matter of personal opinion that Fluent is de facto still in alpha.