Filtering formatted text in Microsoft Office files

 Recently, I shared an approach to selecting text in a Microsoft Word file with editing restricted to certain paragraphs. This feature of Microsoft Word is, alas, not supported by any translation tool filters of which I am aware, so to import only the text designated for editing it is necessary to go inside the DOCX file (which is just a ZIP archive with the extension changed) and use the XML file which contains the document text with all its format markers.

This approach is generally valid for all formats applied to Microsoft Office files since Office 2007, such as DOCX from Word or PPTX from PowerPoint. I have prepared a video to show how the process of extracting the content and importing it for translation can work:

 After translation, the relevant XML file is exported and the original XML is replaced with the translated file inside the archive. If the DOCX or PPTX file was unpacked to get at the XML, the folder structure can then be re-zipped and the extension changed to its original form to create the deliverable translated file.

What I do not show in the video is that the content can also be extracted by other means, such as convenient memoQ project templates using filters with masks to extract directly using various ZIP filter options. But the lower tech approach shown in the video is one that should be accessible to any professional with access to modern translation environment tools which permit filter customization with regular expressions.

Once a filter has been created for a particular format such as red text, adapting it to extract only green highlighted text or text in italics or some other format takes less than a minute in an editor. Different filters are necessary for the same formats in DOCX and PPTX, because unfortunately Microsoft's markup for yellow highlighting, for example, differs between Word and PowerPoint in the versions I tested.

Although this is a bit of a nerdy hack, it's probably easier for most people than various macro solutions to hide and unhide text. And it takes far less time and is more accurate than copying text to another file.

In cases where it is important to see the original context of the text being translated, this can be done, for example, using memoQ's PDF Preview Tool, a viewer available in recent versions which will track the imported text in a PDF made from the original file. This can be done using the PDF Save options available in Microsoft applications.

Forget the CAT, gimme a BAT!

It's been nine months since my last blog post. Rumors and celebrations of my demise are premature; I have simply felt a profound reluctance to wade in the increasingly troubled waters of public media and the trendy nonsense that too often passes for professional wisdom these days. And in pandemic times, when most everything goes online, I feel a better place for me is in a stall to be mucked or sitting on a stump somewhere watching rabbits and talking to goats, dogs or ducks. Certainly they have a better appreciation of the importance of technology than most advocates of "artificial intelligence".

But for those more engaged with such matters, a recent blog post by my friend and memoQ founder Balázs Kis, The Human Factor in the Development of Translation Software, is worth reading. In his typically thoughtful way, he explores some of the contradictions and abuses of technology in language services and postulates that

... for the foreseeable future, there will be translation software that is built around human users of extraordinary knowledge. The task of such software is to make their work as efficient and enjoyable as possible. The way we say it, they should not simply trudge through, but thrive in their work, partially thanks to the technology they are using. 

From the perspective of a software development organization, there are three ways to make this happen:  

• Invent new functionality 
• Interview power users and develop new functionality from them 
• Go analytical and work from usage data and automate what can be automated; introduce shortcuts 

I think there is a critical element missing from that bullet list. Some time ago, I heard about a tribe in Africa where the men typically carry one tool with them into the field: a large knife. Whatever problem they might encounter is to be solved with two things: their human brains and, optionally, that knife. In a sense, we can look at good software tools in a similar way, as that optional knife. Beyond the basic range of organizing functions that one can expect from most modern translation environment tools, the solution to a challenge is more often to be found in the way we use our human brains to consider the matter, not so much the actual tool we use. So, from a user perspective and from the perspective of a software development organization, thriving work more often depends not so much on features but on a flexible approach to problem solving based on an understanding of the characteristics of the material challenge and the possibilities, often not adequately discussed, of the available tools. But developing capacities to think frequently seems much harder than "teaching" what to think, which is probably why the former approach is seldom found in professional language service training, even when the trainers may earnestly believe this is what they are facilitating.

I'll offer a simple example from recent experience. In the past year, most of my efforts have been devoted to consulting and training for language technology applications, trying to deal with crappy CMS systems for which developers never gave proper consideration to translation workflows or developing methods to handle really weird outliers like comment translation for distributed PDFs or filtering the "protected" content of Microsoft Word documents with restricted editing to... uh... protect the "restricted" parts.

That editing function in Microsoft Word was new to me despite the fact that I have explored and used many functions of that tool since I was first introduced to it in 1986. I qualify as a power user because I am probably familiar with at least five percent of the program's features, though I am constantly learning new ways to apply that five percent. And the 95% remaining is full of surprises:

Most of the text here can't be edited in MS Word, but default CAT tool filters cannot exclude it.

Only the highlighted text can be edited in the word processor, and that was also the only text to be translated. The real files were much larger than this example, of course, and the text to be translated was interspersed with a lot of text to be left alone. What can you do?

It was interesting to see the various "solutions" offered, some of which involved begging or instructing the customer to do one thing or another, which is not always a practical option. And imagine the hassles of any kind of manual selection, copying and replacement if you have hundreds of pages like this. So some kind of automation is needed, really. Oh, and you can't even hide the protected text. It will import with the default filters of the translation tool, where it will then be indistinguishable from the actual text to be translated and it can be modified. In other words, bye-bye "protection".

What can be done?

There are a number of possibilities that fall short of developing a new option for import filters, which could take years given the often sluggish development cycles for any major CAT tool. One would be...

... to consider that a Microsoft Word DOCX file is really a ZIP archive with a bunch of stuff inside it. That stuff includes a file called document.xml, which contains the actual text of the MS Word document:

That XML file has an interesting structure. All the document text is in one line as one can see when it is opened in a code editor like Notepad++:

I've highlighted the interesting part, the part with the only text I want to see after importing the file for translation (i.e. the text for which editing is not restricted in MS Word). Ah yes, my strategy here is to deal with the XML text container for the DOCX file and ignore the rest. When the question was raised, I knew there must be such a file, but despite exploring the internal bits of MS Office files with ZIP archive tools for about a decade now, I never actually had occasion to poke around inside of document.xml, and I knew nothing of that file's structure. But simple logic told me there must be a marker there somewhere which would offer a solution.

As it turned out, the relevant markers are a set of tags denoting the beginning and end of a text block with editing permission. These can be seen at the start and finish of the text I highlighted in the screenshot. So all that remains is to filter that mess. A simple thing, really.

In memoQ, there is a "filter" which is not really a filter: the Regex Text Filter. It's actually a toolkit for building filters for text-based files, and XML files are really just text files with a lot of funky markup. I don't care about any of that markup except in the blocks I want to import, so I customized the filter settings accordingly:

A smattering of regular expressions went a long way here, and the expressions used are just some of many possible ways to parse the relevant blocks. Then I added the default XML filter after the custom regex text filter, because memoQ makes filter sequencing of many kinds very easy that way. This problem can be solved with any major CAT tool I think, but I don't have to think very hard about such things when I work with memoQ. The result can be sent from memoQ as an XLIFF file to any other tool if the actual translator has other preferences. Oh, the joys of interoperable excellence....

The imported text for translation, with preview 

After translation, document.xml is replaced in the DOCX file by the new version, and the work is done, the "impossible" accomplished without any new features added to the basic toolkit. Computer assistance is all very well, but without brain-assisted translation you're more likely to achieve half the result with double the effort or more.

MS Word Macros to Speed up Translation-Related Terminology Research

Guest post by Tanya Harvey Ciampi, English translator (DE/FR/IT>EN)

Is your terminology research slowing you down?

When we translate Microsoft Word documents, we often find ourselves having to leave Word to look up terms online, for example in monolingual dictionaries for definitions, in bilingual dictionaries or translation memory databases for translations, on specific reputable websites (such as newspaper websites) to double-check usage or frequency of use, or on clients’ own multilingual websites to check how certain terms have been translated in the past to ensure consistent use of terminology.

This sort of research involves switching to a browser, copying and pasting or retyping our term into a search box, possibly adding specific search criteria, and finally launching a search: all that typing and clicking can be time-consuming and easily cause us to become lost among the many windows opened.

Macros to the rescue!
This is where macros come in. A macro is essentially a short sequence of commands that automates repetitive tasks. Macros cost nothing to create and can be tweaked to do exactly what you need them to do, based on your specific language combinations and favourite online terminology resources, providing these lend themselves to this sort of querying.

How do macros work?
A macros consists of code, which you simply need to copy and paste into the Macros section of Word. That done, you then need to assign an icon to the macro and add it to your toolbar to launch the macro with a single click every time you need it. If you wish, you may also assign a specific key combination to the macro (for example CTRL plus a key of your choice) so that you can launch the macro from your keyboard, too.

From now on, when translating a text in Word, all you need to do is place your cursor on a word that you wish to look up and click on the corresponding icon in your toolbar (or use the assigned key combination) to launch the search. That’s all there is to it!

A few examples of macros and what they can do for you:

SCENARIO: Imagine...	SOLUTION... with a single click!
...you need to look up a term in the bilingual dictionaries www.leo.org and www.dict.cc but this requires opening your browser, browsing to both dictionaries separately and pasting in or retyping your search term on each website... quite time-consuming!	A macro to search both dictionaries at once taking your word from MS Word and inserting it automatically in both dictionaries for you... with a single click from within Word. (This macro can be adapted to all sorts and any number of websites) What this macro does essentially is launch a Google search from within Word, adding specific search criteria, in this case: “your search term” inurl:leo.org or inurl:dict.cc
...you wish to run a search in the online translation memory database www.linguee.com (or linguee.de, linguee.fr, linguee.it etc.) to check how other translators have translated a certain term or expression.	A macro to search Linguee taking your word from MS Word and inserting it directly in the Linguee search engine with a single click from within Word. This macro produces a list of source- and target-language sentences containing your search term along with context.
...you are translating a text and need to check how a particular expression is used. You decide to search reputable sources such as high-quality newspapers to check usage and/or frequency of use of a specific term or expression. Where do you look?	A macro to search specific newspaper websites which you consider reputable sources from within Word. (This macro can be adapted to all sorts and any number of websites.) This macro essentially launches a Google search from within Word, adding specific search criteria to target a specific website, for example: “your search term” inurl:guardian.co.uk
...you are translating for a company that has a multilingual website and you need to check how a specific term has been translated in the past.	A macro to search for the term on a specific multilingual website from within Word. This macro can be extended to cover various related multilingual websites. In banking, for example, these might include the following: www.ubs.com www.credit-suisse.com www.raiffeisen.ch This macro essentially launches a Google search from within Word, adding specific search criteria, for example: “your search term” site:www.ubs.com or site:www.credit-suisse.com or site:www.raiffeisen.ch
...you are translating a text and can't find an appropriate translation of an expression or technical term in any dictionary.	A macro to search for your term on a large multilingual website such as that of the European Union from within Word. This macro targets the section of the EU website containing translations side by side (“parallel texts”) on the same page, saving you precious time. This macro essentially launches a Google search from within Word, adding specific search criteria, for example: “your search term” inurl:eur-lex.europa.eu Once you have opened a page on the EU website, all you need to do is specify your target language under “Multilingual display” to view source and target language side by side.

See a couple of these macros in action:
https://www.youtube.com/watch?v=XlvBLgJPaFk

These and more macros are available for free at https://www.facebook.com/groups/TranslatorsSwitzerland/

The macros themselves are written by a translator with translators' needs in mind and can be adapted to your specific requirements.

Macros may also be created to automate the web-based terminology research techniques for translators found at
http://www.multilingual.ch/Search_Interfaces.htm
... reducing them, too, to a single click in Word!

The original search techniques on which these macros are based were featured in the book entitled “Google Hacks” (“Hack #19: Google Interface for Translators”) by Tara Calishain, Rael Dornfest

*******

Tanya Harvey Ciampi, Dipl. DOZ (Zurich)
English translator (DE/FR/IT>EN)
6673 Maggia, Switzerland, www.multilingual.ch

Tanya grew up in Buckinghamshire, England, and went on to study in Zurich, where she obtained her diploma in translation. She now lives in the Ticino, the Italian-speaking region of Switzerland, where she works as an English translator (from Italian, German and French) and proofreader.

The challenge of too many little files to translate

It seems to me that most translators face this challenge eventually: a customer has many small files of some kind - tiny web pages perhaps or other content snippets in XML, text or Microsoft Word files or perhaps even in some bizarre proprietary format - and wants them translated.

Imagine a dictionary project with thousands of words with their definitions, each "entry" being stored in a separate text file. How would you translate that efficiently?

The brute force method of opening and translating each file individually is not very satisfactory. Not only does this take a long time, but when I have tried foolishness like that I tend to overlook some files and spend far too much time checking to ensure that nothing has been overlooked. And QA measures like spellchecking? Let's change the subject....

Some translation tools offer the possibility to "glue" the content of the little files together and then (usually) "unglue" them later to reconstitute the original structure of little files, now translated.

Other tools offer various ways to combine content in "views" to allow translation, editing, searching and filtering in one big pseudofile. This is very convenient, and this is the method I use most often in my work with memoQ or SDL Trados Studio after learning its virtues earlier as a Déjà Vu user.

Unusual file formats can often be dealt with the same way after some filter tweaking or development. But sometimes....

... there are those projects from Hell where you have to ask yourself what the customer was smoking when he structured his data that way, because some other way would be so much more practical and convenient... for you. Ours is generally not to question why some apparently insane data structure was chosen but to deal with the problem as efficiently as possible within budget and charge appropriately for any extra effort incurred. Hourly fees for translation rather than piece rates certainly have a place here.

Sometimes there is a technical solution, though it may not be obvious to most people. For example, in the case presented to me by a colleague on Christmas Eve

the brief was to write the translation in language XX in the empty cell in that columnof the 3x2 table embedded in a DOCX file. There were hundreds of these files, each containing a single word to translate.

If these were Excel or delimited text files, a simple solution would have been to use the Multilingual Delimited Text Filter for memoQ and specify that the first row is a header. But that won't fly (yet) for MS Word files of any kind.

In the past when I have had challenging preparation to do in RTF or Microsoft Word formats - such as when only certain highlighted passages are to be translated and everything else is ignored - I have created macros in a Microsoft Office application to handle the job.

But this case was a little different. The others were always single files, or just a few files where individual processing was not inconvenient. And macro solutions often suffer from the difficulty that most mere mortals fear to install macros in Microsoft Word or Excel or simply have no idea how to do so.

So some kind of bulk external processing is called for. In this case, probably with a custom program of some kind.

I usually engineer such solutions with a simple scripting language - a dialect of the BASIC language which I learned some 45 years ago - using a free feature which is part of the Microsoft Windows operating system: Windows Scripting Host. And one-off, quick-and-dirty solutions with these tools do not require a lot of skill. The components of many solutions can be found on Microsoft Help pages or various internet forums with a little research if you have only a vague idea of what to do.

In this case, the tasks were to

1. Select the files to process (all 272 of them)
2. Open each file, copy the English word into the empty cell next to it
3. Hide all the other text in the file so that it can be excluded from an import into a working tool like Déja Vu, memoQ or SDL Trados Studio (using the options for importing Microsoft Word files in this case; the defaults usually ignore hidden text on import)

After that the entire folder structure of files could be imported into most professional translation support environments and all 300 or so words to translate could be dealt with in a single list view.

A more detailed definition of the technical challenge would include the fact that to manipulate data in some way in a Microsoft Office file format, the object model for the relevant program would probably have to be used in programming (for XML-based formats there are other possibilities that some might prefer).

Microsoft kindly makes the object models of all its programs available, usually for free, and there is a lot of documentation and examples to support work with them. That may in fact be a problem: there is a lot of information available, and it is sometimes a challenge to filter it all intelligently.

In this case, I needed to use the Microsoft Word object model. It also conveniently provided the methods I needed to create the selection dialog for my executable script file. The method I knew from the past and wanted to use at first is only available to licensed developers, and I am not one of these any more.

It is easy to find examples of table manipulation and text alteration techniques in Microsoft Word using its object model in VBScript or some other Microsoft Basic dialect like Visual Basic for Applications (VBA). The casual dabbler in such matters might run into some trouble using these examples if there is no awareness of differences between these dialects; trouble is often found where VBA examples that declare variables by type (example: "Dim i as Integer") occur. Declarations in VBScript must be untyped (i.e. "Dim i"), so a few changes are needed.

In this case, the quick and simple solution (' documentary comments are delimited by apostrophes and marked green) to make the files import-ready was:

' We have a folder full of DOCX files, each containing
' a three-column table where COL1 ROW2 needs to be copied to COL2 ROW2
' and then the COL1 ROW2 and other content needs to be hidden.

Option Explicit

Dim fso
Dim objWord
Dim WshShell
Dim File
Dim objFile
Dim fileCounter
Dim wrd ' Word app object
Dim oFile  ' Word doc object
Dim oCell1  ' first cell of interest in the table
Dim oCell2  ' second cell of interest in the table
Dim oCellx1  ' other uninteresting text
Dim oCellx2  ' other uninteresting text
Dim oCellx3  ' other uninteresting text 
Dim oCellx4  ' other uninteresting text 

fileCounter = 0

'set the type of dialog box you want to use
'1 = Open
'2 = SaveAs
'3 = File Picker
'4 = Folder Picker
Const msoFileDialogOpen = 1

Set fso = CreateObject("Scripting.FileSystemObject")
Set objWord = CreateObject("Word.Application")
Set WshShell = CreateObject("WScript.Shell")

'use the path selected in the SelectFolder method
'set the dialog box to open at the desired folder
objWord.ChangeFileOpenDirectory("c:\")

With objWord.FileDialog(msoFileDialogOpen)
   'set the window title to whatever you want
   .Title = "Select the files to process"
   .AllowMultiSelect = True
   'Get rid of any existing filters
   .Filters.Clear
   'Show only the desired file types
   .Filters.Add "All Files", "*.*"
   .Filters.Add "Word Files", "*.doc;*.docx"
         
   '-1 = Open the file
   ' 0 = Cancel the dialog box
   '-2 = Close the dialog box
   'If objWord.FileDialog(msoFileDialogOpen).Show = -1 Then  'long form
   If .Show = -1 Then  'short form
      'Set how you want the dialog window to appear
      'it doesn't appear to do anything so it's commented out for now
      '0 = Normal
      '1 = Maximize
      '2 = Minimize
      'objWord.WindowState = 2

      'the Word dialog must be a collection object
      'even with one file, one must use a For/Next loop
      '"File" returns a string containing the full path of the selected file
     
      For Each File in .SelectedItems  'short form
       'Change the Word dialog object to a file object for easier manipulation
        Set objFile = fso.GetFile(File)
Set wrd = GetObject(, "Word.Application") 
wrd.Visible = False 
wrd.Documents.Open objFile.Path 
Set oFile = wrd.ActiveDocument

Set oCell1 = oFile.Tables(1).Rows(2).Cells(1).Range  ' EN text
        oCell1.End = oCell1.End - 1
        Set oCell2 = oFile.Tables(1).Rows(2).Cells(2).Range  ' Target (XX)
        oCell2.End = oCell2.End - 1
        oCell2.FormattedText = oCell1.FormattedText  ' copies EN>XX 
oCell1.Font.Hidden = True ' hides the text in the source cell

' hide the other cell texts (nontranslatable) now
Set oCellx4 = oFile.Tables(1).Rows(2).Cells(3).Range
oCellx4.Font.Hidden = True
Set oCellx1 = oFile.Tables(1).Rows(1).Cells(1).Range
oCellx1.Font.Hidden = True
Set oCellx2 = oFile.Tables(1).Rows(1).Cells(2).Range
oCellx2.Font.Hidden = True
Set oCellx3 = oFile.Tables(1).Rows(1).Cells(3).Range
oCellx3.Font.Hidden = True

wrd.Documents.Close 
Set wrd = Nothing
 
fileCounter = fileCounter + 1
      Next    
   Else 
   End If
End With 

'Close Word
objWord.Quit

' saying goodbye
msgbox "Number of files processed was: " & fileCounter

The individual files look like the above screenshot (all text in the top row is hidden, so the entire row is invisible, including its bottom border line) after processing with the script, which is saved in a text file with a *.vbs extension (it can be launched under Windows by double-clicking):

Of course the script could be made much shorter by declaring fewer variables and structuring in a more efficient way, but this was a one-off thing where time was of the essence and I just needed to patch something together fast that worked. If this were a routine solution for a client I would be a bit more professional, lock the screen view, change to some sort of "wait cursor" during processing or show a progress bar in a dialog and all the other trimmings that one expects from professional software these days. But professional software development is a bit of a bore after so many decades, and I haven't got the patience to see the same old stupid mistakes and deceits practiced by yet another generation of technowannabe world rulers, I just want to solve problems like this so I can get back to my translations or go play with the dogs and feed the chickens.

But before I could do that I had to save my friend from the Hell of manually unhiding all that table text after his little translation was finished, so I put another 5 minutes (or less) of effort into the "unhiding" script:

Option Explicit

Dim fso
Dim objWord
Dim WshShell
Dim File
Dim objFile
Dim fileCounter
Dim wrd 
Dim oFile  
Dim oCell1  ' source text cell in the table
Dim oCellx1  ' other uninteresting text
Dim oCellx2  ' other uninteresting text
Dim oCellx3  ' other uninteresting text 
Dim oCellx4  ' other uninteresting text 

fileCounter = 0

Const msoFileDialogOpen = 1

Set fso = CreateObject("Scripting.FileSystemObject")
Set objWord = CreateObject("Word.Application")
Set WshShell = CreateObject("WScript.Shell")

objWord.ChangeFileOpenDirectory("c:\")

With objWord.FileDialog(msoFileDialogOpen)
   .Title = "Select the files to process"
   .AllowMultiSelect = True
   .Filters.Clear
   .Filters.Add "All Files", "*.*"
   .Filters.Add "Word Files", "*.doc;*.docx"
   If .Show = -1 Then  
      For Each File in .SelectedItems
         Set objFile = fso.GetFile(File)
Set wrd = GetObject(, "Word.Application") 
wrd.Visible = False 
wrd.Documents.Open objFile.Path 
Set oFile = wrd.ActiveDocument
Set oCell1 = oFile.Tables(1).Rows(2).Cells(1).Range
oCell1.Font.Hidden = False 
Set oCellx4 = oFile.Tables(1).Rows(2).Cells(3).Range
oCellx4.Font.Hidden = False
Set oCellx1 = oFile.Tables(1).Rows(1).Cells(1).Range
oCellx1.Font.Hidden = False
Set oCellx2 = oFile.Tables(1).Rows(1).Cells(2).Range
oCellx2.Font.Hidden = False
Set oCellx3 = oFile.Tables(1).Rows(1).Cells(3).Range
oCellx3.Font.Hidden = False

wrd.Documents.Close 
Set wrd = Nothing
 
fileCounter = fileCounter + 1
      Next    
   Else 
   End If
End With 

objWord.Quit
msgbox "Number of files processed was: " & fileCounter

memoQ AutoCorrect update & MS Word export macro

Last summer I wrote about autocorrection of text in memoQ and offered an indexed embedding of a video I created to give an overview of the AutoCorrect functions in memoQ 2013. There have been a few enhancements since then in memoQ 2013 R2; where only "smart quote" toggling was possible before there are now various options for correcting accidental miscapitalization.

I've also been looking to optimize the procedure for migrating the Microsoft Word autocorrection lists to memoQ. There are a number of problems with using the table-generating macro that Kilgray suggests in the knowledgebase article on using MS Word 2003 autocorrect data; when I created a 17,000 entry list from a large AutoCorrect file for one language, it was nearly impossible to do anything with it because of memory problems. The following macro, which could be put into the Normal template in MS Word, should be a little easier to work with:

Sub BuildAutoCorrectList()
  Dim ACE As AutoCorrectEntry
  ' Create new document.
  Documents.Add
  ' Iterate through AutoCorrect entries.
  For Each ACE In Application.AutoCorrect.Entries
    ' Insert each entry name and its value on a new line.
    Selection.TypeText ACE.Name & vbTab & ACE.Value & vbCr
  Next
End Sub

Invoke the macros dialog in MS Word with Alt+F8. Select the Normal.dot or Normal.dotm file (depending on your version of MS Office) from the dropdown list, enter the name of the new macro and click the Create button. Then paste in the code above. When the macro is run, it will create a new document with the autocorrection list in tab-delimited text. To bring the list into memoQ, you'll have to

1. Paste in the XML header needed by the "light resource" for AutoCorrect lists in memoQ. You can see what this looks like for the language setting you want by creating a dummy resource, exporting it and opening the file with a text editor. European Spanish might look like this, for example:
   <MemoQResource ResourceType="AutoCorrect" Version="1.0">
     <Resource>
       <Guid>6d61e3bc-da00-4cb8-a4f3-93c980543bba</Guid>
       <FileName>spa-ES#EU Spanish AutoCorrect.mqres</FileName>
       <Name>European Spanish</Name>
       <Description />
       <Language>spa-ES</Language>
     </Resource>
   </MemoQResource>
    
2. Save the file as plain text with UTF-8 encoding.
3. Change the file extension to "*.mqres"
4. Import the resource to memoQ.

AutoCorrect lists which are language-neutral (for example, lists of company names) use "all#" in the name and "Neutral" between the tags.

Other sources for autocorrection data
With a bit of searching, one can find other sources of data to add to AutoCorrect resources for various language. Wikipedia, for example, offers lists of commonly misspelled words, such as this one in English, which includes links to Dutch, Hungarian, Portuguese, Spanish and Turkish lists. The structure of the data lends itself easily to reformatting with the search and replace features of a text editor:

alamanya->almanya
aferim->aferin
agrasif->agresif
ağostos->ağustos
ahret->ahiret
ayle->aile
alarım->alarm
atmış->altmış

Copy the data from the Wikipedia page to a text file. Then use search and replace to substitute tabs for the "->" structures, add an appropriate XML header for the memoQ resource and save the file as UTF-8 with an MQRES extension and you have an AutoCorrect list ready for import to memoQ. An example of the Turkish list converted and ready for use in memoQ is available for download here.

For German, there is a list of common spelling errors on Wikipedia which can be adapted with very little effort to make this resource.

The English list on the Oxford Dictionaries page can also be adapted without much ado. And there are many others to be found on the Internet.

Merging memoQ AutoCorrect resources
Entries from multiple AutoCorrect lists can be combined in a single tab-delimited file, and duplicates can be removed using Microsoft Excel, for example.

The screenshot above shows a merged German AutoCorrect list opened in Excel. When using the Remove Duplicates function on the Data ribbon, be sure that only Column A is selected in the dialog:

The reason Column B must not be selected is that it contains the desired text after correction, and there may be more than one error entry for a particular word.

After duplicates have been removed from the list, save the file as Unicode text, then import it to memoQ. A similar procedure with Excel may be followed to maintain other memoQ light resources; I do this rather frequently for segmentation exceptions to ensure that the lists for the different language variants I work with remain synchronized. (It would be nice, of course, if Kilgray would create a reasonable light resource manager with such capabilities. It gets tiring to do this so often with stopword lists and other resources.)

Want a revolution? Try memoQ 2013 Release 2.

OK, so I'm exaggerating a bit. And even though the new version of memoQ was officially released today by Kilgray, it really is still beta software. But damned good beta. I expect that there will be more of interest to individual translators added in this version of memoQ than in any other version I've seen up to now. Lots of T's to cross and i's to dot still, but there is great promise, and it's worth having a look now at the future of memoQ.

I'm not talking about changes to the memoQ Server. There are lots of those in this version, and for a change many of them actually seem to be helpful to translators working on the server and less focused on slicing and stuffing linguistic sausage faster like many of the 6.x server features introduced. The rollout webinar with István Lengyel and Florian Sachse of Kilgray showed enough of why memoQ Server users should be pleased. But they could have filled the hour and three quarters with nothing but presentations of new or improved functions for the rest of us and still not run out of material. Since I still have a project to finish tonight, I'll just hit a few of the highlights that I'll probably return to later as the features stabilize and are truly ready for productive work.

Language recognition
memoQ now intelligently recognizes the language(s) of the source text. This is a small convenience in setting up projects perhaps, but for those occasions when a source language has many passages in another language or more than one other language, these other language segments can be identified automatically, copied source to target and locked. I can think of more than a few patent dispute translations where this would have been helpful.

Startup Wizard
A new feature under the Help menu gives a quick, friendly guided tour of important settings that are often overlooked that are hard to find for new users and many experienced ones. This is actually one of my favorite new features and possibly the best help I've seen yet for making a better start with the software.

Better Microsoft Word spelling integration
Custom dictionaries can now be imported from Microsoft Word with greater ease. Users can now also choose Microsoft Word for dynamic marking of possible spelling errors (unknown words). This is a good thing for those of us who hate Hunspell. Oh, and those pesky doubled words are caught now.

More stuff with Microsoft Word...
like exporting tracked changes between translation versions to a DOCX file (sans formatting I think), exporting target comment to a DOCX file (alas! in writing the specification Kilgray failed to consider that one might want to select which comments get exported and possibly suppress all the comments, but I'm told this will be remedied quickly), font substitution in DOCX files (this was a major WTF feature for me, but if I understood correctly, there is some way I can use this to protect text formatted a certain way, such as code in a programming guide - if that's true, this is cool) and...

the TM lookup tool,
an external application which runs in Microsoft Word and any other environment and allows you to look up text copied to the Clipboard in selected memoQ TMs. Too bad they didn't include termbases in this new feature. Yet.

New filters and processes
like direct import of InDesign files with a preview using the free online Language Terminal integration, Adobe InCopy and some file formats that must be pretty damned geeky because I've never heard of them.

Why am I excited about
a plain text view which is about as exciting as lukewarm, unspiced pea soup. Well, because it's absence has been driving me nuts for years now. It's in this version.

Meanwhile, back at the termbase
great things are happening with new import options that are still a wee bit buggy but will get very good very soon. Until now memoQ could only import terms as TMX and delimited text. New options include Excel (at last!), MultiTerm XML and TBX. It was child's play for me to tweak a couple of TermStar MARTIF exports from STAR Transit to import those terms, because TBX is a dialect of MARTIF and STAR's MARTIF is very close to TBX. Extra effort? About 2 minutes of search and replace so I'm hoping Kilgray will go the extra five yards and touch this import option down.

The addition of the MultiTerm XML import option means that memoQ users can now roundtrip data from memoQ to partners using SDL MultiTerm and back for termbase updates. Unfortunately at the moment, the only meta data transferred in the import is the definition field, but efforts are in progress to support at least the MultiTerm fields memoQ exports to XML with Kilgray's own definition. That was simply forgotten at specification time (oops). But still, this will be serious headache relief for those of us who work in teams with SDL Trados users and want to share terminology in the most effective ways.

Is that all?
No. This new version of memoQ is like a very messy Christmas where one can easily lose the overview of hat's under the tree with all the wrapping paper and bits of ribbon cluttering the floor. As it gets cleaned up, we'll all notice a good bit more, and I suspect that Santa's Hungarian and German helpers will be slipping a few more things under the tree that they might forget themselves until some user trips over them. There has been so much effort put into consolidation and improvement of existing features that it's simply too much to keep track of. I've made a list and checked it more than twice and still find things to add. But I'll end with another look at something I've already blogged about, that groundbreaking

Monolingual Project and TM Update
with edited files in any target format. It still has a lot of little quirks, especially with some formats, but here I expect a lot of improvements. I've made a little demonstration video and put it on YouTube; it shows the reimport of edited translations to update the translated file and the TM in memoQ, and it shows two different ways to look at tracked changes before revealing the dark secret of Row History Recovery which I think Kilgray didn't realize was possible. Well, damnit, they should have made it a feature with a button anyway.

  (View this in full screen mode by clicking the icon at the lower right of the video window.) 
Oh yes, and one more cool little thing about this release that I forgot to mention...

... the quickstart shortcut to creating memoQ projects
in the context menu by right-clicking on a file. I'm not much into single-file projects any more and prefer to use "container" projects for customers or categories instead, but it's still a nice little addition that can save time once in a while:

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

Coping with objects and graphics to translate in Microsoft Office documents

About a year ago, I published a series of posts describing a simple way to get at the objects and graphics embedded in Microsoft Office documents, such as Microsoft Word DOCX documents or PowerPoint PPTX presentations. These investigations were inspired by a series of jobs where I had to cope with up to 60 embedded Excel tables in a Microsoft Word document. The four related posts are:

• Translating embedded objects in Microsoft Office documents
• Coping with embedded BIN objects in Microsoft Office documents
• Replacing bitmap graphics in Microsoft Office documents
• Refreshing embedded objects in Microsoft Word (a macro)

The post titles may differ a little from the text in the links here, which is updated for a little more clarity.

I've also added two short videos to my YouTube channel which illustrate how to remove embedded objects from a DOCX for translating separately from the Microsoft Word document and how to put them back afterward.

Here's how to extract the embeddings folder from the DOCX file:



And here is how to put the translated embedded objects into the DOCX file and refresh the view of the embedded objects in your translation:



These and other videos I've produced recently are part of an effort I began recently to develop integrated courses for self-instruction and review with software tools used by many of us. These courses use the Moodle platform and offer text, screenshots, audio, video and data files such as examples of file formats to translate, backups of memoQ practice projects to restore on your local computer for training, configuration resources for memoQ, useful macros to support work with many translation environment (CAT) tools and a host of other resources and learning links.

Examining embedded objects in Microsoft Word

Recently I described a method for translating embedded objects in Microsoft Office documents. The final step in that method requires these objects to be refreshed by opening them manually or using a corresponding macro.

The macro below is intended for inspecting all the embedded objects in a Microsoft Word document. When run, it opens each of these objects if possible, regardless of type, and leaves the corresponding editing window open. This allows last minute changes to be made conveniently before the objects are saved and refreshed in the document view. A similar approach can be used for objects embedded in Excel or PowerPoint, though the references are a little different.

This macro could also be used to test quickly whether a large document has embedded objects to be dealt with. Sometimes it's hard to recognize these. It does not, however, open bitmaps inserted as pictures.

Sub openEmbeddedObjects()
   Dim longShapeCount As Long
   On Error Resume Next
   Application.ScreenUpdating = False
   longShapeCount = ActiveDocument.InlineShapes.Count
   If longShapeCount > 0 Then
      For i = 1 To longShapeCount
        ActiveDocument.InlineShapes(i).OLEFormat.Edit
      Next
   End If
   Application.ScreenUpdating = True
End Sub

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.