Historically, many translators use Microsoft Word application to directly translate Word documents by creating a bilingual Word file. We find this format less convenient than a full-fledged translation environment and use the latter for standardization. For instance, you can find this type of opposition in SDL Trados products, which allow translation both in a bilingual Word file and a stand-alone bilingual TTX file.
A bilingual (also known as “unclean”) Word file is a file containing both source and target text in the form of “segments” such as created by SDL Trados or Wordfast Classic products.
A translation environment is a complex Computer Assisted Translation software that uses its internal file format to create a stand-alone bilingual file. Examples: TTX in SDL Trados, TXML in Wordfast, or file pairs in STAR Transit.
A final (also known as “clean”) Word file is a file containing only target text, fully formatted and print-ready.
About 95% of our jobs use one of the delivery formats below:
- final formatted Word file only
- final formatted Word file + translation environment bilingual file
- translation environment bilingual file only (the customer creates a final formatted file themselves)
With returning customers, we have made our position clear, and most of them accept this approach. Whenever they need a bilingual Word file for some reason, we additionally create it. With new customers, the situation is different though. Naturally, we can provide a bilingual Word file if asked. However, some customers, while not providing any specific instructions, expect a bilingual Word file “by default”. This results in misunderstanding, since we don’t provide one by default. As one of the reasons for this post, I would like to clarify our position on this to avoid misunderstanding.
Obviously, shorter files and simple formatting files are suitable for translation in Word. However, larger files and more formatting intense files are likely to cause problems when translating. For standardization purposes, we have chosen the same unified environment for both. It helps eliminate some of the repetitive issues, including those below:
- Any formatting displays in WYSIWYG form, i.e. it is fully visible. A translator is forced to manually format their translation, e.g. use bold or italics. In contrast, while using a translation environment, they only need to rearrange the tags, which represent the formatting after conversion. Aside from improved convenience, this has a direct impact on quality: in Word, a translator can easily forget to reflect formatting, while a translation environment greatly reduces such risks.
- While translating in Word, you can easily damage tags, source or segment structure, without even noticing this. Until we standardized the environment, the level of damaged segments remained high. With a translation environment, this kind of damage is close to impossible.
- Any images containing editable source are usually quite a nuisance to translate in Word. Often, they are hidden after opening a segment, or you simply miss them when moving around the segments automatically.
- Word files can also contain tags. When this is the case, they display fully and cannot be visually shortened, as in a translation environment. This may result in huge segments that make it difficult to distinguish between tags and translatable text.
- Significantly slower performance, especially with opening and closing segments.
- Occasional Word errors and crashes both during translation and batch file operations.
- Occasional formatting damage while opening/closing a segment or creating a final file.
- A bilingual file makes it difficult to create a really final look by adjusting the formatting. We recommend to format final files only.
- Translating headers and footers requires opening them separately in some of Word views. Table rows are often skipped.
- Notes, index, or contents almost always trigger translation issues.
On the other hand, the customer’s position is also clear and reasonable:
- Managing a single (bilingual) file requires less effort than two files (final and unclean), especially in ongoing projects. For instance, it is easier to correct just a single file rather than 2 files.
- When the project workflow involves an editor who doesn’t use a translation environment, a bilingual Word file will be an ideal solution.
- Sometimes the customer believes that this will help avoid separate DTP of the final file.
To seek a compromise between the two positions, we always agree with the customer’s requirement to use a bilingual Word file, while explaining the potential roadblocks.
Recommendations and Support
Firstly, we always agree with the customer’s suggested workflow, i.e. a bilingual Word file (given that we generally accept the job). However, it is important to understand that the bilingual file might still require some formatting effort, before it is really final. Also, we provide the support below:
- We provide Word formatting mostly free of charge. This means that when your editor/proofreader introduced corrections into the translation environment file, we can use it to create a final file free of charge. In such cases, we ask the customer to confirm this beforehand, so that we can avoid creating a final file twice.
- If you send a file to an editor/proofreader and then need to introduce their corrections into a translation environment file, we can do this for you (free of charge, depending on the circumstances) and then, again, create a final file.
To benefit from the translation memory technology we use, ask us for an English to Russian translation quote today.