Active
Project:
Drupal core
Version:
main
Component:
locale.module
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
1 Nov 2026 at 16:07 UTC
Updated:
2 Nov 2026 at 16:05 UTC
Jump to comment: Most recent
• Drupal core
• Version: 11.x
• affects also drupal commerce
• Component: Configuration Management System / Translation API
Any change of a screen name for an entity results in a change from "display" to the new screen name where default entity of machine name is used.
Background
- This was discovered while transferring data from D10 to D11 via sql and drush rebuilding views manually and I probed this extensively with AI. It is unclear if this is a core problem or caused by the transfer of D10 data to D11 or caused by Drupal Commerce after adding this.
In drupal commerce but caused by a core issue:
- changing the screen name of product type / product variation machine name "default" leaks into anywhere where display is used in views.
In Order type
- Changing default name of ID default leaks into all displays of products and views.
In Stock location type entities
- Changing default name of machine name: default leaks into all displays of products and views.
As a consequence of leaking into all displays, entities and machine names "default" a totally confusing situation appears due to anything related to "default" changes to the latest screen name everywhere associated to default "ID", entity or machine name.
Temporary Work around
Do not modify or repurpose a native entity bundle named "default".
Create a brand-new ID, entity or items with a machine name, and use that instead.
Issue fork drupal-3634663
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
shank115 commentedReproduced on 11.x without Commerce: rename the shipped shortcut set "Default" on a site where English is translatable (or the default language isn't English), and the Views UI "Default" display tab picks up the new name.
The cause is
LocaleConfigSubscriber::onConfigSave(). Saving shipped config writes the new label back as a customized translation of its source string.Moving to locale.module.
Comment #3
panchoReproduced on main, on 10.6.20, on 9.5.11 and on 8.9.20, so not at all a new regression.
Seems to be introduced in 2015 by #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated
Now that we're aware of it, however this is clearly critical and probably a release blocker.
I think we'll find a solution for it, but it's not straightforward.
Comment #4
panchoThere's a couple of things to say about what's wrong with the implentation of #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated:
The mere fact that someone customizes a Configuration label or something doesn't imply that this is a generic translation of a particular string useful enough for it to be wirtten back to a global dictionary.
It doesn't even imply that it's a translation into the current interface language at all, or into any other language.
It's just some blob that may be one or a couple of words in any language, or even an untranslatable personal name, number, ID, or whatever. We don't know.
And the user may not even know they are translating something, lest alone for a site-wide dictionary. There's no langcode shown, there's no warning, nothing.
If we want users with the right permission to have a translation written back to some dictionary, then at the very least they need to be informed about it. But besides that, there should be an option to override it, thereby taking the string out of the translation update automatism. And a way to revert that decision.
Optimal solution might be a way to store local config overrides with the "und" langcode by field. But that'd mean we had to expand our YAML config format as well, I guess.
I'm trying to avoid that and settle with storing overrides in the dictionary with sufficient context, so effectively they aren't too global any longer. Let's see how far we can get this way.
Comment #5
panchoThere are so many inconsistencies in both code and logic that will have to be tackled in followup issues.
At this point, we don't want to rewrite everything, just do a proper bugfix without introducing codebloat, redundancies, performance degradation, new inconsistencies, or one-off architecture.
Still, the MR I'm working on is going to be quite substantial and will need throrough reviewing. I'll try to break it down into a couple of individual commits.