Search me!

Jun 24, 2022

The Invisible Hand of Social Media


We've probably all been there by now. The evolution of social media platforms has seen the "rise of the machines", with artificial (non-)intelligence programmed by unintelligent humans monitoring and managing our actions, sometimes with little or no possibilities of pushback on our part or processes that waste inordinate amounts of time to obtain correction. We see this on Facebook, LinkedIn and other media which are too often also a major venue for business communication and technical support for professional tools we use. In the case involved with the screenshots above, my "wicked" comment was made with regard to an economic theory promulgated by the long-dead white Englishman, Adam Smith, and I was given the opportunity to protest to an external board after the fourth-world budget help confirmed that I was indeed a bad person promoting terrorism. I wrote:
There was a discussion about the abuses of capitalism and the flawed thinking of Adam Smith's "invisible hand", which he thought guided markets to do the right thing without control. As we all know, it is necessary for societies to exercise some control to protect health and safety, the environment etc. Blind belief in the invisible hand too often leads to tragedy -- in a sense, this invisible hand concept points the middle finger at us humans too often. So I suggested a metaphorical amputation of a metaphorical middle finger on a metaphorical invisible hand, meaning that we need legislation, etc. to protect against abuses in an unrestricted market. No real violence against any living beings whatsoever was suggested. The AI used by Facebook is functionally idiotic.

Consider also that if the hand is invisible the metaphorical blood must be too, so amputation should shock nobody, as any gore will also be invisible ;-)

Now all that is just a bit of amusement over coffee in the morning. But other cases are more serious, like the automated banning of a Ukrainian software developer for two months on LinkedIn because Putinist trolls objected to him trying to describe the reality of serving his customers while coffee breaks are accompanied by missile strikes and business-as-usual genocide. It seems that a certain volume of complaints can trigger a ban even when no specific violation can be identified. Artificial intelligence indeed.

Entirely too much trust is granted to automation, almost a reflex, even when it obviously contradicts logic and common sense. In the translation sector, I encounter time and again the idea that language services work should be cheaper if it involves text pre-proccessed by machine translation such as DeepL, even when it can be demonstrated that achieving the desired level of quality takes longer than if the text were translated by human effort only. So time isn't money for these people, I guess. The real issue is slavelancing.

Some postulate that most people need to believe in a Higher Power of some sort and take from it the direction and meaning of their lives. I used to dispute that, but seeing now how so many educated people in the business world have replaced Nin-girsu, Shiva, Allah, Nossa Senhora da Fatima and Mighty Cthulu with the new God of MTness, I suspect I may have been wrong.

As with most religions, it's our people and their welfare who are the true victims of this automation religion, while the priests argue that the real problem is that we haven't sacrificed enough to that invisible middle finger the technologists wave in our faces.

But I ask, what's the harm of paying a few more cents if you must if it leads at last to a lot more sense and better understanding for us all?

Jun 17, 2022

memoQ Inside Out: Templates for Translators

In the summer of 2021, I was coaching a group of project managers and translators at a Portuguese service company, helping them to develop processes to overcome some rather complicated filtering and configuration challenges for recurring project types. It was clear to me that some of their difficulties could be overcome with the use of templates, but I had only recently begun to use these productively myself, and my attempts to communicate the subject matter overwhelmed the group for the most part, and examining the sample templates provided with memoQ installation simply made matters worse.

After several frustrating tutorial sessions and the failed acceptance of a template that I had developed which was tailored to a rather long wish list of automation that came out of our discussions, I decided that the only way to make the value of templates clear to this group of professionals was to wipe the slate clean, forget about all the myriad "wishes" and build a few simple templates which did just a few simple things. Starting from a new configuration with nothing at all. Surprisingly, less was indeed more, and the frustrated people began to "get it".

At almost the same time, my friend and colleague Marek Pawelec, a gifted teacher whom I often refer to quite objectively as "a consultant's consultant", mentioned that he was thinking of writing a book on memoQ templates, because he found that most people were unable to avoid the problems in the example templates provided with memoQ installation, nor were they able to work out most difficulties encountered when making their own templates. I could understand this very well, because the user interface in the configuration dialog for a template is not a stellar example of clarity, and it took me years to make proper sense of much of it. Disappointing, really, because I had been part of the chorus begging for something like templates for years, but when they were delivered, little about them made obvious sense to a dummy like me.

He sent me a chapter he had drafted, where I noted that he had adopted the same reductionist approach to getting started. A template with just a pick list or two for meta data to avoid the problem I've had for years of accidentally using different designations for the same clients, subjects, domains, etc. He had come to the same conclusion independently that the best approach to helping people use templates effectively is to start with one or two simple things they do all the time but often mess up.

That interesting draft chapter took time to evolve into a full-fledged guide of nearly 70 pages, with many practical, relatable examples of the kinds of challenges that individual translators (and many other service providers) often face in configuring translation projects. The topics cover the full range of options, from very simple tasks to extremely complex workflows involving pre-import scripts for preparing translation data and post-processing to recreate the original data formats. At every stage he offers clear examples and guidance on how to make things work in cases I have seen time and again in more than two decades of commercial translation work.

I had the pleasure to edit two drafts of this work as it neared completion. And pleasure really is the right word to use here. Marek has a very different explanatory style than mine, but one which I prefer for my own education. He manages very well the deep dive into messy details without drowning the reader in jargon and other unhelpful complexity. His guide gives valuable suggestions and information for every level of expertise. Much of the content can be understood and applied by unsophisticated new users of memoQ, but some of the details on content connectors and scripting can light a chandelier full of bulbs in the heads of alleged experts like myself.

Templates for Translators is an essential reference work for all memoQ users in my opinion, the sort of thing which ought to have been provided seven years or so ago when templates were introduced. Instead we got some imperfect examples which too often - especially in the hands of under-trained PMs at translation agencies - result in unworkable projects with 50+ translation memories and term bases grinding performance to a halt or a lot of mysterious and unwanted automation that does stupid shit like write unfinished and defective translations directly into one's master TM.

In addition to explaining clearly how to create your own helpful project shortcuts and automation from scratch, Marek included a great  chapter in which he describes in detail the templates provided for local projects, what works in them and what doesn't, and how to fix any issues so things work right for you. Even if you are a server user working primarily with online projects, there is a wealth of material in this version of the templates guide to help you work more effectively with templates for online projects. A second edition is planned for later this year, which will cover the additional features of templates for memoQ Server projects, but the real problems of most people working with those are covered in the basics presented in the "translators" edition, not in a lack of guidance on the many extra event "triggers" for online projects or other details. So if you are a server user, don't wait for the later edition, get this guide now, read every damned page and try to contain your exuberance as you finally understand a lot of stuff that has been confusing the Hell out of most of us for a long time. Then when the "server edition" of the guide is published, you'll be better prepared to absorb the increment of information it offers.

This book is now a valued part of my teaching "arsenal", and I recommend it without reservation to every memoQ user who aspires to work independently and create more effective processes for the special needs of various clients and subject matter. If you are a consultant or trainer at a serious level, it could well be considered malpractice to train without some of the information you'll find in Templates for Translators. But that's just what I see too often: discussions of templates glibly use the few defective examples installed with memoQ with little consideration given to how many translators should work in the real world with real, common client projects. This book is a welcome aid to move beyond all that and improve our satisfaction with the routine of translation in memoQ.

So for less than the cost of half an hour of consulting, the €30 invested here will save nearly anyone a large multiple of that and continue to pay dividends for a very long time, even if you understand and apply only 10% of the material presented. I charge far, far more to teach people less than that.

memoQ Inside Out: Templates for Translators is available for purchase at

May 30, 2022

Cleaning up language variants in memoQ term bases

While the idea of using sublanguage variants, such as UK, US or Canadian versions of English, sounds nice in principle, in practice these often create headaches for users of translation environments such as memoQ, particularly when exchanging glossaries with others but also when viewing and editing the data in the built-in editors. Many times I have heard colleagues and clients express a wish to "go back" and work only with generic variants of a language in order to simplify their management of terminology data. In the video below, I share one method to do so.

At 3:08 in the video, I share a little "aside" about how the exported term data can be edited to mark a term as forbidden (for instance, if its use is not desired by the translation buyer). Other changes to the information are also possible at this stage, such as the addition of context and use information for example. Other data fields from the term base can also be included in the export for cleanup if these play an important role in your memoQ term bases.

For years, users have requested an editing feature in memoQ that would make "unifying" language variants possible, but as you can see in this video tutorial, this possibility already exists and is neither difficult nor time-consuming to implement. 

If you do not wish to create a new term base to import the cleaned-up data (as shown in the video) but would rather bring it in to the same term base, it is important to configure the settings for your import correctly so that the original data will be overwritten and you won't end up with messy duplication of information. This is achieved with the following setting marked in red:

However, it should be noted that the term base will still have all the now-unused language variants, albeit with no entries for them. These can be removed by unchecking the boxes for the respective language variants in the term base's Properties dialog.

Speaking of the Properties dialog, some may have noted that in recent versions of memoQ there is an automated option for cleaning up those unwanted language variants:

Why bother with the XSLX route then? Well, depending on what version of memoQ you use, you may not have that command available in the dialog. But more importantly, I find that when merging data from various language variants I often want to do additional editing of the term information, and that really isn't possible when merging language variants in the Properties dialog. Doing the edits in Microsoft Excel gives you an overview of the data and the option to make whatever adjustments may be needed. In Excel you can also make further changes, such as altering the match properties for better hit results or more accurate quality assurance.