My customer, however, had warned me when she sent the job. “Natalie, you know that our terminology is highly technical and most terms can’t be translated literally, but DeepL doesn’t know that. So be particularly careful when you come across our company-specific terminology and GUI terms.” “Sure thing”, I replied. I’d been working with this company for years and knew their terminology could be quite unusual.

Now every post-editing job consists of two steps. During step one, you read through the translation and basically make sure it sounds alright, checking it for any grammar mistakes. As DeepL had mostly produced a perfectly fluent and grammatically correct translation, I could almost breeze through step one. During step two, you carefully compare the original text and the translation to make sure the translation reflects the original in terms of content. This is when I noticed the terminology “mistakes” DeepL had made and corrected them accordingly – or so I thought I did, until I received feedback on the project.

I had by no means caught all of DeepL’s terminology mistakes. But how is that possible? I am familiar with most of the company-specific terms. In addition, I had been using MultiTerm (a termbase containing customer-specific terminology and the respective translations desired by the customer). How could I have missed the mistakes?

The answer is quite simple: Because when reading through the translation, it sounded perfectly fine – even though it wasn’t.

Let me give you a simplified example. In most software manuals the German ‘Datei anlegen’ is translated as ‘Create file’. My customer, however, wants ‘Datei anlegen’ tranlsated as ‘Add file’. So what happened when I was checking DeepL’s translation? Well, several times I read ‘Datei anlegen’, thinking my customer wants this to be ‘Add file’. So I changed DeepL’s translation accordingly. However, in some sentences, ‘Create file’ still simply snuck past my radar. ‘Create file’ sounds perfectly fine and is a correct translation of ‘Datei anlegen’ – but not in this case, and not for this project. What about MultiTerm? Didn’t it help? It did, but MultiTerm does not always automatically show the translation of the technical term required (e.g. when it is a variation of the term saved in termbase it won’t be displayed, unless you perform a search).

I’m sorry to break it to you, but the truth is: Not all projects benefit from machine translation. If your project contains numerous highly technical, non-standard terms, meaning DeepL is not familiar with them, you should think twice before applying machine translation, especially in the field of marketing and PR, where the content rather has to be transcreated than translated.



If you’re interested in learning more about machine translation pitfalls, follow up on our next blog post with more specifics!