Velior's Corporate Blog about Translation and Translation Industry

This post expands on my older entry about the role of proofreading and the importance of having it done by a qualified person, ideally your original translator. Now, I would like to follow up on, and reinforce, the idea that using someone who is not qualified to do proofreading or dropping it altogether can result in problems ranging from slightly reduced quality to simply unusable content.

Blunders + Proofreading = Happy Ending

With website translations, many clients prefer to copy their website content into a text file, have it translated, and then paste it back. This means a manual, error-prone process. Some time ago, we did an English to Russian translation of a pharmaceutical company’s website, and the person who manually pasted our translations to the site made a major error. One of the pages had a table with the drug names in the left column and their descriptions in the right column. In one of the rows, the specialist erroneously replaced a drug name with its description, leaving the next (description) cell empty. Instead of two cells, the resulting row had just one cell, and, to make things worse, this cell was also invalid. Luckily, the client did request proofreading, which made it possible to find and correct the blunder.

Website that Could Use Some Proofreading

The second example is also a recent website project—German to Russian translation for an equipment manufacturer. Here, no proofreading was ordered at all. Some time after delivery, I checked this website, since I wanted to showcase our work to a prospect from the same industry. What I saw, however, made me completely abandon the idea of showing it to anyone:

Untranslated English section names: “Home” and “Shop.” While these English words might look okay in the original German version, they look plain weird on the Russian pages. Perhaps, the translation was pasted and/or proofread by a native German speaker who assumed that because leaving “Home” and “Shop” untranslated is alright in German, this should be equally acceptable in any other language.

Russian word order replaced by German word order. This was probably triggered by similar thinking (okay in German, should be okay elsewhere). In fact, it was again incorrect, resulting in phrases such as “XYZ-cuttng tool.” First, the manufacturer’s name (XYZ) cannot be placed in front of the product name with a hyphen like this. Second, “XYZ” connects with a hyphen to the adjective instead of the main noun, which is grammatically incorrect.

Em dashes were globally replaced either by question marks (probably, damaged during pasting) or hyphens (perhaps, the person who did the pasting noticed some of those question marks and replaced them by what was in the source text). Now, using a hyphen instead of an em dash is not very good in Russian, but will likely go unnoticed with most readers. However, a question mark in the middle of a sentence is clearly inappropriate.

A few paragraphs were assembled from the sentences that we originally translated as standalone pieces, without any full stops. What resulted was paragraphs consisting of just one very long sentence.

These examples illustrate what might happen when a linguistic decision is made by someone who doesn’t know the target language, and the result of this decision never gets checked. Based on this kind of experiences, I am an avid advocate of proofreading the final content, whether it’s files, software, or websites. As it usually takes little time and just a small fraction of your project budget, it’s really cheaper to do it and be safe than deal with potential consequences. An attempt to save on this step may backfire in much greater loss of business when your prospects are turned away by blunders.

This post offers instructions on basic OmegaT setup. Although OmegaT comes ready-to-use, its out-of-the-box functionality can be improved significantly by taking just a few simple steps. This post is intended as a one-stop explanation of these steps so that any user can start benefiting from the extended functionality quickly instead of taking the hard way of trial and error. As the instructions are very basic, I also provide links to more detailed descriptions. The post is intended for those translators who want to evaluate OmegaT or reviewers who need to connect to an existing OmegaT-based translation workflow used by a translation company.

1. You need to start by downloading OmegaT from the SourceForge. It is important to download the latest beta version available in the Files > Latest section. I don’t think it makes sense to use the older stable version, because it’s obsolete. The beta version also seems safe to use. Choose the version appropriate to your operating system, normally without Java (unless you don’t have Java installed on your system). Under Windows, you will need to install and run OmegaT as you do with any other software. Under Linux, you need to unpack the downloaded archive and run OmegaT shell script.
2. The next step is to enable spell checking. You can do this by going to Options > Spell Checking. Enable Automatically check the spelling of text option. Create a dictionary file folder and browse to it in this window. Then, click Install to install the dictionaries for your target languages. Unlike many other translation environment tools, OmegaT will now check spelling as you translate, making it easier to write correctly from the start instead of having to return and correct errors.
3. Now, add the Language Tool, which is a style and grammar checker. Go to OmegaT plugin page at the SourceForge. Select the Language Tool and download the latest version. Since the Language Tool is a platform-independent plugin, you can use the same version both under Windows and Linux. Create “plugins” subfolder in OmegaT installation folder and unpack the downloaded archive into this subfolder. Restart OmegaT, go to Options and make sure Language Checker option is enabled. The Language Tool suggestions will be underlined in blue as you translate. A detailed instruction is available in the Readme file that comes with this plugin.
4. The next step is to follow a similar procedure to install the tokenizer plugin. It provides better fuzzy and glossary matches by finding other forms of a given word such as a plural form. You can download it from the same OmegaT plugin page at the SourceForge as mentioned above. After unpacking, again, place all files to “plugins” subfolder in OmegaT installation folder. If any files already exist, just overwrite them. Now, running OmegaT with the tokenizer enabled requires creating and editing a launch script, but it’s nothing difficult really. You need to create a separate launch script per source language. For instance, if your specialty is English to Russian translation and German to Russian translation, you need an English script and a German script. To proceed with the below instruction, you will likely need to read this HowTo page, which provides all necessary details.

java -jar OmegaT.jar %* –Itokenizer=org.omegat.plugins.tokenizer.SnowballEnglishTokenizer

…OmegaT.jar” $* –Itokenizer=org.omegat.plugins.tokenizer.SnowballEnglishTokenizer

Now that you have extended the basic OmegaT functionality, you can use it more efficiently. If you have any questions about these instructions or other OmegaT-related questions, please feel free to ask them in the comments. Velior will be happy to help.

I am sometimes asked about how Velior manages to maintain translation rates above the industry average in the highly competitive English to Russian language combination. I think the key to this is quality. You might say, “Wait a minute, you’ve just mentioned high competition, shouldn’t that drive quality across this combination?” You are right, of course, it should, but, judging by the translations I get to edit, it basically doesn’t. For this reason, a translator who puts quality first has a better chance of outdistancing competitors. So, which specific steps can you take to achieve this? From my experience as an editor who looked at several million translated words over the last five years, I can think of at least three main development areas for you to focus on:

1. Literal translation. Because English and Russian are extremely different, very few texts actually allow literal translation. In most cases, a literal translation is hard to read, unclear, and often ridiculous. Nevertheless, this kind of translation is commonplace in our combination. I hear two main explanations of why this happens, which both seem quite amusing to me. First, a translator often knows that the translation is poor, but just won’t do anything about it due to the lack of motivation, time, or skill. Second, many translators simply think this kind of translation will do, because they’ve always delivered this level of quality and got little or no feedback. Make it your job to never resort to literal translation, and you are on the fast lane on the road to success in your translation career!
2. Poor understanding of the source text. I strongly believe that understanding of the source text has a major impact on quality, but you might be surprised about how many translators think otherwise. It is not at all uncommon for people to translate without a clue as to what they are translating about. The bad news is that machine translation is evolving. One advantage of a human translator over MT is the ability to add value through better understanding of the text. Think about this: without this advantage, your translation becomes similar to MT output. As MT continues to evolve, human translators must invest more effort in understanding the text or be prepared to be put out of business. Change your direction today: instead of producing one vague translation after another, give more thought to what you write and look everything up on the Internet. Resolve to understand as much of the text as possible before committing it to your target segment.
3. Failure to use quality assurance tools. Although numerous tools, including free ApSIC Xbench and CheckMate, are available, many translations are delivered unchecked. In fact, one of our agency clients got so fed up with the errors, which can be easily detected automatically, that they put a special policy in place to discourage this kind of errors. This software became an integral part of our translation workflow long ago, since it improves quality and saves time otherwise spent on manual checks. Because I am so used to it now, I find it increasingly difficult to understand someone who doesn’t use translation environment tools on all or some of their projects. When I hear about this, my first thought is, “But this way you don’t get a bilingual text and can’t do automatic QA!” One of the best things about such tools is their simplicity—you can add them to your process easily and start benefiting from them almost immediately.

The actual process of evaluation against the metrics suggested in the 1st part of this post has its own challenges. One challenge is that an editor may incorrectly assume something to be wrong, particularly because normally the editor doesn’t have the same level of understanding of the source text as an original translator. To ensure no “false positives” are corrected during editing, it is important to get the original translator confirm potential errors and preferential changes.

Easy In-house Communication

Within Velior’s workflow that revolves around in-house translation, the editor simply sits down with the translator to go through suggested changes. The translator can challenge any suggestion and explain decisions behind the original translation. Although this process is much more time-consuming than simply letting the editor go ahead and edit the translation freely, we find it worth the cost, because we see a tangible payoff in quality and employee development. The organized effort of two people helps improve translation and reduce the risk of similar errors in the future.

Communication with Freelancers Requires More Effort

With freelance translators, this process can’t be applied easily for obvious reasons. In my experience, what usually happens is that a freelance translator is kept in the dark about the editor’s changes. For instance, read this post in the Medical Translation Insight blog by ForeignExchange Translations. This is the rule rather than the exception in our profession, which is quite understandable—communicating errors takes energy and resources, while offering little direct benefits to a translation agency.

Those agencies that do confirm the editor’s changes with the original translator typically have the editor compile a list of changes, ideally with explanations, and send this list to the translator for approval. The downside of this process is that it’s quite formal, and the translator often makes it their job to reject as many changes as possible, because their reputation with the agency is at stake (“Will they trust me with another job after seeing that this one was edited heavily?”). Unlike informal in-house dialogue, email-based communication also makes it more difficult for the freelance translator to explain why a specific translation was preferred over another. Devoid of human touch, a straightforward list of errors is likely to arouse resentment and defensiveness (“I did a perfect job, and they just mangled it!”). Compare this with a face-to-face conversation: when the translator actually hears suggestions directly from the editor who invites feedback and disagreement, the translator is in a better position to take criticism more positively, which results in adding value to the translation and learning from the errors.

Do you consider it important to communicate and confirm changes with an original translator? Is such communication worth the effort? What is the best way to confirm changes with a freelance translator?