Someone: So, what’s your work?
Me: I do translations.
Someone: Aha… So your English must be excellent.
Me: Well, not exactly…
Someone: How is it possible?
Me: I do software localization, which is more about background knowledge than excellent language knowledge.
Someone: Aha…

That conversation happened many times. Why is it so interesting? Well, it isn’t, but gives some taste on what people think and know about software localization. Sure, it’s some kind of translation, but one of the many specialized areas of it.

What am I talking about?

The input of the software localization process is a software in a given, usually English language, and the output is a software with the same functionality, but displaying its user interface in another language. The localization process can be made up of many stages, for example: choosing languages which you want to localize your application to, choosing the right tools for the process, exporting strings to an editable and translatable format, choosing a supplier who is able to make the translation work, building, testing and finally distributing the localized version of the application. But I won’t cover the whole process; in fact, I won’t fully cover any part of it, but I will bring examples how can you make a mess of the outcome, producing a localized application, which is irritating to the end user – finally, throwing your money out of the window when paying for the whole process.

What to localize?

Let’s see the first question. What’s your goal? You need a localized application, which can be sold to the people speaking the given language. But… Wait a moment. Sure, you have an application, but what’s the product? Is it simply some kind of software, or maybe there are some help files belonging to it? Does it have an installation and administration manual? Does it have a box, a printed start-up poster, a “return to us” registration card? Does it have a support forum, a “Minimum requirements” page on your web site? Maybe all of these things make up your product, and you have to decide on what to localize. It has to be a business decision, but it can be a root cause of annoying dependencies and problems. When making your decision, you have to take into account how many copies you plan to sell, what’s the target audience of your application (for example, applications written to professionals do not have to be localized, because you can assume they have an appropriate level of English knowledge), costs, legal requirements (for example, a product cannot be sold without a manual written in the official language spoken in the given country), deadlines etc.

Let’s suppose, the decision is made, you want to localize the application itself, the help files and the accompanying documentation. This is not obvious, sometimes the software itself remains in English, but the manual has to be localized. This can be the case when you have an application which tightly integrates with some embedded operating system, uses its messages, but the operating system isn’t localized. Or, you can localize the user guide, but not the administration guide written to the operators. Finally, in some cases, you can find localized applications without localized documentation.

There is a further marketing-related question: do you want to localize the product name itself? In most, but not all cases, the name remains in English, but sometimes a part of it is localized. For example, if it’s called ABCD Phone Manager, the “Phone Manager” part can be localized.

Tools

The localization work itself is done with software tools, that’s why the process is often called CAT, Computer Aided Translation. Many tools exist, their developers have a different point of view and as such, their applications have different features. Some of them target software developers, and treat translators as a “must have” resource. These applications are nice tools for the developers, because they require little conversion and editing work, but in some extent, are difficult to work with as a translator. On the other end of the scale you find tools made for general translation work. They are easier to use for the translator, but are unable to handle formats used by developers. This gap is often narrowed by integration between tools; an obvious example to this is using the spell checker of Microsoft Word, which is available in many languages.

Most of the tools have more than one version; for example, one for developers, one for localization teams and one for freelancer translators working alone. The latter one is often free, that’s why usually only the version made for developers can be used to create new translation projects. The model is simple, you choose and buy the appropriate tool for you, you send the project file to the translator, he/she can download the translator’s tool for free and can make the work. This way, you don’t have to force the translator to make an investment in another tool, only to work with you – and spend all his/her income to buy something which will be never used to work for another client.

The basic functions provided by CAT tools to the translators are the following:

  • Text editing. That’s evident, the tool has to display the original text and has to provide some space the type in the translation. It is good to have some spell checking functionality.
  • Translation memory. It is a database, which stores original-translation pairs. It can be used to search for previously translated and repetitive sentences or parts of sentences.
  • Dictionary or terminology database. It can be used to store simple original-translation pairs of words or expressions.

Let’s see some examples. IBM Translation Manager (TM/2) is a very old tool. Previously, it was sold as a CAT product. Currently it is used as an internal tool for IBM.

IBM TM. Source of picture: www.vegadata.cz

IBM TM. Source of picture: http://www.vegadata.cz. Notice the dictionary at the lower third of the window.

Trados is an old player too. Its most important feature (to me…) is that it integrates with Microsoft Word, so the translator can use all the editing and spell checking features of Word while doing his/her work. Its developer was recently bought by another player of the CAT market, SDL.

Passolo, also owned by SDL, is a tool with more focus on the needs of software developers.

Passolo. Source of picture: www.multilingual.com

Passolo. Source of picture: http://www.multilingual.com. Notice how small the input field is, but on the left side, the translator gets the list of similar sentences.

Alchemy Catalyst is similar to Passolo, from the translators view.

Microsoft has some tools too, like Helium and Localization Studio, with many developer-minded functions.

If we want to draw a “Specialized tools, made for developers, difficult to use” – “General tools, made for translators, easy to use” axis, maybe Trados is on the right side, and the others in some or more extent, on the other side. Thanks to the recent buyings, integration efforts and developments, they are sliding to the right side in terms of usability.

Of course, you can find many other tools. It isn’t difficult to write an application with basic functionality, like having a field to type the translation in. The real art of CAT tool making begins with providing various filters for formats like .doc, .pdf, supporting the formats used by development tools, integrating with other applications and spell checkers, importing and exporting translation memories of other CAT software etc.

When deciding to localize your software product, you have to choose which tool to buy and use. Of course, there’s no one fits for all solutions, so you may choose two tools: a developer-friendly to localize the user interface’s strings and a translator-friendly to translate the documentation. Due to the integrations, they may use the same translation memory, which makes everyone’s work easier.

Input to the translator

Suppose you have the right tools, and you have to assemble the project you will send to the translator. As your software product is made up of the application itself and all the documentation, the project will also have at least two parts.

Look at your application. It displays a lot of strings: it has a window title, menu names, error messages, popup messages, dialog boxes, option buttons, links and so on. This is the first part. The other part of the project is the help file and the documentation.

You can differentiate these parts by the length of the strings found within: user interface elements are often made up of a single word or a few words. Error messages, links and some explanatory texts are whole sentences, at most. However, the documentation has sentences which are parts of a continuous text. This distinction is important, because shorter parts have to be treated in a different manner than continuous text. The latter is easy to understand to the translator, because it contains the context in itself; the former ones are difficult to work with, because they don’t have a context, and in many cases, it is difficult or impossible to figure out what these sentences are talking about. These two parts require a very different working style.

Why? Because all the CAT tools work with segments. A segment is a translation unit. When working with continuous text, a segment can be a sentence, a title, a member of an enumeration etc. When working with user interface terms, a segment is a menu name, a window title, a message – simply anything displayed on the interface. Due to the nature of things, when translating a continuous text, the translator can see the previous (already translated) and the next sentence (segment). But when localizing user interface elements, he/she works with separate units, which, in many cases, are not related to each other, or simply aren’t following each other on the list of terms to translate.

Again: What to localize?

So far, the localization work itself seems to be simple, you need a translator, or a translation office which has translators as employees or subcontractors, you send them your localization project, and you get the localized one. Development tools support this process, you can use them to export the appropriate strings, and you can import the translated ones. If strings aren’t built into the executables, but attached as XML files, then your work is much simpler; you’ll have general binaries and separate language files. Whichever method you use, you’ll send and receive strings, no problem.

However, remember, you need a product which talks to the end user on his/her own language. Do you really need to send out every exotic error message, used only during testing, seen only by developers, for translation? Do comments made by developers, function names, module names etc. need to be translated? Do comments made by Jane, the reviewer of the manual, inserted in your Word document with a style “comment”, have to be localized? The answer is clearly no. First, they cause disturbances during the translation process, second, you’ll pay for useless work. Third, sometimes you’ll give out internal information that would be kept inside your organization. Of course, if you want to begin localization work before releasing the final product, you can’t avoid sending out some beta materials, but in every case you have to check what you hand out to some foreign people.

Summary

At this stage you know what’s your aim with your localization project, you have some imagination of the translator’s work and chosen the appropriate CAT tool. Next time I’ll talk about the terminology database and keeping consistency during your localization project.

Advertisements