Add a second language to your requirements and the shortlist collapses. Not because platforms lack a localisation feature, but because they mean different things by it, and the differences are structural rather than cosmetic.
Localisation is a data model question wearing a feature’s clothes. A platform that supports two languages by duplicating everything and a platform that supports two languages by treating them as variants of one item are not two implementations of the same capability. They are different products, and the difference shows up in every editorial decision you make afterward.
Ask which model, not whether it is supported
“Does it support multiple languages” gets a yes from everybody. The useful question is which of these four it implements.
1. Separate sites, or separate spaces. Each language is its own instance, with its own content, its own users, its own settings. Simple to reason about, and the two versions have no structural relationship at all. Nothing tells you the English article and the German one are the same article, and nothing keeps them in step.
2. Field-level localisation. One content item, with individual fields carrying a value per locale. The item is one object; the title exists in several languages. Relationships and structure are shared automatically.
3. Entry-level localisation. One content item per language, linked as translations of each other. The link is real, so you can find the counterpart, but the two entries are separate objects that can drift apart in structure.
4. Nothing, plus a plugin. Localisation as an extension rather than a core capability. Works, and inherits every risk of depending on an extension.
None of these is correct in general and all four ship in real products. What matters is which one matches how your team actually works, and that is the next question.
Which model fits which team
The deciding factor is whether your other languages are translations or independent editions.
If they are translations, and the German page is meant to be the English page in German, field-level localisation is usually right. One item, one structure, one relationship graph, several sets of words. You can see what is missing at a glance because the untranslated fields are empty rather than absent.
If they are independent editions, and the German site publishes different things for a different market, separate sites are usually right. The structural link is not just unnecessary, it is an obstacle.
Most teams are somewhere in between, and that is the honest and awkward answer. Some content is a translation, some is market-specific, and the platform has to tolerate both. Entry-level localisation is often the compromise, with the cost that nothing enforces consistency.
Establish which you are before you evaluate anything. It is the same principle this site’s pillar applies to the whole decision: how to choose a CMS without reading 165 vendor pages starts from who publishes and how, rather than from features, and the localisation model is a publishing question.
The questions that separate real support from a checkbox
Send these to a vendor, or answer them in a trial. Each one exposes a different structural limitation.
Can a field be locale-specific while the item is shared? This is the field-level test.
Can I publish one locale while another is still a draft? Enormously important and frequently not possible. If publishing is all-or-nothing across locales, your slowest language sets the pace of every release.
Can locales have different URL structures? And who controls them. URL structure across locales is a discipline of its own, and this site does not cover redirect and hreflang handling: that belongs elsewhere, and the point here is only that the CMS’s URL model has to allow whatever that discipline requires.
Can I see what is untranslated? Without opening every item. Without this, a growing site has an unknown amount of missing translation and no way to find it.
What happens when the source changes? Does the translated version get flagged as stale, or does it silently keep serving an outdated version? This is the single most consequential difference between implementations and the least discussed.
Can a translator have access to only their locale? Permissions per locale, rather than per site.
Is the content model shared or duplicated? If duplicated, adding a field is a job you now do once per locale, forever.
The cost question, which is separate
Locales are frequently a pricing dimension rather than a free capability, and they are frequently a multiplier rather than an addition. Two languages can move you a tier for reasons that have nothing to do with your volume.
This page publishes no numbers, and the reason is the same one that governs reading a CMS pricing page without being misled: vendor pricing moves, and a stale figure on a pricing question is worse than no figure. What is stable is the mechanism, and the mechanism here is that locales are a metered unit on many platforms and a tier trigger on some. Ask which, in writing, before you commit.
The editorial cost, which is larger
The platform question is the smaller half. The workflow question is the larger one and it is usually discovered later.
Every article now has a lifecycle per language. Someone has to notice when the source changes, decide whether the change is worth re-translating, get it translated, get it reviewed by someone who reads that language, and publish it. That is a multiplied workflow, not a duplicated one, because the stages interlock.
Two specific things that break:
Review capacity. If nobody on the team reads a language, nothing published in it can be checked, and the honest options are to hire that capacity, to accept unreviewed publishing, or not to publish in that language.
Machine translation as a stage. It is a legitimate stage in a workflow and it requires a human review step after it. Whether a given translated draft is good enough is not a question this site answers, and it should not be decided by whoever operates the platform. That is a content-quality question with its own owner. What belongs here is the process point: if your workflow has a machine translation stage and no review stage, you have a publishing process with a hole in it.
The general shape of that problem, that adding stages multiplies handoffs rather than adding them, is the finding behind this site’s work on team workflow, and it applies with particular force once every article exists several times.
Multi-site, which is a different requirement
Several brands, several regions, or several properties, which may or may not also be several languages.
The questions are related but not the same:
- Shared content model, or one per site?
- Can content be reused across sites, or does each hold its own copy?
- Shared assets and shared users?
- Is a site a metered unit?
A platform that handles languages beautifully can handle multiple sites badly, and the reverse. If you need both, test both, separately.
Test it before you commit
An afternoon, with a real second language rather than placeholder text.
Create one item in two locales. Note whether it is one object or two.
Publish one and leave the other in draft. See whether that is allowed.
Change the source after both are published. Watch what happens to the translated one. This is the test that reveals the most.
Add a field to the content type. Once, or once per locale?
Find everything untranslated. In one view, or by opening items?
Export the whole thing and open the file. Are both locales in it, and is the relationship between them expressed in a way another system could read? Exporting your content from a CMS covers what to look for, and a multilingual export that loses the locale relationships is a migration problem waiting years to happen. Content model migration covers why that particular loss is so expensive to repair.
The short version
- Everyone answers yes to “does it support multiple languages”. Ask which of the four models it implements.
- Translations of one thing want field-level localisation. Independent editions want separate sites. Most teams are in between.
- The tests that matter: publish one locale independently, see what happens when the source changes, and find what is untranslated.
- Locales are frequently a metered unit or a tier trigger. Ask in writing. No numbers appear here.
- The editorial cost is bigger than the platform cost, because every article now has a lifecycle per language.
- Multi-site is a related but separate requirement. Test it separately.
