Localization

Glossary

---

• Localization: The process of adapting a program for a local market, which includes translating the user interface, resizing dialog boxes, customizing features (if necessary), and testing results to ensure that the program still works.
• Levels of localization: The amount of translation and customization necessary to create different language editions. The levels, which are determined by balancing risk and return, range from translating nothing to shipping a completely translated product with customized features.
• Enabling: Altering program code to handle input, display, and editing of bidirectional or East Asian languages, such as Arabic and Japanese.
• Layout: The order, positioning, and spacing of text or other user interface elements.

World-ready core code is a basic requirement for software that will ship outside of your native country. You can vary the level of effort and expense devoted to localization, however, depending on the target market and the application type. (See Figure 1-3.) Some markets are currently comparatively small, so shipping a product there is considered an investment for the future. Other markets are well established, and breaking into them requires a large investment and a commitment to high standards. Still other markets are small, but growing rapidly. It is possible to establish a presence in small markets by shipping a partially localized application quickly and following it up later with a more fully localized edition of the same application or its next revision.

At Microsoft, subsidiary marketing managers decide the level of localization for each language edition of Windows. Developers and translators provide the marketing managers with an estimate of how much time and money each level will require. Then the subsidiaries and product teams decide whether the potential return is worth the cost. (For information on specific Microsoft localization choices for Windows, see Appendix V, "Localized Versions of Microsoft Windows.")

Figure 1.3 - Levels of localization.

The first two levels of localization listed in Figure 1-3, translating nothing and translating documentation and packaging only, involve little development cost-at most, developers will be called upon to explain technical issues to translators. The next level, enabling the code, involves no translation cost. The term "enabling" applies most often to software that was originally designed for European languages. Enabled software allows users to display and enter data in their own languages, even if the user interface isn't localized. Code for Middle Eastern, Indic, or East Asian language editions of such programs must be altered to handle input, layout, display, editing, and printing of text associated with these languages. (If you design and create a single world-ready application, it is already enabled and thus there are no extra costs). Screen savers, multimedia titles, and other programs that do not allow the user to enter or edit text do not require enabling.

If an English-language edition of your product exists, consider using it to test the waters in markets where users will buy a product with an English-language user interface until a fully localized edition is available. The following list gives some guidelines for determining the markets in which an English-language user interface is acceptable:

• Small markets (for example, Thailand, Philippines,and Indonesia)
• Markets where your product has no competitors
• Markets where the target audience speaks English (scientific, medical, and technology communities)

In markets where only translated products are successful, do a partial translation if you want to ship quickly or don't want to pay the cost of a full translation. As a general rule, the more involved the translation, the more questions developers must answer and the more bugs developers must fix.

In more competitive markets, you will need to customize features and, in some cases, add support for hardware that is sold locally.

The Localization Process

Glossary

---

• Globalized functionality testing: Functionality testing that has been enhanced to include verifying the world-readiness of a product.
• Beta testing: Distributing prerelease software to future users and potential customers in order to get feedback and bug reports.

The process of creating localized software involves a great deal of communication between different players on a product team. Figure 1-4 depicts some basic lines of communication and, when read from top to bottom, indicates a rough timeline for international product development. During the core phases, the development team provides files to the localization team, which translates text, resizes dialog boxes, and hands files back for compilation, if necessary. The localized executable then goes to the testing team, which reports functionality problems to development and reports user interface problems to localization. All three groups work together to resolve bugs, and the cycle continues.

The least painful kind of localization process is one in which the product team considers international issues during the initial feature design and coding design stages. Market forces, usability tests, and development constraints also affect the design of the product. Translating and testing the code in parallel with development uncovers problems with code and feature design early in the process, when it is easier to make changes. Localizing a product is akin to launching a probe to Mars. It's much less involved and much less expensive to adjust the course soon after liftoff. The trajectory might be only a few degrees off when the probe is near Earth, but if you wait until late in the mission to make adjustments, you won't have enough fuel to keep the probe from shooting past Mars by a million kilometers.

Figure 1.4 - The localization process.

It is important to "freeze" as much of the user interface and feature design as possible well before the product goes into final testing. Freezing the design means that no more changes will be made before the product ships. Every time a piece of the user interface changes, it has to be retranslated. In addition, the teams in charge of documentation, online Help, online tutorials, and marketing collateral might need to update their materials, which also have to be retranslated. Late changes, as you can imagine, cause significant, expensive delays in the release of localized products.

Shipment of International Products

Glossary

---

• Release delta: The time between the release of the domestic product and the release of the localized edition.
• Simultaneous ship, or "sim ship": The release of localized editions of a product at the same time as the domestic product; or a short release delta, usually within 30 days (to allow for nondevelopment needs).

You can take one of two approaches to shipping international products. The first is to begin working on international editions after the domestic edition has been released or when it is almost finished. The second is to plan for international products in advance, work on several language editions concurrently, and ship them all at roughly the same time.

Those who would advocate the first method fail to realize how much effort it takes to create localized software. If it were an easy task, the text of this book would be only a few pages long. A common argument from development managers is, "Our domestic product is really important. We don't want to delay the domestic product or distract the team by worrying about the international editions now." This short-term, restricted thinking makes sense only for companies that generate 95 percent of their revenue domestically or that have no international competitors. In other words, very few companies benefit from this strategy.

Microsoft's careful attention to its internationalization practices is the reason it earns the majority of its revenue outside the United States. Companies that make most of their revenue domestically either ship products with a domestic focus, such as financial software or certain multimedia titles, or they haven't tapped the potential of the international market. Because controlling costs has a significant impact on profits, the main argument against delaying work on international editions of a program is that to delay such work is expensive.

One effective approach, and the one Microsoft uses to develop Windows, is to create a solid world-ready core code base and to begin translation work as soon as there is something to translate. Microsoft develops the English, German, and Japanese editions of its operating systems in-house and in parallel-English because it is the largest language market for Windows and because most of the developers on the Windows team are native English speakers; German because as the largest European-language market, it is a good test of European-language functionality and ease of translation; and Japanese because East Asia is Microsoft's second-largest market, with Japanese being a good representative of East Asian language-development challenges. Other language editions, such as Italian and Swedish, are translated in parallel at Microsoft's subsidiary in Ireland. Teams in both Ireland and Redmond, Washington, worked furiously to ensure that localized editions of Microsoft Windows 2000 and Windows XP were ready for testing at each major development milestone.

This method of developing international software is easier to implement if all developers are held accountable for the international functionality and localizability of their own features. Naturally, having an internationally conscious team that constructs several language editions of a product concurrently-and with minimal problems-is an ideal that might take more than one product cycle to fully achieve. Again, the key is to begin early in each new product cycle. Early translation, for example, can uncover design blunders before complex features have been built around them. Coding problems can then be resolved while the code is still fresh in developers' minds.

The best result of a "three-pronged" development approach-such as Microsoft's simultaneous development of English, German, and Japanese editions-is simultaneous shipment of more than one language edition. The Windows 2000 team, for example, released the French, German, Spanish, and English editions of its product within days of one another. A "four-pronged" approach, such as the one summarized in Table 1-2 on the following page, would include either a right-to-left language (such as Arabic), a European language that does not use Latin script (such as Russian), or a language that is based on a complex script (such as an Indic language).

The international press pays attention whenever a new product revision reaches the market. Having more than one language edition ready when the domestic edition is released allows more than one language edition to take advantage of the publicity surrounding the new revision. Not having key language editions ready soon after the domestic release means that international customers will wait for the revised localized releases rather than buy the existing localized releases. The longer they have to wait, the more frustrated they become, and the more sales your company loses.

You will not significantly delay your domestic product if you work toward international functionality from the beginning of your product cycle; you will actually save your company time and money in the long run. Inventing a product-wide plan that satisfies all internationalization requirements-timely domestic and international releases, inexpensive localization, a compelling set of new features, and appropriate staffing-can be a balancing act. But without a plan and your team's commitment to it, producing international editions of your product will turn into one headache after another.

Table 1-2 Sample "four-pronged" approach, designed to uncover potential problems in international software early in the development process.

Language	Purpose	Reason	Language Alternatives
English	To develop product and test for general functionality	Largest market for Windows-based software	Native language of developers
German	To uncover international- related bugs and over- crowded user interface designs	Largest European language market	Finnish, French, Spanish
Japanese	To enable large non- Latin character sets, vertical writing, and vertical printing	Largest East Asian language market	Simplified Chinese, Traditional Chinese, Korean
Arabic	To create right-to-left look and feel; enable bidirectional text	Largest Middle East- ern market; issues are a superset of Hebrew issues	Farsi, Hebrew

If your product team has already produced localized editions, but they have long release deltas, the principles in this book can help you shorten the release deltas for your next product revision. In some cases, a new product plan might schedule localized releases of Product Two within months of localized editions of Product One. If this happens, suspend localization of Product One and concentrate on shipping international editions of Product Two quickly. Microsoft, for example, did not release a Japanese edition of Microsoft Visual Basic 3, but went straight from localizing Visual Basic 2 to localizing the version of Visual Basic that followed Visual Basic 3.