I saw this in one of my mailing list digests this afternoon: "pptx.itd.sdlxliff - does not import to DVX2". My first thought was "My God, why should it? Serves you right!" as my mind boggled at the thought of someone taking a PowerPoint file through the venerable SDLX application to some version of Trados Studio and then on to DVX2. Whither next? Why not Wordfast Classic just for fun, with a detour through a few different versions of memoQ and a pass through TagEditor just for laughs. Somewhere in all of this, text presumably needs translation, but with all the myriad MT integrations along the way that will surely happen to the satisfaction of the translation as a utility gurus at TAUS.
Seriously, though, that slightly disturbing process chain evident from the file-extension-too-far is just one example of many of the odd surprises out there in the world of real projects and why even in my most ungenerous moments I won't expect any provider to cover every inconceivable scenario perfectly, only to offer sufficient interface support so that somewhere, somehowever improbably, a suitable tool can be added to the process to get the job done.
What's the most absurd process chain you've experienced? This message from the Déjà Vu list seriously tempts me to see how long and ridiculous a "supply chain" I might be able to simulate with a moderately complex file and still run the translation back through the chain to get an acceptable target file. We could have a contest and call it the Rube Goldberg Memorial Translation Relay. The diagrams alone would be worth a round of beer.
Well, not most absurd, but I fairly frequently have to go .docx.ttx.sdlxliff (i.e., segment a Word file with Tag editor, then translate it in Studio), for those customers who are among the 25% that still use Trados 2007.
ReplyDeleteThat depends. You can just take the presegmented TTX straight to memoQ as well :-) Might be a better option unless Studio will also handle the unsegmented number and date content.
ReplyDeleteBut in any case, whatever tools we prefer to use, that 25% makes it clear enough that some tested strategies for compatibility are smart business. Even SDL had to acknowledge this by finally re-introducing compatibility with the venerable bilingual DOC/RTF format in later versions of Studio. The biggest successes I've seen with most tools in the past decade or more often depend to some degree on their ability to share data with other environments with the least trouble, and I hope that some day soon this ability will be extended to the rather awful current generation of translation project servers, which are often an attempt to return to the past headaches of platform lock-in.