1. Technical Field
The present invention generally relates to tools for developing software for international use and in particular to multi-language software development. Still more particularly, the present invention relates to an improved system and method for performing language translation in computer software.
2. Description of the Related Art
Software Internationalization
As computers have become more prevalent, it has become desirable for software developers to be able to market their products to those people who do not speak the native language of the software developers. In particular, it is desirable that software developed in the English language be available to those persons, both in the United States and in the rest of the world, that do not speak English. Accordingly, many software applications that are developed in English are later translated for use by non-English speakers.
The process of translating a software package into another (or more than one other) language is time-consuming and expensive. Each text message, menu, and button must be translated to allow the user to operate the program. The most direct way to do this is to search the entire program source code for every text string, i.e., every string of characters that would be displayed to the user, and translating each of these to the new language.
This approach has several problems. One problem is that the use of this method means that the software must be specifically translated and compiled for each intended language. This, of course, is an expensive process in itself, and means that any change in the source code requires each language version of the code to be edited and recompiled.
FIG. 2 shows an example of hardcoded labels in a Java application. In this Figure, window 200 shown with two graphical user interface (GUI) "buttons" 210 and 230. These buttons are created using a hard-coded Java "JButton" call; for example, code-line 220 calls JButton with the string argument "Ok", creating button 210 with text label "Ok". Similarly, code-line 240 calls JButton with the string argument "Cancel", creating button 230 with text label "Cancel". To translate a software application which uses hard-coded strings as in FIG. 2, each line of the code must be parsed and each displayed string must be individually translated for each target language.
One solution to this problem is the use of separate localization files, in which the text strings that are to be displayed are stored separately from the executable code itself. As the software is executed, the text for every given display screen is simply read from the localization files, in whichever language is stored in the file. In this manner, the text in the localization file can be translated without disturbing the executable, and the executable can be changed or replaced without disturbing the translated text (except, of course, that if the text to be displayed changes, the corresponding entries in the localization files must also be changed). The localization files may be in any number of formats, including compiled message catalogs, Java resource bundles, HTML files, and many others.
The use of localization files provides an easy way to do multiple translations, but presents an additional problem in that the translation is performed on text isolated in a separate file, without any kind of context for the translator. Because this is the case, the translation will often contain errors which would not be present if the translator had been able to perform the translation according to the context in which the text appears.
However the translation is handled, each screen of the program in operation must then be proofread to ensure that the translated text is properly displayed and properly translates the text in the context of the display. Therefore, it has become common practice to hire individuals with backgrounds in other languages to proofread each screen of the translated program to detect any display, grammar, or other translation errors. This second phase is called Translation Verification Testing (TVT).
FIG. 3 shows a chart of a translation and testing cycle according to conventional methods. A typical Company A, located in Country A, builds the application intended for Country B (310). Next, Company A packages and ships the application to Company B, located in Country B (320). Company B will then execute the application to test for any translation or internationalization errors (330). Company B will then do TVT testing, note any translation errors, and make any necessary retranslations (340). Company B then ships the corrections back to company A, and the process repeats until no more errors are found.
According to this conventional process, each time an error is corrected or a change made in translation in Country B, the product must be rebuilt and repackaged in Country A before it is retested. Because of this, the TVT process is necessarily an expensive and time-consuming process. It would therefore be desirable to provide a means to provide additional information to the translator, and contextual information in particular, so that the initial translation is as accurate as possible. By doing so, the cost and time required for TVT testing can be reduced or eliminated.
Java
Java is two things: a programming language and a platform. In one aspect, Java is a high-level programming language, and is unusual in that each Java program is both compiled and interpreted, to make it accessible to many platforms. Java is also a software-only platform that runs on top of other, hardware-based platforms. The Java platform has two components; the Java Virtual Machine (Java VM), and the Java Application Programming Interface (Java API).
The Java VM is the base for the Java platform and is ported onto various hardware-based platforms. The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into libraries (packages) of related components.
JavaBeans brings component technology to the Java platform. JavaBeans API supports reuseable, platform-independent components. Using JavaBeans-compliant application builder tools, components can be combined into applets, applications, or composite components. JavaBean components are known as Beans.