In translation management, there is a growing class of buyers with a do-it-yourself approach. Often, developers and product owners build a technology stack from multiple components like Lego blocks. They connect those components with the help of application programming interfaces (APIs) that are sets of commands to operate software through other software. APIs replace the need for manual control – where humans used to click buttons in user interfaces, now bots proudly make the calls.
For the buyer on-boarding a TMS, it’s important to evaluate how detailed and robust the APIs are. This determines how long building integrations will take and how future-proof the setup will be. For the TMS vendor, it’s important to ensure all functionalities can be operated via the API, not just manually, and that the API is intuitive and developer-friendly. Any tiny little thing can influence decisions worth hundreds of thousands – sometimes millions – of dollars. Below is Nimdzi’s first summary of what TMS users look for in an API.
There are hundreds of possible integrations that can be accomplished via the API, and some of them have yet to be invented. The most popular ones fall into three broad categories:
|Content transport (CMS <> TMS)||Project management (BMS <> TMS)||Language tools (QA, QE, TMM <> TMS)|
|Automatically export content from the content management system into the translation system and import ready translations back. With frequent updates on a large scale, such integration can eliminate hundreds of man-hours of work.||Add functionality to project management, for example, invoicing and order management or CRM. LSPs often link business management and translation project management.||Complement translation editor functionality. Third-party CAT-tools improve the handling of concordance searches, the management of terminology, spell-checking and error checking performance, translation on mobile, etc.|
|● Frequently updated websites |
● E-commerce product catalogs
● Code repositories for software developers
|● Enterprise procurement systems linked to translation systems |
● Portals for translation ordering <> TMS
● Client relationship management systems (CRM) <> TMS
|● Correct errors in a third-party quality assurance and evaluation tool (Xbench, GlobalReview) |
● Publish terms on an enterprise terminology portal available to thousands of people
● Use translation memory server functions in a new editor
We’ve analyzed lists of API requirements in tenders from the enterprise buyer side and talked to five companies on the vendor side. Most of their requirements loosely fit in the above framework. Beyond a core set of controls, TMSs offer various unique APIs functionalities:
The list of unique functions is extensive – just for the 5 mainstay systems, the list of endpoint is 400+ items long. When comparing APIs, users evaluate whether specific controls are present, but overall best practice is far more important to them. For a technology company, it is fairly easy to add an API call on request. However, changing the approach and revamping the documentation is not something that can be quickly done.
Technology companies find it very useful to have their APIs evaluated by a third party. This is the best way to make sure that you are getting an unbiased opinion of your technology and to see how it stacks up against the competition.
Nimdzi\’s technology research team works with companies on a regular basis to better understand their own technology and their place in the larger industry.
Here is an aggregation of user feedback that we’ve collected:
Whatever can be done manually should also be available for automated operation. It’s often the case with TMSs that APIs are developed after the manual controls, so there is a “technology debt” that developers need to catch up on.
If every component in the system is developed as a freestanding API first, then issues would be found very quickly by the TMS company instead of just the few users that actually use the API for their particular purpose.
Translation traffic going through the API may contain confidential information, so it needs to be encrypted. For instance, traffic can go \”https/TLS\”, but additional security measures might be necessary for the enterprise.
This means that the API and the TMS can handle large files, or thousands of small requests per second, and can instantly respond. This can only be found by testing. However, some systems offer status pages that track latency and issues in real time (for example, \”https://status.smartling.com/\”).
Is one license for the API user-sufficient or for every \”end\” user using a service build with the API? Are there limits for the number of API calls per day?
This involves real-life examples of requests and responses, meaningful error codes, forums and QA tools, easy access to the docs and an easy-to-follow change-log. Mainstay TMSs use automated tools that detect new APIs and add them to documentation – primarily Swagger tools such as ReDoc – but they do not always offer support for community and discussion, or subscription to updates.
A granular search API (with scripting to slice and dice the data in many ways) would be very beneficial. For example, it’s common to see a project and client-search API, but not the endpoint to get a list of projects-by-client. For language integrations, powerful segments, concordance, terminology, and translation memory, lookup is a must.
Batch operations are also referred to as \”multi-gets\” and, \”multi-updates.\” Not having the option to instantly get multiple users by ID or multiple projects by ID may be a serious bottleneck during integration.
Some APIs return too much information which needs parsing. Having the ability to select only a few fields for the output increases usability and performance of integrations, making them “cleaner.\”
If APIs allow changing source and target languages after the project creation, this would be an advantage over systems where such changes are impossible.
TMS developers look outside the industry when developing APIs and follow practices set by tech leaders such as Stripe, Slack, and Zendesk. The general direction is towards the REST standard, which replaces modular APIs with a longer list of shorter endpoints:
However, following REST standard does not result in any uniformity in actual syntax or terminology. For the users, the lack of standardization in APIs means users have to start from scratch when they connect to each new system. A lot of effort goes into multiple integrations – effort that could be well applied elsewhere. In the comparison below, four systems use a different syntax for the same function to delete a project.
Here are a few examples of terminology inconsistencies:
GALA association has attempted to standardize APIs via the TAPICC project, but so far none of the mainstay TMSs have even begun to change their documentation, and the initiative has been around for two years. Commercial providers that must deal with multiple TMSs, regularly build adapters for this purpose. For example, two LSPs, Gemino and Kaleidoscope, have created internal middleware to call different TMSs with a single API.
As the translation process becomes more automated and users operate systems increasingly through API (and not manually via user interfaces), TMS developers need to adapt their whole approach to system design.
Perhaps in the future, there will be no need for a translation productivity tool to cover every conceivable need because this could be done with a set of integrated components. There won’t be a need for so many buttons in the user interfaces since PMs won’t manually handle projects, and beautiful reporting dashboards can become a thing of the past thanks as statistics data that can now be fed into a third-party BI tool such as Tableau with a much more robust functionality. CRM components for LSPs can come from something like Salesforce or Pipedrive, and in small teams, task management can go through Trello. In a similar fashion, every component can be replaced, taken from an outside system.
TMSs might need to adapt their pricing. Today\’s most popular model (to charge per user) is under threat of automation. With fewer people in the system and more work done through APIs, technology companies might need to start charging per API call – or risk losing profits.
Competition is fierce in the Translation Management System (TMS) arena, with dozens of providers duking it out to win over clients.
One of the main reasons for implementing machine translation (MT) into localization workflows is that it saves money. And time. This time, let’s focus on money. In particular, cost savings.