memoQ AutoCorrect: mysteries revealed

Actually, AutoCorrect isn't that mysterious to those familiar with it. Many Microsoft Office users love it or hate it. I usually love it when I type English, but when I switch between languages in the same document, strange mutations occur in my words and I often wonder how I could possibly have typed some of the things I seem to have typed and of course did not.

Last December when I started the research to update my book of memoQ tips (which is still in progress, because the software is a fast-moving target to describe), I found a way to migrate the AutoCorrect lists from Microsoft Word to memoQ (and vice versa). This was a happy day for me, as a Dutch partner had been asking for exactly that for a very long time, and Kilgray's Support had not been able to offer a solution. I never did get around to blogging my findings, but a few months later, a similar solution was published in the Kilgray Knowledgebase. It states that it's perhaps only for migrating AutoCorrect lists from MS Word 2003, but I used an old macro from MS Word 98 when I worked out the problem, and if that still functions for MS Word 2010, then I'm sure Kilgray's posted solution must be fine for new versions. (Just be careful to use UTF-8 as the code page of text files you transfer or there may be trouble.)

But the best solution was actually published a few years earlier by Val Ivonica. In Portuguese. She included the macro code, and I like her macro (or the one she got from someplace) better. For some strange reason, the only really good information available on memoQ AutoCorrect up to now that I could find is in Portuguese. There are some nice examples of useful AutoCorrect shortcuts for periods of a year from William Cassemiro on the Janela Tradutória blog.

I was quite surprised to learn that many users of memoQ have no idea what AutoCorrect is; Déjà Vu offers the same feature, but I think it's missing in the various Trados versions, possibly because of the history of Trados Workbench as an application used primarily in the MS Word environment. The Kilgray documentation I could find was rather skimpy and seemed entirely focused on typing shortcuts. The idea of correcting spelling or vocabulary differences between language variants wasn't anywhere I could find it.

So I put together this "little" overview of how AutoCorrect works in memoQ and how and where to manage the AutoCorrect list resources there. It's a start... perhaps Kilgray or someone else can fill in the missing bits.

Time  Description
0:38  Activating AutoCorrect in an open project
1:47  AutoCorrect in action while typing
3:30  How the "primary" AutoCorrect list "rules"
3:55  Slide show: overview of AutoCorrect
4:59  Slide show: Three places to manage AutoCorrect

Translating presentations in memoQ: PowerPoint vs. OpenOffice Impress

Microsoft PowerPoint files can be a real nuisance to translate. One of the biggest challenges with these files is the haphazard formatting that many authors apply when working in that medium: line breaks and paragraph breaks in the most inconvenient places, which can cause some stress when working with many translation environment tools.

The current status of the PowerPoint filters in memoQ (version 6.5 build 10) is not as well developed as the filters for Microsoft Word and Excel files; in particular the inability to configure the handling of "soft breaks" (line feeds) causes me no little grief. However, I can at least join segments to get complete sentences where I want them. That's something you can't do in SDL Trados Studio, though that tool at least represent the breaks as inline tags. Sometimes I prepare my PowerPoint files in Trados Studio and then translate the SDLXLIFF file in memoQ if there are a lot of breaks in the sentences. But then I miss the preview.

Recently I had occasion to look at a presentation created with OpenOffice Impress, a rather nice alternative to PowerPoint. Given the confusion over Microsoft's new licensing practices for MS Office 2013, I would not be surprised if more of my corporate clients begin to use the clever free alternative.

However, when I tried to import the Impress (ODP) files to memoQ, I found that the files were not recognized as a translatable format. However, that problem was quickly solved, and the technique for translating ODP files in the current and older versions of memoQ is shown in the video below. One could, of course, convert these to PowerPoint formats, but you might not want to. With ODP files, it is possible to have breaks treated as inline tags.

Time Description
0:33  Importing the PowerPoint file to memoQ with options
1:10  Examining the segments of the imported PowerPoint file
1:35  Joining segments for "broken sentences" in the imported PowerPoint file
1:43  The presentation as an OpenOffice Impress (ODP) file
2:07  Importing the ODP file to memoQ
2:39  Setting the filter for the "unknown" file type
3:04  Configuring "soft" breaks as inline tags
3:34  Examining the segments of the imported ODP file

I hope to see a few more refinements of the PowerPoint and OpenOffice filters in future builds of memoQ!

Coping with embedded "BIN" objects in MS Office documents

When I published a procedure for getting at embedded objects in Microsoft Office documents, I mentioned that older documents in MS Office 2003 formats could be saved as Office 2007/2010 equivalents in order to access the embedded objects via Windows Explorer after renaming the extension to ZIP. What I failed to mention is that older format embedded objects are stored with a BIN extension, not the proper extension of the application with which they are associated. The icon above, for example, is for an embedded PowerPoint 2003 slide.

There are a few ways of dealing with this. If you know what the object should be, just re-name the extension to fit (PPT in this case). Or if you are importing to a CAT tool, specify the proper filter for the *.bin file. Here's an example for memoQ 6:

The number at the end of the file name before the extension indicates the order of the objects in the document, which may be helpful in identifying the new extension to use. If you want to put the translated objects back in the embeddings folder, remember to change the extensions of the older objects back to BIN.

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.

Back to 2003!

Like many people, I am deeply unhappy with the changes that Microsoft made to its Office Suite in the 2007 and 2010 versions. Since I upgraded from Office 2003 about a year ago, I have been unable to find many functions I used for decades. I find the "ribbon" paradigm used in the current interface appalling. Icons have been carried much too far in interfaces. We need words to figure out where things are in most cases. Or I do at least.

This topic has been raised several times on the private translators' forum Stridonium in which I participate, but until recently I managed to overlook the solution suggested there. One colleague suggested the commercial solution from Addintools. When I mention this at last night's translators' social evening in Hohen Neuendorf near Berlin, one person there thought I was referring to a macro solution from Switzerland, which I was not. This morning he sent me a link to UBit's pages with their interesting solution:

The macro from UBit adds a "Menu" menu to the MS Office 2007 or 2010 menu bar (how's that for redundancy in wording?). When selected, it displays a strip of dropdown menus corresponding to the structure of the MS Word 2003 menus. The product was developed to make the transition to the awful new interface less painful. So far it looks promising. There's a little info video, which is short on information but has a nice music track: