1397377 - [translate] Restore delete translation option

Status: RESOLVED FIXED

(Webtools Graveyard :: Pontoon, enhancement, P2)

Description

[Matjaz Horvat [:mathjazz]]

Ability to delete translations has been replaced with the reject option as part of bug 1288956.

Removing the option to delete translations has several benefits. For example, it allows us to keep the exact history of translations for each string and see the exact approved vs. rejected ratio per contributor. That makes it possible for Pontoon to (one day) send a notification to team managers that a new contributor started to improve so they should consider giving her Translator permissions.

On the other hand, if one makes a typo and instantly notice it, the reject option sometimes isn't sufficient to overcome the embarrassment. Also, not being able to delete translations means we'll need to keep spam and inappropriate submissions in the DB and UI forever.

Let's collect the pros and cons of the delete translation option and identify any actionable items.

Comment 1

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

Let me add a short feedback here. I was one of the people "complaining" about not able to remove suggestions. But after some time not being able to do it I have realized there is only one scenario when I did so, and that was a typo or an immediate idea to improve my own translation before it get approved. Once I approved a translation, I never deleted it (or maybe I did, but before the first sync and commit to the repository).

So what about adding the delete option back, but only for suggestions, that were actually never approved (and never made it to the repository history)? That way we can remove spam and typos, and keep in mind, that deleting anything else may bend our stats, if we calculate some one day.

Comment 2

[Francesco Lodolo [:flod]]

Personally I'd prefer to be able to delete translations. I often find myself correcting a string right after I submitted, and before review, not much of a point in keeping both (actually confusing).

> Removing the option to delete translations has several benefits. For
> example, it allows us to keep the exact history of translations for each
> string and see the exact approved vs. rejected ratio per contributor. That
> makes it possible for Pontoon to (one day) send a notification to team
> managers that a new contributor started to improve so they should consider
> giving her Translator permissions.

Do we need to keep translations forever to do that? It sounds like that would be only useful to recalculate stats.

We should still be able to do that by storing that ratio in the contributor when a string is rejected, not sure how much of a performance hit it would be.

Comment 3

[Jeff Beatty [:gueroJeff]]

Since one of the problems we're trying to solve is spam and typos, this begs the question in my mind: why are we keeping rejected suggestions in the TM at all? Unless we hope to add the ability to make a rejected suggestion actionable (meaning that a rejected suggestion is used as a teaching opportunity for the submitter to correct their translation), we shouldn't need to keep rejected suggestions at all. Instead, we should register the action (accept/reject) in user statistics, not the state of each individual database entry.

Comment 4

[Francesco Lodolo [:flod]]

I think there are 2 separate cases:
* I fix a typo, or improve my own translation, and don't want it to be stored.
* I reject someone else's translation, and I want to keep it around for anyone doing another review pass (included the author of the rejected translation).

Delete would only be needed for the for first case.

Comment 5

[Ton [:Tonnes]]

Any news? I’m some users would like to see this restored.

Comment 6

[Matjaz Horvat [:mathjazz]]

The decision has been made some time ago (offline) to restore the delete option, but we never documented it in the bug.

The bug is not on our roadmap for the current roadmap, though. I'm keeping it as P2 so that we don't forget about it when making plans for the next quarter.

Comment 7

[Matjaz Horvat [:mathjazz]]

Attachment: Proposal 1A

Comment 8

[Matjaz Horvat [:mathjazz]]

Attachment: Proposal 1B: Replace "Show diff/Hide digg" with the "Diff" toggle to save some space

Comment 9

[Matjaz Horvat [:mathjazz]]

Attachment: Proposal 2: Move Show/Hide Diff and Delete Translation to the menu

Comment 10

[Matjaz Horvat [:mathjazz]]

Attachment: Proposal 3: Use icon instead of text for "Delete Translation" action

Comment 11

[Matjaz Horvat [:mathjazz]]

I've added a few UI proposals for the Delete Translation action and I'd like to hear your thoughts on this.

I'm a bit concerned about Proposal 3, because it makes the Delete action equivalent to Approve/Reject. I think it will be used much less often.

Comment 12

[Francesco Lodolo [:flod]]

I personally prefer #3, but the question is also if we want to discourage using it, not just how much it will be used. 
If we want to discourage it, then putting it in a submenu might make sense.

I would definitely not hide the SHOW DIFF, requiring another click (#2).

Do we have any data on how often these 3 commands (approve, reject, diff) are used?

Comment 13

[Lan Glad [:upwinxp]]

I like #3, too. How about displaying the delete button only after a translation is rejected?

I agree with Flod about hiding Diff as well.

Comment 14

[Matjaz Horvat [:mathjazz]]

(In reply to Francesco Lodolo [:flod] from comment #12)
> Do we have any data on how often these 3 commands (approve, reject, diff)
> are used?

The only data we have is for the actions below. The number represents clicks in the last 7 days:
- reject: 348
- unreject: 18
- unapprove: 55

Comment 15

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

I also like the proposal #3, but :upwinxp also has a good point.
> How about displaying the delete button only after a translation is rejected?

In any case, I would suggest to add some confirmation step before the string is deleted, because in contrary to approve/unapprove/reject action that are reversible, there is no undelete. To me that can be bigger blocker than how often is will be or is supposed to be used.

As for the "diff" question, I am not a frequent user of it. More than any change in how the action to show/hide it in History tab, I would like to see some consistent UX and UI solution applicable both for History and Machinery tab, which would allow me to show/hide diff for any suggestion in History and for both source and target in Machinery. But that's probably another discussion we can take to a separate ticket?

Comment 16

[Matjaz Horvat [:mathjazz]]

I've staged Proposal 3, ammended with Lan's suggestion - only rejected translations can be deleted:
https://mozilla-pontoon-staging.herokuapp.com/sl/firefox/browser/browser/aboutPolicies.ftl/?string=189611

That means we're implicitly introducing a confirmation step for any non-rejected translation. If you want to delete an approved or unreviewed translation - you need to reject it in step 1 and then delete it.

This approach also keeps Approve & Reject as the only first-rate actions. The Delete action should be used in edge cases, more rarely, and hence, discouraged. It's a different, but still similar kind of UX degradation we talked about for comments over the weekend with :flod and :MikkCZ.

No changes have been made to the Diff functionality.

Please let me know if this is good to move forward.

Comment 17

[Francesco Lodolo [:flod]]

(In reply to Matjaz Horvat [:mathjazz] from comment #16)
> That means we're implicitly introducing a confirmation step for any
> non-rejected translation. If you want to delete an approved or unreviewed
> translation - you need to reject it in step 1 and then delete it.

I think that's acceptable, given that the most common scenario is "multiple suggestions on untranslated string", and approving one will automatically reject all the others. If there's a suggestion on an approved translation, it needs to be explicitly rejected, and that's good.

Stage looks good to me.

Comment 18

[Michal Stanke (Mozilla.cz) [:mstanke][:MikkCZ]]

The behaviour in staging looks good to me. Deleting only rejected suggestions is reasonable, so it won't happen accidentally for approved, or worse unreviewed or uncommited translations.

Comment 19

[Lan Glad [:upwinxp]]

It looks great to me. To prevent deleting a translation accidentally, we might want to add some confirmation box or an undo option; what do you think?

Another question is, who will have the permission to delete translations? Every contributor for their own translations, plus locale managers for everything in their locale?

Comment 20

[Matjaz Horvat [:mathjazz]]

(In reply to Lan Glad [:upwinxp] from comment #19)
> It looks great to me. To prevent deleting a translation accidentally, we
> might want to add some confirmation box or an undo option; what do you think?

That would make deleting Unreviewed suggestions a 3-click process (Reject, Delete, Confirm), which sounds pretty tedious. Undo OTOH would add a lot to code complexity, and I'm not sure that justifies the importance of it.

Note that the original implementation of the Delete functionality (which this bug is resolving), didn't have any confirmation step whatsoever, not even an implicit one (which we're introducing here).

> Another question is, who will have the permission to delete translations?
> Every contributor for their own translations, plus locale managers for
> everything in their locale?

Permission to delete is available to anyone how can reject a translation: you need to be a Translator (or Manager), otherwise you can only delete your own translation.

Comment 21

[[github robot]]

Commit pushed to master at https://github.com/mozilla/pontoon

https://github.com/mozilla/pontoon/commit/ba838fa88b787a9323f563987c35a4904fcab942
Fix bug 1397377: Restore ability to delete translations (#1152)

Translation can only be deleted, if it's rejected. That means we're
implicitly introducing a confirmation step for any non-rejected
translation. If you want to delete an approved or unreviewed
translation, you need to reject it first, and then delete it.

This approach also keeps Approve & Reject as the only first-rate
actions. The Delete action should be used in edge cases, more rarely,
and is hence, discouraged. 

Other changes:
* Make <menu> height always the same, even for non-authenticated users
  and read-only translations. That makes the helpers height occupy the
  entire available height across all pages.
* Unify the way of getting translations from the DB.
* Improve some comments.