• Software/GUI (Graphical User Interface)
• Online Help (e.g. RoboHelp, Doc2Help, HTML Help Workshop)
• Documentation (FM, Textformat/Word, XML)

• Quality (use of customer terminology, consistency between GUI and help file/documentation, validation of GUI (buttons, dialogue windows, hotkeys), validation of Online Help (links, goto addresses)
• Time considerations (small time window for GUI, because product must be ready with all components)
• Cost (minimising reworking, increasing efficiency, increasing speed of translation)

• Alchemy CATALYST (GUI - preparation and clean-up of the Translation Kit)
• Trados/Transit (Online Help, documentation)
• Help QA
• Original version of the software (to be reviewed by the translator)

Analysis:
Difficult for GUI: cost evaluation (aided by analysis function in CATALYST, not a problem for Online Help and documentation using Trados)

Creation of the Translation Kit:
(Importing various file formats (.DLL/.EXE/Java/.RC) into CATALYST - .txt files (ReadMe) can also be edited.

Translation:
usually TTK files created with CATALYST

Validation:
Check for completeness
Spelling
Consistency
(typical errors: duplicated Hotkey entries, clipped text in objects [buttons, text fields], overlapping objects)

Possible creation of screenshots

Compilation of Online Help, creation of PDFs

Delivery:
Either in the original format, as a file export from the TM tool, or delivery in TTK format

Software Localisation

A software package normally consists of the software, the Online Help and the corresponding documentation. Unlike a "pure translation process", a software localisation process involves three different sub-projects and usually includes many more files of various formats requiring more steps, such as compiling Online Help, testing localised software and Online Help, creating screenshots and much more. Guaranteeing consistent terminology across the three sub-projects is an important issue in projects of this kind. If a button is called 'Green' in the software, then it must also have the same name in the Online Help and the documentation.

The first step in a software localisation project is, or should be, the localisation of the software of the user interfaces (also called the "GUI" = Graphical User Interface). This is the best way to create the required consistency between the three sub-projects. We first translate the terms in the GUI, agreeing them with the customer where required, and then importing them as a glossary into the terminology system of the translation memory tools that we will use to translate the body texts in the Online Help and documentation files.

In our experience, software localisation accounts for about 30% of the project volume of a localisation project, the rest being taken up by the translation of Online Help and documentation. If you begin the project by translating the Online Help or the documentation and only then localise the software, then you may have to adapt all the already-translated Online Help or documentation files to fit the different terms arising from the subsequent interface translation - extra work that can be avoided using the procedure described above.

As mentioned above, specially designed localisation tools are used for interface translation. These provide excellent support for the engineering component when preparing and cleaning up the Translation Kit before and after the actual translation phase. For example: If earlier versions of the software have been localised, then the localisation engineer must carry out the "leverage" between the existing TM files and the new files. This does not merely involve using Fuzzy Matches and Exact Matches to reduce the amount of translation work carried out on the interface strings, it also entails making the correct settings in order to coordinate the dialogue resizing of the current version so that it adopts the dialogue resizing from the earlier version, where the objects have not been altered. This option makes the task of dialogue resizing a great deal easier and was not available in earlier localisation tools. It means that only new objects or objects that have been changed need to be adapted.

Quality Validation and testing of the localised interface are important tasks in the localisation process. They can be simplified and automated using modern tools such as CATALYST. For example, CATALYST provides 40 check parameters that the system uses to automatically search the Translation Kit for typical localisation errors (such as overlapping objects, clipped text in objects, duplicated Hotkey entries, etc.,) and list them in a report. When the localisation engineer clicks on one of the errors, the system immediately displays the corresponding object, and the error can be removed on the spot. The engineer no longer has the arduous task of searching through the source code files.

Online Help and documentation are translated with other TM tools that are better suited to the translation of body text (e.g. well-known TM tools such as Trados and Transit). There are currently limited options for direct data transfer between the software-oriented localisation tools and the TM tools mentioned above because the objects contained in the software differ too greatly from the objects in the texts. Various committees are working on standardising the data interchange formats in order to allow closer integration between the differing tools.

Online Help must be considered together with the software application and deserves special mention at this point. Online Help is only translated within the framework of a localisation project. Online Help files are usually written as text files using special Help authoring tools (such as RoboHelp, Doc2Help, HTML Help Workshop and others), but using special Online Help tags, links and formatting attributes. These are then compiled into executable Online Help programs that can be included with the software application. The original files created using the Help authoring tool can be translated using TM tools, in the same way as the documentation files. Afterwards, however, the localisation engineer must recompile them and test them. This requires appropriate familiarity with the various Online Help tools and very good knowledge of the structure and workings of the objects contained in the Online Help (i.e. links, tags, jumps, hot spots for animated screenshots, pop-ups, etc.).

When translation has been completed, a quality validation cycle is performed. This means that the translation is checked for completeness and style, consistency in terminology and consistency with regards to the customer's terminology glossary, correct spelling/grammar, etc. After that, in agreement with the customer, the layout of the translated pages is checked and, where necessary, edited and reformatted using the original DTP editor. The last step in the process is the delivery of the translated document to the customer and internal administrative tasks such as formatting and archiving the new TM files for additional update translations for the customer.

Basically, documentation belonging to a software package is translated in the same way as described in the steps outlined above. A software manual, however, also requires additional QA tasks, especially consistency checks against the translated terms from the software interface, insertion of screenshots (pictures of the software interface) and so on.

SAM Engineering uses CATALYST when localising 32-bit software applications. CATALYST makes it possible to accelerate the engineering phase of a localisation project as well as the translation of user interfaces by using comprehensive functions that enable direct editing of binary files (e.g. .EXE, .DLL).