At the moment I'm not sure if this is a bug, something I'm doing wrong, assumptions I'm making that are wrong, or anything else.
So I'm posting it as support so we can figure out what this behaviour is.

Problem/Motivation

The problem is that an interface translation that was added for a string coming from a custom module was reverted (deleted) after importing an untranslated views configuration that had the same string as a translatable label in it.

To reproduce the issue:
1/ Install Drupal and make sure you have enabled views and file modules and setup at least 2 languages. (this is very specific for this example, but in theory any view would have this issue)
The view "views.view.files" (/admin/content/files) needs to exist and not be translated.
2/ Export your configuration (in my case this is always done so we can deploy the configuration to other environments and/or developer)
3/ Create a custom module that includes "anything" that outputs a translatable string "Name". In my case I had a custom form with the below element in it:

    $form['name'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Name'),
      '#required' => TRUE,
    ];

4/ Visit the page that shows the custom form from step 3 in another language so the "Name" label becomes translatable.
5/ Go to the interface translation administration screen, search for "Name" and translate it to another language.
6/ Visit the page that shows the custom form from step 3 in another language and verify that "Name" is indeed translated. (it will be :))
7/ Import the config exported in step 2. (this simulates a deploy to another environment) This config import will indicate that "views.view.files" needs to be reverted, although no changes were made to it. Accept this and continue.
8/ Do 6/ again and you will see that the translation for "Name" is lost.

The above example is very specific to the view "views.view.files" and the translatable label "Name". But the same principle will apply to any label in any view that is also used elsewhere.

I know that the config import warns about the change, but this is really confusing since no changes were made to the view and the translation that was added is (at least to me) totally unrelated.

I fixed my problem by adding a context to my custom "Name" label in the form.

    $form['name'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Name', [], [ 'context' => 'my_module' ]),
      '#required' => TRUE,
    ];

But this feels really wrong to me... That would mean that any custom module (even contrib) that wants to translate anything should always add a context to prevent views module from interfering if you import config.

Proposed resolution

We need to clarify first if this is me doing something wrong or not. This is just a support request for now ;)

To the best of my knowledge, translations of view labels should never go through the interface translation, but only live in configuration. (just like field labels for example)

Remaining tasks

Figure out if this is bug, needs documentation, ...

Comments

weseze created an issue. See original summary.

Version: 8.4.4 » 8.4.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

Version: 8.4.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

thomjjames’s picture

Hi,

Also experiencing this now on multiple sites. Seems to only effect more common strings like "Search" & "Yes" so I wonder if they're being picked up from the config & reverted on config import. It does not delete the translations (ie. translation isn't blank in the UI), it reverts them to the default language version.

Will try to debug some more & report back.

Thanks
Tom

thomjjames’s picture

Just posting a workaround I'm using in case it helps anyone finding this, for me it was only 3 strings effected so far so this is sustainable (for now) & simple:

In Twig:
{{ 'STRING'|t({}, {'context' : 'CONTEXT_NAME'}) }}

In PHP:
t($string, [], ['context' => 'CONTEXT_NAME']);

Do wonder if this is a bug though as I guess the strings shouldn't get reverted on config import regardless of where they are used.

Thanks
Tom

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.