Getting around language variant issues in memoQ LiveDocs

I was told by some other users that a fundamental change had been made in the way language data are accessed in LiveDocs. It was said that until a few versions ago it had been possible to use documents for reference in LiveDocs regardless of their sublanguage settings. So I was told. The truth is more complicated than that.

According to my tests, memoQ 2015 is the first version of memoQ to have a logically consistent treatment of language variants for both bilingual and monolingual documents in corpora. All the other versions tested (memoQ 2013R2, 2014, 2014R2) are equally screwed up and show the same results.

The "visibility" of a monolingual or bilingual document when viewed in a corpus attached to a project running under memoQ 2015 follows these rules:

• the sublanguage (language variant) settings for source and target (of the document or the project) must match the project
• or the language setting (of the document or the project) must be generic. 

Two rules. Pretty simple. It doesn't matter what version of memoQ the project or corpus was created in, only which version is actively running.

I created a test corpus with the following document mix:

The corpus contained 11 documents, both bilingual and monolingual with a mix of generic language settings and settings with language variants specified (such as German for Germany, Switzerland and Liechtenstein and English for Zimbabwe, the US and UK). 

In a project running under memoQ 2015 with the languages set to generic German and generic English, all 11 documents in the corpus were accessible. 

So if you want access to all LiveDocs corpus data for the major languages of your project, it is necessary to use generic language settings, either when you load the data into LiveDocs (difficult unless you always use the resource console, since adding documents to a corpus from within a project automatically applies the project's language settings!) or in the languages specified for the project itself. And this will only work with memoQ 2015. If you want to apply penalties to particular language variants this can be done using keyword markers (as seen in the screenshot above) and configuring the More penalties tab of the LiveDocs settings file applied to that corpus.

If the same corpus is attached to a project running under memoQ 2015 with language settings for Swiss German and generic English, the documents available from the corpus are these:

For a Swiss German and UK English project under memoQ 2015, this is the picture:

And for a Germany's German and US English:

 All the screenshots above can be predicted based on the two rules stated. Work it out.

"But what happens with earlier versions of memoQ?" you might wonder. It's messy. Here is a look at a Swiss German and UK English project under memoQ 2013 R2, 2014 and 2014 R2: 

And here's a project with generic German and Generic English under memoQ 2013 R2, 2014 and 2014 R2:

In each case the five bilingual documents are visible no matter what the project's language settings are. However, there is strict adherence to language variants and the generic language setting for monolingual documents! In my opinion, that's for the birds. I see no good reason to follow a different rule for data availability in bilingual versus monolingual documents. So in a sense, Kilgray has cleaned up this inconsistency in the latest version of memoQ.

Some have expressed a desire for a "switch" setting to allow language variant settings to be ignored. And perhaps Kilgray will provide such a feature in the future. But the best way to get there now is simply to make your project's language settings generic.

Changing the language settings for bilingual data in an existing LiveDocs corpus 

If you have a corpus with a mix of language settings and you want to convert these to generic settings or a particular variant, this can be done as follows currently only for bilingual documents:

1. Select the bilingual documents to export from the corpus and export them to a folder. (If you choose to zip them all together, unpack the *.zip file later to make a folder of the exported *.mqxlz files.
2. Re-import the *.mqxlz files to the LiveDocs corpus via the Resource Console so you are able to specify the exact language settings you want. In the import dialog, you'll have to change the filter setting manually from "binary" to "XLIFF". These *.mqxlz files are not the same as bilingual files from a translation document in a project and are not recognized automatically.

Unfortunately, there is no way to change the language settings of a monolingual document except to re-import it in the Resource Console in its original form and set the language variant (or generic value) there.

So really, for now, the best way to go seems to be to use memoQ 2015 with generic project language settings.

memoQ 2014 Release 2: beware of Hungarians bearing updates!

Just kidding, actually. Facebook groups are, of course a buzz with tales of bugs and crashes the day after Kilgray's milestone release, and in my own office I heard a flurry of curses behind me as my Portuguese translator discovered the "can't quit" bug that someone had written about. This was just a short time before I delivered the last files for one of the busiest weeks of translation I've been hit with in months, weeks where I decided to live dangerously and do all the work with the bleeding-edge beta for yesterday's release. For me it was actually a rather bloodless experience.

Sure, I saw bugs. Screen refresh weirdness in the first few beta builds and my favorite (non-lethal) quirk: multiple instances of memoQ web search. I guess the developers figured we can't get too much of a good thing!

Triple play, anyone?

I didn't write as much about this release as I intended to originally, partly because I was too busy, but also because I took a very different approach this time, using the beta opportunity to do a little informal psychological research to support some upcoming tutorials I'm working on to help people make a smooth transition to the new interface and cope better with the costly challenges of flipping between versions if required to by some projects (for example with conservatives who still use old memoQ servers.

Those who are not absolute newbies on the technology scene are well aware that the months after any release from any provider of translation technology are always a risky time for those eager to get started with a new version. The prudent advice to anyone is don't hurry. There's no use slamming Kilgray or SDL or anyone other firm for the inevitable bugs after any release, at least not until two or three months have passed and the version has put through the real-life wringer in a way no testing program can do. After that, fair game as far as I'm concerned. Those first months are usually a critical time in which many improvements not even anticipated by the designers occur. So regardless of the official line, people, for the next three months any of you using memoQ 2014 R2 are beta testers. And that's a good thing, a chance to participate in a good development process. SDL Trados Studio users, DVXn fans and everyone else are on more or less the same curve each time a big upgrade hits.

In my beta test over the past month I made few attempts to explore new features. Instead, I focused on my usual workflows to see how they felt in the new environment. As I indicated in my first blog post on this release I was not entirely comfortable after a week of work just with thew new version. And I'm still not. I am less productive than I want to be, because changing the translation environment interface is always a costly process associated with reduced productivity. This is why I am such a strong advocate of interoperability and tell people to go deep with their environment of choice and learn how to work with information prepared in other environments with just your favorite tool for maximum efficiency and better earnings if you work at full capacity.

What I have learned so far is that this learning curve will be longer and steeper for me than I anticipated. However, the Kilgray ribbon designs for the new memoQ are well-designed for the most time, and I can reason my way through them and find anything. It just takes time right now. So make the transition when you aren't going to be under the gun for a while. Kick the tires soon (you can install versions in parallel at no risk) but take it slow and easy. The trip may be long, but it is clearly worth it in the end for a design that will benefit most in the long run.

And focus on keyboard shortcuts. The more you depend on those, the easier your work will be in the months ahead. Stay tuned.

My first project with memoQ 2014 Release 2

When I got my first look at the test version of the upcoming memoQ release, memoQ 2014 R2, I argued with  Kilgray that it ought to be called memoQ 2015 instead, not only because the year 2014 is almost over, but because this software represents a major break with the old interface design. Kilgray likes to point out that there are not so many new features being introduced here - perhaps a mere "dozen" give or take a bit - but just one of these - the new ribbon interface - has its own 50 page manual. Meu deus.

On the whole I am coming to view the rapid pace of development for some CAT tools in a rather negative light. I rather like the current memoQ 2014 release, but I am not even close to coming to grips with the 70+ new features introduced earlier this year (which has probably grown to 100+, depending on how you want to count them). I think back to my experiences as a corporate systems consultant in the archiving and document management sector and those working with a state department of transportation before that, where many thousands of networked workstations and other systems had to be managed for maximum productivity and minimum disruption. It took me a while back then to understand why, after many months of thorough testing at enormous cost, an upgrade for  something like Internet Explorer was permitted for the version two whole numbers below the current one. I eventually learned that these big organizations were not so dumb after all: being on the "leading edge" is too often the same as the "bleeding edge", which can have considerable, unanticipated costs.

This is the reason why for years I have advised my clients and colleagues not to consider new versions of any tool for routine production use until several months at least past its release date, and to use "roundtrip testing" in every instance to ensure that a technically usable result can be obtained from every project. Ultimately, Kilgray and others are going to have to determine whether constantly stirring the feature pot in a way that too often makes established workflows obsolete is in the best interests of their clientele and market future. Despite all the trendy talk of the benefits of disruption and "creative destruction" I am unconvinced that this is the case.

However, I do see very good reasons for the major changes to the interface in memoQ 21014 Release 2, and I think that new features like the limited sharing of online translation memories and termbases (with an open API in the future to allow access by other tools I'm told) are an excellent intermediate stage for those who aren't quite ready to move up to a team server solution like memoQ Cloud or the greater access capacity of the full memoQ Server license but who still need realtime data sharing for projects with a partner from time to time.

Kilgray's blog has a good post describing the basic shift in the logic of the environment from cataloging commands as one might in a library or inventory system to organization by the normal sequence of work. This makes a lot of sense, and this is also the way I teach new users to use the software, with small sets of features organized according to the sequence of typical work.

After spending about a week just staring at the new ribbons, I decided to do my first small, low-risk commercial project with the test version. Everything went quite well, but I had to fight a sense of disorientation as I kept looking for commands in the lower area of the screen, which is now free for viewing more files and file information in a project. In some cases, I had to get used to clicking on the little arrows under icons rather than the icons themselves. Nothing I needed was difficult to locate, but as a longtime user of memoQ with many ingrained habits, I will take some time getting used to this, after which my work will probably proceed even more smoothly. In any case, it is clear to me that new users will find their way more quickly with this new, workflow-based interface.

This impression of greater ease for new users was reinforced by remarks from a colleague in my office a few days ago. Her professional background prior to her activities in translation was as an educational psychologist and adult education teacher, and when I began to complain about how awful the new ribbons were and how uncomfortable I felt with them, she patiently explained how I had it all wrong and why the new design was much more logical and easier to use. Years ago I teased SDL Trados users who bitched at first about the change from the nasty old over/under TWB interface to the tabular working environment of SDL Trados Studio only to become enthusiasts later when they realized how much their workflows had improved; I fear that I will also become a just target for such teasing.

I don't want to admit it, really, but I am already beginning to like those awful ribbons, which are perhaps rather useful after all. And if I really don't want to look at them, they can be hidden with just a click, leaving me with even more working space on my screen. So all right, I'll say it. Reluctantly. Good job, Kilgray.

Now who is going to re-do all the screenshots and videos for my tutorials?