Drupal multilingual site setup

Drupal chooses the language for each request by running language negotiation, an ordered list of detection methods set in the site configuration. The usual inputs are the language prefix or domain in the URL, the language saved on a signed-in user's account, the session, the browser's Accept-Language header and the site default language. Drupal checks the enabled methods in the order shown on the language detection settings page and uses the first one that returns a language enabled on the site. Because the order is configuration, a change made in the admin interface can move visitors to a different language without any code change. Confirm which methods your build enables and in what order before launch.

The user preference step matters most for editors and members who sign in. A saved language follows the person across devices, while anonymous visitors depend on the URL, the session or the browser. Browser detection is the least predictable input because it reflects a device setting the site cannot see, and it can select a language the organization would not choose to show first. Decide whether browser detection is needed at all. If it is, decide whether it should only drive the first redirect on the homepage or apply to every page. Write this decision down, since editors and support staff will otherwise assume the answer.

Language fallback covers the case where a translation does not exist for the chosen language. For content, Drupal follows the fallback chain configured for the site, which can end at the default language. How a missing node appears depends on the translation settings for its content type, so a visitor may see the source text in another language or see nothing at all. Interface strings follow a separate path: when no translation exists for a string, the English source text is shown. Ask the content owners which behavior they want for each content type, then test it with a node that has only one translation.

The chosen language changes what the cache stores. Drupal's caches vary rendered output by context, including the interface language, so a page built for one language should not be served to another. Reverse proxies and CDNs sit outside this logic and only know what the cache key contains. If language is chosen from a cookie, the session or the Accept-Language header, the proxy must include that input in its cache key or it may return an English page to a visitor who asked for another language. If language comes only from the URL path, each language already has its own cache entry, but the proxy configuration still needs review. Confirm this behavior with your proxy vendor and your Drupal version.

Test the negotiation order in your own environment after the build and after every change to detection, caching or translation settings. A simple matrix works well: an anonymous visitor with each supported browser language, a signed-in user with a saved preference, each URL prefix or domain, and a node with a missing translation. Record which language each request receives, and repeat the checks through the reverse proxy or CDN, not only directly against the web server. Testing this way shows both the negotiation result and whether the cache returns the correct version, which is the failure most likely to reach visitors unnoticed.

Verification before launch should test language behavior across every part of the site, and each test should record the language, the user role and the content state involved. Start with language switching on each template type: the front page, content nodes, taxonomy term pages, Views listings, user profiles and any Layout Builder pages. For each one, confirm that the language switcher block lands on the translation of the same entity and that the path alias, page title and browser language all match. Repeat the check for menus, blocks, forms and the site header and footer, since these are often built once in the default language and missed later.

Next, test translated and untranslated content side by side. For every content type, create or select one item with a full translation and one with a partial or missing translation, then confirm that the fallback behavior matches the design your team signed off on, whether that is a fallback language, a notice or a designed not-found response. Check that the 403 and 404 error pages render in the visitor's language. Run search queries in each language and confirm that results link to the correct translation. Trigger account and content moderation emails for users with different preferred languages, and test redirects after a path change in each language.

Cache checks need their own pass. Clear caches, then load the same pages in each language as a logged-out visitor and as a logged-in user with a different role, in both orders. The goal is to catch a page cached in one language or for one role being served to another. If a reverse proxy, CDN or external cache sits in front of Drupal, confirm that it varies on the language and session context Drupal sends. After editing a translation, confirm the change appears for the right language without a manual flush. Use the team's own accessibility and SEO tooling to confirm the language attribute on the html element and the alternate links between translations, and record any gaps as defects.

Role-based testing should cover at least four viewpoints: an anonymous visitor, a translator, an editor and an administrator. Translators should reach only the translation tasks and content they are assigned, and they should not be able to publish. Editors should publish translations within the workflow you designed. Anonymous visitors should never see an unpublished translation, whether they reach it by direct URL, through search, a View, a feed or a related-content block. Build an explicit check for this: create a draft translation in a moderated workflow, then confirm it stays hidden from every anonymous path until it is published. Ask any partner to include this matrix in the written test scope.

After launch, translations usually go stale through neglect, so monitoring should focus on age and backlog. Track how long each translated node, block and menu item has been out of step with its source, using the change timestamps that Content Translation keeps for each language. Watch the translation queue for jobs that sit unassigned or stall, and review failed jobs in the log of whichever translation management tool your team uses. Agree a threshold for each content type with your editors, such as the number of days a page may stay untranslated before it is flagged. Confirm which report or view will show these items, because the reporting you need often depends on contributed modules and on how your workflow is configured.

Back up the database and the configuration together so that a restore returns a consistent state. Translated content sits in the same entity tables as source content, with separate rows for each language, and interface strings are stored in the locale tables that Interface Translation populates. Configuration Translation stores overrides for translated configuration, so those overrides must be included in your configuration exports. Keep the exports in version control alongside any translation files your team imports or exports. Test a restore on a staging copy and confirm that a page in each language comes back intact. Ask your hosting provider whether database and files backups are taken at the same point in time, and confirm the retention period your editors need for rollback.

Monthly bugfix releases arrive on the first Wednesday of each month, and security releases arrive on the third Wednesday, according to the Drupal core release schedule. Either type of update can change translated interface strings. A core or contributed update may rename, add or remove source strings, which leaves existing translations unmatched, and the affected text then displays in the source language until someone translates it. Read the change notes for each release to see which strings changed, and check how your translation status reports show them. Apply updates to staging first, export configuration before and after, and plan a short translation pass for any module that changed its interface text.

After each upgrade, retest every language on staging before the change reaches production. Build a short checklist that covers the home page, a long form, search results, error pages, the language switcher and a sample of content in each language. Check the URL pattern, the hreflang output and the fallback behavior for each page. Include forms and outgoing emails, because they carry interface strings too. Record the results in a table so that the next release can be compared with the last one. Assign the checklist to a named person and agree in advance who signs off if a language fails.

Keep four documents current and stored with the project repository. The language matrix lists each language, its code, its content owner, its review process and the content types it covers. The URL and domain map records the URL pattern or domain for each language, the default language and the redirects in place. The translator roles document lists who translates, who reviews, who publishes and who may access the translation interface, along with the permissions each role needs. The fallback rules state which language a missing translation falls back to, for each content type and for interface strings, so that editors and support staff can answer questions without reading the configuration. Review all four documents after every major change to languages or modules.