 |
SILICON VALLEY LOCALIZATION FORUM |
Quality Issues in Internationalization (I18N) and Localization (L10N)
Authors: E.Uren, R.Howard and Tiziana PerinottiPublisher: The LISA Forum Newsletter, Volume III Number 3, August 1994
Copyright by E.Uren, R.Howard and Tiziana Perinotti 1994. All right reserved. No part of this work covered by the copyright herein may be reproduced or used in any form or by any means, graphic, electronic, or mechanical, including photocopying, recording, taping or information storage and retrieval systems, without the written permission of the authors, who may quote passages to be printed in a magazine or newspaper.1. INTRODUCTION & DEFINITION
In our experience, there is a large discrepancy between the ways that translators and engineers view the question of quality; translators appear to be concerned with the accuracy of translation while engineers are more concerned with functionality. An American dictionary gives the following definitions (among others):
QUALITY
Degree of Excellence
Degree of Conformance to a Standard
Inherent or Intrinsic Excellence
ASSURANCE
Certainty
Freedom from Doubt
Quality of State of Being Certain
Something that inspires Confidence
The purpose of a SW Quality Assurance function in a SW developer's organization is to help answer the question "Is this product sufficiently error or anomaly free that it may be released for use?"
For the purpose of this article, we will focus on I18N issues, those features that must be added to American code so that it may be adapted easily for use in other locales. We will assume that the reader has some familiarity with Testing or Quality Assurance procedures as used in American SW companies. Time and money spent up front in planning and technical reviews usually pays off in the form of fewer mistakes and changes later on in development. Some companies involve their best domestic customers at the design stage and this may be desirable with overseas customers too. Keeping things short and simple is a good strategy too. Part of the Quality Engineers' role is to play Devil's Advocate to developers and like everyone else in Marketing, International, Documentation and Technical Support the earlier they are involved in a project, the better. But Quality Assurance engineers who have only worked on US code need to verify features that their US experience does not prepare them for, and it is those features that we discuss below. We do advise you to keep track of what problems you find during development and localization. Then it may be possible to figure out either ways to prevent these anomalies occurring again or ways to automate finding them in your next project. Have a project post-mortem with all parties that were involved.
Quality Engineers sometimes use automated regression suites; there is an opportunity here to localize them too for testing localized SW. Some translation tools extract and replace text strings, handle increased space considerations, merge new engineering releases with previous translations and pseudo-translate. Some have versions for SW, documentation and Help that can consistent terminology in all three. We do not have space to discuss any of these tools.
2. "FIRST-TIME" FUNDAMENTAL ERRORS
In our experience, US programmers involved with I18N features for the first time can make some fundamental mistakes. Therefore particular care should be taken to verify the basics. Are strings hard-coded rather than placed in resource files, are hot-keys in resource files as they should be, and are dialogue/message boxes dynamically sized? Are extended characters used as word delimiters, are all characters imported and exported correctly, do decimal tabs work, is case conversion correct, and does sorting conform to a locale's rules? What about basic numeric, date, time and currency formats? Do they conform to the orthographical rules of the target language? Spell checkers, hyphenators and other third party SW need to be verified as do kerning and leading. Concatenated strings and strings with two or more variables might ignore gender variations and plurals or result in a sentence order that is incorrect. Printing and displaying characters for all fonts, displays and printers is basic. Can you input characters, parse input strings, and are character and word boundaries correctly defined? Are measurement scales and page sizes appropriate and is clipart acceptable? Testers need to verify that there are no errors in these basics.3. ADDITIONAL TESTING PROCEDURES
In testing a localized product's functionality, a tester has two additional procedures when compared with testing the US product. First, there is a "sibling" product available which itself has undergone testing and whose functionality is available for comparison. Therefore a suspected anomaly can be verified on the other product. Second, resource files from different localizations can be swapped. It should be possible to swap French and German and US versions of resource files, for example, and that can assist greatly in focusing on a problem area in the code.One of the most difficult test in retrofitted code is to ensure that all necessary strings have been identified for translation. We know of no structured procedure for detecting all strings although some companies do have proprietary tools.
Of course, here should be consistency of translation, that is in the terms used, between the major components of a SW product, namely documentation, Help and Software.
3.1. SW Testing
3.1.1. "Localizability" Testing on International English version
It is possible to test whether the Software contains many of the internationalization or "localizability" features on the basic US version before any actual localization has taken place. And it is an article of Quality Assurance faith that the earlier an anomaly is found, the easier and cheaper it is to fix. Basically, what the testers can do with the internationalized, but not localized, code is test whether all the additional features work correctly.
The scope of this testing can be greatly enhanced if there is a tool available that can:
extract text strings,
perform a pseudo-translation incorporating both the anticipated extra characters and taking additional space,
and then insert the pseudo-translated strings back into the code.
Use of such a tool assists quality engineers to test the display and printing of characters, the anticipated sizes of menus and dialog boxes, string resourcing and basic functionality at a very early stage in the development process, even before a version of the code has been given out to translators. This reduces both the amount of time and the number of times that there are two different versions of the code, the one that engineers are developing and the one that translators are translating. And there will probably be fewer engineering corrections to make later in development, after real translations are re-inserted into the code.In the realm of text processing, test the input, display and output of characters (including their order and direction if dealing with non-European languages), the import and export of characters to other applications, the processing of Multi-Byte and Double-Byte and Single-Byte character strings, the use of concatenated strings and strings with embedded parameters (in particular verify that word order is grammatically correct in the target language). In testing multi-byte strings, areas of interest include verification that characters are correctly deleted, that they copy and paste correctly, that searches perform correctly and finally that lines break correctly on the screen and in printing.
3.1.2. Localized versions
Localized resource files, being of a different size than basic US versions, are arranged differently on disks and so it is necessary to test installation procedures. Depending on the strength of your overseas organization, arrange for some beta testing. An advantage to localizing in the target country is that it provides the opportunity to verify the localized product's functionality on more of the typical computer environments than may be available in the US home office and with more localized versions of third-party SW.3.1.3. Subtleties There is an increasing tendency these days to use the operating system's I18N support. One subtle issue as a result is whether it is "all right" for I18N features to change with the OS or not. For example, a Parisian French localization might take on some German characteristics (currency or numeric formats to name two) under a German OS even though menus may still be in French. So it may behoove testers to test the application under a localization of the operating system different from the one planned to see if the application's I18N support overrides the OS's support.
The increased pressure to produce localized versions within at most a month after the completion of the basic US version intensifies the following predicament for localizers. They will have started to localize incomplete engineering releases of the product; as bugs are discovered in the basic code and corrections are made to the code, documentation and Help, new engineering releases get out of synchronization with the releases being translated. Merging the two can be difficult and therefore can easily introduce errors unless a rigorous oversight of resource ID numbers and a rigorous build transfer process is maintained.
The DTP package used for documentation must handle all contemplated target languages. Even when it appears that a package does fulfill this requirement, it is possible that different releases exist for different languages, a compatibility problem. For example, the French version of a DTP package may be two engineering releases later than the Japanese version and therefore may contain features that are just not present in the Japanese one. One obvious strategy is to keep everything as simple as possible, including the requirements on the DTP package itself.
3.2. Translation Errors There is no alternative to using Native Speakers in the translation process. In other words, the translator should be able to pass for a native of the target locale. Such a person can recognize if the language is from another locale (e.g. France, Quebec, Switzerland, Belgium). And of course, the translator should be up-to-date in the application's terminology. The conventional method for verifying translations is for an editor or proofer (in other words, another person) to review the translations; another method that is rarely used is to have another translator reverse-translate a small sample back into English so that the original author can compare that with the original. A reasonable similarity may induce a "warm fuzzy" in any mono-lingual developers. In certain cases, the question of translate versus re-write arises. Purely American examples need to be replaced by examples that are more appropriate to the target locale. It is entirely possible that a Japanese reader would expect more graphics and less text than an American is accustomed to, so perhaps the Japanese version of documentation should be re-written rather than translated.
The use of hypertext adds a dimension that needs to be checked after translation, namely, are the hypertext jumps preserved? Less obviously, spurious leading and trailing blanks may be introduced during the translation process, hot-keys and quotation marks may be mismatched or hot-keys may not be unique.
Note: Tiziana Perinotti, creator of the Silicon Valley Localization Forum Web Site and co-author of the article "Quality Issues in Internationalization (I18N) and Localization (L10N)", has been quoted several times in the article "Successful On-Demand Multilingual Web Publishing" on LISA December 1996 Newsletter.
LISA Secretariat
7 Route du Monastere 1173 Fechy, Switzerland.
Tel: +41 21 821 3210
Fax: +41 21 821 3219
E-mail: admin@lisa.org