Interface translations override config translations on update

Encountered the same issue, on our website some migration modules are enabled then disabled on daily basis to perform some migration sync, it triggers \Drupal\locale\LocaleConfigManager::saveTranslationActive which was overriding our config values.

Our website is in french (default language), single language. So our config strings provided in the install folders of our custom modules were written in FR. So the solution for us was to make sure this yml files in these install folders provides the langcode property with a value of fr! Just modifying this install yml files fixed the problem! The solution is ridiculously easy regarding the damn difficulty to debug it...

This seems like a duplicate of #2806009: Installing a module causes translations to be overwritten. Comment #76 contains a patch to never override config translations with interface translations.
As a side effect configs need to be translated manually, as with that patch no automatic translation is happening from the known interface translation.

Other half related issue is #3150540: Configuration langcode is forced to site default language to make sure your config language does not change at import.

I think this should be re-opened. A number of people in the referenced ticket are still experiencing the issue described even after the fix. It is happening to me in the following scenario on Drupal 10.3

* I have some country names translated in locale E.g. United States = アメリカ in Japanese.
* We display country names in a language selector. That information is stored in simple config.
* Feedback from client was that country names should be displayed in their own language in the language selector. Translations should still exist in other contexts though.
* Put United States for the translation of United States in the Japanese config for the language selector. You could even delete the whole config file.
* Re-import locale like so: drush locale:import --type customized --override customized ja /app/translations/ja.po
* Export your config. You will notice that the config has been overridden with アメリカ

Drupal 9 is EOL. Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies.

It would help to have one issue for the discussion. Can you comment on the other issue that this is open? And update the Issue summary with the most recent steps to reproduce. Thanks

I can confirm this is still happening, as reported by @achap and it's a critical issue for multilanguage sites.
Technically it might make sense to postpone this on #3150540: Configuration langcode is forced to site default language but that would also mean that issue should be seen as a critical fix.

I have a similar problem just the other way around. My interface translations are overwritten by config when I run drush cim

In my case the translation string "Delete" was translated to the Norwegian "Slett" in the "Interface translation". Now I'm doing a drush cim and I'm able to reproduce that the settings.default_delete_button_label from the webform.settings configuration, which has the language: nb (Norwegian) and the English label Delete is overwriting the translation strings.

Can be fixed be changing the webform settings, but I'm quite worried about the side-effects, that a config is overwriting already customized interface translation strings. So whatever I'm overwriting in in "Interface translation", will be in this case overwritten by the webform config.

I also encountered this now in the other direction like comment number #11. Drush cim is adding default translations like "Content Types" into my custom user interface translations in non English languages. So it seems like this issue can occur in both directions. I stumbled upon this module https://www.drupal.org/project/config_import_locale
which provides a more sane behaviour. Now I have set my user interface translations to be the source of truth and when they change, I can export my config and see that it has changed as well. That seems like a more logical behaviour. The current way this works in core feels broken to me or at the very least not intuitive.

@achap & @szeidler thanks for your feedback! You're both reporting this to happen when using drush cim. Is this an effect of core or might this be an issue in drush? Could you find a related drush issue or clear root cause?

If not it might make sense to open a drush issue for further investigations and link it here?

I also think the core concept isn't solid enough, IMHO core should always have EN as "system" language everywhere... to make things more clear and solid. But that's a discussion for a different issue.

As a quick test I tried the following to rule out this being a drush issue and can confirm it occurs only with core.

Firstly, my locale settings. Note that I have overwrite_customized: false and overwrite_not_customized: false. In my project, I turn off all importing from core and contrib. All translations are custom and live in /app/translations.

_core:
  default_config_hash: cSdYeE-_AQETCNZnl8BMFS9-sVn5--VzAYILkpPBUbM
langcode: en-AU
cache_strings: true
translate_english: false
javascript:
  directory: languages
translation:
  use_source: local
  default_filename: '%project-%version.%language.po'
  default_server_pattern: 'https://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po'
  overwrite_customized: false
  overwrite_not_customized: false
  update_interval_days: 0
  path: /app/translations
  import_enabled: false

Note that I also have a "Default" string in my locale database already. I do have this in my UI in a $this->t function but it's possible Drupal also scans the strings in config files to make them appear on the User Interface page at /admin/config/regional/translate.

Steps to reproduce:

1. If you have a pre-existing language config override file, edit a string in there. For example, I have a sync/de/views.view.files.yml file and I changed the display_title key from "Standard", to "Standard Foobar", which is a translation of "Default" in the default config file.
   

   display:
     default:
       display_title: 'Standard Foobar'
       display_options:
         exposed_form:
           options:
             reset_button_label: Zurücksetzen
     page_2:
       display_options:
         arguments:
           fid:
             exception:
               title: Alle
   

2. Go to the configuration synchronization UI at admin/config/development/configuration and synchronize the changes (no drush involved).
3. Go to the user interface page at /admin/config/regional/translate and search for the 'Standard Foobar' translation in German. You will see that it is now the translation of "Default". So my locale.settings: overwrite_customized and overwrite_not_customized, were not respected.
4. If you now edit "Standard Foobar" in the User Interface UI to be "Standard Foobar bla bla" in German and save it, when you return to admin/config/development/configuration all the views that use that string "Default" for the display_title have been changed to "Standard Foobar bla bla". This is kind of more expected and intuitive than the other way around, even though the other way was the reason I stumbled on this issue.

So there is no involvement of Drush, it all happens inside the LocaleConfigSubscriber, which is what config_import_locale overrides.

Maybe then locale overriding config is not such a big deal, and the real bug is when config overrides locale, especially when the locale settings say not to?

I'm on Drupal 10.5.9. Since there is a workaround for this via a contrib module, maybe we can reduce the priority to normal?

Nice catch @achap! Just recognized that @L_VanDamme created this issue, who also created the contrib module. So I guess we now might have a plan for a fix. Maybe config translations could generally use the "context" parameter in translations for example, so there's no overlap. That's an existing, clever concept!

We could then extend that to inherit to context from no-context if no explicit tranlsation exists, but that's a different improvement.