The development team should supply the localization team with a single binary that works well for all different locales. The localization team will expect that the software has been designed and created to meet locale-aware and localizability standards. (For more information, see Part II, "Globalization," and Part III,respectively.) The UI elements should be stored in the resource files of a program or in some other resource repository. If the development team has not done this, localizers should ask the development team to put the resources in a standard format, so that localization tools can handle them. (For more information on storing UI elements, see Chapter 6, "Multilingual User Interface (MUI)," and Chapter 7, "Software Localizability Guidelines.")
There are many elements that are modified in both software and content localization. These elements include text, layout, graphics and multimedia, keyboard shortcuts, fonts, character sets and locale data, as well as the product's build process and packaging.
Text translation is the most important aspect of localizing the software UI. The translation should communicate in language, phrasing, and vocabulary that is natural as well as accurate. Moreover, the language should be clear, familiar to the user, and appropriate for the culture of the target country. Additionally, it should follow conventions used in the target country such as customary symbols, punctuation, formatting, and typography. Title bars, menus, dialog boxes, buttons, messages, and tool tips are some common UI controls that have text. Help files and user manuals typically require heavy translation efforts.
Translation does not always result in a one-to-one correspondence between the source and target language. A single word in English can have multiple translations in another language. For instance, the word "supply" in English can have varying translations in Spanish, depending on whether the word is used as a verb or as a noun. Even within the verb and noun categories themselves, the Spanish translation can differ, depending on the particular context. On the other hand, certain English words might have only a single meaning in another language. In addition to semantic variations among words from one language to another, adjectives and articles sometimes change spelling according to the gender of the nouns. Therefore, when re-using a text string in multiple places, localizers need to make sure that the string is translated in such a way that the text is correct for a given context. (For more information, see Chapter 7.)
Consistent and precise terminology throughout the software application helps the user to learn the application faster and makes the translation time shorter. For example, "traveling" and "travelling" are both correct in English, but it is better to use one variation of the word in the product. Localizers should do the same for the localized text. Having consistent terminology in the original-language product is particularly important if the localization team uses automatic translation tools because the utility might not translate the variation in the same way. (For more information, see Chapter 9, "Content Localizability Guidelines.") Consistent and clear phrasing of the original text makes localization easier and prevents confusion for localizers, who might interpret the text differently from what was meant. Localizers should avoid "sublocale" idioms, colloquialisms, or metaphors, since these might be meaningless-or even offensive-among cultures that use the same language.
Some locales share the same language yet use different words for the same object. For instance, the word "computer" is "ordenador" in Spain and "computador" in Mexico and Puerto Rico (both of which are masculine in gender). The word "computadora" is used in the rest of Latin America (and the word's gender changes from masculine to feminine). To resolve such issues, if there is one translation that is considered acceptable for all locales, localizers should use this particular wording.
In general, the text (as well as the graphics and other elements) of the localized software product should not be altered to reflect locale-specific geopolitical views because this could cause inconsistency in the localized product. Nonetheless, sometimes there could be undesirable consequences resulting from a localized product that is not adapted to meet a locale's geopolitical views. If the views conveyed in the unaltered product are going to offend the target market, this will affect sales in that market. Such a situation would warrant alteration of the localized product. For disputes over national borders, maps, country names, international or political organizations and leaders, or any other politically sensitive subjects, consult an expert on geopolitical issues for advice. Then make any necessary adjustments in the original product. (For more information on political content, see Chapter 7.)
Another element that requires localization is the UI layout. The localization process changes the UI layout because the length of the translated text usually increases from its original length. This text-stretching affects the size of the UI controls that display the text and potentially necessitates relocating and resizing the UI controls. The best way to ensure that the UI has a consistent look and feel throughout different localized versions is for the development team to design the UI with resizing-and other required locale variances-in mind from the beginning. In turn, the localization team should try to minimize any changes to the UI, unless these changes are absolutely necessary.
In addition to text that increases in length when it is translated, font size can differ among language groups. For instance, East Asian languages usually display text in a larger font size than many other language groups. As a result of the change in font size, the system expands the UI vertically. Edit boxes, static text, and button controls within the East Asian localized version of the product usually result in larger vertical spacing than those within products from other language groups. Bidirectional languages like Arabic and Hebrew require mirroring of the screen layout to accommodate their RTL reading order. This requires mirroring the layout of menus, text, dialog boxes, and edit boxes.
One of the advantages of graphics is that they can communicate more universally than text, provided they are not culture-specific. Graphical UI components of the software product might need to be revised for the international audience. Use images that are not geared toward a particular culture or locale, and avoid including text within graphics. These practices will help minimize the localization of graphics, which is very expensive and often causes the shipping of the product to be delayed.
You will also need to retake UI screen shots for the localized versions of the product. Icons that have a particular directional orientation-such as Undo and Repeat-will need to be localized for bidirectional languages in order to be locale-aware. (For more information, see Chapter 8.) The same concept applies to music and video. For instance, suppose you want to use music to indicate that the computer is calculating an equation. Because the famous U.S. game show "Jeopardy" uses a particular musical theme to indicate that a contestant is thinking of an answer to the game-show host's question, you decide to include the music in your application. Unfortunately, this effort will not necessarily be understood in other countries.
The localization team can give feedback about the graphics and multimedia components used in the product to ensure that they are suitable for all locales. Even if it were not expensive to design custom graphics for each language, having different images from one language to another can confuse the user who works with more than one language version.
Keyboard shortcuts might need to be changed according to the translated text that contains these shortcuts. For example, the F key is used as the shortcut for "File" in English. This shortcut needs to be modified during German localization to the D key because the same word in German-"Datei"-does not have the "F" character in its name. Chinese, Japanese, and Korean do not have a Latin-based script that allows for single-key shortcuts. For this group of languages, a common practice is to keep the source language's original Latin-based shortcuts such as "(F)". When there are standard shortcuts for common functions in localized products, localizers should use these shortcuts and not create new ones.
Localized products might have different UI fonts than the original-language products. The font name, size, and style in dialog boxes and documents can be changed to customize the final UI based on user preference. Localizers will use the best font settings according to the font capabilities of the particular target language.
Formats of dates, time, currency, measurements, and telephone numbers vary from one locale to another. Again, localizing the software to suit an international audience requires using the appropriate format for the particular locale. You can change a format programmatically by using the globalization infrastructure provided in Windows operating systems and the .NET Framework. (For more information, see Chapter 4, "Locale and Cultural Awareness." ) Some instances of locale-data values can be stored as part of the resources to initialize variables like the default character set or the default date format. If the development team does indeed want to store these values, localizers should change the locale-value strings according to the format of the target locale.
It is a good idea to use the same build process for the localized product as for the original product. Still, there are some binaries that need to be included in or excluded from the localized product for specific markets, which can alter the build process for the localized product. The localization team should work with the development team to set up an automatic procedure for handling changes, and should make this procedure part of the general production process. Localizers need to make sure all text, controls, and menu items that refer to locale-specific features are changed accordingly.
The basic product design for the localized product should be the same as for the original product. However, product packaging might require a certain amount of local ization so that it appeals to international customers. For instance, the localization team should change any reference that is made to locale-specific features, such as contact phone numbers and addresses. Another important aspect of product packaging is the End User Legal Agreement (EULA), which must be modified according to the laws of the country in order to sufficiently protect the manufacturer.
An important component of localization involves tools that will simplify the localization process. While some people might be able to add up ten numbers in their heads, using a calculator is usually a quicker and easier method of achieving-what should be-the same result. Similarly, the proper localization tools will help expedite the localization process and will handle many of the common tasks that localization entails.