Drupal Multilingual Architecture: What Appears, What Is Possible, and How Translation Works

This document summarizes the changes that appear after enabling multilingual support in Drupal, and explains how both *foreground* (content) and *background* (configuration/UI) translation works. It also identifies the source of new interface clutter and what can be simplified later.

1. What Appears After Enabling Multilingual

Enabling multilingual introduces several new subsystems:

1.1 Language Negotiation

Drupal determines the language of each page using:

URL prefix (e.g., /en, /nl)
User preference
Browser preference
Session
Default site language

This affects how content is displayed and which translations are loaded.

1.2 Translatable Fields

Every field can be marked as:

Translatable
Not translatable

If a field is translatable, Drupal creates a separate value per language.

This causes:

Additional language selectors
Additional translation tabs
Duplicate fieldsets in the edit form

1.3 Translation Tabs on Nodes

Each node now shows:

Edit
Translate
Revisions
Language-specific edit pages (e.g., “Edit (Dutch)”)

This is normal but creates visual clutter.

1.4 Interface Translation (UI Strings)

Drupal adds:

A new “Translate Interface” screen
A new “Languages” configuration page
Automatic import of .po files for core and modules

This handles translation of system text, labels, and UI strings.

2. What Is Possible in Multilingual Drupal

Drupal supports two major translation domains:

2.1 Foreground Translation (Content Translation)

This includes:

Node titles
Body text
Field values
Media fields
Taxonomy terms (if enabled)
Custom entities (if enabled)

Each language gets its own version of the content.

2.2 Background Translation (Configuration Translation)

This includes:

Field labels
View labels
Menu items
Block titles
Interface strings
System messages

These translations are stored in configuration, not in content.

2.3 Mixed Translation (Shared vs. Per-Language Fields)

Fields can be configured as:

Translatable → separate value per language
Non-translatable → shared across all languages

Choosing correctly reduces clutter.

3. How Foreground (Content) Translation Works

Content translation creates a separate “translation set” for each node.

3.1 Workflow

1. Create the node in the default language. 2. Click “Translate”. 3. Add a translation (e.g., Dutch). 4. Only translatable fields appear for translation. 5. Non-translatable fields are shared.

3.2 Storage Model

Each translation is stored as:

A separate revision
A separate language entry
Linked to the same node ID

3.3 Editor Experience

Editors see:

A language selector
A “Translate” tab
Additional vertical tabs for language settings

4. How Background (Configuration/UI) Translation Works

Configuration translation handles:

Field labels
View labels
Block titles
Menu items
Interface strings

4.1 Where It Happens

Go to:

Configuration → Regional and Language → Configuration translation

4.2 How It Works

Drupal extracts all translatable strings from:

YAML configuration
Module-provided strings
Theme templates

You translate them once; they apply everywhere.

5. Why the Edit Form Now Looks Cluttered

Multilingual mode adds:

A “Language” vertical tab
A “Translate” tab
A language selector on the edit form
Duplicate fieldsets for translatable fields
Additional metadata fields per language
Extra tabs for each translation

This is normal but overwhelming.

6. What Can Be Simplified Later

After understanding the behavior, you can safely:

6.1 Hide Unneeded Tabs

Using:

Form modes
Permissions
hook_form_alter()

Examples:

Hide “Authoring information”
Hide “Promotion options”
Hide “URL alias”
Hide “Menu settings”

6.2 Make Only a Few Fields Translatable

This reduces 70% of the clutter.

Typical fields to translate:

Title
Body
Summary
A few descriptive fields

Fields that usually stay shared:

Images
Dates
Geolocation
Internal metadata

6.3 Simplify the Translation Workflow

Options:

Remove the “Translate” tab
Use inline translation only
Limit languages per content type

7. Summary

Enabling multilingual introduces:

New tabs
New field behaviors
New translation workflows
More UI elements

This is expected. Once the behavior is understood, the interface can be cleaned up significantly by:

Reducing translatable fields
Hiding unnecessary tabs
Simplifying the translation workflow

This results in a clean, historian-friendly interface with minimal clutter.