|
This document describes the localization process, as well as all the technologies, problems and methodological issues involved with localization. It should be used as a reference guide to the various processes, functions and areas of localization for anyone seeking to expand their knowledge over the subject. It is more of a factual document than that of opinion, and should be used as a study on the topic of localization.
As far as most of the IT industry is concerned, the term “localization” means translation plus “some other things”. In fact, translation is no more than one part of the entire localization jigsaw puzzle, sometimes not even the most important one. So what is localization? Though the definition varies somewhat throughout the industry, we believe that the following explanation describes localization fairly well. We will try to explain it in further detail later on in the document however, the “simplest” definition of localization is: the full adaptation of content for a local market during the translation process. Localization requires the understanding not only of specific local markets, but the understanding of actual content surrounding a given industry and/or culture. Localization and translation are codependent and because of that, they require much focus and strategy.
As such, this document also attempts to familiarize the reader with issues related to the strategy of executing localization projects within IT companies. Furthermore, this text aims to answer the question that many people in IT frequently ask themselves: What resources and technologies do we need to carry out localization projects?
If a producer wishes to sell a product in a given market, he has to provide relevant product information in the language spoken in that country, regardless of whether his product is a complex ERP system worth $100,000 or a hair shampoo priced at PLN 3. Obviously, if a region specific translation is not available, all such products or items will loose consumer interest and encounter market entrance barriers.
This can occur because anyone remotely interested in a purchase, would be immediately discouraged from buying the product if he were unable to read the instructions manual or even figure out what the item is. The best that the producer could hope for in such cases would be that the product marketed in English to an Eastern-European region, would find some English speaking residents of the region or English speaking tourists tempted to purchase it.
Although it is true that some items could sell even without English manuals or English labels, it is hardly likely that revenues would exceed costs incurred in most cases where the product did not have a localized marketing campaign. Unfortunately decisions as to whether or not to localize a given product tend to be based on the estimated cost of such ventures and the benefits (increased revenues/sales) they would generate, instead of on the assumption that localized products will find a larger target audience.
As stated previously, when one localizes a product/service, he adapts it to the requirements and standards applicable in another country. However, in order to understand the term “localization” fully, we first need to understand all of the parts of the localization process.
Localization process: Translation of all terms, abbreviations, symbols and units (in short, all language specific components) into the language of a given country (for example, when dealing with software, we translate the user interface, online help, messages that may be displayed, and all documentation).
What should the professional localization process be like to ensure the success of localization projects? The following features make up the localization process:
A native speaker of the target language should check each translation. Following the translation and proofreading, the translated text must be re-read in hard copy to identify errors that are hard to detect without looking at the translation as a whole. It is important to realize that even the best translators and proofreaders can make mistakes.
If tools and technologies adequate to the specific project or subcontract are used, and used by people familiar with them, then everyone involved will sleep easier and be sure that it will be wrapped up on time. Some of the tools that facilitate the automation of some parts of the work relate to:
What matters in localization is the execution procedure. The right approach to the project is bound to result in the development of a successful product. On the other hand, any attempt to execute the project without careful preparation is likely to have a negative impact on costs, deadlines or product quality, and in a worst-case scenario on all of them. So, strategize, and strategize smart!
Below is a procedure for executing a localization project. Different emphasis should be placed on different stages for different kinds of localization projects. Depending on the specific nature of the projects, some stages will be more complex while other may be less complicated.
This is undoubtedly the most important part of the entire process as it affects all the subsequent stages of the localization process. Mis-analysis of specific issues can jeopardize the whole project, substantially raise the costs involved or prolong the project execution process, not to mention the negative impact that it can have on quality.
The size of the project is determined by drawing up a detailed specification of the amount of text to be translated for all the files. Even at this early stage of the project we have to be aware which files contain components for translation. A thorough assessment of the size of the project is crucial for its subsequent execution as it enables us to plan all the stages for all the components such as audio, graphics or text.
The purpose of a project plan is to:
Development of stylistic guidelines and instructions for translators (such documents can be prepared on the basis of existing templates for a given type of project or specifically for the project at hand). Verification procedures (QA): development of adequate procedures for verifying localized material (including instructions for translators) is crucial to the final quality of the project. For example something as obvious as making sure that all hyperlinks in the translated HTML material work properly. If this task is written down as a step in the procedure, we can be sure it won’t be forgotten.
Reference materials are materials available to everyone involved in the localization project, whether translators, proofreaders, engineers or testers. The general principles of preparing such materials are as follows: The more reference materials are prepared the better.
To that end, we can use older versions of documents, help strings or software tests. Obviously, should such materials not be available, where the relevant software is a new product, materials similar in substance can be used (such as similar applications, documents on similar subjects, etc.), All reference materials should be developed with ease of access and browsing in mind. For example, creating 100 reference files will prove useless, as searching through 100 files to clear up a problem identified in the course of the project is too time-consuming.
In this case, relevant documents should be combined into one, with information on source documents/files kept for further reference. For example, HTML files may be pasted into one large file using a tool incorporated in the SDLX software (all versions) or Perl script. Translation Memory translation and terminology databases are the most important reference materials as they are the easiest for translators to access.
Virtually all TM applications feature a translation memory and terminology database integrated with the editing environment for translating. This is the fastest and most convenient way to use this information. We simply block text, and by clicking the relevant key view the search results.
The proper way to configure a TM tool is as follows:
Importing into the TM environment means converting the file we want to translate into the TM application format.
Pre-translation is performed if we have a translation memory containing the previous version of a document, for example, or help files or software. Pre-translation brings down the cost of translation, because text that is pre-translated only has to be proofed as part of the project.
The translation is executed using the Translation Memory editing environment, in accordance with stylistic guidelines and using all available reference materials for the project. The functionalities of TM tools increase translator output by providing shortcuts and other labor saving features. Use of TM tools also cuts the costs of both translation and proofreading.
Proofreading also needs to be carried out in the Translation Memory editing environment. During the proofreading process, the format of the target document should be previewed as far as possible (some TM applications have a built-in preview function, while in others files have to be exported to be viewed in the target format).
The proofreader can also view the translated text on paper to see the formatting and layout of the target document on an on-going basis. This is useful when translating documents with complex formatting or HTML pages, for example:
When proofreading we use the following functions that are available to support the proofreading process:
This is usually a simple conversion from the working format of the TM application to the target format. In the Trados application and when working with .rtf files, this means simply removing markers inserted for segmentation purposes. In the case of documents saved in a more complex format, this operation may not be error-free, for example when working with FrameMaker files in the Trados application.
At the functional testing stage, the end-translated product is checked. The importance and length of this stage of the localization process is determined primarily by the type of the project: software localization projects require compilation and testing, or testing alone in the case of binary files (.exe and .dll). for Website localization projects, we check that all links function properly, all scripts on the site run correctly following localization, and all elements containing language-specific components have been localized.
For professional publications prepared using electronic design software, such as Adobe FrameMaker or QuarkPress, the appearance of the document as a whole is of crucial importance. Attention should be paid to details as fonts, the entire layout (respective location and captions), illustrations, headers and footers. The electronic layout of the text contains all these aspects and many more. There are certain specific issues typical for each file format.
After all changes have been made in the course of functional testing, the translation memory and terminology databases have to be updated. This will ensure that the same mistakes are avoided in similar translations in the future. We can also be sure that the reference materials that can be created from the project will be error-free.
This chapter describes the tools that support the localization process. These tools can be used for any localization or translation project, from a simple translation of a document to the localization of complex software.
These types of tools support translation and proofreading (with the use of TM databases). To learn more about how to use translation memory databases, please consult the definitions at the end of the document.
Translation tools can be used to:
These are applications for translating files containing software components such as the user interface or application messages. Such applications include:
These types of applications are also equipped with functions for validating (checking the correctness of) translated components. In many cases, these functions are sufficient for checking that the translated software does not contain errors such as messages that do not fit in dialog boxes.
These applications are used to carry out tests on the user interface, RTF or HTML help texts, and also contain tools for Web site testing. They are useful at the functional testing stage. The starting point for functional testing is usually the consultation of error reports generated by these applications. In most cases, all detected problems can be repaired by means of the editor in the application. Use of these applications does not render manual verification of the localized application redundant. Such applications include:
This type of software is used for editing graphic files. The simplest example of graphics localization could be replacing the English caption with a Polish one in the format of the file that contains layers. Localization of complex graphics tends to be extremely time consuming and requires not only excellent knowledge of graphic editors but also artistic talent. Such applications currently available on the market include:
Below is an example of a typical localization project, which includes the localization of a program as well as the translation of the documentation and help strings. The basic steps are as follows:
The localization project we obtained was as follows:
Suitable tools must be used to evaluate the size of the project and its subparts:
The project plan must include:
Which of these documents will be required and helpful in a specific project depends, of course, on its size and complexity. For large, complex projects it is worth preparing all the documents listed above in as simple a format as possible, so that they are clear and helpful when the project is underway. Then the time devoted to the preparation of these documents will be time well spent.
If the company does not have an experienced team and is not in a position to analyze the project or prepare a project plan, it can use the consulting services of a localization agency. Localization agencies often provide these services to IT companies free of charge.
It is certainly advisable to use them if the project in hand is large and technically complex (both often go together). Investing into localization expertise will certainly be profitable: lower costs of the translation and avoiding the risk of failing to keep a project deadline. The following reference materials will be used in our sample project:
It is important that the project be carried out in accordance with the plan prepared in advance and on the basis of the instructions developed for the project. During the project the need may, of course, arise to review some of these items, such as the time frame for a particular task.
If an application is developed in Borland Delphi, the optimum solution is to use either a localization tool or a TM tool capable of handling this file format. After translation, the text is proofread in the same environment.
If the SDLX application is used, for example:
Once the application is compiled, the appearance of all the windows in the application must be checked. It is best to begin this stage of the project by using a tool that can automatically detect UI faults, such as strings that are too long or elements that overlap. Next, the entire application is manually tested by testers with instructions that point to issues specific to a particular application. The results of their work are forwarded in standard report format to the technical teams that rectify any problems.
Documentation can be translated with the use of any Translation Memory application; FrameMaker format is sufficiently popular and is supported by all Computer Aided Translation tools. Proofreading, using the same reference materials, is also done in the TM application. The final step of verification of the translation is a review of the whole translation (preferably in hard copy) to spot errors or defects.
The last stage of the project is the final formatting of the documentation. In our example, the FrameMaker application must be used for DTP, as the original documents were developed in this format. Attention must be paid to all details, such as:
The sample project described above covers the issues and problems that can be encountered during localization. It is important to point out here that when handling a particular file format for the first time, specific technical problems connected with translating these files are to be expected.
The information and examples provided in this document leave no doubt that localization is a complex process that calls for the use of state-of-the-art technologies and a team of experienced and devoted specialists. Localization teams cannot be set up ad hoc, for example for a particular project only, as that will lead to low quality outcomes. The volume of reference materials that members of localization teams must review is truly huge, resulting often in a very time consuming process. As such, quality localization services are certainly not cheap, but well worth the money spent.
HP to expand Wroclaw centre Hewlett-Packard (HP), the US computer group, plans to create up to 700 new jobs at its Global Business Centre in Wroclaw over the next few years, as the fa[...]
Ikea freezes regional expansion The Swedish furniture retailer has suspended its programme of regional expansion in Russia. The construction of the company's shopping centre in Voro[...]
(Die Links unten öffnen sich jeweils in einem neuen Fenster)