Forum: CAT Tools Technical Help
Topic: Lionbridge PMs can "detect" the use of SDL over their proprietary CAT tool?
Poster: Samuel Murray
Post title: @me
[quote]Samuel Murray wrote:
Additionally, it's possible that Trados does NOT change the file structure, in places where TWS would be expected to change it. [/quote]
I tested one of my own Lionbridge XLZ files (an old Logoport file) in an old version of TWS (since I don't have the latest version) and Wordfast Pro 7 (since Trados refuses to open the Logoport XLIFF file), and I found three problems with the XLIFF version saved by WFP7. I just mention this to show what kinds of things can go wrong.
1. WFP7 rewrote the order of the attributes in the "file" tag in the header. This shouldn't matter, but it does represent a change that is unnecessary and that could be used by a PM to recognize that the file was edited in a different program.
TWS wrote the file information in this order: datatype, revision type, target language, date, source language, original
WFP wrote the file information in this order: date, source language, datatype, revision type, original, target language
2. WFP7 inserted the source text into all target segments in the XLIFF file, even though in WFP7 itself I only translated a single segment and left all other segments empty (untranslated).
3. TWS added a segment status to the one translated segment, namely:
<target logoport:matchpercent="0" state="translated">
...which WFP7 obviously did not insert.
This means that if I were to send this file back to a client, with just one segment translated, from the client's perspective all segments would be "translated but unconfirmed". Even the segment that I had translated would be "unconfirmed".
Topic: Lionbridge PMs can "detect" the use of SDL over their proprietary CAT tool?
Poster: Samuel Murray
Post title: @me
[quote]Samuel Murray wrote:
Additionally, it's possible that Trados does NOT change the file structure, in places where TWS would be expected to change it. [/quote]
I tested one of my own Lionbridge XLZ files (an old Logoport file) in an old version of TWS (since I don't have the latest version) and Wordfast Pro 7 (since Trados refuses to open the Logoport XLIFF file), and I found three problems with the XLIFF version saved by WFP7. I just mention this to show what kinds of things can go wrong.
1. WFP7 rewrote the order of the attributes in the "file" tag in the header. This shouldn't matter, but it does represent a change that is unnecessary and that could be used by a PM to recognize that the file was edited in a different program.
TWS wrote the file information in this order: datatype, revision type, target language, date, source language, original
WFP wrote the file information in this order: date, source language, datatype, revision type, original, target language
2. WFP7 inserted the source text into all target segments in the XLIFF file, even though in WFP7 itself I only translated a single segment and left all other segments empty (untranslated).
3. TWS added a segment status to the one translated segment, namely:
<target logoport:matchpercent="0" state="translated">
...which WFP7 obviously did not insert.
This means that if I were to send this file back to a client, with just one segment translated, from the client's perspective all segments would be "translated but unconfirmed". Even the segment that I had translated would be "unconfirmed".