Localization

Localization is the work of making a Drupal site fit a language and a region. Drupal 11 splits that work over four core modules (Language, Interface Translation, Configuration Translation and Content Translation) and two settings pages for regional formats. Each module is installed separately.

How localization works in Drupal 11

Core's Region and language section groups the settings. The Language module comes first, because the three translation modules build on it.

When people say "Drupal localization" they may mean only the interface layer. The Interface Translation module has the machine name locale, and its help points to the Drupal translation server at localize.drupal.org. That covers strings such as button labels and help text, not your pages. This page uses the wider meaning.

The base language of the software is English. The user guide says the Language module is required to use another language, and that the Update Manager module is required to download interface translations automatically. Interface translation files come from the Drupal translation server or from local files; the source is set on the Interface translation settings page.

The Language module also decides which language a visitor sees. Its Detection and selection page offers methods such as URL prefix or domain, session, user profile, browser and a selected fallback language. The first method that detects a language wins, so the order matters; the help says the selected-language method belongs last.

Regional formats are separate. The Regional settings page at /admin/config/regional/settings holds the default country, the first day of the week and the default time zone. Date formats are managed under /admin/config/regional/date-time.

Example

To add German, go to Configuration › Region and language › Languages and choose Add language. If Interface Translation is installed and the translation server is a source, the German interface strings download as well. To translate pages, open Content language, enable translation for the content type and pick which fields are translatable. Each item then gets a Translate tab or link.

Common mistakes

• Expecting one switch to translate everything. The layers are separate, and a site can have a German interface and English-only pages.
• Leaving a field untranslatable by accident. The Content Translation help says a field excluded from translation still appears on the edit form, and changes to it apply to all translations.
• Not flagging outdated translations. After editing one language, use the "Flag other translations as outdated" checkbox so editors can see which versions need work.
• Putting the selected-language method first in detection. It is a fallback, and it should be listed last.

For marketing and content teams

Plan translation per layer: who owns interface strings, who owns the site name and menus, and who owns each page. Each layer has its own permissions. Content Translation provides "Create translations", "Edit translations" and "Translate any entity" among others; Interface Translation has "Translate interface text"; Configuration Translation has "Translate configuration", so permission to translate pages and permission to translate menus are granted separately. Give each translator only the layer they own. Pages are content; menus and the site name are configuration.

Sources

• Drupal User Guide: Concept: User interface, configuration, and content translation
• Drupal core 11.4.10: Language module help text
• Drupal core 11.4.10: Interface Translation module help text
• Drupal core 11.4.10: Content Translation module help text
• Drupal core 11.4.10: Configuration Translation module help text
• Drupal core 11.4.10: system.links.menu.yml (Region and language)
• Drupal core 11.4.10: RegionalForm (Regional settings)
• Drush locale:update command