Velior's Corporate Blog about Translation and Translation Industry

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.

Despite the rise of content/translation management systems, the share of uneditable source texts in translation supply chains remains significant. One reason is simple unavailability of the original editable versions. An example could be a Soviet Union patent issued back in 1980s that now needs translation from Russian into English. Or a client may want to translate documentation, which was provided by a subcontractor in PDF format several years ago, and now they lost contact with the subcontractor. Because handling such files can be challenging, it is important to consider preparing them for translation before you proceed.

Best Way to Prepare Uneditable Files for Translation

It is our experience that the best approach to uneditable files is to prepare an editable copy through an optical character recognition (OCR) process. This is also a method of choice with many of our peers.

Now, the main dilemma is that clients don’t always agree with the OCR charges. Instead, they would often prefer to have a linguist translate into an empty DOCX file while referring to the original. The willingness to avoid the OCR costs is perfectly reasonable, particularly with small and less significant jobs. But let’s consider some of the reasons why OCR might be a better alternative.

Indirect Benefits of OCR for Clients

1. It is usually easier and faster to translate an editable file than an uneditable one. A translator doesn’t get distracted by low-value formatting tasks, which often consume much time and energy that should be rather spent on high-value translation activities. An editable file eliminates the need to manually re-key numbers, company names, product names, addresses, and so forth. Translating into an empty DOCX file means you need to double-check whether all content was transferred from the source file correctly, while a properly OCRed file makes such check either marginal or completely unnecessary.
2. Editable files make it possible to use a translation environment tool (TEnT). This provides at least two benefits in terms of quality: (a) easier bilingual editing process, especially for an editor, and (b) the ability to use an automatic QA tool.
3. Using a TEnT also provides an efficient backup functionality, with a translation memory storing each translated segment and making disaster recovery easy. We learned this the hard way many years ago after losing a day’s worth of work by accidentally deleting a document which was created by putting translation into an empty file.

These performance improvements have a positive impact on speed and quality of translation, resulting in indirect benefits for clients.

Direct Benefits of OCR for Clients

1. OCR enables advanced analysis of a source file against a translation memory, allowing to detect internal repetitions, which are otherwise unseen. This may result in significant discounts. One project we completed with OCR had as many as 25,000 repetitions (with 10,000 unique words only). Paying full rate for repetitions instead of paying just a fraction of costs for OCR would have been a major waste for our client.
2. One of the common problems associated with uneditable files from the clients’ perspective is the uncertainty about the word count and the estimated time of completion. OCR essentially eliminates this headache, because as soon as an OCRed file is ready, a client can receive an accurate quote. If you are a project manager at a translation agency, you can then use this information to produce a more specific and meaningful quote for your end client. Using OCR can also put you in a particularly great light if your competitors submit vague or too expensive quotes based on guessing, rather than an accurate analysis.
3. It is sometimes necessary to divide an uneditable file between several translators due to time constraints. Letting each translator take care of formatting on their own normally results in an inconsistently formatted final file. Such inconsistent layout may require rework or even go unnoticed and damage your reputation when seen by your clients or prospects.

What are some of your approaches to uneditable files when you buy or provide translation?

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 a great believer in free and open-source software as it lends itself to empowering people with the technology they need to be more efficient. The ability to use a free alternative instead of a commercial product can be of great value to any person or company, especially a small business like ours, which has to run a very lean operation in order to maintain competitive edge. When a major production tool in an industry is available for free, it is arguably a blessing to many people engaged in this industry. One of such tools in the translation industry is OmegaT.

Sometimes Intuition May Be Misleading

I first got my hands on OmegaT in 2009 and I must confess I wasn’t too impressed. I fell victim of what I now know was a snap judgment—the simplistic GUI and the philosophy that didn’t align with my previous experience with other translation environment tools (TEnTs) required a degree of flexibility I couldn’t come up with at that time.

A year later, I revisited OmegaT to actually rediscover it in a way that now makes me feel bad about the previous snap judgment. In this post, I want to share a few general thoughts based on my recent experience. What I mention here is just a tip of the iceberg, and I hope to be blogging more about this tool in the future as Velior continues using it in our translation projects.

How You Can Benefit from OmegaT

1. Packing all essential TEnT features, including project management, translation memories, and glossaries, into a single tool, OmegaT is a full-fledged translation environment software that provides a viable alternative to similar commercial products.
2. For a freelance translator who is just embarking on a journey to a career in this industry and doesn’t have the knowledge and/or money necessary to buy a commercial TEnT, OmegaT gives a strong helping hand. For instance, it might be a good starting point for those English to Russian translators who are building their translation business from the ground up or seeking cost-efficient ways to improve productivity and quality.
3. For an in-house translator, OmegaT gives the freedom of choice, making it possible to continue working on a project at home or using a laptop on the go just as easy as in the office.
4. Although SDL essentially discontinued development and support of the TTX format, it remains among the most common in the industry. This means that you need the commercial SDL Trados package to accept TTX-based projects and may be a potential roadblock limiting your availability to translation agencies. OmegaT, however, eliminates this barrier by allowing you to handle the TTX format, and many others for that matter.
5. Personally, I also enjoy the feeling of the community-based development process that is open to requests concerning bugs and new features. You can watch the software maturing and may even feel a sense of ownership in case you are somehow involved in the process.

What Limitations Need to Be Considered

Just as many other open-source initiatives, OmegaT carries a certain amount of limitations. Similarly, OpenOffice.org is arguably less sophisticated than Microsoft Office, and Ubuntu is less mature than Windows. Probably inherent to free software, such limitations are often minor in the sense that you can live with them if you make up your mind to do so. What matters most is your mindset—if your chief aim is to save wherever possible or you support free software philosophy in general, you are likely to be okay with the limitations, finding and using a temporary walkaround until they are fixed by the developers.

I am not exactly advocating for using OmegaT, because it is just one of the options available on the market, and it has its limitations. My point is that OmegaT is a valuable alternative to commercial products that can be considered by many translators, and I am happy with the freedom of choice it adds to our industry. Hats off to this project’s team for their enthusiasm!

Which free tools do you consider to be of great value in your work? Is OmegaT among them?

In a recent English to Russian translation project, we worked on a file with all internal repetitions extracted (received like this from our client). As this is a relatively uncommon practice, I decided to use this opportunity and explain my thoughts on this subject.

Example of a Repetition

Let’s take a look at this example to illustrate the main challenge associated with extracting the repetitions:

“Note:“ can occur in at least three different situations, and, as plain as it seems, may cause problems:

1. Below a paragraph. The colon is often replaced by a dot. (Примечание. Обратите…)
2. In the middle of a paragraph. I prefer to keep the colon and begin the actual note with a lower-case letter. (… кнопку. Примечание: обратите…)
3. As a subheading. The colon is often deleted. (Примечание)

In this example, the identical source requires three different translations. Imagine what happens when the identical translation “Note.” is used across all three situations instead. For instance, a standalone sentence “Note.” appearing in the middle of a paragraph may look weird. In a subheading, it wouldn’t be that bad, but might still be inconsistent with punctuation in other subheadings, so why let it happen at all?

Does it mean that extracting the repetitions is evil? No, of course not. In some situations, the benefits derived from such extraction may outweigh any potential problems. Consequently, you need to consider applying this approach on a case-by-case basis and exercise caution, making sure you understand the implications.

Pros

1. A significant, if not the main, gain is the possibility of savings. This is especially true when many thousands of repetitions are considered for extraction. The client’s willingness to reduce the costs through extraction is perfectly reasonable in such situations.
2. Extraction might be vital when two or more translators work on the same project simultaneously. Otherwise, they will likely translate repetitions in two or more different ways. This means double work, hence a plain waste of money. An arguably better solution might be to extract the repetitions into a separate file and have it translated by one linguist and then checked by another and/or the editor.
3. Extraction also helps eliminate or at least reduce inconsistent translations of the repetitions. Although many translation environment tools ensure consistency by automatically changing all occurrences when you edit any single repetition (auto-propagation feature), there is always room for human error in this area.

Cons

1. Extracting the repetitions means that you don’t get a final file from your translator. What you get is an intermediate file, which you then need to process to create the final file, e.g. by creating a translation memory and applying it to a source file. Before you go for extraction, you may want to compare these additional management costs against the expected benefits of extraction.
2. As a translator, I prefer to work on a copy that retains its original look, rather than an intermediate “censored” file. With the repetitions extracted, you cannot see the whole picture, which may decrease your understanding of the source text and the sense of ownership. The pain can be somewhat eased if you have the original copy (with all repetitions) at hand for reference. For this reason, I believe that providing such file is a must in most extraction scenarios. Aside from taking the guesswork out of the translation process, it is also important for understanding more technical things such as tags.
3. I believe that in most extraction scenarios the repetitions must be checked in the final file. In practice, however, this step is sometimes skipped, as it seems unimportant. This approach may backfire in various forms of damage, from minor slips to weird mistranslations. Unless you are prepared for substandard quality, I advise to keep this step in your process, perhaps in a form of a quick proofreading.

By the way, Velior provides discounts for the repetitions in our quotes, making it quite affordable to let us handle the repetitions. And how do you approach the repetitions in your translation business? Do you accept work with any unpaid repetitions?

This post offers a few best practices for translating uneditable text. The approach to handling this type of text depends on the source files:

1. Many uneditable texts are scanned copies of poor quality. A good example is medical records written in Russian. Russia-based healthcare professionals often develop illegible handwriting, because they handle too much paperwork daily in the environment that is still largely paper-based. For this reason, their written opinions or prescriptions are often Greek to the people outside of medical profession, including translators. Ideally, we prefer to use a healthcare professional to “decipher” such records, instead of translating directly from the scans. This eliminates hours of guesswork otherwise spent by a translator.
2. Another common uneditable text type is a PDF file printed from a desktop publishing software or MS Word. In such cases, we ask the client to provide the underlying editable file such as INDD with Adobe InDesign, because handling this editable file requires much less effort than translating the uneditable PDF. Typically, the underlying file is available and can be easily provided by the client. A common reason for the client to initially provide a PDF file instead of an INDD file is simply being unaware that the latter can be translated more easily, leading to reduced costs.
3. Where the items 1 and 2 above are not applicable, we resort to the optical character recognition (OCR), recreating the uneditable content in a separate text file. Creating an editable file enables our standard translation workflow, which is built around processing bilingual files. Where any complex formatting is required, we add the cost of OCR to the total amount billed to the client: this service is called “recreation of formatting.” With smaller or simpler files, we may do the OCR free-of-charge or bypass this step by translating directly from the source file.
4. Sometimes, the client would complete an automatic OCR at their end and then request translation of the resulting editable file. With the files that include complex formatting such as tables or figures, the automatic OCR tends to provide poor results, and the OCRed file may still need many manual adjustments. In such cases, we may ask the client to compensate the “recreation of formatting” anyway, despite the theoretically editable source file.

As many other professions of today, translation is tightly interconnected with the Internet. Some of the ways translators use it in their daily work include researching the subject matter to understand the original text and finding the commonly used target language terminology. But which websites can be considered trusted sources of reference materials? I’ve recently worked on an English to Russian translation concerning innovative disease treatment methods and referred to the Internet extensively to find terminology that is not in the dictionaries yet. I was, however, frustrated with the low efficiency of my research because the search engines continuously yielded tons of unusable results. This post summarizes my general opinion on this matter.

The average quality and trustworthiness of the search results I scan through while searching for the reference materials on the Internet are decreasing. The quality is diluted since useful content is just a fraction of the total content volume added daily. I can think of two potential reasons behind this:

1. As I use the search engines to research Russian terms, I increasingly stumble upon the automatically generated texts. A major source of such content is the machine translation (MT). The webmasters simply feed English (or other language) content into the MT engines and publish the resulting Russian text without any editing. Another significant source is the software that generates “unique” content by stealing someone else’s text and replacing as many words as possible by synonyms. As seen by the search engine crawlers, this content is indeed unique, but for the human users and especially translators who look for the commonly used terminology it’s of no practical use and is really a time waster.
2. The abundant human translations also contribute to diluting the content quality. While the Internet is certainly home to many well-crafted translations, a huge portion of translated content gives rise to concern. In particular, I find it hard to trust the terminology. For this reason, I rarely use translations as the reference materials. The odds of a literal or incorrect translation are just too high for me to take the chances. I’d rather invest more time in finding content written by the subject matter experts using their native language.

In the light of these observations, I am often surprised by the criticism of Wikipedia. I do realize that it’s not ideal, just as nearly any other crowdsourced initiative. But, as a whole, it might be one of the best general knowledge resources we’ve got on the Internet, simply because there is no other website that provides the same amount of reliable content under one roof. The additional benefit is the well-structured, easy-to-use GUI. Naturally, the translators should not use it as their only source, but at least it’s a good place to start—you can develop a basic understanding of the subject matter and then go deeper with your research by using the available links or keywords.

You can read more about how the Internet helps translators in this post.

This is the 2nd part of the post. Part 1.

Reasons Not to Charge Full Rate

3. Translators who prefer full compensation also maintain that they invest a lot in translation memory software and related training to make it possible to process 100% matches and repetitions with less effort. Because of this personal investment, it is they who should reap the full benefit, not the client. As a translator myself, I think that they are correct to some degree, but the reality dictates otherwise:

• This logic could apply when the TM tools were just introduced to the market. Now, they are an inherent part of the translation industry. A translator is often forced to buy them to work on the specific types of jobs, because otherwise they will not be able to accept such jobs at all. It is not therefore a genuine investment in the sense that you put your own money into optimising your own work, but simply a mandatory requisite just like a PC or phone. Trying to keep all benefits of this software to yourself by labeling it as your investment means resisting progress in the industry where many peers and clients use it routinely. It is now a common technology, and, as such, its benefits should be shared by all parties to the translation process. For example, many clients put additional effort into writing consistently and should share the resulting savings as a compensation of this effort. (I understand though that some translators do, and will continue to, charge full rate for individual and completely justified reasons.)
• The clients become increasingly aware of both repetitions in their documents and the translation memory capabilities, therefore expecting discounts, as they do not see why they should pay the same price for identical text. And I find this fair, because it is a healthy consequence of the technological progress.

What if Client Prefers Not to Pay

1. Generally, Velior requests that 100% matches and repetitions be compensated. When a client asks to automatically process them without checking, there is often a risk of mistranslations, and we do not want any flaws in our translation, even if they happen through no fault of ours. For this reason, such requests are honoured on an exception basis only.
2. In these situations, we ask the client to extract the 100% matches and repetitions into a separate file, which includes only a single occurrence of each match/repetition. After the translation, the client can use this file to assemble a final translation. Again, there is always a high risk of mistranslations. Normally, such assembled translation should be proofread. Otherwise, the quality will likely decrease.
3. Translation agencies also use the “Perfect Match” technology to insert 100% matches only when the current context is identical to the context, in which they were originally translated. While this technology indeed brings client-side efficiency and cost-effectiveness, it often has drawbacks from a translator’s perspective. The translator normally needs to have control over the entire text, while this technology lets them work just on parts of the text. They do not see a “big picture” and also cannot change the existing translation (either because it is blocked, or they have little motivation to do so, as this work is not compensated). This reduces the translator’s efficiency and quality.

Notes

1. Generally, Velior does not provide discounts for any matches with the translation memory created by someone else, because we cannot be sure about the quality of those translations. They may contain errors that will reappear in the current translation and eventually become our responsibility. Such jobs are subject to negotiation on a case-by-case basis.
2. The match and repetition discounts do not apply to editing or proofreading, because these services are designed to check the entire text, hence matches and repetitions give little or no time savings.
3. Interestingly, our main language combination, English to Russian, yields much more repetitions than the Russian to English translation, which can be mainly attributed to more complex and diverse grammar and punctuation rules in the Russian language.

This post discusses Velior’s approach to charging for 100% matches against translation memory and internal repetitions. Generally, there are three opinions on this matter. Two of them are opposite: some believe that these matches and repetitions should be compensated fully just as any other words, while others maintain that no compensation is necessary, since processing these words does not require any specific effort. The third opinion, shared by Velior, is neutral: a reduced rate should apply to these words.

Reasons to Charge for 100% Matches and Repetitions

1. The context where a 100% match or repetition occurs may be different from the context of the original translation. It is therefore important to check whether all such words fit the new context. The time spent on checking should be compensated. Processing 100% matches and repetitions without compensation and hence without checking is justified only when the client is absolutely positive that the context is always identical, e.g. in a data sheet or parts catalogue. However, in our experience, such texts are rather the exception than the rule: they account for about 3% of our workload (translation from Russian to English, English to Russian, German to Russian).
2. 100% matches and repetitions often require the same amount of typesetting work as any other words. Even when 90% of your text are repetitions, you might end up spending just as much time on formatting them as if they all were new words. And unless this type of work is compensated separately, it should be included into the repetition rate.

Reasons Not to Charge Full Rate

1. Because the amount of work associated with 100% matches and repetitions is normally reduced as compared to the new words, it does not make business sense to charge full rate for them. You do not have to translate them from scratch, but just check whether the previous translation fits the new context, and it usually does. Truth be told, sometimes such words do require adjustment or even complete re-translation. For instance, an English to Russian translator may render the word “position” as “должность” when it means job position. This translation however will be of no use as a 100% match in the context where “position” means simply location and should be translated as “положение.” Yet, as I mentioned above, this happens to a very low percentage of 100% matches and repetitions, and a discount is therefore completely justified.
2. Translators who prefer full compensation for 100% matches and repetitions often refer to various examples from other industries to explain that a discount for repetitive work is unnatural. For instance, in the construction industry, you will not push the construction crew, which is building your new home, for a discount on the basis that one room is an exact match of the other. While this idea might have some truth to it theoretically, in real life, it is the actual amount of work/time/effort associated with the repetitive task that is important here. The new room might be indeed identical, but the amount of work required to finish it will still be the same. In contrast, the amount of work associated with 100% matches and repetitions is usually much lower as compared to the full-rate new words. Normally, the translation memory software inserts them automatically, and you only check whether the previous translation fits the new context. It is therefore fair to charge a reduced rate reflecting the actual time spent on checking instead of charging the full rate as if these words required the same amount of effort as the new ones.

This post is continued here.