Change 228220 had a related patch set uploaded (by Santhosh):
MT Card: Hightlight the section when hovering action buttons

https://gerrit.wikimedia.org/r/228220

Change 228220 merged by jenkins-bot:
MT Card: Hightlight the section when hovering action buttons

https://gerrit.wikimedia.org/r/228220

This might be delayed till VE integration(which will bring undo,redo support)

How about the following simplistic solution: Remove this button entirely.

It's possible to delete a paragraph's content by marking all the text and pressing the Delete key. It's just as effective, it's generic, it's undoable, and it's not destructive. Other thoughts?

In T106427#2031021, @Amire80 wrote:

How about the following simplistic solution: Remove this button entirely.

It's possible to delete a paragraph's content by marking all the text and pressing the Delete key. It's just as effective, it's generic, it's undoable, and it's not destructive. Other thoughts?

I see value in providing a quick way to clear the paragraph:

• The purpose of having a quick way to clear the paragraph is that it reduces the negative impact of having a potentially low quality automatic translation. If the user gets a bad translation for a specific paragraph, she can start from scratch (or using the source text as a template) in a single click.
• Clearing a paragraph manually requires additional steps and relies on either users precision (to select the proper content) or familiarity with keyboard shortcuts.

OK... so how can we fix it without it? It's a thing that people keep complaining about as a kind of data loss. Save the content being deleted it in localstorage? (I'm kinda unhappy about reimplementing the Undo action that browsers provide, but I guess we could something limited. Most importantly, I don't want users to lose the work they typed.

In T106427#2031424, @Amire80 wrote:

OK... so how can we fix it without it? It's a thing that people keep complaining about as a kind of data loss. Save the content being deleted it in localstorage? (I'm kinda unhappy about reimplementing the Undo action that browsers provide, but I guess we could something limited. Most importantly, I don't want users to lose the work they typed.

Some local way to keep the information sounds good to me (localstorage, a property of the dom element, ...), I think we don't need to keep that info across multiple translation sessions.

I recalled one reported case where the action was applied accidentally when trying to add a link. For similar cases, one of the proposed points would help:

Don't show the paragraph/MT card when there is text selected. Show it only when the text caret is on a given paragraph.

Not showing the card when it is not relevant will help to keep things simple and avoid unintended uses too.

Don't show the paragraph/MT card when there is text selected. Show it only when the text caret is on a given paragraph.

Not showing the card when it is not relevant will help to keep things simple and avoid unintended uses too.

That seems to be already done. I'll update the ticket description to reflect the status of the sub-items.

This is high priority, because it causes data loss.

It generates data loss, but it is also worth mentioning that the cause and how to prevent it becomes also obvious to the user (unlike receiving a cryptic error after hitting "publish", for example). So while I agree that we need to polish the experience, we should not consider just a general "data loss" bucket. Whether those two cases are both marked as "high" in Phabricator is your call, but just wanted to point a difference I think is relevant.

Also, do we have some data on how much this action is used? (I guess it would be hard to identify how many of those uses causes trouble, but having the frequency of use can be informative).

In T106427#2039203, @Pginer-WMF wrote:

This is high priority, because it causes data loss.

It generates data loss, but it is also worth mentioning that the cause and how to prevent it becomes also obvious to the user (unlike receiving a cryptic error after hitting "publish", for example). So while I agree that we need to polish the experience, we should not consider just a general "data loss" bucket. Whether those two cases are both marked as "high" in Phabricator is your call, but just wanted to point a difference I think is relevant.

Of course they are not the same, but as far as the users are concerned, a text on which they were working for some time is irrecoverably lost in both cases.

Also, do we have some data on how much this action is used? (I guess it would be hard to identify how many of those uses causes trouble, but having the frequency of use can be informative).

No. It's fairly easy to add an EventLogging event for this, though I'm not sure it's worth it (why this and not any of the other buttons?)

No. It's fairly easy to add an EventLogging event for this, though I'm not sure it's worth it (why this and not any of the other buttons?)

Because it is a potential source of frequent or infrequent data loss, unlike other buttons you didn't suggest to remove.

Since now we are applying the MT strategy as soon as it is selected, there are some clarifications needed on this ticket. I'll add more details.

I explored a way to reduce data loss by simplifying the MT card: T130594: Simplify the "Automatic translation" card
That provides a way to keep user modifications while making the destructive actions more explicit.
Feel free to add it as a blocker of the current one if needed.