Nowadays choosing the perfect TMS should be a piece of cake, shouldn't be? Well ....
During my career in the Localization industry, I have had the opportunity to be involved in choosing a TMS in the companies I worked a few times. 3 to be precise. Today we have many companies developing very sophisticated TMS. I’m quite impressed with the functionality that I’ve seen in some of the TMS I have had the opportunity to test lately.
There are many TMS that can help us improve our translation process, to automate traditionally very time-consuming tasks that Project Managers are in charge of.
Technology has advanced enormously, and with so many solutions in the market, it should be easy to find a TMS that suits the internal needs of a Localization team and his stakeholders, right?
Well, no, not really.
Choosing a TMS that meets the needs from the client's perspective was not easy a few years ago, not easy now, and I wonder if one day it will be easy....
The question then is, why is it so difficult to find a TMS that suits the needs of a client? My thoughts below.
A company usually develops internal tools to meet their needs, these tools are constantly evolving; In many companies there are internal teams that create tools, that evolve them, they are iterating the tools, the tools are changing, they are improving ... and an external TMS suffers a lot to keep the rhythm of an internal team improving tools. In addition to that, internal tools are rarely developed with Localization in mind. Let's set a real example, a mobile app, a video game to be more specific 😉
We can have an internal tool that fits developers needs to write in-game content, probably that internally developed tool is the perfect tool to store all the keys and content that then it's perfectly integrated into the Jenkins compilation process that are converting lines of code into moments of fun for players; but we may also have other internal tools for other roles that are involved in the process of bringing a game to the market.
Perhaps, we have another app for the team that creates the push-notifications that we see on our mobile phones, maybe there is another internal tool for the team that is responsible for creating FAQ, or managing customer support relationships with players, and maybe, there might even exist another tool that is the content repository for the Legal team. With this landscape obviously what it comes to my mind is ...is it really necessary so many internal tools? Well, I don't know, maybe we can reduce the number and homogenize a bit, but the reason why there are so many internal tools is that the content and needs of different stakeholders are very different.
In our industry, we are trying to solve this challenge with APIs.
APIs that connect a TMS with an internal client tool(s). Good intention, laudable intention. But doing just that, the problem is not really solved. An API is a bridge, it connects systems, but that is not enough. The internal tool is going to be very unlikely that has been developed with localization in mind. For example, the chances that an internal development team will create an internal tool that respects and understands let's say how to manage ZWS (zero wide space) in Japanese is quite minimal. Yes, it is likely that the internal tool is managing properly “normal” content but it is “less” likely that the internal tool is internationalized. Internal tools are not developed with Localization in mind, and this is a handicap for API or any connector in general.
The API is not a magic solution, in addition to having an API, we need to connect it to the different internal tools, and that's where everything gets complicated; Each tool is storing the content in a different way. Although we are able to connect an API to internal tools, that will not be enough; being able to move back and forth files is not enough. We have to take the content file, process it and display it correctly. This is infinitely more complicated than it seems due to the diversity of workflows, the diversity of internal tools and the diversity of content types.
For this reason, there are many translation buyers that they decide to create and customize their own CMS and create own tools. See below image a real example about how Squarespace is managing their content. In the following illustration we can see the complexity of the TMS integration by interacting with different systems.
Source: Squarespace
Finding a connector, an API, a TMS that connects and integrates internally is tough. Now, complicated does not mean it is impossible!
And this is when certain vendors or software development companies can help customers to customize an API to connect to different internal tools.
Sometimes we believe that an API connecting everything is the magic solution, but it rarely is.
API + Deep customization is in my opinion the only way to have smooth integration.
So, which are the key-take aways from this post
An API alone is unlikely to make our Localization/software development framework strong enough.
Connecting systems is different from having a smooth integration.
To have a smooth integration the API in many cases is not enough. API / connector customization is the key.
And to finish this post in a positive tone I leave 3 links that they are very detailed and informative about what aspects we should take into account when selecting our TMS
Basic architecture of a Translation Management System
What is your experience in your teams, in your companies or offering solutions to customers? What steps have you taken so that the TMS is perfectly integrated into the production framework of the development teams?
It would be great to have a standard in the industry that solves these problems, but until that moment arrives I would love to get your comments below, please share how you face this challenge of integrating translation management systems in development environments.
One last thing …. Confused about what’s a CMS and a TMS, click HERE to read my post Twins ... CMS and TMS. So similar, so different where I explained the differences/similarities
Have a great week everyone!
@yolocalizo
In this blog post, I imagine three roles that could become as popular as the Social Media Manager did: AI Workflow Localization Manager, Localization Data Curator and AI Localization Quality Specialist
These roles blend human expertise with AI, pointing to a future where localization jobs look very different from today.