I disagree. I think it depends on the use-cases. I blogged about that recently: https://slint-ui.com/blog/translation-infrastructure
In short, I much prefer having the original (English) in the source code as it makes it easier to maintain and removes level of indirection. Using message identifiers adds boilerplate.
https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...
> The most important difference between gettext and Fluent is the choice of a message identifier. Gettext approaches the problem by taking the source string (often English). While the choice seem simple, it has long standing consequences in form of two limitations that this choice imposes.
First of all, it means that any change to the source string invalidate all translations of the string. This severely increases the burden on the developers to never alter messages in the source language as it results in all translations having to be updated.
> Secondly, it makes it harder to introduce multiple messages with the same source string which should be translated differently ...
> Fluent establishes a social contract between the developer and localizers. The developer introduces a unique identifier and provides a set of variables such as number of unread emails or the name of the user, and localizers are using Fluent syntax features to construct the best possible translation for that identifier.
I’ve wondered about the possibility of having the best of both worlds: have the source code contain the full English message (and no other identifier), but use a tool that automatically assigns identifiers to source code locations that contain messages. Different locations would get different identifiers even if they use the same string. The tool would have to be history-aware, in order to keep the identifier the same if the code is moved or if the message is edited. It would have to use heuristics to differentiate between “message was edited” and “message was deleted, and an unrelated message was added in roughly the same place”. But in practice this would usually be easy to do.
…Or you could simplify things drastically by having the source code contain both the English message and a unique identifier (perhaps just a number rather than anything descriptive). That’s less fun though.
English string directly in the source, plus a human-readable identifier that helps translators understand the context of the string they’re translating. One script to extract all strings, and another to load all translations.
Works fine really.
FWIW I do the same thing in our code.
Technically, it also solves the first problem - because there is also a “no translation” translation, and you can make the changes there instead of in the source code - no worse than Fluent in terms of work - but a lot more confusing down the line, so I wouldn’t refer to it as a solution.
Sounds good.
Since it is the last one then it will also handle something like this:
Fetch grocery item #{number} # groceriesI used an app that used Gettext for translation and had this problem. The string "banned" appeared in two places, once as a filter (to only show online / moderator / banned users) and once as a status indicator on the list of users (to indicate that a given user is banned). In English, the word "banned" is the same regardless of whether you're referring to a single user or a group of users, but that isn' true in other languages.
If you're developing with Gettext, you usually get this wrong and then translators have all sorts of issues. If you use something like Fluent, the natural thing to do is to give the first string an identifier like `user_list_filter_banned` and the second an identifier of `user_status_banned`.
As far as I understand, Fluent also lets you pass seemingly extraneous data to translation strings (like the user's gender), which, in some languages, might be necessary to translate something like "%s has just sent you a new message."
Their React example kind of points towards this: https://github.com/projectfluent/fluent.js/wiki/React-Bindin...
They provide a <Localized> component, which has an identifier and wraps a piece of markup containing the original:
<Localized id="hello">
<h1>Hello, world!</h1>
</Localized>
As long as you’re fine with the original being Italian or whatever if you happen on a project which is chiefly aimed at Italians.