Translation and the Technical Writerby Roger Tunsley |
Imagine that you want to buy a new software package. You have a choice between an excellent package written in a foreign language or a good package written in your own language. Chances are that you would forego the foreign language version and buy the less capable package.
As more companies sell in the global market and recognize the importance of customer service and satisfaction, they are beginning to realize the importance of translating software and documentation into foreign languages. Once your own company realizes that it needs to translate its documentation, to whom will it turn for project management? You, of course. The technical writer is in an ideal position to control the translation of documentation and the textual element of software.
I have recently managed a project to translate a sizable software package of several linked applications and their associated online and paper documentation into French, Italian, German, Spanish and Japanese Kanji. In this article, I will give you tips on how to choose a translator, what you can do to help the translation process, and how to avoid or solve some of the problems that you may come across. All that follows is based on my own experiences, but all projects are different and your experiences and problems are likely to be different than mine. However, if you can pick up a tip or two, you will be in a better position when you finally do the job yourself.
Choosing a good translator is crucial. There are many sources of translation and you need to take many variables into account, such as the size of the project, the technical expertise required, the number of languages and so on.
Translation sources range from the language major at a local university to the professional firm with overseas, native-speaking translators. The quality of the translation from these sources also tends to range from amateurish to professional respectively. For a small, non-technical task, you may find someone locally who has native fluency in the target language as well as a good command of English. However, for anything large or technical, you should take advantage of a professional translation company, preferably with experience in the technical discipline that they need to describe. Question the company thoroughly about the technical expertise and language capabilities of their translators.
Assess the scope of the project. Translating a small brochure into a single language requires fewer resources than translating a major software package and its associated online and paper documentation into several languages. The larger the task, the more organized your translators need to be.
Assess the level of technical expertise required for both the type of material that you are translating, such as software and online documents, and the content of the text. Most people who have never been involved with translation have an image of the translator reading a page of text while typing the translation into the word-processor. This image is not necessarily accurate. Today's translators have to be extremely technically adept.
If they are translating software, they need to be proficient with software and to know the terminology and the standards for your interface (Windows, Macintosh). They need the ability to compile resource files, where possible, to make sure that the translated text still fits in its allotted space on the screen; to run the program (which is often still under development) and see the text in context; and to know which lines and words in the jumble of code in front of them actually need translating and which ones they absolutely must not change.
If they are translating online documents, they need to know how the hypertext coding structure operates in order to leave it intact, and how to compile the online files to ensure that the navigational routes are still operational.
If they are translating text and graphics in a desktop publishing package, they need to know how to use the package, so they can reformat and repaginate your final copy and include a new table of contents and index. You may even require them to recapture graphics, such as software screens that are now in a foreign language.
At all times, even on the largest jobs, the translators must ensure the consistency of the translation. Consistency of terminology is necessary between different items such as the software, the online documents and the paper documents, as well as between the languages. Thus, good project management may be one of the controlling factors in your choice. My own project involved the translation of 6 interlinked software applications, supported by 17 separate help files and 6 paper manuals. Six different writers in two countries developed the various components, and many different translators in five different countries translated them. Good project management by the translators was high on my prerequisite list.
The cost of translation ranges from high to expensive, again dependent upon your translation source. Most companies use different measures to assess the cost of a project. To compare costs, send each company an identical sample of your documentation and give them an arbitrary but identical number of pages on which to quote. In this way, you can get a reasonably accurate comparison of cost-per-word between companies.
Plenty. It is important to start your planning early. The more you can do at the start of the task, the easier it is to complete.
Develop an extensive glossary of terms in common use in your documentation, whether these terms are esoteric to a scientific or technical discipline or are common terms such as "disk drive," "file" or "load." Any good translator will recommend developing a glossary early on in the project, as it helps enormously in establishing consistency of terminology, both for the translators and for the developers in your own company.
Make yourself highly visible and brief everyone involved in the project. There is one thing that everyone must know -- translated text gets bigger. You should plan for around 30% expansion of translated text; short words and phrases of up to 10 characters can expand by 100% or more. This expansion has different effects on different parts of the project. The greatest effect is on the short words and phrases of the software interface. All developers must therefore be aware that they need to leave adequate space for translation. Even so, text interference will occur, so they also need to know that there will be an engineering requirement once the translation is complete, in order to resize buttons, labels, list boxes and soon, so that the new text will fit.
Developers and engineers also need to remain consistent in their terminology. They won't, so you must be vigilant. I became a member of the interface design team for the software and took on the responsibility for all text used in the project. Thus I was able to ensure that text expansion and text consistency remained important in the minds of the developers. I cannot stress enough how much this helped, although there were still plenty of sizing and consistency problems to resolve.
Think carefully before you translate during development. I began our translation task early in development, as we wanted to launch the product with all the languages intact. We did so, and the availability of translated software and documentation impressed both the sales force and customers. However, with development and bug-fixing continuing past the launch date and up to the first shipments, there was a constant stream of changes and additions flowing between us and the translators. If you wish to impress anyone with language early in the development, consider translating only the software interface and leaving the documentation translation until the product is less volatile.
Translation is an iterative process that generally needs several reviews. Use the sales staff at your overseas offices to review the translators work, but make sure that one person is responsible for signing off on each language. Translators are not experts in all disciplines and they will need guidance from your local staff. Conversely, the local staff may need guidance from the translators. For example, the sales staff may not be fully conversant with new software technology, such as Windows, and they will need advice on standard terminology. However, the local sales staff must have the final say in the review process; after all, they are going to have to sell the product and they know their market.
The problems are likely to vary from task to task, but here are some of the main ones that I encountered.
I mentioned cost assessment in the discussion on choosing a translation firm, but be aware that different types of material have different translation costs. Software files and online documentation files are more expensive to translate than text on paper. Make an accurate assessment of the volume of the various types of files before you go firm on your cost estimates for your budget.
On a large task such as this, the number of files that are being transmitted around the world can become extremely difficult to track. I had over 1000 files by the time they were in all languages. I developed a spreadsheet to list the files and date them when they left for translation, when they were due back, when they came back and soon. Good tracking will help ensure that you send all the necessary files for translation. For example, I was expecting to do all the screen captures of the software directly, thus I forgot that I had developed several bitmaps that included text in support of the documentation. The tracking file highlighted this omission and possibly saved me a last minute scramble to translate the files.
Software incompatibility can be a major headache. For example, Japanese Windows software development lags substantially behind the U.S. and Europe, which creates software version differences. Thus I would send files written in Word for Windows 2.0, and the Japanese office would load them into Word for Windows 1.2J for translation. When I got the files back and reconverted them, many of the translation changes were lost in the file conversion. You should check early in the process to ensure that software incompatibility does not cause you a problem at the worst possible time.
Keep reviewers informed. I have already mentioned the need to brief everyone, but I forgot to include the reviewers. At first, they were trying to review the software interface text without being able to see it actually inside the interface. This meant that many of the terms used were out of context. Also, reviewers were generally unaware of the need to keep interface text strings short, which caused problems with text interference on the screen. We soon overcame these problems, but it would have been better to avoid them from the start.
None of the problems that I faced proved insurmountable, but consideration from the start would have helped me avoid most of them.
Translation management is challenging and, with good planning, rewarding. I have been immersed in this project for the last six months and, believe me, the time has passed quickly. If you get the chance to become involved, take it. As a technical writer, you are in an ideal position to bring your experience of task estimation and working to deadlines to bear on a complex and exciting project.
Roger Tunsley is the Manager of Technical Publications for Instron Corporation, a manufacturer of systems and software for testing materials. You can reach him at Instron Corporation, 100 Royall Street, Canton, Mass. 02021, (617) 575-5231.