This comparison mentions that in gettext, using the source string as a message identifier "makes it impossible to introduce multiple messages with the same source string which should be translated differently."

It's rather disingenuous to say this without mentioning that in gettext, the actual identifier is a combination of the source string and the string context, which is blank by default. But the context can and should be provided in cases where disambiguation is required.

https://www.gnu.org/software/gettext/manual/html_node/Contex...

Thank you! That's a good feedback. In our experience of working with the gettext based localizations we noticed that developers almost always omit the context and in result localizers are stripped of the ability to distinguish the message variant which makes them have to ask the developer to introduce it.

This, in turn, breaks the design principle #1 of Fluent - https://github.com/projectfluent/fluent/wiki/Design-Principl...

I'll update the Wiki to reflect that!

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.

Having said that, Fluent looks interesting.

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.

Considering the translation ID as a "slug" is a good tip to ease choosing the ID. Thanks!

There's a tool written by a Udacity developer which can be used to autoextract copy from React source code: https://github.com/udacity/fluent-react-utils/tree/master/pa...

I was thinking of something along this line. Thanks!