Don't take the comparison at its face value, it's clear to me that whoever wrote it isn't really familiar with gettext, or deliberately talking it down. Yes, it's sort of ancient, but the problems mentioned can be solved.
And using the source string as ID is a pretty clever trick. Of course, there are some downsides, but there are certainly also downsides with separate IDs.
Hi! Thank you for your feedback. I'm one of the authors of Fluent, and this wiki article.
I have, in fact, been using Gettext for quite a few years, but of course, as you pointed out, I am also biased.
If you have suggestions on how to improve the article to better represent the reality, please, file an issue and provide a PR! Our goal is to express our design differences, but we don't want to mislead anyone!
The downside of using separate IDs is that the developer has to "name" each string shown in the user interface, instead of just using the source string as an ID. And as you know, naming things is hard ;-)
Yes, naming is hard, but, to quote the previous commenter "this can be worked around" - you can `slug` any string if you want to.
We prefer to think of the ID as the base of the social contract between the dev and the localizer. This enables a lot of fine tuned control over string invalidation.
And using the source string as ID is a pretty clever trick. Of course, there are some downsides, but there are certainly also downsides with separate IDs.
Having said that, Fluent looks interesting.