The challenge of light resource updates with many projects in memoQ

"Templates" take two forms in memoQ: the configuration option for equipping new projects with relevant resources in an automated way to save time and avoid forgetting important references or other information, which was introduced several years ago, and the older sort of "template" - a configured, existing project for a particular client or subject area - where new documents are simply added and old ones archived or deleted as time goes by. I use both approaches and still tend to rely more on the latter practice, as many do.

One colleague who is a frequent source of inspiration for new workflow approaches often mentions that her projects and support resources number in the hundreds, so many ideas I have for managing my own more limited set these days are not practical for her work. But recently someone mentioned casually that it was going to be difficult to update segmentation rules in the 1500 or so projects that her team maintains to support in-house translation needs in their firm. Oh, my God. Yes, that would take some time following the usual approach of going to Project home > Settings and selecting a new resource in even 10% of that number of projects.

There is a better way. In fact, this way will work with the desktop editions typically used by individuals as well as with memoQ server installations of any size, and a "mass update" of project light resources can be performed in very little time - less than it usually takes me to finish a cup of coffee in the morning. My recent article on memoQ light resource defaults and how to change them essentially points the way, but more details, now tested with a memoQ server as well, are given here.

Light resources in a desktop edition are typically stored in the paths

C:\ProgramData\MemoQ\Resources\Defaults for default resources and
C:\ProgramData\MemoQ\Resources\Local for customized (user-created) resources, unless that path was changed (as many do if they deal with a lot of files with long names and need to shorten paths to avoid errors when the file and path names together approach the 256 character limit imposed by Microsoft Windows).

Server installations follow more or less the same logic:

C:\ProgramData\MemoQ Server\Resources\Defaults for default resources and
C:\ProgramData\MemoQ Server\Resources\Local for custom ones, unless changed as noted above.

Note that the ProgramData folder is a hidden folder by default in Windows, so you may need to change your folder settings to view it.

Light resources stored in both the Defaults and custom (Local) folders are saved without the MemoQResource header one sees in an exported light resource file. Compare the following two screenshots of the same resource in the external editing and maintenance file (with XML comments to help me keep track of what things mean) and the stored file after importing it into memoQ:

My master resource file for German segmentation, maintained with comments in Notepad++

Imported custom resource file for German segmentation. All comments are stripped by memoQ.

So, what should you do if you have 200 projects for your personal work with a memoQ desktop edition or 1500 projects on your memoQ server, and you have a new segmentation rules file, for example, which you want to apply to all of your projects? Simply

1. Copy all the text beginning with the XML declaration
   
   all the way down to the end of the file.
2. Find the default or local resource to update in the paths described above (or in your own custom path) and open the file in a text editor.
3. Select all the text in the installed resource file, and paste the text of the new resource over it, replacing the content completely.
4. Save and close the file.

The changes to your default or custom resource will be active immediately. No need to restart memoQ or close and re-open any projects.

In my case, with the German segmentation file given as an example, I would paste that new content into the resource files for generic German (ger), as well as German from Germany (ger-DE), Austria (ger-AT) and Switzerland (ger-CH). No need to mess with the awful integrated resource editors in memoQ, because I keep a master resource file with explanatory comments to help me maintain it better outside of memoQ, and the segmentation I want will be the same for all language variants.

This method does nothing to disturb the content of existing projects nor does it affect their stability in any way. This should work with any memoQ light resources. Thus, for example, an IT department could plan bulk updates even of local resources like keyboard shortcut or web search settings given the necessary access to user drives on a network.

The approach that many follow of deleting old resources and importing new ones with the same names won't work; this can play Hell with project settings, because memoQ notices that a resource used in projects has been removed, and it does not replace the old assignment with a new one, even if that new one has the same name. I played that game with many variations to see if I could trick memoQ into substituting the same-named resource in my project and had no success at all. Don't go there. Use the process I described above.

Re-importing reviewed translations in memoQ server projects.

One of the unexpected benefits of testing the memoQ cloud server is that it gives me a good opportunity to reproduce and test some of the disaster scenarios encountered when working with project managers not fully aware of the implications of their choices when setting up server projects. Many of the problems that come to my attention relate to revision workflows that many experienced translators like to use.

For various reasons, exporting bilingual formats - XLIFF, Wordfast Classic-compatible DOC or RTF tables - is a popular review method. Sometimes these are checked by others who do not use memoQ, sometimes they are convenient for QA with third-party tools or have other perceived advantages. As far as I know, translators can always do bilingual exports from a local installation of memoQ connected to a server project. (I haven't looked for ways to block this, because I find the notion of doing so extremely counterproductive.)

The trouble comes when they want to re-import the corrected and/or commented bilingual file to update the translation. This is possible only by the project manager working in the management window. There's no way for the translator to import a bilingual reviewed document. I asked Kilgray Support about this and was told that this is intentional because of the difficulties which could result in the project. So basically if you edit a bilingual, someone with project manager privileges for that project has to re-import it for you.

Well, not always. Sometimes it works, just a bit differently than one might imagine.

If the project manager sets up the project to use "desktop documents" (as opposed to "server documents"), then it is possible to export bilingual files and re-import them. This cannot be done directly with documents in the Translation list. But it will work with Views of these documents. Or with the full bilingual exports of the documents themselves!

The screenshot above is from a server project with configure for desktop documents. For these two project types (with or without web translation enabled), when working from a memoQ desktop client you are able to import any bilingual to update a translation file from this interface.

But wait, that's not all!

or is it? That command says "Import" and so devious minds might wonder if it is possible to import something other than a bilingual export from one of your translation documents. Indeed, the dialog that appears for file selection tantalizingly offers all supported formats. So I grabbed a DOCX with a financial text and gave it a try:

SWEET SUCCESS! A mere translator, I've cracked the memoQ server and uploaded another document to my project. Visions of Caribbean beach vacations in the warm sun dance through my head as I contemplate all the extra work I can upload to certain client projects and bill because it is, well, right their on that server project they assigned to me.... then I get this message:

General error.
TYPE:
System.NullReferenceException

MESSAGE:
Object reference not set to an instance of an object.

SOURCE:
MemoQ.Project

CALL STACK:
   at MemoQ.Project.ProjectDocument.TranslationDocumentProjectContext.UpdateDocumentDivisionInfos(TranslationDocumentCore doc)
   at MemoQ.Translation.Storage.SqlCeStorageService.SaveDocument(TranslationDocumentCore document, SavePreferences savePref)
   at MemoQ.Translation.Storage.SqlCeStorageService.SaveDocumentAndAllInfos(TranslationDocumentCore document, ICompactSerializable workflowInfo, ICompactSerializable tagDefinitions, ICompactSerializable lqaModel, SavePreferences savePref)
   at MemoQ.Project.TranslationDocImportExport.LocalImportController.doImportOrReimport(ImportTask importTask, String targetLangCode, String docStorageDir, Boolean reimport)
   at MemoQ.Project.TranslationDocImportExport.LocalImportController.DoJob()

That's Geek for "Nice try, buddy... an automated report has just been sent to the NSA and our agents will be at your door shortly." I click again, and that message self-destructs and I am given a second warning:

A knock on the door, then after a stern interview, I sink back into my desk chair and click Continue. Next time I'll stick to importing bilingual exports of documents or views from the project. That works beautifully from the View tab and allows me to work as I prefer, since by now most of my clients with memoQ servers know to use the desktop documents options for my projects. Perhaps in the future, Kilgray's programmers might tighten up the code to trap errors from fools like me who do the unexpected.



But of course, as of memoQ 2013 R2, when translating with the desktop client in server projects, one can usually update a translation with minor edits using the reviewed monolingual target document and the Import reviewed document command in the Translations menu of the project. This won't let you bring in comments, and it does have some (but increasingly fewer) quirks, but in many cases it works quite nicely. A video demonstration of this feature can be seen here.

Proofreading LiveDocs bilinguals, recycling versions in memoQ

(These tests were performed with memoQ 2013 R2 but should, in principle, work the same in any version of memoQ 6.0 or later.)

I really like memoQ's versioning features, and I use the X-Translate function fairly often when a document I'm translating has been updated or a new version comes sometime later. However, I don't keep documents in my projects forever. I use "container projects" for particular clients or subject domains so that I don't have to keep reattaching the same translation memories, terminologies and LiveDocs corpora and various light resources (non-translatables, autocorrect lists, segmentation rules, etc.) all the time. These can get rather full, so I send my old translations off to a LiveDocs corpus after a while. And then if a new version of a document shows up, well... I'm sort of out of luck if I want to use the X-Translate function with the previous version.

Or so I thought. And then a friend rang me and asked how she can export a LiveDocs alignment she did to an RTF bilingual file to make it more convenient to proofread in Microsoft Word and pass on to one of her partners with tracked changes. With that the answer to both problems was clear.

Select the corpus and the file in it to export:

Click Export and choose a location in which to save the MQXLZ file:

In the Translations window of any memoQ project with the correct source and target language settings, select Import and choose your MQXLZ file:

After the file exported from LiveDocs has been imported as a translation file, it can serve as "version 1" for a new file version to be translated using the Reimport document and X-translate features. It does not matter that the file types are different. A bilingual RTF file can also be exported for external correction and commentary.

Here is an example of an exported bilingual RTF file with changes tracked. The changes do not have to be accepted before the bilingual file is re-imported to update the translation using the Import command.

Here is the updated translation:

Changed are marked with blue arrows. Only text changes were implemented in this case, no format changes such as italic text, because the XLIFF file does not support WYSIWYG text formatting. (MQXLZ is a Kilgray-renamed ZIP-package with XLIFF and a chocolate surprise inside.)

Now I've got a new version of my text to translate in a DOCX file. I use the Reimport document function, answer No to the dialog so I can select the new version at a different location:

I'm curious what the differences from the original text are, so I use the History/reports command in the Translations window to find that out:

Then using Operations > X-Translate in the working window, followed by pretranslation to get the changed "exact matches" (like "Aussehen und Gewicht" above) and the fuzzy matches, I end up with this:

If you make it a point to store your important versions in a LiveDocs corpus, this procedure will allow you to recover your archived texts and re-use them for more controlled, reference-based translation. It would be nice, of course, if some day Kilgray would enable specific LiveDocs files to be used as the basis of a reference translation, perhaps even scanning a corpus or a set of corpora to identify the best-matching document or documents. It would also be nice if bilinguals stored in LiveDocs could be exported to other formats and perhaps even be updated with something like an exported bilingual RTF. However, those bilinguals can simply be imported directly to a LiveDocs corpus as new documents, and any corrections made to a document in the Translations list can be sent back to LiveDocs using the relevant command in the Translations window.

The Next Big CAT Feature To Copy?

Thanks to the persistent disbelief of some users, particularly cranky financial and legal translators who don't understand the challenges of programming, that it really is "impossible" to enable a project or TM update based on an edited monolingual target text, Kilgray has decided to just do it and make this feature available to the masses with the next release, memoQ 2013 R2. It's not a perfect solution, but a great start, and when the rest of the specification is implemented later, it will be really, really good.

Here's an example of the first step reimporting a short text in which every sentence except the first was rewritten and rearranged (click the pic to see it full-sized):

This monolingual alignment and the matches it assigned was totally automated - no adjustments by me. When applied to the translation document in memoQ, it doesn't change the order of the translation, but it does make updating the translation memory much easier. I can also use the tracked changes feature for versioning to look at the edits in more detail, and the view can be filtered to show the changes in a large document more clearly to ensure that nothing was missed.

What good is this? Well, so far Kilgray is rather fixated on the idea that one might receive edited documents from a proofreader or a client at some later date and import the changes to the project to update the TM. Maybe, but in many cases, this won't really happen in my workflow. If I finish I project, now I very often send the documents to a LiveDocs corpus, where they make a marvelous pseudo-TM (if a bit slow or slower sometimes) and an excellent context reference for concordance searches. I then delete the documents from the project, because I use projects as "containers" for repeated business, so unless some day the monolingual updates are made available for a document in LiveDocs, I may often not be able to take advantage of it. One could, of course, apply the same principle of monolingual alignment to a translation memory or even a TMX file, and I am sure somebody will do that before long if it doesn't already exist in some flaky academic freeware for supernerds somewhere.

So why am I so excited about this feature? Because I already use it every day. It saves me time and puts a big smile on my face. When I get ready to deliver  translation, the last step for me is to look at it in the source application - Microsoft Word, PowerPoint, etc. There I make last-minute adjustments, change words, combine sentences, split sentences, delete things, etc. A lot of these changes never make it back to the TM, because that maintenance can be a major pain in the backside, especially when there's a lot happening on my desk and in my e-mail inbox. This feature is a big step toward reducing that stress.

Kilgray isn't done with this by any means. Plans for source text merges to allow combined sentences in an edit to be handled easily have not been implemented yet, but I'm told that will follow no later than the next version. I hope so. The current beta version is also a bit dodgy with many formats I've tested so far beside DOCX and TXT, and changes of target text file type have been forbidden in the current version, as have any edits except segmentation adjustment and linking during the monolingual alignment.I plan a lot more testing to understand the limits of the current implementation, and I expect there will be many improvements in this area. But this is an excellent start.

When the specification was developed, Kilgray was unaware that something like this was already available from SDL in one of that company's pricy "regulatory" licenses (I wonder if the idea came from watching the video of the public argument about this option at memoQfest two years ago - I know that remarks about the SDL OpenExchange were followed closely). However, SDL has taken no great advantage of this to offer such a feature to a wider user base yet, so I have no idea how well it looks. But mark my words - in a few years, this innovation will be one of those things that users of any good CAT tool should take for granted!

Translating SDL Trados Studio SDLXLIFF files & more in memoQ!

My latest demonstration video actually covers a number of memoQ features so that I would have an excuse to create this video index:

Time  Description
0:32  Importing the first SDLXLIFF file to memoQ
1:12  Exporting the finished translation
1:27  Viewing the translation in SDL Trados Studio 2009
1:40  Re-importing the edited translation for a TM update
3:24  Saving the translation in a LiveDocs corpus for later reference
3:55  Importing a new version of the text in an SDLXLIFF source file
4:25  Comparing source text versions
5:55  Document-based pretranslation ("X-Translate")
7:11  Examining a "warning" for forgotten tags
7:46  Results of the second translation in SDL Trados Studio

That is the sort of thing I was talking about in a recent blog post about new approaches for online instruction. Many times I have wished for just such an index for long webinars or even much shorter reference videos like this one.

This tutorial was inspired by a Skype chat with a colleague in the US a few days ago. She uses memoQ but works with a number of others who use various versions of SDL Trados Studio, and there were some questions about about how one might deal with TM updates after a translation as well as the inevitable new versions that legal and financial translators often encounter. 

I have also noticed that quite a number of people are not up to date on SDLXLIFF compatibility with memoQ; this video also shows that former issues with preserving segment status have been taken care of, and everything now works well.

What is not obvious in the video is that one can also change the segmentation of the SDLXLIFF in memoQ; this happens only in the memoQ environment to allow better translation and more sensible translation memory content, and when the SDLXLIFF file is exported from memoQ, the original segmentation from Trados is preserved in the Trados environment.

Also not shown in the video is how I imported a third version of the source text, this time as a Microsoft Word file, not an SDLXLIFF. The document-based pre-translation (X-Translate) worked perfectly, and the target file was exported in the proper format (DOCX).

There are, of course, many other ways one could handle a "project" like this, but the procedure shown is not unlike what I sometimes do in projects myself.

********

I apologize for the quirky click animation in this tutorial; Camstudio had some problems I have never encountered before, and I'll have to get to the bottom of that if I keep using that tool. Otherwise, the video quality is probably the best I have achieved so far, and I would like to thank the friend who revealed the "secret" of better quality video for YouTube.