In this series of articles, I would like to show how collaboration between software developers, UI designers and translators is essential for successful localization, and how (and why) you should go about organizing such a team. This first article shows some common unintentional mistakes software developers tend to make.

According to wikipedia, localization is the process of translation of messages which a program presents to a user into various languages. Sounds simple enough. Newcomers to localization often use the following approach: export all strings from the finished application, send the strings to a bunch of translators who do not know each other, wait one or two months (you can do a lot of work on another project while the translators toil away), receive the translated texts, pay ridiculous sums for the translations, import and recompile, and pronto! Instant translation, right?

Wrong. Such an approach results in horribly distorted texts, sometimes outright wrong sentences and many other problems. Sadly, such an approach is quite often used in practice. It degrades the software as a whole and the result has to be thrown away or repaired, incurring expenses that equal or exceed the original price of the translation.

If you do not know any language well other than your mother tongue, you simply cannot imagine the range of problems that occur in translation. For instance, two translators can produce totally different text (different words) although the meaning stays the same. True localization requires collaboration between software developers and translators, very close and very intensive collaboration. Or, if you work for a large company, it probably employs UI developers and these UI guys and gals can act as an interface between application developers and translators.

And you need to have your localization ready yesterday. No time to help translators. All of your application's messages are clearly written and present no problem to a qualified professional translator... sentences like "Time flies“ are unambiguous. Or are they? Let's see:

Time flies: A "fly“ is an insect. "Time flies" are insects that travel through time without using a time machine (here "time" functions as an adjective – use of a noun as an adjective is common in English)..

Time flies: I want you to time my flies! Please measure the time it takes them to get from point A to point B! Well, okay, but what flies are we talking about? Perhaps I'm an entomologist and I'm asking you to time how long it takes my flies to get from A to B. Or I'm a baseball trainer and I want you to time how long the flies [=fly balls] hit by members of the team take to get from home-plate to some point in the field. (Here "time" functions as a verb.)

Note: You might feel that "Time flies" is as unlikely a sentence to appear in a technical text as possible. I used this short sentence purposely because of titles (column and row headings) and instructions displayed in software, which are often very short, as you will see later in this article.

Of course, the third meaning is the one most likely to be correct. But you can't be sure without contextual remarks or background information – a few explanatory words. that will not go into the translation itself but will enable the translator to choose the right vocabulary and grammar in the target language. Providing background information is expensive in terms of time required to type the information and even to discover what type of information is required. Nonetheless, background information is necessary. Let me show you what kind and what amount of context is needed with a couple of examples.

[Note: The context generally is made up not of explanatory words but lived structures that (a) our lives are full of; and (b) a translator is, should be, has to be implicitly familiar with. Recognition of this context is, for the most part, a non-verbal, intuitive matter. Nonetheless, explanatory notes can provide considerable help to the translator.]

A simple text export is a flat file that contains all text messages used in your program, such as prompts, database column names, descriptions, window titles. Look at this example:

resolution
number of 
number of tables
from
to
April 
image counter 
stretching center
enter new password
Do you want it to be created?
 number (where  is one of [Operator, Table, Chair])
Rocker
Process sequences
time flies

Can you guess how many of the above lines can be translated without background information ? Let's look at them one by one:

You can see that of all these sentences and sentence fragments, only one (perhaps) can be translated without context. All the rest require supporting documentation to be translated correctly.

It is difficult, or downright impossible, to provide perfect contextual remarks without feedback from the translator. Therefore you should provide all the context you can think of, and tell your translators that they are free to ask for more context at any time.

Writing all this supportive text is time-consuming. Alternatively, you could provide screenshots and no other explanation, but in such a case the translator would spend quite some time reading the screenshots and trying to understand the workflow (and you will need to reimburse him or her for the effort) and he can still make mistakes. It's better to provide both context and screenshots.

Perhaps the best approach is if the translator can actually use the software or website in question. You will have to budget for the time the translator will spend coming to understand the software, but you will not need to provide much context. There are disadvantages in this approach: to investigate a website thoroughly, the translator must have a good and affordable internet connection, which very often is not the case. For locally-installed software (not web-based), producers are rarely willing to provide the translator with a copy of the localized software, even when the translator specifically asks for it.

Part II of this article can be found in Issue 10 of ZopeMag

Milos Prudek: Milos Prudek has been working professionally in the IT industry since 1988. While working as an application programmer with FoxPro and Pascal, he also taught a wide range of IT subjects to different audiences. A freelance developer and writer since 1991, he established a local ISP company, which he has since expanded. He has been active in Zope development since 1998 and runs a small Web usability and Web development company Spox Design. His only passion is promoting tolerance among people.