Featured Article

Find a Translator or Interpreter
Search for:

Featured Article from The ATA Chronicle (August 2010)


What Technology Companies Won’t Tell You: The Truth Behind Integration
By Bob Donaldson

Elsewhere Translation Company recently decided to upgrade their technology infrastructure. They started by looking at their internal needs and external opportunities, developed a high-level requirements document, evaluated candidate vendors, and ultimately selected a package that fit both their budget and their needs. The future looked bright as they installed the new software on their servers, went through some preliminary training, and prepared for a new era in translation productivity.

That was six weeks ago. Today Elsewhere is beset by frazzled users, an overworked implementation staff, and unmet expectations on every side. Sound familiar? In an effort to figure out what went wrong (and perhaps more importantly, how your small company can avoid the mistakes made at Elsewhere), let’s start by looking at why they chose to go down this path in the first place.

The Case for Integration
The translation and localization business provides many opportunities for technological integration. These opportunities exist on both the client side and the vendor side, but the power of a partnership can serve as a benefit multiplier when client and vendor integrate processes and systems across company boundaries.
On the client side, many content management systems (CMS) provide some integrated tools for managing the translation process. For example, the CMS may support rules about when to translate new material and into which languages. As these systems are integrated with a translation memory system, the process of leveraging a new translation request and preparing a set of files to transfer to the vendor can also be streamlined. These tasks are both time-consuming and error-prone, so the return on this kind of technology investment is pretty obvious.

On the vendor side, the challenges of tracking hundreds of files from dozens of clients through the various stages of a typical translation project can be daunting. Add to this the complexities introduced by last-minute changes, internal quality assurance steps, client review cycles, and a dizzying number of standalone software tools, and the need for integration is obvious.

2 + 2 = 5

The client-vendor partnership unlocks potential beyond what can be achieved by either party alone. All integration efforts require some sort of partnership, but the greater the scope of the integration efforts, the more important the partnership becomes. The benefits, however, become even more pronounced as the scope widens. The technology available today makes it possible for a translation request to be generated and authorized within a client-side CMS. The CMS then kicks off an entire string of automated steps that extracts the text to be translated, delivers it to the designated translation vendor, automatically applies translation memory leverage, creates the project within the vendor’s translation management system, and assigns the translation task to a qualified individual translator. When the translation and any vendor quality assurance processes are complete, the translated file can be returned to the client where it is automatically placed back into the CMS and associated with the original source text. (Table 1 summarizes the tangible benefits to be gained through software integration.)

Table 1: Summary of Software Integration Benefits

  • Improves content reuse.
  • Reduces turnaround time.
  • Reduces translation costs.
  • Improves consistency.
  • Automates repetitive tasks.
  • Reduces “special case” processing.
  • Maintains control of language assets.
  • Protects freedom of vendor choice.
  • Focuses on value, not volume.
  • Automates the entire workflow.
  • Optimizes the entire workflow.


With this kind of promise, it is no wonder that Elsewhere decided to go forward with their technology integration project! So what went wrong?

Seven Things “They” Never Tell You

Every situation is different, but there are several aspects of the way technology, especially language technology, is sold that can easily lead to unmet expectations.

1. The Demo Problem:
Have you ever noticed how easy things look in a software demo? Remember that the salesperson has probably given that demo dozens of times. All the data fit the story and the story is not designed to raise any questions about the complexity of set-up activities. Mitigation ideas:

• Force the salesperson to discuss the overall philosophy of the product; ask questions that reveal hidden assumptions about how users work.

• Force the salesperson to demonstrate set-up activities. These can include data entry (customers, vendors, price lists, etc.), but also system configuration or “rules” that tailor the product to your situation.

• Schedule a “dummy” pilot before the “live” pilot. The point of a “live” pilot is to gain insight into how a well-configured system will support your actual workflow and workload. The point of a “dummy” pilot is to validate your assumptions about what constitutes a “well-configured system.”

• Make sure your entire organization plans adequately for the set-up activities.

2. The Standard Problem:
Whenever concerns about integration and interoperability are raised, the topic of support for “industry standards” is sure to follow. The problem is that very often the “standards” are not standard. By definition, standards such as XLIFF, TMX, etc., represent a consensus view of how to support standard functionality. However, tool vendors are continually striving to provide features that raise them above their competition. This often results in custom “extensions” to the standards. This has implications both internally (as you integrate multiple tools) and externally (as you seek to automate data exchange with your clients and vendors). Mitigation ideas:

• Make sure you get detailed documentation of the standards as supported in the package under consideration.

• Test interoperability during the “dummy” pilot.

• Find reference accounts with similar needs.

3. The Open Problem:
Another approach to addressing integration concerns is to tout the “open API” (application program interface). An API is an interface implemented by a software program that facilitates interaction with other software, similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions and is used to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API. With a complete, well-documented API, you can write custom code to integrate with existing software.
The real problem, though, is that while vendors may advertise an API, they may not have anticipated your needs. Furthermore, unless it is well documented and there is a commitment to long-term support, there can be significant “cost of ownership” problems in the future. Mitigation ideas:

• Force the salesperson to answer “what if” questions about the specific kinds of functionality you want to integrate.

• Insist on full API documentation before the sale as well as a commitment from the vendor to support the API in the future.

• Find reference accounts that have used APIs.

4. The Process Problem:
This problem is a two-edged sword. The vendor often suffers from the “what you ought to want” version of this problem. In other words, the vendor has done an excellent job of automating a set of processes, but unless you share the vendor’s assumptions, those processes may not fit your needs. On the other hand, the operations team often suffers from the “that’s not how we do it” version of the problem. This involves a stubborn clinging to processes that are no longer needed in the new environment enabled by the technology. Mitigation ideas:

• Get buy-in for change from key operations staff; do not try to automate obsolete processes.

• Force the salesperson to answer “what if” questions that reveal underlying assumptions about the process, and make sure you share those assumptions.

5. The Planning Problem:
Also known as the “Ready, Fire, Aim!” problem, this involves getting the implementation steps out of order, in particular the “aiming” (or “planning”) step. The challenges of initial implementation and system configuration are seldom discussed in the sales presentation. Therefore, it is incumbent upon the buyer to “count the costs,” including data migration, master data set-up, process documentation, workflow templates, project manager training, and vendor training.

6. The Timing Problem:
This is another problem with two sides, though the vendor will always be eager to sell “now.” On the one hand, it is never a “good time” to make technology changes. Things are always busy and there are always new technological advances soon to be released. On the other hand, it is always a “good time”; there is no time like the present to begin to streamline your operation and to begin to reap the rewards of better integration. As you struggle with this dilemma, consider the following:

• Focus on the long-term “big picture.” Where do you want your business to be in three to five years?

• Focus on incremental progress. Where can I get a near-term return on a relatively small investment?

7. The Excuse Problem:
This is a problem that cannot really be blamed on the vendor. Are you suffering from analysis paralysis? Or maybe you are having a crisis of confidence due to your company’s lack of internal technical expertise? Or maybe all the other things the vendor does not tell you are affecting your ability to decide and act. As the old saying goes, not to decide is to decide. Mitigation ideas:

• Get over it. Do not allow anything to become an excuse for inaction.

• Get help. There are plenty of other companies that are willing to share their experiences and a number of qualified consultants who can help you make the right decisions.

• Get moving.


Whether you think you can, or think you cannot, you are probably right. Do not allow the fear of following in Elsewhere’s footsteps prevent you from setting out on your own technology journey. The benefits of integration are there for those who pursue them.


Bob Donaldson is the founder of Carson Strategy Group, providing language technology consulting and project management training focused on localization. He also serves as the chief technology strategist for Text & Form, and is responsible for all aspects of language technology planning, evaluation, and implementation. Previously, he served three years as vice-president of strategy for McElroy Translation. He has over 25 years of experience in creative technology application, including executive management positions in a number of software companies. He has also served as a Russian linguist in the army, putting to use his educational background in Slavic linguistics. Contact: