Translation Methodology

What is translating? We define it as the process of reading, understanding, interpreting, rephrasing and delivering an original message—with all of its subtlety and impact—to a new audience, in its mother tongue and within the context of its indigenous culture. The best translators love words, of course, but more importantly they love the life that words depict. They are the connection between the creators of a message and an audience that would be incapable of getting that message without their help. Our translators are experienced specialists whose job challenges them on a daily basis. We have all been amazed at the breadth and depth of human knowledge displayed on the Web; imagine translating it, not just skimming through it!

A translator's basic responsibility is to be “true” to the original text. If we consider a translation to be a form of inter-cultural message, then we should evaluate its faithfulness to the original on two counts: how the original message is expressed in the target language, and how it is received by the target audience. The translator is responsible for both of these steps in the communications process. The Internet in particular is teeming with audience groups who will receive the same message in different ways depending on their cultural background.

Consequently, we have access to native speakers of each source and target language that we serve, not to mention experts in each subject domain, writing style and language dialect. Domain knowledge can be learned, but for these intents and purposes, a target language or dialect cannot.

As an overview of our approach to the translation process, let us assume that we are localizing a product for the international market.  In a software-localization context, the typical product consists of code, documentation and help files, and each of them needs to be translated either in part or completely.

1. General Issues

We make a distinction between localization and translation. Our localization approach is explained in a paper titled Localization Methodology that is also published on this site.

This section presents the basic information requirements for our translators when localizing a new product. Of course, the scope of a project determines how much preparation is needed before translation starts. However, no project is automatically classified as "small". A low word count does not necessarily mean that little work is involved.

1.1       Evaluation

The first step is the evaluation of the original product. It is necessary to establish what the product consists of in order to work out a schedule. During evaluation, questions will arise that should be answered before localization starts. These questions tend to be asked by all linguists of the different languages, and to avoid answering the same questions separately several times, it makes sense to ask them up front. Examples for such questions are:

      Can the date/time format be changed? (In American English, month comes before day, but it is the other way round for European languages; there is no AM and PM in other European languages than English.)

      Formatting conventions: Adhere to industry standards, such as Microsoft, or follow specific requirements by the client?

      Are there any terms that should not be translated?

It is important for the client to answer these questions, in order to avoid delays and confusion during the translation process and, eventually, the final QA of a product.

1.2       Glossary Generation

Second to an in-depth knowledge of a product, glossaries are the most important source of information for a translator. They are vital to ensure consistency in the translation process when a job is done by several different translators. Glossaries must always be up to date, approved by the client, and distributed to all linguists working on a job. Outdated glossaries cause confusion and lead to errors. Every update to a glossary can have major consequences in every component of a product; e.g., when a term is changed in the software, all of the documentation and help files must be checked for that term and updated accordingly. For this and other reasons, it is important that there is competent language support on the client side. For example, a language reviewer who does not speak Arabic but is equipped with a Arabic-English CD-ROM dictionary is NOT capable of judging the quality of a translation into Arabic.

Glossaries can be generated by:

      The client

      The people who do an evaluation

      The translators

      The engineers preparing software files for translation

Glossaries should include:

      Product-specific terms

      References to where a term occurs (software, documentation, help file)

Glossaries should NOT include:

      Platform-specific terms, as these can be found in the respective glossaries for the platform

      Obvious terms like Yes, No, OK

1.3       Reference Material

Any reference material that can be provided is helpful. This includes such basic things as the nature of the product in question: Are we dealing with a software application, a game, a printer, or a toaster? In most cases, there is no such thing as a "straightforward" translation and very few things are self-explanatory. Translating a list of 20 words without knowing which context they are used in can be more time-consuming (and frustrating) than translating 2,000 words within a given context. For example, for a plastic surgeon, the word "face" means something very different than it would for a printer, and it cannot be assumed that this word is the same when translated into other languages.

In more detail: These can be the running software, printed documentation, on-line manuals, help files, or all of the above. To have the software translated by one vendor, the documentation by another, and the help files by yet another is generally a bad idea. If for some reason this cannot be avoided, all people involved have to be in regular contact to make sure there will not be any inconsistencies. Furthermore, it is necessary to make sure that everybody works with the same up-to-date glossaries.

Translating documentation and help files is much easier when the running software is available. We all know that the original product is often not finalized when localization starts. However, this does not necessarily mean that software is completely unavailable. There are always alpha or beta builds that do not run perfectly but can provide essential information. Another source of information is the resource files, when they can be displayed in an editor like Borland Workshop or AppStudio. It is always more helpful to see an actual dialog box than trying to visualize it by looking at the source code of a resource file.

The same is true for (e.g.) instruction pamphlets to be enclosed with a product.  We have to keep in mind that we are translating for an end user who has to rely on the descriptions given to be able to use the item, and who probably does not speak the language the instructions were written in.  Instruction leaflets often contain illustrations, with text something like: "When moving the device, be careful not to touch the metal plate (see Fig. 1)". If this illustration is not available to the translator, there is an 80% chance that the translation will not make sense. Other languages often have to be more precise; "device" might be sufficient in English, but in other languages, the device in question might have to be named. And what is a metal plate in this case? What does it look like and where exactly is it on the device? Asking these questions can be avoided by simply providing the illustration to the translator.

Another issue is marketing and packaging material. The purpose of text on the packaging of a product is to advertise the product so that people want to buy it. Nevertheless, it should have something to do with what is inside the box. It is important that whoever translates the box text knows the product. Translation should be thought of as rewriting a text in another language, and it requires the translator to know as much as possible about the item described.

1.4       Summary

Before translators start localizing a product, they have to be provided with:

      Evaluation documents that point out the problems that are likely to occur during translation, answer questions, or indicate which questions still have to be answered;

      One or more glossaries;

      Reference material.

2. Translating the different components of a product

Different components of a product require different strategies for translation. Therefore, instead of giving universally valid guidelines about how to deal with a particular component, let us present some ideas for how translation can be handled in order to have a quality product at the end of the localization process.

2.1       Resource Files Software

Resource files can be edited in a text editor, like Notepad or WordPad, or in a resource editor, like AppStudio or Borland Workshop. The advantage of resource editors is that the translators can see the user interface. The appearance of menus and dialog boxes in the running software can be tested immediately after translation, and errors or truncations can be fixed, which saves time on the engineering process. Any hotkey clashes will also be spotted immediately.

2.2       Proprietary File types

These are files that are specific to one particular client, and therefore no general rules apply for their translation. Translation guidelines have to be provided by the client.

2.3       Flat text files (ASCII and ANSI)

The format of a text file has to be specified by the client. We cannot automatically assume that everything is required in ANSI; for instance, there are still installers that have to be run in DOS, which requires ASCII code. The problem is not as obvious in English, where there are no extended characters, but for other languages, extended characters are corrupted when a file is opened in the wrong environment.

2.4       HTML Files

The translation of HTML files can be confusing because of the abundance of code in these files. It is easy to miss translatable parts; however, untranslated words are also easy to spot when looking at the file in a browser. There are tools to facilitate the translation of HTML files, e.g. by color-coding the different components of the file—code in red and translatable text in blue. The use of such applications should be considered for large HTML files.

2.5       Graphic Files

One way of localizing graphic files is to edit them directly in a graphics application like Adobe PhotoShop. However, depending on the complexity of the graphics, this might not be feasible. Some translators will be able to deal with graphic files, but they cannot be expected to be graphic experts. Furthermore, there is a large variety of applications for the editing of graphic files, and not all translators can be expected to have access to specific applications that might be required for a particular job.

An easier way of editing graphic files is to give the translator a text file with a table containing the text of the graphic files. A graphic expert can then do the editing of the graphics. The following points have to be taken into account when supplying a table with text contained in graphics:

    ALWAYS supply the graphics along with the table. Only then is it possible for a translator to give an appropriate translation. Keep in mind that graphic experts do not necessarily speak the language the edited graphics will be in. When the translators see that a word might need hyphenation, they can indicate where it can be hyphenated. Guesswork by graphic artists is undesirable and leads to errors.

      ALWAYS have the edited graphics checked by a linguist to make sure there are no errors in them.

      NEVER ask for the faking of screen shots without supplying the software options contained in the screen shot. As a rule, screen shots should not be faked at all, but taken from the running software; faking should only be a very last resort.

2.6       Help Files (RTF, CNT, HPJ)

A Windows 95 help file (.HLP) is compiled from different files, some of which need translation. The most important files a translator is concerned with in a Windows 95 help system are files with the extensions .RTF, .CNT and .HPJ, and possibly graphic files (.BMP files). The following points should be taken into account when translating .RTF files, which belong to a help system:

      Translators have to be careful NOT to insert spaces between the last letter of a text that is used as a link (indicated by e.g. green text and underlining) and the hidden text, which follows the link.

      The # footnote must never be translated.

      The $ footnote should have the same translation as the topic title.

      The K footnote consists of the keywords used for the search engine of the help system. The keywords are separated by semicolons.

      Smart quotes are not supported by the compiler, always use straight quotes.

      The names of bitmaps displayed in curly brackets (e.g. {install.bmp}) must not be translated.

The easiest way of translating .CNT and .HPJ files is using Microsoft Help Workshop. With this tool, it is possible to display only the text that needs translation. These files can also be displayed in a text editor, but sometimes there might be confusion about the words that need translation.

The .CNT file is the contents file of the help system. The topic titles in the .CNT file should therefore match the topic titles in the corresponding .RTF file. Usually in a .HPJ file, the title of the help system and locale-sensitive information, such as keyboard and language settings, have to be translated.

2.7       Audio Files

Audio files have to be translated and then recorded. The script of the files should be provided along with the audio files. Ideally, translators will be given the time to listen to the files before supplying a translation. Translations depend on the intonation and pacing of the audio file, and the first translation that would be chosen when reading the script alone might not be appropriate. Supplying the audio files helps to avoid nasty surprises when listening to the finished product, and keeps down the costs. Nobody wants to discover inappropriate translations at the end of the localization process, when re-recording is no longer possible. If sound effects are needed, the developers should include them in a separate sound effects folder with a description sheet. 

2.8       Scripts

The best format for an audio script is an Excel 97 sheet, with columns for each of the following:

      Filename (and directory if applicable)

      Character name

      Script text to be spoken

      Time duration of file

      Sound effects (notes on what sound effects are required to mix with the file)

Another important item is Script accuracy:

      Has someone checked the script with the original audio?

During software development, audio files become redundant, new ones get added, some get new sound effects, or get renamed.

      Does the script reflect these changes?

If not, it could be very costly to fix later.

2.9       Overview / specification document

This document should contain information such as:

      The file format required for the audio, this includes:

      WAV or AIFF (most common)

      Sampling rate: 44.100 Hz, 22.050 Hz, 11.025 Hz etc.

      Bit depth: usually 16-bit or 8-bit

      Number of characters in the script, with a description/direction breakdown of each character.

      Details of the original (e.g. US) recordings such as how many voice artists were used?

2.10     Video Files

Typical video file formats include AVI, MOV or SMK. The videos may have been created using applications such as Adobe Premiere, Adobe After Effects, Director or 3D Studio Max.

The final video files are compressed video. For localization purposes, this format is mostly useless, since trying to change the files is a little like trying to recreate the ingredients from a pot of soup.

In order to localize these, it is necessary to have the project files from the application, as well as information on build settings. If this is not possible, then an uncompressed source of the files is needed.

If videos are to be localized, the main questions are:

      Does the new spoken audio need to be lip-synched with the video?

If it does, then the translation of the script will need to reflect the speed of the video. The audio should be recorded with the voice artist looking at the video.

      Does the video have a soundtrack or effects?

These unmixed sources will be required from the developer, so that they can be mixed with the new audio.

      Does the video have any graphics or text, which require localization?

These can be tricky, particularly if the text is 3D or animated. If so, and the project files for the video are not available, then we have the options of trying to mask them out, over-painting frames, or re-editing the video to avoid them.

2.11     Language QA

Software: After every build cycle a linguist should make sure there are no errors/truncations or untranslated text in dialog boxes and menus.

Documentation: After the first and second desk-top publication stages, a linguist should proof the printed files in order to make sure that everything is in the right place, the page breaks are correct, and all graphics are in the correct language. These steps also include software consistency checks, to ensure that all software terms in the manual match the running software.

Help: The compiled help files should be checked by a linguist to make sure all links point to the correct topics. QA of the help files requires software consistency-checking as well.

For the final QA of documentation and help, it is vital for the running software to be available. A linguist needs to have all components of a product in mind, and maintain consistency between all of them.

2.11     DTP Formats and issues

The following information is needed:

      Name and version of the application to be used;

      Font names and sizes;

      Number of graphics in the document;

      Is copyfitting required?

When creating a document that has to be copyfit in another language, the expansion of the text should be taken into account. The very general rule is that a translated text is about 30% longer than the English original. A page that is full of text from top to bottom is hard to copyfit. Font size, leading and spacing can be reduced, but that might make the text extremely difficult to read. Examples for copyfitting are registration cards (which ideally should not contain very small print squeezed into four columns with very little space between them), or license agreements, which are generally written using a small font size.

All graphics/screenshots for a document should be supplied separately. 

3. Tools and Software

Has a significant depth of experience in the translation and analysis of a wide range of texts, including technical and military documents.  The company has dedicated the last eight years to the research and development of machine translation systems to and from English, with other languages including Chinese, Korean, Turkish, Persian\Dari and most European languages.  In that process, electronic domain-specific dictionaries were constructed, including but not limited to military, nuclear, aviation, computer, telecommunications, and business/accounting domains. These dictionaries—as well as tools to browse, search and retrieve bilingual text in synchronized form—are utilized to assure consistency in meaning and terminology selection across the whole volume of text, as well as efficiency and ease of use. The customer can also choose to build a customer-specific glossary online; in this case, in-country review and validation of preferred terminology is an integral part of the translation cycle. Furthermore, the customer can choose to implement TextFinder technology to make the material available and viewable by the user in a bilingual environment. TextFinder provides users with hyper-links to graphs and images, as well as query-translation capability with retrieval of words, phrases, related graphs, figures, tables etc. in both languages, regardless of inflection or morphology.

3.1       TranSphere:  English-to/from-Foreign Language Machine Translation

This addresses the Machine Translation (MT) system.  Workstation-based with a client-server architecture, TranSphere is used to:

       Analyze the semantic, morphological and syntactic structures in English and produce their equivalents in the target language

       Function as a fully automated Machine Translation system

       Utilize a general-purpose lexicon in addition to special domain micro-dictionaries

       Allow users to control the ordering of those dictionaries

       Sustain throughput at high rates (WPM).

       Support a Vocabulary Search Utility to identify words not in the system’s dictionaries

       Support a Dictionary Maintenance Utility to add user-defined words.

       For words not found in the dictionary, reproduce them in the target language’s character set

       Interface with a Text Management System (TextFinder) with search/retrieval capabilities and bilingual file viewing

       Interface with an OCR and a spell checker

3.2       Translation memory

Translation memory, an efficient tool for locating and re-using previously translated phrases and sentences, is an ideal aid to the translator. Some notable functions and features are listed below.

      Indexes complete or segmented sentences

      Displays the source sentences aligned with the target translation

      Creates word and phrase match using a bilingual morphology analyzer

      Utilizes monolingual lexicons for automatic sentence alignment

      Alignment can be performed on a word-by-word basis

      Many-to-one/one-to-many word alignment can also be done, i.e. for idioms and multi-word terms

       Elimination of “noise” words, e.g. the, a, an, etc.

       Ability to map entire phrases or sentences for specific contextual use

       Intuitive user interface for fast and easy manual sentence alignment

       Centralized database in both client-server and standalone systems

       Automatic bilingual translation-memory creation allows sentences to be added dynamically

       Uses both exact-match and partial- or block-match techniques

       Dictionaries and glossaries:

       TranSphere’s general dictionary (100,000 words) customized for translation memory use

       Domain-specific micro-dictionaries (computer, business, aviation, etc.) can also be used

       User-defined glossaries can be imported into translation memory

      In standalone mode: Unfound words / segments can be translated using a stem-based bilingual lexicon

      Integrated with TranSphere: Unfound words / segments can be presented to TranSphere for automated translation.

      Reduces post-editing time

      Enhances translators’ productivity and throughput

3.3       TextFinder 

TextFinder is an electronic publishing application that performs bilingual browsing, searching and retrieval of information, with hyper-links to graphs, figures and other information. Documentation in both source and target languages can be synchronized and viewed. The software is equipped with linguistic intelligence to search for general themes, as well as inflected words, phrases and graphs. It also has bi-directional query-translation capabilities.

3.4       Customer Glossary Online

Can build custom-made electronic dictionaries that translate terms to and from English and integrate them with the TextFinder search engine. These domain-specific micro-dictionaries are developed and approved by the customer to conform to in-country terminology requirements.

3.5       Personnel

A turn-key translation project usually requires two independent teams of translators to handle the English-to-target-language and the target-language-to-English translation tasks.  The testing procedure involves sample selection and software validation of comparative grammatical features between source and target.  (If reverse translation is only required for quality-assurance purposes, the testing procedure eliminates this need.) 

Once two independent teams with two distinct project leaders are assembled, they start digging the tunnel from two different directions.  The “from-English” team consists of several translators trained on translation software tools, as well as Desk-Top Publishing (DTP) applications.  This is a diverse group of foreign-language translation specialists. All are U.S. citizens, some with secret-level clearance. Among the team are several with almost a decade of technical translation experience.

The “to-English” team performs the reverse translation, utilizing software tools for matching the English output with the original source language from the customer.  The tools provide both exact- and fuzzy-matching techniques for comprehensive coverage and exhaustive testing. The team members who are bilingual English native speakers concentrate on providing native comprehension of the source language and fluency of English output.

4. Conclusion

The key to a high-quality translation is active participation by you, the client. If you are localizing your product for a market where you already have distributors or representatives, then by all means ask an employee in that market to be on hand to answer questions and to review the completed translation. Your representatives will generally be eager to help since in the long run they will be directly affected by the quality of the translation.

While in theory it is possible to translate product information without any background knowledge of the product, this cannot be done without sacrificing the quality of the translation, so that the documentation may be vague and irrelevant and the product barely executable.  Therefore, whenever possible, you should supply the translator with company literature in the source and target language, and a bilingual glossary of domain-specific terms. A translator cannot be expected to know which terms are favored by your company in a given market, and which are considered the property of your competitors. By observing the procedures outlined in the above sections, the quality of the finished product will be optimal and time will be saved, which means a more smoothly running project.

Contact Us