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:

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: Exporting TMX from memoQ

Translators are often asked to export translation memory data (TMX files typically) to deliver with their work. Although this is fairly simple to do in memoQ, too often more than just the required data is sent by mistake.

Select the TM from which to export via Tools > Resource Console... > Translation memories or Project home > Translation memories.

Click Export to TMX to export all the data in the chosen TM.

If a selective export (just some of the data in the TM) is desired, click Edit, enter the filter criteria in the dialog that appears and click OK. It is also possible to filter in the editor view. Only the data shown will be included in the TMX file created.

The memoQ TM editor with filtered records shown. Click to enlarge.

Here is a "video tour" of the process:


Ten brownie points to anyone who can figure out where I "cheated" with the translation information shown in the video.

Exporting from an SDL Trados Studio package project in memoQ

In memoQ 6.2 and later versions, Kilgray has enabled the import of SDL Trados Studio project packages, SDLPPX files, for translation in memoQ. A wizard automatically creates a memoQ project from the SDL package, and TM information which is included is transferred to a memoQ TM. Other information, such as MultiTerm terminologies, analysis files and QA instructions are not included, however. So this solution is not suitable for every case.

However, it is more than adequate to handle the dozen or so SDLPPX files I've been given to translate myself so far. Most of my clients do not use very many of the features in SDL Trados Studio, so typically files to translate and a translation memory are all they try to send to me. If there is more, I can always use my licensed copy of the SDL software as an intermediate stage.

However, once a project package has been imported to memoQ and translated, there is sometimes trouble with the return package. Typically, some files in a multi-file project are "forgotton".

To include all files in the SDL Trados Studio return package, you must select all of them, and then click Export (stored path). This will create the SDLRPX file in the same folder from which you imported the SDLPPX file. Only selected files will be included in the package.

The other option for exporting project files is Export (dialog). This will export individual SDLXLIFF files for the translation documents in the memoQ project.

Here is a short video on YouTube showing this process:

A new look for MultiTerm XML data in memoQ & Trados

Recently I got back to testing suggestions made last year for improving the quality and usability of terminology data from memoQ and Trados MultiTerm. With a bit of a refresher for rusty XSLT skills and brilliant help with sorting challenges from Stefan Gentz of Tracom, things are now looking quite promising. Here's a first look at early results for HTML conversions of term data in MultiTerm XML format:

This approach, perhaps including other useful conversions, will be included in the chapter on "possibly useful scripts and macros" in the tutorial guide memoQ 6 in Quick Steps, which will be released very soon with over 200 pages of productivity suggestions for the latest version of Kilgray's desktop technology.

Fun with the memoQ 6 Client API!

The release of Build 55 of memoQ version 6 included a client application programming interface (API) for the first time. It is currently available only in the project manager edition of memoQ, which is really a shame, but I look at this as a good start nonetheless. I have wanted this API for years, and a mere 6 months before it was released Kilgray's chief developer swore that it would never happen, because the work involved was monumental and the effort had no perceived payoff. Well, events unanticipated on that cold February night in Budapest changed that perception, and this is an excellent start for a great tool that was never supposed to happen. The current scope is pretty much limited to project preparation, analysis and TM manipulation, but even there much can be found to simplify the lives of some translators and corporate users with automation.

A simple snippet of script code for exporting a TM to TMX has been circulating for a while now as a VBA macro to run from Microsoft Word, for example. Personally, I object to running something in MS Word that has nothing to do with that program, so I recoded it as an executable script and added a few extra tweaks:

tmFolder = InputBox("Which TM should be exported?")
if tmFolder <> "" then

' The path where all my memoQ TMs are stored
standardTMpath = "C:\ProgramData\MemoQ\Translation Memories\"

'build absolute paths
outputTMXfile =  ".\" & tmFolder & "_" & date() & ".tmx"
tmFolder = standardTMpath & tmFolder

Set fact = CreateObject("MemoQ.ClientService.ServiceFactoryScripting")
Set tmService = fact.CreateTMService
Set createTMRes = tmService.ExportToTMX(tmFolder, outputTMXfile)
if createTMRes.Success = False then
   MsgBox createTMRes.ShortErrorMessage
else
   MsgBox "The TM was exported."
end if

end if

Just copy that script into a text file, rename the extension to *.vbs and you have a double-clickable script to export a TM without opening memoQ. The TMX export is placed in the same folder where the script is executed and tagged with the date of the export.

Encouraged by this little test, I went on to tackle one of my pet peeves: the lack of muliti-file import capabilities in memoQ TMs. Trados Studio has no problem importing a folder full of TMX files to a TM in one go, but with memoQ one must import each TMX file - painfully - one at a time. The pain is felt quite severely if, for example, you are a former OmegaT user with a legacy of 300+ TMX files from your old projects.

So I wrote another little script which allows me to drag and drop any number of TMX files onto its icon and have them all import to the specified TM. This is a rather crude example for just one set of had-coded sublanguages (DE-DE and EN-US). The API currently does not allow sublanguages to be ignored for the import. Adapt this to use your relevant sublanguages if you like:

'
' memoQ TMX import macro
' drag & drop TMX files onto the script icon
'
tmFolder = InputBox("To which TM should the TMX file(s) be imported?")
If tmFolder <> "" Then

' The path where all my memoQ TMs are stored
standardTMpath = "E:\Working databases\MemoQ\TMs\"

'build absolute path
tmFolder = standardTMpath & tmFolder

' Create the ServiceFactoryScripting object and TM service
Set objSFS = CreateObject("MemoQ.ClientService.ServiceFactoryScripting")
Set svcTM = objSFS.CreateTMService

' Set import options parameters
Set objImportOptions = CreateObject("MemoQ.ClientService.TMImportOptionsScripting")
objImportOptions.TMXSourceLanguageCode = "ger-de" 
objImportOptions.TMXTargetLanguageCode = "eng-us"  
objImportOptions.TradosImportOptimization = False
objImportOptions.DefaultValues = Null
objImportOptions.DefaultsOverrideInput = False

  Set objArgs = WScript.Arguments
  For I = 0 To objArgs.Count - 1
    tmxfile = objArgs(I)
    logFileName = tmFolder & "_" & date() & "_" & "importlog." & I & ".txt"

    Set returnvalue = svcTM.ImportFromTMX(tmFolder, tmxfile, objImportOptions, logFileName)
    If returnvalue.Success = False Then
        MsgBox returnvalue.ShortErrorMessage
    Else
        MsgBox "No errors in the import of " & tmxfile & ". See the log file at: " & logFileName
    End If
  Next

end if

Since I once wasted a full day importing a big load of TMX files to memoQ (before I got the bright idea to use The Other Tool as an intermediate step), I was so delighted to get this script working that I just kept making new test TMs and running it long past the point where there was anything left to prove. It's just a thrill to know that consolidating my TMs is now much, much simpler!

These are just a few of the myriad simplifications that are possible for one's processes with the new API. I expect most of its applications will be in "real" programs with real programmers using "real" languages and not wimpy, half-baked scripts like I've thrown together and shown here. This API has potential benefits to a great number of ordinary memoQ users, I think - especially if little productivity tips like these here are shared. So I do hope that, at some point, access to the client API is expanded to include the memoQ Translator Pro edition!