TAPICC is a pre-standard initiative—sponsored by the Globalization and Localization Association (GALA)—that seeks to tame the wild frontier of today’s CMS/TMS integration landscape. Moravia is “all in” with this initiative. Let me explain why.
The rise of CMS and birth of the CMS/TMS gap
When it comes to content management options, we live in a bit of a golden age. Thanks to the evolution of CMS starting around the mid-to-late 1990s, today there are more options than ever for creating and managing different types of content with a wide range of applications—publishing, creating websites, selling things, etc. It makes me wince when I think about how we used to manage content before the rise of CMS. (If you weren’t there, let’s just say it was very manual and process-heavy.)
This graphic from chiefmartec.com shows how vast and diverse the world of content management is today. Remember “Where’s Waldo?”
Unfortunately, the worlds of content management and localization/translation ended up evolving largely independent of one another, resulting in a disconnect that I’ve called the “CMS/TMS Gap.” You probably know this Gap if you have content management responsibilities that have anything to do with localization. The Gap reveals itself when you ask the deceptively simple question, “how do I get the content managed with System X translated using the technologies that are part of System Y?”
At one point in my career, and in the careers of quite a few industry colleagues, addressing the CMS/TMS Gap was a significant focus. It was a matter of necessity; without finding a way to bridge these worlds, the very content that was being so brilliantly and efficiently created in the CMS would drift further out of reach of the systems and processes that could localize the content, ironically making it less accessible. We all seemed to eventually gravitate toward a common model: integration by way of CMS/TMS connectors.
The model is based on a process of transferring content between systems, and typically works this way: a plug-in gets installed into an extensible-host CMS and creates an interface by which translatable content can get sent along to a receiving TMS’ API in the form of a project and “payload.” After going through the localization process (translation, edit, proof, etc.), the project then gets retrieved by the connector which distributes all the newly translated content into its appropriate places in the host CMS.
It’s a model that’s still used today. Do some web research and you’ll find that there are a lot of CMS/TMS connectors out there. I’ve certainly helped create my fair share of them.
So that’s a success story, right? Well, yes and no.
Today’s wild frontier
If you look more closely at the landscape of integration solutions, you’ll find that that there are about as many different types of implementation out there as there are CMS+TMS combinations. They have different definitions for what constitutes a project, what gets handed off, how content gets retrieved, how context is provided, etc.
It’s understandable. These solutions evolved organically and in isolation from one another, and their diversity largely reflects the heterogeneity of the CMS and TMS that they’re trying to integrate.
But collectively, this legacy has resulted in a significant amount of unnecessary variation—a problem for various reasons—that ultimately leads to waste, barriers to scale, and (perhaps counter-intuitively) lack of operational freedom. When components within an ecosystem aren’t interoperable, or can only be made interoperable through significant expense, the entire ecosystem suffers. Every dollar or euro spent addressing friction in the system is money that is not spent actually adding value to the content through localization.
A system integrator gets a translation project ready to go live.
To me, it seems like a bad situation for everyone involved. If you’re a content owner who needs content localized, your criteria for service providers is largely dictated by whether or not you can efficiently exchange content with a company, as opposed to other merits such as translation quality. If you’re a TMS vendor, you are already caught in the loop where you’re having to invest in the development of connectors for each of the dozens of heterogenous content systems out there. And if you’re a CMS vendor who needs to support your customers’ globalization efforts, you’re at the mercy of this wild frontier. Your platform is only as global as the integration solutions out there for it.
The mission of TAPICC
TAPICC stands for “Translation API Class and Cases” and was born out of the enlightened self-interest of the globalization/localization/translation industry. It’s a community-driven initiative that seeks to improve the interoperability between the various systems that are involved in localization and translation programs by applying some standardization toward the way they interact.
You can read the TAPICC project statement here.
The project has been organized into four tracks, the first of which focuses on the classic project handoff/handback scenario, and is being worked on by a collection of working groups each focusing on different aspects of the exchange (metadata, payload, API specification, etc.).
I’m actively involved in the project, as are several of my colleagues at Moravia. I co-chair the working group focused on the API specification, and my colleague Ján Husarčík chairs the working group focused on the payload specification. We’ve both travelled to conferences to collaborate on and evangelize the initiative.
For us, this is a “no-brainer.”
Moravia’s support for standards
At Moravia, we embrace standards if we believe they’ll lead to improved inter-system operability, because that ultimately means flexibility and operational freedom for our customers. The more we can easily and affordably integrate technologies, services, and systems into our globalization solutions, the more capable—and therefore more valuable—our solutions become. Everyone wins.
We adopt standards in the technologies we develop, we’re selective toward standards in the tools we procure and employ, and whenever possible, we help shape emerging standards.
For Moravia, seeing TAPICC succeed means that we envision the cost and effort of connecting any CMS with any TMS, or any TMS with any QMS, to be much less. We expect that by removing unnecessary friction in the supply chain, the entire system will become more efficient. We hope that the “integration question” eventually becomes a non-issue when it comes to adding, removing, or replacing components in the solution.
And that’s why Moravia supports TAPICC!
You can support TAPICC too
TAPICC is an open initiative, and you can be involved in various ways depending on your interests and ability to participate. You can sign up to join the main group, and any or all of the four working groups, which will give you access to those forums. You need to create a GALA account if you don’t have one already (it’s free).
You can also come meet the folks who are directly involved in the initiative at GALA 2018: Boston, March 13-16.
I’ll be there, so come say hi!