The hardest decision in a multi-language CMS project isn't which platform. It's how the collections, locales, and editorial workflows interact. Get that wrong and you're locked into years of translation debt, duplicated content graphs, and a redirect table nobody wants to own.
During the LumApps consolidation I managed content ops across 5 languages (English, French, German, Italian, Spanish), 36 CMS collections, and 1,539 published items. The platform was Webflow Enterprise, but the same decisions apply to Sanity, Contentful, WordPress with WPML, or any other stack. Here's the decision tree I used.
Three patterns, three different tradeoffs
Every multi-language CMS problem boils down to one of three structural patterns. Pick wrong and the pain shows up months later.
Pattern 1: Single collection, localized fields
One collection per content type. Each document has a field for every locale. A Product document has title.en, title.fr, title.de, and so on. Works well when translations are tightly coupled to the source (product specs, UI strings, microcopy). Breaks down when one locale is materially different from the others — if the French team wants a product page with an extra testimonials section the English version doesn't have, you're now hacking conditional rendering into a schema that assumed parallel structure.
Pattern 2: Per-locale collections
One collection per content type per language: Product-en, Product-fr, Product-de. Documents are fully independent. Works well when locales have editorial autonomy — the German team can publish a blog post that doesn't exist in English without waiting for translation. Breaks down when you need to enforce consistency. If product specs must match across all 5 languages, you've traded one pain for another: now someone has to manually sync.
Pattern 3: Reference-based (source of truth + translations)
One canonical collection (usually English) and a Translation collection that references it. Each translation row points back to its source and stores only the translated fields. Works well when you have a clear authoritative locale and translations are additive. Lets you track translation status per source change, show 'translations needed' dashboards, and roll back cleanly. Breaks down when locales are peers. If French isn't 'a translation of English' but 'the thing French users see,' the reference model creates an artificial hierarchy.
When each pattern fails: real examples
On the Beekeeper and Teach on Mars merge into LumApps, we hit all three failure modes within one week of planning.
- Pattern 1 failed on case studies. Each language wanted to feature different customer stories — German case studies weren't relevant to French prospects, and the French marketing team had commissioned local content the English team would never have written.
- Pattern 2 failed on the product catalog. Product names and specs had to match across all 5 languages for compliance reasons. Per-locale collections would have required a sync tool nobody wanted to build.
- Pattern 3 failed on blog posts. English wasn't the source of truth — each region ran its own editorial calendar. Treating one language as canonical would have required dozens of orphan translations that had no source parent.
The answer wasn't picking one pattern. It was picking the right pattern per content type. Product catalog → Pattern 1. Case studies → Pattern 2. Blog posts → Pattern 2. Help docs → Pattern 3 (with English as source). Five content types, three different structural patterns. That decision takes longer than 'just pick Webflow and figure it out later.' It also saves you from the six-month refactor when the business requirements surface.
Editorial workflow implications
The structural pattern determines the workflow, not the other way around. If you pick Pattern 2 and then try to impose a centralized 'translation queue' workflow, editors route around it because their work is already independent. If you pick Pattern 3 and let each locale publish autonomously, translation references go stale within months.
Three workflow questions to answer before writing any schema:
- Who publishes? If each locale has its own editorial team with publish authority, you need Pattern 2 or 3. If a central team publishes all languages, Pattern 1 is viable.
- Who translates? If it's a shared translation team or an external vendor, the translation job needs a status field. That's easier in Pattern 3 than Pattern 1.
- Who approves? If legal or compliance needs to approve content per locale, build that into the schema as a status field — and make sure it isn't global.
The redirect map is not just hreflang
The SEO advice for multi-language sites starts and ends with hreflang. That's necessary but not sufficient. A real multi-language redirect map handles users who landed on the wrong locale via search, legacy URLs from pre-consolidation properties, country-level redirects for users in regions where you don't have a localized site, and canonical redirects when one locale is deprecated.
On LumApps the redirect map was thousands of rows across 5 locales. Hreflang was set correctly from day one, but users still ended up on the wrong pages — because hreflang is a hint to search engines, not a redirect for users. The two are different problems, and the scoring model I described in How I Scored 436 Pages for a Domain Migration has to run per locale, not once across all locales combined.
The content debt you can't avoid
One statistic stuck with me from the LumApps audit: 153 unique meta descriptions, hand-written across 5 languages, for the highest-traffic pages. I wrote them by hand, one at a time, because every auto-translation service I tried produced meta descriptions that violated local idiom in ways Google penalized.
Content debt is the dirty secret of multi-language CMS. You can architect the schema perfectly. You still have to write the content, keep it in sync, and update it when the source changes. Most platforms sell you a schema and hand-wave the workflow. The workflow is the whole job.
The operations guide
The deliverable that actually moves the needle on a multi-language project isn't the schema or the redirect map. It's a written operations guide that answers: who owns each collection per language, what's the translation SLA, what happens when a locale-specific edit conflicts with a source change, and how does a new content type get added to the multi-language workflow. Without this guide, the schema decay starts on day 31. With it, the team has a reference to settle arguments and onboard new editors.
The shortcut
If you're scoping a multi-language CMS project right now, don't start with platform selection. Start with the content type inventory. For each type, answer the three workflow questions (publish, translate, approve), pick the structural pattern that matches, and build the schema from those decisions. The platforms are all good enough. The architecture is what decides whether you ship in 8 weeks or 8 months.
If you want someone to run this inventory with you, that's the Architecture Review package — one week, a written decision record, done. For the upstream audit that finds what's actually in your stack today, see Auditing 3,489 Pages of MarTech Infrastructure with Playwright.