Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Drupal separates interface, content and configuration translation — enable all of them.
- Set translatability per field so editors are not duplicating shared values.
- Make the language switcher link to the translated equivalent, not the homepage.
- Decide who owns each language and what happens when source content changes.
Three layers of translation
Drupal separates translation into interface, content and configuration. Interface translation covers module and theme strings. Content translation covers nodes, media and taxonomy terms. Configuration translation covers things like field labels, views titles and menu items.
Teams routinely enable the first two and forget the third, then discover that a menu or a form label is stuck in the source language. Enable all four core multilingual modules at the start unless you have a specific reason not to.
Decide what actually gets translated
Not every field needs translating. A product code, a price or an image may be shared across languages while the description is translated. Drupal lets you set translatability per field, and doing that deliberately saves editors a great deal of duplicated work.
- Shared: identifiers, numeric values, media that carries no text.
- Translated: titles, body copy, metadata, alt text.
- Language-specific: content that only exists in one market.
URL strategy
Path prefixes (/fr/, /de/) are the common default and work well for most sites. Domain-based language negotiation suits organisations with genuinely separate market presences and separate teams.
Whichever you choose, set hreflang correctly and make sure the language switcher links to the translated equivalent of the current page rather than dumping users on the homepage — which is the single most common multilingual defect we see.
Workflow and ownership
Translation is an editorial process, not a technical one. Decide who owns each language, whether translations must be reviewed before publishing, and what happens when the source content changes after translation.
Drupal's content moderation can model this, with separate workflow states per language. Without that, translated content silently drifts out of date and nobody notices until a customer does.
Search visibility in several languages
A multilingual site that is technically correct can still be invisible in the markets it was built for. The mechanics matter: each language version needs its own indexable URL, correct hreflang annotations declaring the relationship between versions, and a self-referencing annotation on each page.
Translate the metadata as well as the content. Page titles and meta descriptions carried over in the source language are a common and costly oversight, as is leaving image alt text untranslated.
Finally, remember that translation is not localisation. Currency, date formats, address formats, telephone conventions and the examples used in copy all carry market assumptions. A page that reads as translated rather than written is less persuasive even when it is perfectly accurate.
Frequently asked questions
Path prefixes are simpler to operate and are the right default for most organisations. Separate domains suit businesses with genuinely distinct market presences, separate teams and separate brand treatments and they cost more to run.
Machine translation is a reasonable starting point for high-volume, low-stakes content, provided a native speaker reviews it before publication. For commercial pages that carry your brand, unreviewed machine output tends to read poorly in ways that damage credibility.
Without a workflow, the translations silently go stale. Drupal's content moderation can hold separate states per language so that an edit to the source flags the translations for review. Deciding this at the start avoids a slow accumulation of inconsistency.
