Terminology output management with SDL MultiTerm

I have always liked SDL MultiTerm Desktop - since long before it was an SDL product, back when it came as part of the package with my Trados Workbench version 3 license.

Then, as now, Trados sucked as a working tool, so I soon switched to Atril's Déja Vu for my translation work, and after 8 or 9 years to memoQ, but MultiTerm has continued to be an important working tool for my language service business. I extract and manage my terminology with memoQ for the most part, but when I want a high-quality format for sharing terminology with my clients' various departments, there is currently no reasonable alternative to MultiTerm for producing good dictionary-style output.

Terminology can be exported from whatever working environment you maintain it in, and then transferred to a MultiTerm termbase using MultiTerm Convert or other tools. In the case of memoQ, there is an option to output terms directly to "MultiTerm XML" format:

Fairly simple; there are no options to configure. Just select the radio button for the MultiTerm export format at the top of any memoQ term export dialog. And what do you get?

Three files: the XML file with the actual term data and the XDT file with the termbase specifications are the important ones. The latter is used to create the termbase in SDL MultiTerm. If you have an existing termbase to use in MultiTerm, you won't need the XDT file, though if that termbase is not based on Kilgray's XDT file there might be some mapping complications for the term inport from the XML file.

Now let's create a termbase in SDL MultiTerm 2017 Desktop:

Give it a name:

When the termbase wizard starts, choose the option to load an existing termbase definition and select the XDT file created by memoQ:

At the end of the process you will have an empty Multiterm termbase into which the data in the XML file are imported:

Now you'll have an SDL Multiterm termbase with the glossary content exported from memoQ. This is a process which can be carried out when sharing terminology with a colleague who uses SDL Trados Studio for translation, for example. If they don't know how to use the import functions of SDL Multiterm or you want to save them the bother of doing so, just share the SDLTB file.

Now that the glossary is in Multiterm it can be exported in various formats which can be helpful to people who prefer the data in a more generally accessible format. Please note that this is not done using the export functions under the File menu! SDL Multiterm is a program originally developed by German programmers, who have their own Konzept of Benutzerfreundlichkeit. Even in the hands of Romanian developers, it's still kinda weird. The desired functions are found in the Termbase Management area of course:

In keeping with the German Benutzerfreundlichkeitskonzept, the command to generate the desired output is Process, of course.

There are a number of pre-defined output templates included with Multiterm. I usually use a version of the "Word Dictionary" export definition, which produces a two-column RTF file, which by default will give output like this:

I prefer something a little different, so I have prepared various improved versions of this output definition, and I usually edit the text, adjust the column breaks as needed and clean up any garbage (like redundant initial letters caused by inflected vowels in a language like Portuguese), then I slap a cover page on the file and make a PDF out of it or create a nice printed copy, possibly with other page size formatting. Here is an example:

Example PDF dictionary output - click to enlarge

Other possible output formats include HTML, which can be useful for term access on an intranet, for example. Custom definitions can be created by cloning and editing an existing definition; these are specific to a given termbase. If you want to apply a custom export definition to another termbase, export it as an XDX file and then load it for the other termbase. The definition file used to generate the example above is available here.

One essential weakness of the SDL export definition which has always annoyed me is the failure to include the last word on the page in the header as most proper dictionaries do. I addressed this in the definition with my limited knowledge of RTF coding, but the change can be made manually in Microsoft Word too, for example, by copying and pasting the SortTerm field and editing it to add the \l argument:

There are, of course other, possibly better ways to get some nice output formats from memoQ glossaries or termbases in other tools. One approach with memoQ is to create XSL scripts to process the MultiTerm XML output from memoQ. For years I have been hoping that Kilgray would create a simple extension to the term export dialog in memoQ, which would allow XSL scripts to be chosen and a transformation applied when the data are exported. It really is a shame that after more than a decade the best translation environment tool available - memoQ - still cannot match the excellent formatted output that my clients and I have enjoyed with MultiTerm since I first started using that program 17 years ago!

Translation alignment: the memoQ advantage

The basic features for aligning translated texts in memoQ are straightforward and can be learned easily from Kilgray documentation such as the guides or memoQ Help. However, there are three aspects of alignment in memoQ which I think are worth particular attention and which distinguish it in important ways from alignments performed with other translation environment tools or aligners.

Aligning the content of two folders with source and target documents; automatic pairing by name

The first is memoQ’s ability to determine alignment pairs automatically based on the similarity of names. This has the advantage, for example, that large numbers of files can be aligned automatically, with the source and target documents matched based upon the filenames. This can be done with individual files or with entire folders with perhaps hundreds of files. Thus if source files are contained in one folder and the translated files in the target language are in a different folder and the source and target file names are similar, the alignment process for a great number of files can be set up and run in a matter of minutes. Note in the example screenshot above that different file types may be aligned with each other.

The second important difference with alignment in memoQ is that it is really not necessary to feed the aligned content to a translation memory. memoQ LiveDocs alignments essentially function as a translation memory in the LiveDocs corpus, with one important difference: by right-clicking matches in the translation results pane or a concordance hit list, the aligned document can be opened directly and the full context of the content match can be read. A match or concordance hit found in a traditional translation memory is an isolated segment, divorced from its original context, which can be critical to understanding that translated segment. LiveDocs overcomes this problem.

A third advantage of alignment in memoQ is that, unlike environments in which aligned content can only be used after it is fed to a translation memory, a great deal of time can be saved by not “improving” the alignment unless its content has been determined to be relevant to a new source text for translation. If an analysis shows that there are significant matches to be found in a crude/bulk alignment, the specific relevant alignments can be determined and the contents of these finalized while leaving irrelevant aligned documents in an unimproved state. Should these unimproved alignments in fact contain relevant vocabulary for concordance searches, and if a concordance hit from them appears to be misaligned, opening the document via the context menu usually reveals the desired target text in a nearby segment.

Concordance lookup in memoQ with direct access to an aligned document in a LiveDocs corpus

Troubleshooting memoQ light resource import problems

The other day I sent a friend some updated auto-translation rules for currency expressions; a short time later I received a message that they would not import into memoQ. The error message displayed was the following:

Now the problem here might seem obvious, but the name of the file I sent was nothing like any rule she already had installed,

In the example shown below, the source of the trouble is more obvious, but if there are a lot of resources in the list shown in the Resource Console or elsewhere, the redundancy of the name in the import dialog and an existing resource name in the list might not stand out so clearly....

In the MQRES file (for the memoQ light resource), the "trouble  spot" is in the XML header at the top of the file. This can be seen by opening it in any text editor (in this case I used Notepad++ to show line numbering);

In this case, the fifth line contains the name that will be applied to the resource after it is imported. The <Name> tags are found in all kinds of memoQ light resources, and the same problem will occur if a redundancy is found during import. Here is an example from a memoQ ignore list (used to exclude certain words from error indications by spellchecking functions):

There are a couple of ways to avoid or correct these problems:

• First of all, when a ruleset is edited, the text enclosed by the Name tags should be altered. It's probably a good idea to update the Description as well. The FileName  is actually ignored and need not be updated; a difference with the real name of the MQRES file will not cause any trouble with an import.
  
• When importing a light resource, you can always change the information read from the Name and Description tags of the MQRES file. This avoids the conflict.
  
            
    
• The name and description of an existing light resource can be edited via the Properties of the resource in the Resource Console or Project Home > Settings, Accessing the resource via memoQ Options will currently (as of version 8.1) not show the Properties.
  
             

memoQ's "light resources" - the portable configurations and information lists to assist various translation tasks - are one of the environment's greatest strengths, but the generally bad state of the associated editing tools and unhelpful error handling continue to cause a lot of unnecessary confusion among users. Key people at Kilgray are not unaware of this problem, and for years there has been a debate regarding new features versus actual usability of the features already present. When you encounter difficulties like the one described above - or other troubles using this generally excellent, leading translation assistance tool - it is important to communicate your concerns to Kilgray Support (support@kilgray.com). 

Without appropriate feedback from the wordface, there is often really no way for the designers and product engineers to understand and prioritize the challenges of usability. I can understand the reluctance of those who have used other tools for many years, where it was clear that their requests for bug fixes or other improvements were largely ignored, to take such action, but it really does make a difference, though not always on a time scale of hours or days. Weeks, months, sometimes years may pass before important changes are made, but usually this is because the urgency of the matter has not been communicated with sufficient clarity, or there are in fact, more pressing matters which require attention. But in fact no serious matters are seldom ignored by those responsible, as nine years as a satisfied user have shown me.