Sun Software Product Internationalization Taxonomy

Print-friendly Version

Chapter 2 Planning for Internationalization

Products cannot be internationalized in a day or even in the course of one release cycle. Internationalization affects all stages of software development, from identifying requirements to production. Since internationalization might be implemented over a period of several release cycles, a plan or "road map" to internationalization needs to be created.

This chapter helps identify priorities for internationalizing a product over time. Along with the completion of the matrix, this information can form a long-term road map to full internationalization. Road maps can apply to existing products as well as new ones.

In order to determine the route to full internationalization, product users must be identified and components must be evaluated. The next two sections describe different types of users and components.

Products provide interfaces and services to a variety of users. Users can be divided into two categories:

• Internal users - Product designers, developers, testers, technical support personnel, sales engineers, consultants, and all who work on product creation, release, support, installation, and customization.



• External users - People who use the product and who are not internal users.

Obviously, a product can have many more categories of users, but from an internationalization perspective, these are the primary ones. To prioritize the internationalization steps, external users can be further subdivided into the following categories:

• Non-technical users - People who are not required to be technically savvy to use the product. Non-technical users are the highest priority for full internationalization. A non-technical user might be someone using an email client, Web browser, or word processor. Typically the product is client software.



• Technical users - People who require some technical expertise to use the product. Technical users are the second highest priority for full internationalization. Someone using a programming language, debugging tool, network monitor, or software design tool can be considered a technical user. In this case, the product is often client software but can also be server software.



• Technical administrators - People who install, configure, and maintain the product. Technical administrators are the lowest priority for full internationalization. Technical administrators usually install and configure server software using command line options, configuration files, and administration consoles to monitor the successful execution and stability of a product.

The relationship between user categories and internationalization planning is further discussed in section 2.4.

Software products are designed to perform some sort of function, usually data processing. Users request the function using an interface that consists of messages, windows, buttons, form fields, drop down lists and other screen elements.

For internationalization, software data can be broken down into:

• Functionality - What the product does. This is the highest priority for internationalization.



• Messages - Text based information from the product for the user. This is the second highest priority for internationalization.



• Interface elements - Text containers and graphics, such as windows, buttons, and icons. This is the lowest priority for internationalization.

Functionality is best internationalized by planning it from the start. Retrofitting internationalization into existing functionality is like changing the foundation on an existing house--the entire structure is affected. Adding internationalization functionality at the end is an expensive and frustrating exercise and often requires a rewrite of most of the code.

Messages, due to their static nature, are fairly straightforward to internationalize. First, they must be further divided into internal and external messages. Internal messages are often called debug messages and are intended for internal users only (see section 2.2). They can be activated by some sort of switch, but this switch should not be in the external documentation. People who need to debug, support, or maintain the program code of the product can turn on internal messages.

External messages can be seen by any user. They can also be activated by switches, but these switches are documented. Some examples are: status messages, error messages, exception messages, and help messages. If an external user can activate the message, it is an external message.

Internal messages must not be internationalized. This prevents them from being localized accidentally, avoiding difficulties for support and customization.

Interface element internationalization is slightly more complex than that of messages. Planning the interface usually requires an interface designer who is aware of internationalization issues. To internationalize some interface elements, it is sufficient to put them into resource files; however, for other interface elements, such as icons, this might not be enough. Designing a new icon for each locale is extremely expensive; therefore, it is not usually done. The icons provided with the base interface are used all over the world. This means icons should be considered in the requirements and design stages of the development cycle.

Functionality, external messages, and interface elements should all be internationalized. Only internal messages are not internationalized. More planning information for data categories is provided in the next section.

In designing an internationalization road map, priorities must be established. The following considerations are listed in order of priority:

1. A user perceives two aspects of a software product: the user interface and the functionality. While a simple and attractive user interface can help sell a product, it cannot make up for incorrect functionality. People buy a software product for the functions it performs; otherwise, it is useless to them. Functionality, therefore, is a higher priority than messages and interface elements.



2. Messages are the means by which the software communicates with the user. If something goes wrong, or the user's request is incomplete, it is through messages that the user understands what to do next. Without messages in a familiar language, the user can become frustrated and telephone a support center. This is costly both in low customer satisfaction and in support costs; therefore messages become the next priority.



3. Interface elements have the lowest priority of the three data categories. This is not to discount the importance of interface elements; they are the product's look and feel and can make product use much easier.



4. Non-technical users are usually far greater in number than technical users or administrators. In addition, non-technical users tend to be the least likely to be familiar with or use English computer-related terms. As a result, product internationalization is most exposed to this group. Their functionality, messages, and interface elements should be the first areas to be internationalized.



5. Technical users may understand the terminology within their area of expertise, but that usually represents a small portion of the data in a software product. For software development tools, internationalization functionality can be crucial to the success of the product. Other companies want to create internationalized software as well. Technical users are a higher priority than technical administrators.



6. Last but not least are technical administrators. Administrators are people too. While many administrators can manage with English data, they would function much more efficiently if data were available in their language.

While many of these considerations can only be addressed through localization, that localization cannot be accomplished without first internationalizing the product. Localization decisions should not be restricted due to lack of internationalization.

There are more considerations than those listed in the previous section. While internationalization strives for a single generic code base, the reality is that some languages need custom modules for support. For example, in a word processing product, extra rendering functionality is required to handle Arabic. This type of functionality is not likely to be part of the general code base, though it should be easily plugged into the general code and should blend seamlessly into the application programming interface (API). In designing the road map for this product, markets should be analyzed.

If a product is a provider of internationalization functionality (see Chapter 1), it is more important to include as much internationalization as possible. Providers should also have a clear road map. Consumers depend on their providers for a certain amount of internationalization and their road maps follow those of their providers.

This chapter aims to provide general guidelines for internationalization phase planning and the underlying reasoning behind it. The Internationalization Assessment Matrix helps you to break down areas of internationalization even further. Product managers and engineers should take into account priorities relating specifically to their products.