Tracked changes in memoQ 5 & what more we need

A recent round of e-mail with colleagues reminded me of how critical revision workflows are for many people and how too often we must resort to workarounds, because our translation environment tools don't quite do what we require of them. Tracking changes and comparing versions is necessary in many different situations, and no single method will cover all needs.

memoQ 5 offers the ability to track differences between minor versions in the translation window. What is a minor version? A major version is created when a version of a source text is imported. The first version of the source text imported will be version 1.0, the second will be 2.0 and so on. When various things occur with the translation of a source text version, such as an export, an update by importing a bilingual file, a change in the person working on the document or the creation of a status "snapshot", a minor version is created with sequential numbering after the decimal point: version 2.1, 2.2, 2.3, etc. memoQ allows you to compare the current translated text to any previous minor version of the same source text version. Of course, in order to use versioning and tracked changes, versioning must be enabled for a project on the first page of the project setup wizard. It is currently not possible to enable versioning later, nor, unfortunately, is it possible to make versioning active as the default for new projects. I hope that memoQ will allow both of these options in the future.

There are three ways to activate the tracked changes view in memoQ. Two of these are equivalent: the menu option Translation > Toggle Track Changes > (options) and the corresponding icon in the memoQ toolbar with the same options:

Selecting the Custom option opens the following dialog:

The third way to activate tracked changes is undocumented as far as I know. It was shared with me just recently by a new user who has a brilliant knack for finding new ways of pushing memoQ to its limits. Pressing Ctrl+F5 with the cursor in a target segment begins tracking changes to that segment. Confirming the segment removes the tracking. Change tracking can be turned on for various individual segments this way, and the toggling of the feature is independent for each target segment. This can be useful if you are changing several segments but don't want to lose track of the original text until you are sure of the edited text. Here is an example of a minor version comparison with additional editing in Segment 2 using this undocumented mode for tracked changes:

Combining or splitting segments appear to erase the row histories for the segments affected.

The process of comparing minor versions will work well to review changes made by editors working externally to memoQ on bilingual files with other tools, for example. What is missing is an effective way to revert changes made to individual segments other than by retyping. Nor is it possible to revert entirely to a previous minor version (except by the workaround of saving a corresponding bilingual file as a backup and re-importing it).

There are also issues if changes between versions are to be exported for review in other tools, such as a word processor (Microsoft Word and others). While one could use the document comparison function in these or other tools to create a mark-up of changes, it would be nice if this were possible directly from memoQ (in the RTF table bilingual format as well).

Another idea shared by the same translator who discovered the use of the Ctrl+F5 key combination for toggling tracked changes is making changes stand out through the use of color in an export format that would support this. The color could be applied to the text which has changed or to the text which remains the same. (The latter case might be more appropriate if the changed text has significant formatting to be reviewed and the color would cause confusion.) Background highlight colors might also be used. In a similar vein, she suggested that this coloring of the target text might be used to indicate other things, such as 100% or context matches. Not only would this make it easier to focus on changes scattered throughout a large text, it would also be of great help in cases where one is not supposed to look at 100% matches and make changes to them. Proofreading is otherwise difficult. This is why clients often using color marking of some sort for text changes, but applying this to matches or version changes of a translation for the same source text would make this concept far more useful.

A few possible workarounds do come to mind for memoQ, but these only apply to a few situations. In the bilingual RTF table exports, one could sort by the status column, then change the background color of rows that are 100% or context matches, then re-sort the table by segment number. Or write a macro to do that. The bilingual DOC format could also have 100% matches marked in color using a macro with an appropriate regular expression to identify those segments. Such coloring options are available in Trados Workbench and are important to the revision workflows of some financial translators I know and probably many others. Similar ideas were shared with Kilgray about a year ago, and I do hope that the upcoming version 6 will offer us something of this sort as well as many other advancements in the management of translation versions.