Contents Introduction That information technology has revolutionized the translator's working environment is a fact so obvious that it no longer even bearsmentioning. For the vast majority of translators and their clients,computers have long replaced typewriters and reams of paper. Modems ande-mail have replaced manila envelopes, mass storage devices havereplaced drawers full of folders, CD-ROMs supplement dictionaries andencyclopedias, and more recently the Internet and its resources moreand more often save us a trip to the library, while various onlinecommunities have brought many translators out of their isolation.
But information technology not only offers us tools. It is itself afield 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 ofinformation technology products, it is frequently the productsthemselves that need to be translated. Whenever a program or processdisplays a word or a phrase on the screen, this means potential workfor a translator or many translators. In an article on a recent market study by Ovum Reports, The Expanding World of Globalization (Language International 9.2 1997),Liza Loughman reports that the total worldwide revenues forglobalization-related services will increase from USD 2.8 billion in1997 to USD 6.2 billion in 2000. Ovum forecasts that Japanese willaccount for 31% of all localization service revenues in 2000, up from18% in 1994, with German falling from 18% in 1994 to 12% in 2000 —which in absolute figures still represents an increase from USD 352million in 1995 to USD 639 million in 2000 and continues to put Germanin second place. Relatively smaller slices, but a larger pie. A very large pie.
International users International users of computer software have come to expect theirsoftware to “talk” to them in their own language. This is not only amatter of convenience or of national pride, but a matter ofproductivity. Users who understand a product fully will be more skilledin handling it and avoid mistakes. So they will prefer applications intheir language and adapted to their cultural environment. The international market has become very important for softwaremanufacturers. Many U.S. manufacturers derive a large percentage oftheir revenues and profits from international sales. Competition isfierce, and those companies who are best at anticipating the needs andpreferences of their international users will benefit most. With the advent of the Web, it has become vital for many manufacturersand distributors to maintain a world-wide presence. For this presenceto be effective, it is not enough to simply be there. It is equallyimportant to make sure the message gets across, and once again, thatmeans: 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, inour context a software program, to a specific locale, i.e., to itslanguage, standards and cultural norms as well as to the needs andexpectations of a specific target market. A properly localized productalso meets all the legal requirements in force in the user’s region. Users can interact with a successfully localized product in their ownlanguage and in a setting that feels natural to them. This means, forinstance, that all messages are in their own language, that they caninput names, addresses, dates, and other data in the same way theywould write them down on paper, that they can freely use their standardkeyboard characters wherever an entry can be made, and that any errormessages are comprehensible to them rather than representing Americangeekspeak. Localization comprises the program itself and any online orprinted documentation. Typically, localization is undertaken from English into otherlanguages, as most software continues to be developed in the U.S., andeven some of the software developed elsewhere is originally developedin English. Localization is performed by taking the source code for a productdeveloped for one country and modifying the source code and product tosatisfy the needs of other countries. Often teams of developers indifferent countries are needed to adapt products. If the originalproduct is not built with a view toward being localized, this can be avery expensive and time-consuming process. There is the direct cost ofmultiple development teams modifying the source code of the originalproduct. This process also produces multiple code bases, which makesfuture development and maintenance more complex. Plenty of books on localization and internationalization have beenwritten that are addressed to software engineers, web site designers,and others. Unfortunately, the role of the translator in thelocalization process has, to my knowledge, not been given any specificattention.
Introductions to localization and internationalization 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 formatthat lists a lot of interesting facts about everything that should betaken care of before we translators see the text to be translated.“This informative guide to product internationalization explores theways you can develop your software, on-line help systems, documentationand audio that will make localization as straight-forward as possible.This overview can serve ... as a primer for anyone involved withlocalization.” (Note: This document is protected and cannot be printed,only viewed.)
How localization is usually organizedTranslation companies are often chosen to provide localization. Theyeliminate the need for companies to maintain expensive in-housepersonnel. In addition, they offer a broader range of services,technical expertise, and flexibility than freelance translators andalso eliminate the need for the company to manage a large pool offreelancers. Translators who work on localization projects are often part of a largeand distributed team. Its complex, multi-layer organization poses newchallenges to those independent translators who usually work on neatlydelimited projects which they have sole responsibility for. Working onlocalization projects is more akin to working in the translationdepartment of a larger company, only that the translator does not enjoymany of the benefits of on-the-job training and rapid information flowwhich characterizes an in-house setting. In actual reality, translatorsare expected to have complete command of the tools required forsoftware localization, know the market and a lot of products, knowtheir own position in the process and workflow, and understand theconstraints involved in ever shorter production cycles — all on theirown. It is for this same reason that most translators working inlocalization do so through intermediary translation bureaus, which areoften specialized localization or “language engineering” companies. Themajority of software manufacturers now outsource their localizationactivities and maintain only a skeleton team for interfacing with theirsupplier. These companies, which can be responsible for as many as 10to 20 languages or even more, will pass the documents on to subsidiarypartners in the target countries or directly to freelance translators,either in the U.S. or overseas. These will typically be some in-housestaff, but most of the actual translation work will probably be done byfreelance translators. It is not even uncommon for corporations tooutsource the localization of their documentation to multipletranslation companies.
Project schedulingIdeally — marketing managers say — the localized versions will becompleted at the same time the original version goes to market. Ideally— translators say — localization begins when the software anddocumentation are finalized. It is immediately apparent that these areirreconcilable demands. In actual practice, therefore, it is attemptedto follow a stringent project schedule where localization is only onestep behind development. Unfortunately, development does not follow a linear schedule; featuresare developed concurrently with the documentation, and the latter iswritten, rewritten, and re-rewritten all the time. What translators getto translate is not infrequently a not-quite-final version of theultimate product. It would seem that programs should be developed fromspecifications, and documentation should be developed from, anddocument, the completed program. We have to know how we translate“Press Enter to continue” in the software itself before we can tell thepresumptive user what the program says when we describe the varioussteps in the online help. Furthermore, translation follows a cycle of comprehension. Astranslators are virtually never given more than the briefest ofsummaries of the product specifications (if that!), when it is time totranslate the software, we must do a lot of guessing as to whatfunction actually does what and consequently what to call it. Oftenenough, though, the purpose of a function, dialog box, or command willbecome apparent to the translator only when he or she finally gets tothe help file that explains it. In this case the translator may have togo back and change the term that was used in the first version of thesoftware translation; and it may not even be the same person doing thesoftware and the help, which complicates matters. Too often thesoftware is already “frozen”, that is, ready for production with noadditional changes possible by the time enlightenment comes. One of the attributes that characterize successful and sought-aftersoftware translators is precisely the ability to guess correctly aboutwhat a given software string or dialog box or function actually does,so as to avoid having to loop back wherever possible. It is here thatexperience plays an important role. All software projects shouldinclude at least some “old hands.” Software translations done only byinexperienced translators usually give away the fact that thetranslators did not have a clue. Their experienced colleagues may nothave had a clue either, but if they have a feel for their work, oftenno one will notice. It may irk those of us for whom quality exclusively means thelinguistic quality of the final product, but: there are other aspectsto quality, and they do tend to come to the fore in softwarelocalization. To the client, sometimes a linguistically mediocretranslation (craftsperson translation) delivered on time is much morevaluable than a perfect one (artist translation) that is three dayslate. Sometimes errors and inelegancies can be caught further down theline, in the various editing steps that (should) follow translation,but a file that is delayed three days may hold up an entire project andcost the client thousands of dollars in lost time-to-market.
Components of a software localization projectWhen localizing software, we are dealing with a number of differentfile types. The following subsections will present a few selectedaspects of frequently encountered file types for the various Windowsplatforms. I apologize to all prospective Mac localizers, but I have noidea how these things work on a Mac. I am therefore a good example ofsomeone who should not undertake localization for the Macintoshplatform. If you do not know either and cannot find out, neither shouldyou...
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 itsrepresentation in a resource file (in a Windows environment this iscalled an
.RC file, where .RC stands for resource compiler).
IDD_SELECT DIALOG DISCARDABLE 0, 0, 167, 106 STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "Select an object" FONT 8, "MS Sans Serif" BEGIN DEFPUSHBUTTON "OK",IDOK,108,8,50,14 PUSHBUTTON "Cancel",IDCANCEL,108,24,50,14 LISTBOX IDC_TOOLBAR_NAMES,8,8,92,88,LBS_SORT | LBS_NOINTEGRALHEIGHT | WS_VSCROLL | WS_TABSTOP PUSHBUTTON "&Help...",IDHELP,108,40,50,14 PUSHBUTTON "&Rename...",IDD_RENAME,108,64,50,14 PUSHBUTTON "&Delete",IDD_DELETE,108,80,50,14 END
You will recognize the various elements. The texts marked in redhere (in actual files they are not marked in color) are the texts totranslate. You must not translate anything else, including the “MS SansSerif” which deceptively enough is also enclosed in quotes but is thename of the font used in the dialog box. The “&” precedes a letter(shortcut) that is underlined in the actual box. The “...” must bepreserved as it tells the user that another dialog box follows whenthat button is clicked. — Everything else is information that tells thecompiler what to put where in the box. Chances are that the boxes needto be resized because the translation comes out longer than theoriginal. This is not something that is usually included in thetranslation part of localization, although some translators possess therequisite tools to do so and offer this as a value-added service. Error messages are more straightforward:
STRINGTABLE DISCARDABLE BEGIN IDS_WINEXEC_ERROR0 "The following error occurred:\n\nSystem was out of memory, executable file was corrupt, or relocations were invalid." 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 "Thefollowing error occurred:\n\nAttempt was made to dynamically link to atask, 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." END
The “\n" stands for a newline character. i.e. this is where a new line will begin in the actual text.
Help filesThe source files for Windows help files are usually .RTF files. Windowshelp compilers take this file and convert it to the familiar hypertextformats you see when pressing F1 in a Windows program.
The Hypertext organization (hypertext is text in which you can click oncertain hot spots that will take you somewhere else, usually to asubtopic relevant to what you want to know) is represented in .RTFfiles in the form of single- and double-underlined texts, hidden text,and footnotes. The title must be translated. All the normal text must be translated as well. The double-underlined parts represent hyperlinks. In the .RTF file they are followed by hidden text thattells the compiler what page to go to when this link is clicked. Thedouble-underlined part must be translated. The hidden text must remainuntouched. The single-underlined parts represent links to a help file glossary. They, too, are followed by hidden text thattells the compiler what entry in the glossary to show in a small windowwhen this link is clicked. The single-underlined part must betranslated. The hidden text must remain untouched. The colors guide users. They should be retained for the translated text. The help page starts with several footnotes beforethe title. These footnotes must never be removed. As can be seen at thebottom of the example, there are different types of footnotes.
"#" footnotes are never translated. They representhyperlink targets. If a different page wants to link to this page, itwould do so by placing “Example_Application_Welcome_Menu" in hiddentext behind a hyperlink. Any changes here destroy the help file.
"$" footnotes are titles as they appear in the Helpcontent list. These footnotes must be translated. It is recommendedthat 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. Some help compilers support additional footnote classes. If you now remember that graphic elements are treated like letters bythe program with which you work on the .RTF file (probably MS Word),i.e. they can be underlined and used as hyperlinks, you know most ofwhat you have to know to confidently start translating help fileswithout destroying them.
Readme files Readme files usually contain late-breaking news that did not make itinto the documentation, additional setup information, or correctionsand additions to the manual. Usually these are plain text files. If youuse your word processor to work on these, you must remember not to savethem in the word processor’s format but as plain text, using thecorrect 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 theend 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 ofimage files in which the information is present as pixels and cannot beedited in the word processor or editor. These bitmaps will be recreatedwith an image-processing program, and the translator’s job is tofurnish the translations to be included. In simpler cases thetranslator may be asked to overwrite graphics files. This should bebilled 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 inheavily formatted form, with many hallmarks of document automation,with the expectation that translators overwrite them; this of coursepresupposes that translators know how to use their tools. You will findmore details in the section
Writing tools and their limits.
Client-prepared file formats A number of mostly larger localization companies take the resources andfiles to be translated and produce text files from them. These textfiles 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 writeyour translations, what elements you must not change, and the meaningof various tags and hints you may encounter in the files you areworking on. One advantage of this procedure is that translators can be providedwith one set of instructions for a variety of different source fileformats. A second advantage is that you can translate files foroperating system environments other than your own. If the target systemis a system that few people have installed, this may be the only way towork 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 donot usually present any specific problems. Basic references Bilingual dictionaries In many other fields, one of the most important and most frequentlyconsulted references are bilingual dictionaries, often in paper form,sometimes on CD-ROM. Bilingual dictionaries always have theirlimitations, but working in a field that does not have these referencesmakes you appreciate them more. Bilingual dictionaries in this fieldare often partly obsolete as soon as they appear. Not only do new wordscome up and old words fall into disuse, but the way existing words areused 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 aone-way street from English to other languages. At the same time, weare often faced with the necessity of coining the words we needourselves, or making an executive decision between severalalternatives, none of which has yet become established. Carefully written and edited computer magazines in the target languageare a very useful source of computer terminology. If you don’t live inthe country of your target language, you should still be able to readthem on the Web. Supposedly, computer magazines are a little lessephemeral than web sites, but a web site may be more on top oflate-breaking news and is also easier to search. However, the approach of jumping on the bandwagon of preliminaryjournalese “translations” as they are usually found in the firstexcited account of a new program, process, or device and of sanctioningthem by copying is, in my opinion, a serious mistake. It is preciselyin the computer field that we can do something for our readers bychoosing our words conscientiously and prudently. Those of us who are confronted with English and with computers andcomputer-related texts in our own languages every day might tend tothink that our languages are just inundated with English loan words. Onthe whole, however, this impression is misleading. Of course there aredifferences in degree between the various European languages (I cannotspeak about any others) but it is probably true everywhere that modernsports, some technical and scientific fields, computers, andcomputer-related topics, and certain aspects of cultural — particularlythose that address a more youthful audience — tend to be full of “cool”loan words. But if you read newspaper and magazine articles that do nothappen to concentrate on these topics (and a good number of those thatdo), chances are that the proclaimed “inundation” of our language withAnglicisms is fortunately still more or less limited to what isreasonable. So with these caveats, computer magazines and carefully edited websites (too many are, unfortunately, hastily thrown together by peoplewith not much respect for their readers) in the target language areprobably the best sources of computer terminology.
General monolingual computer-related glossaries Fortunately, it is not usually a problem finding out what a technicalterm or abbreviation means. There are too many glossaries to list hereindividually, but here are some good starting points for finding them: The University of Wasa, Finland, has an impressive collection ofcomputer 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
Translator’s 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 Hacker’s 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, asthe software is a tool that is supposed to help the user get somespecific work done. So the translator’s requisite expertise must be inthe field in which the software is supposed to do its job. All thecomputer expertise in the world still leaves the translator cluelesswhen a help file contains pages upon pages of dense accounting jargon.Translators must not fall into the trap of accepting anysoftware-related assignment just because they know a lot aboutcomputers. The results can be disastrous.
Your computer Your most important tool is also your most important reference: yourcomputer itself. I am going on the assumption that you are working onthe same platform that the software product is for — which is therecommended procedure. In that case it makes eminent sense to use thelocalized version of your operating system in the target language. Oneof the most important aspects of a good user interface is that it hasto be consistent. So it is always a good idea to have everything thatyour translation is supposed to be consistent
with at your fingertips.
Industry-standard glossaries For the same reason, user interface consistency, it is important thatall references to the operating system and other industry standardprograms are correct and use the same terminology. If a user, forinstance, is directed to click on an icon in the Control Panel of theoperating system employed, but the name of that icon is translated by aterm that is different from what the actual icon is called, theinstruction becomes useless, and the user is led astray. For some manufacturers there are glossaries that contain every menuitem, every message, every dialog box entry that appears in theirproducts. 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 thatthere will ever be a general one, since there are too many differentflavors of Unix, a fact that is compounded by localization. To the best of my knowledge, and judging from translators’ repeateddesperate 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 rarelygiven. Like so many things in a translator’s life, the client glossarysituation is often best described by the expression “feast or famine”.Sometimes you get nothing at all. But some clients will try to give youa printed glossary, sometimes hundreds of pages long. Working withthese is hopeless. You cannot find what you need in a reasonable amountof time. Insist that the glossary be made available in electronicformat. But even electronic glossaries are sometimes too large to beuseful or fractured into too many files. The most useful client glossaries come in electronic format, as tablesthat can be read, searched, sorted and otherwise operated on with astandard word processor or spreadsheet program. There should be columnsfor source and target terms, domains, syntactic information whereneeded, and — very importantly — where that term occurs in the project.Tabular output of terminology management systems would seem to beideally suited for this purpose. If clients have a problem maintaining proper glossaries, why notconvince them that they can save a lot of time in the long run, andoffer to do it for them? Although terminology management tools arefrequently discussed among translators, most of us do not yet use anyorganized form of terminology management. What better way of learninghow to use them, or not to use them, than in the context of a billablejob?
Client style guides Most localization companies issue their own style guides for thevarious languages they handle. Often these appear to be written fornon-native speakers, as they have a tendency to belabor points that anative speaker knows without having been told. However, a well-designed style guide will help guide the translator inmaking stylistic decisions, such as whether to put commands ininfinitive or imperative form, how to phrase chapter headings so theyare stylistically congruent, and other things. Of course a style guidecannot substitute for your translator’s common sense and writingskills, but it may be a great help in tying the different parts of aproject together and smooth out the stylistic differences betweendifferent translators.
Project glossaries The minimum you will need to know to be able to translate help files ormanuals is what the software texts in the actual product are. Normallythey should be available to you in tabular format; if you don’t haveone, ask for one, maybe the project manager forgot or did not know. Sometimes even this minimum does not exist. In that case you can (underWindows) at least put all target terms into one file to search byconcatenating them. (Hush — this is best done in DOS: Open a DOSwindow, 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 everyother sentence literally quotes program messages which you don’t knowjust how they are going to appear in the target language? Surely yourcustomer did not think that you will arrive at the exact same wordingas your colleague who translated (or will translate) the user interfacebecause there is always only one correct translation? On secondthought, maybe...
Writing tools and their limitsMany translators consider themselves wordsmiths and definitely notlayout tinkerers. In translating help files and manuals these days,however, an understanding of word processors that goes beyond meresurvival level is usually a must. The PC is not a typewriter! (There iseven 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 textswhich you will be expected to overwrite, preserving the original formatto a tee. Normally there simply is no time for someone to copy yourforeign-language text-only translation into these highly complex files,especially since this would require target-language expertise. Makesure you understand styles, hidden text, fields, tables, graphics, andother objects that will crop up in your texts. If you are open to thisway of working, you will find that it has its rewards. You will findthat seeing near-final format all the time and having the old and thenew text in the same file and thus right in front of you is a relief tothe eyes. You can use search and replace (if your target language isamenable to that, there are a few tricks to doing this well.) I do not believe that overwriting a localization help or manual file ina word processor goes beyond what can be expected from a translatorknowing his tools today. Nor do I, frankly, believe that this is wortha surcharge, but should be figured into your general rate forlocalization. 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 (theyare often hidden inside the text and — caveat vendor! — usually notcounted by counting routines). You can check the translation of theentries for conformity with general usage in the target language,understandability, and consistency by generating the index and goingback and forth. This should not be left to the engineers who don’tspeak the target language, so you should offer to do this. It is notthat difficult to learn how to generate index entries and indexes inmost word processors.
DTP and engineering tools These are
not the translator’s responsibility. Creating a layout, whether in a word processor or in a DTP program suchas Framemaker or QuarkXPress, requires expert skills. If you are anexpert, go ahead and offer this value-added service. But do chargeextra for it. Overwriting files in a DTP program is something that we are asked to domore and more frequently. What our clients often forget is that DTPprograms are not made for writing, they are made for layouting.(Re)creating text in a DTP program can slow you down considerably, andthese programs are also expensive and take time to learn. If you wantto invest and offer this value-added service, do it by all means, butdo remember that the slower speed will reduce your earnings per hourunless you consider this in your price. Testing files is engineering work. I would go so far as to suggest thatchecking existing document automation features (index, table ofcontents) that you overwrote in your regular word processor issomething you should be able and willing to do. (But remember thatcreating a proper index — as opposed to simply translating an Englishone, which usually yields disastrous results — is a lot of work andshould usually not be billed at a word rate.) When you overwrite anHTML file, I think asking you to check the result in a browser to seewhether you inadvertently destroyed any HTML tags is not asking toomuch. But running help compilers, resizing dialog boxes, followinglinks across files, or testing the runtime behavior of files is nottranslation. If you offer this, again, this is a special value-addedservice to be billed for accordingly.
Computer-assisted translation (CAT)
In software localization, translation companies sometimes try to useengineering methods to cut costs, ensure consistency, and assist thetranslator, in short: integrate aspects of computer-assistedtranslation (CAT). The most common strategies are the leveraging of target language termsand phrases from existing translations and the elimination ofduplicates. How the result is presented to translators depends on thetools used. In the best of cases, the translator is given somethinglike a table with the source texts in one column, any material thatmight help understand strings and keep them consistent in a secondcolumn, and the translation is then entered in a third column.
Problems with home-grown CAT What we are faced with is, however, too often not all that helpful. Thetools used are often created by software engineers who don’t seem toknow or care enough about the mechanics of language. I recentlyreceived a file from a TC that they had been given by a well-knownsoftware manufacturer whose name you would certainly be familiar with.This file incorporated every conceivable sin in this department. It wasa short file and should not have taken longer than an hour to do. Butthe 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 infact one is negative and one is positive! Imagine this happening withfifty or so phrases where you can’t see which first (prefix) strings gowith what last (suffix) strings. Imagine further — this was the casehere — German words being stuck into the German text almost arbitrarilyfrom a list. In some cases the suggestions were the opposite of whatthe original text was trying to say. What was meant as a time and money saver ended up delayed and costingtwice 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 ourclients to firmly reject these source files. There is often no way tosalvage them, and if there is, often enough it takes so much time andguesswork that we lose money on these files. The only professionalsolution is to work with the client and to explain why this“preparation” is counterproductive. Many of the problems can beeliminated if translators know how to work in the original sourcefiles, where (hopefully) strings and texts are given completely and incontext. To make your point convincingly, you should know theunderlying formats and be able to work in them. CAT (including the professional tools) suffers from one intrinsicshortcoming: it tends to assume that what is the same in language Amust be the same in language B, and what was the same in one situationmust be the same in another situation. Not so, as you know. Thesetools, then depend a lot on whether the project management knows itsstuff.
Professional CAT I am always a bit afraid that techies use those tools to “translate” alot of text, throw everything the machine was unable to find in a file,and send this residue to the translator, who depending on thecircumstances, may be stuck with a chunk of text for which he does notknow the precedent, or text where he can’t go back and make necessarychanges to precedent (old text may be bad or contain errors orotherwise need improvement). The second problem is that no CAT system can output better text than isinput. All archiving systems — and that is what CAT essentially is, itarchives and classifies preexisting translations — suffer from theweakness that mediocrity and mistakes are perpetuated. The danger is that control over what is translated how passes from thetranslator to the client or translation company in charge of managingprojects, that is, people whose expertise is not necessarily linguisticin nature. I strongly feel that we as translators should be in control of ourtools; any actual savings may well be passed on in the form ofattractive prices, but we must be sure that the existence of CAT toolsis not simply used as an excuse for putting pressure on our rates. Thetools and the time needed to learn how to use them are a substantialinvestment that has to be recovered, and everything that you or yourclients will expect to get out of a CAT system will first have to beput in. CAT is here to stay, and most of us will have to deal with it in anopen and receptive manner to continue to operate profitably. But theintroduction of CAT will be a bone of contention between clients,translation companies, and independent translators in the next fewyears as its potential and limits are not yet fully understood by allthose involved in the process. It would seem only fair for everyone toshare in the benefits. Certainly CAT can save translators frommonotonous repetition (software translation can be incredibly boring attimes.
Press Return to continue!)but it should be the translator who ultimately decides if what lookslike repetition is in fact repetition. Certainly CAT can help make theterminology in software localization projects, especially distributedprojects, more consistent, but every now and then someone has to cutthrough the wallowing dust and start from scratch. Some of these products are more and some are less friendly to thetranslator who is actually supposed to feed them. This is not theplace to discuss the pros and cons of the various CAT systems. I willrestrict myself to presenting a few URLs for some of the more popularones.
What to do when things go GNORWA good translator’s ingenuity will often be able to overcome theworst effects of poor preparation. But there are situations —unfortunately too many of them — in which we as translators simply haveto stand up and state that what is expected is simply not do-able. Wemust remember that if we do not do this, then the result may bedisastrous for the manufacturer, who is, after all, spending a largeamount of money on having his product translated and whose businessplans may fail if overseas sales fall behind expectations for anyreason. What can be particularly frustrating is to discover an error (and thereis hardly a project where you won’t) only to find that you can’t conveyit back up the development chain where it would have to be fixed (andpassed back down to all the other languages and translators). The golden rule here, as elsewhere, is: Communicate! Justabout anything can be fixed if everyone who should know about it doesknow about it early enough. Of course no stressed-out project managerwill be able to answer a lot of questions about things that are foryou, the translator, to know. But if we want to be experts incommunication, we need to communicate, and we should do so in a mostprofessional manner: briefly, to the point, and addressing thedesignated contact or other person in charge. But we have to make itvery clear to our contacts that the problems we discover (and who looksmore closely at texts, formatting or even the program itself than thetranslator?) are not simply going to go away by waiting.
ConclusionSoftware translation does not have to be the low-paid drudgery whereinexperienced translators fumble in the dark. It is a field that hasmany rewards, not the least of which is that you will come tounderstand your own computer, its operating system and applicationprograms much better, enabling you to make better use of your tools.With regard to the conditions under which you work, a certain degree ofperseverance is often needed to make translation managers, softwareengineers, and others upstream aware of problems, errors, and thetranslator’s specific needs. In localization we are part of a team,maybe more so than in other fields, and have to show team spirit. Butwe must make sure that our voice is heard and that our personal andprofessional needs are recognized by others. If we demonstrate therequisite subject expertise, we will earn the respect of our teampartners, our customers, and our customers’ customers. Finally, we should never forget our responsibility to the users of the software we are localizing.
Further readingApple 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.
O’Donnell, 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. http://accurapid.com/journal/softloc.htm