The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Currently, when a site builder creates or edits certain configuration entities (like Views, Taxonomy Vocabularies, Menus, and Date Formats in core), they are always presented with a hardcoded language selector dropdown:
This leads to several issues:
- UI clutter: It adds unnecessary complexity for these forms unless the site needs this feature. Especially the
Not specifiedandNot applicableoptions could be confusing to some, these are pretty advanced data modeling features. - Inconsistent config: While Drupal is capable to handle this functionality, if the site does not desire the potential fragmentation of configuration language, then a site builder accidentally selecting a different language will potentially cause problems down the line with consistency and translation. Config entities saved in not human languages also cause problems with 3rd party settings, this needs a followup. See #3600904: Shipped configuration entities that do not have translatable elements are not set to the site default langcode as it pertains to default config.
- Future enhancement: This page will be the logical place to introduce a "Configuration default language" setting separate from site default language to serve multilingual sites better as they transition languages. See #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" for that.
Steps to reproduce
- Add multiple languages.
- Crete a menu or date format or view or taxonomy vocabulary.
Proposed resolution
Introduce a centralized UI to allow administrators to toggle the visibility of the language selector on configuration entity forms (that allow them), defaulting to hidden on new installs and not hidden on existing installs to retain existing behaviour.
Remaining tasks
Review.
User interface changes
- Addition of a new menu link under
Administration > Configuration > Regional and language: Configuration language. This is alongside the existing Content language option.
- A new settings form containing checkboxes for supported configuration entities.
- The language selector dropdown will disappear from Views, Menus, Date Formats, and Vocabularies by default, simplifying the authoring experience.
- Site builders can still enable these features on those config entities.
- Language selector will not be possible on the UI to magically add to config entity types that don't otherwise support it.
Introduced terminology
None.
API changes
A langcode_configurable property is added to \Drupal\Core\Config\Entity\ConfigEntityTypeInterface and \Drupal\Core\Config\Entity\ConfigEntityType, and a isLangcodeConfigurable() getter method is added.
A new language.config_entity_langcode_config service is introduced to be used by custom config entity forms, such as in Views. The service provides a showLangcode(string $entity_type_id): bool method to check if a certain config entity type should show the language code or not. View is updated in core to use this, other core config entity types use the core built-in form structure so are are well served by the automated alter method already in place.
Data model changes
A new configuration schema for language.config_type_settings is added to store the boolean visibility preferences for each entity type.
Release notes snippet
New installations of Drupal will not show the language selector on configuration entity types (such as Menus, Date Formats, Views and Taxonomy Vocabularies) by default to simplify the interface and enforce a consistent configuration source language. Site administrators can now selectively show the language selector dropdown on these configuration entity forms if they desire. The new settings page is available at Administration > Configuration > Regional and language > Configuration language to manage these preferences.
A langcode_configurable property is added to \Drupal\Core\Config\Entity\ConfigEntityTypeInterface and \Drupal\Core\Config\Entity\ConfigEntityType, and a isLangcodeConfigurable() getter method is added to support this.
Contributed and custom configuration entities that support changing the language should start adopting these to record explicit user intent about language configuration.
LLM disclosure
LLM was used to accelerate the development of this MR. All the changes were closely reviewed and endorsed as a human.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screenshot 2026-07-06 at 10.31.21.png | 117.46 KB | gábor hojtsy |
| #3 | Screenshot 2026-07-06 at 09.30.36.png | 115.61 KB | gábor hojtsy |
| #3 | Screenshot 2026-07-06 at 09.30.10.png | 138.92 KB | gábor hojtsy |
| Screenshot 2026-07-05 at 18.42.46.png | 168.7 KB | gábor hojtsy |
Issue fork drupal-3608533
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:
changes
Comments
Comment #2
gábor hojtsyComment #3
gábor hojtsyUpdating issue summary with screenshots and more elaborate explanation on new APIs and consequences.
Comment #5
anybodyThanks @gábor hojtsy I very much like the idea! Just left two little comments, code LGTM. I think I'm not the right person to set this RTBC because I'm just in the user's perspective, but a Drupal language system expert. Maybe also someone from the UX team should look into it?
From my perspective it's a big step forward for much better and clearer SBX, even if it's one more (but very logically relevant) settings page.
Comment #6
gábor hojtsyCreated a parent issue to group related problems and show how this leads to resolving config language issues once and for all hopefully :D
Comment #7
gábor hojtsyCheckboxes form label now explains the current site default language to make it easier to understand how this works. Thanks @Anybody for the suggestion.
Comment #8
gábor hojtsyComment #9
gábor hojtsyComment #10
gábor hojtsyFully working solution presented in MR.
Comment #11
anybodyThanks @gábor hojtsy works GREAT! In contrast to #5 I'm setting this RTBC, but please ask others to review it, maybe the UX team or whoever should have a look. I just want to unblock this, but in a quite defensive manner, you're the right one to decide who should sign this off.
Comment #12
gábor hojtsy@anybody: did you try manually on a new site and/or an existing site with running the update function that it works as expected? (It is my understanding that reviewing code may not be your strong side, but if that is a misunderstanding then what about the code other than the UI elements you suggested changed for? :)
Comment #13
andypostComment #14
jose reyero commentedThis feature makes a lot of sense, yes.
However, it looks hard to grasp from the config page alone.. Even after reading this issue, I had trouble at first understanding the final line "Items not listed will always be created in the site default language." ... that is right, just hard to grasp (Items listed, items checked, items not listed.... :O ) I don't know, maybe less words, more words, or better wording, or maybe it's just me, I don't know ...
Maybe also tell users what are we talking about in the page like "Set language options for these configuration (entity) types / objects.... " ?
There are other things that I just don't understand like why do we have here 'Taxonomy vocabularies' but not 'Node types'... Yes, I know that is a different one, just realized it now (!?)
The code works - hides language field- and the update script works. Tried for Vocabularies, Menus
One minor consistency issue though: When unchecking the box for existing sites, if some objects are already created with a different language, they keep it but hidden, I mean they keep existing with that other language but you are not able to see it anymore... that may be confusing specially if trying to create translations for those objects...
(There's some - looks unrelated - bug when trying to translate config that is not in the default language btw, I don't know if it's tracked somewhere else, it just doesn't get created...)
So about this consistency thing, maybe just to note it for now, or add a todo... At some point we'll need to add some cleanup scripts that fixe all these inconsistencies with configuration languages. There are plenty of them in other issues, we're just introducing another (small) one here, I don't think it's a big deal.
Comment #15
gábor hojtsy@jose: I don't think "Configuration objects" is a terminology we use on the UI anywhere.
core/modules/help/help_topics/core.config_overview.html.twiguses configuration entities and configuration items, mostly configuration items. Since the whole page is about configuration I did not think adding more of the word "Configuration" would disambiguate it, but we can :)I also tried to list the non-checkable items but there is a LOT of them and include a lot of internal things like base field override, etc. that we would not want to expose like that I think.
Re variance in language not being visible, we can also disable checkboxes where config exists in other languages than the default language, if that makes sense.
Re tools to reconcile problems I think what core should provide is a mass-update feature that is not tied to site default language in any way. That is what I proposed in #3337864: Introduce a dedicated "Configuration default language" different from "Site default language". I think this issue that we are on is first, because this tells Drupal to leave alone the config that has hte checkboxes checked when doing that update because the admin wanted to keep them potentially in other languages. Otherwise I think that feature would be too greedy. So that is why I proposed this first.
Re why only these support base language variance that is not the site default that is historic to some degree. I think this is related to site building elements that are most likely potentially per language. You are much less likely to have a content type that you only want to use in a specific language while having a dedicated language for a menu or a dedicated taxonomy term for content in a language (with terms only in that language) I think is more likely. So that is where this list of items comes from I think, but it could also be revisited (elsewhere).
Re translating config not in the default language, that should still be possible entirely, not sure why that would not be, if you have steps to reproduce that would be important to open issue for or find the existing one :)
Comment #16
gábor hojtsyThe problem is larger :D One can very easily create config in random languages that the admin UI is accessible in, so this will not quite ensure the rest of the config is in or will be in the future in the expected language. Need more thought :)
Comment #17
anybody@gábor hojtsy sorry for the late reply. I reviewed the code and I tried it in an existing installation. Just wanted to point out that I shouldn't be the only one reviewing it because it's a quite heavy change and I think there are persons with a lot more knowledge in the different aspects :)
Just wanted to be defensive.
Comment #18
gábor hojtsyTurns out #3337864: Introduce a dedicated "Configuration default language" different from "Site default language" is an even larger problem. I wrote that out. So I started working on that instead now and think this will be a special case we need to consider. So while that was postponed on this before, I'm flipping that and postponing this on that :)
Comment #19
anybody@gábor hojtsy following this with huge interested and just wanted to say a HUGE THANK YOU again!