Those blunders might be due to the fact that the translator made some of the translations unconsciously or by guessing, without any idea of the layout or context of the original text. And then neither the translator nor anyone else checked how the translation would actually look in its final form. Let’s analyze a couple of examples:
Normally, “Note:” is placed at the beginning of a paragraph:
Note: This transducer is not designed for examining the bile ducts.
When translated into Russian, “Note:” is in most cases replaced with “Note.” (with a period). The actual note starts with an upper-case letter:
Примечание. Этот датчик не предназначен для исследования желчных путей.
But sometimes, “Note:” occurs in the middle of a paragraph, where it’s better to keep the colon and begin the actual note with a lower-case letter:
… кнопку. Примечание: обратите внимание…
If translators don’t realize that “Note:” is actually the middle of a paragraph, they will likely keep the period, thereby creating a weird-looking standalone “Note” sentence in the middle of a paragraph:
… кнопку. Примечание. Обратите внимание…
If translators are translating movie subtitles and don’t watch who’s saying what, they are in for a lot of trouble. While in English, there’s no difference between a phrase “I went home” said by a man and a woman, in many other languages such as Russian, the form of the verb will be different depending on the gender. Translating based on guessing means a 50% chance of hitting the bull’s-eye.
Why this happens
Imagine a translator working on an Adobe InDesign file (IDML). She has two options generally. The first one is simply opening this file in the native application, i.e., InDesign, and translating directly in InDesign by overwriting the original text. This is ineffective and often impossible, because a translator usually doesn’t have the expensive license for this software. The second option, which is much more efficient and has been employed by the translation industry for many years, is using a CAT (Computer Aided Translation) tool such as OmegaT to process this file.
In this scenario, the translator loads the IDML file into her CAT tool. The tool displays the text to be translated only. It doesn’t show layout, making it difficult to understand the context sometimes. To see the layout, she must open the PDF file produced from the IDML and refer to this PDF while translating. The PDF is called a “reference material” or a “PDF for reference.” By referring to it regularly, the translator is able to watch layout and context closely.
If she fails to follow the reference PDF, the translator sometimes makes errors such as those in the examples above. Instead of adjusting her translations to reflect layout or context nuances, she produces something that doesn’t fit the context at all.
Even if the translator fails to use the reference PDF while translating in a CAT tool, this is not the end of the world. After the CAT tool produces the translated file and a DTP specialist creates the final file, this file is supposed to go through some form of proofreading. The original translator (ideally) or someone else capable of this proofreading reviews the final file for the kind of problems I am referring to in this article, as well as formatting issues. Unless this reviewer is also inattentive, he/she spots those errors and corrects them at this step.
How to avoid this problem
If you’re a translator, just do it! I mean just follow the reference file closely while translating, making sure you see how each translation you make in your CAT tool fits layout and context.
If you’re a translation buyer, make sure to have the final file checked. This check can take a form of full-fledged proofreading after DTP or just a quick review. For more information on the types of reference materials, read a detailed article on how important the reference materials are.
Do you agree that using a CAT tool is still more efficient than translating directly in the native application, even though you need to spend time referring to another file?