In just the last few years, the term Globalization has become a household word around the world. Just what is Globalization? Most often, the term is associated with the globalization that periodically appears in the news stories. This is economic globalization. Economically and in other ways, the world is shrinking, becoming more interdependent. We are witnessing the emergence of the Internet, global communications, global travel, global village, global ―almost stateless― corporations, intertwining of the world's economies, blurring of national distinctions, challenging existing legal structures, global e-business, etc. Whatever one's views on the subject of economic globalization, several facts are clear:

• It is now a fact of life.

• It is here to stay.

• It is changing forever the world, as we know it.

• It is ever more evident.

• It is changing the way we do business at an increasingly faster pace.

In fact, 94% of CEO's of major US corporations have agreed, "Globalization is THE most important trend..."

Bottom line: Economic globalization is basically about the bottom line ―get used to it!

But globalization also assumes worldwide communication. Worldwide communication assumes language.

Despite the proliferation of English through commerce and US pop culture, not all users of software speak English. Not all speakers of English as a second language throughout the world are able to use the language efficiently in their work. Some know just enough English to be dangerous! Nor would all even prefer having to use English to accomplish their daily tasks. This is particularly true at the end user level. In fact, somewhat of a backlash to English has been noted, even in some traditionally English-friendly countries such as Germany and Israel. In other words, despite the advance of economic globalization in all its manifestations, national language identity remains alive and well, often for very practical reasons. As one German customer recently told us: the user should be able to use the product seamlessly in German, and not have to go through a translation exercise in order to utilize the output of a particular application. In a real-world business environment, all users need to understand application output, accurately and in real time, and not just those who happen to be initiates into the English language.

We are witnessing trends within the software user community that underscore these conclusions. Given the increasing level of automation within the industry, emerging hands-on users are increasingly unlikely to have sufficiently strong English skills to justify an English-only deployment in some environments.

The following statistics provide context. Global Reach, an international marketing and Web site promotion service, broke down the world's native speaker online population by language zone as follows:

For further details, cf. the Global Reach site at http://global-reach.biz/globstats/index.php3.

Clearly, "English only" is no longer the right answer!

Among other things, all this means that globalization is more than just a buzzword. The focus of Internet marketing, e-business, and e-commerce is shifting from the US market to a truly global economy. It follows then, that such a marketplace also demands that software be tailored or "globalized" to support key non-English markets.

So just what is software globalization? The short answer is making software products run anywhere. In our context at IBM, it means making applications work seamlessly, regardless of the user's language and culture. Globalization is all about choices: it gives the user the choice to use the original US English version of the product, or in fact, any of the other supported languages.

Software globalization must start well before the translation phase. It begins with the very design (as opposed to retrofit) of software to allow its use in non-US locales. Known in this connection as Internationalization (I18N), product developers must deliver designs that allow for such features as selectable date and currency formats, as well as dynamic resizing of buttons and boxes. Users must be able to input, view, and print data using their own character sets. It must also address different character sets such as ideographic (also known as Double-Byte Character Set or DBCS) and simple text (Single-Byte Character Set or SBCS). Complex text languages (BiDirectional or BiDi) such as Arabic and Hebrew must likewise be seamlessly supported. Observance of local government requirements must be factored in, such as the Chinese government GB1830 certification character set standard. Another example is the Québec Law 101 that makes French the language of education, work, and business in Québec. Absent such compliance, the product cannot be sold in the country. It is as simple as that. Unicode™ support is also a must at IBM. In fact, IBM applies an entire set of globalization-related product design or NLS (National Language Support) enablement requirements. Any deviations are subject to approval. These internationalized capabilities are built into the initial design for a simple reason: it is far less expensive and disruptive to do so from the outset than to go back later and retrofit. Some companies have had to learn this the hard way. Internationalization then, is the process of producing a product (design and code) that is totally free of any dependency on the language, script, culture, and coded character set.

Strictly speaking however, an internationalized product is not usable in any region of the world unless it is localized to that specific region. It must also speak the local language in every sense of the word. With a solid foundation of internationalization in place, it is relatively straightforward to then "localize" into the desired language. Localization (L10N) is the process of adapting an internationalized product to a specific language, script, cultural, and coded character set environment. In localization, the same semantics are preserved while the syntax may be changed. Localization goes beyond mere translation. The user must be able to not only select the desired language, but other local conventions as well. For instance, one can select German as a language, but also Switzerland as the specific locale of German. Locale allows for national or locale-specific variations on the usage of format, currency, spellchecker, punctuation, etc., all within the single German language area.

This simple equation is used to put these processes into context: G11N = I18N + L10N

Today's global economy is unthinkable without software, specifically software that supports multiple languages and locales simultaneously.

As part of the development process, IBM early recognized the importance of its presence in foreign markets. Software that is available in the user's own language and runs on a localized operating system provides a great convenience to the user and represents a huge competitive advantage. Given the predominance of languages other than English, it just makes good business sense to address those markets.

As a pioneer in the field of both economic and software globalization, IBM has always emphasized products that can be used worldwide. The reason: the majority of IBM revenue is generated outside English-speaking countries. Multinational companies want uniform solutions that can be used worldwide. In some countries, laws leave no choice to those who want to do business there.

The IBM vision sums up our approach to software globalization: "A user can access a server from anywhere in the world, using a client in the language of his or her choice, work with applications and interact with other users in the language and cultural conventions of choice." This direction is implemented in the strategic objective to deliver comprehensive, consistent solutions to meet worldwide customer requirements.

In turn, this vision drives a set of baseline requirements aimed at delivering consistent end-to-end solutions in a set of languages with cultural support. These include globalization architecture requirements and worldwide availability of all languages, generally simultaneous to the US English product release.

Current implementation of globalization covers several aspects. First, we will discuss specific elements such as processes that we have in place and the tools used to execute them. Then we will address the people who really make globalization happen, the project teams.

IBM translates millions of lines of product information every year at more than 30 translation centers around the world. This infrastructure has evolved over a 25-year period to meet a growing demand for good quality localized software. As a true pioneer in the field of software localization, IBM was quick to recognize the need for this kind of translation, altogether different from traditional documentation translation, and to put into place the needed processes and guidelines.

IBM's process includes a central clearinghouse for incoming source files. Before being released to translation worldwide, all material for translation must undergo file quality checking. Translation memory project folders are created and an English-to-English word count is performed to derive the delta.

Two key actions by developers have direct bearing on translation cost: communicate early and often with the translation centers, and select appropriate authoring tools. All files sent to our translation centers must be verified against a set of internal tools to ensure that they can be translated without errors or unnecessary expense.

We take pride in our planning and interaction with other teams to make sure that the translation centers are not surprised by source files arriving late, unannounced substantial volume increases, file errors, and unscheduled shipments after user interface or documentation freeze. A reporting system is also in place to make sure that we can quickly and efficiently communicate with all software localizers regarding any questions on the source material. Answers to those questions are broadcast to the originators as well as to all the other translators involved in the project. This prevents those same questions from being posed again.

Early in the planning cycle it is important to identify translation assets already in place. These include determining the availability of any English source (from earlier versions of this product or other similar products) that can be reused, and the availability of applicable translation memory. Another consideration is whether source conversion will be necessary (for multiple outputs). Finally, this is also the time to identify any new terms that will be used in the product. All too often, terminology is left until very late in the development cycle, causing increased costs or delays. We have in place a terminology process that describes the tools, process, and responsibilities for handling terminology and ensuring the availability of approved glossaries to all translators.

One of the vital elements in this localization process is the use of TranslationManager, a proprietary translation memory management tool. Like other tools (Trados® Freelance™, Atril Déjà Vu, STAR Transit, SDLX™, only to name a few) quite popular among the members of the software localization community these days, TranslationManager has been developed by IBM for use in translating its UI (User Interface) and publications.

IBM TranslationManager is a Computer-Assisted Translation (CAT) system that automates repetitive tasks, freeing the professional translator to attend to the finer points of translation that require the judgment of an expert. TranslationManager helps accelerate turnaround time and save money in overall translation costs. It enables the translator to handle large volumes efficiently while eliminating much of the tedious routine work inherent in translation projects. TranslationManager supports single-byte languages, double-byte languages, and those languages with bidirectional scripts, such as Arabic and Hebrew. In bidirectional languages, the general flow of text proceeds horizontally from right to left, but numbers, English, and other left-to-right language text are written from left to right.

As part of the localization process, we perform a series of tests to verify the quality of the translated version. Globalization Verification Test (GVT) provides early verification of translatability and globalization enablement function during product functional testing, well ahead of the next step, translation verification testing. In a nutshell, GVT ensures that the source product works properly on a localized operating system. Later in the cycle, mock versions of the source product are used to check for truncations, corrupted characters, and space limitations.

As a final step, Translation Verification Test (TVT) provides the real test of localized version quality. This stage requires close cooperation by development team and translation testers. Ideally, this testing is performed in-country using the translated document. This is because it is difficult to set up a specific country's test environment elsewhere in the world. If the test is to take place in the country (a recommended Best-of-Breed practice), the tester must communicate the specific hardware and software needs early and schedule time to install and test equipment. On the other hand, if the test is to take place in the development lab, the lab developers must ensure that the appropriate test equipment is installed. Developers must also make sure that testers have a