An Interactive, Text-based Translation Aid Environment Eric Nichols and Yuji Matsumoto Graduate School of Information Science, Nara Institute of Science and Technology 8916-5 Takayama, Ikoma, Nara, 630-0192 JAPAN eric-n,matsu @is.naist.jp 1 Introduction Translation is an essential and important part of human communication. However, it is a very challenging task, requiring the translator to have a complete understanding of and a deep familiarity with the source and target lan- guages. This difficulty is not eased by the fact that fun- damentally it is an inherently repetitive task, consisting of looking up unfamiliar words and doing large amounts of editing to produce a good translation. Given these demands, computers provide a good way to ease this repetitiveness by automating lookup and editing; by converting resources like dictionaries, other transla- tions, and collections of example sentences to a computer- readable format, lookups can be performed much faster. Likewise sophisticated editing languages can reduce the time and complexity of editing translations. Since the idea of a translation aid environment was first proposed by Martin Kay (1980), a number of different systems have been built. There have been systems built on (Wordfast 1 ) or mimicking (Trados 2 ) Word processors; stand alone applications like D´ ej` a Vu X 3 and OmegaT 4 ) and web-based translation aid systems, both free (TRANS- Bey (Bey et al., 2006)) and commercial (Lingotek 5 ). A survey of professional translators in 2006 showed that 82.5% of translators own and use at least one translation aid environment (Lagoudaki, 2006). Yet existing transla- tion aid software has a reputation for being hard to use. The conductor of this survey summarized her findings say- ing users want ”flexibility, simplicity, and ease of use” in their translation aid environments. Why do current trans- lation aid systems lack these qualities? We consider this to be in interface problem: most trans- lation aid environments are modeled after word processors, with functionality for processing text often hidden away in complex hierarchical menus or behind obscure keyboard shortcuts, making it difficult for translators to explore and manipulate language. Given that translation is an inher- ently text-centered task, it makes sense to investigate the 1 Wordfast: http://www.wordfast.net 2 SDL Trados: http://www.trados.com/en/ 3 D´ ej` a Vu X: http://www.atril.com/default.asp 4 OmegaT: http://www.omegat.org/ 5 Lingotek: http://lingotek.com/features.html potential of text as the interface. The Acme text editor pro- vides an ideal environment for this goal. 2 Text as the Interface 2.1 Acme: An Interactive Text Editor Acme is ”a hybrid of window system, shell, and editor” created by Rob Pike (1994) as a programming environ- ment. At first glance, Acme seems like a strange editor; it is designed for use with a three-button mouse, and there are no menus or buttons of any kind. However, the interplay between the mouse and text in Acme give it a powerful and flexible interface. 2.1.1 The Mouse In Acme, the mouse allows the user specify how to con- textually interpret text. Acme is designed for use with a three-button mouse, and each button has a different use. The left button selects text. The middle button interprets it as a command. For example, clicking on the text ’New’ opens a new buffer window. Clicking on ’Del’ closes that buffer. All common editor functionality is handled in this way: ’Snarf’ is Acme’s copy and ’Put’ saves the con- tents of the current buffer; ’Undo’ and ’Redo’ provide their namesakes’ editing functions. Text for these com- mands is provided in the ”tag” area at the top of each buffer, but this is simply for convenience; text can be added and executed anywhere in Acme. When the text middle-clicked on is not a built-in com- mand of the Acme editor, it is interpreted as a system com- mand, and the command is piped to a system call for exe- cution with results are sent back to Acme. What this means is any command that operates on standard I/O can be ex- ecuted just by middle-clicking on its name. In this way, Acme can be extended at any time by a large number of commands that the user is already familiar with. Outside of the small set of Acme-specific editor commands, there is no need to learn any special commands to add new func- tionality to Acme; almost all functionality is outsourced. The right-button provides another useful function: it performs a context-sensitive ”get” function. When the name of an existing file is right-clicked on, it is opened in a new buffer; when the name of a function is clicked on, its definition is shown. Clicking on a number followed by a colon (’:’) causes the cursor to jump to that line number - 333 -