Facets of Software LocalizationA Translator's View
by Per N. Dohler
That information technology has revolutionized the translators working environment is a fact so obvious that it no longer even bears mentioning. For the vast majority of translators and their clients, computers have long replaced typewriters and reams of paper. Modems and e-mail have replaced manila envelopes, mass storage devices have replaced drawers full of folders, CD-ROMs supplement dictionaries and encyclopedias, and more recently the Internet and its resources more and more often save us a trip to the library, while various online communities have brought many translators out of their isolation.
But information technology not only offers us tools. It is itself a field in which more and more translation work is actually performed. This is certainly true of other fields like marketing materials, packaging materials, advertising copy, and manuals. But in the case of information technology products, it is frequently the products themselves that need to be translated. Whenever a program or process displays a word or a phrase on the screen, this means potential work for a translator or many translators.
International users of computer software have come to expect their software to talk to them in their own language. This is not only a matter of convenience or of national pride, but a matter of productivity. Users who understand a product fully will be more skilled in handling it and avoid mistakes. So they will prefer applications in their language and adapted to their cultural environment.
The international market has become very important for software manufacturers. Many U.S. manufacturers derive a large percentage of their revenues and profits from international sales. Competition is fierce, and those companies who are best at anticipating the needs and preferences of their international users will benefit most.
With the advent of the Web, it has become vital for many manufacturers and distributors to maintain a world-wide presence. For this presence to be effective, it is not enough to simply be there. It is equally important to make sure the message gets across, and once again, that means: translation. Localization and internationalization
Internationalization , also referred to as globalization, is the process of designing or redesigning a product so that it can be localized with minimal changes.
Localization is the process of adapting a product, in our context a software program, to a specific locale, i.e., to its language, standards and cultural norms as well as to the needs and expectations of a specific target market. A properly localized product also meets all the legal requirements in force in the users region.
International Consulting has an instructive overview over localization and internationalization, including many technical and business aspects.
ILE in Boulder, Colorado, has compiled an interesting document in Adobe Acrobat format that lists a lot of interesting facts about everything that should be taken care of before we translators see the text to be translated. This informative guide to product internationalization explores the ways you can develop your software, on-line help systems, documentation and audio that will make localization as straight-forward as possible. This overview can serve ... as a primer for anyone involved with localization. (Note: This document is protected and cannot be printed, only viewed.)
Translation companies are often chosen to provide localization. They eliminate the need for companies to maintain expensive in-house personnel. In addition, they offer a broader range of services, technical expertise, and flexibility than freelance translators and also eliminate the need for the company to manage a large pool of freelancers.
Ideally marketing managers say the localized versions will be completed at the same time the original version goes to market. Ideally translators say localization begins when the software and documentation are finalized. It is immediately apparent that these are irreconcilable demands. In actual practice, therefore, it is attempted to follow a stringent project schedule where localization is only one step behind development.
When localizing software, we are dealing with a number of different file types. The following subsections will present a few selected aspects of frequently encountered file types for the various Windows platforms. I apologize to all prospective Mac localizers, but I have no idea how these things work on a Mac. I am therefore a good example of someone who should not undertake localization for the Macintosh platform. If you do not know either and cannot find out, neither should you...Resource files
In localization, the visible part of the software, the user interface, is usually simply called software per se. In properly developed software, the texts the user sees are included in separate files, the so-called resource files. They contain everything the user is likely to see and that is not created when the program actually runs (at runtime): menus, dialog boxes, error messages, bitmaps, cursor shapes, and so on. Help files are resources, too, but they are usually treated differently.
The following is an example of a very simple Windows dialog box and its representation in a resource file (in a Windows environment this is called an .RC file, where .RC stands for resource compiler).
IDD_SELECT DIALOG DISCARDABLE 0, 0, 167, 106
IDD_SELECT DIALOG DISCARDABLE 0, 0, 167, 106
You will recognize the various elements. The texts marked in red here (in actual files they are not marked in color) are the texts to translate. You must not translate anything else, including the MS Sans Serif which deceptively enough is also enclosed in quotes but is the name of the font used in the dialog box. The & precedes a letter (shortcut) that is underlined in the actual box. The ... must be preserved as it tells the user that another dialog box follows when that button is clicked. Everything else is information that tells the compiler what to put where in the box. Chances are that the boxes need to be resized because the translation comes out longer than the original. This is not something that is usually included in the translation part of localization, although some translators possess the requisite tools to do so and offer this as a value-added service.
IDS_WINEXEC_ERROR2 "The following error occurred:\n\nFile was not found."
IDS_WINEXEC_ERROR3 "The following error occurred:\n\nPath was not found."
IDS_WINEXEC_ERROR5 "The following error occurred:\n\nAttempt was made to dynamically link to a task, or there was a sharing or network-protection error."
IDS_WINEXEC_ERROR6 "The following error occurred:\n\nLibrary required separate data segments for each task."
IDS_WINEXEC_ERROR8 "The following error occurred:\n\nThere was insufficient memory to start the application."
IDS_WINEXEC_ERROR10 "The following error occurred:\n\nWindows version was incorrect."
The \n" stands for a newline character. i.e. this is where a new line will begin in the actual text.
Help files The source files for Windows help files are usually .RTF files. Windows help compilers take this file and convert it to the familiar hypertext formats you see when pressing F1 in a Windows program.
The Hypertext organization (hypertext is text in which you can click on certain hot spots that will take you somewhere else, usually to a subtopic relevant to what you want to know) is represented in .RTF files in the form of single- and double-underlined texts, hidden text, and footnotes.
"#" footnotes are never translated. They represent hyperlink targets. If a different page wants to link to this page, it would do so by placing Example_Application_Welcome_Menu" in hidden text behind a hyperlink. Any changes here destroy the help file.
"$" footnotes are titles as they appear in the Help content list. These footnotes must be translated. It is recommended that this text be the same as the help page title.
"k" footnotes are entries in the Help index list. They must be translated, but with the same caveats that hold for index entries in documents.
"+" footnotes are internal compiler information and must not be translated.
Readme files usually contain late-breaking news that did not make it into the documentation, additional setup information, or corrections and additions to the manual. Usually these are plain text files. If you use your word processor to work on these, you must remember not to save them in the word processors format but as plain text, using the correct character set (e.g. Text only or MS-DOS Text). Otherwise you should try to break lines so the result looks pleasing. Readme files are pretty much the only place where hard returns at the end of a line and formatting text with spaces are ever allowed! Screen shots and bitmaps
Some of the elements of a user interface may be present in the form of image files in which the information is present as pixels and cannot be edited in the word processor or editor. These bitmaps will be recreated with an image-processing program, and the translators job is to furnish the translations to be included. In simpler cases the translator may be asked to overwrite graphics files. This should be billed as a value-added service.
Examples of bitmaps are the splash screens, the colorful rectangular messages that often greet users when a program is started. Word processing and DTP files
Documentation (manual) files are often presented to translators in heavily formatted form, with many hallmarks of document automation, with the expectation that translators overwrite them; this of course presupposes that translators know how to use their tools. You will find more details in the section Writing tools and their limits. Client-prepared file formats
A number of mostly larger localization companies take the resources and files to be translated and produce text files from them. These text files are the files that the translators get to work on.
These companies will send you, along with the text to be translated, instructions about how to use their formats, where you should write your translations, what elements you must not change, and the meaning of various tags and hints you may encounter in the files you are working on.
One advantage of this procedure is that translators can be provided with one set of instructions for a variety of different source file formats. A second advantage is that you can translate files for operating system environments other than your own. If the target system is a system that few people have installed, this may be the only way to work on the files to be translated. Incidental files
There are a variety of other file types: for packaging, warranty cards, and other purposes; these are too diverse to be listed here. They do not usually present any specific problems.
Basic referencesBilingual dictionaries
In many other fields, one of the most important and most frequently consulted references are bilingual dictionaries, often in paper form, sometimes on CD-ROM. Bilingual dictionaries always have their limitations, but working in a field that does not have these references makes you appreciate them more. Bilingual dictionaries in this field are often partly obsolete as soon as they appear. Not only do new words come up and old words fall into disuse, but the way existing words are used will also change rapidly. Remember what a Winchester drive is? Web sites and computer magazines
The vast majority of original published material, digital or otherwise, is written in English today. This is why localization is so often a one-way street from English to other languages. At the same time, we are often faced with the necessity of coining the words we need ourselves, or making an executive decision between several alternatives, none of which has yet become established.
Carefully written and edited computer magazines in the target language are a very useful source of computer terminology. If you dont live in the country of your target language, you should still be able to read them on the Web. Supposedly, computer magazines are a little less ephemeral than web sites, but a web site may be more on top of late-breaking news and is also easier to search.
However, the approach of jumping on the bandwagon of preliminary journalese translations as they are usually found in the first excited account of a new program, process, or device and of sanctioning them by copying is, in my opinion, a serious mistake. It is precisely in the computer field that we can do something for our readers by choosing our words conscientiously and prudently.
Those of us who are confronted with English and with computers and computer-related texts in our own languages every day might tend to think that our languages are just inundated with English loan words. On the whole, however, this impression is misleading. Of course there are differences in degree between the various European languages (I cannot speak about any others) but it is probably true everywhere that modern sports, some technical and scientific fields, computers, and computer-related topics, and certain aspects of cultural particularly those that address a more youthful audience tend to be full of cool loan words. But if you read newspaper and magazine articles that do not happen to concentrate on these topics (and a good number of those that do), chances are that the proclaimed inundation of our language with Anglicisms is fortunately still more or less limited to what is reasonable.
So with these caveats, computer magazines and carefully edited web sites (too many are, unfortunately, hastily thrown together by people with not much respect for their readers) in the target language are probably the best sources of computer terminology. General monolingual computer-related glossaries
Fortunately, it is not usually a problem finding out what a technical term or abbreviation means. There are too many glossaries to list here individually, but here are some good starting points for finding them:
The University of Wasa, Finland, has an impressive collection of computer glossary links for Chinese, Croatian, Dutch, English, Finnish, French, German, Greek, Hungarian, Italian, Norwegian, Portuguese, Spanish, Swedish, Russian, Vietnamese plus some multilingual ones: Term-Online, Online Special Language Glossaries Computing, Internet.
The Translators Home Companion also lists a number of interesting starting points for terminology searches.
A by now famous source for finding out the meanings of obscure computer-related terms is the Jargon File, the electronic Version of The New Hackers Dictionary.
A well-known and well-kept listing is BABEL: Glossary of Computer Abbreviations and Acronyms.
Most of the time when we translate software and related documentation, we are not concerned with the fine points of computer terminology, as the software is a tool that is supposed to help the user get some specific work done. So the translators requisite expertise must be in the field in which the software is supposed to do its job. All the computer expertise in the world still leaves the translator clueless when a help file contains pages upon pages of dense accounting jargon. Translators must not fall into the trap of accepting any software-related assignment just because they know a lot about computers. The results can be disastrous. Your computer
Your most important tool is also your most important reference: your computer itself. I am going on the assumption that you are working on the same platform that the software product is for which is the recommended procedure. In that case it makes eminent sense to use the localized version of your operating system in the target language. One of the most important aspects of a good user interface is that it has to be consistent. So it is always a good idea to have everything that your translation is supposed to be consistent with at your fingertips. Industry-standard glossaries
For the same reason, user interface consistency, it is important that all references to the operating system and other industry standard programs are correct and use the same terminology. If a user, for instance, is directed to click on an icon in the Control Panel of the operating system employed, but the name of that icon is translated by a term that is different from what the actual icon is called, the instruction becomes useless, and the user is led astray.
For some manufacturers there are glossaries that contain every menu item, every message, every dialog box entry that appears in their products.
Microsoft has made the glossaries for its products (operating systems and applications) available. They can be downloaded with any Internet browser.
Novell also offers its glossaries.
There is no similar resource for Unix, and it is also unlikely that there will ever be a general one, since there are too many different flavors of Unix, a fact that is compounded by localization.
To the best of my knowledge, and judging from translators repeated desperate pleas, Apple has not made its glossaries available. Client glossaries
Client glossaries, if they exist, are usually straight term lists, often culled from earlier projects. Contextual information is rarely given.
Like so many things in a translators life, the client glossary situation is often best described by the expression feast or famine. Sometimes you get nothing at all. But some clients will try to give you a printed glossary, sometimes hundreds of pages long. Working with these is hopeless. You cannot find what you need in a reasonable amount of time. Insist that the glossary be made available in electronic format. But even electronic glossaries are sometimes too large to be useful or fractured into too many files.
The most useful client glossaries come in electronic format, as tables that can be read, searched, sorted and otherwise operated on with a standard word processor or spreadsheet program. There should be columns for source and target terms, domains, syntactic information where needed, and very importantly where that term occurs in the project. Tabular output of terminology management systems would seem to be ideally suited for this purpose.
If clients have a problem maintaining proper glossaries, why not convince them that they can save a lot of time in the long run, and offer to do it for them? Although terminology management tools are frequently discussed among translators, most of us do not yet use any organized form of terminology management. What better way of learning how to use them, or not to use them, than in the context of a billable job? Client style guides
Most localization companies issue their own style guides for the various languages they handle. Often these appear to be written for non-native speakers, as they have a tendency to belabor points that a native speaker knows without having been told.
However, a well-designed style guide will help guide the translator in making stylistic decisions, such as whether to put commands in infinitive or imperative form, how to phrase chapter headings so they are stylistically congruent, and other things. Of course a style guide cannot substitute for your translators common sense and writing skills, but it may be a great help in tying the different parts of a project together and smooth out the stylistic differences between different translators. Project glossaries
The minimum you will need to know to be able to translate help files or manuals is what the software texts in the actual product are. Normally they should be available to you in tabular format; if you dont have one, ask for one, maybe the project manager forgot or did not know.
Sometimes even this minimum does not exist. In that case you can (under Windows) at least put all target terms into one file to search by concatenating them. (Hush this is best done in DOS: Open a DOS window, go to where the .RC files are, type COPY *.RC ALL.DOC, and open ALL.DOC in your word processor. Voilà.)
But seriously, how are you going to translate a manual in which every other sentence literally quotes program messages which you dont know just how they are going to appear in the target language? Surely your customer did not think that you will arrive at the exact same wording as your colleague who translated (or will translate) the user interface because there is always only one correct translation? On second thought, maybe...
Many translators consider themselves wordsmiths and definitely not layout tinkerers. In translating help files and manuals these days, however, an understanding of word processors that goes beyond mere survival level is usually a must. The PC is not a typewriter! (There is even a book by this name, by Robin Williams.) There should be, however, limits to what should be expected of you for free.Word processing
You will most probably be given files with already formatted texts which you will be expected to overwrite, preserving the original format to a tee. Normally there simply is no time for someone to copy your foreign-language text-only translation into these highly complex files, especially since this would require target-language expertise. Make sure you understand styles, hidden text, fields, tables, graphics, and other objects that will crop up in your texts. If you are open to this way of working, you will find that it has its rewards. You will find that seeing near-final format all the time and having the old and the new text in the same file and thus right in front of you is a relief to the eyes. You can use search and replace (if your target language is amenable to that, there are a few tricks to doing this well.)
I do not believe that overwriting a localization help or manual file in a word processor goes beyond what can be expected from a translator knowing his tools today. Nor do I, frankly, believe that this is worth a surcharge, but should be figured into your general rate for localization.
You might, however, try to negotiate a special (fixed or time-based) price for creating, generating, and checking a foreign-language index. It is usually not enough to simply translate the English entries (they are often hidden inside the text and caveat vendor! usually not counted by counting routines). You can check the translation of the entries for conformity with general usage in the target language, understandability, and consistency by generating the index and going back and forth. This should not be left to the engineers who dont speak the target language, so you should offer to do this. It is not that difficult to learn how to generate index entries and indexes in most word processors. DTP and engineering tools
These are not the translators responsibility.
Creating a layout, whether in a word processor or in a DTP program such as Framemaker or QuarkXPress, requires expert skills. If you are an expert, go ahead and offer this value-added service. But do charge extra for it.
Overwriting files in a DTP program is something that we are asked to do more and more frequently. What our clients often forget is that DTP programs are not made for writing, they are made for layouting. (Re)creating text in a DTP program can slow you down considerably, and these programs are also expensive and take time to learn. If you want to invest and offer this value-added service, do it by all means, but do remember that the slower speed will reduce your earnings per hour unless you consider this in your price.
Testing files is engineering work. I would go so far as to suggest that checking existing document automation features (index, table of contents) that you overwrote in your regular word processor is something you should be able and willing to do. (But remember that creating a proper index as opposed to simply translating an English one, which usually yields disastrous results is a lot of work and should usually not be billed at a word rate.) When you overwrite an HTML file, I think asking you to check the result in a browser to see whether you inadvertently destroyed any HTML tags is not asking too much. But running help compilers, resizing dialog boxes, following links across files, or testing the runtime behavior of files is not translation. If you offer this, again, this is a special value-added service to be billed for accordingly.
In software localization, translation companies sometimes try to use engineering methods to cut costs, ensure consistency, and assist the translator, in short: integrate aspects of computer-assisted translation (CAT).
What we are faced with is, however, too often not all that helpful. The tools used are often created by software engineers who dont seem to know or care enough about the mechanics of language. I recently received a file from a TC that they had been given by a well-known software manufacturer whose name you would certainly be familiar with. This file incorporated every conceivable sin in this department. It was a short file and should not have taken longer than an hour to do. But the way the file was prepared made it untranslatable.
For instance: The original sentences often consisted of fixed and variable parts, as in the following example.
No file containing ", xxx, " will be deleted.
The objects named ", xxx, " will be deleted
The process had resulted in a file that contained the following in alphabetical order
" will be deleted
No file containing "
The object named "
It is easy enough to see that this is a hopeless endeavor in many languages. In German, for instance, will be deleted comes out as wird nicht gelöscht and werden gelöscht, respectively these chunks of text are not at all the same, and in fact one is negative and one is positive! Imagine this happening with fifty or so phrases where you cant see which first (prefix) strings go with what last (suffix) strings. Imagine further this was the case here German words being stuck into the German text almost arbitrarily from a list. In some cases the suggestions were the opposite of what the original text was trying to say.
What was meant as a time and money saver ended up delayed and costing twice as much as if it had been done correctly in the first place...
In cases like this one, it is important and in the best interest of our clients to firmly reject these source files. There is often no way to salvage them, and if there is, often enough it takes so much time and guesswork that we lose money on these files. The only professional solution is to work with the client and to explain why this preparation is counterproductive. Many of the problems can be eliminated if translators know how to work in the original source files, where (hopefully) strings and texts are given completely and in context. To make your point convincingly, you should know the underlying formats and be able to work in them.
CAT (including the professional tools) suffers from one intrinsic shortcoming: it tends to assume that what is the same in language A must be the same in language B, and what was the same in one situation must be the same in another situation. Not so, as you know. These tools, then depend a lot on whether the project management knows its stuff. Professional CAT
I am always a bit afraid that techies use those tools to translate a lot of text, throw everything the machine was unable to find in a file, and send this residue to the translator, who depending on the circumstances, may be stuck with a chunk of text for which he does not know the precedent, or text where he cant go back and make necessary changes to precedent (old text may be bad or contain errors or otherwise need improvement).
The second problem is that no CAT system can output better text than is input. All archiving systems and that is what CAT essentially is, it archives and classifies preexisting translations suffer from the weakness that mediocrity and mistakes are perpetuated.
The danger is that control over what is translated how passes from the translator to the client or translation company in charge of managing projects, that is, people whose expertise is not necessarily linguistic in nature.
I strongly feel that we as translators should be in control of our tools; any actual savings may well be passed on in the form of attractive prices, but we must be sure that the existence of CAT tools is not simply used as an excuse for putting pressure on our rates. The tools and the time needed to learn how to use them are a substantial investment that has to be recovered, and everything that you or your clients will expect to get out of a CAT system will first have to be put in.
CAT is here to stay, and most of us will have to deal with it in an open and receptive manner to continue to operate profitably. But the introduction of CAT will be a bone of contention between clients, translation companies, and independent translators in the next few years as its potential and limits are not yet fully understood by all those involved in the process. It would seem only fair for everyone to share in the benefits. Certainly CAT can save translators from monotonous repetition (software translation can be incredibly boring at times. Press Return to continue!) but it should be the translator who ultimately decides if what looks like repetition is in fact repetition. Certainly CAT can help make the terminology in software localization projects, especially distributed projects, more consistent, but every now and then someone has to cut through the wallowing dust and start from scratch.
Some of these products are more and some are less friendly to the translator who is actually supposed to feed them. This is not the place to discuss the pros and cons of the various CAT systems. I will restrict myself to presenting a few URLs for some of the more popular ones.
A good translators ingenuity will often be able to overcome the worst effects of poor preparation. But there are situations unfortunately too many of them in which we as translators simply have to stand up and state that what is expected is simply not do-able. We must remember that if we do not do this, then the result may be disastrous for the manufacturer, who is, after all, spending a large amount of money on having his product translated and whose business plans may fail if overseas sales fall behind expectations for any reason.
Software translation does not have to be the low-paid drudgery where inexperienced translators fumble in the dark. It is a field that has many rewards, not the least of which is that you will come to understand your own computer, its operating system and application programs much better, enabling you to make better use of your tools. With regard to the conditions under which you work, a certain degree of perseverance is often needed to make translation managers, software engineers, and others upstream aware of problems, errors, and the translators specific needs. In localization we are part of a team, maybe more so than in other fields, and have to show team spirit. But we must make sure that our voice is heard and that our personal and professional needs are recognized by others. If we demonstrate the requisite subject expertise, we will earn the respect of our team partners, our customers, and our customers customers.
Apple Computer, Inc.: Guide to Macintosh Software Localization. 1992. ISBN 0-201-60856-1.
Hoft, Nancy L.: International Technical Communication: How to Export Information About High Technology. 1995. ISBN 0-471-03743-5.
ODonnell, Sandra: A Guide to Internationalization. 1994. ISBN 0-13-722190-8.
Uren, Emmanuel, Howard, Robert, and Perinotti, Tiziana: Software Internationalization and Localization. 1993. ISBN 0-442-01498-8.
Williams, Robin: The PC is not a typewriter. 1995. ISBN 0-938151-49-5.
Copyright © 1997 Per N. Dohler. All rights reserved.