In the year 2000, the World Bank started an ambitious project aimed at automating translation workflows. Now, 15 years later, the mission is still not complete. Why has technology not been a simple solution for such a common goal?

The World Bank initiative has been commendable from the very first day. It was designed to give the poor access to the World Bank’s analytical work in their local language. Project teams at the World Bank considered localization automation to be key. Since there is no revenue in empowering the poor and the cost of translation and translation project management can consume a lot of financial and human resources, the World Bank thought that localization automation could help reduce the cost to publish multilingual documents and shorten the time to publish them.

Why is it taking almost two decades to get this formidable mission accomplished? The support and the resources have been available. The World Bank’s annual report of 2003 specifically mentions the importance of its ”Translation Framework” as a central piece of their updated disclosure policy and proactive outreach programs. And the World Bank’s Supplemental Note on its Translation Framework, dated September 26, 2006, shows a long list of contributors and supporters of its plans, including representation from its Operations Policy and Country Services External Affairs, General Services Department, Information Solutions Group, Office of the Publisher and outside vendors. The paper shows agreement on critical issues, such as translation and production, budget planning and quality assurance.

Since then, The World Bank did reach a few great achievements in localization automation. It is also true that the institution needed over ten years before its efforts showed significant traction. I want to know why technology has not been able to help faster, and what we in the localization industry can do better.

There is no one-size-fits-all answer. Localization automation is still quite a feat to accomplish, even in 2015. The market simply does not offer solutions that seamlessly fit into an enterprise content workflow without heavy lifting from IT departments.

Take the World Bank’s current multilingual web content management system as an example. It is one of the very best that money can buy — hands down. But at the time of writing it does not enable automatic exchange of media files for localization and requires old fashioned, manual file transmission instead.

Shortcomings like that are the norm and can be tricky. They often lie in areas where one would least expect them. They can, therefore, easily go unnoticed until implementation. The list of inadequacies in workflow integration with translation includes the following examples (but is by no means limited to them):

Workflow solutions that do not allow for setting deadlines for tasks.

Translation review tools that allow quality assurance of translated documents either from vendors or internal subject matter experts, but not both.

Translation management tools that require HTML files to be uploaded to a content management server before they can be properly reviewed.

So, if you are in the market for translation-related technology, first and foremost make sure that it plugs into your existing processes. It’s often a trade-off. The best solution for translators and localization project managers may not be practical to implement.

Three of my team’s recent selection processes illustrate that very well:

A life science company picked one localization project management tool over another, because it required fewer IT resources to implement.

A nonprofit organization chose a multilingual web content management because it was programmed in Java, which the IT team could support best.

A software company selected an open source translation management system because the IT team disliked commercial technologies.

Your IT team is crucial in decision-making. In all of our selection processes for localization automation, it has always been IT that makes or breaks a choice.

The World Bank knew that, of course, when they started out in the year 2000. They even formed a technology selection panel with diverse stakeholders, including a procurement officer, project manager, customers and translators. But guidance from IT was not enough for them to make the best business decision. It turned out that financial viability of technology vendors had a huge impact on the institution’s ability to implement its plans.

The first product that they piloted was Globalix, a most visionary translation management tool by Alpnet. But the company failed and was acquired by SDL in 2002. The World Bank then bought a system called Ambassador by GlobalSight, one of the hottest localization technology companies at the time. Two years later GlobalSight was sold to Transware, which did not invest much time and effort in advancing the system. This did dramatically change when Welocalize acquired Transware in 2008. But the World Bank was in no position to wait and moved on to other solutions instead. One of them included MultiTrans from MultiCorpora, which was sold to RR Donnelly earlier this year.

The lesson from this story is that technical specifications are not as important to localization automation as a developer’s compliance with good financial practice and your existing IT infrastructure. So, start there first.