New Approaches to Creating and Testing
By: Harry J Robinson Sankar Chakrabarti
Creating high-quality software that runs in any language is a big challenge. By
changing our development process to stress early defect detection and by using
the World Wide Web as a collaboration tool, we have dramatically improved
the quality of our internationalized software.
Most software companies want to sell their software in every country
in the world. Since users prefer to use software in their native language, it
makes good marketing sense to develop software that can run in those
languages. After the initial investment has been made to write and test
software in English, a software company can make significant profits by
reselling the same software to other countries if the cost of conversion into
other languages can be kept low.
Traditionally, software testing occurs at the end of the development cycle. This
kind of testing works against creating high-quality software. When bugs are
found late in the cycle, there is little time to fix them. This is especially true
in internationalized software development where the developers, testers, and
translators are spread all over the world. Our new approach allows a team
to test the software during the entire process and to
release foreign language versions simultaneously with
the English version.
Developing Internationalized Software
The I18N Approach
One common method of creating internationalized software
at a reasonable cost is called I18N.* The essence
of the I18N approach is to separate the executable code
from any character strings that the user will see. User
messages are placed into files called message catalogs.
Two numbers, the set number and the message number,
index each string in the message catalog. The executable
code uses these numbers to retrieve strings.
For example, every C language programmer knows the
classic hello, world program:
In the I18N methodology,1 this program would be written
printf(catgets(my_cat, 1, 5,
”hello, world\n”) );
The program accesses the string “hello, world\n” by retrieving
set 1, message 5 of the “hello.cat” message catalog file.
5 hello, world\n
The string “hello, world\n” that appears in the printf statement
is a default string that is used if no message catalog
file can be found.
Separating executable code from user-visible strings is
very useful when working with translations. If we want to
run our hello, world program in French, a translator merely
changes the string in the message catalog to:
5 bonjour, le monde\n
* I18N = I[nternationalizatio]N. 18 is the number of letters between the I and N.
Users running the hello.c program with the translated
message catalog will see bonjour, le monde as their output.
No changes are made to the executable code to support
the French version. Only the user interface strings need to
be translated. The executable code remains unchanged.
Figure 1 shows an example of what a typical application
Help menu looks like in both English and French. The
same executable code was used to generate each menu,
and only the message catalog was changed.
The idea behind creating internationalized software is conceptually
simple, especially when the number of languages
is small and the application is as simple as hello.c. On the
other hand, producing real-world applications in a dozen
languages can pose several challenges to a development
The shaded area in the diagram in Figure 2 shows the
traditional process flow for developing an internationalized
1. The programmers write an application with the appropriate
I18N calls for fetching strings from the message
catalog. They also produce the original message catalog
2. The message catalog is sent to translators (called
localizers) who translate each string into a target
language, such as French.
3. The application (with the original message catalog) is
delivered to the test team, who verify that everything
Internationalized software has great advantages for the
marketplace and is a worthwhile and growing trend, but
high quality levels can only be achieved if internationalization
is integrated with the rest of the software development
process. Current development models do not
encourage easy integration of coding, localizing, and
testing. We have designed tools to promote early detection
of defects and collaboration among the different
groups involved in software creation.
... to read more articles, visit http://sqa.fyicenter.com/art/