Quite often a company has settled on one or more content management systems before they even think about localization. Sometimes they land on a natively multilingual CMS like Contentful, but quite often they don’t.
It’s not that teams choose poorly, but they are typically unaware of the dependencies between content management systems and translation platforms. They often choose these platforms based on prior experience rather than do a systematic assessment of current and future needs.
If you haven’t chosen a CMS yet or are planning to migrate
This is the ideal place to be because this is a critical infrastructure decision. You have the opportunity to get this right from the beginning, which will save you a lot of time and money because migrations are expensive and slow.
Be sure to read Choosing A Global Ready Content Management System (CMS) and Translation Management Systems : Which One Is Best?
You have chosen a niche CMS and aren’t able to migrate
This is a common scenario I encounter. EPD teams in particular will often choose a niche CMS or static web framework for things like documentation. These systems are often not well supported by translation platforms, so you have three basic options here.
- Manually cut and paste content and translations to and from the translation platform. This is not scalable, but if you only have a limited number of articles and target languages, this can work with the caveat that it’s not a good use of staff time.
- Build your own API to API integration to push source content to the translation platform and download translation. This is usually a cron job that runs a few times per day. These sorts of integrations are easy enough to build, but if you don’t have engineering support, you might be blocked. This is usually a smallish job for an engineer, so if you have support from engineering this is the best option.
- You can use an orchestration tool like Blackbird.io to perform these actions. Blackbird is a no code / low code tool for content and localization automation. I generally recommend Blackbird to clients, even if they have engineering support, because everyone has edge cases and usually engineering capacity is limited. This is a good option if you don’t have dedicated engineering support.
You chose a natively multilingual CMS and are ready to start adding languages
Some teams get lucky and have already chosen a natively multilingual CMS that has solid TMS integrations (like Contentful and Storyblok). That’s good news. All you need to do is to decide on a translation management system that works well with your CMS. The main things to be aware of when choosing a TMS are:
- How robust is their integration with your CMS?
- Does it support full automation or do users need to initiate translation requests?
- Does it sync bidirectionally with the CMS?
With the CMS decision out of the way, your decision making process for selecting a TMS is simpler. Be sure to read Translation Management Systems : Which One Is Best?
You chose a CMS that has broken support for localization or no support at all
This is an unfortunate position to be in, but it happens a lot. Many CMS platforms treat localization as an afterthought, if they consider it at all. I recently worked with a customer that was using static web framework to host their documentation.
While this is great for performance, the framework had broken support for localization. It supported multiple locales, but it had no support for fall back rules and would return a 404 error if there was no translation for a page.
A good CMS will support fallback rules like:
- Try to display the asset or page in Mexican Spanish
- If that’s not available, fall back to generic Spanish
- If that’s not available, fall back to US English
It is almost always better to revert to the source language (often English) than to display a page not found error.
The available work arounds are:
- Migrate to a CMS that is natively multilingual. This is the best long term solution, but migrations can be slow and expensive. This will only get worse the longer you put this off.
- Use a Javascript widget or translation proxy to serve translated views of pages. This works, but generally search visibility is limited, which is an issue for documentation and KB content.
- Punt on localizing this content or assume that users will use in browser machine translation. This is not ideal, but it may be the least worst option if you can’t migrate.
Be sure to read Localizing Legacy Websites And Services and Multilingual SEO : A Primer
Related Reading
Choosing A Global Ready Content Management System (CMS) – this article walks the reader through considerations in choosing a CMS that can grow with you.
Translation Management Systems : Which One Is Best? – this article walks the reader through considerations in choosing a TMS (best done at the same time you are evaluating CMS platforms).
Localizing Legacy Websites And Services – this article reviews your options in localizing legacy websites and services that were not built with multilingual usage in mind.
Integrating Your CI/CD Pipeline With Your Translation Pipeline – this article discusses how to integrate your CI/CD pipeline with your translation platform, often used for in app content localization.
Get In Touch
If you’d like to discuss your situation in more detail, book an initial consultation.