IBM holds a leadership position within the GILT (Globalization, Internationalization, Localization, Translation) industry. It also deals with massive translation volumes each year. Both factors, along with stringent budget constraints and internal mandates to save money and to do more with less, drive the need to constantly streamline and improve tools and processes. Those of you who attended our presentations at the recent LISA Global Strategies Summit in June already know that Tivoli Globalization realized 10 to 15% savings over the last few years compared to each previous year. Our costs dropped 35% in one year from 2000 to 2001 even as translation quantities increased.

Our costs dropped 35% in one year even as translation quantities increased.

How Did We Do It?

After our first year of translation, we sat down and methodically analyzed our costs. Where did the money go, and where could we be more cost-efficient? IBM globalization funds don’t come out of one big bucket, but rather from several sources, including Development, Marketing, Globalization, etc. For example, translation of documentation is paid for by the in-country marketing organizations, so this cost was not included in our analysis.

We have little control over our translation costs.

We also have little control over our translation costs. While that may sound scary at first, it really is not. Each globalization department at IBM works through IBM Translation Service Centers (TSCs) who manage and own the translation and linguistic testing aspects of globalization. Think of this relationship as one similar to that between a client-side localization manager and a localization service provider. We ask the TSCs to translate and test a project for us, they tell us how much it will cost us and - within limits - we negotiate the project’s parameters. The TSCs’ per word rate typically includes all aspects of translation, and is very competitive with current market rates. So, while we on the globalization side have little say when it comes to translation costs, we are in a great position to be able to work with very capable TSC managers who strive for uncompromised quality while minimizing cost, just like us.

Testing Was Where We Saved the Most

We reduced these costs through global-readiness testing.

The area where we were able to make the biggest difference was in testing. For most companies in the localization industry, testing is divided into two categories: functional and linguistic quality assurance (QA).

At IBM Tivoli, we found that the bulk of our linguistic QA costs went into labor, followed by travel and accommodations for testers. Contributors to high labor costs included:

• long test cycles
• build breaks
• paid down-time

We managed to reduce these costs by introducing global-readiness testing, which includes single-byte, double-byte and bi-directional character set localization/enablement to the globalization functional testing mentioned above. Owned by the development organization, the internationalization of the product is tested during this cycle with the use of mock or pseudo translations. Only once this testing is completed and problems including insufficient field sizes, formats, etc. are ironed out, do we start linguistic QA. This approach allows our linguists to focus on what they do best, i.e., language. Unproductive hours caused by build breaks, functional defects, etc. are reduced to a minimum, and best of all, we now receive our money’s worth for our QA dollars.

Next, we tackled the travel and accommodation costs incurred for linguistic QA. Especially after 9/11, visas for our testers were hard to come by, thus making planning and preparing for testing increasingly difficult. We made use of evolving technologies, including remote access to test machines, and added our own tools to support remote testing. Linguistic testers no longer congregate in one central place for the duration of the test, but remain in their remote locations and simply log on to our systems from wherever they are.

For file management, we implemented a web-based tool that allows us to check files into our source-control system from anywhere in the world. Testers now check in their own changes and merely have to notify the test lead when they require a new build, thus killing two birds with one stone:

• file handling is minimized and standardized, i.e. files don't need to pass through several sets of hands.
• all of our testers use the same process to check their files into pre-defined areas of our source control system.

The margin for human error is minimized, along with the time that would go into a non-automated file handling process. We use similar automated processes for defect handling, query management etc., and again reduce human error while maximizing our time- and cost-efficiency.

Enter the Localization Pack

Customers buy a product, not a “language version.”

Probably the single biggest contributor to our cost savings was the idea to de-couple localization from the base product, i.e., our introduction of the localization pack. The localization pack contains the localized software and help files for the English base product. It is installed separately, in addition to the base product. For most Tivoli products, the customer receives all available languages in one deliverable and then decides which language(s) they want to install, in addition to the English that is part of the base product.

When we presented this concept at the recent LISA Global Strategies Summit, some people in the audience raised concerns about giving languages away for free. They were used to charging their customers different rates, depending on the language version(s) requested. From a return-on-investment standpoint, this approach may make sense. IBM, however, has a significant portion of its customer base outside the U.S., in countries where English is not an official national language. Rather than approaching the issue from the perspective of the software publisher, we look at what our customers want. They buy a product, not a “language version,” and have come to expect to receive this product, if not in their own language, then at least in one of the major world languages.

Dutch and Deutsch are the same, right?!

Among the many advantages of the localization pack architecture is the fact that the development organization does not have to deal with the localization part of the product/project. Once it hands off the English software and help strings to us (Globalization), we are responsible for having the latter translated, built, tested and released to manufacturing. Since the localization pack is a separate deliverable, we do not need to worry about merging the translations back into the base product build. This relieves developers from having to deal with translated files, and once again, minimizes room for errors introduced into those files by well-meaning, but for the most part, monolingual developers. (Do hyphenating a German word in the wrong place, or corrupting Japanese characters into two single- rather than one double-byte character, or similar problems ring a bell? How about dropping some Dutch files into the German build since Dutch and Deutsch are the same, right?!).

The localization packs allow us to truly simship on the exact same day.

From a project management perspective, the localization pack concept is what allows us to truly simship at the exact same time, rather than within a 30-day period (or however many days) after the source product. Depending on the size of a project, the latest point in time that Development hands off its strings to Globalization is at the time that it hands off its first build to the (functional) test organization. Globalization thus has the entire test period to create and test the localization pack, thus finishing around the same time as the functional verification team.

Development does not have to wait for the translations to come back, and Globalization does not have to wait for Development to create builds to test. Since the localization pack contains only the language support for the product, our tests are not too time-consuming, and most defects found relate to problems that we can fix, i.e., they are not functional defects. In addition, we do not need to spend a lot of energy convincing the same well-intentioned developers that a language problem can indeed be a valid severity 1 defect.

The Real Secret to Our “Secret Sauce”

We save big localization bucks because internationalization is now part of the product design.

Lastly, and most importantly, we save big localization bucks because internationalization is now part of the product design. In other words, localization is not merely an afterthought, as it unfortunately still is in many other companies.

You have all been there: a great product is ready to be released to the local market, i.e., the country of its origin. A financial accounting application, for example, may contain clever algorithms to validate bank account numbers, forms to auto-fill in addresses and dates, snazzy icons to quickly access frequently performed functions, etc. It just so happens that some strings may be hard-coded because, for some reason, it just happened to work out better that way.

Everything is fine until Marketing announces that there is a foreign market for this product. Now that clever algorithm needs to be replaced by one that works in the new locale, the address format needs to be adjusted so it does not force entering a five-digit "zip" code but rather allow a four-digit plus two-letter “postal code” that appears in front of the place name rather than behind it, the date and time fields need to conform to international standards, and some of the icons may be completely inappropriate altogether and need to be replaced, or better yet, removed. The hard-coded strings need to be rewritten in order to be extracted for translation. The list goes on and on.

At IBM, we no longer have to deal with headaches like the above. Internationalization is now a mandate, and globalization receives buy-in from the highest management levels. Since we are provided with a good internationalized foundation, we do not have to retrofit our products when the time to localize comes around.

Looking closely at what we do and how we do it, what we spend and where the money goes, has made us successful in delivering quality products to our customers, while saving significant amounts of money and affirming our leadership position in the industry. We are, however, not done yet. Our tools are being further developed, and our processes further streamlined. Content management is becoming more and more important as the trend toward higher frequency, lower volume releases grows. Stay tuned!

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.