Software localization is one of Logrus’s core activities. Let’s have a look at the major stages of this process.
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. Most likely, the package will consist of:
- 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. Next comes the stage of preparing tasks for outsourcing. It involves selecting pieces for translation and converting the files into a format convenient for the translation vendor. This stage is very important because:
- Although most of translation companies do have enough experience in working 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, 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 that they can be recycled multiple times using 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 make the resulting database a part of the delivery to our client.
4. The localization phase always starts with terminology glossary development.
If there is no glossary yet, 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, for example, to one of the client's business partners with extensive knowledge of the product.
6. While the translators are working on the new language of the software interface, help and documentation (steps 7 and 8 below), Logrus software engineers are busy examining 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 although we do our best to reduce 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 with the Pilot Language approximately one week ahead of 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. Then the resulting localized files 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 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 are too long. These are sometimes tricky to locate and fix, but due to Logrus software engineers' extensive experience with a variety of products, an answer will definitely be found. If changes in the code are needed, 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 for client’s acceptance before being released.
14. After completion and delivery of the project, the Logrus project manager remains responsible for the product providing on-going support that may include processing minor patches and handling updates.