Most things in life come at a price, and so does OmegaT’s freedom from bilingual translation files. Since I wrote about how great it was not to have intermediate bilingual files in OmegaT, it is only fair now to describe also the “catch.”
Tracking changes is a very useful function for a translation memory program, and particularly important for editing. It allows you to go back to a previous version of a translation. When an editor makes changes to the translation, a translator can review them easily and decide whether to accept or reject them.
Since OmegaT stores translations in a TMX file (project_save.tmx), it does not allow tracking changes. To review changes effectively, you need to use another tool such as the excellent Change Tracker to produce a comparison file that shows all changes made to a translation. It is a good workaround, but not as effective as working with tracked changes directly within OmegaT. For example, to reject changes, you need to open OmegaT and make those adjustments manually.
No bilingual file means no segment statuses, because, just as with tracking changes, there is no place to store them. Statuses could come in quite handy, though.
For example, other translation programs allow filtering based on statuses. If I change a 100% match in SDL Trados Studio, the segment still keeps the 100% status, allowing me to keep handling it as such in the future. For instance, If a client asks me not to review 100% matches, I will want to skip them. Since other programs keep the status even after changes have been made to the segment, I can always filter out 100% matches, despite the changes that I made. In OmegaT, however, as soon as I change the 100% match, both the time and user name are changed, while this is the only information I can use to find 100% matches. So after changing a 100% match, I can no longer filter it out and might end up reviewing it, which is exactly what I want to avoid.
Alternative translations are different translations of identical segments resulting from different context. For example, I might have very poor segmentation in source files—sentences split into several parts:
As a global company, we must comply with the
U.K. Bribery Act
which has global reach.
U.K. Bribery Act
is a law enforced by the U.K. Government.
Due to bad segmentation, these two sentences have two identical segments “U.K. Bribery Act.” By default, these are auto-propagated; that is, changing one segment also changes the other one. Suppose I need to translate them differently, because, although identical, they are in different sentences and even in different parts of the sentence. Thus in the case of English to Russian translation, for example, I will need to make the translations different. For this purpose, I use the alternative translations function.
This function saves alternative translations at the end of my project’s translation memory, appending additional information to them:
- File name
- Preceding segment
- Following segment
This information allows OmegaT to distinguish between two different translations in the translation memory and insert them in the right places.
Now, what if the file, preceding segment, and following segments are identical? Such situations are rare, but possible. Right now, OmegaT does not know how to deal with this. You can only resort to a workaround, such as changing the source files to make one of the segments unique. This is time-consuming compared to working on a bilingual file in another CAT program, where you simply disable auto-propagation and change the translations freely. Since those programs store translations directly in the translated files rather than in translation memory files, they do not need to rely on context.
Some of the above limitations may have already materialized in feature requests for the developers to consider. The question remains, though, is how we, as users, can help the developers implement these and other requests. One thing that I believe OmegaT could benefit from in this respect is crowdfunding, as suggested by Marco Cevoli. Users could let the developers know what they find to be most important to do in terms of OmegaT development by voting with their money.
Please disagree with me in the comments if you have a different opinion. If you liked this post, please let me know by “liking” Velior on Facebook.