3. Localization support technology
This chapter describes the tools that support the localization process. These tools can be used for any localization or translation project, from a simple translation of a document to the localization of complex software.
Translation Memory tools
These types of tools support translation and proofreading (with the use of TM databases). To learn more about how to use translation memory databases, please consult the definitions at the end of the document.
Translation tools can be used to:
translate files in virtually any format,
do a word count of text to be translated in one or more files,
create and edit the content of Translation Memory – TM
create and edit the content of Terminology Databases – TDB There is a large number of translation applications available on the market. These include:
Trados,
SDLX,
Déjà vu,
Transit,
WordFast,
TransSuite 2000,
MetaTexis.
Software localization tools
These are applications for translating files containing software components such as the user interface or application messages. Such applications include:
SDLinsight,
Catalyst,
Passolo.
These types of applications are also equipped with functions for validating (checking the correctness of) translated components. In many cases, these functions are sufficient for checking that the translated software does not contain errors such as messages that do not fit in dialog boxes.
Tools for testing
These applications are used to carry out tests on the user interface, RTF or HTML help texts, and also contain tools for Web site testing. They are useful at the functional testing stage. The starting point for functional testing is usually the consultation of error reports generated by these applications. In most cases, all detected problems can be repaired by means of the editor in the application. Use of these applications does not render manual verification of the localized application redundant. Such applications include:
SDL Tool Proof,
SDL Help QA,
SDL HTMLQA.
Graphic editors
This type of software is used for editing graphic files. The simplest example of graphics localization could be replacing the English caption with a Polish one in the format of the file that contains layers. Localization of complex graphics tends to be extremely time consuming and requires not only excellent knowledge of graphic editors but also artistic talent. Such applications currently available on the market include:
Adobe Illustrator,
Adobe Photoshop,
Corel Draw,
Paint Shop Pro.
4. Sample projectBelow is an example of a typical localization project, which includes the localization of a program as well as the translation of the documentation and help strings. The basic steps are as follows:
File types are obtained and specific related issues are examined,
Selection of project tools,
Project plan identifying the procedures and defining the roles of each member of the project team,
Translation and proofreading,
Export to the target format and functionality tests.
4.1 The project in brief
The localization project we obtained was as follows:
the program was created using the Delphi IDE,
the online help is in .chm format (compiled html files),
the PDF documentation was created in Adobe FrameMaker. Note: many times in software localization projects the user interface has the lowest word count for translation. Contrastingly, the UI localization is the most demanding task from a technical point of view, as testing the localized interface is usually a labor-intensive process. All documentation in addition to being translated will require DTP, while online help, in addition to being translated, will also have to be functionality tested.
4.2 Evaluation of project size and adaptation of tools to be used
Suitable tools must be used to evaluate the size of the project and its subparts:
For software we have the following options:
if the source code of the application is available we can decide whether to translate the software in a TM application or using a localization tool (note: not all TM applications can be used to translate source code files; consult the program manual to check),
if the source code is not available and compiled files (.exe, .dll, …) have to be localized, an application must be used that can handle these types of files and will be able to extract translatable text. Applications of this type include SDL Insight, Passolo and Catalyst. Each of these tools includes a word count functionality, which, after all files have been analyzed, generates the word count of translatable text in the software. In our project, the total word count of translatable text is 5,400.
Online help in .chm format We have a total of 2,128 HTML files that make up the application’s online help. If we are using a tool with a built-in functionality for merging all the HTML files in the project into one, we can now import all the files into the TM tool. After importing them into the TM application, the project word count functionality will give a word count of translatable text. Let’s assume that we are using the SDLX application: all the small HTML files are merged into one large file, after which the file is imported into the SDLX Edit Tool. The log file provides a word count for all 2,128 HTML files. We also know the number of internal repetitions, i.e. words and phrases that are repeated in all the documents. Thus we know the actual translation word count.
Documentation in the FrameMaker format:
First the .fm files must be saved in .mif format so that they can be imported into the TM application. Then they must be converted to a file format that the application’s editor module can handle. Most tools of this type provide a batch import functionality for files of the same type and save the results into a log file, so that even if large numbers of documents are to be translated, we immediately know the actual translation word count and the number of internal repetitions.
Problems that can arise when evaluating the size of the project:
If we do not have an application that can fuse all the HTML files into one or more larger files, then we have a serious problem. Translating 2,128 files one by one is feasible, but it is certainly not the optimum solution. The answer is to create an application ourselves. This can be a PERL script, for example, or a simple executable that can be created using any software development environment or even the visual basic editor (or, more accurately, VBA – Visual Basic for Applications) integrated with the Microsoft Office suite or a DLL library with the applicable procedures.
Problems can also arise with specific file types if our localization tool does not handle a particular file type within the project. In this case all settings for files of this type must be defined. 4.3 Project planThe project plan must include:
the time frame for each stage of the project (translation, proofreading, testing),
specification of reference materials to be used during the project,
all necessary documents needed for the project, such as instructions for translators, proofreaders and engineers, emphasizing issues to which particular attention must be paid,
procedures to be followed with regard to project terminology,
contingency procedures in case of problems,
a communication arrangement for project related information,
standard forms for submitting project related inquiries,
assignment of roles for each member of the localization team for the specific project at hand.
Which of these documents will be required and helpful in a specific project depends, of course, on its size and complexity. For large, complex projects it is worth preparing all the documents listed above in as simple a format as possible, so that they are clear and helpful when the project is underway. Then the time devoted to the preparation of these documents will be time well spent. If the company does not have an experienced team and is not in a position to analyze the project or prepare a project plan, it can use the consulting services of a localization agency. Localization agencies often provide these services to IT companies free of charge.
It is certainly advisable to use them if the project in hand is large and technically complex (both often go together). Investing into localization expertise will certainly be profitable: lower costs of the translation and avoiding the risk of failing to keep a project deadline. The following reference materials will be used in our sample project:
the Microsoft glossary, containing terminology used in Microsoft applications and operating systems,
a TM database aligned from translations of a portal with a functionality very similar to the application we are translating,
databases of terminology related to asset management and planning,
during the project we will also be using online dictionaries available on the Internet covering related subject areas.
4.4 Execution of project
It is important that the project be carried out in accordance with the plan prepared in advance and on the basis of the instructions developed for the project. During the project the need may, of course, arise to review some of these items, such as the time frame for a particular task.
Translation of the user interface:
If an application is developed in Borland Delphi, the optimum solution is to use either a localization tool or a TM tool capable of handling this file format. After translation, the text is proofread in the same environment.
Translation of help strings:
If the SDLX application is used, for example:
the HTML Utilities option is used to merge all the files into six large HTML files, containing approximately 400 source files each,
these files are imported into the SDLX application (converted from HTML into .ITD, i.e. a file format in which the translations can be carried out using the SDL Edit module)
Functionality tests:
Once the application is compiled, the appearance of all the windows in the application must be checked. It is best to begin this stage of the project by using a tool that can automatically detect UI faults, such as strings that are too long or elements that overlap. Next, the entire application is manually tested by testers with instructions that point to issues specific to a particular application. The results of their work are forwarded in standard report format to the technical teams that rectify any problems.
Translation of documentation:
Documentation can be translated with the use of any Translation Memory application; FrameMaker format is sufficiently popular and is supported by all Computer Aided Translation tools. Proofreading, using the same reference materials, is also done in the TM application. The final step of verification of the translation is a review of the whole translation (preferably in hard copy) to spot errors or defects.
DTP:
The last stage of the project is the final formatting of the documentation. In our example, the FrameMaker application must be used for DTP, as the original documents were developed in this format. Attention must be paid to all details, such as:
using fonts that correspond to those used in the source document,
inserting localized image files,
maintaining page layout so that the appearance of the document is the same as the original.
Summary of the sample project:
The sample project described above covers the issues and problems that can be encountered during localization. It is important to point out here that when handling a particular file format for the first time, specific technical problems connected with translating these files are to be expected.
5. Conclusions
The information and examples provided in this document leave no doubt that localization is a complex process that calls for the use of state-of-the-art technologies and a team of experienced and devoted specialists. Localization teams cannot be set up ad hoc, for example for a particular project only, as that will lead to low quality outcomes. The volume of reference materials that members of localization teams must review is truly huge, resulting often in a very time consuming process. As such, quality localization services are certainly not cheap, but well worth the money spent.
[1] [2]
