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.

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.

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.

Working with translation agencies often involves projects with existing translation memories (TMs) created by a different translator or translators. For example, an agency decides to use your services, since the original translator is unavailable. The agency expects you to provide discounts for 100% and fuzzy matches. Because you can’t be sure of the quality of those existing translations, the best practice is to scan the TM before accepting the project, but this is not always possible or informative. More often than not, it is only after you have started translating that you find multiple errors in the TM. This post outlines the most common errors in the TMs and suggests recommendations on how to deal with them.

Most Common Errors

1. Mistranslations. This is the single most important type of translation error, and the existing translation memories are not free of it. Normally, a translator should, and is expected by the agency to, trust the existing TM. This, however, can create a conflict: you can notice an erroneous TM entry, but your basic assumption and often a direct instruction from the agency is that TM is correct. Such conflict is a serious time waster causing you to scratch your head each time you encounter a potential error: is it really an error or is there something that I don’t understand, but the original translator understood better through more experience with this project?

2. Inconsistency. Because translation companies often have to use different translators for the same client, this client’s TM tends to grow more and more inconsistent with time. Each new translator hopping on the bandwagon is more likely to make changes to the existing TM, rather than strictly follow it. The main reasons include: (a) failure to look up the existing translations in the TM, and (b) the assumption that they know better than the previous translators.

3. Poor, literal style. Based on my experience with editing English to Russian translations (and using outside of my work for that matter), I sadly conclude that a literal translation is today more like a given. The ability to make translation feel natural is the mark of a truly professional translator (perhaps, top 5-10% in our line of business). This means that any existing TM is very likely to have a certain amount of sloppy translations that are difficult to apprehend.

Recommendations

1. Be sure to understand that you are responsible for the translation you will provide based on the external TM. Sometimes, despite being paid for reviewing the TM matches, a translator may tend to skip them or ignore errors, assuming that the TM is correct, just because it should have been checked thoroughly in the course of the previous projects. This assumption can be extremely detrimental to the quality of your work and hence your image. In fact, the minute you insert a 100% match or adjust a fuzzy match in your current project, it becomes your very own translation. Any errors in the translation you deliver are your errors, even though they may come from the TM. It’s my recommendation to review and edit all matches following your general editing approach. Don’t trick yourself into thinking that correcting someone else’s errors is not your job or this memory should be correct anyway (despite what common sense may tell you), otherwise it wouldn’t have been provided to you. For instance, my approach is to correct obvious errors, in particular mistranslations or inconsistency, and minimize preferential changes.

2. When things get worse as you move through the project, stop and let the agency know immediately. Just as with the previous recommendation, don’t ignore the obvious: as long as you keep editing the sloppy TM matches, you perform unpaid work. As I said earlier, the basic assumption and the only valid reason for discounts is that the TM is correct, i.e. you are paid for reviewing the matches, not correcting errors. Otherwise, you wouldn’t have accepted the discounts. You don’t have to bear a loss by spending uncompensated time on correcting someone else’s blunders. I made this mistake too often myself thinking, okay, this is probably the last error, I will correct it, it won’t take long, but the TM kept throwing errors at me. You may also think that because you already accepted the project and confirmed the price, you are bound to complete it on the agreed terms and absorb the loss alone, because you should have known better. It’s important to understand that the erroneous TM is a hidden issue, which is too hard to discover in the process of considering and negotiating the project. You definitely have the right to contact the agency, explain the problem, and renegotiate the price or work out another win-win solution.

For more information on working with the external TMS, you are welcome to read this post.

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.

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?