The 2013 translation environment tools survey

From mid-October until the end of 2013, I placed two small survey questions at the top of the blog page and publicized these in a variety of user forums. The questions were similar to two posed in 2010, because I was interested to see how things might have changed. This is, of course, an informal survey with a number of points in its "methodology" wide open to criticism, though its results are certainly more reliable than anything one can expect from the Common Sense Advisory :-) My personal interest here was to get an idea of the background readers here might have with various translation environment tools, because it is useful to know this when preparing posts on various subjects. Here is a quick graphic comparison of the 2010 and 2013 results:

Responses to the question about the number of translation environment tools were very similar in both cases. About half use only one, with between 25 and 30% of respondents using a second tool and increasingly small numbers going beyond that. The question posed covered preparation, translation and checking in projects, so some respondents using multiple tools may be translating and maintaining terminologies and translation memories in only one tool. I am encouraged by this result, as it means that despite changes in the distribution of particular tools, users are exercising good ergonomic sense and predominantly sticking to one for their main work. Everyone benefits from this: translators generally work more efficiently without tool hopping, and more effort is focused on what clients need - a good translation.

In 2010, half the respondents cited the use of some version of "SDL Trados" (more details on this were provided in a later survey); the next highest responses at just under 20% were for Déjà Vu and memoQ. Three and a half years later, Atril's share of users appears to have declined considerably, and the use of memoQ appears to be about on par with SDL Trados Studio. OmegaT, an excellent free and Open Source translation support tool capable of working with translation formats from the leading tools, appears to be doing better than many of the commercial tools in the survey, which should not surprise anyone familiar with that software.

Across continues to be a loser in every way. Despite massive efforts in the low end of the market to promote this incompatible Teutonic travesty and the availability of the client software free of charge to its victims (translators), no real progress has been made in the Drang nach Marktanteil. One would expect that a good solution supported by a competent professional development team and a marketing budget, available free to translators, would easily beat the low-profile OmegaT. And I am sure that this is the case. The case simply doesn't apply to Across, which drives some of the most technically competent translators I know completely berserk. The fact that OmegaT is about twice as popular despite its volunteer development and total lack of marketing budget speaks volumes.

More important than any of the individual figures for translation support tools are some of the implications for interoperable workflows that the numbers reveal. Most of the tools listed support XLIFF, so if you use a tool capable of exporting and reimporting translation content as XLIFF, developing an interoperable workflow for translation and review that will work with the majority of tools will probably not be that difficult. An XLIFF file from SDL Trados Studio or memoQ is usually a no-brainer for translation in Déjá Vu, OmegaT, Cafetran or Fluency, for example, and any concerns can be checked quickly with a "roundtrip test" using pseudotranslation or simply copying the source text to the target, for example.

While individual tools have largely improved in their mutual compatibility and ability to share translation and resource data, there is legitimate continuing concern about the increased use of translation servers by translation agencies and corporations with volume needs who manage their own translation processes. Jost Zetsche and I have expressed concerns in the past regarding the lack of compatibility between server platforms and various clients, though with the appropriate use of exchange formats, this can still be overcome.

The greatest challenges I have seen with server-based work is that the people creating and "managing" projects on these servers often lack a basic understanding of the processes involved, so that the skills of the translators competent with a particular client tool may be effectively nullified by an incompetently prepared job. I experienced this myself recently where segmentation, termbase rights and even the source language were set wrong on the server, and the project manager had no idea how to correct the situation. However, things worked out in the end, because I had a playbook of strategies to apply for such a case. In the end, better training and a good understanding of the interfaces to the processes our partners use can get us past most problems.

Translating embedded objects in Microsoft Office documents

Yesterday a colleague sent me a note to say he had been searching my blog for information about translating compound Microsoft Office documents (that is documents with embedded objects) in memoQ and couldn't find any. I presume he was referring to the article about how often one CAT tool is not enough - combined workflows with other tools can frequently help solve many tricky translation problems, and DVX2 or STAR TRANSIT are definitely useful options for preparing compound Microsoft Office documents for translation in memoQ. Some time ago I recommended using STAR TRANSIT as a pre-processing tool to one of my agency friends, and he carried out a very large, complex project successfully using memoQ's excellent integration features for STAR TRANSIT projects.

There is, of course, another simple way to translate the embedded objects in a Microsoft Office document that does not involve purchasing other software licenses. I don't usually talk about it, because there are a few limitations, and until recently I had not figured out how to avoid corrupting the files when I tried to do things the "easy" way. This approach is not limited to memoQ and will actually work with most CAT tools - so SDL Trados Studio users can do this as well, for example.

It is useful to know that the Microsoft Office 2007/2010 file formats (DOCX, PPTX, XLSX) are really just ZIP files containing XML and a bunch of other stuff. That stuff includes a folder with the embedded objects in formats that can be dealt with directly.

If you have an older, binary MS Office document (DOC, PPT, XLS) with embedded objects, convert it to a 2007/2010 format.

If you rename the file extension DOCX, PPTX or XSLX to ZIP and unpack the ZIP file, inside the folder you will find a folder called "embeddings". The files in that folder can be copied elsewhere and usually handled directly in your CAT tool. But problems usually arise when you put them back, rezip the folder and change back to the original extension. The compression gets screwed up, and the Microsoft Office file is corrupted and won't open.

The only reliable method I have found for avoiding this is to use the Windows Explorer (under Windows 7) to open the ZIP file:

Here's what the "guts" of one DOCX file with a bunch of embedded Excel tables looks like:

Inside the word folder you'll find the embeddings folder:

The contents of the embeddings folder look like this:

Simply copy the embeddings folder somewhere safe, translate its contents, then copy them back to the ZIP file using Windows Explorer. Then rename the ZIP extension to the original extension for the file.

If you open the file and look at it, you'll get a shock. When you see all the objects in their original language, you might think something went wrong. Nothing bad has happened; you merely need to refresh the objects. This can be done by opening each briefly to edit or using a macro to open each object and close it again quickly. In a job with dozens of embedded objects in a long file, this macro is a helpful shortcut.

Given how easily accessible this embedded content actually is, one has to wonder why other major CAT tool providers like SDL and Kilgray have failed to offer the option of importing embedded content in their filters up to now. Let's hope they do soon. In the meantime, this workaround should enable many people to deal with this complex and irritating file format challenge.

Here's a summary of the procedure once again:

1. Rename the *.???x file to *.zip 
2. Under Windows 7, right-click on the ZIP file and open it using the Windows Explorer. Using ZIP tools of any kind risks corruption by changing the compression ratios. 
3. Find the embeddings folder inside the ZIP structure. Copy this elsewhere and use it as the source for translation. It will contain all the embedded objects as single files. 
4. Copy the translated content back into the embeddings folder in the ZIP structure.
5. Rename the ZIP file to its original extension. 
6. Open the file and refresh each embedded object (which will initially appear not to have been translated) by right-clicking and opening it from the context menu or running a macro to do that.

Sometimes one CAT tool is not enough

Not long ago, a colleague in New Zealand expressed her frustration about the limits of interoperability for common translation environment tools and her sense of unfulfilled promises:

In the case she was concerned with, she was quite right. There are workarounds for complex MS Word documents with footnotes, but none of these are really optimal for a team working simultaneously in several different CAT tools. In the case of memoQ 5 (which was part of the mix) the lack of support for footnotes in RTF/DOC bilinguals made it impossible to review an uncleaned translation done in WordFast Classic (not a problem for simpler files), and the use of a bilingual DOC export from memoQ used the "simple" format of one segment per line, thus losing the format for the working translator. I hope that will be dealt with in time by Kilgray's developers.

But fortunately, interoperability really does work - it is "the art of compromise" as one industry guru put it, but there are many acceptable compromise strategies that allow productive collaboration, and memoQ excels in this regard more than any other tool I know. But as I have said so often, we need a broad palette of tools to enable us to handle any job efficiently, and last week's project here was a good example of this.

No good deed goes unpunished, and my punishment for an almost miraculous rescue of the editing and harmonization of a large, complex financial report done in a hurry by several translators, some of whom don't use CAT tools at all, was that I got to do the update of that text and see all the little stuff we missed the first time around when the client CEO and I traded sleep for coffee and Excel spreadsheets. Actually, I loved that job, and I was proud of what we could accomplish in 48 hours that should have taken a week or more of overtime. All of it possible only thanks to memoQ LiveDocs and the QA module. And lots and lots of coffee.

In this round, however, I was determined to avoid some of the pain caused last time by file format problem. The Notes to the annual report contained about 30 embedded Excel tables in a Word document. "So what?" says the user of Star Transit or DVX2. "Uh oh!" say the Trados and memoQ users. This is where interoperability saved me hours of bother.

I'm no longer comfortable doing routine work in my former preferred tool, Déjà Vu. The working environment of memoQ is more ergonomic for me, and although I still miss a number of very useful features in DVX, on the balance, the features I gained in memoQ allow me to do many more things better (or even at all). Nonetheless, this time Atril had the clear advantage.

I translated the main text of the Notes in memoQ, making full use of my translation memories, glossaries and QA settings there. I enjoyed the previews of the embedded Excel documents, which gave me necessary context for some of my work, but the actual content of those tables was untouchable in memoQ. Then I exported the translation, which was an English document with embedded tables in German.

This compound document was then imported to DVX2 together with my TM. I copied the source to target, locked all the English content (it was helpful that the content extracted from the Excel tables was at the end of the translation scroll) and pretranslated what remained from the TM. Less than an hour later I exported the completely finished translation - and saved a lot of fiddly work exporting and importing those stupid tables like I had to do before. I really do hope that memoQ's filters for MS Office documents will be updated to handle embedded objects soon - it's not uncommon that I have Excel, Visio or PowerPoint objects stuck in my Word documents.

After delivering the text, I then turned to the next task: exporting my terminology. Once again, interoperability came to my rescue here. This customer places a lot of importance on the correct use of IFRS and their own terminology. One of the ways we coordinate this is to exchange glossary information in a format that this customer, who doesn't know a CAT tool from a Persian feline, can cope with. A nicely formatted DOCX or PDF dictionary does the trick. But I can't do that with memoQ.

I've been advocating the addition of XSL script selection to memoQ's XML term export for some time now. My own efforts to create good scripts for my purposes are hampered by the fact that I haven't done much programming for a decade now and I've lost most of my skills. So until I sort that problem out, I take the terms in XML from memoQ and import them to SDL Trados MultiTerm. MultiTerm is unique among the terminology tools on the low end of the market in that it has always offered some useful export format templates (which can be adapted) for re-use of the term information in other environments. Formatted RTF dictionaries like the one shown here as a thumbnail, web pages, custom text exports... the sky's the limit if you can deal with the odd configuration options and unexpected crashes. Having traversed that minefield often enough in the past decade, I can usually produce something good-looking from my memoQ terminology with SDL Trados MultiTerm without much ado. And my clients like it a lot more than an ugly CSV export.

So why didn't I just use Déjà Vu or Trados in the first place? Re-read the text above. None of the three CAT tools I use was capable of doing everything I required as efficiently as I needed it done. DVX2 came the closest, but the lack of a preview, the primitive way that tags (codes) are still managed and the lack of comfort I feel translating in that environment (I'm much slower now) made it a poor option for the bulk of the work. But working in carefully planned concert, these three tools produced excellent results, made my client happy and made me happy by saving the rest of my day with an early delivery.

Translation tool concordances compared

A recent experience when tutoring a new memoQ user started me thinking about the way concordance searches work in various translation environment tools and how the results are displayed. The user, who was quite experienced with OmegaT, kept telling me that memoQ could not find examples of a term's use in the TM and she had to do all her searches in OmegaT. I was somewhat puzzled by that, and when I looked at her screen with the memoQ concordance dialog, I saw something like this:

The memoQ version 5 concordance dialog

Looks like the term ("Inverkehrbringen") was found. So what was the problem? For years she had looked at this concordance view:

The OmegaT concordance dialog

The differences in layout and the lack of highlighting of the key term (which was aligned in the center of the memoQ concordance window in the ancient KWIC display tradition) were unexpected and confusing to the new user.

This inspired me to have a look at how various other tools display concordance results. I was not very happy with some of what I discovered, especially with some of today's leading commercial tools. I took a look at the TWB translation memories in SDL Trados 2007, concordancing in SDL Trados Studio 2009, Wordfast Pro (very limited test due to a demo license and my inability to load my TMX test data), memoQ and OmegaT.

In terms of overall performance, the best results were obtained with OmegaT and "Trados Classic" (2007). Searching a huge TM gave results in a flash. Concordance searches with SDL Trados Studio 2009, on the other hand, really sucked with a big TM (EU data, about 400,000 TUs). I vacuumed my entire apartment and fed the dog while I waited for the result, and I wasn't even told how many hits were found. Unfortunately, my favorite working environment, memoQ, performed worst with the same big data set: it simply gave an error message. Further testing revealed that this error was due to the very large number of hits. (This would have been obvious had I paid enough attention to read the dialog title in the first place.)

memoQ error message from too many concordance hits

So it looks like some development attention may need to be directed here. (Update: Kilgray's develops are actively working to remove this restriction.) Of all the tools I was able to test with a large concordance, memoQ was the only one to fail this way. My personal TM with about 10 years of my work in it is nearly as long as my German/English EU legal test database, but concordance searches in it using memoQ are not unduly slow.

Other concordance views looked like this:

The concordance in SDL Trados 2007 - hits limited compared to OmegaT (see above)

SDL Trados 2009 - perhaps the easiest to read, but slower than molasses

Wordfast Pro - format not bad, but the test was limited due to the demo license

The Déjá Vu X concordance hasn't changed significantly in appearance in the latest version (DVX2). Once again, Victor Dewsbery was kind enough to provide me with screenshots of the two "scan" options for searching the translation memory. The initial scan produces only fairly close matches, while the "power scan" is more like the usual concordance with the term embedded in a larger body of text (the non-matching parts being crossed out)

DVX2 scan (first click)

DVX2 Power Scan (second click)

I do have a license for the older version of DVX, but I didn't attempt any stress testing. While its performance with large TMs has always been good (my personal "Big Mama" is about 330,000 TUs), import and export of such data volumes are painfully slow. We're talking overnight. I hope the new version is better in that respect. There I must really give kudos to the OmegaT developer: loading the TM was even faster than with Trados Workbench, which for me has always been a benchmark of speed to aspire to. All you have to do to add a TMX file to the TM of an OmegaT project is to drop it in the "TM" folder of the project. Very nice :-)

I also received a screenshot of a search in Transit NXT from colleague Hans Lenting in the Netherlands. He searched the term "Inverkehrbringen" in the German/Dutch EU dataset from the DGT:

STAR Transit NXT concordance search

As you can see, there are many ways to display data from a concordance search. Which do you find easiest to deal with? Personally, I love the insertion features of the memoQ concordance, but for readability I think some of the other tools are better. And I do like to know how many results I can expect from my data, and I might even want to view them all.

Converting MARTIF to Excel

This afternoon I received an interesting project of a sort I don't see often - Star Transit. I avoided these like the plague for years, because I dislike Transit as a working environment, though I expect the latest version is probably an improvement over what I used to use. However, since Kilgray created an excellent import routine for Transit packages (PXF files), working on these projects is quite a simple matter. Except for terminology. The memoQ integration currently does not include the Transit terminology.

The client was kind enough to supply MARTIF exports from the Transit dictionaries, but unfortunately that's not an import format for memoQ, though really it should not be that difficult to deal with that XML format (I hope). So I went on the search for a solution and soon discovered a PrAdZ thread in which Czech translator Antonín Otáhal offered a VBA macro for converting the MTF files (MARTIF) to Excel.

The solution works nicely, though in my tests I found it necessary to open the MTF files in Notepad and re-save them as ANSI so the special characters in German would not get trashed. And I hate typing a full file path into the selection dialog, so I modified the code to include a proper file selection dialog. If anyone else can use such a tool, I've made it available here as an XSLM file (a macro-enabled Excel worksheet for MS Office 2010). Improvements are very welcome; I've been out of the programming game too long now to refine this much without investing more time than it is worth to me.

Nonetheless, I'm quite pleased that I can now save a tab-delimited or CSV text file from Excel and import this easily into memoQ or other translation environments. So moving term data from Star Transit to other tools is now a little easier.

To use the tool

1. Make a copy of the Excel file
2. Open your working copy of the Excel file
3. Press Alt+F8 to bring up the list of macros
4. Select the macro "mtf2excel"
   
   
   
   
5. Click the Run button. A file selection dialog will appear, and if everything is OK with the encoding, your term data should appear shortly in the columns of the Excel sheet.

Has Kilgray jilted freelance translators?

The latest post on the Kilgray blog is a strange one, though not entirely unexpected. It's an attempt to answer recent criticism that the company cares more about its corporate clientele than freelance translators. I've heard concerns about this for some months now, though honestly more concerns from within Kilgray than from the world of translation at large. I take the fact that the company's board even worries about such things to be a sign of the basic health of its concern for freelancers. I mean, really, can you imagine the board members of SDL losing sleep over a few grumbling translators?

I've heard a lot of internal concerns from members of the Kilgray team that the many features which have been added to memoQ since I began using it a bit over two years ago have made it harder to have a full overview of everything the product can do. I would actually agree with that, but it doesn't worry me any more than the fact that I use perhaps 10% of Microsoft Word's functions: I focus on what I need and ignore the rest. I know it's there and if something becomes relevant to me later, I'll learn about it then. Like the Star Transit project import feature. I hadn't done Transit projects in years and gave them no thought any more until Monday when an old client called with an urgent request. So I spent 5 minutes learning to use that memoQ feature and made my rent and then some once again with a day's work in an unusually slow week. You tell me if that's ignoring the needs of a freelance translator.

Kilgray's pursuit of LSP and enterprise business has in reality been a godsend to its freelance translator base. As major clients like the German post office adopt memoQ technology, its perceived legitimacy and the legitimacy of those using memoQ increases among potential clients. Even freelance translators using Trados have benefited considerably from Kilgray's user support and innovative skills as SDL has been forced to clean up its act in many ways and make substantial improvements in its product and support due to competitive pressure not felt before.

Corporate sales underwrite development of features interesting to freelancers in a way that individual "pro" licenses never could, and that is a good thing. Just look at the disaster of Atril over most of the last decade as the product which was once the most versatile, innovative tool available to freelancers languished with almost no development for years, and many users truly expected the Second Coming before the release of DVX2, which finally came out several years after the announcement of its imminent release. Kilgray is innovating and adding features that are directly useful to me as a freelancer at a pace far beyond my ability to keep an overview. Without making memoQ any more complicated in my daily routine! If corporate money helped pay to develop that superb Transit compatibility feature or the bilingual RTF table output I use almost every day, then I can only be grateful to Kilgray for having the wisdom to seek balanced development of its business in all areas of translation service.

But are they ignoring freelance user support requests and giving all the attention to big-ticket customers? I don't think so. I hear time and again from friends with no personal acquaintance with the Kilgray team how quickly and competently their questions are answered. Sometimes there's a little back and forth before the issues are understood clearly, but that is normal in any human interface in any company or industry.

A quick look at September's schedule of TEN free webinars by Kilgray shows a good balance of interests, with a number of presentations for all interest groups. Nobody is being ignored nor is any group receiving an undue share of attention.

Misunderstandings are inevitable in human interactions, even among intelligent people with good intentions. We are all preprogrammed to misread what's right in front of us rather often, because we cannot help but look through lenses of experience that is not always positive. Having been disappointed very often in my dealings with many companies offering products and services, I can be positively hairtrigger with respect to some organizations and unleash a torrent of criticism that may not be fair in a given instance. I look very closely at Kilgray and what it is up to, and I have done so well before I began using the company's products, which I was very reluctant to do. But in the end, the team there won my trust, not with its often superior technology, but rather by its ability to admit mistakes, treat all its users with respect and always try to do better. They don't get everything right all the time, but their basic good sense and desire for stability and balance have carried them very far and very fast in recent years as freelancers, LSPs and enterprises recognize a partner who really can be trusted, one with no hidden agendas or corporate divisions looking for a wedge to sell its translation services to your customers.

Results of the June translation tools surveys

At the end of May I discovered that a new widget had been added to Google's Blogger tools, which offered me a simple way to conduct single question polls. I had been wanting such a feature for a while, so I promptly tested it with a poll on translation tools used (the one on the bottom in the graphic at the left) and followed it a few days later with a question on the number of tools used routinely when it occurred to me that they were a number of others like me who make routine use of multiple tools. As I see it, the responses to that question are also important when considering the significance of responses to the other question. The initial trend of the results remained fairly constant throughout the month, even with a large surge in responses after Alex Eames kindly mentioned the polls in his last tranfree newsletter.

Over 40% of respondents use more than one translation environment routinely. (Astute readers may note that the percentages don't add up. Google's programmers are obviously fond of new math or at least screwy rounding and truncation.)  This would include people who actually translate in multiple environments as well as those who use environments other than their favored one for project preparation and QA. My partner is a good example of this latter category; she uses "classic" Trados all the time to export TMs and terminologies provided to her, pre-segment Word/RTF and TTX files for translation in Déjà Vu X or memoQ and to perform tag QA on TTX files. Probably a few other things too. But after she learned the benefits of more modern translation environments, I would risk singing soprano if I suggest that she actually take up translating with the Trados Workbench macros or TagEditor again. Maybe I can get her to look at SDL Trados Studio 2009 one day, but first I think I'll take up something safer like mud wrestling with crocodiles.

The 8 to 12% of respondents who indicated that they use no translation tools is probably well under the true figure in our profession. My blog tends to attract readers with an interest in the technology of translation and not so many who like to contemplate flowery phrases for translating obscure poetry (too bad, really - that's more my taste, but first bills must be paid). But since one of my intentions in creating these polls was to get an idea of the technology interests of my readers and perhaps choose some future topics to reflect these interests, I'm not really concerned about an accurate representation of the full population of translators. The profession is simply too diverse and fragmented for me to care. It's interesting to see that I belong to the 1% of nutcases that use 5 or more tools - I can hear I told you so on this one already from many quarters. And I like to think I'm not a nerd. Einbildung ist auch 'ne Bildung.

In the poll on specific tools, I received some criticism for not including certain tools under a category more specific that "other". As you can see, with a grand total of 15% other, I'm probably not missing much there. When I see interesting minor tools I'll certainly mention them if I can do so with some knowledge, but I don't have the time to offer the extensive expert surveys that you'll get from a guy like Jost Zetzsche and his Toolkit newsletter or book on computer skills and tools for translators.

I probably also should have split the Trados part of the question into at least the new and old generation of SDL products, but I simply didn't think of this until a few days after the poll was running, and I decided to deal with that issue in a follow-up question another day (and I have - see the poll in the left sidebar, which will run until August 1st). This is also relevant to me, as I'll be exploring the no-longer-so-new Studio 2009 version more in the future. (Why call it 2009 still when you release the service pack that actually makes it work in 2010?) It may run like a lame pig on many machines, but I do like some of the interface elements a lot, and it's the best program on netbooks I've used as far as critical parts of screens and dialogs not usually getting cut off.

If the poll statistics even roughly approximate the real distribution of tools among commercial translators, then the perception that "everyone" uses Trados is certainly not even close to correct. The greatest share of licenses is certainly for some version of Trados, but if one considers the number of people who use it as I do primarily for some of its filters and to prepare projects for clients who ask for Trados uncleaned deliverables, then the percentage actually translating with Trados will be far under 50%. This is a point well worth considering for those who want to use the most qualified translator for a given subject: statistically, the odds are against you if you insist on Trados use. It's far better to design projects in a tool-neutral manner as far as practical and let the translators work with whatever they feel most comfortable with. The importance of using the best qualified translator for a particular subject rather than the first monkey with a particular tool in his box is one of the reasons why I like Déjà Vu X and memoQ so much: the RTF table exports from these two tools allows projects to be translated or edited by anyone with a modern word processor regardless of the source format. Every translation environment tool should follow the example set by Atril and Kilgray in this respect.

It's also interesting to note that "major" tools like Star Transit and Across only have 6% of respondents claiming use. Anyone who tries to insist on a translator using those tools is playing a very bad hand.

The main conclusion I draw from these data is that give the diversity of tool use among qualified translators, it is more important than ever to design and test our processes for true interoperability and to drop the religious insistence on the use of One True Tool, no matter what that tool may be.

But that's just my initial reaction to the data. What do you think?

MemoQ 3.5: the march of progress continues!

Since I'm heading off to Budapest next week for the MemoQ Fest 2009, I was very pleased to see Jost Zetzsche's review of the latest MemoQ release in his very useful Translators ToolKit newsletter a few weeks ago. Here it is republished with his permission for the benefit of those looking for flexible new options in translation assistance technology. I am particularly excited by the new filter for doing Star Transit projects; although I have been using Déjà Vu X and occasionally Trados to translate the target XML files in a PXF project package, Kilgray's approach represents a huge step forward in functionality and user-friendliness. This is a tool worth watching!

*******

Rememo Me?
(republished from The 137th Tool Kit - Premium Edition
© 2009 International Writers' Group)

For the last few months I have been keeping tabs on MemoQ's latest releases, which have come out with refreshing regularity. Every so often there was enough interesting material to write about, but I always held out. Until now.

This last week MemoQ 3.5 was released, and here are the new features according to Kilgray (the Hungarian company behind MemoQ):

· Longest substring concordance

· Wildcard concordance and wildcard in terms

· STAR Transit filter

· Bi-directional language enhancements

· Horizontal edit view

· XML preview feature

· PowerPoint 2007 filter

· Drastic server speed improvements

I downloaded the new version and specifically looked at the first three features, which I found truly ground-breaking.

Let's start with the first feature first, the oddly named "longest substring concordance" (or, just as odd: LSC). This is an attempt to automate concordance searches according to user-defined parameters (under Tools> Options> Subsegment leverage you can set the minimum number of concordance hits and/or the minimum number in words/letters/characters) and without interrupting the workflow. In the Translation results pane there are now not only translation memory matches, terminology matches, and assembled rows (available since version 3.2) but also ominous-looking matches of subsets of the string that needs to be translated with empty targets. These are the LSC matches. Clicking on them will produce the Concordance dialog, which will list all (or a predefined number of) the appearances of that particular substring in the translation memory within the context of the complete strings in the TM.

Confused?

Imagine you have this (real-life) sentence:

The starter motor rotates the engine during the start sequence, by driving it through the reduction gear unit assembly.

MemoQ might find that "the reduction gear unit" is a worthwhile subsegment and will display this in the Translation results pane with an empty target. Double-clicking on it would bring up the Concordance dialog with these options:

The starter motor rotates the engine during the start sequence, by driving it through the reduction gear unit assembly.

A coupling assembly mechanically connects the main output drive shaft of the reduction gear unit to the driven unit.

Individual accessory drive pads for the main lube oil pump are also incorporated on the reduction gear unit.

with their respective translations. If you wanted to use any of those, you would just need to highlight the part of the translation you want to use and select Insert selected.

I really like this feature because it offers a new granularity to TM materials without being obtrusive (the program does not slow you down by displaying an additional dialog like a comparable feature in Trados, plus you are free to use the displayed option or not), it enables easy paste access to the desired translation, and MemoQ's superior search-and-lookup speed allows it to operate without even seeming to slow down the search process too much.

Speaking of the Concordance dialog, that same dialog is also used for the enhanced concordance features. (A "concordance search" is the process of manually highlighting one term or phrase in the source segment, pressing a shortcut key -- in the case of MemoQ, it's Ctrl+K -- and accessing all occurrences of that in the TM.) What makes MemoQ's concordance feature attractive is the possible automatic addition of a wildcard character. In the Concordance dialog you can select the option Add wildcard to selected text, and for the current and next search(es) MemoQ automatically adds an asterisk (*) to each of the terms. This will make MemoQ look for 0 or more additional characters to the term in question, something that is particularly helpful for languages with heavy flexion. (Plus, I really like this because I always forget where the asterisk is on the German keyboard and I get tired of switching back to the English keyboard to enter it manually.)

The last feature that really caught my interest was the Transit compatibility feature. Now, Transit is a great program, but it's really different, and many folks just don't want to spend the time to learn to use the free Satellite edition (even if they might miss out on something). For those, this feature will be very useful. It allows you to import a PXF file -- this is a Transit-specific package file with the translation files, reference material (i.e., TM), and glossary data -- extract the translation files as well as the TM content, translate it, and then send it back to your client as a TXF file -- Transit's return package format.

In general it works very well. There are a few glitches -- a couple of strings (out of a few thousand in a test run) were unduly protected as tags, and I had to switch my import mode to get all my data, but it's impressive that the MemoQ developers were able to use Transit logic to "harvest" reference material that is readily available in the TM you selected when you started translating. What this feature is not able to do is automatically import the TermStar glossaries. This is somewhat unfortunate because Transit projects tend to be very terminology-heavy because of its excellent terminology tool.

Here are some other caveats with the new version: Word 2007 is still not supported -- though PowerPoint and Excel 2007 are -- and TBX, the termbase exchange standard, is also not supported yet.

This morning I had a chance to talk with the owner of a translation agency who has been using the server edition of MemoQ for a while, just to get an idea of what his take on performance and user acceptance was. He was very positive overall. Compared to other server-based products (Idiom WorldServer, Logoport, and Across) he reported equal or better server response times. He also liked the option for translators to check out resources to work offline or the online document storage. This last feature allows translators not only to share translation memories and terminology databases, but also the actual documents, which -- optionally -- can be server-based as well. Thus, multiple users can have access to large documents that can be translated and edited at the same time for faster turnaround. His assessment of that process was kind of interesting: He ran into problems with translators not working successively from top to bottom through documents, creating havoc for the poor editors; however, that seems to be less a technical limitation than an organizational one.

As far as user acceptance, he acknowledged that not all his translators were super-eager to adopt a new tool at the drop of a hat, but it helped that they did not have to pay for the program. With MemoQ's mobile licensing concept, he is able to assign temporary full licenses to his users. Interestingly -- and he was not the first to mention it -- Déjà Vu users in particular are struggling with the idea of using a different tool.

Speaking of licensing, I am interested to see how MemoQ's licensing scheme will be adopted once it's time for it. Last fall Kilgray adopted a new system in which all upgrades are free for a year after purchase, no matter how major or minor they might be; after that year, a 20% annual fee is applicable for further upgrades. This is certainly not an uncommon practice in the software industry in general, but as far as I know it is unusual for the individual user sector in our industry. We'll see what happens come fall of 2009.