To provide a good translation, you should always understand what you’re translating and adapt your process. In this article, you will see how Palex managers do this every day.

From the first days of its existence, our company has translated texts about information technology — networks, protocols, hypervisors and the like. For many years, we worked with an experienced editor who knew almost everything about network administration. He could easily configure a Linux virtual machine or add a computer to a domain. We had no doubts that he was qualified for the job and his translation was good.

One day, however, we noticed an unhealthy trend: we were consistently failing at least one out of every five customer’s reviews. Moreover, four of every translations we delivered were nearly perfect, but the the reviewer would have to completely rewrite the fifth. At first, we suspected bias on the part of the reviewers. So we went back and checked their work — unfortunately, the reviewers were absolutely right.

We tried using a different editor — that didn’t solve the problem, either. The fail rate remained virtually unchanged.

Ultimately, we realized that the problem didn’t lie with the people involved in the process. These source texts for the translations were very different, even though all of them concerned network administration. Some were user guides whose translation required an expert understanding of network architecture. Others were license agreements consisting of a series of arcane legal expressions — often their relationship to network administration came down to a single use of the word “network” in the document.

This series of failed translations led us to develop a special system of classification. We assign three attributes to every text and use them to determine the right translators for the job. We had this system in place for five years now and it has helped us ensure that translators work only with those texts that they can translate well.

The first question is always: what is the text about? It is crucial here to define the subject area as specifically as possible. For example, definitions like “Medical” or “Legal” are generally too broad for our purposes, while “Cardiology” and “Labor Law” better reflect the essence of the text.

Clearly defined subject areas are the key factor in determining which translators have the necessary areas of expertise. If this isn’t done properly, the translations will contain errors of meaning (especially where there is ambiguity in the source text) and the terminology will fail to meet the expectations of the target audience.

To make this clearer, let us show you our list of subject areas for IT:

The intended use of the text is another important attribute. Once we know what a text is about, the next step is to establish what the text is for and who will be reading it. Even at first glance, texts with nearly identical subject matter can look radically different.

Various circumstances require language experts with completely different skill sets. Someone capable of a top-flight translation of user manuals may have trouble adequately rendering advertising content or legal agreements, even if they are highly familiar with the relevant subject area.

An administrator’s manual is meant to help a network administrator install and setup a hypervisor and then deploy virtual machines as quickly as possible. A promotional brochure, in contrast, is intended for people at the stage of planning to buy a hypervisor. The goal here is to persuade a company’s IT director that this software will help them spend less on infrastructure by deploying multiple instances of an operating system on a single server.

There are various possible approaches to classifying the purpose of a text — we’ve come up with the following system:

There’s another point of view from which we can look at texts: where it will be encountered and in what format. We have a term for this — they are called “containers.” Containers affect the technical requirements for a translation, set limits on the string length, restrict the use of certain characters and symbols, etc. You keep this in mind when choosing a vendor: video content translators may not be as good at software translation, and vice-versa.

Let’s check out some texts again in the same subject area — but now in different forms.

Software strings usually contain placeholders — variables that can be replaced with numbers, words, or even parts of sentences. A translator needs to know where they have to be placed so the text doesn’t end up as gibberish on the screen of the localized build. Software can also contain hot keys — references to keyboard keys for quick access to specific features. These usually take the form of an ampersand (&) followed by a character. Language experts are required to know what these are and how to work with them. If the translator breaks the code in the process of his work, the hot keys won’t run as expected.

On an HTML-page, a translator will encounter tags, sometimes a mass of tags. So the translator needs to know how they are used and be able to distribute them around the right words or phrases. Moreover, some of these tags can also be placeholders — just like in software. It’s important not to skip them, and also to change surrounding text where required.

Video translation is a similarly involved undertaking. The length of subtitles and the speed of narrator speech are always restricted. That means that a translator cannot afford lengthy sentences: brevity is of the essence. This is especially true for language pairs where the target text tends to be substantially longer than the source. It is also crucial here to keep track both of the text and the video. The footage may contain images that greatly affect translation choices.

We use the following set of containers in our work. As with applications, these categories are somewhat approximate, but they serve us well for our practical purposes.

We classify every source text by subject area, application and container. That allows us to determine efficiently which translators are the best fit in each case. Sometimes a single request can involve several translators. For example, software strings may contain extended licensing agreements. This is work for a legal translator, of course, but the rest of text goes to a language expert with an IT background who can handle software translation.

This kind of approach also helps us quickly and clearly define the requirements for a translation, even when the client can’t determine them for us. If the assignment is to translate an educational video, for example, we know immediately that it is crucial to make the text easy to understand and for it to fit within a restricted string length.

We use the same classification for translators and editors. We offer them different types of texts and observe who best handles reference texts and who is better at promotional content or legal agreements. That helps us correctly distribute work assignments among them. As a result, translation is always performed by those vendors who are the best fit for a given project.

This system helps to rationalize our translation quality management. We no longer have to wonder why a client’s reviews give highly different results from time to time. We have a much better understanding of why and where we make mistakes, and that means we can learn from them and improve our service.

Below is a short reference card that will help you to better understand the principles we use for text classification.