English translation of the data protection policy path set back to the default value

> Update the website: the english translation for the settings is now set, to .

It's not really about updating, it's about doing something that causes locale/config translation to sync between config. For example installing a module or doing a manual translation update.

I'll try to follow-up a bit with what's going on exactly.

Thanks for the issue and the patch.

I'm puzzled that an empty string will behave better than a string with content. Aren't they both strings to Drupal?

Can somebody please post a list of steps to reproduce? The ones given were a big vague.

This Twitter conversation fits well here: https://twitter.com/gaborhojtsy/status/1517246677438107648

@svenryen: to reproduce, these steps should work:

1. install site with default language other than EN
2. make the site multilingual
3. take care, that the English translation of the config does not override the popup_link
4. then run locale update of the site - or maybe better install any contrib module, so that locale update will then be triggered

In most of the cases, you should have comletely overridden your English version of the eu_cookie_compliance, including popup_link set to

Also, I often face problems on non-multilingual sites (in German), that after DB updates, locale updates, module installations, occasionally either the popup_up link gets overridden by the confirmation_url value of our contact webform, vice versa. I guess, it's because both are shipped with as default value. Then you override both independently of each other, but Drupal treats them as translations of the "" string, then updating both configs to the same "translation" from time to time

Thanks for the steps, agoradesign.

Is there any good design pattern to implement or contrib module we could use to remedy this?

I notice that other config values are also wiped or reset when I require and enable another module, not just the privacy policy.

I can confirm the patch solves the issue in question for the policy link, so we need to do the same for all the other settings that are translatable?

That's what Gábor replied on Twitter: "Configuration overrides is an infinitely extensible thing that is layered on top of each other. A module or suite of modules should implement this use case if not already. It was/is not in scope in core."

So the main problem is, that there's no unified solution for this use case of having different values per language, that are not really translatable strings, but rather "real values" - from Core at least. You have the configuration override system, but you have to find a way to use it properly in such cases. I don't know, if there are contrib modules out there handling this, but I am also not a fan of enforcing to use them, just because a module like eu_cookie_compliance or webform *could* potentially be used in a multilingual environment.

Maybe you can reach out to Gábor Hojtsy. He's the big expert on this topic, hopefully he can find some time to discuss this

I've been meaning to do configurations per language (since there are other values than strings that admins may want to localize) for version 2.0.x, so maybe we can do a quick fix for version 1.x and then later do a better job.

For now I will try setting more values to "" to see if that helps.

Have a look at the patch from the Merge Request:
https://git.drupalcode.org/project/eu-cookie-compliance/-/merge_requests...

This patch clears all the 14 instances of translatable text from the install YAML file, and sets defaults in the php code instead.
I just tested the patch and it seems to do the trick.

Can somebody else quickly take a look at the issue branch and help do a review?

Wow, a lot of activity here, didn't expect that.

There are multiple aspects to this. Partially, this feels like a deja-vu, like we had this discussion already at some point, partially at least.

One thing, as mentioned above, the combination of having default configuration with language code en and for configuration that is defined as translatable in the schema, it means that drupal considers them candidates for official translations through localize.drupal.org, see https://localize.drupal.org/translate/languages/de/translate?project=eu_....

Because the only mechanism to transport and import configurations is through locale translation, this also becomes a locale/interface translation string.

But that's only the beginning.

Now, you've installed the module on a site where you have english installed and also germanas default language. Then you go ahead and change the configuration from <front> to something else on the default config, lets say /node/25. What happens now is that drupal knows that this is a translatable string, so it syncs this configuration change on save also back into the locale table, so now you have a global interface translation of <front> to "/node/25". You make the same change then also on the EN config translation, because you want that to be the same. This does not update the locale table, like you haven't even enabled EN interface translation.

Now, something like installing a module happens and drupal does the opposite, it imports locale translations for that module from localize.drupal.org into the locales table and syncs that back into the config system. It sees the following things:

* Default config of this has "<front>" in the module
* locale has a translation of "<front>" to "/node/25" for german
* installed en config override has "/node/25"
* default config in de has "/node/25"
* It's now trying to be helpful, and thinks, wait, the en translation of this in config is wrong and not in sync with locale. And it "back-translates "/node/25" to "<front>" into your en config override.

By removing the default config value for this, the config/locale sync system can no longer make the connection that this is a default translation and stops that sync. However, I still don't fully understand the whole picture, specifically why this specific key is more likely to be wrongly back-translated and other configuration less so.

And I'm also not sure that applying this pattern for this specific key, where we can say for 100% certainty that it makes no sense to have a default translation for for this specific configuration, makes sense for everything. What this means is that non-EN installations lose the ability to get default translations for that configuration, so it will always be EN for them and the existing translations like "Accept" will not be imported anymore and everyone has to do that manually.

Related core issue:

* #2275865: Per language settings (vs translated settings) are not directly supported: on the definition and meaning of translatable config, what core considers it means.
* #2806009: Installing a module causes translations to be overwritten: about this behavior in general, not everyone agrees which part is a feature, what's a bug, what core should or shouldn't do.
* #3079242: \Drupal\locale\LocaleConfigManager::updateConfigTranslations() should not remove non-existing EN translations: for the special case of the above when you have EN as a non-default language. we used that on our site, it solves many cases, but it's also possible that it affects the exact behavior here in a way that's different for us than others.

@agoradesign: Ah yes, I saw that webform also shows up as related projects for the localize.drupal.org string. That's equally incorrect then and causes exactly this problem, as the localize.drupal.org string is global and doesn't have a context.

Another (old, closed) related issue: #2791405: When installing a site in a language besides English, the site name is not saved and reverts to "Drupal". We had this exact same problem with the site name in our install profile too and only just recently removed the default config for it, this is basically the same concept as this although the default is more dynamic there.

@mathilde_dumond, I tried changing the other field values (like Accept button label) on the test site and they also reverted, which I why I expanded on the patch a bit. Are you able to review the Merge Request that I opened?

The config translation system is designed to translate UI string and not "different values per language". That would need for example widgets to support path entry with validation (access checking, validity checking, etc), so you don't enter <font> instead of <front> or whatnot, and break things. The config translation system does not support these and assumes instead that the translated values are human readable text that is to be translated centrally on localize.drupal.org and not a site specific language dependent configuration. So if you use translatable configuration for the later, the results would be incorrect.

Re @berdir's example from:

* Default config of this has "" in the module
* locale has a translation of "" to "/node/25" for german
* installed en config override has "/node/25"
* default config in de has "/node/25"
* It's now trying to be helpful, and thinks, wait, the en translation of this in config is wrong and not in sync with locale. And it "back-translates "/node/25" to "" into your en config override.

I think if English is not marked as translatable, locale should not back-translate it. I mean if it does that would be a bug, since it does not maintian a list of English translations and thus cannot update it's understanding of the English strings, while the English override is editable and thus may change. It still needs to create the English overrides originally, but should not be dealing with keeping it up to date. When English is enabled for translation, it would need to sweep in and import all the changed translations from config (overrides) though. Is there a dedicated bug report for this already?

@Gabor: Yes, I'm aware of that, which is why I proposed to just remove the front. But it's also more complex than that, especially with short, common terms. The config translation system claims that every config and every single setting can be translated separately.

But the (inconsistent, unpredictable*) sync with the locale table of many of these means that's not true. We just did some quick tests, what's happening at the moment is that when you save a config translation of something that exists in the locale table, it syncs it into that table but *not* yet into other configs. But when you then install a module for example, it syncs that back into every single place in every config that uses the same string *in the default config* of the module. So it doesn't even consider that you locally customized it to a completely different value. And because of that unpredictable order, if you edit multiple configs in a row, the last one wins and is then synced back into everything the next time you install a module.

Another really ugly side effect is changing default configuration. If eu_cookie_compliance decided to change the h2 to a h3 in its default text, it is going to actively delete/reset any existing *customization* of that string in all config translations of existing sites. This has happened several times to us already for this module.

That's not how many config strings work. They are meant to be *defaults* that you can change, not something that means the same thing for everyone, not even on the same site (Multiple configs might use Accept or Title and so on that you want to change differently in different places.

But this is all a bit off topic. I'll try to follow-up in the mentioned core issues. Short version is that yes, for now I think this is the correct approach. The practical difference is that you still get translated values when initially installing, for the default language, but you won't get config translations. Which seems like an acceptable side effect because config in this module is highly likely to require to be customized anyway, and not just translated.

Re this patch I think at best it could be a workaround that works for you. From the core feature's point of view, the correct fix would be to remove translatability of this config key from the config schema, which should fix it being tossed around to different values, but it would need to implement language value swapping a different way, not shoehorn it into the core feature that was not intended for this and thus leads to bugs with the module.

@berdir:

But the (inconsistent, unpredictable*) sync with the locale table of many of these means that's not true. We just did some quick tests, what's happening at the moment is that when you save a config translation of something that exists in the locale table, it syncs it into that table but *not* yet into other configs. But when you then install a module for example, it syncs that back into every single place in every config that uses the same string *in the default config* of the module. So it doesn't even consider that you locally customized it to a completely different value. And because of that unpredictable order, if you edit multiple configs in a row, the last one wins and is then synced back into everything the next time you install a module.

Yeah if core does not sync back the config translation to other configs after it synched to the locale tables, that is a bug that needs fixing. So that the core behaviour happens instantly instead of later when config install happens.

@mathilde_dumond, I'll mark it RTBC based on your comment in #24

...........The config translation system claims that every config and every single setting can be translated separately.

But the (inconsistent, unpredictable*) sync with the locale table of many of these means that's not true.

..... if you edit multiple configs in a row, the last one wins and is then synced back into everything the next time you install a module.

I'm aware that this is a little bit out of scope here, but this has bitten me already a couple of times eg. with the "Body" field label, when you eg. create a "job_offer" node bundle and want to rename the "Body" label to "Job description" there. Then you have to fix configs manually quite often, as either other "Body" labels gets renamed to "Job description" as well, or that one gets renamed to "Body".. The last one wins ;)

I bet it related to #2806009: Installing a module causes translations to be overwritten