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.
Unfortunately, development does not follow a linear schedule; features are developed concurrently with the documentation, and the latter is written, rewritten, and re-rewritten all the time. What translators get to translate is not infrequently a not-quite-final version of the ultimate product. It would seem that programs should be developed from specifications, and documentation should be developed from, and document, the completed program. We have to know how we translate “Press Enter to continue” in the software itself before we can tell the presumptive user what the program says when we describe the various steps in the online help.

Furthermore, translation follows a cycle of comprehension. As translators are virtually never given more than the briefest of summaries of the product specifications (if that!), when it is time to translate the software, we must do a lot of guessing as to what function actually does what and consequently what to call it. Often enough, though, the purpose of a function, dialog box, or command will become apparent to the translator only when he or she finally gets to the help file that explains it. In this case the translator may have to go back and change the term that was used in the first version of the software translation; and it may not even be the same person doing the software and the help, which complicates matters. Too often the software is already “frozen”, that is, ready for production with no additional changes possible by the time enlightenment comes.

One of the attributes that characterize successful and sought-after software translators is precisely the ability to guess correctly about what a given software string or dialog box or function actually does, so as to avoid having to loop back wherever possible. It is here that experience plays an important role. All software projects should include at least some “old hands.” Software translations done only by inexperienced translators usually give away the fact that the translators did not have a clue. Their experienced colleagues may not have had a clue either, but if they have a feel for their work, often no one will notice.

It may irk those of us for whom quality exclusively means the linguistic quality of the final product, but: there are other aspects to quality, and they do tend to come to the fore in software localization. To the client, sometimes a linguistically mediocre translation (craftsperson translation) delivered on time is much more valuable than a perfect one (artist translation) that is three days late. Sometimes errors and inelegancies can be caught further down the line, in the various editing steps that (should) follow translation, but a file that is delayed three days may hold up an entire project and cost the client thousands of dollars in lost time-to-market.

Related Articles:

Project scheduling :: Difficulties Localizing Software :: Methods for Localizing Software :: How Localization is Usually Organized :: Software Localization Tools