memoQ Cloud subscriptions and credit card tribulations

Kilgray's memoQ Cloud service is a very convenient platform for learning and testing the latest features of the memoQ server and operating a server for small teams without the hassles of maintaining the server infrastructure and software in-house. For those considering a dedicated server for their company or institution, it offers an excellent opportunity for pilot testing at low or no cost depending on how long you use it. The first month is free; after that the monthly charges (to a credit card) currently start at EUR 160 or USD 175 for an account with one project manager license and 5 web access licenses (to which anyone with a licensed copy of memoQ can connect, without the need to include Translator Pro licenses in the subscription - these are needed only if users without a license will be connecting with the desktop editions of memoQ).

I use the memoQ Cloud server occasionally for shared projects, because it allows me to configure files and resources (of all kinds) more conveniently than file-swapping by e-mail or Dropbox folders and provide better support to my team members. For €160 per month in the months I need it I am on equal footing with any large agency with a memoQ server for the team sizes I want to work with. And I can even share the translation memory resources with colleagues who use SDL Trados Studio using the free Kilgray plug-in for that platform which enables access to any memoQ server online (with an access account created).

The only disadvantage of this service for me is Kilgray's annoying tendency to force upgrades much too soon in the release cycle. This won't matter at all to someone testing the memoQ Cloud server to evaluate the latest release; in fact, this is helpful to avoid the occasional server setup difficulties with new versions on which the paint has not yet dried so you can focus on evaluating features and general stability. But if you are in the middle of a big project, this can be a nuisance. More often now I assume, since Kilgray's current strategy involves more frequent minor version releases. If there is a compatibility problem between the latest release and a team member's memoQ software version, and that person isn't current with the annual maintenance and support plan (which includes free upgrades), they will be stranded for access from their memoQ desktop application until the missed annual fees are paid up.

But until today there was another mysterious hassle that I finally got sorted out. When I first started using memoQ Cloud, I paid the subscription with a US credit card from an old credit union account there. No problems. However, when I incorporated my business in my current country of residence and tried to use a card from my business account there, it never worked, and the explanation screen was displayed for only a brief time, with the text completely garbled due to an incorrect codepage specification for the web page. The first time this happened, I assumed the problem was Kilgray's, and after some back-and-forth with support, the company kindly made an inconvenient exception to their "credit card only" rule and sent me a normal invoice to pay by bank transfer. This isn't a usual thing as I have learned from some frustrated potential corporate customers who don't want to pay by credit card, so I am grateful that something was worked out in that case so I could get on with some urgent teamwork.

After a break of six months or so, the need for a cloud server arose again, and again I had the same trouble with my business credit card. After grumbling briefly to a friend at Kilgray who had sorted the mess out before, I decided to call my bank, because in the meantime my reading skills had improved enough that I was fairly sure that the trouble had nothing to do with Kilgray. Indeed.

The credit card verification and approval service used by Kilgray for web payment is 3-D Secure. In the case of my bank, this service is not available for credit card payments unless its activation is specifically requested. Such a thing never occurred to me, because I use the same card with Amazon and others to order dictionaries and other work materials. As the technician at my bank's help desk explained, there are several different payment approval systems for web transactions with a credit card, and it's merely a coincidence that the others I have dealt with haven't used 3-D Secure. He activated the service immediately (no cost), and five minutes later my memoQ Cloud subscription was renewed with the means of payment I preferred to use.

So it was in fact not Kilgray's problem at all, but it's probably a good idea for their support staff to take note of this scenario, because I am surely not the only one who got tripped up by 3-D Secure not being activated for my card. I am sort of embarrassed that I didn't think of this possibility earlier, but I don't do a lot of shopping online, and for minor stuff if one card fails for reasons unknown, I just shrug and use another. In fact, I think the same problem may have occurred with an airline ticket last spring, but I never associated that with my earlier troubles.

So now I'm up and running with the server version 8.2.5 on the memoQ Cloud, hoping I can finish my training project on that version before the impending release of memoQ 8.3 and the possibility of an upgrade before I get the work done. Tick, tick, tick....

Get started April 10th with extension development for SDL Trados 2017

On April 10th, 2017 at 4 pm (UTC) there will be a free webinar for those interested in the basics of development for SDL Trados Studio 2017 using SDL's application programming interfaces and software development kits.

Romulus Crisan, an SDL Language Platform Evangelist Developer, will guide you though:

• configuring the development environment 
• new APIs introduced with the Studio 2017 release
• upgrading current plug-ins to support Studio 2017
• building a simple editor filtering plug-in

Heads-up to Kilgray developers: maybe here you can figure out how to fix problems with that cool plug-in that allows SDL Trados Studio 2014 and 2015 users to read and write memoQ Server TMs so that it will also work with the latest Clujed Maidenhead Madness.

You can register for the webinar here.

Who's afraid of the BDÜ?

A recent publicity stunt by the German Association of Translators and Interpreters (BDÜ) has provoked some interesting responses, most of which, I think, reveal the personal agendas and prejudices of the respondents and miss the point entirely. In a brilliant bit of political theater, financial translation wizard Ralf Lemster was pitted against The Machine loved and feared by many: Google Translate.

Well-known MT pundits like Kirti Vashee know this isn't "fair" and uttered the expected objections and protests. I imagine the details of their criticisms are correct, or largely so. But they are also largely irrelevant. They are all too aware of the Imperial Elephant in the room: public perceptions and how too many private individuals, corporations and - to their great shame - language service brokers apply machine translation in ways that are entirely inappropriate.

All the talk of controlled language, fit-for-purpose, quality-is-what-the buyer-thinks-it-is and "it's here to stay, so deal with it" and all the other noise generated by MT's sycophant choir reminds me a bit of the old carnival shell game, except that the ones taking your money there are a bit more honest in their game than ones who tell you now to "get on the MT boat or drown".

Off-hand comment? Bollocks. It was a prepared keynote speech at memoQfest 2012 and carefully calibrated to play on the fears, uncertainties and doubts of listeners and drive them down the drain of the post-editing sewage cycle. It is a far cry from the restrained, responsible approach to machine translation promoted by technologists I know who understand the extremely limited scope of MT and never oversell its performance or potential (at least not within my hearing).

The MT carnies know instinctively why the ludicrous BDÜ "case study" is brilliant. It is short of fact and science and follows a familiar lightweight format we all know from modern "news" reporting. And however much better custom, optimized MT engines are said to be, it is Google Translate more than any other which casts the biggest shadow across the translation landscape.

I remember a few years ago how Kilgray once objected on ethical principle to officially supporting a Google Translate plug-in for memoQ, because of the very real violations of confidentiality and often law which occur when translators send their clients' content to Google for processing. This promiscuity with the intellectual property and privacy rights of others is not excused by the frequency of its practice any more than the widespread practice of unsafe sex in countries devastated by  double-digit AIDS infection rates makes the risk of illicit mingling any less.

But SDL, long an ethical "innovator" in the world of translation (remember how the Trados gang brought you the Big Lie of how translators prefer to give fuzzy discounts - long before most translators had CAT tools or even knew what a fuzzy match was), apparently had no such reservations and made the tools to facilitate breaches of confidentiality more accessible to translators and wannabes, so Kilgray as well as many others gave in to popular demand and indifference to the law and released its own Google Translate plug-in officially. (Of course I support the right of SDL, Kilgray, Atril and any other company to make such tools freely available. A Google Translate plug-in no more violates intellectual property rights than guns kill people. We all know and accept that it is humans and their weak nature which are at fault, and we can do nothing about that but let things take their course, right?)

Reactions from translators who understand German were fascinating. Some pointed out that the New York Times had already "gone there" (not really - the translations of literature snippets are even less relevant I think... I want to see real-life risks shown with electrical repair instructions and instructions for surgery or the use of pharmaceuticals), others criticized the BDÜ for not showing side-by-side comparisons of the machine's erroneous spew and Ralf's correct text. But I think the Devil's distraction is in the details.

The BDÜ is generally rather hidebound and out of touch with many aspects of modern translation practice; the pages of nonsense in the online registration for their recent conference in Berlin tried my patience to the point where I decided to stay home and make jam for the second time. But this time they got it all right I think.

A good guerrilla knows that the battle is about hearts and minds, and since most of the public is a bit short in the latter capacity, it's best to go straight to the heart of the matter with an entertaining show. A week after watching the "report", few will remember the details. But they will remember the emotions evoked and the air of authority projected. MT will lose every battle of fact on the fields where its carnies pitch their tents and the public crowds gather, but the shysters have a very sure advantage and exploit it at every opportunity: the naive confidence of the scientifically illiterate that "progress" will continue and things will always get better, MT included. I hear this all the time from colleagues. The less they understand the technology they use, the more they are willing to be used by it, and the greater their confidence that it will inevitably infiltrate their necessary professional activities.

A similar confidence once existed for the impending discovery of the Philosopher's Stone to turn lead to gold, occupying even the greatest minds like Sir Isaac Newton. Skeptics like me were most likely laughingstocks to go against such wisdom.

The way to win this "war" is not with facts to be forgotten in a day. The path to the victory of good sense and the human spirit lies in a bit of theater like the BDÜ has offered and perhaps some good jokes like the late Miguel Llorens so generously shared at the expense of dishonest MT promotion.

That is something which the carnies have good reason to fear.

Just for fun: 8 MT engines for DE>EN compared

When technology guru Jost Zetzsche (Twitter: @jermobot) recently reminded the world of the relative new memoQ plug-in for itranslate4.eu, I thought I would test and blog it for fun if not profit. Alas! The key validation for the free demo (10,000 characters) I "purchased" isn't working for me, so I decided to have fun another way until that gets sorted out. I plugged two sentences into their engine offering translations from six commercial MT tools, then I put the same two sentences in Google and Microsoft's MT engines. One of these sentences is fairly simple in structure, the other less so. I won't comment the results much; I leave judgment to experts and fools to make as they choose.

The results layouts for Google & Bing were modified for better viewing. I think there are plug-ins for all these engines in a number of tools if anyone is daft enough to really want to use them productively (thus unprofessionally ignoring many confidentiality requirements for clients quite aside from other possible issues).

PROMT actually got it right and idiomatic. Should I be impressed? Repeats with other simple sentences showed that accuracy is a real crapshoot for all six engines, though True Believers in MT can serve the machine by suggesting improvements. I did my part by submitting improvements for sentences related to the ongoing Vatican scandals about abuse by priests.

Go Google! Nice to know there are so many ProZ translators depending on this great engine :-)

Full points to Big Bill & Co. this time. Two out of eight got it right. Hmmmmmmmm.

Now for something a wee bit more, taken from the Wikipedia entry on photovoltaics...

Our friendZ at Google say:

Now Big BillZ BoyZ get their chance:

O what a Brave New World, that has such technology in it :-) I think I'll stick to my specialties and use the Dragon if I feel the need for speed. I can dictate fresh faster than I can analyze and fix even the simplest "close calls" for correctness.

Of course, sentence-by-sentence, results will differ in reliability with every engine. But isn't it simply better to use the most reliable engine of all: BAT* with a good translator?

A recent LinkedIn discussion went on at length about quality metrics and other bla bla for MT. And there are various discussions of "best practice". Given enough beer or other intoxicating substances, I'm not averse to engaging in such discussions, and the ten-year-old in me who still likes to fiddle with things IT does take an academic interest in the subject of MT and productivity, but if I want real work and real quality (and yes, Renato, Kirtee, et alia there is such a thing, though its definition will vary by domain and be ever disputed... try telling a customer trying to understand a user manual that it doesn't exist or watch the faces in an audience as a translated speech is delivered in various versions, or send your marketing brochure for the UK to Bangladesh or Russia because rates are lower) I will find it with methods that stay far away from MT. Let the competition do otherwise. PLEASE.

* "brain-assisted translation", a concept once common in the days before the IT devoloution of the profession and still favored by a few high-earning dinosaurs