Tivoli Software is a brand within International Business Machine’s (IBM) Software Group division. We began translation of Tivoli products about seven years ago and now translate virtually all of our product offerings into at least nine languages (German, Spanish, French, Italian, Japanese, Korean, Brazilian Portuguese, Simplified and Traditional Chinese), and in many cases quite a few more. Our initial translation projects were fraught with the need for large amounts of support for the translation process from Development. In this article, the first of two parts, we will discuss how those projects were organized, the problems we encountered, and the solutions we arrived at to make management of the translation media easier for everyone involved.

A Bit of History

We continually pushed the limits of the existing IBM translation processes.

Tivoli was a comparatively small company making network management software when it was acquired by IBM in 1996. A team of relative novices was put together to manage the translation of Tivoli products, and we followed IBM’s translation processes and worked with their Translation Centers. One major difference between Tivoli and the rest of much of IBM at that time was that Tivoli was focused on delivering a simultaneous worldwide General Availability (GA) of an internationalized product and its localization. Many IBM product groups were still delivering an English product on one date followed by translated versions of the product several months later. Because of this, we continually pushed the limits of the existing IBM translation processes.

After completing a “one-off” Japanese localization of a previous release of the Tivoli product set that had been shepherded through translation by an IBM Tivoli lab in Japan, our first full translation project involved a complex product suite made up of nine different products containing a total of about 300,000 words into three languages.

Although Tivoli had adopted a sophisticated IBM source control system, we really did not have a process to interact with the system to manage the source and translated software and help files in-house. Instead, we counted on development teams to identify their source files for translation, to keep track of any changes they made, to deliver the files to us (or point us to the files on a file system after they had extracted them from the source control system), to put the translated files into source control, etc. A labor-intensive and error-prone process at best.

The Long and Winding Road

We knew we needed to do something differently to avoid a disaster.

Both during the main translation phases, and the linguistic quality assurance that took place on-site in Austin, we quickly realized that we lacked a consistent and efficient way to ensure

1. that we were receiving all the new and changed files that needed to be translated,
2. that we were receiving error-free translated files from translators,
3. that we were reinserting the translated files back into source control, and
4. that the files were in the required format before they were returned to source control.

After a long, trying, but ultimately successful, test, we were faced with translating the next release of the same product set into an additional five languages. We knew we needed to do something differently to avoid a disaster.

We were lucky in that the Tivoli products had been well-architected with globalization in mind by a very experienced, dynamic team of Internationalization Engineers who could lead us in developing a solution that would make life easier for everyone.

A Two-pronged Strategy to Introduce Automation

The strategy we developed was two-fold:

Our strategy supported a single, internationalized installable of the base product that includes English language resources.

1. To de-couple the translated resources from the base product so that they could be built and installed separately—what we call language pack or localization pack architecture. It is important to point out that this does not lead to separate national language versions of the product, but instead supports a single, internationalized installable of the base product which includes English language resources. Other language support is then installed as an addition to this base product, invoked either during the standard product install or as a separate executable.

A key part of this strategy is that it also allows us to deliver translated files to the source control system without worrying about breaking the base products’ builds, since it also posits a standalone build for the language pack (please refer to the diagram below).

We wanted to take care of the manipulation of translated files with automated tools and automate placing updated files into the source control system.

2. To develop a set of tools that would allow us to automatically work with source and target software and help files. We wanted to make it easier for the development teams to identify their translatable files and automate working with them. And rather than require a lot of manual manipulation of translated files by the translators, testers or developers, we wanted to take care of that manipulation with automated tools, as well as automate placing updated files into the source control system.

Winning Over Development

We first had to convince the development teams that it made sense to move to the language pack architecture. We did this by selling the idea that we could avoid breaking their builds and offload the major part of the task of working with translated files from them. In addition, the group of Internationalization Engineers was made available to create each product’s language pack. This also fit in with other architectural/design imperatives: (1) the ability to deliver additional languages in the future if necessary without re-releasing the entire product, and (2) the ability to perform linguistic quality assurance very late in the development cycle and still be able to obtain frequent builds of translated resources at a time when product builds were being created less frequently, etc.

Automating Source and Target File Management

All of these process changes and tools greatly reduced our overhead and simplified the tasks of working with the translated files.

Next, we had to figure out how to automate management of the source and target files. We decided to use the source control system’s ability to identify the files needing translation and to track the versioning of those files. We developed a tool that integrated other tools to perform error checking of the source files before we sent them to translation. It notified developers automatically if their files had errors that would cause problems for translation. We firmed up our processes for receiving target files, performing checks to make sure that the same files were returned to us as had been delivered for translation, and that file paths, names, etc. had not been changed.

During our initial translation project, we had asked translators to perform format modifications to the files before returning them to us, including converting files to the Unicode codeset, changing some code values inside files, etc. When this proved problematic and error-prone, we added functionality to our tool to perform all this processing automatically, so that our translators could concentrate on what they do best, i.e., translation, and our tool would do whatever else was necessary.

Our tool also performed error checking and test builds on the translated files. During linguistic quality assurance, the testers used this tool to deliver the files to us and would receive immediate feedback if their files had errors. Once error-free files were delivered, we would use the tool to check the translated files into the source control system, automatically performing any required file renaming, path changes, etc. needed for the build process. All of these process changes and tools greatly reduced our overhead and simplified the tasks of working with the translated files.

The next step was to adapt the tools and processes to allow us to perform linguistic quality assurance without having the testers leave their home country. We could realize further cost reductions by avoiding testers’ travel costs and the capital costs of purchasing and maintaining lab equipment and space.

Voilà! WebFM

Our original toolset was script-based and had a cumbersome installation and configuration process, and needed to be installed and configured on a local machine wherever testing was being performed. So we settled on an architecture for new tools that would allow us to have a single, centrally configured and maintained web-server that was accessible from anywhere within the IBM intranet. We call this tool WebFM, for Web File Management.

This is the basic architecture we use today, and more details about WebFM will be discussed at our session, Don’t Just Do It! Automate It and Save More Money, on June 23 at the LISA Global Strategies 2004 Summit in San Francisco.

What We Learned

To summarize the lessons that we learned:

1. Use localization pack architecture if at all possible.
2. Leverage the source control system to identify and track changes to files that require translation.
3. Try to develop some understanding of the translation tools used. Obtain training, if necessary, so that you will know explicitly what translators will deliver to you. This will also allow you to educate testers on the capabilities of the translation tools, if required.
4. Ensure that the translated deliverables meet your specifications.
5. Understand what you need to do to the translated deliverables, i.e., whether you will need to perform any format modifications, renaming, etc. for the files to build successfully.
6. Have a way to perform the tasks under number 5 automatically.
7. Make sure your processes and tools can also work during the linguistic QA phase.
8. Try to develop processes and tools that are not tied to a particular way of doing business. For example, you may need to allow for remote linguistic QA in the future.

Bonnie Bonomé has worked in the localization industry for the last 10 years. After obtaining her MA in Translation in Germany, she began her journey, spanning three continents and working for a number of the best-known companies in the industry. Bonnie currently devotes her time to Globalization Project Management at IBM Tivoli in Austin, Texas. She can be reached at bbonome@us.ibm.com.

Sushma Patel began her career at Tivoli Software in 2003 for the Tivoli Globalization Core Services Team. She is responsible for the design, development, and maintenance of the Tivoli Globalization Tools, such as Web File Management Tool along with a few others.

Lum Twilligear joined Tivoli Software in 1997. He has worked as a Translation Coordinator, Globalization Project Manager, and is now the team lead for Localization Engineering on Tivoli Software’s Globalization Core Services Team. Prior to working for Tivoli Software Lum was an International Student Advisor at The University of Texas at Austin.