Running a website in several languages is less about translation and more about management: deciding what gets translated, keeping every version in sync, serving the right language to the right visitor, and doing all of it without turning content editing into a chore. Drupal handles this at the core level, which is one of the reasons it's chosen by governments, global organizations, and universities that publish in dozens of languages.

This guide walks through how multilingual management actually works in Drupal: the four core modules, the three distinct kinds of translation, how to add and manage languages, how Drupal decides which language to serve, which translation workflow fits which team, and the mistakes that most often derail a multilingual build.

Why Multilingual Lives in Drupal Core

Multilingual capability isn't a plugin bolted onto Drupal — it has been part of core since Drupal 8, and Drupal 9, 10, and 11 have continued to build on it. That's a meaningful distinction. On platforms where multilingual arrives through a third-party extension, every major update carries the risk that the translation layer and the platform fall out of step. In Drupal, the language layer ships and is maintained with core, and the system supports well over 100 languages out of the box.

The practical effect is that a Drupal site can be planned as multilingual from day one rather than retrofitted. During installation you're asked to choose a base language, and if you pick a non-English one, Drupal enables the relevant modules automatically and pulls the latest interface translations. On an existing site, the same capability is a matter of switching on a few modules rather than migrating to a different toolset.

The Four Core Multilingual Modules

Drupal's multilingual system rests on four core modules. Only the first is strictly required, but in practice most sites enable all four. You turn them on under Extend (admin/modules), in the Multilingual section.

  • Language: The foundation. It defines which languages the site offers, sets the default language, and controls how Drupal decides which language to display. Nothing else in the multilingual stack works without it.
  • Content Translation: Lets editors translate content entities — pages, articles, taxonomy terms, custom blocks, menu links, and more — into each language. Every language version is a distinct entity with its own fields, URL, and publishing state.
  • Interface Translation: Translates the built-in text that comes from Drupal, modules, and themes: buttons, form labels, error messages, and system strings. Because Drupal core already ships translated into 100+ languages, much of this is filled in the moment you add a language. (In older versions this module was called Locale, which is why some outdated tutorials use that name.)
  • Configuration Translation: Translates configuration rather than content — the site name, field labels, views, menus, block titles, and vocabularies. Without it, the scaffolding of the site stays in one language even when the content is fully translated, which quietly breaks the experience.

A useful way to hold these apart: content is what your editors write, configuration is how the site is built, and interface is the text Drupal and its modules provide. All three need translating for a site to feel genuinely localized rather than half-translated.

Three Kinds of Translation: Content, Interface, and Configuration

The single most common source of confusion in a Drupal multilingual project isn't a technical setting — it's not knowing which of the three translation systems a given piece of text belongs to. Getting this mental model right prevents hours of hunting for a translation option in the wrong place.

  • Content translation covers anything editors create: node bodies, titles, images, taxonomy terms, custom blocks. This is field-level in modern Drupal — you choose which fields on a content type are translatable, so a shared field (say, a product code) can stay identical across languages while the description is translated.
  • Interface translation covers text baked into the software. You rarely translate this by hand; it arrives with the language download and is refined at Configuration → Regional and language → User interface translation only when you want to override a specific string.
  • Configuration translation covers structural text stored in Drupal's configuration system. You translate it from the Translate tab on the relevant configuration page, or in bulk at Configuration → Regional and language → Configuration translation.

One operational detail worth knowing early: interface translations can be exported and imported as standard .po files, but configuration translations can't be moved that way with core alone — that requires a contributed module. On a project where translations are prepared outside Drupal, that difference shapes your handoff process.

Adding and Managing Languages Step by Step

Once the four modules are enabled, bringing a new language online is straightforward. The high-level flow is the same on every modern Drupal version:

  • Add the language: Go to Configuration → Region and language → Languages (admin/config/regional/language) and click Add language. Pick the language, click Add, and wait while Drupal downloads its interface translations. It then appears in the language list, ready to use.
  • Decide what's translatable: Under each content type, enable translation and choose which fields should be translatable versus shared. Do this deliberately — turning it on for the right fields now avoids painful rework later.
  • Translate content: Open any translatable entity and use its Translations tab to add a version in each language. Each version has its own URL and can be published on its own schedule.
  • Translate configuration and interface: Localize the site name, menus, and views through Configuration translation, and override any system strings through Interface translation.
  • Add a language switcher: Place the language switcher block so visitors can move between versions. Use the language name rather than a flag — a flag represents a country, not a language, and misleads users in multi-country languages.

A practical tip echoed across experienced Drupal teams: start with your main language plus one secondary language, get the translation workflow working end to end, and only then add further languages. Proving the process on two languages is far cheaper than discovering a structural problem across six.

Language Negotiation: How Drupal Decides Which Language to Serve

Language negotiation is the core feature that determines which language a visitor sees, and configuring it correctly is central to multilingual management. Drupal can detect the intended language from several signals, applied in an order you control: the URL (a path prefix like /fr or a domain), the user's account preference, the browser's language settings, the session, or a fixed default.

For most sites, URL-based detection is the right primary method — it gives every language version a distinct, shareable, indexable address and keeps behavior predictable. Negotiation can also be set separately for content and for the administration interface, which is how many teams keep the public site fully localized while leaving the admin backend in a single working language for their editors. The order of these detection methods matters: place the most specific and intentional signal (the URL) above softer ones (the browser default) so a deliberate choice always wins.

Choosing a Translation Workflow

Drupal's core translation UI is enough for a small site, but as content volume and team size grow, the workflow becomes the thing that actually determines whether a multilingual site stays current. There are three broad approaches, and the right one depends on scale and how translation is sourced.

  • Manual, in-Drupal translation: Editors and translators log in and translate directly through the native interface. Ideal for smaller sites — think a site of 20–30 pages in two languages — where volume is low and everyone works inside Drupal.
  • Export/import with translation files: Content is exported (commonly as XLIFF), sent to translators, and imported back. This suits teams that work with external linguists who don't use Drupal, and content that updates in predictable batches.
  • TMGMT (Translation Management Tool): A contributed module that turns translation into a managed process inside Drupal — creating translation jobs, assigning them to an internal team or to external providers, tracking status, and integrating with services and machine-translation engines. It's the standard choice for medium-to-large sites and high content volumes.

Two additions make these workflows more robust. Content Moderation lets you define how a translation moves from draft to review to published, so a machine-translated or in-progress version never goes live by accident. And Translation Views or the translation dashboards let you monitor coverage — what's translated, what's in progress, and what's missing — across the whole site. For most medium-to-large builds, a hybrid of TMGMT plus human review is the sweet spot: automation for speed, a person for quality on the pages that matter.

Common Multilingual Mistakes and How to Avoid Them

Most multilingual problems in Drupal trace back to a handful of avoidable decisions rather than platform limits:

  • Deciding field translatability too late: Changing which fields are translatable after translations already exist can cause data loss. Model translatable versus shared fields before large-scale translation begins.
  • Translating content but forgetting configuration: A site with fully translated articles but an untranslated menu, site name, or view feels broken. Treat configuration translation as part of the job, not an afterthought.
  • Publishing raw machine translation: Auto-translation is a fine starting point but not a finish line; unreviewed output can read poorly and undermine trust. Route it through human review for anything important.
  • Using flags for languages: A flag is a country symbol, not a language. Label the switcher with language names to avoid confusing speakers of a language shared across countries.
  • No fallback for missing translations: Decide what happens when a page has no translation — fall back to the default language or hide it — rather than leaving visitors on an empty or broken page.
  • Restructuring translation widgets carelessly: With structured content such as Paragraphs, switching to asymmetric translation after translations exist can lose data. Test structural changes on a copy first.

Multilingual management, done well, is mostly discipline: model the content once, translate all three layers, and give every language a predictable URL and a clear workflow. Getting the SEO side of that right — hreflang, URL structure, and per-market keywords — is a related but separate discipline, which we cover in our guide to multilingual SEO in Drupal, and it builds directly on the same core language layer described in our Drupal SEO guide.

Frequently Asked Questions About Multilingual Management in Drupal

Do I need a contributed module, or is core enough?

For most sites, the four core modules are enough to add languages and translate content, interface, and configuration. You reach for contributed modules when needs grow: TMGMT for managed translation workflows and vendor or machine-translation integration, a language switcher enhancement for a friendlier selector, or a configuration-translation import/export module when translations are prepared outside Drupal. Start with core, and add tooling only where a real need appears.

Should I use one multilingual site or a multisite setup?

For most organizations, a single Drupal install with language versions (for example /en and /fr) is the better choice: one codebase, shared content structures, and centralized updates. A multisite setup makes sense mainly when each market needs genuine operational separation — different teams, different content, different governance. The single-site model keeps management simpler and consolidates authority, which is why it's the default recommendation for most multilingual builds.

Can I change which fields are translatable after launch?

You can, but it carries risk once translations exist — altering a field's translatability can lead to data loss. The safe approach is to decide translatable versus shared fields during content modeling, before large-scale translation. If a change is unavoidable later, test it on a staging copy and back up first, so you can verify no existing translations are affected before applying it in production.

Latest update: 05.08.2026 16:37