Another trap companies often fall into is to choose a CMS that is not designed for multi-lingual content. Early stage companies will often pick the CMS that is cheapest, or eschew using a CMS at all. Migrating to a different CMS after you have a fully built out website is challenging at best. So it is important to get this right early on to avoid having to migrate to another CMS down the line.
The good news is that many CMS platforms natively support multi-language operation. Drupal and Contentful are two good examples (Word Press, on the other hand has no notion of multiple locales, and requires the use of third party plug ins to do so). That’s one criteria to consider.
Another criteria to consider is what translation management systems (TMS) a candidate CMS integrates with. Smartling, a popular TMS platform, has connectors that work with a wide variety of CMS and customer support platforms. Whatever CMS you choose, you’ll want to make sure it can be integrated with one or more TMS platforms. In general, you’ll want to avoid using lesser known platforms because it is unlikely they provide robust integrations like this.
<aside> 👉 One option to consider if you are stuck on a legacy CMS is to use a translation proxy service, such as Smartling’s GDN (global delivery network), or a Javascript translation plugin that “redraws” the website with translations. Transifex and Localize both offer the latter functionality. That said, it is generally better to translate within the CMS, primarily to make translated content searchable.
</aside>
While multi-lingual CMSs like Contentful allow content maintainers to add and edit translations to assets, maintaining translations within the document editor is very tedious. Let’s say a content author edits a paragraph in a support article. Translators then have to comb through to find these changes and update the translated versions accordingly. It is very easy for translations to get out of sync with the source material.
With a TMS, on the other hand, incremental changes like this will get picked up. Translators work within a translation editor that isolates these changes so they don’t need to go through the entire document. This is a lot like the way Github displays the diffs in a pull request. It saves translators a ton of time, with resulting cost reductions.
TMS platforms also enable automated workflows where translation happens by default. For example, with Contentful (CMS) and Smartling (TMS), you can set up an automation where any new or updated asset will get queued for translation without user intervention. This eliminates a lot of busywork for content maintainers, whereas with the in CMS approach, somebody has to track down changes, manually submit translation requests, and generally herd cats (not fun, nor a good use of staff time and money).
You’ll need to make a similar decision around customer support material. If possible, I recommend using the same CMS for marketing and CS|CX material, although you probably will want to create separate domains or workspaces for each. The past several companies I worked at used Contentful and were overall happy with it.
That said, you may opt to use a turnkey customer support platform like Zendesk. If you go that route, you’ll want to make sure it supports multlingual content and is integrated with the TMS you decide to go with.
<aside> 👉 While there are dozens of low cost TMS platforms that do a great job with app localization, relatively few of them have good support for long form content. If you are planning to localize web content such as your marketing site and help center, you’ll want to look at one of the higher end TMS platforms. Pricing for these is generally a function of how much content you are translating. While more expensive than app localization tools, the cost is generally about 10% of what you’ll end up spending on translation services (even with AI driven cost reductions).
</aside>