Biomedical Computing and Standards



Software Internationalization

Dallas Ramsden

Computer Science and Software Engineering Department

University of Wisconsin – Platteville

Platteville, WI 53818

ramsdend@uwplatt.edu

Abstract

Software is a universal language; if developed properly, there is no reason why the same software system cannot be run anywhere in the world. The system can perform the same regardless of the local language, formats, and other cultural specific elements of that particular location. This paper looks at processes, standards, tools, and methodologies to help facilitate an efficient way to produce internationally usable software. In the words of Tom McFarland, Internationalization Architect – Hewlett Packard, “internationalization is not a feature!”

Introduction

World Economics

A need is what drives development and with software there is no exception. With the growth in the power of other countries’ economies, the need for software development within those regions is too great to ignore. For example, China has replaced America as the world's largest exporter of IT goods. In 2005 China exported $180 billion of mobile phones, computers, and other digital equipment, exceeding America's international sales of $149 billion. Earlier, in 2003, China's technology exports had surpassed those of both Japan and the European Union [1]. Refer to Figure 1.

[pic]

Figure 1: Exports of Technology and Telecom Goods [1].

Although this particular example is with China’s digital equipment exported, it should be noted that with digital equipment, software drives a large portion of functionality. Thus, this growth can validly be applied towards a growing software engineering market. This growth thereby creates a need that can be fulfilled by any efficient company, regardless of its geographical location in the world Business will need to address this need effectively to stay competitive. Software internationalization processes is what will allow this.

Internationalization

Internationalization, abbreviated “I18N,” provides framework and structure in which localization, discussed hereafter, can take place. I18N allows the dynamic bindings of language and local conventions into the software. The goal of I18N is to have software that can run anywhere in the world without having the source code changed or recompiled for the different language and conventions. To be achieved, the software must be independent of language, code pages, and local conventions – only at runtime will the software determine which conventions and code page to use in interpreting the data. Take a steering wheel as a physical analogy. A steering wheel does the same function regardless of what type of car it is in or where that car is being driving; the steering wheel steers the car. In America, Canada, and Costa Rica the steering wheel is on the left side while in Japan, the United Kingdom, and Australia the steering wheel is on the right. An I18N solution would be to develop a mechanism in which the steering wheel could slide into either position, depending on location, and lock. The mechanism demonstrates I18N; the position represents localization, and the steering wheel as software functionality. Of course with some things this may not always be physically possible, but with software it is possible and highly encouraged.

Ideally, internationalization should start during the design of the system so that errors and problems are identified and fixed in the early stages of the process. A system built around internationalization practices result in the reduction of time and cost to market [2].

Localization

Software localization refers to adapting software from one culture to another. It is a complex process, requiring careful coordination between phases of work, and requires the collaboration of different professionals ranging from translators, graphic designers and programmers to marketing experts. Example tasks include the work of: translating the user interfaces from one language to another, accommodating for different alphabets, and adapting the system to be acceptable within a foreign culture is needed. It is possible that references to history or culture may need to be replaced with an equivalent native reference. Done on a per-project basis, this process is labor-intensive and requires significant effort from development teams [2].

To assist in minimizing this complexity, software “locales” are created. A locale is a set of files and software objects which define the language and specific cultural conventions to be used. Done correctly, localization is the process of adjusting internationalized software to a particular locale; software internationalization is a prerequisite for localization [3].

Process

Considerations

Locales must identify and deal with any attribute that changes from region to region. Many issues arise in the format of printed standards. This includes, but is not limited to, measurement formats (e.g., centimeters vs. inches), number formats (e.g., different thousand separators), time formats (use of the 24-hour vs. 12-hour clock), and sorting rules (different alphabetical orders), etc. Cultural-dependent or ambiguous symbols such as body parts (e.g., hand gestures), religious symbols, graphics with more than one meaning and cultural- specific symbol (e.g., the stop sign) should be avoided, as they may lead to misunderstandings [4].

Locales use different character codesets (e.g.: 7-bit ASCII, EBCDIC, Unicode) and fonts (e.g.: Latin, Hebrew, Cyrillic). According to [3], some suggested basic procedures to follow in order to ensure unproblematic software localization are as follows:

• Compose decimal numbers and dates from dynamic lexical units. Such lexical units are strings that contain a locale-specific representation of a fraction sign, currency symbol, and date format separators.

• Do not assume anything about text directionality. Semitic languages such as Hebrew and Arabic and are written right-to-left, as opposed to European languages. Some Asian languages are written bottom-up. Consequently, menus, frames and pages are aligned differently in such languages.

• Avert from hard coded literal text in system code. Use string tables or environment variables as an alternative.

• Use wide characters in place of narrow characters. C and C++ support the wchar_t datatype. C++ also provides the wstring class. Use these types instead of char and string.

• Deal with other calendar systems appropriately. Calendars such as the Hebrew, Chinese, and Muslim calendars may be used in addition to the Gregorian calendar in certain locales [3].

Outline

Once region-specific problem attributes have been identified, the team can then initiate the development process. A sample software localization outline is as follows, courtesy of RIC International [5].

A. Preparation:

1. Analysis of the product and assessment of the level of its Internationalization

2. Freeze source code

3. Terminology research and Glossary development

4. Create Localization Kit*

5. Pre-production planning, creation of a project schedule, setup of the project team

B. UI Localization: Translation and Adaptation of User Interface

1. Isolate translatable strings from the software

2. Translate and edit software strings

3. Finalize UI bilingual glossary

4. Resize dialog boxes

5. Adapt accelerator keys, tool-tips, tab order, menu options, buttons, sorting orders in list boxes

C. UI Localization: Testing and Delivery

1. Functional testing of the localized product

2. Linguistic testing of the localized product

3. Client Review of UI

4. Freeze localized UI

D. Localizing Online Help and Translating Documentation

1. Screen Captures taken and incorporated in documentation

2. Help files and documentation translated and edited

3. Compile help files

4. Format translated documentation

5. Online Help Testing (including consistency checks against localized software)

E. Client Review and Implementation of review changes

F. Update translation memory, get ready for the next software release

Localization Kit*

Localization kit includes:

• Source files for translation

• Reference materials

• Style guide

• Contact information

• Templates for query handling

• Review process

• Schedule tracking

Notice that software help documentation translation is a very relevant issue in software internationalization. Often however, this is overlooked until the very last minute. Unfortunately, the effective usage of a software system, especially a foreign one, is directly proportional to how developed the related help is. If users can’t understand the software, they are not going to use it!

Tools

There are many tools available to aid with the internationalization process. This incomprehensive list was taken directly from a consistently updated list found on that is far more detailed [6].

Internationalization Tools

Tools that help ensure that programs are properly internationalized. Internationalization tools are generally environment-specific.

▪ Borland (Delphi/C++ Builder)

Helicon Translator for Delphi, Helicon

Localization tool for Delphi applications. It uses Delphi’s native localization technology and generates localization libraries for all languages. The built-in spell-checker and the auto-translation make the translation easier and quicker.

Multi Language Designer, Lingscape

VCL component-based package for designing multilingual applications (Delphi and C++). It supports all languages, including Japanese and Chinese. It can be used with the external localization tool, Translation Workshop.

MultLang Suite 3, Lingscape

Suite of Globalization tools for Delphi & C++ Builder applications. Its features include the localization of codes, extraction of strings, automatic translation of strings, Universal Language Modules, customization of dictionaries, and QA procedures.

PolySuite Professional, Pretty Objects Computers

Internationalization suite, which offers internationalization of Delphi and C++ Builder programs at design and run-time, automatic extraction of files to be localized by a third party, automatic users creation and management as well as customization features.

TMultiLang

This software allows the developer to create foreign language versions of existing Delphi applications. CSV files can be imported from and exported to an external translator.

▪ Java

Java Internationalization and Localization Toolkit 2.0

A toolkit for the quick internationalization and localization development of Java applications.

SGIL Suite 2.0, Everlasting Suite

A suite of software tools to internationalize software written in Perl, JSP, ASP, CSS, XML, SQL, Java, C, C++, Visual Basic.

▪ Visual Basic

Localization Guru, Beta-Sigma Data System

A tool for Visual Basic programmers who want their applications to support multiple languages. The source language text is exported to a database and then translated by the localizer by means of the Localization Guru Language Editor.

ResMe String Extractor for Visual Basics, Resource Mining Incorporated

This tool extracts hard-coded user interface strings from Visual Basic source code to a resource file.

VB Language Manager Professional, Whippleware

VBLM Pro manages the localization process of Visual Basic applications from start to finish. It maintains one copy of the original source code and creates localized versions in an unlimited number of languages. Strings extracted for translation are stored in tables, by means of the Language Table Editor, which interfaces automatically to third party translation programs.

Localization Tools Software

Localization tools are specifically designed for the localization of user interfaces. They support both resource files (.rc, .res files) and binary files (.exe, .dll, etc.), and normally have translation memory and editing features. Dynamic localization tools translate the user interfaces of applications while they are running.

▪ Tools for Linux Applications

Gtranslator

A gettext po file editor for the GNOME desktop environment. Features include auto-translation, search function to look for existing translation, and navigation capabilities within untranslated messages.

Kbabel

A set of tools for editing and managing PO files. It includes full navigation capabilities, plug-in framework for dictionaries to search for existing translations, "rough translation" function, automatic spelling and syntax checking. Version 0.9.5 is part of KDE 2.2.

▪ Tools for Windows Applications

AppLocalize, Software Builders

For the localization of Windows applications: after importing .res files, one translates the items and then make AppLocalize generate new .res files. Support for Chinese, Japanese, Russian.

CATALYST 4.0, Alchemy Software Development

A fully integrated localization system that combines powerful localization tools with project management features. It includes a suite of visual editors that allows translators to see their translations in context, a secure XML/HTML editing environment, Replica for translating repetitive segments, a Quality Assurance toolkit to validate software and help files, and a range of testing, fixing and updating utilities for software engineers. It offers multiple file format support, including TMX support.

Software Translator, Eurocity Online

This localization tool dynamically translates any Windows application without affecting its source. The system dictionaries contain standard terminology and can be modified by the user.

Venona Localization Toolkit

It can be used for localizing resource files created in Visual C++ and Borland C++. Version 1.1 allows the localization of Java applications and C++ applications for any platform.

Quality Assurance

The job of an internationalization quality assurance engineer is to asses the extent to which a software system is as functional in other cultures as it is in its native culture. Standard quality assurance tasks (e.g. performance measurements, fail rates, etc.) should be left to the core quality assurance team. Internationalization QA focuses directly on I18N issues. Tasks could include verifying that strings are sorted appropriately, test for different date and time formats, the availability of alternative measurements, test the system on a reasonable set of hardware from different cultures, etc [2].

The QA team should develop an International Quality Assurance Plan. Suggested layout is as follows [2]:

Overview of Product – What is the product? What does it do? What is/are the target audience? What level of internationalization should this product be taken to?

Overview of Plan – Reasons for writing test plan. Who is target audience? A list of other relevant documents.

Purpose/Scope of the testing – States that you will be testing for internationalization enabling issues only and are not responsible for other areas. Give general types of I18N functionality that will be tested.

Exclusions – List specific areas of the product that are outside the scope of the testing and responsibility. Also list who or which group should be responsible for each area.

Description of testing approach – How will the testing be carried out? How will the work be shared? What form of automation is used, if done so? What tools are used?

Responsibility for enabling Quality Assurance – Who is testing the I18N aspects of software and who is performing the core (i.e. standard) QA? What is the relationship between the I18N QA and core QA (different groups, same group, etc.)?

Overview of required resources – How many QA engineers required? What hardware / software needed? Any special hardware or software needed.

High level view of areas to be tested – divide the testing into product functionality or I18N functionality.

General schedule.

General quality expectations.

Bug Reporting

When bug reporting, it is recommended to have I18N-specific bugs included into the pool of ‘regular’ bugs so that the developers can achieve an understanding of what is important to the internationalization quality of the product. In fact, some developers may not think an issue is a bug at all. It may take some explaining/coercing to get the developer to produce internationally acceptable code. If a bug is put into the standard pool of bugs, the developer should learn that this is an important issue to remember for the next project [2].

The description of an internationalization specific bug should include: the effect on end user, the number of users affected and how often, when (and if) the bug should be fixed, and who should be responsible for the bug [2].

Conclusions

The ability to internationalize a software product will greatly increase an organization’s competitive advantage. Internationalized software must be considerate towards the foreign host culture. It takes an in-depth amount of research and understanding of the culture for a successful system to be achieved. Although I18N takes quite a bit of work up front, the process will be learned and more efficient, that is, lest costly the next time around. Should a foreign software market opportunity exist, there really is no excuse for not obtaining it.

References

[1] December 14, 2005, Digital Dragon, The Economist Newspaper and The Economist

Group.

[2] Driscoll K., Lok J., Luong T, Taylor D., 1995, INTERNATIONALIZATION:

Developing Software for Global Markets, John Wiley & Sons, Inc.

[3] Kalev, D. (2000 August 4). Tip of the Day. Rules of Thumb for Software

Internationalization. Retrieved March 30, 2006 from



[4] Globalization, internationalization, localization: an overview. Retrieved March 30,

2006 from



&MySubcatID=1&pageID=1322

[5] RIC International Inc. 1999-2006. Software Localization Process Outline. Retrieved

March 31, 2006 from

[6] Globalization, internationalization, localization: an overview. Retrieved March 30,

2006 from



&MysubcatID=3

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download