Choosing the Right CMS for Multilingual Accessibility and Global Scale

Just as you will need to write code to be global ready, it is also a good idea to choose a content management system that can support multiple regions and languages. Most early stage companies choose a CMS long before they decide to expand into other languages. Some get lucky and choose a natively multilingual CMS like Contentful. Some don’t, or even worse, try to build their own CMS (please don’t do this).

This article is not intended as a comprehensive overview of CMS platforms, but rather it points out the feature areas to be aware of in planning for future multi-language, multi-region rollouts. It is far cheaper to plan ahead, even if you don’t end up doing this, than to be forced to migrate from one CMS to another once you have a fully built out website.

Primary Criteria To Consider

Is The Web Important?

This is important to call out because you can save a lot of time and money if this isn’t important to your business. A CMS platform is primarily used to host long form content. For example, if your main interaction with users is via mobile apps, and your website exists mainly for ancillary purposes, you don’t really need a fully featured CMS and can use tools like Wix, WordPress, etc and not worry about localizing everything there.

Lyft is a case in point. We localized the company’s corporate website into six languages, but in hindsight this was probably a waste of time because hardly anyone was visiting the corporate site, especially outside of English.

Multi-Locale Support

The most important criteria to consider is whether a CMS supports multiple languages and locales. Many CMS platforms treat this as an after thought. A well designed CMS respects locales as part of its internal data structure. Documents or objects authored in the CMS can exist in many different locales (e.g. “en-US” for US English, “en-GB” for British English, “es-MX” for Mexican Spanish and so forth).

A well designed CMS will respect signals about the user’s preferred language, including their browser’s language setting (signaled via the Accept-Language request header), account parameters if logged in, cookies, etc. With this information, it will serve content in the user’s preferred locale while respecting fallback rules.

Let’s say the user is a Peruvian Spanish speaker (locale code “es-PE”). Some of the content on the page they are requesting is available in the “es-PE” locale, some is available in a generic “es” locale, and some is only available in US English. The general fallback rule the CMS should follow is to try to serve content in the user’s country and language domain, then fallback to a generic language domain, and then fallback to the source domain (typically English, but this pattern applies generally).

So the main questions to ask a candidate vendor are:

Does your platform allow documents and modules to have representations in multiple locales?
Does your platform support locale fallback rules as described above?

Of the CMS platforms I’ve worked with, Contentful handles this well, is easy for non-technical people to work with, and is well integrated with translation management systems. It should be at the top of your list for consideration. While I’ve worked most extensively with Contentful, other headless CMS platforms like StoryBlok and Sanity score well in this regard.

Integrations

The next issue to consider is whether the CMS is integrated with translation management systems. Most TMS platforms have REST APIs that enable integrations with other platforms like content management systems, but it’s best if you can use an out of the box integration to sync content and translations back and forth. Nobody likes to build and maintain this tooling, especially when the person who built it quits before documenting what they built. It’s usually easier and cheaper to buy this if you can.

This is also why it is important to consider both CMS and TMS purchasing decisions at the same time because there are a lot of dependencies between them. One issue with some TMS platforms is that while they are good for app localization, they have weak integrations with CMS platforms.

A lot of this will boil down to how much engineering support you have. If you are well supported by engineering, you’ll have more flexibility in choosing these systems. If not, you’ll probably want to look at higher cost but well integrated systems like Phrase or Smartling. I’ll discuss this tradeoff in more detail at the end of the article.

Something to dig into when asking about TMS integrations is the level of automation they enable. Some integrations are pretty weak and are little more than widgets to request a translation from within the editing tool. This means content maintainers need to remember to request translations when they add or update content, which they will forget to do.

I like to set up “set it and forget it” automations where all content is translated by default. For example, with Smartling and Contentful it is easy to set up an automation where all new content with tag “X” is routed to a specific translation workflow, while updated content with tag “Y” is sent to a different workflow.

This is powerful because it works at scale, frees you from busy work, and enables you to automatically use different workflows for different content types (e.g. long tail help center content goes to AI only translation while signup funnel content goes to boutique translation agencies).

Modular vs Page Oriented Architecture

This is another important consideration because in addition to translating your content, you will also need to serve different content in different regions.

Let’s look at the example of your marketing home page. One of the things you will probably want to feature are anchor customers or logos. A good heuristic to use here is [a few global brands] followed by [a few local brands].

A CMS with a modular data architecture makes it easy to do this by creating pages from “LEGO blocks” that are child objects within the page object. So your signup page might be represented as a group of objects like below.

			
[Home Page]  
  [Title]
  [Hello Welcome To ABC Company]
  [Global Brands]
  [Local Brands]
  [Sign Up For A Free Trial]
  [Footer]

		

The CMS renders each object in the user’s locale. The detail to catch here is that the title, welcome, global brands and sign up blocks are translated from the source language, while the local brands block is specific to and authored in the user’s locale/language.

Localization involves more than translation and is about making your company and product appeal to users in their region and culture. A modular data architecture makes it a lot easier to create websites that are culturally relevant to users, which improves adoption and retention.

Apart from localization, a modular data architecture cuts down on busy work. Let’s consider the example of a help center knowledge base. In each KB article you have a paragraph that reads “Stuck? Need help? Contact us at ____”.

If you need to update that contact point, you can make one edit in a modular CMS. In a page oriented CMS, you have to make that edit in every page where that callout appears.

Application Boundaries

Another thing to consider in choosing a CMS is the ease with which you can blend application generated content and CMS served content in a single domain. Headless CMS platforms make this easier to do since the CMS is front ended by the application and functions more as a data store and editing environment for content authors and editors and does not act as a user facing destination.

Standalone CMS platforms like WordPress don’t really enable you to do this because it is not possible to run application logic within wordpress.com. If your product is a web/mobile service and you want to blend the application with your long form content, you’ll probably want to look at a headless CMS.

When I was at Notion, the boundary between app and CMS hosted content was pretty blurry. Much of the marketing site and help center lived in the CMS (Contentful), but signup paths and support agent paths were app driven. The general rule of thumb was “if it is a document or longish blurb of information put it in the CMS, if it is small or dynamic serve it via the app.”

Legacy Assets and Content

Pretty much every company I have worked with has this issue. There is almost always an orphaned website or service where nobody remembers who built it, but there isn’t enough time or money to properly refactor it. This type of asset, by definition, can’t be connected to a translation management system, so what do you do?

One option to consider is to use a Javascript translation plugin that “redraws” the website in the client browser with translations. Transifex and LocalizeJS both offer this functionality. This is a bit of a workaround, and has limitations such as limited search visibility, but it’s cheap, easy and it works.

To Do’s And To Don’ts

Think About Who Your Reader Is

More and more content is being created for AI. Help center content is a classic example of this. While you may continue to publish one, most users will interact with it via an agent in the course of asking questions. While you are still authoring content for your users, their interaction with it will often be mediated by AI. This is another reason to look at headless CMS platforms because the reader could be a person with a web browser or an AI agent that is consuming structured data.

Consider Your Level Of Engineering Support

All TMS platforms worth considering provide REST APIs for importing and exporting content and translations. If you have good engineering support, the dependences between your TMS and other platforms including CMS are much less of an issue. If you are limited in engineering support, it is more important to anticipate dependencies and probably spend more on CMS and TMS platforms that have good integration coverage (buy versus build).

Beware Of Prior Experience Bias

Decision makers will often buy from vendors they are familiar with. This bias affects everyone regardless of which team they are on. This isn’t an automatically a bad thing, but it’s important to be aware that everyone who has worked with a web editing, blogging or CMS platform has opinions that are shaped by prior use.

A good way to work around this is to build a feature or decision matrix that captures the needs of different teams and user personas. This will naturally steer you toward vendors that are well matched for your needs.

Don’t let one department make this decision

The choice of CMS is often made at a team level, and this can turn out badly in two ways.

In an engineering led company, the decision is forced by engineers who fetishize features or metrics that are totally irrelevant to marketing and customer success.

In a marketing led company, the decision is forced by less technical people who favor pre-made, purpose built solutions that while they are good for their intended use case provide little flexibility or extensibility.

In both cases, the result is a system that is a mismatched to different teams and needs. Note that it is not bad to have more than one CMS, but the decision to do so should be well considered and not accidental.

Don’t Let Perfect Be The Enemy Of Good Enough

This is a cliche, but it’s true. CMS and TMS platforms are enterprise software. As such they are neither cheap nor delightful to work with. Their job is to facilitate work and fulfill a functional need, and they all have tradeoffs.

There are two traps to be aware of here.

One is failing to make a choice because of decision paralysis. Whichever platforms you are considering they will not address all of your needs. So you will need to decide what criteria are most important. Not deciding is also a choice, which typically leads to individual teams going off in different directions. It is hard to undo that later on.

The other trap is rushing the decision. Startups and early stage companies often approach these decisions in an ad hoc or shambolic manner. One of the original engineering managers makes a decision that nobody remembers the rationale for (probably prior experience combined with a deadline).

Conclusions & Platform Summaries

The purpose of this article was not to tell you which specific vendor you should choose, but rather the questions you should be asking. I’ve spent my career working in startups and early stage companies. The lack of process and ad hoc decision making is both a strength and a weakness for them.

The main issue to understand is that choosing a CMS is an architectural and infrastructure decision. It is important to get this right or mostly right early on because migrating off to something else will just get more expensive and time consuming as time goes on. As the migration cost grows, the incentive to defer action does too.

As a wrap up, here are some thoughts on platforms you are probably considering.

Contentful

Multilingual content model, modular information architecture, headless/AI first, and extensive integrations with translation platforms. Checks all of the boxes related to localization and global accessibility. It requires more technical expertise to deploy and may not meet all of your needs, but it should definitely be considered.

Drupal

Multilingual content model, but a page oriented information architecture. They now offer a headless version. Drupal is open source so it can be adapted to specific use cases.

Sanity

Multilingual content model, modular information architecture, and headless. Decent but not deep integrations with TMS platforms. You may need to build and maintain your own TMS integrations for full automation.

Storyblok

Multilingual content model, modular information architecture, headless CMS. Decent but not deep integrations with TMS platforms. As with Sanity, you may need to build and maintain your own TMS integrations for full automation.

WordPress

Monolingual content model, but can be rendered in other languages via plugins like WPML. If you just need to set up a website with a limited number of pages and languages, it works well and is super easy to deal with.

Choosing A Global Ready Content Management System (CMS)