Software localisation ist eine Angelegenheit für Spezialisten, und da alle Spezialisten in dieser Branche Englisch verstehen, ist diese Seite nur auf Englisch verfügbar.
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
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.
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.
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.
Is equivalent to a small software localisation project, with the incorporation of updates.
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
|© by FXM||office[at]fxm.ch|