The way Serge works is that it never alters an existing translation by itself. It should not be a concern of a low-level tool like Serge to decide whether to propagate translation changes to all unrelated string instances (event if their translations are marked as fuzzy): the same string can be translated differently depending on the context, so such bulk translation replacement is something that needs to be done in the CAT tool where the translator can see what translations will be affected, and can understand the context of each change.

However, if there's no translation yet, Serge can propagate translations automatically simply as a way to save translators some initial copy-pasting work. This is where reuse_orphaned and reuse_uncertain take effect.

There's also a possibility to write a SQL query that would remove some "bad" translations from Serge database. Then running serge localize --rebuild-ts-files would propagate changes from the database into translation files, and Serge will also do translation substitutions again where possible, using the remaining "good" translations.

Thanks for your response.

I understand that it is not the job of Serge to propagate translation changes.
But I believe that since the feature of automatic fuzzy translation is available and reuse_orphaned can be set to NO then it should be possible to achieve this.

I believe that the reuse_orphaned option is not working as expected.
Please correct me if I'm wrong:
In my case I have 10s of entries which have the exact same string. And the context is always the same.
When I translate only one entry then that should be the only possible option for fuzzy translation.
After I change that translation then the last translation that was stored in Serge should be marked as orphaned and not used again. Which would result in updated fuzzy translations.
Except the fuzzy translations are also being reused. Which shouldn't happen, in my opinion.

After I change that translation then the last translation that was stored in Serge should be marked as orphaned and not used again.

Serge doesn't store the history of translations. If a new translation comes from a translation file (.po), this translation replaces the previous one for a specific item (instance of the string in a specific file). I.e. there can only be one translation for a given item in the database. The notion of "items" means that even if there are multiple identical strings in the file, Serge still treats them as different instances (and it will disambiguate the context to make sure context+string pair is unique within a given file).

If you have multiple strings all having the same translation across the entire Serge database, and then add another identical source string, then Serge knows that there's only one possible translation for this string, and will reuse it. If you change the translation for one of these strings, this will mean that now there are multiple translations for the same source string in the database. In this case Serge will only reuse the translation if reuse_uncertain is set to YES.

When some translated string in Serge is marked as orphaned (i.e. the string was removed from the source file, or the file with resource strings no longer exists), Serge still keeps its translation in the database, but will ignore translations for orphaned items unless reuse_orphaned is set to YES.

ok, now I understand what orphaned translations are. thanks.

Are fuzzy translations also reused?
In other words, can fuzzy translations be in conflict with the original translation and therefore reduce the chance of changed translation to be reused, when reuse_uncertain is set to YES?
How would the logic behind reuse_uncertain affect the results in my case? (Matching strings, one manual translation which then changes)

Fuzzy translations are reused as well, yes (and they are always reused as fuzzy, i.e. the fuzzy flag is never cleared on reuse). See https://github.com/evernote/serge/blob/a10b1744d9fe62c772f79832abdbf9ca8b0eb2be/lib/Serge/DB/Cached.pm#L593-L630

reuse_uncertain helps you decide what to do if you have multiple translations for the same source string. See https://github.com/evernote/serge/blob/4156cf8ab75b60c36bba72731547cdc8812831cf/lib/Serge/Engine.pm#L1679

In your case if you translate string the very first time, the translation is auto-propagated to all same strings across all files/projects (provided you have the translation reuse feature enabled, of course). Once the translation is propagated, it is essentially locked from any automatic updates. If you then change the translation for one of your string instances to something else, this won't affect any previously propagated translations.

Note that Serge database is pretty simple (see https://github.com/evernote/serge/blob/a10b1744d9fe62c772f79832abdbf9ca8b0eb2be/lib/Serge/sqlite_schema.sql). If you want to bulk-update translations across the entire database, the simplest use case would be to run a query like UPDATE translations SET string = 'good string' where string = 'bad string' and language = 'xx' followed by serge localize --force --rebuild-ts-files. But that's probably needed only if your changes are truly massive (for example, you want to replace the product name to something else in the entire translation database). In real life it's easier to do such replacements in the translation UI (which one do you use, btw?).

Thanks for your detailed responses.
I'm using Pootle.
I was hoping that there would be an automatic way to update fuzzy translations whenever a translator updates the original translation.
But I understand that when the fuzzy translations are reused, it's not possible for the changed translation to always be the chosen one.

If you're using Pootle, then you can search there for all matches of an exact phrase in the translation field only (across the entire database or in a particular project or file), and just go through the found units and change the translations accordingly. There are no bulk operations there, though.

Yes, thank you.

What do you think of adding an option which is called reuse_fuzzy?
That would solve the problem, because then I could set it to NO if I only want manually translated strings to be reused.

This option makes sense. Will add it.

Great.
Keep up the good work!

Closing as implemented.