Once all the source material is complete and compiles without errors, it is important to address the following issues:

• Which files need to be translated?

• Are existing translations available that can be re-used, or leveraged?

• What is the most efficient translation method or approach?

• Do marks or comments need to be inserted in the strings for the translation team?

• How can the software code be protected, for example by using a filter, tagger, or parser for a translation memory tool? If no existing filter, tagger or parser is available, is it possible to create a customized tool?

If the source material is well prepared, the translation kit will make life easier for translators, and avoids unnecessary re-translation of previously translated text.

1. TRANSLATABLE FILES

If the localization kit does not contain a list of "translatable" files, locate them in the build environment. In Visual C++ or Visual Basic projects, translatable strings are usually included in .rc files. It is advisable to check all files, as programmers often include translatable text in files with extensions such as .str, .txs, .dlg, msg or .txt. If there is any uncertainty about the translatable files, create a list of these files and verify this with the publisher.

On the Mac OS platform, translatable resources are usually embedded in the executable itself. Here, it is more important to identify which resource types within the executable require translation.

In addition to the resource files, it is important to identify any image files that may need to be localized, such as bitmap images of splash screens, or buttons used in the software.

2. LEVERAGE

With most software localization projects, it is possible to re-use existing translations from the following sources:

• Project glossaries

• Previously localized versions of the software application

• Localized versions of other applications from the same publisher

• Operating system glossaries

Re-using existing translations not only reduces the word counts, it also increases the speed of translation and improves terminology consistency. For example, if version 4 of a Windows application was being translated, it may be possible to pre-translate 90% of the application if a localized version3 exists.

If no previously localized versions exist, it is possible to leverage translations from operating system glossaries. Most applications contain standard commands or menu items such as File, Edit, Save As, or buttons such as Cancel and Apply. Try pre-translating these items using the operating system glossaries before sending source material out for translation. For more information on operating system glossaries.

The way in which existing translations can be leveraged depends entirely on the file format and the translation method chosen. Most software localization tools include features that enable the user to import previous translations or glossary items. Some localization tools, such as Corel Catalyst, also enable the user to re-use resizing information from previously translated and resized versions.

When using a translation memory tool to translate software resource files, convert software glossaries to translation memory databases before the translators start working on the files. For more information on translation memory.