Regression: not possible to delete source strings in Drupal 8 interface translation

Tested #53 with php 8.1 and Drupal Core 9.5.4. Works perfectly both with single or multiple selections for delete.
RTBTC +1

Tested #53 with 9.5.9 and it works nicely

Same patch as #53 with a typo fixed.

I re-rolled #57 and created an MR for work going forward. The patch is the current state of the MR.

FYI Patch #57 works with the latest Drupal 10.1.6

But #59 can't be applied, maybe works only with the latest core dev?
Drush error: Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2023-12-02/2503893-59-fix-string-reg... →

Patch #59 is for the 11.x-dev branch, because that's the current commit target. It should also work with Drupal 10.2.x, which will be out in a few days.

Perhaps we should also test multiple deletion?

Drupal Usability Meeting 📌 Drupal Usability Meeting 2024-05-10 Active reviewed 🐛 Regression: not possible to delete source strings in Drupal (>7) interface translation Needs review

[placeholder for notes]

For the record, the attendees at the usability meeting (Comment #64) were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @skaught, and @worldlinemine.

We all agreed that the two submit buttons ("Save translations" and "Delete translations") were confusing. Given that, I do not think we should implement a confirmation form.

Deleting a translatable string is temporary. As soon as someone visits a page where the string is used, the string is re-added to the list of strings available for translation. This whole approach seems confusing from a usability perspective.

Opinions at the usability meeting were divided. Some of us were in favor of each of these proposals:

1. Close this issue as "won't fix".
2. Add a checkbox as in the current MR, but not a second submit button. When the form is submitted, the checkbox has the same effect as deleting the text in the "Translation for ..." column.
3. Add help text to clarify that deleting the translation means the source string will be used.

I have used this patch with great success in several projects. It is great to delete some translations that were added by mistake due to inexperienced developers passing dynamic strings to $this->t().

Now, this is really helpful in these cases, but in _normal_ usage this issue shouldn't really arise. When using good quality stable modules, and custom code that has been peer-reviewed, in theory no "bad" source strings should be present. So I think this is solving an edge case and should not be included in core. It would be great to have this in a small contrib module though.

I am in favor of closing this as "Won't fix" and move it to contrib.

Even if I might agree this could happen in contrib first, strings are added/removed in different module versions without only being a result of bad practice per se.

Sooner than later, with the different page builders being built like XB, we will have SDC components strings here too, and SDC components will evolve too.
Also recipes will have translations (hopefully) soon, which might be affected by the same.
So it's not a priority for me, but Close (Won't fix) is probably excessive :-)

I rerolled the #39's patch to apply against 10.5.1 including the last commit from #63