3. TRANSLATION METHOD
The translation approach depends largely on the tools strategy adopted by the software publisher, i.e. whether they have developed their own tool set or elected to use the standard commercial tools?
Either way, the vendor will need to decide, if the publisher has not already decided, how to send the files out for translation. In general, one of the tools listed below is used for software translation:
• Text editor
• Resource editor
• Software localization tool
• Translation memory tool
The choice of tool should be based on the criteria below:
• Publisher instructs the vendor to use a specific industry standard tool.
• Publisher instructs the vendor to use a proprietary tool. Some software publishers, such as Lotus and Oracle, have developed their own localization tools, which have to be used on all projects.
• Did the publisher instruct you to use a specific tool, or were you provided with a proprietary tool? Some software publishers, such as Lotus and Oracle, have developed their own localization tools, which have to be used for all their projects.
• Are the investments for developing or purchasing a translation tool justifiable? For example, a 3000 word software user interface project may not justify the costs of purchasing a professional tool like Corel Catalyst.
• Which method is safest, i.e. how can we minimize the risk of translators damaging or altering the software code? If the software is translated using a text editor, it is very easy to inadvertently alter the code surrounding translatable strings.
• Is the file format supported by the tool? For example, binary software files such as .dll files are not supported by translation memory tools.
• Is it possible or easy to re-use translations if updates need to be processed during the project?
• Does the tool support all target languages, especially double-byte or bi-directional languages?
In most cases, a software localization tool should be used on binary files (such as .dll files or Mac OS executables) and standard resource file types, and a translation memory tool should be used on custom resource file types or database strings in text format.
In the case of custom software file types a text filter or parser will need to be created using regular expressions in a scripting language such as Perl or Awk. Regular expressions are patterns used for searching text in data.
4. MARKING
Depending on how well the source files have been programmed, localization engineers should browse through all text strings and include marks and comments if necessary. Here are some examples of comments that could be added to strings:
• Do not translate!
• Do not use more than xx characters.
• Translation leveraged from operating system glossaries, please review.
• This message is concatenated with message ID xx.
• Do not delete hot key symbols.
• Leave trailing space in string.
• Do not change order of variables.
If the developer of the source material has internationalized the application fully, i.e. separated all translatable text from software code, it should be relatively easy to comment or mark the strings. However, if the resource files contain many strings that should remain in English, marking the strings will be quite a time-consuming task, but it is worthwhile doing this on multilingual projects, where the same items will be
translated for all languages.
责任编辑：admin
上一篇：LANGUAGE SETTINGS FOR SOFTWARE TRANSLATION
下一篇：Mac OS Software Localizing
微信公众号搜索“译员”关注我们，每天为您推送翻译理论和技巧，外语学习及翻译招聘信息。