A simple DOCX test file was created, which looked like this:
TagEditor test
Using the default XLIFF INI supplied with SDL Trados 2007, I obtained results which looked as follows:
Some ugly tag salad there and exposed , vulnerable information from the header. Using the adapted INI file I made for memoQ XLF files, things improved a bit:
Still not very pretty, but it works, and it works better than an memoQ XLIFF currently does in TagEditor. No breaking of tags.
Translated and brought back into SDL Trados Studio, the translation grid looked like this with everything in good order:
The target DOCX file with the translation saved nicely and was perfect.
In real life, however, it may be necessary to adapt the INI file in TagEditor more extensively for good results. The German consultancy Loctimize has compiled some good instructions for doing so in which the entire workflow is also described nicely (in German). So far I haven't run across similar instructions in English.
OmegaT test
Initially things looked much better with the SDLXLIFF file imported to OmegaT:
A great start, much cleaner-looking than TagEditor! But when the translation was re-imported to SDl Trados Studio, a small problem was apparent:
One of the tags in the second segment was dropped. In a similar test with an XLIFF from memoQ, the version of OmegaT I tested (version 2.3.0, update 3) appeared to trash even more tags, and the target file was completely reformatted! In fact, it even trashed tags on the source side in the memoQ file! Thus I was deeply concerned about the XLIFF filter in OmegaT. However, as astute observers have noted, I probably deleted the missing tag when editing in OmegaT, and a subsequent successful re-test of the workflow confirmed this. But the problem with the XLF file from memoQ was frighteningly repeatable. Careful, systematic testing revealed, however, that the roundtrip of a bilingual XLF file from memoQ back into memoQ failed. Either there is a problem with the version I have installed (5.0.56) or the installation is corrupted. The matter is being pursued with Kilgray support. The target file from the SDLXLIFF translated with OmegaT was fine.
memoQ test
I have translated many SDLXLIFF files in memoQ and seldom encountered a problem of any kind. The file from SDL Trados Studio looks as follows in the memoQ environment:
Please note: with memoQ I can use an XLIFF which has not had the source copied to the target or one which has been pretranslated. That is not really the case for the other two environments tested, because with both TagEditor and OmegaT the source must be copied to the target or you have nothing to translate. You might say that memoQ offers "real" XLIFF editing for translation.
The SDLXLIFF file translated in memoQ reimported beautifully to SDL Trados Studio 2009 and saved to a target file (DOCX) from there with no problems.
I am really surprised by the results you obtained in OmegaT.
ReplyDeleteYour screenshot shows one thing: the tag is missing from your target segment.
How have you inserted the 2 other tags ? Have you inserted them manually? Have you used the "Insert tags" function? Have you used the "Insert source" function?
Also, have you validated the tags before creating the target ?
My idea is that you probably had the "Insert source" default setting on and that you erased the while translating, then you forgot to validate the tags and you created a malformated XLIFF file.
As for "trashing tags on the source side", I find that a bit suspicious. The XLIFF filter has been used by quite a number of users already, on plenty of real life SDLXLIFF files and such behavior was never reported.
It's hard for me to believe that the first time you review OmegaT with a trivial DOCX file you manage to bump into the one little file that triggers the bug that nobody had noticed yet...
Let me suggest that you send your project to the OmegaT developers and/or that you redo your tests with: "Insert all tags" instead of "Insert source" and that you validate your tags before target creation.
I've used OmegaT numerous times for quite complex SDLXLIFF file sets that were produced by the client on Studio 2009 and Studio 2011, either as standalone XLIFF files, or as files that I extracted from translation packages with Started 2011 and none of the files I delivered triggered a negative reaction from the client (or from the software).
After I acquired a license for Starter 2011, all the files were checked in OmegaT before verification in Starter 2011 and "return package" creation and none shown the behavior you describe.
I don't doubt your sincerity but I think you may have forgotten a few important things while you translated.
Regards,
Jean-Christophe Helary
OmegaT l10n manager
Thank you for the comments, Jean-Christophe. I've spent the afternoon re-testing in various configurations, and the problem with memoQ described elsewhere at least is repeatable (I haven't had the time to look at Studio yet in the test matrix.) The tags were indeed trashed when the XLF file translated in OmegaT was re-imported to memoQ version 5.0.56 (which had generated it). However... when I did a roundtrip test from my copy of memoQ I discovered that memoQ trashes the roundtrip import of its own XLIFF file. Either there is a bug in the current filter or my own configuration has been trashed in testing. I have reported this to Kilgray support and await feedback from there before continuing my tests. On days like this I wish I had done the work on a virtual machine.
ReplyDeleteSo at the moment I can't make a definitive statement confirming or recanting my comments here about OmegaT and XLIFF. In general, though, I would like to comment that I like the improvements to the tool compared to what I saw several years ago. For the most part I am referring to the greater number of filters.
@Jean-Christophe: re-testing the SDLXLIFF in OmegaT indicated that you are right, or at least close to what must have happened. (I was working in parallel with several files having the same words and different tags, so this might have happened when editing tags from a match with "fuzzy tags".)
ReplyDeleteSo my revised opinion is that doing content like this in OmegaT is far more pleasant than TagEditor :-) Just don't forget to verify the tags before you export from OmegaT....
Would you be willing to share the adapted INI file you made for memoQ XLF files?
ReplyDelete