We charge for translation mainly per the number of source words. This means that for each source word—whether it’s something as long and seemingly difficult as “pregelinatined” or as short as the article “a”—a client pays the same rate. Charging a single rate might appear controversial to some clients, resulting in a sticker shock: “Why would I pay the same rate for those words that require little or no work?” At first glance, such pricing does seem to make little sense. For instance, with English to Russian translations, you don’t translate the articles “a” and “the,” but simply omit them. Here is a possible explanation of why this pricing method is generally accepted as fair:

Besides those simple words, almost any translation job involves more challenging words that, in contrast, require effort beyond the standard rate. Examples include:

1. Words that don’t exist or have no commonly accepted counterpart in the target language, e.g. “matrix team” in Russian.
2. Words that are extremely difficult to translate because they don’t have an identical equivalent in the target language. One of my favorite examples is the word “leadership” which is now often used instead of “management.” The literal Russian translation “лидерство” doesn’t carry any meaning of “management” at all. The closest match is probably “руководство,” but it doesn’t fully convey the meaning of “being a leader”. For more information about this kind of translation challenges, I invite you to read this post.
3. Unclear or incorrect wordings which appear to say one thing, while the author actually had in mind something completely different. I don’t think any example is necessary in this category because misunderstanding is so common in all aspects of life. Just ask yourself: do I get my message across to others correctly 100% of the time?

To illustrate, let’s make a simplified calculation based on the assumption that you translate on average 300 words per hour. This means approximately 5 words per minute or 1 word in 12 seconds. At the rate of $0.1 per word, you make 300 x $0.1 = $30 per hour. And it’s natural that you want to make $30 for each hour spent on translating.

Now, imagine yourself working on a text so challenging that you occasionally have to spend 5 or 10 minutes on a single word instead of 12 seconds. Gradually, you are falling behind your expected productivity level. If you continue to get many challenging words downstream, there is no way you can achieve your average amount of 300 words per hour. You might end up making $20, $10, or even $1 per hour instead.

This is when simpler words come to improve your performance. While spending too much time on the challenging words, you also have a certain amount of articles, prepositions, and similar words that you can translate much, much faster. With these words, you don’t need 12 seconds per word, but rather just one second or less. By spending less time on simpler words, you can make up for the time you lose on the more difficult ones. So, one possible rationale for charging the same rate for the “little effort” words is to assume it’s a form of compensation for the more difficult bits of the text.

This is part 2 of this post. For part 1, please follow this link.

1. There are two types of inconsistency. The first type is inconsistency at the term level. To avoid errors of this kind, we use tools such as glossaries and QA Distiller to automatically check for any discrepancies. A client’s editor doesn’t always recognize the importance of consistency and doesn’t have the proper tools to maintain it. The second type is inconsistency at the sentence level. The translation environment tools we routinely use in our work provide specific functions that make it extremely simple to avoid any discrepancies of this kind. This means that a similar sentence is unlikely to be translated differently within a project. A client’s editor, by contrast, typically works in Microsoft Word, which isn’t designed to provide such functions. Imagine that you spent your morning editing half of a translation project, then switched to some other tasks during the day, and finally returned to the project in the evening. When you come across a sentence that is an exact match of, or very similar to, a sentence you edited in the morning, chances are that you won’t remember your previous edits accurately and make a different edit or no edit at all. These small inconsistencies may add up in the long run, making the translation misleading.
2. Because a client’s editor often uses Microsoft Word for “surprise” review, the project’s translation memory doesn’t get updated. This is exactly what happened to us last week. What this means is that for future translations, folks will use outdated TM, resulting in inconsistency, lower translators’ performance, and yes, misleading translations.
3. The “surprise” review means that a client’s editor did not provide the changes for revision to the original translator. This is always a risk, since the translator is usually able to point out any incorrect changes, including the above-mentioned types of errors. By doing review in a “surprise” fashion, you miss the chance to make sure the translation is flawless and also educate your translator. You might end up with the translation that contains multiple errors and the translation vendor who is unaware of your changes and will stick to the old translations in any future work for you. This cycle will repeat itself until you let the vendor know about your edits.

To conclude, we highly recommend avoiding “surprise” review and using the normal review process instead. All it takes is just one simple step: send your edits to your translator. A professional translator will then take care of the rest: check your edits, fix any errors or inconsistencies, update the TM, and learn from your edits for better translations in the future. Good luck!

Last week, one of our clients contacted us with an update of a manual we had previously translated from English into Russian. The client made changes to the source text and now wanted us to make the same changes in the Russian version by updating the old translations and adding the new ones directly in the manual (Microsoft Word format). While this is not our preferred approach to updates, it’s totally fine with us, because it helps clients to avoid DTP costs (such costs are typical of the industry-standard approach, which is to translate the entire new version using the translation memory from the previous version). We extracted all modified and new sentences and translated them using the old TM. We then proceeded to insert them in the previous version. At this point, much to our surprise, we discovered that our translation had been edited by someone else. For consistency reasons, we now had to examine the “surprise” edits and then adjust our new translations accordingly.

Such “surprise” review also happened to us a few times before, so I decided to put together a blog post about it based on this example. I will focus mainly on the downsides. Please don’t get me wrong, I love clients’ reviews and believe they are mostly beneficial. The “surprise” review is beneficial too, but it may also create unnecessary problems. And in this case, avoiding the problem is definitely easier than struggling with its aftermath.

1. While a person doing the review, whether a client’s employee or their local distributor, is normally qualified to do the job from the subject matter expertise perspective, this person may not be an expert translation-wise and introduce a variety of errors into the translation. For example, as a translation company, spell checking and automatic quality assurance on each translation are in our DNA. In contrast, a client’s editor may not even be aware of these tools, let alone use them routinely.
2. A very common type of error associated with surprise review is inconsistency. This is a serious problem that can result in misleading translations. Imagine an end user scratching their head over a manual that randomly uses three different names for the same procedure. Inconsistency will also confuse folks who will provide future translations to this client, because they will normally want to keep the new translation consistent with the old material. But how can they do it with the old stuff inconsistent in the first place?

This post is continued in part 2.

OmegaT provides an incredibly powerful capability to filter segments in the editor pane. A similar function is available in other translation environment tools as well, e.g. Wordfast allows you to select just 100% matches or fuzzy matches for easy navigation. OmegaT, however, takes this functionality to a whole new level. This post describes some of its applications.

The basic idea of using a filter is to save time by limiting your scope of work to only those segments that require attention, while also making navigation between them instantaneous. To apply a filter, you need to open the Text Search window (Ctrl+F), perform a search to find all segments you need, and then click Filter in the lower right corner. The OmegaT editor pane will now display and make available for editing only those segments. To disable the filter, perform any other search, click Filter, and then Remove Filter.

1. Perhaps, the greatest benefit our translation company derived from using this feature is the ability to remove unpaid 100% matches from the scope of work. This ability is essential when a client wants to insert 100% matches in the current translation automatically and without any review, thus avoiding the costs associated with reviewing them. It makes sense then to exclude such 100% matches from the workflow to a reasonable extent. While translating, you can simply skip 100% matches by going to the next untranslated segment each time (Ctrl+U). For the editing step, however, this shortcut obviously doesn’t work. This is when a filter comes in handy. All you need to do is come up with the appropriate search criteria that will find only the segments changed in the course of translation. An example of such criteria is searching for all TM entries committed under a specific translator’s name. After finding them and applying the filter, you will be able to focus exclusively on the required segments.
2. You often need to make global changes, e.g. to ensure a term is translated consistently. The straightforward way is to find the segments containing this term through the Text Search window and then start clicking the segments one by one to open and modify them in the editor. Clearly, the more occurrences of this term you have, the less efficient this navigation procedure gets. In such cases, we sometimes prefer to open the project’s TM in a text editor such as Notepad++ and make changes there in order to do it faster. The filter feature reduces the need for this type of workaround by allowing you to display only those segments that require changes and move through them with speed.
3. To process TTX files that include already translated Context TM (Perfect Match, XU) segments, we use the great Toxic utility to convert the files to the format supported by OmegaT. The downside of this process is that OmegaT incorrectly provides the target text of such Context TM segments for translation as if it were the source text (due to Toxic’s method of conversion). Just as with the unpaid 100% matches, these segments can slow you down. To increase efficiency, you can use the filter feature to exclude them from the scope of work.
4. Recently, I mentioned that OmegaT now provides the note feature. The filter function can help optimize this feature as well. After finding all segments with notes in the Text Search window, you can apply a filter to display these segments and move through them directly in the editor pane, rather than do this by clicking each segment in the Text Search window and switching back to the editor. Again, the more segments with notes you have, the more efficiency a filter will bring.

Creating and maintaining a glossary for a specific client is a best practice in the translation industry. A glossary contains client’s terminology, making it easier to access approved translations and ensure consistency across this client’s projects. There are, however, a few common pitfalls that can render glossaries difficult to use or misleading. This post provides a few suggestions about how you can avoid such pitfalls to get the most out of your glossaries.

Challenge: Many glossaries are created before the actual translation starts, by extracting and translating a list of frequent terms. This supposedly helps translators to access correct terms easily and avoid discrepancy in the course of the project. While the idea of creating a glossary in advance is undoubtedly reasonable, its actual implementation can be far from perfect. The terms in such list are translated out of context, which inevitably results in a significant percentage of too general translations or even mistranslations. The resulting glossary becomes misleading and can either cause errors in future translations or, in case of a client-approved glossary, create delays in the project schedule, because the translation team will need to compile a list of suggested corrections and wait for the client to approve them.

Solution: I recommend to create your glossary along the way, so that it contains correct translations based on understanding rather than translator’s guesses.

Challenge: Glossaries tend to contain words that are completely irrelevant to their purpose. These can be verbs, names of countries, general nouns, etc. Instead of helping translators, they are downright misleading. Each time a general verb or noun requires a translation different from the one provided in the glossary (and this happens extremely often!), a translator becomes confused, wondering whether it is okay to use a better translation instead of the glossary item that would make little sense in the current context. The more irrelevant words a glossary contains, the less usable it is.

Solution: It is best to have a glossary that is focused on real terms specific to this end client and avoid general words.

Challenge: It is not uncommon to regard a glossary as an “ultimate authoritative source” and comply with it blindly, irregardless of what common sense might be telling you. For example, a translator following this principle may intentionally use a glossary translation, even if it doesn’t fit the current context or is obviously incorrect. An editor who spots a different translation may rush to overwrite it without considering possible reasons behind such deviation from the glossary. Also, the same way of thinking may prevent the end client from allowing changes to the glossary.

Solution: It pays to be flexible about your glossary. A glossary is not always an ultimate authoritative source. We have been maintaining and meticulously improving some of our English to Russian translation glossaries for years, and they still don’t fit all contexts! Written communications are unique and create so many different contexts that it’s impossible and impractical to have all imaginable translations in a single glossary.

Although dozens of both free and commercial translation environment tools (TEnTs) are available on the market, translation buyers, including translation agencies and direct clients, sometimes choose to develop and use their own tools. In this scenario, particularly typical for larger companies, a client asks a translation vendor to use their company’s tool instead of whatever tool that vendor prefers. One widely known example is Translation Workspace used by the translation agency Lionbridge. We worked with quite a few tools of this kind over the years, and I would like to share some of our experiences with them.

Benefits

1. Perhaps, the biggest benefit derived from using such tools is that they make things easier for a client through better integration of the translation process with the client’s content management system. The client is able to seamlessly integrate their translation vendor into the content production process, which increases productivity and makes the client less dependent on any specific translation vendor.
2. Many tools of this kind are web-based, thus having various advantages provided by this valuable technology. A web-based system is typically very intuitive and has little or no prerequisites: all you need to start translating is a web-browser and your login credentials. It also simplifies management and communication by making file exchange over email irrelevant—the text to translate, translation memory, and glossary are all inside the tool.

Challenges

1. From the translation vendor’s perspective, working in the client’s tool makes it impossible to fully utilize the strengths of their standard workflow. For example, while working in a client’s web-based system, we often can’t employ our quality assurance tool or have translator check and approve editor’s changes.
2. Whenever any technical issue arises in the course of translation, the only way for the vendor to resolve it is to contact the client for help. This may take more time as compared to using third-party tools. For instance, we have extensive experience with the tools we use on a daily basis and can therefore resolve any issues immediately and without involving the client.
3. Some of the client’s tools might be less productive than the latest translation environment tools such as OmegaT. One reason is that the clients don’t find it necessary to improve their tools as actively as developers of TEnTs do. A client may have developed their tool years ago and now has little motivation to improve it, because it already provides the basic functionality and the company’s employees are comfortable with it as it is.

In summary, client’s translation environment tools can be a very easy and time-saving way to provide translation for both clients and translation vendors. We are normally happy to provide English to Russian translation in such TEnTs, unless they make our quality assurance process completely impossible.

A few months ago, I tested Ubuntu 10.10 to see whether the savings generated by using this free operating system for translation purposes instead of Microsoft Windows is worthwhile. Over a period of six months, I used Ubuntu to handle dozens of translation projects. This post outlines some of my findings:

The good news is that you can definitely use Ubuntu for translation. In fact, this OS leaves a much better impression than I originally expected. Ubuntu supports at least three translation environment tools: OmegaT (also free), Wordfast Pro, and Swordfish. It also provides most of the tools essential to running a translation business: OpenOffice.org (a viable alternative to Microsoft Office), Adobe Reader, web-browser, email client, instant messaging (including Skype), and many more.

What’s the catch then?

Because Ubuntu is not as popular and user-friendly as Windows, it doesn’t offer a similarly high level of user experience. The three most serious issues I encountered are as follows:

1. Getting all your programs to work properly might take quite some time and require knowledge beyond basic PC user skills. If you want to deploy Ubuntu in a translation agency environment, you will also need to invest significant time in basic user training.
2. While many programs a translator might need do have Ubuntu versions or Ubuntu provides alternative programs, there is a good chance that at least some of your favorite programs won’t be available under this OS. For me, this list included:

• Abbyy Lingvo (dictionary)

• Abbyy FineReader (OCR tool)

• Punto Switcher (automatically switches keyboard layout and quickly enters phrases that I use frequently)

• Foxit Reader (there was an Ubuntu version at the time of testing, but it didn’t allow editing PDF files as the Windows version does)

• QA Distiller (quality assurance tool)

3. Another major roadblock to using Ubuntu for translation purposes is compatibility issues. Instead of Microsoft Office, which is used by most companies and individuals, you will have to use OpenOffice.org. Although OOO is a great program and in fact supports Office files without any conversion, I found that this support is in name only. The program can indeed handle small and plain Office files successfully. With larger and more complex files, however, a roundtrip (Office – OOO — Office) often results in corrupted formatting. This means that if you often translate DOCX or PPTX files, you will likely end up using Office to check and adjust formatting after translation, because OOO won’t be able to produce a file that will display correctly in Office. Thus, handling such files will be very difficult, unless you have a separate Windows machine with Microsoft Office installed.

Based on this testing experience, I came to the conclusion that using Ubuntu for translation purposes instead of Windows is certainly possible, but may not be worthwhile. The main reason to use a free, but less popular OS is to save on license costs. This economy, however, is heavily offset by the significant amount of time and effort you will need to invest in getting the programs to work properly and dealing with compatibility issues. Although Ubuntu is a great operating system, I just don’t think it has any economic advantage over Windows for translators.

This post is designed to review some of the changes implemented in the latest version of OmegaT, 2.5.0, released this week. The new version introduced quite many new features. This time, however, I will focus on only those that we are already using for English to Russian translation on a daily basis.

1. OmegaT now supports multiple translations of identical segments (internal repetitions). Previously, whenever a repetition needed a translation different from the one used elsewhere in the project, we would insert a special mark in this segment. After creating the translated documents, we would search for the mark and adjust the translation as required. Hardly effective, this approach is now history. Whenever you want to use a different translation for an internal repetition, you can do this right away within the program by selecting the Create Alternative Translation command in the context menu available in the editor pane.
2. You can now add notes to segments. Previously, we would add a special mark and insert a note directly inside a segment. Now, it is possible to enter or edit a note for any segment in a dedicated pane. When you re-open a segment that includes a note, this note will appear in the pane. To find all segments with notes, press Ctrl+F to open the search window, deselect all options except In notes, and perform search with an empty string. Needless to say, this is a very useful and long-awaited feature, especially for a translation agency environment like ours where a translator and an editor use notes to communicate with each other regarding their choices and questions.
3. Another improvement is the ability to have project-specific file filters and segmentation rules. Prior to this version, you could only use one common set of filters and segmentation rules for all your projects, which was stored locally on your PC. In our case, this resulted in a problem each time a translator added a new segmentation rule to improve incorrect segmentation. Because the new rule was saved locally on this translator’s PC, opening this project on another PC, e.g. for editing, resulted in a different segmentation. Each time an editor had to either add the same rule manually or ask the translator to provide the segmentation rule file stored locally on this translator’s PC. Now, when adding a rule, you can make it project-specific by pressing Ctrl+E, selecting Segmentation and then Project-specific segmentation rules. The segmentation rule file will be saved to the omegat folder of this project. Whoever opens this project thereafter will get exactly the same segmentation based on the rules in this file. A further benefit of this improvement is that you can avoid automatic application of any rules set up in an older project to all new projects. Previously, all rules you once set up, however specific they might have been, continued to apply to all future projects, often ruining segmentation.
4. The last new feature I want to cover today is the improvement to the process of detecting changes in the external translation memories. Prior to 2.5.0, if you made any changes to, or added, any TMXs in the tm folder of your project, you needed to reload the project to be able to see the changes. This was particularly time-consuming with multiple large TMXs. Now, the program automatically detects any changes or additions in the tm folder. One benefit we’ve already derived from this improvement is an optimized process of sharing TMs between two or more translators working on the same project simultaneously. Previously, whenever one translator placed their current TM to the tm folder, they had to ask a colleague to reload the project to be able to see the latest translations added by that translator to the TM. Now, you simply place the TM to the tm folder, and the other translator sees it immediately without any notification or reloading.

In summary, the new version is a big hit with us. We truly appreciate the continued efforts the OmegaT developers are putting into this highly successful free open-source tool. If you are in need of a high-performance translation environment tool to boost the productivity and quality of your work, I strongly encourage you to try out this new version. For more information about OmegaT, please read other related blog posts. We’ll also continue reviewing the remaining new features in future posts.

Unlike other popular translation environment tools, OmegaT doesn’t provide a full spectrum of built-in quality assurance functions out of the box. Automated quality assurance is, however, paramount to high performance in our line of work, so translators or translation agencies working in OmegaT will need to use mainly external solutions. This post is intended to briefly discuss the most essential QA tools available to OmegaT users.

Spelling and Grammar Checker

OmegaT makes it possible to check spelling and various style or grammar errors from within the program. For information on how to enable these types of checks, please refer to our previous post. These checks are performed as you go through the file, by highlighting potential errors. But you can’t perform them on the entire file as you can, say, in Microsoft Word or Wordfast. If you wish to do so (and you normally do, because it’s way too easy to miss an error if you simply look through your file for highlighted errors, rather than focus on these errors by running a specific type of check), you can use external QA tools mentioned below.

Tag Checker

OmegaT provides a built-in tag checker. All you need to do is run it by pressing Ctrl+T. This is a very important step in your QA process, since OmegaT doesn’t protect tags. The risk of deleting a tag partially or completely and missing it during editing is therefore very high, so it is imperative to run this checker on each project that involves tagged text.

Quality Assurance Checker

There are at least three reliable tools that you can use to check for errors such as inconsistent translations, untranslated segments, numbers, glossary entries, and many more: QA Distiller, ApSIC Xbench, and CheckMate. The latter two are available for free. While we use mainly QA Distiller, the free ApSIC Xbench and CheckMate provide basically the same functionality.

Whichever program you choose, you start by loading a TMX file. This file is either the “project_save.tmx” that includes all translations committed to the translation memory in your current project or one of the TMX files created whenever you save target documents in OmegaT. After loading such TMX file, you can process it in the QA tool just as any other bilingual file. If you find any errors during QA, you can return to your OmegaT project, use the search feature to find the respective segment, and then make the correction. QA Distiller has a built-in TMX editor, which makes it possible to conveniently edit the loaded file from within this program, i.e. without returning to OmegaT. By using this feature, you can close the project in OmegaT, load the “project_save.tmx” in QA Distiller, process it, and then make changes directly to the “project_save.tmx” by clicking an error and using the editor to change the translation. When you reopen the project after finishing QA, you will see updated translations.

Summing it up, you can easily use various external tools to perform QA on OmegaT projects. Our experience of using OmegaT for English to Russian translations on a day-to-day basis shows that the quality of QA performed within these projects is just as high as with other translation environment tools that provide built-in capabilities. If you have any questions on the subject, our translation company will be happy to assist.

This post continues the series of tips on using OmegaT as a professional tool for English to Russian translation or other language combinations for that matter. Today’s focus is on the translation memory (TM) feature.

We store all translation memories in a centralized manner on a file server, which makes it easier to maintain and access the TMs. This is quite crucial in a translation company environment like ours where ongoing projects from the same end clients account for a significant portion of business. By default, OmegaT offers a project structure that keeps the “tm” subfolder in the project folder. If you need to access any additional TMs, you put them into this folder (as TMX). What this means is that you have to copy all previous project TMs to this subfolder every time you create a new project for a returning end client. You might find this inefficient, and you also face the risk of losing a few TMs along the way. You can avoid this by storing all TMs for this end client in a centralized location. If you plan to store the TMs on the same PC, this can be any folder on this PC. If you prefer to store them on a network share, you need to connect such share as a network drive (OmegaT doesn’t work well with Windows network paths starting with \\). When you create your next project for this end client, change the default TM path to your centralized location path. Afterwards, you can simply copy the settings file (omegat.project) from this project to each new project. This file will always include the correct path to your centralized location.

When your project includes many 100% matches, you normally want to insert them into your translation automatically. You can’t do this from within OmegaT, because this tool currently allows inserting such matches one by one only. This may decrease your efficiency and also result in committing all these 100% matches to TM under your name, so you won’t be able to distinguish them if you need to do so (e.g. your client doesn’t pay for them and you want to skip them during editing). The workaround is to create a subfolder named “auto” in the TM folder used in this project (either local “tm” subfolder or a centralized location described above) and put the relevant TM there. When you launch the project next time, all 100% matches from this TM will appear in your translation immediately.

Whenever you create the translated files, OmegaT also creates three TMs that include all current translations, providing a few useful abilities. This TM is created in three formats: level 1 (TMX 1.1), level 2 (TMX 1.4), and OmegaT (OmegaT’s native TMX 1.1).

1. The TMX 1.4 provides a certain degree of compatibility between OmegaT and other translation environment tool (TEnT) and is, therefore, ideal when you need to provide your TM to a translation agency client who will use it in a different TEnT such as SDL Trados.

2. You may want to change segmentation or correct errors in the source text. Often, this results in two translations in the project TM, one being current (after the change) and the other being obsolete (before the change). This might be inefficient for at least two reasons: (a) when you put this TM through a spell checker or QA process, these confusing obsolete segments appear in the results; and (b) if you re-use this TM at a later time for the same end client, these obsolete translations may mislead you during translation. In such situations, the native OmegaT TM file comes in handy, because it contains current translations only. You can use it instead of the main TM (project_save.tmx). Also, if you want to remove all obsolete translations from your main TM, you can simply rename this TM file as project_save.tmx and replace the current project_save.tmx in “omegat” subfolder with this clean file.

If you have any questions about these tips, I will be happy to assist. For information about installing and configuring OmegaT, please read this post.