"New Beginnings with memoQ" tutorial guide released

The initial version of my new tutorial guide for memoQ has finally been made available through the distribution site I use for convenient promotional distribution. Those interested in this 101-page PDF e-book can see more details or purchase it by clicking on the cover graphic above. A table of contents for this edition can be downloaded here. Many of the discount codes distributed by myself or Kilgray in the past year or two can be applied to anything on that site, including this volume.

The book is organized in three sections. The front part gives a quick guide to navigation in the old and new memoQ interfaces (because even those who have purchased memoQ recently may have to come to grips with older versions to do some server projects for customers using older releases). Then a series of four "job" chapters introduce common, fundamental concepts for basic work and safe data management in the memoQ translation environment. The last section, an appendix called "This & that" covers about a third of the total page count with a great variety of supplemental information to help new and experienced users come to grips with many challenges for working efficiently with this translation environment.

The appendix includes a glossary of terms to "de-nerdify" things a bit as well as an overview of some of the most important or useful features introduced for individual translators in recent versions. I added the latter because I often advise people about which versions to upgrade to for particular features, and with the rapid development of memoQ this is not easy to keep track of!

Until very recently I never considered doing instructional materials specifically focused on new users and their needs because of the large number of people offering beginners' instruction. However, as my conceptual collaborator in this guide and I observed, the feature-focused approach used by many instructors often confuses and intimidates users and sometimes fails to address basic matters needed for their routine, productive work.

The approach here focuses on workflows and possibilities for application rather than features. And because of the challenges many experienced users of memoQ face adapting to the recent changes in the interface and the many new possibilities for the memoQ translation environment, I called the book "New Beginnings" because it offers everyone a chance for a fresh start for better productivity.

Setting memoQ to run as a 64-bit application

It has been so long now since 64-bit versions of the Windows operating system were introduced, allowing access to more RAM and adding other efficiencies to the systems we use. So imagine my surprise today when, after a recent memoQ build upgrade, all Hell broke loose in the midst of a time-critical project, with crashes every five or ten minutes

and interesting views of the working translation grid like this one:

Of course all this happened as I was doing a time-critical translation, dictating at top speed to meet a tight deadline for a last-minute legal matter.

So I send a quick cry for help to support@kilgray.com, and in a short while I got a question back, asking whether I was running in 32-bit or 64-bit mode. "What a silly question," I thought. "64-bit, of course!" Wrong, actually.

I don't know why, but it seems that memoQ upgrades are currently configured to run in 32-bit mode. And depending on what kind of work you are doing, that can have unfortunate results. Working with my version of Dragon NaturallySpeaking today it was an absolute disaster that caused me to lose half my working time and sweat buckets right up to the delivery.

There are two executable files for memoQ in the program folder: MemoQ32.exe and MemoQ.exe, the former obviously for 32-bit systems and the latter not-so-obviously for the more typical 64-bit systems for our times.

I checked the properties of the shortcut I use to launch memoQ

and 'shore 'nuff

there was the problem. So I edited the "target" field, which tells the shortcut what to run:

and lived happily ever after for the rest of the afternoon. The worst problems I have seen with a CAT tool for a decade were resolved.

"But how do I know if I have a 32-bit or a 64-bit Windows operating system," you might ask. Good question. Most translators answer this by disemboweling a black chicken and examining its entrails, but being an advocate of better treatment for animals, particularly oppressed chickens, I researched a better way.

The answer can also be found in the Windows Control Panel in the System control. The screenshot from my Windows 7 Ultimate version is shown above; other versions may have a slightly different display, but the System control is where you should look in any case.

*******

P.S. - In my correspondence with Kilgray Support, the engineer helping me had suggested a one-off start of the memoQ.exe application (64-bit memoQ) from the program folder. I thought this was a bit of a hassle, and I questioned why he would propose such a thing and why the 32-bit application would be a default now. I received this response:

" ... this is by design: by default memoQ will start in 32-bit mode to ensure better startup and better user interface performance. But you can start memoQ 2014 R2 or memoQ 2015 in 64-bit mode, which is useful for heavy operations which requires several gigabytes of RAM."

All very well and good... those who do mostly lightweight stuff can go for the default and perhaps have a special shortcut for the "heavy lifting" memoQ version. The problem I see is that most users are not going to know what sucks up a lot of system capacity and may require the 64-bit application.

I suspect that large TMs or other big resources, things like predictive typing (commonly in use) and certainly the use of speech recognition software is going to make a crunch. I am unaware of any discussion (to date) which is publicly accessible, which will make clear the line that is crossed to require more memory access. Most of the professionals I know tend to use memoQ in a rather resource-intensive way, and I am unclear what the recommendations should be here. 

P.S. #2 - Kilgray responds to questions on 64-bit versus 32-bit on the Yahoogroups forum: https://groups.yahoo.com/neo/groups/memoQ/conversations/topics/41676. Due to access difficulties with Yahoo's sucky Neo interface, some of the message thread is included here:

Dear All,
I'll try my best to clarify how memoQ relates to 32-bit and 64-bit.
1. Use 64-bit if you expect "heavy" use
memoQ is a "hybrid" application that was designed (at least from maybe version 6) to run in 64-bit mode on a 64-bit system and 32-bit on 32-bit systems. The support for 64-bit mode was added to avoid out of memory issues with "heavy" use, like importing very large documents. (I clearly remember that one of the use cases was importing large FrameMaker documents. Most probably the other most significant use case was memoQ server in general, which, depending on how it is used by how many people, may have to do many things at once and load an enormous amount of resources.)
A 32-bit application is limited to 2 GB of memory regardless of how much memory is available on the system, while a 64-bit application is practically umlimited (technically there is a limit, but it is enormous). One could argue that 2 GB of memory use is not likely in memoQ anyway, but actually there can be short spikes, during document import or when loading a translation memory, for example. There are also further details that complicate this, like memory fragmentation which are frankly too technical for me, but, as far as I understand, they mean that an "out of memory" error is still possible when there seems to be enough memory overall, but not enough "continous" memory for a specific operation.
These kinds of issues are rare in 64-bit operation and more common on 32-bit operation. This means that with 64-bit memory. This means that with 64-bit memoQ you are less likely to get out of memory errors. Use 64-bit memoQ if you expect "heavy" usage or if you have run into out of memroy errors. If you have, the error message displayed by memoQ most probably already advised you to go 64-bit.
2. memoQ is 32-bit is more snappy
Most modules of memoQ are based on the .NET framework and is written in "managed code" that runs under the Common Language Runtime of the .NET Framework. Sorry if this is too technical, but the point is that memoQ itself is (mostly) intermediary code that must be "translated" (compiled) to code that a computer can actually execute, right when the program modules are loaded to memory. The piece of software that does this compilation is called the Just In Time (JIT) compiler. It is the JIT compiler that creates either 64-bit or 32-bit machine code, as required.
The JIT compiler in recent versions of the .NET Framework simply performs way worse when creating 64-bit code than 32-bit code. (Most probably the compilation itself is slower on 64-bit than 32-bit, or it is possible that there are performance issues with the resulting "machine code" itself.) This is a widely known problem, and Kilgray has done elaborate research to confirm that this is why memoQ starts up slower (by approximately 100%) in 64-bit mode than 32-bit mode. It is also likely that some of the interface is also slower in 64-bit than 32-bit. We are also convinced that this was a very signifcant issue to the user base, and has led to unfavourable comparisons to the competition (which I think is at a dubious advantage here in the sense that they don't offer a 64-bit mode, as ar as I know). The good news is that Microsoft has been working on the problem and they have created a brand new JIT compiler for version 4.6 of the .NET Framework. So whenever memoQ gets upgraded to .NET 4.6, 64-bit will see a performance boost.
It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true, at least in terms of loading and "JIT compiling" program modules. This can heavily affect startup times, for example.
Best regards,Gergely

I left out the part that is (hopefiully) obvious by now to many of you, and something I have explained here before, maybe twice or more:
As an answer to the performance (especially startup speed) concerns, in recent builds of memoQ, we turned off the autoamtic "hybrid" behaviour that detected the 32 or 64 bitness of the system, and created a separate 32-bit executable (and a start menu/screen shortcut) to start memoQ with. With this you can force memoQ to run in 32-bit mode. This is also the default in the sense that if you just click "memoQ" in your start menu/screen. you start the "forced" 32-bit mode. There is also a "memoQ (x64)" shortcut you can click to enable 64-bit mode on 64-bit systems.
Also, another piece of advice: for users with beefy systems the perforamnce degradation caused by the 64-bit JIT compiler may be completely irrelevant, as memoQ may start up for you in maybe four seconds instead of two. If you have such a machine, 64-bit might be a very good choice. And you get some protection from "out of memory" issues.
Another piece of advice: please don't switch to 64-bit mode if you do not have a beefy system and you are not having any issues with memory use. This might just slow your copy of memoQ down with no benefit in your specific case. Switch to 64-bit if you know you are affected by "out of memory" issues, or you expect some heavy use (very large resources or translatable files, etc).
Gergely

Message 3 of 3 , Today at 12:49 PM 
"It is a myth that 64-bit most always perform better, and in the case of .NET (before version 4.6), clearly the opposite is true"
Really glad that, despite this, Kilgray kept the 64-bit support. The 32-bit version caused out of memory errors for most of our translators after ~15-30 minutes of use, causing a lot of confusion after 2015 hit, until we found the 64bit version :D
wolfschoe 

Introduction to memoQ in Lisbon / Introdução ao memoQ em Lisboa

From July 6th to the 11th, the summer school of the New University in Lisbon will offer a week-long introductory course for memoQ 2015, which includes:

• The functional modules of the memoQ translation environment and how these work together;
• Common workflows for translation and editing tasks;
• Making use of legacy translations and data from other environments;
• Collaboration with users of other translation environments (SDL Trados Studio, OmegaT, etc.);
• Tips for problem-solving and added value for translation customers.

The course will be taught by me an Professor David Hardisty, with whom I have spent most of this year so far exploring innovative speech recognition and editing workflows, which will also be an important part of this course. It's a pleasure to work with David, because not only does he have a strong commitment to the success of his students, but he has a marvelous talent for taking my concepts and recasting them in a way that work really, really well for undergraduate and graduate students at all levels.

The course is open to anyone (limited enrollment, 16 persons I think) and offers 24 hours of instruction in the week. It will be taught in English with summaries in Portuguese.

A description of the course in English and Portuguese is here. I am not responsible for the errors in the English. Registration information (Portuguese only, alas) is on this page. Attendees who don't read Portuguese but manage to figure out how to register nonetheless will receive a special reward during the course.

During the week, the course is offered in the evenings, leaving the days free for work or local tourism. It is recommended that translators make a pilgrimage to the monastery named after the patron saint of translation in Belém. Miracles have occurred there, carpel-tunnel syndrome has been healed and dead text has even come to life, but not even the intervention of St. Jerome can save a machine pseudo-translation. You might learn that trick from us, however. Or not.

On August 3rd a course on project management with memoQ will be offered on a similar plan.