Creating the Ideal Word Processing Environment in Translation Environment Tools

By Jost Zetzsche,
an English-to-German translator,
a localization and translation consultant

jzetzsche[at]internationalwriters.com

4,400+ Translation Agencies! Click Here to Buy the Database!

One of the areas at the heart of how successful a Translation Environment Tool (TEnT) is for the translator, editor, and proofreader is the quality of its word processing environment.

Wordfast is the only tool left on the market that offers Word as its only word processing environment.

Early on, many TEnT makers chose the "easy way out" by using Word or WordPerfect as their main word processing environment. This seemed to have a number of advantages. Not only did this provide access to the advanced word processing facilities that came with Word and WordPerfect, but it also didn't hurt their marketing message: "If you know how to use Word, you know how to use our tool." This message really was a fallacy that badly back-fired when users became upset that these tools were indeed quite complex and challenging. Though it was nice to operate in a familiar environment while writing or editing, the setup and maintenance of databases and the use of all the many intricate features that most tools offer really had very little to do with MS Word.

The first assumption—that Word does offer advanced word processing features—was correct, though. So why is there a move away from Word, even by the tools that are automatically associated with Word such as Trados or Multitrans? (In fact, to my knowledge Wordfast is the only tool left on the market that offers Word as its only word processing environment.) There are a number of reasons for this departure. One obvious one is the reliance on a third-party tool that makes it difficult to do your own independent planning for your tool. Another is the need to require users to purchase Word if they want to use your tool. And lastly, it is difficult to use Word with all the many other non-Word-compliant formats that are to be translated (DTP, tagged, other Office, database, software development, and many other formats).

So, what features would ideally be part of a TEnT that does not use Word as its translation editor?

Input

Clearly, all the different language keyboards and Input Method Editors (IME) need to work. While this is typically the case, another kind of input via speech recognition does not always work as easily. Even though speech recognition programs such as Dragon NaturallySpeaking or Vista's internal tool work with most Windows applications, including TEnTs, they are often less than optimal. For instance, in some tools the beginning of a sentence is automatically recognized and capitalized, while in others it is not; in some tools, internal codes are harder to control with your voice than in others. The development of a good translation editor needs to include testing with the most common speech recognition programs.

Spell-Check

We all know how important this is and we all know how lacking most TEnT tools are in this regard! There are typically four strategies that tool developers have employed so far:

• The use of a third-party spell-checker, particularly the one by Wintertree software (www.wintertree-software.com). The quality of this spell-checker is very language-dependent, and I have yet to meet anyone in any language who is really satisfied with this option.
• Plug-in to Word to use its spell-checkers. Also a relatively good solution—provided that you own Word and the language pack for the respective languages (see below). To my knowledge this does not yet work with Word 2007. The benefit of this feature is that you can use the customized spell-checkers that you have in Word anyway right away; the drawback is that it is usually a very slow option.

Choosing between the Wintertree and the Office spell-checker in Trados TagEditor

• The use of plugged-in open-source spell-checkers that are also used for OpenOffice (see wiki.services.openoffice.org/wiki/Dictionaries). In many ways this is a much better solution than the previous one, not only because of the better quality of the spell-checkers but also because of the large amount of covered languages.
• Browser-based tools such as Lingotek or Pootle offer browser-built-in spell-checking (Firefox 2 by default and IE with add-ons such as www.iespell.com or www.ie7pro.com).

Knowing how important good spell-checking is for translators and editors, it is clearly important to find out how your (prospective) tool handles this and how good it is for your language (and at the same time for developers to use the broadest and best solution available). Also, some languages have stand-alone third-party spell-checkers that are often considered superior to any other product. While this is no easy task, it would be wonderful if there were ways to use these in the respective TEnT tools.

And lastly, only browser-based tools (see above) and across offer the squiggly-underline on-the-fly spell-check that Word or OpenOffice offer. It's true that some of us don't like this feature, but others think it is absolutely essential so it would be nice to have the option of using it.

Almost everything that was said about spell-checks could be said about grammar checks, only that it is just never offered outside the Word environment! I know that some folks REALLY look down on grammar checks, but again, others use and like it. There should be no reason why this cannot be offered in TEnT tools through a link to Word or to some of the other third-party tools.

AutoText (the ability to expand a token with a keyboard shortcut) and AutoCorrect (the feature to automatically correct common typos and other customizable short forms) are part of most word processing tools and should also be part of any TEnT tool. Typically one or the other is done by most tools, but rarely both. It should also be possible to import language-specific lists from other tools.

This is huge and it's really a no-brainer that it should be part of any kind of TEnT tool. Yet at this point, not a single one provides it outside of the Word environment. There are workarounds (some tools track whether a different user has touched a cell, while others have third-party tools available for a comparison), but an elegant integrated solution needs to be part of any word processing environment for any tool. The very nature of the job makes this is a necessity, because the translation process typically involves editing and proofreading passes during which the documents are exchanged back and forth between translators, editors, and proofreaders.

Though it uses a different process than Word, Lingotek also stores information about the different stages and allows you to compare them in any combination at a later point (even through its exported XLIFF format).

Comments have fortunately become a rather common feature within TEnT tools, and the few that do not offer this feature should definitely do this. It's just very handy to add some comments as you're working when you are in doubt as a translator or editor (or you want to express your appreciation for a colleague's good work . . .).

Inline codes are the markers that are used to "remember" formatting or other kinds of tags within sentences in a TEnT environment. Every tool needs to deal with those in some way or other. What's important is that placing these codes not interrupt the workflow of translating. Anything that can be achieved only through the mouse is not user-friendly and should be banned. It is important to have (customizable!) keyboard shortcuts for this task.

This seems like a small thing, but most of us know it is very frustrating to have to enter the smart/curly quotes of our particular language with the help of some kind of fancy work-around. The tool should do it for you.

What-you-see-is-what-you-get—the ability to see the translation in its context and layout—is as old a topic as TEnTs, and different users simply have different preferences. What has become common practice for a good number of tools is not to offer a complete WYSIWYG environment while you translate (because this could be distracting and is in some cases just not possible, such as when dealing with text that is embedded within certain code). Instead, the user is given the chance to switch on the fly to a WYSIWYG environment (as much as that is possible) to verify the placement and context of text strings.

In an editing environment it's helpful to see these to avoid or make sure of double-spaces (within a sentence or after a period), to see the difference between a breaking and a non-breaking space (one of the few ANSI combinations everyone should know: Alt+0160), or to verify whether a tab is used instead of spaces. Transit has a very fancy and user-definable implementation of this and so does SDLX. Trados TagEditor shows normal spaces vs. non-breaking spaces and so does across by default. Most other TEnTs don't do that, though.

I can think of a number of other things that could be listed here, but if the items above were to become a minimal best-practice checklist for tool developers, we all would be well served.

Read more articles - Free!

E-mail this article to your colleague!

Need more translation jobs? Click here!

Translation agencies are welcome to register here - Free!

Freelance translators are welcome to register here - Free!

Subscribe to TranslationDirectory.com newsletter - Free!

Take part in TranslationDirectory.com poll - your voice counts!

Menu

Free Newsletter