During the SLV era (or “cottage industry phase”), customers dealt with one or more single-language vendors (SLVs), with their in-house translation departments or with both. The SLVs sometimes had translators on staff, sometimes engaged freelancers and sometimes farmed out work to smaller translation agencies. As a result, there were often two or three layers of management for any one project: the customer, the SLV and the small agency.

During the MLV era (or “industry consolidation phase”), many SLVs were merged into larger multi-language vendors (MLVs) such as Bowne Global Solutions, Lionbridge or SDL. Customers with multiple-language requirements could then choose a single MLV, rather than deal with several SLVs. However, this did not reduce the layers of management because the MLVs often contained two layers of management: the global project Management team that dealt with the customer for project analysis, file preparation, etc., along with the local (in-country) project management team that handled the translation into the local language.

In fact, in some cases, the layers of management actually increased (up to as many as five layers with customer, MLV-global, MLV-local, SLV and small agency.) because some large customers preferred to use several MLVs, giving each of them a certain number of languages, to keep them “on their toes” (i.e., forcing them to compete against each other in order to obtain better pricing). For these customers, the benefit was to reduce interaction with twenty or more SLVs to only three or four MLVs.

The diagram below shows the resulting supply chain. We had a content owner with content to localize. The localization process was, at least at a high level, managed by the content owner, with the work distributed to a mix of in-house personnel, large and small agencies, and freelancers. Agencies, in turn, often employed in-house personnel, smaller agencies and freelancers. The smaller agencies either carried out their work in-house or hired freelancers.

The Internet Era

Today, the Internet is changing the globalization landscape; it has provided both the impetus and the infrastructure for the development of global content. More and more translation work is distributed and performed remotely over the Internet. It is now easy for small agencies to reach translators anywhere in the world. As a result, it is no longer true that MLVs are large and SLVs are small. More and more small agencies are offering hundreds of languages or are specializing in a group of languages (e.g., Asian vendors offering all Asian languages under one roof).

The distinction between MLV and SLV is fading. The new globalization supply chain involves several vendors collaborating on the basis of the services and expertise they possess rather than on the simpler MLV-SLV model. For example, a multilingual localization project may now be handled by a small multilingual localization firm (with only a few project managers and localization engineers) that will outsource the translation part to a small multilingual translation agency that deals with thousands of freelancers around the world, as shown below.

The globalization supply chain is realized in many different ways in practice. Any technology designed to support the supply chain must be flexible enough to accommodate its many variations. For maximum efficiency – to allow translators, vendors and customers to collaborate easily – the following technology components are required:

• centralized linguistic assets (translation memory and terminology)
• centralized workflow engine and project data
• a translation interface with remote access to the linguistic assets
• a management interface with remote access to the central workflow engine and project data
• a delivery mechanism to move the content (files or otherwise) between the customer and the various vendors

The benefit of centralized translation memory is that translators can collaborate in real-time. This can be the enabling factor when large volumes of text must be translated in a very short time.

The benefits of centralized automated workflow include shorter timeframes, process consistency and the sheer efficiency of significantly reducing management layers.

Globalization Management Systems

The features just mentioned are precisely part of Globalization Management Systems that we described in part 1 of this article

such as (in alphabetical order): GlobalSight Ambassador, IDIOM WorldServer, SDL Workflow and TRADOS GXT.

It would thus appear that a GMS is the technology solution for the globalization supply chain, but is it really? A GMS is an excellent solution for the global enterprise that truly wants to manage its content, notably because GMS vendors have built their systems specifically for such customers and not for language services vendors.

However, not all customers want to manage localization projects themselves, and not all customers are well-equipped to manage their linguistic assets. Thirty years ago, the question was: Should translation be outsourced or performed in-house? Now the question seems to be: Should translation management be outsourced or performed in-house? or, if you prefer: Where should localization workflow and linguistic assets be stored and managed: with the customer or with the language services vendor? Both options are needed, but clearly services vendors require appropriate technology to help with project management and management of translation memories.

In fact, roughly 90% of the services vendors I talk to report that they have had one or two technical people building their own in-house system for the last year or two… They were and still are building their own systems because nothing seems to offer the right functions at the right price. In particular, GMS have not been adopted enthusiastically by these vendors for a number of reasons:

1. First and foremost, as already said, the vendors were not targeted by the GMS developers (so the following reasons should not be considered mistakes made by the latter).
2. The fairly high price of GMS, especially for smaller services vendors.
3. Services vendors normally have expertise, processes and methods in place. Therefore, they are looking for software that will integrate and streamline their existing processes, rather than replace them. If it ain’t broke, don’t fix it; just improve it.
4. The lack of a standard delivery protocol between customer and services vendors means that if the latter purchases one GMS, then its customers must install the front-end component(s) of the specific GMS to monitor their content and deliver it to the provider. In short, a services vendor thus locks in its customers to a specific GMS and will be locked in itself unless it wants to buy more than one GMS!

Is There a GMS for Language Services Vendors?

It is in this context that TRADOS recently announced the Teamworks product. Teamworks is a project management tool that integrates with TRADOS TM Server, MultiTerm Server and, of course, with Workbench. It offers remote access to linguistic assets and project management functions and includes specific functionality for managing tasks (workflow), files, translation memories, etc. As such, it is the first integrated software suite targeted at language services vendors that meets almost all of the requirements of the globalization supply chain (it does not yet contain a delivery mechanism, but may have it soon; more on that later). One could call it a modular GMS for language services vendors.

To find out if Teamworks actually met vendor expectations, I interviewed Smith Yewell and Etienne Kröger, respectively CEO and Director of Global Production of Welocalize, along with Steve Desmeules, Managing Partner at ACCU Translation Services Inc. Both companies had evaluated Teamworks with positive results; however, neither company had yet deployed it, so I will revisit them in a few months to follow up and report on how things went.

Welocalize is a company with 52 employees that has been using TRADOS Workbench for seven years (both internally and with their freelancers). They have also built their own in-house workflow system to manage tasks, files, reports, etc. Yewell wants to move away from this in-house system, stating: “We are not a software company.” He wants his technical staff to focus on the technical problems of his customers, not the tools used to run the business. Many customers are moving away from in-house CMS (content management system) tools for the same reasons. Bottom line: developing good software tools is difficult, time-consuming and expensive.

Nevertheless, the new tool must replace most of what their current system is doing. Etienne Kröger explains, “The main competitor for Teamworks is our own internal tool.” Some of the features they would like to see in Teamworks include:

• a content delivery mechanism (customer connection)
• an interface to their financial systems
• a component to replace or integrate with their customer-facing portal (project status reports, an issue log, a knowledge base, etc.)

The main benefits that Welocalize expects to gain from Teamworks include better management of translation memories and files. Etienne expects a 10% savings on project management costs, over and above the savings provided by the centralized translation memory (which he estimates somewhere between 30% and 50%).

ACCU Translation Services Ltd., a smaller vendor with fourteen employees and more than 100 freelance translators worldwide, purchased TM Server last year and is now one of the first companies to have purchased Teamworks. At any given time, ACCU's two project managers deal with two to three hundred projects. Just as Welocalize, they expect benefits from better TM and file management. Inasmuch as they had no in-house system, moving to Teamworks is easier (fewer integration issues) and the benefits greater; they expect a 15-20% reduction in project management costs. Steve Desmeules was quite enthusiastic: “Teamworks will take translation technology to the next level.” This may sound like a TRADOS sales pitch but there is nevertheless some truth to it.

The Value of an Integrated Suite

The significance of Teamworks is that there is now an integrated solution available. If you use Microsoft Office on Windows, you already know the value of an integrated set of tools. Any manager knows that the simplest way to avoid problems is to have everyone employ the same tools. This is why ACCU Translations and Welocalize require their translators to use TRADOS.

So, the next level that Desmeules refers to is not a purely technological one (after all, the GMS are already there), but rather that, if Teamworks indeed succeeds, there is a definite possibility that TRADOS will parlay its dominant market share on the translator's desktop into a similarly dominant market share in translation teams and on the project manager’s desk (much like Microsoft went from PCs, to LANs to the enterprise).

The Value of Standards

So what, you may ask, is the value of standards, if we don't use them to mix and match tools? Standards allow us to migrate from one tool to another when there is a definite advantage in doing so. Standards allow us to mix and match tools when the situation requires it. But there is always a cost.

Standards are always imperfect or incomplete, imperfectly and incompletely implemented; tools always have bugs. When I ran R&D at ALIS, we not only standardized on a specific programmer’s tool set, but we also refused to let programmers upgrade to the next version of the same tool until the project was finished (we established this rule after feeling the pain of not having it). There is always a certain amount of friction between different tools, be it losing some animation effects when a new version of PowerPoint comes out, or loosing a few percent of translation memory leveraging due to segmentation algorithm differences, etc.

This does not mean that standards are useless – quite the contrary. Standards are precisely what reduce the friction between different tools; however, they must follow technology in an eternal game of catch-up in order to consolidate what has been achieved. Some standards may actually help Teamworks succeed in the market.

Translation Web Services

A case in point is Translation Web Services (TWS). If TRADOS were to develop a content delivery mechanism based on TWS (an open standard), it would avoid the lock-in effect already mentioned for GMS. It would in fact bring more work to Teamworks-equipped vendors. It would encourage more vendors to buy Teamworks and more customers to adopt TWS-compliant delivery front-ends. An interesting synergy between a standard and a product!

Stay tuned for what happens at Welocalize and ACCU Translation Services.

Pierre Cadieux is President of i18N Inc., a firm specializing in internationalization training and consulting for Web sites and Globalization Management Systems, shrink-wrap software and embedded systems. Pierre is Technology Editor for the LISA Newsletter and teaches internationalization at University of Montreal. He has been Director of Localization Technology at Bowne Global Solutions, where he published the first generic model of Web globalization, and VP Technology at Alis Technologies, where he pioneered the transparent handling of Arabic and Hebrew languages and created the core bidirectional technology licensed by Microsoft. Pierre also regularly presents workshops at LISA on CMS/GMS and internationalization and localization issues in general. He can be reached at pcadieux@i18n.ca.