Making Life Easier for Translators
- Localization kit: A subset of tools, source files, and binary files that can be used to create a localized edition of a program. Generally given to translators or third-party contractors.
Setting up a proper development environment, as just discussed, can go a long way toward ensuring world-readiness. Developers can have a significant impact on the translator's job, a particularly important task since translation is not cheap-most translators charge by the word. Developers can help maximize the accuracy of translation and minimize the amount of support translators need in a number of ways.
First of all, clarify the context of strings that should be translated, preferably by providing comments in resource files or separate text files. Does the English word "integral" refer to the mathematical operator, or is it an adjective meaning "important"? Does a particular string appear on a dialog box, menu, or button, or in a message? If a string should not be translated, try to put it in a separate resource file where the translator won't even see it, or use a standard way of naming identifiers. For example, you could prefix identifiers for debug messages that shouldn't be translated with "IDS_DBG" or with an underline, as in "_IDS."
When composing messages or other translatable strings, watch out for slang, sloppy grammar, and ambiguous words or statements. Translators will have a hard time understanding poorly worded messages, and so will international users. Have a linguist or a professional writer edit messages for clarity before you send them for final translation. This will increase the accuracy of translation as well as improve the quality of your native-language product. If translators know which strings to translate and how to translate them, they will be able to work much faster. Their work will be more difficult if terminology is inconsistent within a single application or among different applications, and if adequate tools for editing and updating resources are not available.
Indeed, there are many localization tools that can expedite translation. Some, for example, allow both you and the translator to create translation glossaries that you can share with other software projects and use for automatically translating resource files. (Microsoft supplies translation glossaries at http://www.microsoft.com/globaldev .) Machine translation software is also becoming commercially available. Automatically translated text still requires editing, but editing often takes less time than translating from scratch.
Giving translators a localization kit will allow them to work more independently because they can compile and check their work as they do it. Passing files back and forth among development, translation, and testing departments is simple when all parties are on the same computer network, but is more difficult when the translators are third-party contractors who work in different countries. Express-mailing floppies, CD-ROMs, or portable hard drives is one option, as is exchanging files via the Internet.
Just as localization should begin early in the product cycle, so should testing of localized programs. It's very tempting to concentrate all testing efforts on the domestic product in order to get it shipped quickly. Early testing of all editions, however, ensures that development is paying attention to international issues because it often uncovers serious bugs in the core code.
When deciding whether to fix a bug, determine how much time fixing it will require and how crucial the fix is to the finished product. Does the bug make the program unusable? If not, will it seriously affect sales in any important target markets? Maintain common standards for all language editions of your product. Never postpone fixing bugs found in your domestic software product that will affect international users.
At the end of the product cycle, when the domestic product is close to shipping, it is tempting to postpone fixing bugs that arise only in localized software until after the domestic product ships, out of fear of "destabilizing" the domestic edition. But every time you delay fixing an international-related bug, you are postponing all of your international releases. If your domestic product will ship in a few days, postponing a few bugs exclusive to localized editions is not a big deal. However, many experienced developers have worked on projects that were in ship mode for weeks, months, or even years. Under these circumstances, allowing international bugs to pile up is dangerous and leaves unresolved a significant number of changes that you will have to merge with the sources for the next product release.
If you plan to ship a single international executable, you really cannot postpone fixing bugs related to world-readiness. Developers of localized editions might need a few extra weeks after the domestic edition ships to make changes to resource files, Help files, or sample documents; but once your single executable is done, it should be done for all languages. Of course, this won't always happen, but striving for this ideal will definitely benefit the ship dates of your localized editions.