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

Created on 10 June 2015, about 10 years ago
Updated 16 March 2023, over 2 years ago

Problem/Motivation

When user is on User Interface translation page then user is not able to see Delete string.

Original report
Hello, In D7 we had the option to edit and delete text strings in theme_locale_languages_overview_form

Now, in D8 we have the option to edit in-line, but where is the option to delete? (in TranslateEditForm)

Any alternative to deleting strings?

Thanks

Steps to reproduce

- Goto: Configuration -> User Interface Tranlsation
- Delete string is not appearing at right side.

Proposed resolution

Introduce Delete checkbox to delete the translation.
Once the checkbox is checked and the form is saved then it will delete the string.

Remaining tasks

Needs a Usability review.
Patch review
Commit

User interface changes

New checkbox will be added on string translation form.

After
Screenshot after patch in #25 (screenshot from #28)

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Needs work

Version

10.1

Component
Locale 

Last updated 4 days ago

Created by

🇪🇸Spain facine

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇧🇬Bulgaria a.sotirov

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

  • 🇧🇪Belgium DuneBL

    Tested #53 with 9.5.9 and it works nicely

  • 🇳🇱Netherlands AshM

    Same patch as #53 with a typo fixed.

  • Merge request !5651reroll #57 → (Open) created by ptmkenny
  • 🇯🇵Japan ptmkenny

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

  • Pipeline finished with Success
    over 1 year ago
    Total: 593s
    #58247
  • 🇨🇿Czech Republic Bohus Ulrych Pilsen (Czechia)

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

  • 🇯🇵Japan ptmkenny

    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.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MariaDB 10.3.22
    last update over 1 year ago
    25,880 pass, 1,781 fail
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7 updated deps
    last update over 1 year ago
    Build Successful
  • First commit to issue fork.
  • Pipeline finished with Success
    about 1 year ago
    Total: 890s
    #164823
  • Status changed to Needs review about 1 year ago
  • 🇩🇪Germany tobiasb Berlin

    Perhaps we should also test multiple deletion?

  • Pipeline finished with Success
    about 1 year ago
    Total: 566s
    #164838
  • Status changed to Needs work about 1 year ago
  • 🇺🇸United States benjifisher Boston area

    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.
  • 🇧🇬Bulgaria pfrenssen Sofia

    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.

  • 🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

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

Production build 0.71.5 2024