Files sync is triggered, despite no change actually happened

[bugzilla-to-github]

This issue was created automatically by a script.

Bug 1388459

Bug Reporter: @MikkCZ
CC: @flodolo, @mathjazz

STR:

1. Open an arbitrary file in Firefox project.
2. Find an approved string.
3. Submit a suggestion for this string and approve it.
4. Go back to the string.
5. Delete the new translation from step 3 and approve the previous again.
6. Pontoon triggers sync for that file, effectively updating comments and cleaning old strings, see https://hg.mozilla.org/l10n-central/cs/rev/3eef070f8347.

Btw. as a localizer i would find helpful to be able trigger this for the whole project intentionally, to clean the old strings from the files and update comments, mostly because of the comments.

[bugzilla-to-github]

Comment Author: @flodolo

I'm not completely sure Pontoon can differentiate an actual change from a change+revert.

The reason we changed the way sync works is to minimize the number of commits that don't have actual human activity behind, so I'm a bit wary of adding back a way to trigger that manually.

Do you have a specific use case where comments changed and they would have been useful in the file?

[bugzilla-to-github]

Comment Author: @MikkCZ

I understand the motivation behind to see only actual activity in the repository, and hopefully reduce the sync time if there if there was nothing done by the particular team. If Pontoon can differentiate, not syncing the files without effective change (like here) could squash the number of commits or the changeset in there rare cases.

Being able to trigger the update manually is only nice to have. It would help to keep the comments up to date for someone looking into the files directly (e.g. link from Transvision) even if there was no new string in the file. If order this list https://pontoon.mozilla.org/cs/firefox/ by latest activity, there is bunch of files with no activity over a year, that may contain updated comments in en-US.

[bugzilla-to-github]

Comment Author: @mathjazz

We don't have sufficient information for all such cases ATM, but we should be able to gather it. For example, the first time the string is changed since the last sync, we could store the state at the last sync (either previously approved translation or None). And then use this as reference when any subsequent change is made.

That said, I think fixing this bug brings very little to decreasing the overal sync time, since such cases are hardly very common. Especially compared to bug #1383252, which is a relatively simple fix and should bring substantial performance wins.

Setting priority to P5.