Why the language industry needs standard APIs and TAPICC

There are close to 200 translation APIs on the market, which at first glance looks like a marvelous box full of legos to build from. But only at first glance; scratch a little deeper, and you find a world of incompatibility and interoperability. The legos don’t connect, and you can’t really build anything without painstakingly filing them down to the correct shape.

Just like with differently shaped bolt heads, there is a frustrating variety of definitions in translation APIs - the same command to cancel a project is coded differently across 4 TMS.

Localization scenarios on both the buyer and the vendor side scream for easier integrations. For example: 

• continuous localization of websites and software
• Automated translation companies with CRM, TMS and CAT-tools working together
• for tighter collaboration of translation buyers and vendors.

Tough luck! Almost every case requires custom development and a hefty investment because of low level of connectivity in language software.

Moreover, should a company put integrations in place, they become a hostage of their own gigantic cost of customization. They can’t modernize aging components without re-developing these resource-consuming integrations. 

If only there was a way to plug-in components, and build freely, exactly like with the proverbial legos! Companies like TransPerfect have recognized this need as early as in 2010.

TAPICC launch

Around 2017, this need led to practical steps. A group of GALA association members came up with an initiative to advance API standards in the localization industry, called the Translation API Cases and Classes, or TAPICC. The experts formed a working group, and put their heads together to standardize XLIFF file formats and APIs to ensure operability between different tools. 

The idea was for TAPICC to become the single API for localization. Once you implement a universal interface, you won’t need anything else, and that ease of integration brings in a colossal economy in engineering effort. TAPICC’s working groups produced a charter and filled a Github repository with draft specifications.

 This initiative started as something really collaborative, community-driven, and open-source. 

Resistance from developers

They hit the first roadblocks when the GALA association offered draft standards to the industry’s key developers of content and translation management systems, like memoQ, SDL, Memsource, XTRF, and others. Developers didn’t rush to change their API definitions and apply standards right away. They either brushed off advances or refused point-blank saying that the re-work of APIs is a lengthy and expensive process and that customers need to request such changes. Every product had a long list of features to implement and bugs to fix, and TAPICC wasn’t prioritized over everything else in the roadmaps. Not unless someone paid for it.

In other words, developers wanted to pass the cost of implementing standards on their clients, and clients didn’t want to pay for open-source features that should be there naturally. The tug of war between them ended in a two-year stalemate with enthusiasts promoting TAPICC definitions at companies like Moravia and ADAPT localization center, and with developers of mainstream applications sticking to their old ways. The majority went with the RESTful APIs, and some like Plunet and XTM kept a set of SOAP APIs for a while.

The first practical TAPICC implementation realized by Xillio

Eventually, Xillio arrived in the localization industry and became the first application to implement TAPICC API, to pioneer its use in a practical scenario. We invested in this specification to show an example, and to demonstrate the viability of a standard API. 

Here is how we did it

Our motivation has been always to create language technology ecosystems.

In ecosystems, multiple developers can build complementary software, and buyers can get new features from many sources instead of waiting for years for their one vendor and being at their mercy in matters of pricing. For consumers of language technology, the ease of integration brings freedom of choice and independence. For creators of the software, this means more opportunities for innovation.

Tackle API standards and make progress in language automation

The language industry isn’t alone in recognizing the value of integrated systems. The financial sector has invested millions in streamlining their processes to simplify communication across organizations. In fact, corporations in many fields across the globe are working together to harness the power of connectivity, but the journey is far from easy. According to State of API 2019 report by SmartBear, many organizations struggle with API standardization, and this is actually one of the biggest developer challenges today. 

We hope the localization industry will be one of the fields that solve this engineering challenge. The mismatch of APIs cannot, and should not, continue. We call other developers to join in this effort to use standards, implement the specification in new language apps, and create awareness via blogs. 

But Xillio can’t do this alone. We need others to follow. And based on experience, we know that hardly anybody will do this. The engineering reasons are just the tip of the iceberg. The real reasons are a lot dirtier and can’t be put on paper. 

In order to create the critical mass we have taken drastic measures. We only allow partner technology companies to offer Xillio connectors through Tapicc integration. This solves a triple edge sword for us. We know that the technology player really is in favor of an ecosystem approach, we know they have modern technology and we are working towards a seamless translation chain. That leaves translation technology players 4 choices. Offer quality connectors to your clients without any down payment, start your own development efforts, rely on custom connectors from partner providers or ignore the need for connectors. We have 7 technology players lined up to follow Kaleidoscope and integrate through Tapicc. Not yet critical mass, but it is getting there. And we are just getting started. 

The standards will become even more important as language technology proliferates and new product classes start to hit the market.  For example, the European Language Grid project funded by the European Commission seeks to create a database of language technology with an environment that could make it easy to try, experiment with, and implement innovation. With 700+ systems shortlisted for this ambitious database, standardization is a key point. There is talk of a new EU standard for language technology APIs. Next, the national governments and agencies in Europe go multilingual, they will want an easy implementation of different technology. Standard APIs will be key in this effort.