DGT-OmegaT new versions published

When you use the menu "view source" or "view target" for an XLIFF file, DGT-OmegaT tries to open the native file, and if necessary, extracts them to the directory source-native or target-native. New versions improve these behavior.

DGT-OmegaT 3.3-STABLE-2 : add extension to file extracted from XLIFF

Initially DGT-OmegaT extracted the file with a name based on the name of the XLIFF file, instead of the name declared in <file> markup. SDLXLIFF files usually have a name with two extensions, the native one and sdlxliff (for example, .html.sdlxliff or .odt.sdlxliff) but this is not a requirement. When the two extensions were not present, the generated file had no extension and the operating system was not able to open it. Problem is solved now.

DGT-OmegaT 3.4-TEST-2.0 and 3.5-DEV-2.0 : treatment of multiple files in XLIFF

An XLIFF file can support more than one <file> markup, each of them containing a distinct file. Trados, for example, uses such files when you merge  multiple SDLXLIFF files.

In such a situation, initially DGT-OmegaT treated always the first file, even if the editor is somewhere corresponding to second or third file. These new versions will now read the entry key to check which internal file should be read.

Even if we could consider this as a bug, some more tests should be necessary, for this reason we prefer to put this as a new feature only in TEST and DEV branches.

Addition. Changes made to file filters are only applied to release 3.5-DEV; we consider them as experimental, not enough tested, so it would be useful to try with 3.4 and 3.5, then check if there are other unexpected side effects.