Exporting compatible XLIFF (XLF) bilingual files from memoQ

Here we go again. Although memoQ is the undisputed leader for compatibility and interoperability among translation environment tools, users still encounter problems exchanging files, particularly XLIFF of some sort, with users of other tools. This is not because of any actual difficulty producing compatible XLIFF files, but rather a matter of deficient tool training and the failure to date by memoQ product designers to make the ease of interoperability a little more obvious. Some other tools, like recent versions of SDL Trados Studio, come pre-configured on installation to recognize the proprietary file extensions for memoQ's flavor of XLIFF ("MQXLIFF") and renamed ZIP packages (MQXLZ) containing XLIFF files, but others (or versions of SDL Trados Studio from many years ago) need to be configured to recognize those extensions, or someone simply has to change the MQXLIFF file extension to an extension that will be recognized by any tool: *.xliff or *.xlf are the choices.

The two-step solution is shown here:

On the Documents ribbon in memoQ, click on the tiny arrow under the Export icon and choose the option to export a bilingual file. There is some blue text which, if clicked, will allow a compatible XLIFF file to be exported, albeit with the MQXLIFF extension that some other programs might not recognize.

When the Export button in the dialog (marked 1, above) is clicked, the Save As dialog (marked 2, above) appears, simply change the file extension (the part after the period) to "xlf", for example. Then any program that reads XLIFF files can work with the file you export from memoQ. Despite the change of extension, memoQ will still recognize the file it produced, so it is possible to re-import it, for example if another person has made corrections to the XLIFF file that you want to use to update your translation or reference resources.

In some much older versions of memoQ, it does not work to change the extension in the export dialog; this has to be done directly to the exported file in whatever folder you save it in.

Of course, all of this will be rather difficult if you are one of those users who has not fixed the awful Microsoft Windows default to hide the extensions of known file types. Fixing that particular stupidity requires slightly different measures in different versions of Windows, but in Windows 10 you can do that on the View ribbon of Windows Explorer by marking the choice to show file name extensions:

Getting around language variant issues in memoQ LiveDocs

I was told by some other users that a fundamental change had been made in the way language data are accessed in LiveDocs. It was said that until a few versions ago it had been possible to use documents for reference in LiveDocs regardless of their sublanguage settings. So I was told. The truth is more complicated than that.

According to my tests, memoQ 2015 is the first version of memoQ to have a logically consistent treatment of language variants for both bilingual and monolingual documents in corpora. All the other versions tested (memoQ 2013R2, 2014, 2014R2) are equally screwed up and show the same results.

The "visibility" of a monolingual or bilingual document when viewed in a corpus attached to a project running under memoQ 2015 follows these rules:

• the sublanguage (language variant) settings for source and target (of the document or the project) must match the project
• or the language setting (of the document or the project) must be generic. 

Two rules. Pretty simple. It doesn't matter what version of memoQ the project or corpus was created in, only which version is actively running.

I created a test corpus with the following document mix:

The corpus contained 11 documents, both bilingual and monolingual with a mix of generic language settings and settings with language variants specified (such as German for Germany, Switzerland and Liechtenstein and English for Zimbabwe, the US and UK). 

In a project running under memoQ 2015 with the languages set to generic German and generic English, all 11 documents in the corpus were accessible. 

So if you want access to all LiveDocs corpus data for the major languages of your project, it is necessary to use generic language settings, either when you load the data into LiveDocs (difficult unless you always use the resource console, since adding documents to a corpus from within a project automatically applies the project's language settings!) or in the languages specified for the project itself. And this will only work with memoQ 2015. If you want to apply penalties to particular language variants this can be done using keyword markers (as seen in the screenshot above) and configuring the More penalties tab of the LiveDocs settings file applied to that corpus.

If the same corpus is attached to a project running under memoQ 2015 with language settings for Swiss German and generic English, the documents available from the corpus are these:

For a Swiss German and UK English project under memoQ 2015, this is the picture:

And for a Germany's German and US English:

 All the screenshots above can be predicted based on the two rules stated. Work it out.

"But what happens with earlier versions of memoQ?" you might wonder. It's messy. Here is a look at a Swiss German and UK English project under memoQ 2013 R2, 2014 and 2014 R2: 

And here's a project with generic German and Generic English under memoQ 2013 R2, 2014 and 2014 R2:

In each case the five bilingual documents are visible no matter what the project's language settings are. However, there is strict adherence to language variants and the generic language setting for monolingual documents! In my opinion, that's for the birds. I see no good reason to follow a different rule for data availability in bilingual versus monolingual documents. So in a sense, Kilgray has cleaned up this inconsistency in the latest version of memoQ.

Some have expressed a desire for a "switch" setting to allow language variant settings to be ignored. And perhaps Kilgray will provide such a feature in the future. But the best way to get there now is simply to make your project's language settings generic.

Changing the language settings for bilingual data in an existing LiveDocs corpus 

If you have a corpus with a mix of language settings and you want to convert these to generic settings or a particular variant, this can be done as follows currently only for bilingual documents:

1. Select the bilingual documents to export from the corpus and export them to a folder. (If you choose to zip them all together, unpack the *.zip file later to make a folder of the exported *.mqxlz files.
2. Re-import the *.mqxlz files to the LiveDocs corpus via the Resource Console so you are able to specify the exact language settings you want. In the import dialog, you'll have to change the filter setting manually from "binary" to "XLIFF". These *.mqxlz files are not the same as bilingual files from a translation document in a project and are not recognized automatically.

Unfortunately, there is no way to change the language settings of a monolingual document except to re-import it in the Resource Console in its original form and set the language variant (or generic value) there.

So really, for now, the best way to go seems to be to use memoQ 2015 with generic project language settings.

Proofreading LiveDocs bilinguals, recycling versions in memoQ

(These tests were performed with memoQ 2013 R2 but should, in principle, work the same in any version of memoQ 6.0 or later.)

I really like memoQ's versioning features, and I use the X-Translate function fairly often when a document I'm translating has been updated or a new version comes sometime later. However, I don't keep documents in my projects forever. I use "container projects" for particular clients or subject domains so that I don't have to keep reattaching the same translation memories, terminologies and LiveDocs corpora and various light resources (non-translatables, autocorrect lists, segmentation rules, etc.) all the time. These can get rather full, so I send my old translations off to a LiveDocs corpus after a while. And then if a new version of a document shows up, well... I'm sort of out of luck if I want to use the X-Translate function with the previous version.

Or so I thought. And then a friend rang me and asked how she can export a LiveDocs alignment she did to an RTF bilingual file to make it more convenient to proofread in Microsoft Word and pass on to one of her partners with tracked changes. With that the answer to both problems was clear.

Select the corpus and the file in it to export:

Click Export and choose a location in which to save the MQXLZ file:

In the Translations window of any memoQ project with the correct source and target language settings, select Import and choose your MQXLZ file:

After the file exported from LiveDocs has been imported as a translation file, it can serve as "version 1" for a new file version to be translated using the Reimport document and X-translate features. It does not matter that the file types are different. A bilingual RTF file can also be exported for external correction and commentary.

Here is an example of an exported bilingual RTF file with changes tracked. The changes do not have to be accepted before the bilingual file is re-imported to update the translation using the Import command.

Here is the updated translation:

Changed are marked with blue arrows. Only text changes were implemented in this case, no format changes such as italic text, because the XLIFF file does not support WYSIWYG text formatting. (MQXLZ is a Kilgray-renamed ZIP-package with XLIFF and a chocolate surprise inside.)

Now I've got a new version of my text to translate in a DOCX file. I use the Reimport document function, answer No to the dialog so I can select the new version at a different location:

I'm curious what the differences from the original text are, so I use the History/reports command in the Translations window to find that out:

Then using Operations > X-Translate in the working window, followed by pretranslation to get the changed "exact matches" (like "Aussehen und Gewicht" above) and the fuzzy matches, I end up with this:

If you make it a point to store your important versions in a LiveDocs corpus, this procedure will allow you to recover your archived texts and re-use them for more controlled, reference-based translation. It would be nice, of course, if some day Kilgray would enable specific LiveDocs files to be used as the basis of a reference translation, perhaps even scanning a corpus or a set of corpora to identify the best-matching document or documents. It would also be nice if bilinguals stored in LiveDocs could be exported to other formats and perhaps even be updated with something like an exported bilingual RTF. However, those bilinguals can simply be imported directly to a LiveDocs corpus as new documents, and any corrections made to a document in the Translations list can be sent back to LiveDocs using the relevant command in the Translations window.

memoQuickie: "compatible" XLIFF in memoQ 6, 6.2 and 2013

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: