Author: Dag Forssell
 Dag Forssell was born and raised in Sweden. In 1965 he earned an M.S. Mechanical Engineering from Chalmers University of Technology, Sweden. In 1967 he and his wife Christine emigrated to the U.S. and in 1971 he received an MBA with emphasis on finance from the University of Southern California.
Dag has worked in American industry since 1967 with assignments in design engineering, manufacturing, financial reporting, marketing, and management. He is experienced as a speaker and writer on technical and leadership subjects. Three articles were published 1993-95 in The Engineering Management Journal and are included in his book: Management and Leadership: Insight for Effective Practice.
In 1994 Dag and Christine established the Forssell Translation Team which has successfully handled a number of translation and localization projects.
One Translator's Thoughts on Software Localization
My wife Christine and I haveparticipated in software localization many times. This has meantparticipating in bits and pieces of the process—translating strings,manuals or help files as requested by translation agents. Recently, Ihave been privileged to work on a large localization project in anintegrated fashion, with all available resources at hand, and found itmost satisfying. I don't know all there is to know about the softwareengineering that goes into localization, but I have experienced theprocess as a translator when it was organized different ways by agentsand their customers. From my perspective, the way a project isorganized makes a substantial difference to the ultimate quality of theproject. Here is an attempt to portray two basic approaches in the formof two short scripts, one labeled Distributed, the other Integrated. Comments in the scripts reflect my experience. Regarding program manuals, documentation and help texts, where the software has already been translated, please note Additional information at the end of this article. Software localization: A translators interpretation—Script in two parts
Summary table Script in two parts Part I: The distributed approach Part II: The integrated approach Additional information Glossary of terms Industry standard glossaries Informative article Translation considerations
Summary Table SOFTWARE LOCALIZATION | | Distributed | Integrated | Salesperson involvement | Take order | Explain process | Customer involvement | Laid back | Rapid response | Translation resources | Few or none | Complete | Translator satisfaction | Minimal | Good | Translation speed, program | Normal/slow | Slow/meticulous | Translation speed, help text | Normal | Normal or a bit faster | Project Quality | Mediocre | High |
Cast of characters: Customer: | Software company that needs localization (software translation) | Buyer: | Customer's purchasing agent—buys translation from translation agency | Expert: | Expert on customer's software—programmer or applications manager | Salesperson: | Translation agent Sales representative | Manager: | Translation agent Project manager | Engineer: | Translation agent Technical manager | Translators: | One or more |
Script in Two Parts Part I: Software localization—The distributed way:(break it down, spread it around and get it done fast)Buyer: | We want to have this program translated. Can you do that? | | Salesperson: | Yes, we have extensive experience with software localization. | | Buyer: | Our marketing people want it yesterday. When can we have it? | | Salesperson: | Let's see—we are talking about 20,000 words of program translation and200,000 words of help texts and manuals. With two or three translatorsdoing 10,000 words a week each, translation alone will take 10-12weeks. Let me schedule it and include time for engineering andvalidation by your expert. Looks like we can do it in 16-18 weeks. | | Buyer: | Fine, go ahead. | | Salesperson: | Great!! I got the order. It appears to us that if the buyer does not understandtranslation, but wants the job done quickly, and the salesperson eitheris not familiar with translation or simply feels compelled by real orimagined competitive pressures to promise rapid delivery. Deadlines fora project are firmly established—tight deadlines that take onoverriding importance. | | Manager: | Glad you got the order! Did you ask for reference materials? I see,they wanted delivery yesterday—I had better break this down, spread itaround and get it done fast. If buyer and sales person focus on due dates, but have littleunderstanding of translation, they are not likely to review and discusswhat reference materials exist.—Materials that translators who actuallywill be doing the job can use to assure consistency and quality. Thismeans that the project manager will tell us that there are no referencematerials available. We frequently ask agents to contact the customeragain with a request for reference materials. Sometimes we are asked to translate a glossary of typical terms,created by the Customer expert, as a preliminary step. Such a glossarycan be used for translation of strings. Translating a glossary whencontext is available is fine, but translating without context is never a good idea. | | Engineer: | (Receives program code from customer and prepares a series of Resource Files (software strings) for translation.) | | Manager: | (Sends software strings (the program elements) to one translator for translation.) The working program itself is not sent—after all, the buyer did notvolunteer to provide it. Help texts and manuals are not sent totranslator who will work on strings. That would just slow him or herdown. Pay the standard word rate—a word is a word is a word. In our experience, working with a large number of project managers,we find that many who have never spoken another language, or have noexperience as translators, appear to think that translation is a matterof substituting a word in one language for a word in another language.If so, what the translators' backgrounds are, whether they understandthe source material and how they expresses ideas in the target languagedoes not matter. | | Translator: | (Translates the software strings without access to reference materials or working software.) When we have been asked to translate software strings, we haverarely been provided a look at the help texts and manuals or theprogram. The program menu structure is contained in these strings andas long as the menu items are standard Windows fare, we are OK. Butwhen you get one or two words by themselves, unusual or strangetechnical or business terms with no context whatsoever, this processbecomes a challenge with a most uncertain outcome. | | Engineer: | (Receives the translation from the project manager and rebuilds it into working software.) Thetranslation will likely require extensive revision when a linguist andthe expert review it. Worse yet, it may not be thoroughly reviewed andrevised. | | Expert: | (Reviews program translation when program has been rebuilt.) Naturally, it is a good idea to have the customer expert review theprogram translation, and this is likely included in the projectschedule. But if the expert is preoccupied with something else, thetranslation of help files will proceed at full speed without thisreview. | | Manager: | (Farms out the help texts and manuals to several translators. Thesetranslators can now be provided with the program translation and askedto translate the help texts and manuals consistent with it.) | | Translators: | (Translate help text, still without access to manuals or workingsoftware, but with access to the software string translation and anyother word list developed for the project as glossary.) If two or three translators work on the help texts and manuals,terms used in the software strings will be propagated in the help textsand manuals. This assures that mistaken translations—individual termstranslated incorrectly in the software strings due to a lack ofcontext, will be widely distributed in the help texts and manuals.Other terms that appear throughout the help texts and manuals, but notin any project-specific glossary, will likely be translated two orthree different ways. This is especially true if the agent does notfacilitate close communication between translators. | | Engineer: | (Compiles the help files with the program and the finished software package is delivered to the Customer.) |
The end result of this process is software localization of questionable quality. | Chorus: | Let's all hope the Customer's end users don't complain. |
Part II: Software localization— The integrated way:(Get it together, keep it together and get it done well) | Buyer: | We want to have this program translated. Can you do that? | | Salesperson: | Yes, we have extensive experience with software localization. We havefound that it is best to work closely with your company's programmersand application managers. Will they be available to work with us? | | Buyer: | Yes, I think so. Our marketing people want it yesterday. When can we have it? | | Salesperson: | Before we discuss delivery, let me ask you what your marketing peopleexpect in terms of quality. Does your company want a quick and dirtylocalization, or do you want something your end users will be happywith? The difference may be a few weeks. | | Buyer: | Why do you ask? We want quality, of course!!!!! When can we have it? Ifyou can't deliver yesterday, I will find someone who can! | | Salesperson: | Let's see—we are talking about 20,000 words of program strings and200,000 words of help texts and manuals. We will find a translator whois familiar with this kind of application to work on the strings andprovide her with all the help text and working software as reference.You do have a working copy of the software I can take with me, right?Also, we will need all manuals that go with the application so we canpass them on to the translator. Anything that will help the translatorbecome familiar with the application, menu structure, dialog boxes,error messages etc. The translator should have plenty of time with thestrings so she can become familiar with the terminology you use. Who isyour expert on this application? We will need to stay in close touchbecause, in our experience, the translator will have lots of questionsabout idiosyncratic terms, abbreviations, confusion and inconsistenciesshe discovers in the source language. Just doing a thorough job with the program strings as a first step andpreparing a glossary at the same time will take about four weeks. Afterthat, two or three translators can use the glossary the firsttranslator has created to keep the terminology consistent throughoutthe help texts and manuals. That phase will take about 10 weeks. Let meplan it out with time for engineering and validation by your expert.Looks like we can do it in 18-20 weeks. With an up-front emphasis onstrings and a glossary translated in context, this is just two weeksmore than a somewhat faster parallel effort that leads to much lowerquality. | | Buyer: | Sounds reasonable to me. Let me get you a copy of the program rightnow, check availability of support materials, and confirm that ourexpert will be available.... Fine, go ahead! | | Salesperson: | Great!! I got the order. | | Manager: | Glad you got the order! You sure covered all the bases and got what ourtranslators will need. You got it all together. I will keep it togetherand get it done well. | | Engineer: | (Receives program code from customer and prepares a series of Resource Files (software strings) for translation.) | | Manager: | (Sends software strings, all help text and a working copy of theprogram—all together—to a translator who understands the subject matterand is familiar with software and operating system practice (e.g.Windows and Microsoft glossaries).) | | Translator: | (The translator can now review all materials thoroughly, translatethe software and develop a glossary. The customer's expert is availableto answer questions.) My recent experience, working with an experienced, cooperative managerand a responsive expert, has been that I can translate the strings (theprogram elements—menu structure, dialog boxes and messages) and relatethese elements to the way they are explained in the help texts andmanuals. I can review the program and see how the menu structure is setup—what the functional relationships are between various text elementsthat are extremely brief and, taken alone, cryptic. I have found that having access to this context makes a majordifference. I have been able to translate a great number of terms,whether business, technical or computer related, not based on what thedictionary says or how these terms are ordinarily used, but based onhow they are used or misused in this particular program—based on thisparticular expert's or his company's individual, idiosyncratic lingo. Rather than making fast and loose translations of individual terms outof context, I am able to look them up in the help text, read what theymean and see how they are used. I am able to review the menu structureand the dialog boxes in the working software. Naturally, this takestime. In fact, I found this translation work far more meticulous andtime-consuming than anything I have experienced before. But the work issatisfying because I know I can do a good job. I am confident that thislocalized program will make sense to its user. While I look up terms in the help texts and manuals and decide how totranslate them, I take notes for use later on, when I and my teamtranslate the help files. If a term exists in abbreviated form in thesoftware strings, I take note of it and its translation in its fullform as well, because that is how it appears in the help texts andmanuals. This, together with the strings themselves, becomes the basicglossary for this project. | | Engineer: | (Receives the translation from the project manager and rebuilds it into working software.) The program will require review and abbreviation of some termsto fit available space in dialog boxes, but revisions will be minimalwhen a linguist and the expert review it. | | Expert: | (Reviews program translation when program has been rebuilt.) As with distributed translation, it is a good idea to have the customerexpert review the program translation, and this should be included inthe project schedule. But if the customer expert is preoccupied withsomething else, the translation of help files will proceed at fullspeed without this review. The difference with integrated translationis that even without the review, I am confident that the program andthe help texts and manuals will hang together. | | Manager: | (Assigns the help texts and manuals to several translators.) | | Translators: | (Translate help text with access to the glossary inherent in theprogram translation as well as additional glossary notes made duringthe string translation, and with access to manuals and workingsoftware.) Terms that appear throughout the help texts and manuals can now betranslated consistently. Additional coordination between severaltranslators can enhance consistency even more. | | Engineer: | (Compiles the help files with the program and the finished software package is delivered to the Customer.) |
The end result of this process is software localization of high quality. Chorus: | Let's all take pride in a job well done. |
Additional information Glossary of terms: Program, Resource files, .RC files, Strings: These termsrefer to the visible part of the software, the user interface: menus,dialog boxes, error messages—any text that appears in the program andits operation and needs to be translated. Help text, manual, documentation: All the other text thatrelates to the program interface, describing it, explaining whathappens, troubleshooting tips, installation instructions etc. Needlessto say, all this should be compatible with the terminology used in theprogram interface itself.Industry standard glossaries: Microsoft glossaries: Microsoft publishes glossaries based on the .RC files for its operating systems and most of its programs. See: ftp://ftp.microsoft.com/developr/MSDN/NewUp/glossary/. Apple glossaries: The last time I found any Appleglossaries was back in 1996 for OS 8.6. Apparently Apple no longermakes glossaries available; however, I recently found an English-onlydescription of Mac terms as a pdf file at http://developer.apple.com/techpubs/macos8/Glossary/IMGlossary.pdf, still for OS 8. Informative article: Facets of Software Localization, A Translator's View by Per N. Dohler is an excellent, comprehensive article published in an earlier issue of the Translation Journal at http://accurapid.com/journal/softloc.htm, which I found when I was looking for information on Resource files. Translation considerations: Pricing translation: It should be apparent from my discussionin the scripts in this article that a standard word rate fortranslation of normal text should not apply to translation of .RCprogram string files. Software already translated: If the program has already been translated and the customer wants some documentation translated, the translator should receive the .RC filesin both the source and target languages, or some combination of these,such as segmented Trados files. These files provide complete insightinto the terminology and all messages tucked away in the program. Theyare the key to good, consistent translation of accessory documentation.As the translator works on the documentation, the translator should bewelcome to ask about and/or change mistakes discovered in the softwarestrings. The program itself should also be provided—in bothlanguages. The program provides a look and feel for the program that.RCfiles do not. But programs do not easily surrender equivalent text andmessages. Programs or demos are not equivalent to the Resource filesand vice versa. When a customer solicits a bid: If your agent representativeis not intimately familiar with localization, please don't submit a bidbased on a casual word count. Review the assignment carefully andconsult an experienced translator who is familiar with the program'ssubject matter as well as localization. |
