Elevating Multilingual Precision in Drupal 12: Configuration Language Consistency

Companies embrace multilingual functionalities to connect more deeply with global audiences. As an enterprise-level CMS, Drupal provides robust multilingual capabilities, making it simple to manage content, interface elements, and underlying configuration across multiple languages. 

Still, continuous architectural improvement is key to keeping complex platforms reliable. Work is underway to make Drupal’s configuration language handling more consistent and resolve a long-standing challenge around how languages are assigned to configuration.

In this post, we’ll explore the problem, the tools that have recently emerged to address it, and where the proposed Drupal core solution is heading. This initiative is part of the ongoing improvements being in progress for Drupal 12. 

Drupal’s multilingual architecture: built-in, not plugged-in

Drupal core initiative coordinator and top expert, Gábor Hojtsy, recently published an article and session recording along with slides explaining the need for a new configuration language model, as well as suggested solutions. As he noted at the very beginning of the session, Drupal’s multilingual capabilities are market-leading, and a primary goal of Drupal core is to maintain a consistent, rock-solid data layer. 

Indeed, when the new multilingual system arrived in Drupal, it was a total paradigm shift. Unlike most platforms that treat localization as an afterthought, requiring paid plugins or third-party hacks, Drupal built language support directly into its core architecture.

Four Drupal core modules work together to handle this data layer:

• Language (the foundation). This module lets you add and manage any language right out of the box with full right-to-left (RTL) support for languages like Arabic or Hebrew. It gives you flexible control over how the site detects a user’s language: by URL prefix, subdomains, browser settings, or user profiles.
• Interface Translation (the automation). Translating admin menus, buttons, and system messages used to be a nightmare. This module automatically fetches community-contributed translations for standard UI elements in dozens of languages. When standard text updates, your localized interface updates along with it.
• Content Translation (the storyteller). It’s the core engine for your actual content. This module allows editors to translate articles, landing pages, custom blocks, media items, and forms into multiple languages while maintaining a clean, unified editorial flow. You can translate entire pages or choose specific fields to localize, giving content teams ultimate flexibility.

• Configuration Translation (the fine print). It’s the detail-oriented module that ensures no text gets left behind. It seamlessly localizes all backend setups (site names, field labels, view titles, taxonomy categories, and email templates) so the user experience remains consistent across every touchpoint.

   

What needs improvement: configuration language inconsistencies

Before describing the challenge, Gábor Hojtsy highlighted a core design principle of Drupal: every piece of content and configuration has built-in language tracking (though site builders can opt out if a piece of config doesn’t require it).

However, Gábor pointed out a crucial difference in how language information is handled across the platform:

• For content, language is visible and prominent: content editors can easily see it in listings, edit forms, and translate tabs.
• For configuration, the language information is not displayed almost anywhere. Configuration generally works behind the scenes. 

Only three configuration entity types (menus, date formats, and taxonomy vocabularies) expose an explicit language selector when they are created. Drupal Views are created in the site’s default language, with a less visible language setting that can be changed only after the view has been built.

For most other configuration entities, including content types, media types, fields, image styles, text formats, and roles, there is no visible language indicator or selector for administrators.

This becomes a problem on multilingual sites because, when certain configuration is created or saved, it uses the language of the current Drupal request rather than the site’s default language. For example, if an administrator is viewing the admin screen in French, they can unknowingly cause configuration to be saved with ‘langcode: fr’, even when the site’s default language is English. 

For most configuration entity types, there is no warning that this has happened and no straightforward interface for changing the language afterwards. This isn’t an administrator mistake but rather a consequence of how Drupal currently determines configuration language.

If a team regularly works in localized admin interfaces while building content types, media types, fields, or other configuration, the site’s configuration can gradually end up with a mixture of base languages, what Gábor describes as: 

“You get all kinds of random configuration languages on your multilingual website.”

Furthermore, other parts of Drupal’s multilingual system (including Interface Translation, Configuration Translation, Configuration Actions), and module and theme installation, introduce additional factors that can affect the language assigned to configuration. Gábor covers these nuances in more detail in his full session. 

He encountered these issues while diagnosing problems with Recipes on Drupal CMS sites using languages other than the default, as well as with Drupal Canvas working with inconsistent configuration. His investigation revealed that these were not isolated bugs but part of a broader set of long-standing issues around configuration language. 

The solution: from contrib experiments to Drupal core architecture

To tackle configuration inconsistencies, Gábor Hojtsy released two contributed modules that give administrators visibility and control over configuration language:

1. Language Audit is a read-only diagnostic tool. It shows the languages currently assigned to configuration and lets site builders take snapshots to track how configuration languages change after actions such as installing a module, applying a recipe, or making manual changes.
2. Configuration Language Lock provides an enforcement mechanism for sites that need configuration to consistently use one language. It applies six safeguards across configuration entity saves, module and theme installation, Recipes, language selectors, and existing configuration, so configuration is normalized to the chosen language regardless of the request language or its previous language.

The contributed modules can be used and tested today while also making it possible to diagnose the problem and experiment with different approaches. Gábor cautions that both modules are new and not yet widely proven, but welcomes feedback on them.

“However, Drupal core solutions are really what’s needed to truly resolve the problems,” he wrote. There is ongoing work toward handling this consistently in Drupal core itself, and here is where this Drupal core issue comes in. 

In his August article, Gábor described a merge request for this Drupal core issue where he had proposed to introduce a global configuration language. That initial approach introduced a separate configuration default language, distinct from the site’s default language. However, it ran into problems because Drupal would still need to handle what happens when the site’s default language changes.

The current proposal takes a different approach. The site’s existing default language becomes the single “source of truth” for new and unlabelled configuration. A new language-resolution mechanism (‘ConfigEvents::RESOLVE_LANGCODE’) gives Drupal a consistent way to determine the language for configuration that doesn’t already have one, using the site’s default language by default while allowing other modules to apply their own language rules when needed.

The mechanism is used when simple configuration becomes translatable and when configuration is installed with an extension. Recipe-shipped configuration goes through the same installation process. Explicitly specified non-English configuration is left alone, while missing or explicitly English language codes can be resolved through the new mechanism.

The proposal also addresses changes to the site’s default language. It gives Drupal a consistent rule for assigning a language to new configuration while also defining what happens to existing configuration when the site’s default language changes.

Final thoughts

This improvement to Drupal’s multilingual capabilities is still in progress, so some details may evolve as the Drupal core work continues. The direction, however, is clear: Drupal is giving configuration language the same careful attention that multilingual sites need, with the goal of making language handling more consistent, reliable, and predictable.