Contao Multilingual Strategy: Fallback vs. Full Translation

Why the Decision Matters

When you’re building a Contao site that speaks more than one language, you’re faced with a classic engineering trade‑off: duplicate every page for every locale, or rely on Contao’s language fallback feature and only translate what you really need. The choice has a direct impact on maintenance effort, content consistency, and user experience.

How Contao Stores Multilingual Content

Page Records

In Contao, each page is a row in tl_page. The language column tells Contao which locale the record belongs to. Pages are linked by the pid (parent ID) field, so a page that exists in English and French will share the same pid but have distinct id values. This gives editors independent URLs (e.g. /en/about vs. /fr/a-propos) and separate meta data per language.

Content Elements

Content pieces live in tl_content. The same language column applies, and the pid column points back to the page record. Every element is stored per language, so you can edit the German copy of a headline without touching the English one. When you enable translation mode, Contao copies the element structure so you can start editing right away.

Enabling Language Fallback

Fallback is a global setting that tells Contao to render the default‑language content when a translation is missing. It’s useful for structural elements that rarely change (menus, breadcrumbs, etc.).

# localconfig.php – add this line to enable fallback for all sites
$GLOBALS['TL_LANG']['FALLBACK'] = true;

Alternatively, you can toggle the option in the backend: Settings > Languages, check Use language fallback, and choose the default language. The setting is applied site‑wide.

What Fallback Does

• When a page is requested in a language that lacks a record, Contao looks for a page with the same pid in the default language.
• If the page exists, Contao renders it while keeping the requested language in the URL.
• For each content element, Contao checks the language field; if it’s missing, it falls back to the default language element.

Practical Example: A Test Page with Fallback

1. Create the default‑language page:
   • In the page tree, add a new page under /en called “Contact”.
   • Set the language to en and add a headline and a text element.
2. Enable fallback:
   • Go to Settings > Languages, enable Use language fallback, and set en as the default.
3. Request the page in a secondary language (e.g. /fr/contact):
   • Because there’s no French page, Contao serves the English page but keeps the URL in French.
   • The headline and text appear, even though no French translation exists.
4. Verify the fallback in the database:
   • Query tl_page:

     SELECT id, title, language FROM tl_page WHERE pid = (SELECT pid FROM tl_page WHERE title = 'Contact' AND language = 'en') AND language = 'fr';
     

   • The result will be empty, confirming that no French record exists.
5. Check the frontend:
   • Open the page in a browser, view source, and confirm that the <meta> tags and content come from the English record.

Trade‑Offs of Using Fallback

Pros

• Reduced duplication: You only need to create pages and elements for the default language.
• Faster updates: When a structural change is made (e.g., a new menu item), you don’t have to touch every language.
• Consistency: The layout remains identical across locales, reducing the risk of broken designs.

Cons

• Unintended exposure: Visitors who expect a translated page may see default‑language text, which can hurt usability and SEO.
• Manual media handling: Images and file references are not translated automatically; you must assign them per language.
• Limited control: You cannot customize fallback on a per‑field basis without additional configuration.

When to Duplicate vs. When to Fallback

A common pattern is to fallback for structural elements (menus, breadcrumbs, sidebars) and translate marketing copy (headlines, body text, calls to action). This keeps the site maintainable while still providing a fully localized experience where it matters.

If your site has high‑volume, frequently updated text (e.g., a blog or news section), it’s safer to create full language records. For static sites with only a handful of pages, fallback can dramatically cut down on maintenance.

Actionable Checklist

• Check Settings > Languages to confirm the default language and whether fallback is enabled.
• Verify that each page has a language record in tl_page for the languages you intend to support.
• Use the Translate button in the backend to duplicate page structures into new languages.
• After enabling fallback, test a secondary‑language URL that has no page record and confirm that the default content is displayed.
• Audit media files: ensure each tl_content element that references a file has the same file assigned in every language you wish to support.
• Monitor user analytics: if a significant portion of visitors see default‑language text, consider creating full language records for those pages.

By following this workflow, you can make an informed decision about when to duplicate and when to rely on Contao’s fallback, balancing maintenance effort with a polished multilingual experience.