Article by Yulia Akhulkova.
Translation management systems (TMS) are one of the oldest language technologies out there. The first solutions appeared in the 80s with the emergence of brands such as STAR Transit and Trados, and the segment has been booming since 2010. In 2022, there are well over 160 technologies of this type on the market.
Before TMS came about, computer-assisted or computer-aided translation (CAT) tools were the main means of properly handling translation tasks. As we’ve previously discussed, CAT tools allow users to work with bilingual text, that is, the source (original) and the target (translation) languages. The core components of CAT tools usually included a translation memory (TM), a bilingual editing environment (such as an interactive bilingual table), a termbase (TB), and a quality assurance (QA) module.
Over time, these features were no longer enough to effectively deal with the growing and dynamic translation and localization needs of modern enterprises. That’s why a variety of business management features ended up appearing in this type of solution, resulting in the birth of what is now called TMS.
The History of TMS Technology: From the 80s to 2010 by Nimdzi Insights
In addition to standard translation environments, modern TMS feature extensive machine translation (MT) options, connectors to a variety of third-party software, such as content management (CMS) and business management (BMS) solutions, as well as design systems and multimedia localization technologies. This provides an efficient way of managing the translation needs of an enterprise from A to Z.
Interestingly, though, there is some irony in the existence of unclear terminology around the naming of TMS/BMS. Both these categories of tools play a central role in localization. The main difference between them is that in a TMS you both translate and manage jobs while in a BMS you just manage jobs/translation tasks. There’s no translation environment per se in the BMS. However, a BMS can connect to different TMS.
Let’s look at the TMS segment of language technology more closely, discussing regular TMS use cases and associated challenges, as well as trending TMS solutions.
With the reality of continuous translated content delivery, there exist consumers and clients who don’t want to know (or who don’t care to know) how their products get localized into multiple languages. They just want to see it get done — and the sooner, the better.
Such an approach requires solid underlying technology to support a quick and seamless translation workflow. What’s more, it should be noted that a regular operational workflow usually involves dozens of tasks and processes — from customer database management, translation task coordination, and productivity tracking to business monitoring and risk analysis. All of these need to be tracked and monitored for the success of a given translation project and the overall localization effort of an enterprise.
This is why the technology stack of a global company often includes specialized software to manage their localization needs. Nowadays, such solutions can be either standalone and/or combined with language services, whether in-house or outsourced, commercial or open source. So, do enterprise-side localization teams tend to own their TMS in-house? Independent sources confirm this was a trend at least in 2019: according to a survey by BeLazy, “the majority of localization buyers today have a TMS that they control."
Moreover, as development teams and engineers have become translation buyers, the traditional waterfall localization model is being replaced with agile localization models. Many TMS providers are responding to this: Memsource with Phrase acquisition, XTM, memoQ, Smartling and others by providing utilities for string localization enrichment (key-based context, continuous processes, screenshot preview), etc. Another TMS brand that has been oriented for developers, Lokalise, is experiencing hyper-growth.
There are also TMS partnerships being established with developer hubs like Atlassian. By attacking the developer market, TMS brands actively answer an IT enterprise use case for translation management solutions.
Design teams and buyers are also not being left behind by TMS providers. Several TMS (e.g. Smartcat) now provide a simpler way to work with multilingual designs, e.g. in Figma. Users can switch between languages, adapt the layout, and collaborate with linguists — all without leaving Figma.
Based on a more recent survey conducted by Nimdzi in 2022, the top-5 companies in the TMS arena — memoQ, Memsource, RWS, XTM, and Smartling — have all increased their individual brand awareness over the past 10 years.
Table: Which of the following TMS solutions have you heard of?
|No.||TMS||Response count||Percentage of total respondents|
Moreover, as data from the same survey suggests, memoQ and Memsource hold the position of most favorable brands on the market, featuring the highest number of positive experience responses as well as the lowest number of negative experience responses. In terms of low frequency of captured negative feedback, they are joined by translate5. However, it should be noted that only 10% of the survey respondents left feedback about translate5, whereas both memoQ and Memsource are well-represented, being rated in 63.5% and 63.9% of all survey responses, respectively.
Source: Nimdzi TMS survey, Q1 2022
These are responses about just 14 systems, which corresponds to less than 10% of the entire TMS market. Taking into account the total number of existing TMS solutions, choosing the right system in and of itself can present a real challenge and can be both time-consuming and costly. Let’s see what factors shape decisions around investing in a TMS.
A TMS needs to take into account the desired file formats, code repositories, and various language services including translation, transcreation, machine translation post-editing (MTPE), among others.
However, matching TMS features to specific organizational workflows usually takes place during the testing or onboarding stages of a TMS implementation process — once the decision of investing into a TMS has already been made.
Looking at the issue of selecting a TMS from a broader perspective, when buying or changing TMS, enterprise-level decision makers care about a number of common themes. Some of the most frequent themes are the following:
Source: Nimdzi Insights
Localization managers are primarily concerned with how a TMS is likely to fit their user expectations, including how easy it is to use the workbench environment and how intuitive the job management and setup features are. Previous unfavorable experiences with a TMS environment often influence decisions about a new alternative.
Another strong factor that produces a significant emotional response is the quality of communications with TMS vendor sales and support teams. Integration capabilities add to a core set of TMS requirements. But, this is a high-level view, so let’s look a bit closer at some of the known challenges associated with the process of selecting a TMS.
If a company was an early adopter of TMS technology and deployed a TMS before the advent of cloud-based systems, it’s likely that they are not really taking advantage of newer technologies. They may also struggle with continuous localization. Growing international businesses may find that their initial TMS choice is not adapting and scaling as fast as their needs are evolving, forcing them to reevaluate TMS after a shorter time than expected.
As noted above, a modern TMS should be able to connect to a diverse set of systems, from web content repositories to home-grown software solutions. Customers expect their TMS to keep up with the ever-evolving enterprise tech stack including technologies being onboarded in other parts of the organization. TMS connectors are used for (but not limited to):
TMS providers, in turn, offer such connectors, with prices per connector ranging from free to USD 20,000 and more. As memoQ puts it, “Connectors are priced on a case-by-case basis. There is no standard pricing for connectors.”
As we see, connectivity is an important factor that can significantly deviate from the original price of a TMS solution.
Speaking of prices, when making decisions around implementing a TMS, another appropriate question to ask is: What would the ROI of implementing it be?
The costs of such a solution include not only the cost of ownership (for instance, the price per seat multiplied by the number of TMS users) and operational expenses, but also, at the very least, the time invested in market research and comparison of tools, implementation costs, training and updates, etc. These calculations can easily consume a significant portion of decision makers’ time as well, as not only is calculating ROI a commitment, but so is defining metrics and tracking the numbers. All of this takes serious effort, without guaranteed crystal-clear outcomes.
Companies with high expectations for data security and confidentiality often have strict requirements defined by the IT or infosec team for any connector or cloud-based service. In language services, these requirements extend from simply signing a specific NDA (by all linguists and other parties involved) to establishing encrypted connections to a translation environment. How do you ensure that your document does not leave the TMS environment on the translator side, for example? Or that your document is not compromised when transmitted via unsecured email servers?
As more global enterprises adopt regulated industry practices, they want to have proof that their entire translation workflow is secure. Unfortunately, not every TMS can boast compliance with such protocols.
In view of modern security demands, some companies prefer to have full control over translation operations and build their own TMS solutions. This remains a viable strategy, especially for IT companies such as SAP or Mozilla. Still, the challenge with buyer-built technology is that it is not necessarily created with translators in mind and is, therefore, quite often not translator-friendly. Sometimes, the concept of the translation supply chain itself is entirely missing from buyer-side TMS technology. The solution, then, is usually to export and import the translation material with an XLIFF, but there are systems that don’t allow the translations to be imported back into them, and workaround solutions can potentially lead to quality compromises.
For customers wanting to migrate from one TMS to another, there is another issue. Estimating the positive financial impact of a TMS migration can prove challenging, and it’s not uncommon for this to be the reason why migration projects are often postponed. Specialists involved in the daily localization work using an “old” TMS may know this has to be dealt with, but without understanding the benefits, no one is motivated enough to allocate the necessary resources. And carrying out an in-depth analysis while calculating the costs associated with the old system compared to the savings associated with a new one requires not only a certain level of expertise and language service maturity but also time to properly conduct this investigation.
Evaluating and migrating between technologies is a lot of work and there are always reasons not to do it. It might be the complexity of moving away from a familiar infrastructure, even if it isn’t fit for the purpose, or the prospect of the time, technical work, and costs involved.
Speaking of costs, because of the diverse profile of buyers and the high degree of customization of their solutions, most TMS providers are not able (or willing) to disclose their pricing on their websites. Instead, they will just capture contact information to later follow up on their offerings. Even if information around pricing models is present on the website of a TMS provider, a buyer will still have to book a call to learn the price of their specific “team/enterprise” case. So what can one learn from pricing pages, then?
There are packages for different scenarios. They are hard to process and compare at a glance. Every TMS provider has a different understanding of what should be included in the package and what information they should disclose with regards to the package components. The due diligence required for TMS pricing alone requires the highest level of localization maturity.
That’s one of the reasons why even the most technically minded members of a localization team may feel that they’re not qualified enough to efficiently evaluate and compare all of the different integrations, supported workflows, etc., available in a range of TMS solutions. Some companies solve this by hiring a full-time engineer. Some by collaborating with an external consultant. But are these extra forces really able to make the best decisions for the whole company and be trusted with implementing and optimizing one of the most expensive and important components of a globalization program?
Moreover, the prospect of rebuilding the web of integrations and patches that have grown around the familiar solution can be quite challenging for both internal and external stakeholders. Speaking of which, with TMS, there’s rarely one solution that satisfies the needs of all stakeholders involved. External vendors will also need to ensure that projects can continue to be processed in adherence to established KPIs/SLAs. Yet again, we should remember that the goal is not to make each individual stakeholder happy, but to find the best solution for the organization as a whole.
A TMS empowers users to organize their processes and workflows, automate resource allocation, measure performance, control translation quality and monitor the whole localization production. Its core power remains in leveraging a TM, helping customers save money by benefitting from various TM matches. However, a modern TMS is much more than that. Among other things, it also collects and stores various user data, making it easy to access and leverage.
The most desired benefits of a TMS now include automation and interoperability. Connectors to other systems enable easier data exchange between multiple sources — be it a marketing team or a development team. They facilitate more continuous localization processes: for instance, sending text through the GIT connector and creating tasks automatically in a TMS as soon as there’s a change in the text.
However, removing all these manual steps from translation workflows has to be preceded by the challenging task of selecting a proper TMS out of over a hundred possible solutions, the prolonged challenge of a TMS adoption, as well as establishing properly organized ongoing support.
The same way clients (and their content) come in all shapes and sizes, there is a great variety of TMS solutions on the market, that each strive to address the specific needs of their client. Accordingly, the TMS market itself is one of the busier — and more competitive — subsegments of the language technology landscape.
Interestingly, when researching news and developments from the main providers of TMS technology, we see that this market segment is experiencing growth that is, at least for some players, outpacing the growth of the overall language services industry. Growth that, in turn, attracts investment opportunities and opportunities to consolidate market position, as evidenced by a slew of mergers and acquisitions.
The article was written by Yulia Akhulkova, Nimdzi's Technology Researcher. If you have any questions about TMS or language technology in general, reach out to Yulia at [email protected].
Language technology providers are scrambling to jump on the speech-to-text bandwagon which means users can view machine-generated live subtitles (translated from the original) as well as multilingual captions (monolingual transcripts available for different languages)of speeches in their preferred language.
This report is the first in an ongoing Business Confidence Study series that Nimdzi is kicking off to keep a pulse on the industry.
Cologne-based DeepL has announced the beta launch of DeepL Write, an AI-powered authoring tool intended to improve texts by fixing errors and making suggestions for word replacements while keeping an eye on style, grammar and formatting.