Editorial illustration; the content cards are representative examples, not a screenshot of a particular Drupal site.
A multilingual Drupal site is not created by adding a language switcher to the header. The hard decision comes earlier: which content entities and fields should have translations, who maintains them, and what should a visitor see when a translation is missing?
This guide is for a site team adding a second language to an existing Drupal content model. It uses Drupal core’s Content Translation module and keeps the first rollout deliberately small. The exact menu labels can vary by Drupal version and permissions, but the planning questions remain useful.
Summary
- Install the core Language and Content Translation modules, then configure a small content type first.
- Mark only the fields that need translation; decide how titles, media, references and metadata behave.
- Test the complete visitor path, including missing translations, menus, access and search, before expanding.
Start with a content inventory
List the content types, custom blocks, taxonomy vocabularies and fields that visitors actually use. For each one, record its source language, owner, update frequency and whether a translation is required for launch.
If the inventory is unclear, pause the language rollout and revisit how to structure CMS content before building the site. Translation exposes weak field boundaries quickly; it is cheaper to fix the model before editors have populated it.
This prevents a common failure: translating the visible body while leaving the title, image alternative text, category label or call-to-action in the original language. A page can be technically translated and still feel unfinished.
Pick one representative content type for the first test. A basic Article with a title, summary, body, image and taxonomy term is enough to expose most planning decisions without turning the rollout into a site-wide migration.
1. Install the language prerequisites
Enable the core Language module and add the languages the site will support. Then enable Content Translation. Drupal’s multilingual guide describes Content Translation as the core approach for translating content entities and selected fields.
Do this in a development or staging environment first. Enabling translation changes the editing model and can affect how existing content is presented. Make a backup and record the configuration change before continuing.
2. Configure Content language and translation
Go to Configuration > Regional and language > Content language and translation. Select the entity types and bundles that should be translatable. Start with the one content type from your inventory rather than checking every box.
For each field, decide whether its value is language-independent or language-specific. The body and title are obvious candidates. A reference to a global legal policy, a reusable image or an internal identifier may not need separate values. The correct choice depends on the content model, not on a universal checklist.
If a field is not translatable, editors may see the same value in every language. That can be correct for a product code and wrong for a marketing sentence. Write the reason next to the decision.
3. Decide how translations relate to the source
The Content Translation module keeps translations associated with the same content entity. In practical terms, you are not creating a completely separate page with a second identity; you are adding language-specific values to the same piece of content.
Decide what happens when the source changes. Does the translation become “needs review”? Does an editor compare versions manually? Who owns the translation when the source author is not bilingual?
Do not promise that a translation is current merely because it exists. A visible label such as “last reviewed” or an editorial status may be more honest than silently showing an old version.
4. Configure the editing permissions
A translation workflow needs more than a language setting. Check which roles can translate, edit the source, publish a translation and change language configuration. A person who can translate content does not necessarily need permission to change site-wide language negotiation.
Test the permissions using a non-administrator account. If the Translate operation is missing, inspect the role permissions and the content type configuration before asking editors to work around the problem by creating duplicate nodes.
5. Translate one complete item
Create or choose a test article with realistic content. Use the Translate operation to add the second language, then translate the title, summary, body and any fields you marked as translatable.
Include a link, an image, a taxonomy term and a call to action in the test. A short “Hello world” page does not reveal whether referenced content or field labels remain in the source language.
Keep the translation natural for its audience. A technically correct translation can still have the wrong tone, length or call to action. Drupal stores the content relationship; it does not decide whether the editorial wording is good.
6. Test the visitor’s language path
Open the page as an anonymous visitor. Test the language switcher, direct URLs, navigation link, page title, metadata, image alternative text and any referenced content. Then repeat the test with a language that has no translation.
The missing-translation result must be deliberate. The site might fall back to the source language, hide the link, or show a clear unavailable state. Choose a behaviour that does not make visitors think an incomplete page is fully translated.
If the site uses language negotiation based on URL, browser preference or domain, test each configured method. A switcher that works only after an editor has logged in is not a successful rollout.
7. Check menus, blocks and configuration separately
Content translation is not the same as interface translation or configuration translation. A translated node can still sit inside a menu whose label is in the source language, while a custom block may have its own translation settings.
List the visible pieces around the page: header, navigation, footer, blocks, filters, taxonomy labels and form text. Decide which module or configuration path owns each translation. Avoid adding a second copy of a block just because its text is not yet translated.
8. Check search and listings
Open category pages, Views listings and site search in both languages. Verify that a translated item appears where readers expect it and that its title and summary use the active language.
Do not assume that a translated page automatically creates a perfect multilingual search experience. The site’s indexing, filtering and fallback choices still need testing. Record any limitation and decide whether it is acceptable for launch.
The practical difference between a translated page and a usable bilingual site is also covered in CMS Dua Bahasa Tanpa Keliru. Use it as a content and navigation review alongside the Drupal configuration checks here.
9. Define the publishing checklist
Give editors a short checklist for each translation:
- The source page is approved for translation.
- The translated title and summary are complete.
- Links, media and references were checked.
- The page was reviewed in the target language.
- The missing-translation behaviour is understood.
- The translation owner and review date are recorded.
This is more useful than telling editors to “translate everything”. It turns a broad quality goal into a repeatable handoff.
10. Expand only after the first item survives review
After the test article works, add another content type with a different field mix. Then test custom blocks, taxonomy and menus. Keep a configuration export or change record so the team can see what was enabled and why.
If the first rollout exposes a confusing field, revise the content model before translating hundreds of items. Multilingual work multiplies a bad decision; a small rehearsal is a chance to correct it cheaply.
Common mistakes
- Enabling translation for every entity before deciding who owns the work.
- Translating body text while leaving titles, labels or calls to action in the source language.
- Testing only as an administrator and assuming visitors see the same result.
- Creating duplicate nodes when a translation relationship would be clearer.
- Treating a missing translation as an edge case instead of a normal publishing state.
My Take
Drupal’s translation tools are most valuable when the content model is honest. If a team cannot say which fields change by language and who reviews them, adding more languages will create more uncertainty, not more reach. Start with one content type, one complete visitor path and a checklist that a second editor can follow.
Conclusion
Enable the core language modules, choose a small content type, configure fields deliberately and test the page as a visitor. Then check menus, blocks, search and missing translations before expanding. A multilingual site is ready when the translation process is repeatable, not when the language selector merely appears.