Connect the connectors: Why Localization is in dire need of an upgrade


The concepts of globalization and Artificial Intelligence (AI) entered the mainstream at about the same time – not a surprise, as both were made possible by the technological revolution. When it became as easy and inexpensive to talk to a friend or business partner ­­­in Taiwan, and eventually, to a ‘virtual meeting’ with clients in Frankfurt, São Paulo and Austin, this world where we would buy and sell the same products, share the same values and all speak English seemed not far off. We could not have been more wrong. Politically, the world is more polarized than ever, and English has not become the lingua franca of the global business community.

While the notion of distinguishing between a ‘real’ meeting and a meeting in ‘cyberspace’ now seems a little quaint, the problem of language has not gone away, as witnessed by the steep rise in demand for Virtual Interpreting Technology (VIT).

We are on the threshold of the AI revolution – although cynical minds point out this revolution has imminent for a long time: Stephen Spielberg’s A.I. Artificial Intelligence came out in 2001. Much more recently, the hubris of Silicon Valley was given a knock when several AI start-ups admitted that they had used plain, old-fashioned human skill and intelligence to do tasks for which they gave AI the credit in their glittering publicity. 

Just as people resisted globalization, they also defended the inheritance that is their language. Words could not be seen as currency ­­– you exchanged one for the other at a certain cost ­– but they were cultural markers that belonged to a time and place. You had to preserve this rich cultural element by localizing.

To what extent that happens, or can really happen, is debatable. The sheer volume of content produced, and the many ways this content has to be delivered, means that this effort of localization has to be managed on an industrial scale ­– by technology in other words.

There are as many Translations Management Systems (TMS) in the world as there are spoken languages – not true, this is false news. But it certainly feels like it sometimes.

All this represents a considerable financial and organizational headache for companies. It is by no means exceptional for an average multinational to employ as many as 10 people responsible for translations with often more than 3 Language Service Providers (LSPs) to support their effort. The sheer cast involved makes the process difficult to manage, to say nothing of the technological challenges.

It is widely assumed in the industry that the men and women in charge – the Localization Managers – must be ‘good at languages’. But that seems to be a cliché too far. Research from the localization advocacy group Nimdzi shows there is a (slight) negative correlation between multilingualism and successful localization management. Success is about being able to understand and dominate the technology.

It is the contention of this white paper that this is becoming increasingly problematic. The process of localization and the technology to make it happen are extremely fragmented. Vendors have been quick to paper over the cracks. Localization Managers and IT had to keep the show on the road, and so connectors to integrate disparate systems were bought or developed by the truckload. And this strategy ­­– if you can call it that – of living from hand-to-mouth with ever more systems and applications talking to each other by means of connectors, has not been seriously reexamined since the late 1990s.

It’s time to reconnect.

Fragmentation: the power of connectors

Connectors are widespread because they meet a need. If you are a software engineer in charge of a multilingual fashion webshop with many thousands of items in stock, you do not want to do a bunch of manual exports every time you launch a new range of converse or add another T-shirt to your line. With a hundred such updates every week in several languages, the name of the game is to integrate your TMS with your Product Information Management (PIM).

Your colleague in marketing wants to send 20,000 emails to your customer base in the Netherlands, the Nordics, Germany and the UK. Ideally, she would like to translate the email from English but that would mean setting up additional five campaigns to a tight deadline on an even tighter budget – and anyway, everyone in Holland and the Nordics is fluent in English, right? But with a connector between your TMS and your marketing software – off the shelf, it’ll set you back just $4,000 – these multilingual mailings become plain sailing. And guess what, the email conversion rates in your supposedly bilingual Danish market shoots up because even a ‘localized’ lingua franca is never as persuasive as your native tongue.

Perhaps the sailing is a bit too plain… There is never a problem because there is always a connector. And if there isn’t, you can have one built for $10,000. This wouldn’t be a big deal if you had just one Content Management System (CMS) to integrate with your TMS. But the reality is most businesses have two or three. And it doesn’t stop there. You have machine learning software, business management systems, memory banks, online repositories, technical document archives, marketing automation and help desk applications, not to mention InDesign and YouTube – and all need integrating with the localization process. That’s a lot of connectors to buy, develop, maintain and replace (because you can’t patch or update them). Every point-to-point connector does a single job – just one – in a process that has a 1,000 steps. The result? A crisscross of connectors that holds the localization process together with loose pieces of string.

This fragmentation of the localization architecture – more about that later – is not the fault of the vendors, although it is very much part of their business model. If a connector does a single job, you get to sell of a lot of them. Once a connector is in place, you cannot then ask it to do something else. You get another connector ($4,000), or you have the existing connector re-built to your specifications ($10,000). Vendors are in no hurry to change this state of affairs.

So what appears to be a “lean and agile” approach at first glance is actually very rigid. There is less freedom, less flexibility – all the more so as connectors tend to lock you in with a specific TMS, typically the TMS with the greatest range of connectors. But you may prefer another, perhaps smaller translation management system, which doesn’t integrate with your marketing software, or your CMS.

That is the paradox of connectors: they are not inter-connected, there is no structure, no architecture, and yet the overall effect is one of constraint, limitation.

As the discipline of localization matures, its cadre is getting more savvy and demanding. They want to add functionality, cut their budget, use the TMS they like and simplify their integration architecture.

Re-strategize your integration

Architecture is a misnomer, not to say downright misinformation, because connectors give you no such thing. Connectors are built on loose sand. They were never intended to impose what you might call an architecture on the process. Connectors were a quick fix to a problem that becomes too lucrative to solve.

To have an integration strategy at all, you must have an integration architecture – or the ambition to impose one. You need this architecture to overcome the inherent limitation of point-to-point connectors – that you can’t ask them to do more, that there is no room for added functionality.

Just as the localization process reaches the tipping point where the crisscross and cluster of connectors is becoming unmanageable, and actually impeding best practice, Localization Managers are under pressure to deliver on complex new functionalities in the fields of automation, continuous localization (almost in real-time) and in-context localization, where translators or reviewers can translate/redact content directly on the channel for which it was written, a web page more often than not.

New functionalities, new connectors. Without an integration architecture, you have to deal with each connector individually – and when we say ‘deal with’ what we mean is rip out the connectors and start over. Localization managers are struggling to make the business case for this scorched earth approach to (re)integration – although the arguments for better automation, and continuous and in-context localization are irrefutable. Everyone in the organization with localization challenges knows these new functionalities exist and look to you to roll them out. What to do? The pressure is on.



The game changer

Connectors are necessary. The system that can do everything will never be developed – many have tried, all have failed. But without an integration platform or architecture, connectors are holding you back. More than that, they are subtly and corrosively imposing a way of working on you, when of course it should be you who’s in control.

Xillio API is a middleware solution that gives you the integration platform to leverage your connectors. No more piecemeal, crisscross, hand-stitched functionalities – with Xillio API you can add features that will work on all connectors. One change, many changed connectors. It can do this for a reason that may seem counterintuitive to many localization managers: by breaking the link between the API and the connectors. Xillio API interrogates the source systems and queries the new functionalities, which it writes on all the required connectors. The connectors are still doing just one job, but not the same job as before. The new feature(s) have been added.

To add the functionalities your co-workers want and your peers are implementing, you have the choice of either changing your connectors one by one or add the features once, in Xillio, and keep the connectors that you have. This white paper is not the place to discuss the nuts and bolts of a business case for Xillio API, but it is obvious the ROI is there, just from this single benefit.

A benefit that is more difficult to quantify in terms of ROI is the automation of the localization workflow – but this is also a game changer as we shall explain in the following section.

Automation: no more jigsaw localization

Even though lack of content automation and increased fragmentation slow down the localization process and make it much more prone to error, the problem is not on the radar of most organizations. Why? Probably because this toing and froing of valuable content happens at a very low level within an organization, and in different business units, different buildings, even different countries. But just because a task is menial does not mean it’s cost-free or without risk.

The Xillio API turns the jigsaw of systems and processes into an automated, 360° experience, where the copy can be selected, translated and seamlessly saved back in the right language website from a single platform. This prevents errors, increases traffic in and out, improves the end-user experience and gives localization managers much greater control of the overall process.

Such automation is immediately transformative. But Xillio API also has what you might call a strategic upside. We shall turn to that now.



Use the TMS you want

We saw earlier how point-to-point connectors can lock you into a particular TMS, because this TMS happens to connect easily with the systems you have in place – in practice this means the larger systems with more market clout. Whereas the TMS that you would like to use is out of reach because it does not talk to or support all the (many) content repositories involved in the localization process.

With Xillio API this problem disappears at a stroke because the middleware communicates with all content sources in your organization through one API. Even custom systems can be connected through the same API.

Localization managers will prize this flexibility, Purchasing will see the potential to avoid integration costs for other content-hungry business applications and Senior Management will sit up and take notice because M&A just became a lot easier. After an acquisition, it typically takes up to a year to migrate acquired content management systems into the existing TMS. With Xillio API, such a migration is done and dusted within weeks.


The business of localization, and the technologies that support it, have historically been very fragmented. Both the Language Service Providers and the Localization Managers they support are realizing that to reach anything like maturity the industry needs to re-think its connector strategy.

The impetus for this change is technological, but it is also driven by a new generation of digitally native Localization Managers with a confident, customer-facing vision of their discipline. It is up to them to make this vision happen.

Download this article as PDF

Why Localization Managers need to upgrade their connector and integration strategy


Request Information