Localizability Considerations for the UI

Now that you have learned how to store and handle text to make localization more straightforward, you need to know how to design your UI so that the localized content does not break the look and feel of your program. The following will discuss how to minimize the resizing of your UI caused by languages that require more (or less) space for the same content; how to handle UI controls like list boxes, combo boxes, buttons and so forth; and how to effectively use images and icons.

Element Resizing

Glossary

---

• Common dialog boxes: Standard dialog boxes defined by Windows for operations found in numerous applications; these operations include Open, Save As, Print, Page Setup, Color Selection, Font Selection, and Find. Applications can call common dialog box API functions directly instead of having to supply a custom dialog template and dialog procedure.

The most time-consuming part of localizing the UI is resizing elements, particularly for applications that will ship in numerous languages and that contain a large number of dialog boxes. The following provides solutions for addressing this issue when working with Win32 dialog boxes.

Win32 Dialog Boxes

You can minimize the amount of resizing necessary by creating your native-language dialog boxes with as much room to spare as you feel comfortable; extend text frames as far as possible so you can allow text to grow when it is translated. For example, in Figure 7-3, the frames surrounding the Name, Initials, and Mailing Address text fields extend all the way to the end of the edit control.

Figure 7.3 - Options dialog box with extended text frames.

Also, when possible, it is best to put text labels above UI controls such as edit boxes, as shown in Figure 7-3. This positioning allows for the greatest extension of the text field. Although putting text labels above UI controls is the best practice for localization, thereare times when the text label is placed to the side of a control for a better look and feel. When this is the case, make sure to leave room for the text to expand in your design, and remember to extend the text field to cover all the space given. For instance, notice the extra space allotted between the text "Digit grouping symbol" and the list-box control in Figure 7-4. In Figure 7-5, you can see much of this extra space was used when the text was translated to German.

Figure 7.4 - Example of a dialog box for which extra space has been allotted between the text field and the list-box control.

Figure 7.5 - Example of how a text field can expand during translation.

When designing and localizing dialog boxes, you should test them with various screen sizes and resolutions to make sure they still look correct and fit on the screen, especially if your application allows the user to change the size of the application's dialog font. Microsoft Windows XP, for example, allows the user to scale the size of the system fonts, including fonts used for system-drawn items such as title bars and menus.(See Figure 7-6.)

Figure 7.6 - The Advanced Appearance dialog box from the desktop Display Properties property sheet, which allows you to change the font and font size of system items such as a menu.

The user can also resize system dialog boxes; the dialog controls will adjust simultaneously and automatically. (See Figure 7-7.) If you decide to incorporate this functionality into your design, carefully consider how your program will automatically adjust dialog boxes that have been localized-the ease with which the dialog box designs can be made to incorporate this feature is a good indication of how localizable they are.

For each localized dialog box, double-check that the order in which the user activates dialog elements via the Tab key still makes sense. If tabbing order isn't consistent, the localizer probably changed the relative position of dialog elements to make the translations fit, or the localizer might have set the coordinates of an item outside the coordinates of the dialog box itself.

Figure 7.7 - The Windows 95 Find: All Files dialog box. A user can adjust the width of the dialog box by dragging the border with the mouse.

To omit references to features not supported in a localized application, you could set the item's coordinates outside the dialog coordinates but, as mentioned, it is not assured that you'll have consistent tabbing order. Another way to omit references is to permanently dim such items. Although this practice preserves tabbing orders, it might confuse the user, who might not understand why certain commands are never available. As mentioned earlier, many applications have similar basic features. For example, most applications open and save files. Windows provides common dialog boxes for these operations (like the one shown in Figure 7-8).

Figure 7.8 - Example of a common dialog box.

Common dialog boxes have benefits for both the user and the developer. They make applications easy to learn because they provide consistency among applications. Such dialog boxes are also easy to implement because they require only a single API function call. Common dialog boxes do, however, present a dilemma for localized applications. Currently, each edition of Windows XP ships common dialog boxes only in the default language of that edition. An application that uses common dialog boxes will, therefore, always display them in the language of the system rather than in the language in use by the application. The mix will be jarring to a user who does not understand that some dialog boxes are drawn by the application and some are drawn by the system. Another problem for applications that use common dialog boxes is that they can be embedded within application-defined resources; the system dialog boxes might differ in size on different language versions of Windows-this can cause text to be clipped in applications.

While the configuration of Windows where your application runs might not provide common dialog resources in the language of your application, one way to work around this predicament is to use templates for the common dialog boxes instead of using the common dialog boxes themselves. The application can provide translated templates to the dynamic-link library (DLL) that contains the Windows procedures for the common dialog boxes. This method might work in the short term, but it does carry the risk that the translated templates will not be compatible with future versions of the common dialog boxes.

Controls, such as radio buttons and check boxes that allow the text to wrap are another way of handling text expansion. To allow multiple lines in a Win32 resource file, you can either manually add the BS_MULTILINE property to the control (shown within bold in the following code):

 CONTROL "Check1",IDC_CHECK1,"Button",BS_AUTOCHECKBOX |  BS_MULTILINE | WS_TABSTOP,21,21,41,10 CONTROL "Radio1",IDC_RADIO1,"Button",BS_AUTORADIOBUTTON |    BS_MULTILINE,19,45,39,10 

Or in Microsoft Visual Studio you can select the Multiline property in the particular control's property sheet. (See Figure 7-9.)

Figure 7.9 - Multiline property set in a Visual Studio control's property sheet.

In the .NET Framework, check boxes and radio buttons are automatically set for multiple lines. Allowing multiple lines is important since localizers might not have accessto these properties; their only alternative is to leave out information so they can fit the translation onto one line. Figure 7-10 shows a dialog box that was well designed in the English-language version. When localized into German, however, the radio buttons' UI design was broken when the translated text was not allowed to wrap.

Figure 7.10 - Result of not allowing controls to wrap text.

Variables used in UI strings usually need extra space because you can never be sure how long the text will be that replaces the variable. A good rule is to add one line per variable in the text box so that there is enough space for the localized text. In Figure 7-11 the translation of the first sentence "Welcome to the %s Registration wizard." will require the entire first line. Thus the inserted text of the variable will extend the sentence onto a second line.

Figure 7.11 - Example of allowing one line per variable in a text box.

The basic rule is that you should leave about 30 percent additional room for text expansion. Most of the time this practice works. The only exception is when you have a string or button that has less than 10 characters. Take, for example, the following OK button.

If you followed the 30-percent rule, all you would do is leave space for one more character; but this does not hold true if you are localizing the text into Spanish. The verb for "accept" in Spanish is "aceptar" (which is used within the UI to mean "OK"). However, the word "aceptar" is 250 percent bigger than the original text.

Therefore, the exception to the 30-percent rule is if the text has less than 10 characters, leave room for at least 400 percent growth. Remember that these are general rules, and all languages' UIs should be designed to look as good as possible, even in English. However, the best guideline is to leave as much space for text expansion as possible. Minimizing the need for resizing is a vital part of making sure that Web pages are localizable also.

Web Resizing Issues

Until recently, the majority of UIs on the Windows platform have been created using Win32 dialog boxes or Microsoft Visual Basic Forms. These days, many developers are taking advantage of the richness of HTML to create an application's UI. This is great for a development team, but causes huge problems for applications that need to be localized into multiple languages. That is because HTML interfaces are a lot harder to resize and readjust after translating the text.

And it's not just UIs that are hard to resize after translation. Ordinary Web pages that utilize the full power of cascading style sheets (CSS) can be an absolute nightmare! People have found that the cost of translating, resizing, and testing HTML UIs is far greater than that of Win32 dialog boxes.

Nevertheless, with the right coding standards, all HTML UI elements can be constructed so that the localization team will have little or no resizing and repositioning work to do. One approach that Microsoft uses internally to accomplish this is called "HTML AutoLayout (HAL)." The HAL documentation shows some of the key coding standards you should follow to allow for "zero resizing." (To view the HAL documentation, see the Extras subdirectory on the companion CD, or go to http://www.microsoft.com/technet.)

The HAL documentation lists a series of rules and the key reasons behind them. These rules are:

Rule 1: Never use absolute positions.

Rule 2: Dialog boxes should use the available width and height.

Rule 3: Each control should be in a separate cell.

Rule 4: Allow wrapping text.

Rule 5: Separate check boxes and radio buttons from labels.

Rule 6: Leave room for growth and avoid fixed-width items.

Rule 7: Define methods for sizing buttons, list boxes, and group boxes.

Rule 8: Define when to set height.

Rule 9: Do not use left or right align exclusively.

Rule 10: Avoid inline CSS with values that localization needs to change.

The rules are then followed by a set of coding samples.

A key point to remember is that HAL is just one approach for achieving zero international resizing. There are probably countless other methods. This is fine as long as they achieve the same result. Even so, other methods will probably benefit from using some of the HAL rules. Another point to bear in mind is that there are already many HTML dialog boxes that are HAL-compliant for the most part. This is especially true for dialog boxes (or windows) that were designed to be resizable.

Localizability of UI Controls

In addition to element resizing, another major localizability consideration for the UI involves UI controls. Since programmers do not have to create their own controls, such as list views and edit boxes, their job is made somewhat easier. However, when used in certain ways, these same controls can pose a problem for localizers. Edit boxes, for instance, often need to be repositioned dependingon the syntax of the target language. The following sections will give you some tips on what to be aware of when working with UI controls.

UI Controls Within Sentences

The biggest problem with UI controls in terms of localizability is when programmers use them as part of a sentence. Localizers often have to either change the position of the controls (if they have access to a formatting tool) or settle for an improper sentence structure. For example, Figure 7-12 is designed with an edit control in the middle of a sentence. In its German localization, the edit control had to be repositioned so that what it represented could fit syntactically in the German translation. (See Figure 7-13.)

Figure 7.12 - This edit control occurs in the middle of a sentence.

Figure 7.13 - When localized into German, the edit control had to be repositioned.

A better design is to rethink the whole phrase, so that the edit box can be removed from the sentence. (See Figure 7-14.) This way the localizer does not have to reposition the edit box. (See Figure 7-15.)

Figure 7.14 - The edit control appears outside the sentence.

Figure 7.15 - When localized into German, there is no need to reposition the edit control.

The other problem with using UI controls in sentences is when you have a drop-down box. As mentioned earlier, strings built at run time cause problems because of grammatical differences (such as the existence of gender in some languages) and syntactic differences (such as verbs that can either precede or follow a noun depending on the language and context). Similarly, drop-down boxes might have terms in them that could change the translation of the sentence depending on the term selected. Plus, moving andaligning drop-down combo boxes that usually consist of multiple controls is always error-prone.

Hidden or Overlapped UI Controls

UI controls such as buttons or drop-down lists should not be placed on top of other controls. Some localization tools are not able to change the state of a dialog box; thus the localizers might not even know that there are hidden controls to translate. Even when localizers have access to all the controls, sizing and hot-key issues with hidden controls are usually only found through testing. In Figure 7-16, the UI is not localizable because the button size cannot be extended to the length required for the translation without rearranging the button positions; also, rearranging is not possible because there is not enough space in the dialog box. Although rearranging button positions is costly and makes the UI inconsistent among languages, there might be times when it is necessary to do so.

Figure 7.16 - This dialog box is not localizable because the button size cannot be extended without rearranging the position of the buttons, and there is not enough space for rearrangement.

Figure 7-17 demonstrates the other problem with hidden controls. Even if there were room for the expansion of the Edit Properties button, unless the Accept button is resized also, the Edit Properties button would be partially visible when it actually should be hidden. This causes a very unusual UI in which buttons overlap.

Figure 7.17 - Dialog box in which the Edit Properties button and the Accept button overlap.

Button Text

Avoid placing button text into a string variable. Text on a button should never be dynamically linked onto the button from a string variable, but should be placed on the button itself as a property of the button. Button sizes usually have to be adjusted to fit the length of the translation on the button. Localizers have no way of telling which strings in the string table end up on which button at run time. (See Figure 7-18.)

Figure 7.18 - The string "add job" ("Auftrag hinzufügen") was stored as a text resource. Since the button cannot change its size at run time, part of the text is truncated.

Images and Icons

Since the beginning of graphical user interfaces (GUIs), images and icons have been a major part of well-designed architecture. Their greatest strength is that with one picture a whole concept can be depicted. One reason behind this is that a picture evokes shared experiences that everyone has within their particular culture. When it comes to software localizability, this strength from shared experiences becomes one of the greatest weaknesses of images and icons. Obviously not all cultures share the same experiences or backgrounds. What for one culture might be a positive experience might be a negative experience for another.

Take colors, for example. In the United States, wedding attire for the bride is largely associated with the color white, while black is associated with death and burials. However, in Japan the color symbolism is just the opposite; white is the predominant color at funerals, and black is considered a color that brings good luck for weddings. Cultural color perception is just one of many issues that can affect the perception and effectiveness of your overall design. The following sections will look at issues to avoid when designing images and icons for your interface.

Avoid Culture-Specific Examples

Just as color can evoke different emotions from culture to culture, certain images can have the same effect. A couple of good examples come from the early days of GUI operating systems. In earlier UIs a U.S. rural mail box was used to indicate mail. This was acceptable for use in the United States because many people had grown up using these types of mail boxes. However, when the image was introduced in Europe, most people wanted to know what a breadbox sitting on a pole had to do with mail. A much better choice would have been-and still is-using an outline of a postal letter, since most people who understand the concept of mail would understand this image. (See Figure 7-19).

Figure 7.19 - Earlier image used to represent mail, versus the newer and more culturally-appropriate image.

Another example of an image that can have varying interpretations from one culture to another involves the concept of a "wizard." A wizard was used in earlier UIs to represent assistance for doing something the user might not understand. Based on Americans' experience with wizards like Merlin in the King Arthur stories, pointed caps and magic wands were used to depict this concept. (See Figure 7-20.) Again, these images worked well here in the United States, but the concept of a wizard is foreign to many other cultures. Even for some cultures that do understand the concept, wizards don't necessarilywear pointy hats. In still other cultures, a wizard represents something evil or destructive; it can even be a religious abomination, rather than something that is meant to enlighten or assist someone.

Figure 7.20 - Culture-specific images formerly used to depict a software wizard.

Avoid Showing Flesh or Body Parts

There are as many different attitudes about displaying the exposed human body as there are shades of gray. What is considered taboo in one culture or country can be widely accepted in another. These varying attitudes range from the body needing to be completely covered to the acceptance of bikinis. With the widespread use of the Internet and global communications, you will never know for sure who will see or use your products. Thus the best practice is not to display skin or even use a body part to convey a concept. So instead of using an open hand to represent "stop," use the internationally-accepted, eight-sided stop sign. (See Figure 7-21.) In addition to the taboo factor, although using the image of an open hand might be understood in the United States as a way to indicate the action of stopping, this doesn't mean the image will be understood in other cultures.

Figure 7.21 - Rather than using the hand to represent the action of stopping, use the internationally-accepted stop sign.

The use of body parts can indeed raise different emotions other than the one intended. Take the American gesture for "okay." (See Figure 7-22.) Although the gesture might be accepted in the United States, there are other parts of the world where it will not be understood, or where it can even have some very obscene connotations. Again, it is better to avoid using images involving a human body part, unless you are dealing with software that has a specific medical theme or context. Even then, be careful not to show a hand in some type of gesture.

Figure 7.22 - Gesture used in the United States for "okay."

Beware of Gender-Specific Roles and Ethnic Stereotypes in Other Cultures

Taking the skin and body gestures one step further, you must also be aware that diverse cultures view the roles of men and women quite differently. In some cultures, men and women are treated as complete equals; in others, one gender is seen as subservient to the other. Thus in some cultures Figure 7-23 wouldbe offensive because it shows a woman standing above men in an apparently superior role. A better graphic to portray the same idea is in Figure 7-24, where the human figures are gender-neutral.

Figure 7.23 - Example of a potentially offensive graphic for its depiction of gender-assigned roles.

Figure 7-24 raises another point: ethnicity. In this figure you cannot tell what race the people belong to. Some cultures feel the same way about ethnic-group roles in society as they do about gender roles. By adhering to the guideline of not showing skin (or skin color), you can feel safer that you are not generating content that has higher potential risk in a locale.

Figure 7.24 - Example of an inoffensive graphic, since it avoids depicting gender-assigned roles.

Avoid Religious References

From ethnicity, the content risk can be widened to include religious references. It's important to avoid any religious references so that you don't offend a local culture's expectations or appease one religious group at the expense of another. A symbol that might seem innocent to a developer in the United States might be sacrilegious to a consumer in a certain market. Be very cautious about employing any religious references, even for holidays and more common events.

Avoid Political Symbols

When it comes to governments and politics, it is very important to realize that your product's distribution in a local market is often dependent upon the local government's approval. Thus when localizing for a specific market, you must take into account the local government's expectations for content. As much as possible, it's important to avoid including content that could offend the local government-either by challenging its authority or by criticizing it through support of a rival government or faction.

Software has been banned in some countries and regions simply because a map showed that a disputed piece of land belonged to another country. Maps are very graphic and obvious statements about a government's sovereignty, so a user associated with the disputed piece of land would know very quickly if the maps are accurate or not. In addition to maps, flags can be a very sensitive piece of content. For example, a flag in a UI that represented an unrecognized country was very upsetting to a nearby government, causing that government to ban a product on the basis of the unrecognized national flag. Both of the incidents just mentioned emphasize one of the most misused group of graphics: political symbols, maps, and flags. Most unknowing developers use flags as a graphical way to display a particular language, country, or region, but that is not what a flag represents. Flags are nationalistic; they represent ideals, boundaries, and political beliefs, but they do not represent a language. For instance, which flag do you use to represent the English language-the American flag, the British flag, the Canadian flag, or the Australian flag? All of these countries speak English. In the process of selecting the most appropriate flag, you will inevitably offend someone because you left them out. The best practice with all flags, national symbols, maps, and so forth is to avoid them as much as possible.

Avoid Text in Graphics

The last area to consider when dealing with graphics involves embedded text. Figure 7-25 displays an icon that a developer wants to use to indicate the function of opening a folder. To make sure that the user understands what to do, the developer has added the word "open" to the graphic.

Figure 7.25 - Translating this embedded text will cost you valuable time and resources.

Using embedded text such as this is helpful if you are only dealing with the English language. However, when you localize your software for another language, you have to translate this graphic for each language edition. Depending on how the graphic was created, this could take some time. Certain graphics packages-such as Microsoft Paint-often take the text you add and convert it to individual pixels. This means that localizers will need to go back into the graphic, change all the pixels from the text color to the background color, and then add the new translation. Furthermore, they must do this for each language into which you are translating.

Suppose you are translating into 24 languages and it takes 10 minutes to adapt each graphic. That one graphic now costs you 240 minutes or four hours of resources. What seemed to be a simple translation has become a half-day project. If you had to adapt just 10 graphics, you have now unnecessarily added five days of work. In addition, even more time might be involved if the background is more complicated, such as if it has many colors, rather than being monochromatic. Besides the extra time spent localizing the graphic, another issue is that there are now 24 different graphics that you have to keep track of. If you have 10 graphics, you would need to deal with 240 different graphics to make sure that they are in the right place and that they are part of the right build.

The better way to handle this is not to add text to a graphic at all. For the previous example, that would save you $2000-using a $25-an-hour estimate for labor-to localize 10 graphics for 24 languages. It would also save you the hassle of keeping track of those 240 different graphics. Even if you think there is a verygood reason to have text in a graphic, you should ask yourself if it is absolutely essential. If so, you can still minimize the extra work needed. For instance, some graphics packages have a function that stores the text as a separate layer from the graphic itself. This way, when you need to go back into the graphic, you don't have to change it pixel by pixel. You only have to go into the text layer and change it to the new translation. Although storing the text as a separate layer saves you some time in editing, you still must do this for each language you are localizing into, and for each graphic for which you have text. This practice does not spare you from having to track all additional graphics.