We build multilingual sites for clients across North America, the EU, Moldova, and Ukraine. Drupal is consistently the right tool for this work — it has first-class multilingual support baked into core, whereas other platforms treat it as an afterthought. But there's a difference between Drupal's multilingual capabilities and a well-architected multilingual Drupal site. Here's what we've learned.
The four Drupal multilingual modules
Drupal's multilingual support is distributed across four core modules that work together:
- Language — adds language support to the site and manages the language list
- Interface Translation — translates Drupal's UI strings
- Content Translation — enables translation of content entities (nodes, blocks, taxonomy terms)
- Configuration Translation — translates site configuration (field labels, views, metatag defaults)
Enable all four. Projects that enable only Content Translation and skip Configuration Translation end up with partially translated sites that confuse editors — field labels remain in the original language even when the content is translated.
Content model decisions that matter
The most important architectural decision is whether content should be translated or whether separate content should exist per language. These are different things.
Translation means: one piece of content, multiple language variants. The content is fundamentally the same — same topic, same images (usually), different language. This is what Drupal's Content Translation module handles.
Separate content means: different content for different markets that happens to be in different languages. A landing page for Canadian clients and a landing page for French clients aren't translations of each other — they're different pages for different audiences. Use separate nodes for this, potentially with Domain Access to control which content appears where.
Conflating these two approaches creates maintenance nightmares. Get clear on which model applies to each content type before building.
URL strategy
The three standard approaches: subdirectories (site.com/fr/...), subdomains (fr.site.com), and separate domains (site.fr). For most projects, subdirectories are the right choice — they're the easiest to implement in Drupal, maintain the domain authority of a single domain, and are clearly the SEO-preferred approach per Google's guidelines.
Drupal's Language module handles subdirectory routing out of the box. Set it in the Language Detection and Selection configuration and it works correctly with Pathauto, metatags, and hreflang tags.
Editor workflow: the biggest overlooked problem
Content translation is only valuable if editors use it correctly. Too many multilingual Drupal sites degrade into partially translated content because the editorial workflow doesn't make translation obvious and required.
Our standard setup: configure Content Moderation to require all enabled languages to be in a Published state before a node can be marked as fully published. This means a French node can't be published until the English translation is also published. It adds friction, but it prevents the silent degradation of multilingual parity.
Performance considerations
Each language variant needs its own cache entries. This multiplies your cache storage requirements by the number of languages. For a five-language site with 10,000 pages, you're looking at 50,000 cached page variants. Redis or Memcached is essentially required — the database cache backend doesn't scale to this volume effectively.
Also: make sure your CDN is configured to vary on the Accept-Language header or the language URL prefix. Otherwise users will be served the wrong language variant from cache.
The hreflang tags
Hreflang tells search engines about language relationships between URLs. Drupal's Metatag module with the multilingual configuration generates these automatically and correctly. Don't implement them manually — the corner cases around x-default values and self-referential tags are easy to get wrong.
