Software localization is one of Logrus’ core activities. The major stages of this process are as follows:
1. During the preparatory stage, Logrus discusses volumes, milestones and languages with the client, negotiates terms and conditions with translation vendors, determines the size and structure of the localization team, and assigns a project manager (PM).
2. When source materials are ready for localization, the client sends them to Logrus. The package will most likely consist of the following:
- The product itself together with its localizable resources and/or help source files.
- A replication of the build environment (or its subset) constructed by the developers at the client’s site.
- A list of translatable resource files with format descriptions and translation guidelines. Any product-specific guidelines, tips, and recommendations are always welcome.
- Product test cases and functionality descriptions which are essential at the testing stage.
- All proprietary and custom tools, methods, and data that are unique to the product being localized, plus lists of strings that must not be translated.
3. The next stage is the preparation of tasks for outsourcing. It involves selecting pieces for translation and converting the files into a format that is convenient for the translation vendor. This stage is very important because:
- Although most of translation companies do have sufficient experience to work with complex file formats, for productivity reasons it is better to provide them with source materials in such widely accepted formats as MS Word .doc, .rtf, or .htm.
- When translators deal with source files that contain not only translatable text but also pieces of code, there is a high risk that they will inadvertently corrupt the code.
- When a new version of a product is released, developers and technical writers rarely re-work everything. Many strings and sentences are inherited from previous versions of the software and help files, and a variety of similar phrases, strings and sentences, known as repetitions, are often found in different parts of the code and documentation. Legacies and repetitions need to be translated only once, after which they can be recycled repeatedly through the use of translation memory (TM) software, which enables “source-translation” pairs to be stored in a database and accessed as needed. We use TM whenever possible, and provide our client with the resulting database.
4. The localization phase always starts with terminology glossary development.
If there is no preexisting glossary, it is strongly recommended that its creation be outsourced to professionals.
5. The newly created or updated glossary is sent for review to an independent evaluator — i.e. one of the client's business partners who has extensive knowledge of the product.
6. While the translators work on the new language of the software interface, help files and documentation (steps 7 and 8 below), Logrus software engineers examine the materials provided by the client. They set up product build environments and reproduce the compile and build procedures and string re-imports. This stage usually requires the support of the client's product developers, though we strive to minimize the number of questions we ask them.
7. The software interface, help, and documentation are translated using the finalized glossary.
8. Translated files are sent for an independent selective review before they are returned to Logrus engineers.
9. Logrus usually works on several languages simultaneously and keeps work on the Pilot Language approximately one week ahead of the others.
Before creating localized builds, Logrus engineers re-import translated units (strings, sentences, and phrases) into the source files and/or perform any necessary conversions. This can be a multi-stage process. The resulting localized files then undergo integrity and format checks using both Logrus-proprietary and third-party utilities.
10. A localized product is never released after just one build. At such an early stage, there can be quite a number of bugs: functional glitches (some elements of functionality are lost after the user interface is translated), truncations, hot-key clashes, language-specific problems and other troubles. Functional bugs usually arise from "over-translation" (when a string that should have been left untouched is translated by mistake) or from translations that are technically correct but too long. These are sometimes tricky to locate and fix, but, due to the extensive experience of Logrus’ software engineers with a variety of products, an answer will definitely be found. If changes in the code are necessary, either the project manager or the engineers will promptly raise the issue with the client, describe it in detail and offer appropriate solutions.
11. Each build goes through quality assurance (QA) testing and bug-fixing. Any bugs identified are entered into a special bug-tracking database that includes such data as product name and version, build number, language, severity, and a detailed description of the bug (bitmaps are attached where needed). In fact, it is quite common that during localization some bugs are revealed in the source product.
In addition to standard test cases and functionality checks, Logrus testers also carry out language-specific testing in areas such as character display, font usage, import-export, filenames, sorting, printed reports, templates, and date, time and number format.
Typically, three or four builds are required before the final localized product can be released to the client. QA and bug-fixing take the most time after the initial build; the number of bugs generally drops after builds two through four.
12. Testing usually uncovers inconsistencies such as missing translations or strings that need to be shortened. Such minor change requests are sent to the translation vendors, and the fixes are incorporated in the next builds.
13. The final product and final documentation (and sometimes even the intermediate builds) are presented to the client for evaluation before being released.
14. After the completion and delivery of the project, the Logrus project manager maintains responsibility for the product and provides on-going support that may include processing minor patches and handling updates.