Unapproving translations whose source strings have been updated

Hello! Is there any way in Pontoon to _un_approve any approved translation when its source string is updated? Alternatively, if that’s not possible, is there a way to find a list of such translations?

(I thought at first that this might be what “Fuzzy” means, but I tested out making an update to an English string, existing translations of that string weren’t marked as Fuzzy.)

Thanks!
-Anand

What happens here really depends on file format.

For bilingual file formats, the en-US string is regarded the key, and for those, Pontoon creates a new reference entity, and possibly fuzzy translations.

For monolingual files, there’s keys, which are considered to be semantic version IDs, effectively.

If you want to enforce a change to translations, you need to rev the ID.

This comes with the benefit that if you want to change the English string w/out affecting all localizations, you just don’t change the ID, and that will happen for you.

1 Like

Thanks @Pike!

FWIW, our use case is sort of in between “change the English w/out affecting all localizations” and “enforce a change to translations”: we want to be able to review existing translations for strings whose English content has changed, revising them only if necessary. One idea: there were a way to filter strings for any locale by the update time of the corresponding English string, that would solve this pretty neatly…

We’re adding a review functionality as we speak.

Maybe a follow-up could be to add a review step for all translations of a string.

@mathjazz?

Hi @anand,

It seems like filtering by source string update time would solve the problem. But I wonder if such filter would be visible enough.

Users usually watch dashboards to see what needs to be worked on, so adding another translation status (e.g. Reviewed) is probably a better solution.

Hi @mathjazz,

I think you’re right that a Reviewed status would be ideal, but as that seems like a larger endeavor, I put together a PR attempting to add a “Stale” filter that looks for translations whose edit times are before their corresponding source string’s updated time: https://github.com/mozilla/pontoon/pull/1625. We’ll probably use this in our fork, but also happy to clean it up if you’d like to take it upstream!

Sorry to dig up an old-ish thread. Is there any updates on this?

I was surprise this isn’t already a thing in Pontoon and came across this post when searching online. This will go a long way to ensure the original version and the translated version don’t drift too far apart over time.

Hey @limzykenneth, could you please clarify what do you refer to as “this” in “this isn’t already a thing”? :slight_smile:

As outlined above, handling updates to source strings is different depending on the file format, so I wonder which one do you use and what is the expected behavior Pontoon doesn’t meet.

Hi @mathjazz, I’m using FTL and by “this” I mean when source string in the source FTL file is updated, Pontoon will mark the existing translations as “Stale” or something like that.

The current behaviour that I observed is that when source string is updated, the translated strings still stay in the approved “Translated” state. I had a look at the linked PR but there doesn’t seem to be any activity on it for awhile now.

When updating Fluent strings, Pontoon honors the social contract between developers and localizers. To quote the most relevant bit:

If you are changing a string such that its meaning has changed, you must update the string ID.

Regarding the PR, I don’t think it solves the problem. Yes, it allows you to filter strings that have been changed, but that information is not visible on dashboards or under notifications, which users typically watch to see what needs to be worked on.

@mathjazz Does this mean such a feature is unlikely to ever make it into Pontoon?

For various reasons changing the string ID is not a practical solution for my use case.

@limzykenneth A feature to unapprove FTL translations when source string changes is indeed unlikely to make it, because it would break existing workflows by breaking the aforementioned social contract.

We could however land https://github.com/mozilla/pontoon/pull/1625. I wonder if that’s a good enough solution for you.

@mathjazz Unapproving FTL translations is also something I would not want as when the original string is updated I want to keep the existing translation still while a translator make the decision of whether the string needs to be updated or not (I don’t want the developer to be the one to make this decision is one of the reasons why changing string ID doesn’t quite work for me).

I think https://github.com/mozilla/pontoon/pull/1625 is indeed pretty close to what I’m looking for. The interaction between Pontoon and the source repo doesn’t need to change from what I can see, marking a translation as stale is just a way to indicate to translators that the translations may require edits (and is a lower priority job than fully untranslated strings), the underlying FTL file doesn’t need to be edited yet, just the database entry in Pontoon.

I also agree that adding visibility on the dashboard would help translators find these stale strings, although does this need to be implemented in 1625 or could it be a separate PR after 1625 is merged?

That sounds like you’d need a new translation status that would capture all strings for which the source string has changed since the translation has been approved. That status would then appear in the filters and dashboards.

(For us, this also wouldn’t work, because it’s again against the social contract. We don’t want that the typo we fix in the source string to result in extra work for localizers).

It doesn’t even affect the DB. The filter just compares the times of source string update and translation approval, which could make the filter quite useless over time, because there’s no easy way to “unstale” the translations. (Unless you unapprove and approve translations again, but that’s a really poor UX).

Also note that the PR needs a new owner, because it needs to be rebased against current master. We should also implement it as an optional feature per instance (e.g. have a setting to turn it on/off).

That’s basically a completely different feature, a bigger one, because it effectively implements the new translation status, which also requires changes to stats calculation.