Software localisation

And not just translation

The goal of localisation is to adapt a software to the language and culture of a new market, and this requires a great deal more than mere translation. Below, we have listed the tasks involved within a full-scale localisation project.
Since one of our guiding principles is flexibility, we can of course take a modular approach and handle any combination of these services or the entire project. In this way, we can adapt to your individual needs and work in collaboration with your internal team.
All aspects of localisation must be carried out for each new product. For subsequent versions or builds, however, it is not always essential to carry out each task.

Receiving and installing the product

The localisation services supplier must, of course, first install the software. This requires the right operating system, which may be different from that normally used by the translator. The installation should be carried out by a power-user, who will already take notes with a view to the localisation of installation procedures at this point.

Glossary creation and maintenance

The project (product) glossary is required to ensure consistency throughout all screens and documentation. Building a glossary will make it possible to first check the consistency of the source text: localisation services are also quality assurance services for the original product. Glossary creation starts with an analysis of all source texts and screens, but a glossary is never frozen before the final delivery. In fact, maintenance procedures play an important part in the overall quality of any localisation project.

User interface glossary

The first task is to list all strings in menus, dialog boxes, commands and error messages. This results in an extremely comprehensive list of all terms related to the product. A term is by no means words alone: the glossary should also contain all character strings that appear more than once in the entire product and its relevant documentation. Whether such strings must then become glossary items or be included in translation memories must be determined from case to case. External terminology resources are often required for optimum adaptation to the standards of a given computing environment. The MSWindows standard terminology, for instance, is available for developers as bilingual equivalence tables for a specific product. However, all the tables are US English based and the English-French table for a given product is not necessarily based on the same structure as that of the English-German table! Building the corresponding French-German dictionary is therefore no easy task.

General project glossary

In addition to computing terms, product specific terminology as used in manuals, CBT, on-line help or even packaging documentation mainly consists of technical jargon. This means that the localisation supplier must have a sound knowledge of the technical field, and an excellent network of specialised translators. It is important to note that a translation company, even specialised in a single field, is first and foremost a translation company, and it is the client who is the field specialist. Building the general project glossary must therefore be approached and carried out as a joint project. Usually, this type of collaboration is of surprising benefit to the client company, which gains a completely new insight into its own corporate terminology.

Software localisation

Translating all strings should normally be carried out by translating resource files, but there are still developers who think hardcoding the text is easier, or that the project is to upgrade older software where screen text is written within the code. This of course requires a very careful translator. Translators should be informed about the maximum number of characters in each string of the original screen, since adapting to this will drastically reduce resizing costs. Ideally, developers should take localisation needs into account and allow for some increase in the length of string. But this is an ideal scenario. Following the resizing of screens, a control of the localised version must be carried out, i.e. all screens must be checked visually! Language and layout errors must then be corrected. Checking the localised version also means checking the software, and if required sending bug reports and implementing the subsequent code modifications.

User manual localisation

Here again, translation is not all it takes. The writer's approach is sometimes highly culture-related, and must be modified in line with a completely different cultural environment. The old Netscape user manual, starting with "Hi Mom, I got a new job..." would sound ridiculous in French. Indexes require more than translation. Think of the German compound words resulting in several words once translated. Where do you want the index tag? For which index entry level? Re-indexing is often a must. Screen captures must of course correspond to the localised version, and are part of the manual localisation tasks, and include resizing, formatting, etc.
Screen captures may include art work. Usability testing is also part of the process: does the localised version of the user manual provide accurate help for the user? After final content QA at all levels, the user manual must still be formatted for the desired media, i.e. on paper or CD.

Online Help localisation

The content of online help is quite similar to that of a user manual, but its presentation, handling and navigation are different. In a cleverly established documentation architecture, where the writing is consistent in terms of vocabulary and style, sentences or segments are often identical in both the online help and the user manual. Using translation memory tools thus leads to greater consistency, faster delivery, and cost savings. Here again, however, translation quality is not everything, and within the localisation process it is essential to format the content, to compile the online help, to tag and test keywords and cross references, to ensure context sensitivity, and to test functionality before creating final localised online help and online manuals. And equally, the text is not everything. Help contains art work, screen captures, hotspots and other bitmaps that require capturing, creating, editing and compiling.

CBT localisation Requirements

They are quite similar to those for help, even if content and media might be different. Again, non-linguistic tasks are as important as translation quality.

Setup localisation

Is equivalent to a small software localisation project, with the incorporation of updates.

Packaging localisation

Packaging texts, labels, brochures, registration cards and various marketing texts. Here, the preferred media is often paper and the layout must be created accordingly. Here, translation quality criteria are not the same as those for technical texts, manuals or help. In this case, the objective is not optimum usability, but maximum appeal.

Other related translations

White papers, retailer information, media documentation and other texts might be part of the overall project, and require pure translation "only".

See also Web localisation and Software localisation with Multilizer