Software Project Management in Practice

The increasingly global world we live in means that localization needs to be more than an afterthought, both from a technical standpoint and from a business standpoint. A shift to free-market economies and free-trade zones, privatization of key industries, and the global Internet infrastructure have changed the way business is done forever. The Web has provided a low-cost infrastructure for sales, marketing, distribution, and support of products worldwide, and the increasing penetration of mobile phones will extend these capabilities with the efficiency benefits of mobile e-business: the ability to remain connected and do business at any time, at any place, no matter who you are and what language you speak. To be successful globally, products must be customized for a local market. This customization includes product packaging and presentation (shape and size, colors, and graphics), as well as consideration of many other cultural, language, and technical issues. Local language adaptation is essential, particularly for consumer applications such as mobile location services, given that not more than 25 percent of the world population has basic English skills.

The Mozilla Project (http://www.mozilla.org), spawned from Netscape during the AOL acquisition, provides good definitions of internationalization and localization. It defines internationalization as:

Designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing code that functions equally well in any of the supported locales.

Internationalization is designing software architecture correctly so that it is easy to localize a product. This involves separating all localizable elements from the source code (i.e., in separate text files), creating a user interface that is flexible and provides sufficient space for character sets that require more space, and ensuring that the necessary character sets and regional standards are supported.

The Mozilla Project defines localization as follows :

Modifying or adapting a software product to fit the requirements of a particular locale. This process includes (but may not be limited to) translating the user interface, documentation and packaging, changing dialog box geometries, customizing features (if necessary), and testing the translated product to ensure that it still works (at least as well as the original).

Elements in the user interface that are localizable include all text, icons, buttons , and alerts. Many programming languages, including C/C++ and Java, allow localization parameters to be configured so that the correct regional standards are utilized. Regional standardization support to consider includes differences in units of measure, using the 24-hour or 12- hour clock, using different thousands separators for number formats, calendar formats, and currency and phone number formats. The two steps that go furthest in enabling a software product to be easily localized are to adopt Unicode as the character set for all operations and to correctly implement the locale functions of the programming language you are using.

A substantial industry has developed that specializes in localizing software products. Additional details on this industry and internationalization and localization in general are available from the Localization Industry Standard Association at http://www.lisa.org/.

Localization: The Voice System Challenge in Europe

Developing a voice-based system using one language is challenging. Pronunciation and grammar dictionaries must be developed and constantly refined. For a true pan-European solution to be effective, a mobile location service provider would need to develop a different system in each major market, one for the United Kingdom, one for Germany, one for France, one for Italy, and so on. Even if multiple language systems were not developed, a voice-based system would need to be designed to recognize the accents of nonnative speakers . If the system were designed to handle voice commands in English, would it recognize the distinctly different accents of the English of a native German speaker and the English of a native French speaker? Despite the driver distraction problems that might be introduced by audio and video navigation systems in the front seat, voice-based systems will continue to be expensive and challenging to deploy in Europe.

Localization: The Map Data Challenge

As discussed earlier, European consumers expect a very different look and feel for their maps compared to what North Americans expect. Localization also requires that map databases have street, city, and POI information in the languages of your target customers. This is less complicated in North America than it is in Europe, where maps must be provided in German, English, French, Italian, Spanish, and perhaps other languages. To further compound this challenge is the actual map vendor support for a seamless solution. As of 2001, creating a navigable database of either North America or Europe required stitching together map data from different vendors. In Europe, Finland is a good example of a country with little map data support, which is interesting given the prominence of Nokia and Sonera in the mobile location service space. Even in regions where you don't need to stitch different map vendors ' data together, there might be quality differences between regions (e.g., Germany and France). A subscriber using a solution in Germany with certain quality expectations might drive over the border to France and find inferior product performance as a result of poor map data. Details on how to address this problem are explored in Chapter 12.