View source and target files

This feature already exists in standard OmegaT since release 3.6, but it was not the case when we started our development. And even if our last fork is based on OmegaT 3.6, we still have a few differerences and added features.

Actually if you use the menus in "Project" → "Access Project Contents", you will use our version of the menu, different from OmegaT 3.6 or later versions. If you use an old version of DGT-OmegaT, before release 3.2, these menu items were directly in the "Project" menu and the menu "Project" → "Access Project Contents" was identical to OmegaT 3.6.

View source

For documents which can be opened directly, such as DOCX or HTML, the «View source» menu works as in standard OmegaT.

In case the document is in the XLIFF (or SDLXLIFF) format, it will open the native file instead (there is also a menu «Open in Studio» if you really wanted to open the XLIFF). To find the native file, it will try the following steps :

1. Look in the «original» folder (Okapi tools) instead of the «source» folder; this directory exists when the project has been generated using the Okapi tools.
   In DGT, we also choosed to use the name «source-native» instead of the «original»

2. Look in the <file original='xxx'> markup in the XLIFF code and open the corresponding file, if it exists.

3. if the file is present inside <internal-file> in BASE64 format (which is the case for SDLXLIFF files), extract it into «source-native» and open it.
   In DGT-OmegaT 3.5 or later, in case you are editing an XLIFF containing multiple documents, OmegaT will check which file is associated to currently active segment, and open the correct document. Since OmegaT has no control on the opening tool, we cannot move into the the given segment, but almost we open the correct document.

View target

The main difference with standard OmegaT is that when you call this menu, the file is rebuilt so that you open the version including your last changes.

 In version 3.0 update 14, the menu "view target files" also introduce the notion of cross-compilation: when the target file is in XLIFF format, after checking for the source file using the same algorithm as in «View source», then DGT-OmegaT will do the following:

1. Create a subproject, with same project-save.tmx but whose source directory accesses to the native original file
2. Compile this project
3. Open the generated native file instead of the generated XLIFF

This method works relatively good, and its main advantage is that it does absolutely not need the original tool used to create the source XLIFF file. The inconvenience is that it does not translate all segments: those containing tags, or when segmentation differs (because OmegaT's rules can differ from those used to generate the XLIFF file), will remain in the original language. For that reason, since version 3.2, users of SDLXLIFF files can call Trados Studio instead, but only if it is correctly installed with an additionnal tool!

Note : use of temporary directory (target.tmp)

The "view target" feature implies to generate a file and to open it after in an external tool. But since OmegaT is higly multithreaded, it can happen that the external tool tries to open the file before the generation is finished.

To avoid that, files are generated not in the target directory, but in a directory named target.tmp, and this directory is renamed to target once the process is totally finished.

The same is applied during simple compilation process. This can be used, for example, if an extra tool monitors the target folder: this tool will see the modified files only once they are really finished, not during the compilation process itself.

To avoid errors, we also forbid the change of the target directory in the project properties : it is named target and is necessairly inside the project folder. Another change is that OmegaT will not complain in the directory does not exist: even if it exists, it will be removed before compilation. For other directories, nothing changes: they remain modifiable and OmegaT will complain if they do not exist.

Forbids compilation if files are opened inside Microsoft Office

When a file which is in the target folder is opened inside Microsoft Office, OmegaT may not be able to create translated documents. This is also the case in the public version of OmegaT, but since their "view target" feature does not imply rebuilding the document, the situation is simply less likely to happen.

The last version of DGT-OmegaT will detect that the file is locked by MS Office (having a look at the lock file, with name starting with ~) and refuse to compile until you close the file. This is true for "create translated documents" as well as for "view target documents", which implies compilation.