Internationalization of Software
Erin McCafferty
Computer Science / Software Engineering
University of Wisconsin-Platteville
Abstract
In today’s global market people are purchasing products, including software, from around the world. Internationalization of software includes creating software that is world-ready and localized to specific regions. The amount of work required to internationalize an existing or new project is often underestimated by management and developers. There is risk involved with developing an international product, as well as cost, but offering software to a global market is often worth it. This paper will explore the importance of international software, the different steps involved in the internationalization of software, and the different tools and technologies that are available to aid designers and developers in the creation of international software.
Introduction
In order to understand software internationalization, a few common terms must be defined. Internationalization of software involves designing and developing software in a way that makes it easy to localize the software to a target culture, region or language. Internationalization is often abbreviated as i18n because of the 18 letters between the “I” and the “N” in internationalization. Localizing adapts the software to the lingual, cultural, and other requirements of a specific locale [1]. Localization is often abbreviated as l10n. Globalizing a software product combines internationalization and localization to create a product that works globally [2]. Globalization is abbreviated g11n. Much of internationalization is focused on changes to the graphical user interface and little else.
Figure 1: The breakdown of the aspects of software internationalization [1].
Internationalization has several variants. The least acceptable is monolingual internationalization which allows creation of localized versions of the product specific to a single locale. Internationalization for multi-localization supports localization for more than one locale, but the locale is specified at execution. Multi-lingualization displays several languages and locales simultaneously in a single user interface [3].
Internationalization Process
The major goal in creating an internationalized software product is to decouple culture-dependent portions from the culture-independent ones [5]. The culture-dependent portion is generally thought to be only in the user-interface. All the culture-dependent parts should be put into separate files; later those files could be translated into a different language [2].
There are two possible approaches to developing an international software product; start developing the international product after the domestic product is complete or nearly complete or to create the international product with several language editions at the same time. Often times development managers say “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 argument really only makes sense for companies that don’t have international competitors or make 95 percent of their revenue domestically [1].
Microsoft, who generates the majority of their revenue outside of the United States,develops a world-ready core code base and begins to translate into Japanese and German as soon as possible. They choose to translate to Japanese because South East Asia is the second largest market for Microsoft’s products and Japan is representative of those languages. Translating to German is a good idea because German is the most commonly spoken language in Europe, and it provides a test of how difficult it will be to translate to other European languages. This method works best if developers are responsible for the international functionality and localizability of their own developments [1].
The goal of developing international editions simultaneously is to minimize the release delta. Release delta is the time difference between the release of the domestic and localized editions. The ideal would be to simultaneously ship the products, or to at least have a release delta of less than 30 days [1]. This takes advantage of the international publicity surrounding the new release. It also prevents international users from waiting for their localized product, becoming frustrated and deciding to purchase a competitor’s product.
Specifying an International Product
The most important factor of a successful international product is beginning early in the development cycle with correct specifications. This will cause issues to arise sooner, and make the solutions easier to implement. Also, it is important to plan and design the product correctly the first time because, like domestic-exclusive products, the later a change is discovered, the harder it is to fix. This is even more important with international products because problems must be corrected in multiple editions. Globalization plan, customizing features, designing a user interface that’s localizable, legal issues and accessibility of features must be included in specifications [1].
Globalization
Globalization, or making sure that different language and locale versions of the software product have the same functionality, involves several general tasks. The first task is to decide which languages and locales will be supported. The next task is to design features that will be used by those languages and locales. The final task is to write code that functions equally well in those languages and locales. There are four different areas of globalization: creating specification, encoding data for internal processing and passing to other applications, input/output of data, and managing of a Multilingual User Interface (MUI) [1].
Customizable Features
Deciding which features need to be customized for a software product is important because some features of the domestic product may not make sense for the products for other locales. Also, some foreign markets require features that are not necessary in the domestic market. Another consideration is features that are necessary for all editions, but the code to perform the functions may be different. This also applies to data; for example, spell checkers use the same code to check spelling, but they use different dictionaries [1].
Localizable User Interface
Having an easily localized user interface is one of the easiest ways to keep costs of localization and development low. Some developer “tricks” that normally save money and work, such as using text strings that are concatenations of phrases, actually increase costs in the long run of developing an international product. Also, hard coding a string into the program becomes a problem during localization. Since having a localized user interface is one of the most important parts of developing international software, keeping the cost of adapting the user interface low will help greatly [1].
Legal Issues
Laws in other countries obviously affect distribution of a product thereand it is important to understand those laws before developing software for those countries. For example, France requires that all software and documentation marketed there must be in French [1]. Also, other countries have laws that tightly regulate the use of encryption algorithms, phone lines, and local hardware. Some of the more restrictive countries are Belarus, Kazakhstan, Mongolia, Pakistan, Russia, Singapore, Tunisia, and Vietnam [6]. Marketing in other countries is also affected; in Germany, no company may claim to have a superior product than another company. Software piracy is another legal issue to consider, since laws for software piracy vary greatly between countries. In general, entering software into a new market requires diplomacy [1].
Accessible Features
Accessibility is the “extent to which computers are easy to use and available to a wide range of users, including people with disabilities.” This includes global cultures. Many features that are easily accessible to people with disabilities are also easy to localize. Simple dialog boxes with a small amount to text are easy to translate, and they are also easier for some people with visual impairments to read [1]. A product can be saved from later redesign if you design it to be accessible from the start.
Internationalization Team Organization
Having a thorough plan and specification is an important step in creating an international product and having people that are able to implement that plan is essential. Having a team of committed individuals prevents having to hire additional people. There are three “golden rules” for product team managers. First, make sure everyone is educated on international issues. Second, enforce the fact that international functionality of features is the responsibility of the team member who developed them. Last, develop at least one international edition in parallel with the domestic product. [1]
Localization
The localization process requires a lot of communication between different product teams. The development team must provide files to the localization team, which will translate the text and return it to the development team for compilation. Next, the software is sent to the testing teamwho reports back to the development and localization teams [1]. These teams then work to fix problems and the process repeats.
Many international developers and managers don’t fully understand what the localization process does. A study of internationalization and localization of software has shown that there is a “perception gap” between the knowledge and processes of developers and Localized Service Providers (LSPs). The study found that 81.3% of developers claimed to have experience with internationalization, but LSPs thought only two-thirds of clients had a thorough understanding of it. The study also found that only 11% of LSPs provide total internationalization support, most only provide testing and assessment services [4]. Many developers believe that the LSPs provide total support, so this perception gap is a problem and shows that developers need a better understanding of the localization process.
The Localization Process
Localization has several general steps that must be taken into consideration for any software product. The first step is internationalizing the source code. All locale specific data should be put into separate files so they can be localized and translated into a new locale. The next step is preparation and pre-processing, which includes preparing your software for basic translations. This is extra work for developers since additional information must also be provided in a “localization package”. The next step is localization, which requires the developer to answer questions about the localization package provide information that was left out to a third party translator or sometimes even the customer. Once the results of the localization are received by the developers, the existing product must be merged with the new localized data. This is sometimes a simple process, but it is more often more complex. The product must be finalized by developers post-processing the localized source. Finally, developers and a quality assurance must confirm everything was localized correctly [2].
Figure 2: A simplified explanation of the localization process.
Levels of Localization
There are several different levels of localization, with varying degrees of risk and return. If there is little competition in a given market, sometimes less localization is necessary. It is acceptable to have an English-language user interface in several markets, such as small markets, markets without competitors, and markets where the target audience speaks English such as medical, scientific, or technological communities [1].
The lowest levels of localization, to translate nothing or to only translate documentation and packaging, take little developer time and cost little to translate. In the worst case, developers will have to explain more technical details to the translators. The next level of localization, enabling the code, allows users to display and enter data in their own language, but the interface is mostly unchanged. Translating the menus and dialogs is the next level of localization, followed by translating online help, tutorials, and sample or README files. The highest levels of localization include adding support for different hardware and customized features for a locale. [1]
Figure 3: Levels of Localization [1]
There are many factors to take into account when deciding what level of localization is necessary. If there already is an edition of a product, it can be used it to find out if users will buy it with an English user interface. If this is unsuccessful, a partial translation can be done to avoid the cost of a full translation and to ship quickly. More translation results in more questions for the developers to answer and more errors for developers to fix. Higher levels of localization are required in competitive markets, so customizable features and support for local hardware must be provided [1].
Localizing Beyond the User Interface
For the most part, software internationalization assumes that all of the locale-specific parts of a product can be in the user interface and separate from the locale-independent core of the application. There are theories, however, that all technology is rooted in culture. Since software, unlike other technologies, describes and implements complex processes and activities that used to be performed by people and organizations, the core also encapsulates decision-making, rules of behavior, and patterns of actions that depend on culture. Thisimplies that the current international standards for software localizations are incomplete and should also cover the software core that was previously unchanged during internationalization. [5]
How deep beyond the user interface that must become localized varies depending on the application. For example, a drawing program has very little culturally dependent aspects because the main goal of the application is the same in all cultures. Some applications, such as an e-business framework, a web-based customer relationship management, or a web-based banking interface, are forms of real-world social relations and may require deeper localization. In order for these applications to be more intuitive for international users, they must be modeled in a way that describes how they will use motifs, metaphors, information architecture, and navigation. [5]
Object oriented programming is traditionally used to separate GUI objects from the culture-dependent information, but they fail to separate some deeper localization processing. Aspect-oriented programming appears to work better for deeper localization, since it allows crosscutting of the system into aspects. [5]
The software internationalization industry needs a better understanding of the role of culture in software design and development and the policies that need to be created. Software internationalization needs to move beyond the surface localization and recognize culture as a primary concern in the design of the core. [5]
Conclusion
Developing international software is necessary for any company that wishes to remain competitive in a global market. This allows for the system to be localized to as many markets as the company wishes to access. Although standards exist for designing these systems, they may be flawed and may need to be updated to use more modern tools and technologies.
References
[1] International, Dr. (2002). Developing International Software. Redmond, WA: Microsoft Press.
[2] Suodenjoki, M. (2001, October). Introduction to Internationalization and Localization. Retrieved from
[3] Sun Microsystems (2001). Sun Software Product Internationalization Taxonomy. Retrieved from
[4] "Lingoport Releases Results of Industry-Wide Study on Software Localization and Internationalization Readiness." PR Newswire. 2007. Retrieved October 26, 2009 from accessmylibrary:
[5] Kersten, Gregory E.; MikKersten,;WojciechRakowski,. "Software and culture: beyond the internationalization of the interface.(Research Note)."Journal of Global Information Management. 2002. Retrieved October 26, 2009 from accessmylibrary:
[6] "Cryptography”Wikipedia. Retrieved November10, 2009 from Wikipedia: