Features for revisors

In DGT, translators can also act as revisors. Generally, the translator has the last word, which means that, after a document is revised by a fellow translator acting as a revisor, the translator will check the changes made by the revisor and can accept or reject them. Bearing that in mind, the following features were developed for the revision workflow.

How to use it - the workflow

This workflow supposes that both the translator and the revisor are working with DGT-OmegaT and can interchange projects. As it is still based on OmegaT 3.6, DGT-OmegaT does not include the aligner written in OmegaT 4, so it is not possible to calculate differences between project_save.tmx and the native target file modified by the user. The possibility to do this with xliff (or sdlxliff), enabling exchange with other CAT tools (but not with editors) is to be considered for the future.

For the moment, it is to be used as follows:

1. Translator does a first version, and sends the full project for revision
2. Revisor opens the copy of the project and makes changes
3. Revisor sends project_save.tmx back to translator
4. The translator puts the project_save.tmx given by revisor in tm/ folder
   (alternative is also to move your own project_save.tmx in tm/ folder and take revisor's one as master)

​See differences and transtips for translation

Two algorithms which are usually applied to the source in the original OmegaT have also been ported to the target text so that the changes made by the revisor can be displayed with track changes in the target segment in the Fuzzy Matches pane:

• The diff algorithm in the Fuzzy Matches pane: if the current segment is already translated, which is the case when you act as a revisor, the Fuzzy Matches pane also has a new variable ${diffTra}, which, when activated, shows the differences between the translation actually in the editor and the segment displayed in matches pane:
  
  In this sample, matches #1 and #2 have a score of 100% because the source is identical, but translation differs between editor and displayed match, that is what ${diffTa} shows. Match #1 comes from the file which has been sent by revisor and copied to the tm/ directory as explained in step #4 of previous section. Match #2 comes from an usual translation memory, it shows you that this feature is not strictly limited to second revision: the revisor can use it to check whenever translators use translation memories or not!
  
  For simplicity reasons, the «External TMX» configuration dialog also adds two check boxes which enable to switch between ${sourceText} and ${diff}, and, respectively, between ${targetText} and ${diffTra}. The reason is that translators do not want to see differences in target when they are not doing a revision.
  
  Note: The project memory (project_save.tmx) of the unrevised translation should be copied to the project tm folder before the revision is started (see previous section), as OmegaT only keeps the last modified translation of each segment in the project memory. When DGT-OT Wizard is used to send a project for revision, the project memory is automatically copied to the tm folder.

• As seen here, the Transtips can also be applied to the translation zone in the Editor: only in the case there is something already translated, it will search in the translation for all occurrences of the target language version of each glossary entry and add underlines where it is found:
  
  
  As for other markers, update is done at real time, meaning that a marker can appear or disappear while you are typing, when you change the contents of the segment in the editor. Thanks to fast markers, this will not slow down OmegaT when you type.

​Notion of revised segment

In DGT, generally the translator has the last word so it is important that (s)he can easily and quickly check the segments that have been changed by the revisor. For that purpose, we added:

• In the View menu, a new color for «Revised and Changed Segments», which is applied to all segments for which the login of the last translator («changeid» in the project_save.tmx and identified as «Translation last modified by {login}, if Modification Info is activated) is not the same as the login of the first translator (creationid).

• In the Go To menu, the options «Go To Next Revised & Changed Segment» and «Go To Previous Revised & Changed Segment» respecting this criteria.

​Revision mode (note: experimental)

Therefore we implemented a distinct behaviour for those who want to use OmegaT for revision. In this mode the following changes occur:

• Each time you visit a segment, a new field «revisor» is filled in the project_save.tmx, even if you do no change it. Such segments have then the «revised» status, even if not changed.
  The revisor field is displayed in the Editor, together with the Translation Last Modified by {login} field. It can be displayed in the Fuzzy Matches and Search panes, if so configured.

• In the Go To menu, there is the option Go To the Next Unrevised Segment (with the same shortcut as Go To Next Untranslated Segment when in Translation Mode), thereby making it easy for the revisor to «bypass» segments already revised, for example, non-unique segments already revised.
  Please note that, in Revision Mode, any visit to a segment implies that it will be marked as revised, whatever method is used to open and close it – mouse, menu, keys or even via a search. And this field cannot be removed.

• Since DGT-OmegaT 3.4, if your documents are in XLIFF 1 or SDLXLIFF format, and if you are using the StaX filters, segments having this "revised" status in project_save.tmx will receive the "approved" status in the target XLIFF file.

The revision mode is activated or deactivated in the Option menu or using the corresponding button in the toolbar:

This button is a two-state button, the mode being active or inactive. You can also see at the top of Omega-T window in which mode you currently are.