Feeling Like Modifying Translation Outside of Your CAT Tool?


September 15th, 2013, Roman Mironov
Dig deeper instead of going for a quick-fix

Dig deeper instead of going for a quick-fix

Sometimes, translators may realize their CAT tool does not allow them to make a particular translation for a technical reason and feel compelled to make the required modifications outside of the tool. Here is an example:

Case 1:

Segment 25: <t0/ >

Segment 26: Introduction

Segment 27: <t1/ >

Case 2: Same word, same file, but different location and different meaning:

Segment 250: <t0/ >

Segment 251: Introduction

Segment 252: <t1/ >

I want to translate the word “Introduction” differently in these two cases, because in the first case, it means prolegomenon, whereas in the second case, it means introducing someone to another person. My CAT tool, OmegaT, auto-propagates translation of these two identical segments. As a result, whenever I change any of the segments, the second one changes as well, so I cannot have two different translations of “Introduction” at once. And when I use the specific function in OmegaT that allows creating alternative translations of identical segments, it fails, because OmegaT relies on preceding and following segments for context, but they are identical in both cases, too (tags <t0/ > and <t1/ >).

In this kind of situation, a quick-fix approach is to save translated files from the CAT tool and then change one of translations of “Introduction” directly in those files. This is easy, but often far from effective. Is there a better way?

I counted four main ways to approach this kind of situations. I list the approaches in the order of preference below. Since I am opposed to making modifications outside of a CAT tool, the recommended approach is to try finding alternative ways to still achieve the result you want from within the CAT tool. And the worst idea is modifying the actual translated files.

Approach 1: Think of not-so-obvious ways to achieve the desired result using your CAT tool

It is generally best to tackle a challenge within the CAT tool as much as possible, relying on outside modifications as little as possible. The more modifications you make outside of the CAT tool, the higher is the risk of double work; that is, having to make those modifications again, after you are forced to discard modified files for some reason: they get corrupted, a client sends you updated source files, and so on.

So the first thing you should do is digging deeper: you might be simply unaware of other functions your CAT tool provides that can be a solution to your problem. Read the manual or ask fellow colleagues. In my example, I could think of several ways:

  1. Disable auto-propagation. In theory, this could be a solution, in particular in other tools, such as SDL Trados. But not in OmegaT. When you disable this function, OmegaT simply creates alternative translations for each unique segment, which, as we already know, is useless in our situation, since the context is identical, too.
  2. Note how the preceding and following segments (which, by being identical, make it impossible for OmegaT to distinguish “Introduction” based on the context) contain just one tag. Originally, these two tags were included in the same segment as “Introduction” (<t0/ >Introduction<t1/ >), but were forced outside by segmentation rules to produce a cleaner segment. It is possible to move them back in by tweaking segmentation rules. As a result, we will get two identical segments again (<t0/ >Introduction<t1/ >), but since the tags are now part of the segments, there will be different text preceding and following these new segments. This new context will likely be different in each of the two cases, finally allowing me to create a valid alternative translation based on the different context.
  3. Enable the Remove leading and trailing tags option in the project properties, so that those tags disappear from OmegaT altogether and the preceding and following segments become different, just as I described above.

Approach 2: Modify source files

The next best move is to make changes to source files. In my example, I can add # to one of the “Introduction” segments in a source file, thereby making it a unique segment:

# Introduction

Doing so allows me to tackle this challenge partly outside of my CAT tool and partly within it. I do just a small minor change outside of it and then do the most important part of the solution—alternative translation of “Introduction”—in OmegaT. While this is not as good as sustaining from outside modification at all, it is a more sustainable approach than the ones that I will discuss below, since it reduces the risk of double work dramatically. It can result in double work, only if you receive updated source files from a client. In this case, you will have to make this modification in those new source files again. But what is more important is that when you load these new source files into your CAT tool, the tool will insert the correct alternative translation from the TM automatically!

Approach 3: Modify bilingual files

If you work on bilingual files (SDLXLIFF, etc.), you can modify them as well. For example, if you use Studio, you can turn one of the segments into “# Introduction” by editing it, even from within Studio. While this looks convenient, remember that such quick-fix might be far from effective. Oftentimes, for various reasons such as a file getting corrupted, you will have to replace this modified bilingual file with the original one, which, of course, will not have the modifications that you made. You will have to make those modifications again, which means double work. Therefore, this approach is not as sustainable as modifying source files. To avoid double work in case of bilingual files, always modify the main, underlying files (source files) rather than something intermediate (bilingual files).

Approach 4: Modify translated files

This is the worst idea and should be your last resort. As soon as you change anything in translated files, you bind yourself to making any further changes to translation in these files, because you are no longer able to make changes in your CAT tool and then resave translated files—those new translated files will not contain the modifications that you already made outside of the CAT tool. To make sure any further changes to translation are also kept in the TM, you will have to make those changes not only in the modified translated files, but also in the CAT tool. This approach is inefficient, since making changes just in the CAT tool and then resaving translated files requires less time and effort.

Summary

When you cannot make a particular translation within a CAT tool for some reason and feel like resorting to making modifications outside of it, it is best to avoid quick-fixes and look for a more sustainable approach that will reduce the risk of double work.

Have a comment? Please raise your voice via the comment form below or on Twitter.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • RSS

    Subscribe by E-mail

  • © 2005-2014 Velior

    Contact Us

    Phone

    +7 (962) 155-89-07
    +7 (4932) 23-87-23

    info@velior.ru
    velior@list.ru