The recent builds of memoQ 6 have caused some confusion with Kilgray following the SDL practice of creating its own extension for XLIFF files, so these may not be recognized by other applications and would need the extensions changed to XLF or something else generally recognizable as XLIFF.
This can actually be done directly in the export dialog for the bilingual XLIFF file. Just change the file extension in the File name field. Despite a renamed extension, the file will be recognized as a memoQ bilingual when re-imported, and the translation of the original file will be updated.
If you encounter a compressed memoQ XLIFF export (MQXLZ), be aware that this is just a ZIP file. Rename the extension to ZIP and unpack it to get the real XLIFF (MQXLIFF) file. That file has a generic name (document.mqxliff) and should probably be renamed before it is shared.
Update 2013-07-23: Here is a short video I posted on YouTube to show how to export an XLF file and open it in SDL Trados Studio:
The need to rename the file extension of the MQXLIFF to XLF, etc. also apples to previous versions of memoQ. In those the program will also insist that the Import/update bilingual function be used rather than Add document.ReplyDelete
Kevin, you´re a life saviour :) Thanks for the info and you are absolutely right, both Memo Q and Trados should find a way to work together, streamline system processes for seamingless compatibility - we, who work with these have better things to do with our time than doing research to change file formats!!Delete
Only a little note not directly in behalf: the next version of Apsic Xbench(ver.3) will support MemoQ 6 XLiff files :)ReplyDelete
The problem is, however, that they've changed the XBench licence and starting from 3.0 it's no more freeware.Delete
The standard addition of the language code in the names of exported documents can be changed in a deeply hidden system file. I wonder if there exists a similar hack for this issue.ReplyDelete
Doesn't matter Thomas - we should not have to tweak this. It should be done properly in the system defaults. It's not that hard to make the necessary change.ReplyDelete
I believe that. But the fact is that Kilgray's priorities don't always coincide with mine, and if there is a simple solution to a problem that involves some tweaking, I'm happy to settle for that. Xliff is supposed to be an exchangeable standard format. It's sad that Kilgray couldn't resist the urge to imitate SDL and created their own signature extension.ReplyDelete
Thomas, I don't have much of a problem with a unique, branded extension, though internal identifiers with a known extension would have been better. The biggest problem for me is defaulting to the compressed format (MQXLZ), which is yet another renamed ZIP file. I have seen a lot of people send this on to others, thinking they have shared an XLIFF, and the trouble starts.....ReplyDelete
Does it default to mqxlz? Never noticed that. Apparently it remembers my preference, which is good.ReplyDelete
Hi Kevin & all,ReplyDelete
I know I'm 3 years late, but this seemed relevant to the discussion:
I was just investigating the .mxliff format (MemSource).
I wanted to import this file into memoQ, and attempted to do so using the default plain XLIFF filter, though unfortunately all the special metadata is ignored (as expected).
I got curious and started comparing files to see if it would be simple to write a conversion program for mliff -> mqxliff, when I came across something interesting.
The XLIFF 1.2 standard does not specify values for the "locked" attribute of , so the follow is not so surprising, but it's still a situation that incidentally supports vendor lock-in, since it complicates conversion between vendor formats needlessly:
Notice how in the below image, MemSource uses "true" to indicate that a segment is locked, while memoQ uses "locked".
I pity anyone tasked with writing fully-functional conversion filters for these formats. Of course, there is probably some very good reason why memoQ does not use the more obvious choice, "true", like MemSource does.
Briefly put, predictability is important, but this is the enemy of vendors who wish to retain and grow their business (preferably until they take over most of the market, like Microsoft brilliantly achieved with their hard-to-crack formats for years. Not to be tough on MS - their recent open source initiatives are commendable.)
So, Kevin, I certainly agree that Kilgray could have done more to promote transparency and ease of use, and using a compressed by format could be considered a brazen attempt at boosting vendor lock-in, though it's also conceivable that some clients preferred this for security reasons, since compressed files can not easily be scanned/grepped, assuming the contents are very sensitive.). Moreover, compression can of course greatly reduce file-size, as mqxliff gets bulky rather fast.