How to Set Up a Multilingual Drupal Site

Drupal's multilingual support is core, not a bolted-on module, and it's one of the more mature options in the CMS space — but "core" doesn't mean "zero configuration." Four separate core modules each handle a distinct piece of the problem, and skipping one is the most common reason a "multilingual" Drupal site is only half-translated.

Enable the Four Core Multilingual Modules

vendor/bin/drush en language content_translation config_translation locale -y

Language — the foundation: defines which languages the site supports and how the active language is determined per request.
Content Translation — lets individual content entities (nodes, taxonomy terms, blocks) have per-language versions, each independently editable.
Configuration Translation — translates configuration itself: field labels, view titles, contact form text — the parts of the site that aren't content but still need to appear in the visitor's language.
Interface Translation (locale) — translates Drupal's own built-in UI strings (button labels, form validation messages) using community-maintained translation files pulled from Drupal's central translation server.

Missing Config Translation specifically is the most common gap: content translates fine, but field labels, view headers, and system messages stay in the original language, producing a site that only looks half-finished in every non-default language.

Add Languages

Under Configuration → Regional and language → Languages, add each language the site needs. Drupal ships with predefined language definitions (including correct RTL handling for Arabic, Hebrew, etc.) for hundreds of languages, so this is usually a dropdown selection, not manual configuration.

Configure Language Detection

Under Configuration → Regional and language → Languages → Detection and selection, choose how Drupal decides which language to serve. The options can be combined and prioritized:

URL (recommended for SEO) — either a path prefix (/fr/about) or separate domains per language (fr.example.com). This is the only method search engines reliably index as genuinely distinct, separately-rankable pages per language.
Browser language — detects the visitor's browser Accept-Language header. Convenient for visitors, but should never be the only method — it produces no distinct crawlable URL per language, which is bad for SEO and breaks sharing a specific-language link.
User's account setting — a logged-in user's saved language preference, relevant mainly for authenticated-area content like a dashboard.

URL-based detection should almost always be enabled and given priority for a public-facing multilingual site; the others are reasonable supplementary fallbacks.

Make a Content Type Translatable

Translation is opt-in per content type and per field, not automatic:

Configuration → Regional and language → Content language and translation.
Check the content type (e.g. Article) to make it translatable.
For each field, choose whether it's translatable (text that differs per language, like the title and body) or shared across all translations (a field like a product's SKU or a fixed numeric value that shouldn't vary by language).

Getting this per-field distinction right matters: marking a genuinely language-specific field as "not translatable" means every translation is forced to share one value, which usually surfaces as a confusing bug reported by an editor rather than an obvious configuration error.

Translating Content

Once a content type is translatable, each node gets a "Translate" tab (alongside Edit, View) listing every enabled language and its translation status. Editors add a translation by selecting "Add" next to the target language — this creates a linked translation of the same node, not a separate, disconnected piece of content, which is what lets the language switcher block correctly link between a page and its translations.

The Language Switcher Block

Drupal core includes a ready-made "Language switcher" block (Structure → Block layout) that automatically lists available translations of the current page and links between them — place it in the header or footer region rather than building a custom one, since it already handles the URL-generation logic for whichever detection method (path prefix or domain) is configured.

hreflang Tags for SEO

Drupal automatically emits hreflang link tags in the page head for every translated version of a page when URL-based language detection is active — this is what tells search engines "these URLs are translations of each other, serve the right one per searcher's language/region" rather than treating them as unrelated or duplicate content. No extra module is needed for this on a correctly configured multilingual site; verify it by checking the rendered page source rather than assuming it's present.

Common Issues

Field labels and UI text stay in the default language — Config Translation isn't enabled, or the specific configuration item hasn't actually been translated yet (enabling the module doesn't auto-translate existing config).
A translation shows the same value as the original for a field that should differ — that field is marked "not translatable" under Content language and translation settings.
Browser-language detection serves the wrong language to search engine crawlers — browser detection has no real concept of "which language should this URL canonically be," which is exactly why URL-based detection should be the primary method for a public site, with browser detection as a secondary convenience at most.
Language switcher links to a 404 — the current node genuinely has no translation created yet for that language; the switcher links to the translation-creation form in that case rather than a broken page, so check the actual generated link before assuming it's a bug.

Building or extending a multilingual Drupal site? Get in touch — I work as a freelance Drupal developer.