There are some very obvious answers to that question. Terminology handling, translation memory features, Unicode support, and good handling of bidirectional and East Asian languages are just some that come to mind. Predictably, these are the features that are typically discussed in reviews and articles. And yes, these are at the very heart of the success of the many tools out there. But there is more. One of the areas that I see as more and more important is the provision of a good word processing environment.
Early on, many TEnT (Translation Environment Tool) 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 Word and WordPerfect came with, 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, Multitrans, or now even Wordfast? 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 for 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 are the features that ideally would be part of a TEnT that did 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 much most TEnT tools are lacking in this regard! There are typically three strategies that tool developers have so far employed:
- The use of a third-party spell-checker, particularly the one by Wintertree software. 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.
- The use of plugged-in open-source spell-checkers that are also used for OpenOffice. 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.
- 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. 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.
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.
Grammar Checks
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 and AutoCorrect
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. What should also be possible is to import language-specific lists from other tools.
Track Changes
This is huge and it's really a no-brainer that it should be part of any kind of TEnT tool. With the exception of Lingotek not a single one provides it outside of the Word environment at this point. Though there are workarounds (some tools track whether a different user has touched a cell, while for others third-party tools, such as Comparator, are available for a comparison), an elegant integrated solution needs to be part of any word processing environment for any tool because we all know that the translation process typically involves editing and proofreading passes during which the documents are exchanged back and forth between translators, editors, and proofreaders.
Comments
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 right then and there when you as a translator or editor are in doubt (or you want to express your appreciation for a colleague's good work . . .).
Inline Codes
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 only be achieved through the mouse is not user-friendly and should be banned. It is important to have (customizable!) keyboard shortcuts for this task.
Smart Quotes
This seems like a small thing, but most of us know it is very frustrating to have to enter the smart/curly quotes of your particular language with the help of some kind of fancy work-around. The tool should do it for you.
Non-Printing Characters
In an editing environment it's helpful to see non-printing characters such as spaces, tabs, and line breaks 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, SDLX, and Idiom Workbench have a fancy and user-definable implementation of this and Trados TagEditor and across at least a non-customizable implementation. Most other TEnTs don't do that, though. There is a simple workaround that the developers of MemoQ offer at: a font that displays non-printing characters. Note, though, that this font displays all non-printing characters the same so that you cannot use it to distinguish between different characters.
WYSIWYG
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 to not 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.
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.
Recommend this article:  |  |  |  |  |
Home
