|
A
number of reviewers have already mentioned that memoQ 2014 R2
should have been called memoQ 2015 instead: a major new
"version" instead of a minor "release" upgrade. In a way I agree, but
this whole naming game really just turns out to be semantics when it
comes to a tool like memoQ, which allows free updates to
whatever version to users with a maintenance contract (which in turn it
strongly encourages its users to own). Plus, its main competitor, SDL
Trados, has also had a policy recently of making rather major minor
upgrades, so it fits within that pattern as well.
Fact
is, that there is quite a bit of new stuff in this version of memoQ.
You
know, we've been talking a lot about the world of translation as still
in its infancy and quite immature, but I think there are some signs for
real maturity. One, of course, is that the technology we use is
maturing (of course, you expected me to say that in the context of this
journal), but another is that our voices are getting stronger. For the
last release of Trados Studio, I skipped writing a review and
instead listed a number of third-party reviews that gave a good
comprehensive overview of the new version's benefits.
For
the new memoQ it's quite similar: some of the external reviews
are just really great. Gone is the bickering about competing products
that all too often marred reviews of translation environment tools or
the fan boy's or girl's rosy glasses; instead, those have been replaced
with some strong and intelligent views.
Here
are some of the reviewers and their blogs:
Still,
let me add a couple of comments about this new version of memoQ
that might not have been highlighted (and some that underscore what the
other reviews include).
Yes,
it's a big version, and here are the major new features:
- The user
interface has changed and is now ribbon-based.
- Approaches to
segmentation have been completely overhauled.
- The editor
for translation memories has been redone and improved.
- It's possible
to share translation memories and termbases with other translators in
real-time, even if you "only" have the Professional version.
As
many of you know, I always liked the ribbon interface -- even in the
early far-from-perfect MS Office implementations -- and I liked
it even more when it became more interactive and customizable in later MS
Office versions. I also thought it was remarkable and far-sighted
when Star Transit presented everything in a ribbon interface
much earlier than any of its TEnT competitors, and I welcomed Trados's
and Déjà Vu's moves as well.
The
kind of ribbon that memoQ is now using is quite similar to Office
(especially the "File" menu, or in memoQ's case, the "memoQ"
menu). It allows access to general options and licensing data,
including the crazy left-arrow at the top that's supposed to bring you
back to your project, which is located on the right-hand side of your
screen. (If you think this is an inconsequential and slightly cranky
comment, you're absolutely right -- I am feel old and reserve
the right to be cranky!)
What
is different and really q uite clever about how the memoQ
developers implemented the ribbon is that it's task-oriented (which is
the very concept of the ribbon) as well as process-oriented. You can
read about this in virtually all of the reviews mentioned above so I
don't need to repeat it here, but I would venture to predict that
Kilgray has set the bar for how ribbons should and will be used when
dealing with something as process-oriented as translation.
I
also really like the newly developed icons (though I wish they hadn't
used the silly "smiley" for a number of icons -- yes, cranky again),
but I naturally miss the "Do not push this button" button that's been
lost in the shuffle. In her blog, Emma said this is a sign that memoQ
has grown up. Unfortunately, I think it's a sign of a new generation of
developers with a more business-oriented approach. I really hope it
will pop up again in some later version. (In case you don't know what
I'm talking about, there used to be an entirely useless button that not
only invoked a clever quote from the Hitchhiker's Guide to the
Galaxy but also a lovely cuckoo sound whose levity and, yes,
uselessness often seemed to halve the burden of whatever translation
the user was battling.)
Accompanying
the change toward ribbons has been a serious cleanup of the memoQ
interface, which I had long found way too cluttered. It's nice
now that the ribbons expose features that many users might never have
known about, plus there's ample explanation space with well-written
tool tips.
One
downside to memoQ's ribbon is that, like Trados's but
unlike Déjà Vu's, it's not customizable. When I
talked to Kilgray's Gábor Ugray about it, he promised that the memoQ-specific
Quick Access ribbon will be customizable in the
future.
Segmentation
(i.e., how texts are segmented and abbreviations are correctly
identified as non-breakables) has been improved in two ways: First, the
previously ridiculously complicated segmentation editor is now actually
human-readable (!). More importantly, though, they've come up with a
feature that allows the user while preparing for translation to run a
check for abbreviations that may not have been identified correctly in
the respective source language, add those to the list of abbreviations
(so they will be considered in later projects), and then -- and now
comes the trick -- resegment the current project or document with that
new rule in place.
If
abbreviations were not found automatically, you can highlight them, add
them to the list of abbreviations, and then also resegment. Very
clever. (I'll bet any of you 10 bucks that by the end of this year at
least two other tools will have this feature also.)
On
to the new TM editor. A little while back I received this communication
from John Musters:
"In my
dual role of internal localiser/memoQ support specialist (...),
I've been spending tons of time + energy helping people with the
cumbersome task of editing/reviewing existing memoQ TMs. As you
might know, this is close to impossible using memoQ's built in
features."
(And
then John recommended the "recently-made-freeware Heartsome
TMX Editor" -- which
I talked about a few months ago.)
So,
yes, memoQ's TM editor was, like most of its competitors,
rather poorly designed, making it welcome news that it's been reworked
significantly (see here for a good description). I'm not sure whether
it'll be good enough for John -- but it'll suffice for most others.
And
on to the last thing: Resources that can be shared in real-time without
extra cost. "You can create up to 4 TMs (two pairs, each in a specific
language pair and its reverse), and 2 multilingual TBs with up to 5
languages. Each resource can be shared with one other person with write
access, and two more with read-only access. The size of TMs and TBs is
limited to 50k entries." This is what it says in the memoQ help
file, and it's very generous in its own way.
What
may not have been discussed fully in this context is something you can
find in Kilgray's Privacy Policy for the Language Terminal. (To be perfectly
clear: Kilgray is not trying to hide this as Gábor specifically
mentioned this to me.) There it says this:
"If you subscribe to the translation memory and
term base sharing service, Kilgray reserves the right to mine your data
to improve their products in different language pairs. Entire segments
or confidential information will not be disclosed to third parties, or
included in the product. If you do not agree to this, do not use the
translation memory or term base sharing service, but rather consider
subscribing to a memoQ cloud server with one project manager license,
where Kilgray does not analyse your data."
Now,
this is not all that different from what Google or Microsoft does with
your data when you use their machine translation services, so it's an
interesting arena that Kilgray is entering.
A
few months ago I pressed SDL about whether there is any way that they
would use data processed in the cloud by their machine translation
engine. They were outright incensed that I would even think about that
option (so much so that they haven't really talked to me since). Since
we know that SDL does not mine and analyze data provided by its users,
it does make me wonder what Kilgray's move will do to the whole concept
of using proprietary data for linguistic mining purposes. Will there be
an outcry of some kind? There certainly does not have to be -- after
all, Kilgray tells you what to do if you feel this is not a prudent way
of dealing with your client's data: don't use that feature.
Still,
I'd like to see a discussion about this, and I imagine that Kilgray's
competitors would, too.
And
in a wondersome manner, this brings us right into the next
article....
|
