This article explains the basics of APIs in the translation industry to translation practitioners, including translation company owners and localization project managers at language service providers. The theoretical framework may also be a useful primer for translation specialists working for software companies. We aslo define what’s the added value of BeLazy – or an integration framework – to an API.
What is an API?
API stands for “Application Programming Interface”. It defines a way to access certain software functionality through programming or scripting. The most typical use case of an API is automation. Usually, you can achieve the same thing programmatically as on a user interface. APIs have been around for a very long time, but their wide-spread availability was hindered by a number of things:
CORPORATE FIREWALLS
Restrictive corporate firewalls were the standard rather than the exception, as corporations want to protect their data. These firewalls were restricting non-user-interface-based communication. However, the scenario today is much better, the ubiquity of cloud systems means that corporations outsource the security of their systems, not only the functionality.
THE COMPLEXITY OF INTEGRATION
APIs were not particularly complicated to use in certain environments such as .NET or Java, but the invention of RESTful APIs in 2001 made them much easier to use if the development happened in a “simpler” platform such as PHP or Python.
SYSTEMS BEIGN SCATTERED
Systems were installed in corporate environments rather than in one single large-scale instance. Remember the days when email sending had to be configured in each and every piece of software? Today many corporate email systems are based on Gmail or Outlook365, and integrating with these email accounts is so much easier. Also, you installed CRM on your own systems (think about SugarCRM) – Salesforce, however, did not need to be installed, and thus managed to champion the API economy.
APIs not only connect different systems. They also drive the so-called microservice architecture, where every major function is implemented as a separate service, a black box, and APIs make the connections (BeLazy is also created this way). Implementing this is more expensive, but it makes error handling easier because you can isolate errors within services. But even in the pre-internet age, if you remember the old times, Trados Translator’s Workbench called the Microsoft Word APIs to integrate translation memory into the familiar Microsoft Word environment.
In the API economy (a term coined by Forbes in 2017), there are API-only or API-first tools. A currency exchange platform, for example, should be API-first, because you take the exchange rate information to perform a conversion, a mathematical calculation. Any computer system with knowledge of the exchange rate can automatically do this calculation for you and improve your user experience. Thus integration with this API improves user experience, and automates the conversion process.
What does an API do?
An API performs specific actions on a certain system. For instance, you can use the API to instruct Google Sheet to create a new line in a sheet. Sounds easy enough, no? But what happens if:
Your username and password combination is not valid, and thus Google cannot find the user.
The Google Sheet that you are trying to access at a certain location has been moved to another location, so it simply does not exist where you want to access it.
The sheet does not have the tab that you want to write a new line into because somebody else has changed its name.
The sheet is protected and cannot be edited.
These are just a few examples of the obstacles we may encounter. The API would attempt to create a new line but would throw an error message if it fails to do so. As a developer, you need to prepare for exception handling – which means addressing each possible problem with a specific solution. Do you want to favor automated actions or do you prefer an interface where the user can make decisions? Bear in mind that interfaces are pretty expensive to implement. On an interface, the user could enter characters that are forbidden in the Google Sheet’s name field, or paste a string that could potentially generate a security breach in your interface, thus exposing all the different Google logins… Every functionality needs to have exception handling at all times, and that’s why it is laborious and thus expensive.
The API returns with information about the success of an operation and possible reasons for failure, but all these failure situations need to be handled one by one. This takes time.
If you are connecting to multiple systems using APIs, many of the possible reasons for failure may be the same. You might want to only implement the error handling once, and connect it to the failure messages of the different APIs.
Why is BeLazy more than an API?
BeLazy is an integration middleware. We analyze the systems we connect to and prepare for every single situation. It has been tailor-made to help companies within the translation industry connect vendor portals and translation management systems to business management systems.
At this point, BeLazy only offers added value to enterprises (“translation buyers”) if they work with multiple translation management systems. However, we can provide much value to language service providers, both to those working for other language service providers and those serving end customers.
How do we prepare for different integrations? We understand that business management systems like Plunet, XTRF, or all other systems can be similar but are not identical — the details and philosophy differ significantly. For example, in XTRF “Specialization” is a built-in field, it assumes that translation pricing may differ whether you charge for a general text or a medical text. Plunet does not take this for granted; in their system, this is one of those fields that can be renamed, changed, etc.
Language codes can also be different. You might want to have a language like “Spanish (Latin-America)”, which we all know that it does not exist – there is no lingua franca there, especially when it comes to slang. However, for medical device translation purposes you might not want to hire 10 translators, and you simply create a language like that. What’s the code to this? ISO standards don’t contain a code for something that does not exist.
However, it may not be only you that has a language for “Spanish (Latin-America)” which tells the translator to avoid local flavors. Your customer may also require you to find translators for this language pair. Their system may include language codes like ES-LA, or ES-419, or ES-INT. You need to know what’s the equivalent in your system, and you can never be prepared for all the language codes for all your customers.
Imagine you are using a business management system that offers various text fields, but it does not provide a field for the technology you may have to use (it could be a project in Across, Trados, memoQ or it’s an online tool you need to use like Lingotek.) This is critical information for your customer and you want to see it when you open the project in Plunet or XTRF. We made some arbitrary decisions on where to locate this information because if it’s in just one single place it’s enough for reporting, and people can easily see it: conventions matter, but usability even more so. This is one area where we made decisions on your behalf: we don’t allow you to map this to specific fields as that would make the configuration too complicated.
Another area that we allow you to configure is the service or workflow or order template selection: you may want to create a project with a different workflow if your customer asks for TEP (translation, editing, proofreading) or translation only – one requires three pairs of eyes, the other one may require one or two. We allow this selection, because it’s your decision how many people you want to pay.
BeLazy does the majority of the error handling and the mapping for you. If you are using Plunet or XTRF, which are the two business management systems we have full support for, at the moment, we cover every single scenario. If you are using your own proprietary system for business management, we simplify error handling and mapping, but cannot fully eliminate them. For example, you may still try to connect to BeLazy with a non-existing user, then we can only give you an error message that the connection failed for authentication, but we cannot tell you who’s your user. But if your system does not have a specialization that the customer asks for, you can use the BeLazy interface to change the mapping, saving you development interruptions. You still need to create an integration infrastructure in your system, but it is much simpler than integrating with individual vendor management portal APIs.
What about the updates?
Software changes. Business management systems – both commercial and proprietary – change. Vendor portals change as they add more functionality, or restructure the existing functionality. Even standards change over time. If you connect to ten APIs, you have to be ready as ten systems may be changing unexpectedly. If you use BeLazy and its APIs for proprietary business management systems, you might have to prepare for one.
The communication of changes depends on how close the APIs are to the users of the APIs: if it’s an important product of the company, you can expect proper communication, support, and follow-up. If the APIs are prepared by a development team that deals with many other things and communicated by a non-technical vendor management team, getting the right information on time may be complicated.
At BeLazy, we don’t only take over the implementation of an API, we also take over the maintenance efforts for users. While we cannot guarantee that every integration will work 100% of the time, we do proactive communication and contractual measures to foresee changes and we have the capacity to quickly implement the changes – thus we provide the best service to guarantee the highest reasonable availability of the integrations.
Additional functionality
An API enables certain functionality that may or may not be implemented in a solution. For example, the automatic approval and creation of small projects with reasonable deadlines and language combinations. While if you were to develop an integration yourself, you’d need to implement such functionality with all its user interface overhead and error handling, we take over this job as well.
We are also able to provide you additional interfaces. For example, you may integrate with your customers in your business management system. But would you be able to provide an Android or iOS app? We certainly can.
Integration without APIs
Most commercial translation management systems (like SDL’s products, memoQ, Across, Smartling or Smartcat) have published APIs: some are the easy-to-use REST APIs, others offer the older SOAP technology. Some allow access for every user, others only for administrators — which means for language companies that you can’t automate anything without the customer’s assistance.
However, very few language companies provide a full-fledged API for their vendors to operate their vendor portal (surprise-surprise, their APIs for their customers are generally better), and it is likely that those APIs lack certain functionality. For example, we found that one company’s API can return the nominal price (for example, 8.43), but not the currency (is it 8.43 dollars, euros or rubles? You simply can’t know!).
So the question is, if there is simply no documented vendor API available for a system, is automation still possible? Most likely yes. How come? There are not only published, nicely polished APIs. Web-based systems usually communicate with their backend systems (the actual database applications) through a set of APIs, because web applications are usually developed using different technology than backend applications, and APIs provide the linking. These are not documented, but through reverse engineering (fully legal) we can emulate that BeLazy is another web frontend to the same backend database. This is how we implemented most of our vendor portal integrations.
Given that these APIs may change, there is a slightly higher risk with such implementation, but given that these APIs drive the web frontend, it’s certain that we can somehow identify every piece of information that appears on the screen, whereas with the traditional APIs there’s a bigger risk of missing information. To mitigate the risk of changing, we go the official way: both XTRF and Welocalize, whose connectors we implemented this way, are made aware that we are using the internal APIs and they know that we need to be notified upfront to keep up with any foreseen change.
Even if this is not possible, there’s still a chance to capture the information by identifying the location of the information on a website and reading the values out. This is called web scraping, and we do this if the two API-based solutions (published APIs and internal APIs) don’t work. Web scraping is risky because if anything changes in the structure of a website, we have to immediately make the same change.
Note: In the following article, we will take a look at TAPICC, one of the industry’s most interesting initiatives.
