Design Requirements

The first decision was to develop a special-purpose tool as opposed to using existing commercially available ones, the main consideration being the nature of the source text to be translated. In particular, use of machine translation technology on such text was not considered worthwhile.

Text used in the end-user interface of Oracle products is in a variety of forms, for example concise error messages, text used in menu options and screen displays. Very little of this is in the form of grammatical sentences. This also applies to text defined as part of an Oracle Forms application, for example text used in a screen display.

Also, text is stored in various binary format files that can not be edited directly. Although text-file formats of such files could be generated, editing these directly would expose the non-text component to accidental damage during translation editing.

Hence, it was decided to develop a special-purpose tool that would assist the manual translation of unstructured text, and provide an environment where the translation process can not damage any non-text component of a product end-user interface or application. Also, it was decided to provide an open interface that would enable text from any source file format to be loaded into the translation tool. This was required due to the multiple methods Oracle products use to store various text components, but also to provide the possibility of providing future capability to handle grammatical, structured text, for example on-line help text and documentation. Currently, such text components are translated using existing commercially available translation tools.

TM*WorkBench Architecture

Text to be translated is transferred from its source form into a standard file format that the translation tool knows about, specifically an Oracle Toolkit Resource file called an NX file. Once in NX file format, text from any source can be handled with TM*WorkBench. All that is required is a transfer utility to move text between source and NX file formats.

TM*WorkBench provides a standard Application Program Interface (API) to facilitate the development of such transfer utilities. The API enables text from different source files to be merged into a single NX file. This is particularly useful when translating an Oracle product or application with source text stored in multiple file formats.

In addition to the text itself, an NX file can store context information about text strings, for example the relationship of menu option descriptions or the structure of screen displays. This enables TM*WorkBench to provide a preview facility to enable a translator to view the appearance of menus and screen displays while actually entering their translations.

Source and translated text can also be loaded into a translation database to create a repository of translations. This enables TM*WorkBench to provide facilities for automated upgrade of translations to new versions, where translations of unchanged source text can be re-used, and changed and new source text identified.

In addition to a repository for previous translations, TM*WorkBench also provides a Term Bank. This is concept based, enabling context and grammatical information on source terms and their translations to be defined.

Using TM*WorkBench

The primary aim of TM*WorkBench is to enhance the productivity and cost effectiveness of the translation process. A translator uses a single Translation Editor to translate text, irrespective of source. The Editor has a Graphical User Interface (GUI) using Oracle Forms and applications built directly on Oracle's GUI ToolKit.

A Translation Window displays each component of source text in turn, above which the translator enters its translation. Selection of text to be translated is made in a Browse Window where the translator can navigate to specific portions of the source text. A Preview Window can be used to view the appearance of text that is part of graphical objects (for example screen displays) so that the translator can view the final appearance while actually entering the translations.

Management of the translation process is done using a Translation Manager. This enables translation projects to be defined. A project consists of a set of translation modules, which in turn define specific text components of an Oracle product or application. Modules are assigned to specific translators for each language, and the translation process can be comprehensively monitored through the various stages of loading, upgrading, translating, review and final acceptance.

The Translation Manager is also used to manage the translation database. New versions of source text components can be compared with previous versions to enable automated upgrade of the translations. Translations for unchanged source text are re- used, and new and changed source text identified. In the latter case, an indication of the type of difference (for example punctuation, spacing and/or text content) is given.

A Term Bank Manager enables glossaries to be created containing context and grammatical information of source terms and their translations. Source terms are added, and translated within the Term Bank Manager, which also provides version control of glossaries. A translator is provided with a manual 'look-up' facility to search for specific terms, and is able to cut-and-paste their translations into the Translation Editor. In future versions of TM*WorkBench, an active interface to the Term Bank will be developed to provide for automated search/replace for terms in source text. This will also be extended to the contents of the Translation Database, for search/replace from the repository of previous translations.