Implementing multilingual support in Drupal 10
A multilingual Drupal website can serve several language communities from one content management system while preserving a single editorial workflow. Drupal 10 includes the core modules required to translate pages, menus, taxonomies, configuration and interface text, so most projects do not need a large collection of contributed modules at the beginning.
The work is easier when language decisions are made before content types and URL structures become established. A site targeting English-speaking customers in Sydney and French-speaking visitors overseas may need a different setup from a government, education or community website publishing in English, Mandarin and several Australian Aboriginal languages.
Drupal separates content translation from interface translation. A page can have translated fields, while the administration toolbar can use another language for an individual editor. This distinction is important when planning roles, translation permissions and the way visitors select a language.
The following process uses Drupal 10 core features and is suitable for a new site or an existing installation being prepared for international audiences. The examples use Australian English as the primary editorial language, with additional languages added according to the website’s market and content requirements.
| Drupal feature | What it controls | Typical use |
|---|---|---|
| Language | Available languages and language negotiation | English, German, Japanese or Mandarin |
| Interface Translation | Text supplied by Drupal and modules | Buttons, validation messages and admin labels |
| Content Translation | Translatable entities and fields | Pages, products, articles and custom blocks |
| Configuration Translation | Site settings containing text | Views, menus, field labels and contact forms |
| URL language detection | How Drupal identifies a visitor’s language | Prefixes such as /fr or separate domains |
Choose the language architecture
Begin by listing the languages the website genuinely needs rather than adding every possible language. Consider target customers, support staff, search demand, legal obligations and the availability of translators. A retailer serving Melbourne and Brisbane may need English and Mandarin, while a university may require language support for international students without translating every historical article.
Drupal usually identifies languages with URL prefixes, domains or browser preferences. A prefix structure such as /en, /fr and /zh-hans is generally the simplest to deploy and test. It keeps all languages within one domain and makes translated URLs easy to recognise. Separate domains can be appropriate for established country operations, but they introduce DNS, SSL, caching and search engine management tasks.
Decide whether regional English is a translation or a formatting requirement. Australian English often differs from US English in spelling, dates and terms such as “postcode”, “organisation” and “licence”. If the same editorial content is used across English-speaking regions, keep one English language and configure local date, number and currency formats. Create a separate English variant only when the wording, legal content or publishing process is materially different.
Install Drupal’s multilingual modules
Open Extend in the administration toolbar and enable the core modules relevant to the project. Language provides language management, Interface Translation handles Drupal and module strings, Content Translation enables translated entities, and Configuration Translation exposes translatable site settings. The Configuration Translation module depends on the other multilingual components, so Drupal may select dependencies automatically.
On a development site, the modules can also be enabled with Drush:
drush en language content_translation config_translation locale -y
drush cr
The Locale module is required for interface translation and is normally enabled along with Interface Translation in the administrative interface. After enabling the modules, clear caches and verify that the multilingual configuration pages are available under Configuration, Regional and language.
Download language interface files from the User interface translation page when Drupal offers them. Interface translations cover core administration text and many contributed modules, but quality and completeness vary. A production website should review important strings rather than assuming that a downloaded translation matches the organisation’s terminology.
Add languages and configure URLs
Go to Configuration, Regional and language, Languages, then add each language required by the site. Drupal provides a large list of language codes and regional variants. Select the correct code, set the display name, and choose the default language. For an Australian site, English is commonly the default, while local formats can be configured through Regional settings.
Next, configure language detection and selection under Language detection and selection. URL is usually the most predictable method for public websites. Set the URL prefix for each additional language and decide whether the default language should use a prefix. A consistent structure, such as /en/about and /ja/about, avoids ambiguous links and helps content editors understand which version they are editing.
Browser language detection can be useful as a secondary signal, but it should not silently redirect every visitor. A visitor in Perth may have a browser configured for Japanese while using an English keyboard and looking for local English information. A visible language switcher gives users control and reduces unexpected redirects.
Place the Language switcher block in a header, footer or mobile navigation region. Check its visibility conditions, ensure it only displays available translations when appropriate, and test it with anonymous users. If translated pages do not exist yet, the switcher should not imply that a complete version is available.
Make the content model translatable
Enable translation for content types under Configuration, Regional and language, Content language and translation. Select each entity type that requires translation, including content, custom blocks, taxonomy terms, menu links and URL aliases where applicable. The translation settings for a content type determine whether fields inherit the source value, are translatable or are excluded.
Fields containing audience-facing text should normally be translatable. This includes titles, body text, summaries, captions, link text, call-to-action labels and SEO metadata. Fields such as an internal reference number, publication status or a shared product SKU usually remain synchronised. Review every field individually; an incorrect setting can cause an editor to overwrite a translation unintentionally.
Images and documents need a policy as well. A single photograph may be suitable for all languages, but its alternative text and title can require translation. A brochure may need separate files when legal terms, prices or product specifications differ. For Australian commerce websites, ensure that translated product information still displays Australian dollars, GST wording and delivery conditions accurately.
Taxonomy terms deserve early attention because categories and filters are often visible throughout a site. Enable term translation for vocabularies used in navigation, search facets or exposed filters. Translate the term names and descriptions, then verify that views filter translated content correctly rather than mixing labels from different languages.
Translate pages and reusable content
Once content translation is enabled, an editor will see a Translate operation beside eligible nodes, taxonomy terms and custom blocks. The original version is the source language. Select Add beside another language, enter the translated fields, and save the translation. Drupal records the relationship between versions, allowing editors to move between them from the translation overview.
A translation is not merely a copied page with a different title. Review headings, links, embedded media, metadata, structured content and accessibility text. A translated page can require a different sentence length or a different image. Editors should also check that internal links lead to the corresponding language version rather than returning visitors to the English page.
Reusable components need special care. A custom block containing promotional text, a footer notice or a store locator may be configured as translatable, but its placement is shared across languages. Translate the block content while keeping its region and visibility rules consistent. If language-specific campaigns need different timing or audiences, separate blocks may be more appropriate.
Menus can be translated through Configuration Translation or the menu’s translation operations, depending on the item. Translate link titles and ensure that each link points to the correct translated route. When a page is unpublished, its translation may also be unavailable, so editorial teams should establish whether translations are released together or independently.
Localise the interface and editorial workflow
Interface Translation covers strings supplied by Drupal core and contributed modules, such as “Read more”, “Search” and validation messages. Go to Configuration, Regional and language, User interface translation to import language files or search for individual strings. Custom text introduced by modules or themes may need to be translated after the relevant code has been scanned.
Drupal uses configuration translation for many administrative and presentation settings. Views titles, exposed filter labels, field labels, menu titles, contact form labels and certain block settings can be translated from the configuration translation screens. This prevents a French visitor from seeing a translated article with an English filter or page heading around it.
A practical editorial workflow should define who creates source content, who translates it, and who reviews it. Drupal permissions can separate translation operations from publishing permissions. A small Sydney agency might have one bilingual editor, while a national organisation may need language-specific reviewers in Sydney, Melbourne and Perth.
Useful editorial checks include:
- Confirming that every required language has a responsible reviewer
- Recording terminology for product names, locations and legal phrases
- Checking translated metadata, image alternatives and URL aliases
- Agreeing whether updates require all translations to be reviewed
Handle SEO, URLs and metadata
Translated pages need language-aware metadata and discoverable relationships. Drupal can output language attributes and alternate links when content translations and URL negotiation are configured correctly. These signals help search engines understand that /en/services and /de/services are language alternatives rather than duplicate pages.
Translate page titles, meta descriptions, structured content labels and social sharing text where those fields are available. Avoid machine-translating important commercial, medical or legal copy without human review. Search behaviour differs by market, so Australian keyword research should reflect terms used locally, including “chemist”, “postcode” and “mobile”, rather than importing US terminology automatically.
URL aliases require a clear policy. Translating a path such as /about-us to /a-propos can improve usability for French readers, but it also creates redirects and maintenance work when terminology changes. If translated aliases are enabled, test them with language prefixes and ensure that old URLs redirect to the correct language, not simply to the default page.
Caching and redirects can expose the wrong language when configuration is incomplete. Confirm that reverse proxies, CDNs and browser caches vary responses correctly, especially if language negotiation uses cookies or browser preferences. Prefix-based URLs are generally easier to cache safely because the language is visible in the request path.
Test, publish and maintain translations
Test multilingual behaviour on a staging environment before importing large content collections. Use anonymous and authenticated sessions, different browsers, mobile layouts and direct links to translated URLs. Check forms, search results, pagination, Views, menus, breadcrumbs, blocks and error pages in every supported language.
A compact release checklist can include:
- Checking language prefixes, aliases and canonical links
- Testing translated forms, validation messages and emails
- Verifying permissions for translators and reviewers
- Confirming that caches show the correct language
Drupal’s translation status screens help identify source content that has changed since a translation was created. When the source is updated, mark the translation as needing review and decide whether the existing version can remain live. This is particularly important for pricing, public health information, event details and other content that changes frequently.
Keep a translation glossary in the project documentation. Record approved names for Australian states and territories, business terms, product features and accessibility language. Review contributed modules after updates because new interface strings, configuration options or compatibility changes can affect translated output.
Finally, monitor the site after launch. Search Console or equivalent tools can reveal indexing problems, while site analytics can expose language switcher abandonment or broken translated links. A multilingual Drupal installation remains reliable when language configuration, content ownership and technical testing are treated as ongoing administration rather than a once-only setup.