It is often assumed and sometimes explicitly stated that, with the introduction of memoQ version 6 and the new MQXLIFF and MQXLZ (a ZIP file with XLIFF and other resources) formats, memoQ has taken a step backward in compatibility and can no longer produce ordinary XLIFF (or *.xlf) files. This is simply not true!
Kilgray doesn't exactly help the situation by talking about renaming MQXLIFF extensions to XLF; in fact, I have roasted the chief developer of Kilgray slowly over hot coals for this and other silliness and told him how I think this all ought to be handled. (And knowing Gábor, when he does fix it, he'll exceed my best imagination in the quality of his concept.)
But as is often the case, those geeks at Kilgray actually solved the 'problem'; they just forgot their own solution or forgot how to explain it coherently.
First of all, it's important to get the settings right. In memoQ, XLIFF files are saved from the Documents or Views tab of Project home > Translations, by choosing Export bilingual, and the correct settings for the bilingual (XLIFF) file to be shared with other environments or older memoQ versions are:
I have boxed the relevant area red for better clarity.
When saving the file, simply change the file extension in the name of the file as you save it as shown here:
When the exported bilingual file is saved to a folder in the file system, a quick check confirms that renaming the file extension in the Save dialog works. (I do this all the time in other software like Notepad).
Now the file can be recognized without further ado and imported into most other environments for translation. The only real "troublemaker" here is, of course Trados. As I reported in September 2011, there is a bug in SDL Trados Studio which screws up the import of XLIFF files in many cases if the sublanguages are not specified or the default major languages do not match. SDL has many priorities, but often it seems that compatibility and standards compliance are not among them; to this day AFAIK the bug remains unresolved!
For users of other tools, this means that to exchange data with Trados users for any purpose, you should get in the habit of specifying sublanguages. This means DE-DE, DE-CH or DE-AT instead of DE for German, EN-US, EN-UK, and so on instead of EN for English. Ain't it great? Brought to you by SDL development. Maybe they'll do a better job once the move to Cluj, Romania is complete ;-)
Update 2013-07-24: Here is a short video illustrating the process of exporting XLF files from memoQ and opening them in SDL Trados Studio:
There's another nasty bug in Studio where inline tags in mqxliff files get corrupt as well.
ReplyDeleteThomas, are you sure that is an SDL bug and not a planned feature? ;-)
ReplyDeleteWhere has the "disinformation and misinformation" been spread, and by whom, if I may ask?
ReplyDelete@Dominique: I doubt by you. J.C. and a number of others have claimed for months that version 6 of memoQ will not create XLIFF any more and that a step backward has been taken in compatibility. An obvious, simple solution for the masses here is to add it as an explicit save option ("XLF for other tools" and *.xlf in the Save dialog), but even so, it works as you see and probbably already knew. And that bit with Trados sublanguages bedevils so many people - to the delight of SDL who happily leave the bug in the software to give the impression that others have the problem. Ii cornered the responsible develooper in Warsaw in September 2011 and it was clear he did not give a rat's tail about it. Or was ordered not to.
ReplyDeleteI would be grateful if you could point me to the post(s) on the memoQ list (or elsewhere) where I made such claims, because I had a look at all posts of mine where "XLIFF" was mentioned and I couldn't find any.
ReplyDeleteYou are perhaps confusing discussions about XLIFF with the uproar related to bilingual Word files. There was indeed a change between memoQ 5 and memoQ 6 in that respect, which upset many people (though not me), and Kilgray eventually reinstated the feature as it was in memoQ 5. But this has nothing to do with XLIFF.
@Dominique: Please re-read m comment. I said that I DOUBT that you made such claims. Information I see from you is inevitably accurate. Unless you read my crapp English wrong, of course ;-) I am referring to Jerzy. He and some others have told half the universe that memoQ is all screwed up for XLIFF now. It's been a real FUDdle. Even regular memoQ users are a bit confused in many cases for which I lay responsibilit straight at Kilgray's doorstep. You are innocent AFAIK :-)
ReplyDeleteOh, I beg your pardon - I may have been mislead by the mglxlz files indeed, as the version 5 has created nice plain vanila XLIFF, which could be opened with the standard file type in Studio, while the uncompressed xliff by version 6 will not open in Studio at all, at least not without defining your own file type fo it, but I certainly did not tell half the world MQ is crap :)
ReplyDeleteThere is an interoperability between MQ and Studio, and if you define the MQ file type in Studio decently, I have encountered no losses in that exchange. So for the time being MQ serves me again as the mediator between Transit and Studio. Working with MQ is not an option, however, because despite it big advantages, there are some important things missing in MQ, making work with it inefficient. The first and biggest issue is view filtering, the second the way segments with numbers are handled - at least so was that in my last big project in MQ, where over 3000 words repetitions resulting from simple numbering like "part nnn" were not handled as such in MQ, but I simply had to confirm all occurances of "Part 1" separatedly from "Part 2" and so on - which would have been one autopropagation in Studio. Of course you can deal with such segments differently, but somehow I could not find out how to confirm "Part 1" and let all "Part nnn" be confirmed alltogether :)
@Jerzy, you and half the world were misled by the confusion of those compressed defaults and the way they were communicated by our Hungarian friends in the interface. So I really think if it's time for a flogging, Kilgray gets the first stripes on the back. But what's this about no view filtering? Will you please share what you are smoking? My shoulder hurts, and I could use the really good shit. There are so many view filtering options in memoQ that it can drive you crazy. I agree about autopropagation of numbers. Crap compared to DVX and possibly Studio, for now at least.
Delete@Jerzy, just in case you did miss it again, please note that this article shows you how to create plain vanilla XLIFF, as you like to call it, straight from the Save dialog of memoQ 6. So it remains possible just as before, the options are merely arranged in an admittedly confusing way.
DeleteCount me in as part of the half of the world that was confused by the way this change in XLIFF handling was "communicated by our Hungarian friends in the interface" (um, not at all?). While I can understand Kilgray's reasoning here in changing the file format, I would think it would be *very* helpful to to include a line of instructions right on the XLIFF export dialog describing, very briefly, the steps to take for generating a plain vanilla XLIFF file so users don't keep unwittingly sending off the default files produced to clients who can't open them. "Uncheck all boxes and rename the file extension to .xlf in the 'Save' dialog" is fine once you know about it, but this is the first time I've seen this clearly explained - 6 months after the fact!
ReplyDeleteInteresting post, Kevin. As always!
ReplyDeleteFor those who are in the need of looking up the language code of a specific language for Trados (that is "de-DE" for "German-Germany"), one of the most comprehensive overviews can be found in Microsoft's Go-Global Developer Center in the Microsoft Windows National Language Support (NLS) API Reference. The codes listed here, are the codes used in Trados:
http://msdn.microsoft.com/de-de/goglobal/bb896001.aspx
There you will find more or less all you will ever need for identifying a language, listing the following for each language:
- LCID
- Culture Name
- Language Country/Region
- Language Name
- Local language name
- ANSI codepage
- OEM codepage
- Country or Region name abbreviation
- Language name abbreviation
If you should ever be in the need to find the ISO 639-3 code for, let's say, Pennsylvania German (WHAT?!?), check out this:
http://www-01.sil.org/iso639-3/codes.asp?order=639_3&letter=%25