One of the most important purchasing decisions you’ll need to make as you build out your localization and internationalization program is a translation management system (TMS). You can think of this as a Content Management System that is designed for translation. When set up correctly, a TMS enables you to automate most of your translation processes. This way source material is translated by default. Most companies start off with mostly manual translation processes. This works OK for small mobile apps in a few languages, but it doesn’t scale as your scope of coverage increases.
Code Repository Integration
Most TMS platforms integrate with popular code repositories like Github and Bitbucket. The companies that offer TMS largely started out as app localization tools, so that’s largely taken care of.
CMS Integration
If you plan to localize your company website (and in most cases you should), you’ll want to choose a TMS that has a robust integration with your CMS. If you have not already chosen a CMS, this is a good time to do so. The switching cost for both of these platforms is high, so it is important to get that right early on.
It is important that your CMS supports multi-lingual operation. Word Press, for example, can only do this using third party plug-ins. Other CMS platforms like Drupal and Contentful are natively multilingual.
Things you will want to look for in the TMS ←→ CMS integration include:
- Process automation : The ability to configure daily automations to pick up new or edited source assets for translation.
- Configurable workflows : The ability to route different types of assets to different workflows (for example, you might send help center articles to a machine translation + postedit workflow, but send marketing articles to a transcreation agency).
- Support for long form content : some TMS platforms do not segment long documents into sentences. This is unwieldy for translators and reviewers to deal with (and error prone)
- Support for in context previews : so translators can see the text they are translating in the larger context of the page it belongs to
As a general rule, higher end TMS platforms have more and better CMS integrations. Low cost platforms tend to have cruder integrations or do not provide them at all. TMS platforms are a niche product and it costs money to maintain these integrations. The right way to view TMS pricing is to compare it to the engineering time and cost to build and maintain integrations. In most cases, the TMS wins compared to having scarce engineers work on bespoke tooling.
If you have already selected a TMS for app localization, which is where most startups begin, you may need to select a different TMS for long form content (web site, help center, etc). While it is generally best to use a single TMS across assets, migrating existing projects to a new TMS is often a lot of effort. This is where we ended up at Notion, which had used Lokalise for app localization before expanding the scope of translation to include web assets and lifecycle comms. We ended up using Smartling for long form content, and stayed with Lokalise for several years as we were so busy and Lokalise worked fine for translating in app content.
See also Choosing The Right Content Management System (CMS)
You’ll also need to go through a similar evaluation for your Help Center if it will live different CMS like Zendesk.
AI + Machine Translation
You are probably going to want to use AI (machine translation) as part of your translation process. Mature TMS platforms enable you to set up a variety of workflows from fully automated machine translation to extensively reviewed human translation. For example, you might route your Help Center back catalog to an AIPE (AI + post-edit) workflow, while marketing assets are routed to human translators and copy editors.
The TMS can also take some of the guesswork out of which machine translation service to use. There are dozens of options available now, and certain systems tend to do better for some languages and not others. Smartling, for example, scores MT engines by how much post-editing is required, and routes translation requests to the MT engines that score best on this metric.
Language Service Providers
A good TMS platform will enable you to use whatever combination of language service providers, freelancers and in house employees you want to. In fact, that is one of the most important functions, because it is often the case that a vendor that is good with one set of languages will struggle with others. Flexibility in work assignments is key.
🚫 Be wary of a translation or TMS provider that locks you into using their translation services. There are a few agencies that do this. It almost always results in a bad customer experience. It’s fine if they offer language services as an option, but also allow you to bring your own translation agencies and freelancers.
Pricing
TMS platforms are generally priced based on some combination of content volume, user seats and the number of integrations.
Let’s consider a common scenario, where a company needs to localize most customer touch points into five languages.
- Help Center (Zendesk) : 150,000 words
- Marketing Site (CMS) : 100,000 words
- In App Content (Github) : 50,000 words
That works out to 1.5 million words (300,000 words x 5 languages).
Depending on which vendor you go with, you’ll probably be looking at an annual spend of around $30,000 to $60,000 per year for the TMS platform. That works out to about 2-4 cents per word (for context, the standard rate for professional translation is 20 cents per word, and more for high end copywriting). Another way of looking at this is to compare the cost of hiring an engineer to build a custom TMS or to build and maintain integrations with other systems you use.
In most cases, SaaS platforms will constitute only 10-15% of your overall program budget. This is also always going to be cheaper than building and maintaining your own TMS and associated integrations. See Budgeting For Localization
What If We Need To Migrate To A New TMS?
This situation arises when a company selects a cheap, mobile focused translation platform and then later needs to translate other touch points (web site, help center, lifecycle comms, etc). This is sort of where we were at Notion. When I joined the company in 2021, they had localized the mobile and web apps successfully using a TMS that couldn’t deal with long form content.
We ended up using another TMS (Smartling) to translate our website and help center, which were hosted on Contentful, a natively multilingual platform. At the time, Smartling had the most robust integration with Contentful and while it was more expensive than alternatives, we also had very limited engineering support, so whatever TMS we used had to have good integrations already built.
We had planned to consolidate app localization onto Smartling, but we had a lot on our plate, that process wasn’t broken, and we weren’t spending that much on the other TMS, so we stayed with it for a long time. The issue we ran into whenever we tried to migrate older app localizations over to the new TMS was that the translation memory (a record of previous translations) would get corrupted, which meant that we would have to re-translate a decent amount of the existing app translations, and also risk regressions that would be noticed by users.
Another situation that also comes up, especially in fast growing companies, is that different teams will choose different translation platforms. This usually happens because there is no “owner” for localization. For example, the product/engineering team might use a app localization TMS for its work, while marketing will opt for something that works well with the systems they are using.
While this situation isn’t ideal, the cost of translation tech compared to the overall spend related to regional expansion is usually low. So in that situation, I go with the attitude that if it isn’t broken don’t fix it.