Unapproving translations whose source strings have been updated

[mathjazz]

@limzykenneth

@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).

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).

@limzykenneth

I think Add a filter for "Stale" translation by anandthakker · Pull Request #1625 · mozilla/pontoon · GitHub 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.

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).

@limzykenneth

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’s basically a completely different feature, a bigger one, because it effectively implements the new translation status, which also requires changes to stats calculation.