Content translation

The core module that adds a Translate tab to pages, terms, blocks and other content entities, where editors create and manage their language versions.

Aprender DrupalGlossário do Drupal Last updated

Content Translation is a core Drupal module that keeps several language versions inside one content item. A page, a taxonomy term or a content block keeps a single ID, and each language is a translation of that same item. Every translation holds its own values for the fields that you mark as translatable.

How Content Translation works in Drupal 11

The module sits in the Multilingual package and depends on the core Language module. Language adds the languages themselves; Content Translation adds translated versions of entities. The Drupal User Guide separates it from the other two layers: Interface Translation for built-in text and Configuration Translation for editable text such as the site name. See localization for how the layers fit together.

Translation is switched on in two steps. First, at /admin/config/regional/content-language, you tick each entity type and each sub-type, such as a content type, that should be translatable. That page requires the "administer languages" permission, its translation checkboxes appear only with "Administer translation settings", and the site needs at least two languages. Second, on the same page, you tick the fields that may differ per language. The User Guide leaves metadata such as "Authored by" unticked and ticks Title, Published, Body and URL alias.

After that, each translatable item gets a Translate tab or link. For a node the page is the canonical path plus /translations, so /node/5/translations. It lists every language and lets an editor add, edit or delete a translation. When you add one, the form shows the source text. If another translation already exists, you can pick it as the source instead of the original.

Each translation also carries its own bookkeeping, defined as base fields by the module: the source language, an outdated flag, and, where the entity type does not already have them, an author, a published status and created and changed times.

Example

The User Guide translates a home page into Spanish. Open Manage › Content, find the page, open the dropdown in its row and choose Translate. In the Spanish row click Add. Enter a translated title, body and URL alias, such as pagina-principal, and click Save (this translation). The guide then visits the home page to check the Spanish version.

Common mistakes

  • Marking too many fields translatable. A field you leave unticked is shared. Editing it in any language changes it everywhere, which suits an image or a date but not a headline.
  • Forgetting menu links. Custom menu links are content entities, so they need their own tick on the settings page; the User Guide ticks Custom menu link next to Content and Content block. The name of the menu itself is configuration.
  • Relying on the outdated flag with moderated content. In 11.4.10 the edit form shows "Flag other translations as outdated" only when pending revision support is off. For content under content moderation, the form says translations cannot be flagged as outdated. The code marks this logic as internal and likely to change, so recheck after a minor update.
  • Giving translators too little or too much. Translating needs the translation permissions in addition to edit access, while the settings page needs "administer languages" and "Administer translation settings".

For marketing and content teams

Decide per content type before launch which fields are translated and which are shared, because that choice shapes every editing screen. Plan who writes each language and who gets the translate permissions. When the English text changes in a way that matters, flag the other translations as outdated where the form allows it, so translators see what needs work. If Published is a translatable field, as in the User Guide's setup, each translation has its own published status, so a language can go live later than the original.

Sources

Questions about Content translation

No. It covers content entities such as content items, comments, content blocks, custom menu links, taxonomy terms and users. Built-in interface text needs the Interface Translation module, and configuration text such as the site name or a menu's name needs Configuration Translation. Each layer is its own core module.

All translations share its value, so a change made in any language applies to every translation. The field shows on translation forms unless the setting Hide non translatable fields on translation forms is on; for moderated content that setting is forced on, and shared fields are edited on the original language form. Use this for values that never differ by language.

Roles need translation permissions on top of normal editing rights. The module defines Create translations, Edit translations, Delete translations, Translate any entity, Manage translations for any entity that the user can edit, and Administer translation settings, plus a translate permission for each content type or other bundle with translation enabled.

Yes. It ships with Drupal core 11.4.10, and its info file does not mark it experimental. Any non-English language still needs the core Language module as well.

Cite this definition

"Content translation." DXPR Drupal glossary, https://dxpr.com/hc/documentation/learn-drupal/drupal-glossary/content-translation. Last updated October 26, 2026.

Related terms

All Drupal terms from A to Z