The memoQ 2013 release started off on the wrong foot with me in many ways. I was deeply disappointed by the features that were previewed in Budapest at the last memoQfest, and I was even less happy after I saw what a hash had been made of one of the features I use most: comments. In fact, I wrote a rather annoyed blog post about that not long after the release. There was a lot of talk about "game-changing innovation", but frankly I really could not see it. My translating colleagues asked me if it was worth it to upgrade, and aside from my usual warnings about the need to wait for at least 2 or 3 months after any release for it to mature and stabilize, I just could not find any compelling arguments for a freelance translator to move from the stable, excellent 6.2 version to the rather dodgy 6.5 version, or "memoQ 2013" as it was rechristened.
Almost on the usual schedule, however, two months later the bugs were largely sorted out, the initial mistakes in the comment feature redesign were well fixed, and I no longer saw the memoQ 2013 release in the same dim light, but could actually see some benefits for my freelance colleagues to upgrade to that version and no actual harm in doing so. And as I got to know the fuzzy term matching feature better and saw how it helped me deal with typo-laden source documents or the usual spelling chaos of German technical writers, I began to see some very compelling value in memoQ 2013 for translators.
Most of the "game changers" talked about in May actually arrived a month ago with Release 2 of memoQ 2013. I did my best to lower expectations for this release, not because I think it is crap, but because I think this is one of the best CAT tool version upgrades I have seen in 13 years, and I knew it would need the usual time to mature. I think by the end of the year this version will have so much to offer that I would rather not have people stressing over the small stuff that I am confident will be fixed well.
However, I decided to live dangerously, and I switched over all my production work to use this version even before the official release. The first few weeks were not fun with all the little quirks I discovered and duly reported, but I encountered nothing data-destroying or really shocking, mostly just housekeeping details like somebody forgetting to vacuum the rug after gutting the whole house and giving it a nice remodel.
One month after the official release, memoQ 2013 R2 is far more reliable than I remember any memoQ version being one month after release. There has been steady refinement in its features, and I continue to discover hidden gems that I sometimes suspect most of the Kilgray team aren't even aware of yet because so much was added and changed, but not in a way that disrupted older work processes. I have a long shopping list of refinements that I think should be made to new features like the TM search tool (which has only actually worked on my system since the release of the 6.8.5 build about a week ago) or that ground-breaking monolingual review feature which (will probably be the next big CAT feature to copy), but even the new features I consider rather immature are already looking pretty damned good. I can't guarantee that this release can be trusted for all your work right now (though it actually seems pretty good to me right now), but since it can be safely installed in parallel with older versions, I definitely recommend taking a look and joining the conversation on refinements still needed. I think Kilgray has been very responsive to user feedback in this round, and I can't say I am anything but encouraged by what I have seen in the last month.
One very exciting change for me in the current build (6.8.6) is that the rather risky non-optional export of target text comments with DOCX files has been sorted out very nicely. The solution seems a little strange to me right now, but it's a great step forward with some excellent possibilities.
When I saw those "severity levels" added to the commenting features in memoQ 2013 (6.5), I had very little good to say about them. I still don't think much about how they are named and wish I could choose my own labels, but now I can only applaud their usefulness. Why? Because the addition of the five checkboxes above has given me the control I want over comments to be included in an exported translation of a DOCX file. I can cleanly separate the comments which are notes to myself from those for my project partners and comments for my customers. This is very helpful.
I do think it is odd that this control was placed at Tools > Options > Miscellaneous > Translation when the comment exports (as far as I know) only affect DOCX files, but if there are plans to extend this feature to other exported formats, then this makes sense. I would like to see similar filtering controls for the ordinary view filters (on that last tab where comment and tag filtering criteria can be specified) and for comment inclusion in a bilingual RTF export. Either of these would be an enormous help to my frequent work processes, because I use a lot of comments intended for different people, and sorting these out cleanly can be laborious.
In recent weeks I have been working on the new edition of my memoQ tips book and taking a very close look at "corners" of the software that I suspect very few have time or inclination to look in. And I've had days when it really felt like Christmas has come early. One discovery after another of nice little refinements, lots of incremental improvements, which added together give a total with what I feel is a lot of value. I'm writing way too many private thank-yous to some of the people at Kilgray for what I see as excellent new directions even if I am inclined to argue over some of the details.
Since the release of memoQ 6.2 and its follow-ups with the bilingual text/Excel filter, there has been such a steady flow of useful improvements to help individual translators work better that those who claim that all the effort of development has been spent catering to the corporate sausage-making interests of the low-paying cattle call crowd simply haven't been paying attention. Or they have been confused by Kilgray's occasionally appalling failure to organize their messages properly for different interest groups. If you're talking to a big group of freelance translators and start discussing "great server features to monitor your translators' productivity", don't expect blown kisses and showers of rose petals. Sometimes it's obvious that the makers of the tool don't always understand the importance of what they have created for our work. Well, why should they? We're the ones doing it. But I tell you, right now there is a lot more gold for individual translators in the memoQ mine than anyone realizes. That goes for me too. I am surprised by fat new nuggets I find almost every week.
Do I care that so much effort is spent on developing cutting edge project management features for memoQ translation servers, even ones that I think can be abused in some pretty awful ways by some companies whose business practices I detest? Well yes I do... I think it's great. Besides, I can actually come up with nice uses of those awful features. You can do a lot of things with a cutting-edge: chop up a tasty salad... or the local nursery school. Blame the fool, not the tool.
Kilgray has avoided the disastrous errors committed by Atril in the last decade as their market mis-focus and disastrous failure to get the maintenance revenue needed to fix and develop features steadily eroded the ability of its loyal users to cope with a changing market. There was nearly a complete failure to compete for the business of translation agencies and corporate and government translation departments. And the solutions that prevailed in those quarters were mostly rather awful. I watched whole departments of Siemens traumatized by the disastrous Trados Teamworks, which made a number of those in the translation team of the medical products division look forward to retirement.
Kilgray has steadily built its business in the markets ignored by Atril a decade ago and in doing so has secured its future far better and ensured the funding of a truly remarkable series of improvements in the four and a half years I have been using memoQ. And now... when I look at the features of the recent SDL Trados 2014 release I see good things that I have known from other tools for a long time for the most part, nice to have really, but as I stifle a yawn I wonder if it all really has to be so complex since I'm not depending on consulting or training for SDL to pay my bills. And then I get back to memoQ and keep getting rocked by the "wow factor" as I find useful new things while trying to concentrate and get a job done. memoQ 2013 R2 is one of the worst offenders I've seen in a long time for its very real threats to make my work a lot easier and more fun!
I dig out my memoQ book I abandoned a year ago, because I need to update my training material. The text was based on memoQ 5.0 and now that I'm reviewing it I'm amazed how many of my "tips and tricks" solutions are irrelevant now. For example working with Studio is now completely seamless. Or you can finally import terminology directly from Excel file. 2013, especially R2 is definitely the thing.
ReplyDeleteOf course things can be still improved, as always, but it's very stable, easy to use and efficient tool.
Oh, I understand the "problem" of advances in memoQ and how quickly that can overtake the material we've created for tutorials. I started off writing my book about 5.0, then I rewrote it for 6.0, and now the rewrite I am doing for version 6.8 (memoQ 2013 R2) amazes (and sometimes intimidates) me as I discover at a fine-detailed level how much has changed. Still, I hope you can find the time to update your book material or write another; you are one of the best resources we have, especially for the more advanced challenges. I figure the best chance I've got to understand the horrors of regex is for me to read what you write about it.
DeleteStill no real 100% solution to the problem I'm constantly having trouble with of translating pdf files. Clients now don't even bother to specify the format - it's a matter of course. The CAT programme that comes up with a complete answer to translating pdf files will earn a fortune...
Delete"Blame the fool, not the tool."
ReplyDeleteI agree with you on that, and it is about time that the collective whining and self-indulging with misery on the professional translators side will stop.
However, there is something to be said about the role and responsibility of the technology developers.
Some, of course, are better than others (some are clearly serving a very specific crowd; they don't even try to hide it as they feel invincible), but dismissing the claiming about their role in enabling technology abuse by saying that 'guns don't kill people, people kill people' or just remaining silent is just the easiest and most superficial way out.
I'm not sure I like the gun comparison, Shai. As a gun owner for large parts of the last 30 years or so, I have experienced enough frightening near-accidents that I find myself grateful for every little bit of reflection that restrictions on the keeping and use of guns inspire. Some of this language technology may play a role in results that look like someone must have blown their brains out before or during the work, but fortunately the physical reality falls short of the ugliness that we can too easily achieve with our guns.
DeleteI have listened to rants from some freelance colleagues, complaining bitterly about certain features that Kilgray or SDL developed just to cater to agencies and corporate clients and felt more than a little impatience because the points they bitched about happened to be features that I and other freelancers depend on for our very different work, and in some cases I have my doubts if much thought was given to the particular value of these features for an agency. Certainly, server features can fall into this category, but even the rather obnoxious FirstAccept and split functions can serve useful purposes in the right team, however much they are probably abused in their routine application.
I think on the whole it's more useful to see what value we might distill from a particular feature set than worry about what someone else might do with it. Where I see specific abusive practices, I say so as clearly as I can, but some individuals behave a bit like jealous lovers when they complain about Kilgray's "unfaithfulness" in courting company business. I see it as a necessary and healthy thing which gives more balance to memoQ than you will find with other tools whose makers have not pursued such a path. As Steve Vitek and some others have pointed out, there is also a great diversity in our activities and a large overlap in the freelance to small service company spectrum.I would rather not worry a lot about defining artificial cutoff points where a company's' catering to some group should end.
I agree with you on the most part.
ReplyDeleteI didn't mean to compare a gun with a translation environment tool, I just used this metaphor to emphasize how easily it is for people that profit from something to develop a selective awareness and find a way to justify their actions (or lack of).
I agree with you that technology developers are not the "translation police", nor they should be. I also agree with you that the "translators" community is much too diverse and fragmented to be considered a one single entity, and different individuals or groups within that community operate differently - some even dig their own hole and have mostly themselves to blame for that.
What I meant to say it that technology developers do not necessarily know the market better than the people working in it. Again, not all technology developers are equal, and I suspect that some of them get their perspectives from the type of individuals they liaise with from within the industry, and pretty sure that some are greedy profit-driven corporations that look at market out of the narrow prism of their shareholders; and some are nicer than others.
But all of them, as far as I can tell, remain silent one subject that is arguably the core issue: the claim that TEnTs increase productivity by X percent and the whole CAT-discounts thing. Both of these are lies. The productivity increase is a very case-specific, and the CAT-discounts do not only contradict the previous productivity gain argument, they are unethical practice devised for helping brokers maintain their margins and force themselves into the (non-)value chain while pushing the translators down and out.
I suspect that honest software developers know that, but have their reasons to remain silent (and now the MT lobby is adopting pretty much the same stance).
I apologize if my previous post has offended anyone, that was not my intention.
Shai, I doubt anyone was offended; I certainly wasn't in any case. I despise that whole "guns don't kill people" argument anyway, because they might not by themselves, but they sure as Hell make murder a much simpler thing to do.
DeleteYou are so right that "technology developers do not necessarily know the market better than the people working in it". This is a given that many of us (including the developers) tend to forget. It's not necessarily a bad thing; it also means that there may be more nice surprises out there than anyone expects. I can't help but chuckle lately when a few of my contacts in Kilgray express some astonishment that some recently introduced features (like that monolingual review) get use productively the way they do. I didn't anticipate them either, but given that every newbie whose shoulder I look over teaches me something new, I've largely come to expect the unexpected. So when the Spanish - or in my case the Portuguese - Inquisition arrives, I'll be prepared :-)
Match discount scales that many apply bear very little relationship to my reality. The simple match cases presented in tutorials have long disappeared from my work queue and are probably off in some Asian jungle being attended to by monkeys. When I see an 85% fuzzy match in a long, complex sentence in a patent clam or description, by the time I am done inserting reference numbers and restructuring the sentence, the effort to maintain consistency has saved me little or no time and has often taken longer than if I had simply translated the sentence out of my head, especially if I am dictating. Perhaps a bit of time has been spared in the revision phase, but probably not. In the case of many 90+% matches which differ only in formatting, the effort to insert the tags or apply the relevant formatting costs me more time than translating the text from scratch would. The CAT tool has been a great aid to consistency, but to talk of actual time savings in the work would be dishonest. The accumulated experience of the past two decades has largely shown this myth perpetrated first by the Trados marketing machine to be the pile of reeking manure that it is. Now that the better CAT tools on the market have evolved to identify blocks of text which remain unchanged from previous versions, I think we're better off to focus any discount schemes on that text and leave off making up arbitrary figures for discounts of "fuzzy" matches and out of context "full" matches which have little or no verifiable quantitative basis in differential work effort.
Just to add a little something after I had a chance to better collect and organize my thoughts on this subject. It is true that many translators think and complain about how the software developers seem to be more oriented towards the needs and (sometimes unethical) workflows of big end clients and big LSPs. While this claim is not completely unfounded, and I must admit that this thought sometimes crosses my mind as well, it is important to understand how this perceived bias might be formed. Translators, and I'm generalizing here of course, prefer for some reason the passive stance, but in terms of business-related issues as well as professional-related issues. For example, most translators, at least that I know personally or virtually, are either completely clueless about the tool that they are using, which to me seems as if they are using it for all the wrong reasons - mainly an agency telling them to, or out of a false hope that it by itself will magically generate more business for them; or they limit themselves and their workflow to the perceived limitations of the tool (I'm surprised to discover time and again how even experienced users are not familiar with more than the basic workflow and functionality to get a project started). Instead of thinking outside the box, push the tool to its limits and demand the developers to add/amend certain functionality that suits or aid their workflow and work as an independent translator, they adopt just the opposite attitude and let the tool (or its abusers) dictate the workflow and process. As a result, not only they sometimes work inefficiently, the developers don't receive much feedback to work with. They get feedback from translators about bugs and other technical issues, which they usually iron out - more or less - but they don't get the invaluable insight about missing or lacking functionality or other paradigm-shifting feedback from the professional translators who use them. Conversely, the big agencies/end clients are generally much more demanding and articulated when it comes to their feedback and requests for new features. Granted, these features are mostly related to project management and the needs/interests of the client/agency, which only seldom are aligned with those of the translators, which shouldn't come as a surprise because the professional translator, agencies and end clients or all different needs, even when all entities play ethically and fair.
DeleteI still have my issues with the stance of the developers and some of features that are being requested of them, but without insightful, well-articulated, not-taking-no-for-an-answer feedback from a critical mass of translators, how can one expect the developers to know?
I can't agree with you more, especially on the last paragraph. However, while CAT discounts and other questionable practices have no real bearing on the reality of many, they still do on the one of many others.
ReplyDeleteThe developers are not the only ones to blame of course, the translators have their fair share of responsibility - both in terms of not knowing and respecting their profession, which leads them to accept such terms; and the fact that many of whom never bothered to learn how to work with the tool beyond the basic workflow that enables them to get started on the next batch of processed, brain-clogging words fodder of the day.
There are so many factors that contribute to the creation of a toxic marketplace, but to my humble opinion, the silence on the subject could be inferred as a validation of these dishonest claims, thus becoming their enabler.
The MT-lobby is not inventing or even re-inventing the wheel in that regard. They merely follow the "successful" steps of past and current technology developers and brokers, and just recycle, re-use, and re-ignite all these practices and old FUD attempts once again. This is what bothers me the most if to be honest, because I believe that when one sees an abuse, especially abuse of one's own creation, one should stand up and call it as it is.