System and methods for translating software into localized versions

What is claimed is:

1. In a computer system, a method for assisting a user with translating a software program into a translated version which is localized for a particular locale, the software program having a plurality of resources for displaying a user interface, the method comprising:

(a) extracting translatable items of said resources from the software program, said translatable items including locale-dependent text strings which are displayed by said user interface and dimensions of said resources;

(b) storing said extracted translatable items in a translation table, said translation table for assisting with translating a locale dependent text string of a particular extracted translatable item to a new text string for the particular locale and inputting a new dimension of a resource of said particular extracted translatable item; and

(c) translating said software program by translating at least one of the text strings of said extracted translatable items to a new text string for the particular locale, while at the same time indicating to the user how said new text string will appear in the user interface of the translated version so that said new dimension may be entered by the user.

2. The method of claim 1, wherein said translation table stores said extracted translatable items in a format which is independent of how resources are stored in the software program.

3. The method of claim 1, wherein step (a) includes:

assigning a unique identifier to each translatable item extracted.

4. The method of claim 3, wherein said unique identifier remains static throughout the life of said software programs.

5. The method of claim 1, wherein said resources include dialogs and menus displayed by said interface.

6. The method of claim 5, wherein said translated items include text strings displayed by said dialogs and menus.

7. The method of claim 6, wherein said translatable items further include dimensions for resources of said text strings displayed by said dialogs and menus.

8. The method of claim 1, wherein step (a) includes:

parsing resource information from a source file of the software program.

9. The method of claim 1, wherein step (a) includes decompiling resource information from a binary copy of the software program.

10. The method of claim 1, wherein said locale dependent text strings are in English prior to translation.

11. The method of claim 1, wherein said software program is a Microsoft Windows-compatible software program, and wherein said resources comprise Microsoft Windows application resources.

12. The method of claim 1, wherein step (b) includes: storing a string value and a dimension for each of the resources which is displayed as text by said user interface.

13. The method of claim 1, wherein said resources include a first resource which is displayed within a second resource, said second resource being a "father" resource and said first resource being a "child" resource.

14. The method of claim 13, wherein said translation table stores for each "child" resource extracted an identifier for referencing a corresponding "father" resource.

15. The method of claim 13, wherein said "father" resource is a dialog resource and wherein said "child" resource is a text string resource displayed within the dialog resource.

16. The method of claim 15, wherein said "father" resource, which is a dialog resource, is itself not displayed within another resource, and wherein said translation table stores a NULL value as the "father" identifier for the dialog resource.

17. The method of claim 1, wherein said new text string is translated into a non-English language.

18. The method of claim 1, wherein step (c) includes:

displaying a string editor having a string field storing text strings of the software program and having a new string field for storing translated strings entered by the user.

19. The method of claim 18, wherein step (c) further includes:

displaying a dialog editor showing a dialog resource of the software program and also showing a translated version of said dialog resource, said translated version being updated to show translated strings as they are entered by the user.

20. The method of claim 18, wherein step (c) further includes:

displaying in the string editor a dimension field storing coordinates of resources of the software product and also displaying a new dimension field storing new coordinates of resources having text strings which have been translated by the user.

21. A computer system for assisting a user with translating a software program from one natural language to another, the system comprising:

a computer system having a screen display, said screen display for displaying a user interface of the software program;

a parsing engine for extracting translatable items including text strings and dimensions of resources from the user interface of the software program and storing those items in a database, said database storing text strings for at least two natural languages; and

editors, operably coupled to the database, for translating text strings from one natural language to another while simultaneously showing the user how the translated text strings will appear in the user interface of a translated version of the software program utilizing dimensions stored in said database, and allowing a user to change dimensions of resources of the user interface of the software program to accommodate the translated text strings.

22. The system of claim 21, wherein said translatable items include text strings of the user interface and dimensions of resources including those text strings.

23. The system of claim 21, wherein said parsing engine includes:

means for extracting resource information from the software program and determining translatable items present in said extracted resource information.

24. The system of claim 21, further comprising:

exporting means for replacing translatable items of the software program which have been translated by the user with translated versions of those items.

25. The method of claim 21, wherein said database maintains a format which is independent of how resources are stored in the software program.

26. The system of claim 21, wherein said database includes fields for storing text strings and dimensions of resources as translatable items and also includes fields for storing new text strings and new dimensions for translatable items which have been translated by the user.

27. The system of claim 21, wherein said editors include selected ones of a string editor, a menu editor, and a dialog editor.

28. The system of claim 21, wherein said resources include dialog boxes, menus and controls displayed on said display screen.

29. The system of claim 21, wherein each dimension describes a size and position of a resource on said screen display, and wherein said parsing means stores with each translatable item its dimension.

30. In a computer system, an improved method for translating a computer program from one natural language to another, the improvement comprising:

(a) parsing user interface resources of the computer program into a central data container;

(b) storing with each resource its dimension as it appears on a user interface of the computer program; and

(c) displaying at least one editor for translating text strings of said user interface resources, said at least one editor illustrating how each user interface resource which is translated will appear in the user interface of the computer program, including allowing a user to adjust the dimension of selected user interface resources which are translated.

31. The method of claim 30, wherein step (a) includes:

assigning each user interface resource a static ID for uniquely identifying the resource throughout different versions of the computer program.

32. The method of claim 30, wherein step (a) includes:

determining whether a first user interface resource is contained within a second user interface resource; and

if a first user interface resource is determined to be contained within a second user interface resource, storing with the first user interface resource a parent ID for locating said second user interface resource.

33. The method of claim 30, wherein step (a) includes:

parsing programmers' comments present with said user interface resources and storing those comments in the central data container, for future use by an end-user translator.

34. The method of claim 30, wherein step (c) includes:

displaying a translator comment field for receiving a descriptive message from an end-user translator, so that descriptive messages can be stored with each user interface resource which is translated.

35. The method of claim 30, further comprising:

exporting said translated text strings out to a translated resource file; and

creating a translated version of the computer program by re-building the computer program with said translated resource file.

36. In a computer system, a method of translating a software program into a translated version, said software program having a plurality of screen objects in a graphical user interface, the method comprising the steps of:

extracting text strings and dimensions associated with screen objects of said graphical user interface of said software program;

translating a selected screen object by entering a new text string for said selected object;

displaying said selected object with said new text string and said extracted dimensions;

inputting new dimensions for said displayed selected object to accommodate said new text string; and

generating said translated version which includes said selected screen object with said new text string and said new dimensions.

37. The method of claim 36, further comprising the step of storing said text strings and dimensions in a translation table according to the screen object to which they are associated.

38. The method of claim 37, further comprising the step of storing a unique identifier in said translation table for each of said screen objects.

39. The method of claim 37, further comprising the step of storing values in said translation table indicating if a screen object is displayed within another screen object.

40. A computer program product that translates a software program into a translated version, said software program having a plurality of screen objects in a graphical user interface, the computer program product comprising:

computer code that extracts text strings and dimensions associated with screen objects of said graphical user interface of said software program;

computer code that translates a selected screen object by receiving input of a new text string for said selected object;

computer code that displays said selected object with said new text string and said extracted dimensions;

computer code that receives new dimensions for said displayed selected object as input from a user to accommodate said new text string;

computer code that generates said translated version which includes said selected screen object with said new text string and said new dimensions; and

a computer readable medium that stores said computer codes.

41. The computer program product of claim 40, further comprising computer code that stores said text strings and dimensions in a translation table according to the screen object to which they are associated.

42. The computer program product of claim 41, further comprising computer code that stores a unique identifier in said translation table for each of said screen objects.

43. The computer program product of claim 41, further comprising computer code that stores values in said translation table indicating if a screen object is displayed within another screen object.

Description Submit all comments and votes

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

For software publishers, overseas markets comprise an ever-growing percentage of revenues for all major PC applications. Traditionally, however, software products have been designed with little or no thought toward portability, let alone translating software products for overseas markets. As non-English speaking countries are buying more and more software from U.S. publishers, there is keen interest in improving the process of enabling or "internationalization", that is, designing and coding a software product so that it can be made to function for international use.

In the past, the process of providing National Language Support (i.e., accommodating a specific country's language, conventions, and culture) was done on a more or less ad hoc basis--essentially retrofitting software to accommodate a particular locale. Merely separating the text in a user interface from one's program is not an acceptable solution, however. Even after translating software prompts, help messages, and other textual information to the target languages, one still has to address basic issues of displaying and printing characters in the target language.

For instance, a target language will often include characters which are not defined by the default character set provided by the computer's operating system. IBM-compatible PCs running MS-DOS, for example, can display and print up to 256 different characters, the first 128 characters of which include the well-known 7-bit ASCII character set. This, of course, is not enough characters to support all languages. Some languages will obviously require a different character set; thus, sufficient means must be provided for switching character sets.

Other issues to consider when developing a system for foreign users include keyboard layout and various format conventions applicable for a particular country. Any use of currency, date, time, and the like within one's software must take into account these factors. For example, keyboards sold for European languages must include additional characters, such as letters with diacritics, and symbols, such as the British pound (.English Pound.) sign.

Another potentially serious problem for localizing a program is the set of assumptions with which the underlying source code for the program was written. Assumptions made by English-speaking programmers, which were quite valid for the once-ubiquitous ASCII character set, often break down when dealing with a foreign language. For instance, the common programming technique of converting a character to uppercase by simply adding the number 32 to the character (numeric code) is often inappropriate for non-ASCII characters. Similarly, one cannot rely on standard C functions either. For instance, one cannot use simple string comparison functions like the C programming language's strcmp() function. Does an "n" (i.e., an "a" with a diacritic) sort before or after a normal "a"?

One of the first serious attempts at providing National Language Support (NLS) for PCs was Microsoft's MS-DOS version 3.3. Since MS-DOS accommodates different sets of 256 characters for displaying and printing text, a system may employ different characters by swapping in new character sets. Each such character set is referred to as a "code page"; the code page in use at any given time is called the "active code page." When installing operating system software, a user typically selects a code page appropriate for his or her national language.

MS-DOS also includes an API (Application Programming Interface) having a variety of functions related to internationalization. Included are functions for inspecting code pages for determining and controlling how the keyboard, display, and printer handle characters. The API includes functions, for instance, for inspecting and changing the current country code and obtaining information about the conventions associated with a current country code (e.g., how to display dates, currency, and the like).

Newer versions of MS-DOS also include support for character comparisons, through use of language-independent tables for sorting strings. Still, this is by no means a complete solution to the problem. Arabic languages, for instance, remain problematic. For one, Arabic is read and written right-to-left, not left-to-right. Also, Arabic characters require contextual analysis in order to determine which of four different shapes the Arabic characters should have (depending upon location in a word or phrase). Thus, a language may have its own special set of problems which must be addressed before international use.

At the level of application development, software translation is typically accomplished by extracting "translatable strings" from various sources, translating them into the local language, and reinserting them back into the original sources for recompilation and linking. The approach has distinct disadvantages, however. For instance, the process of parsing different types of sources and extracting "translatable items" from those sources is prone to error. Owing to the complexity of modern-day software development, sources are typically very diverse, ranging for example from strings embedded in C/C++ source to well-organized data sets in resource files. The ability of systems to reliably parse these different types of sources and identify each translatable item by a unique token is fairly limited. This limitation substantially affects the success of steps in the process and the reusability of tools from one project to another.

To date, translation tools have focused on character-based information, taking into consideration only literal text strings. However, as more and more software development exploits graphical user interfaces, such as Microsoft Windows, this character-centric approach is inadequate. Other elements of the user interface require appropriate handling. For instance, the use of particular icons and bitmaps in one locale may be entirely inappropriate in another locale. Moreover, a system should take into consideration secondary effects of translation. For instance, translating a prompt in a dialog box from English to German may, in fact, require that the dialog box be resized (e.g., to accommodate a larger text string).

Moreover, the present-day approach to software translation requires substantial human resources. Since tools are not typically reusable, the cost of developing new tools and having translators learn them can be quite substantial. These costs result not only from the resources required for training translators but also result from the delays in bringing a product to market.

SUMMARY OF THE INVENTION

The present invention comprises a Software Translation Kit (STK) system having a shell, TShell, coupled to an Export/Import module and various Editors. The Export/Import module itself includes a parsing engine to extract strings and translatable information from application programs. It functions as a front end parser to "translatable" sources, providing data conversion as needed.

Employing TShell as a front end, an end-user translator employs the various modules of the system as follows. First, the sources are parsed by the Export/Import module to a translatable format. As shown, a resource file for the original program may be obtained (e.g., from the original source files), or may be generated from the original program by decompiling the resources bound to a program into a resource file (e.g., Microsoft Windows .RC format). From there, Export/Import (EXPIMP) module parses the resource file into a Translation Table, which is typically stored as a database table. The Translation Table encapsulates all the information that is known or can be derived from the various resources and stores them in a format which may be utilized by various editors.

Using editors, which may include a string editor, menu editor, dialog editor, and the like, the end user (translator) can easily access and manipulate the various resources of the program for carrying out translation. The translations themselves are stored back in the Translation Table. Once the end-user translator has completed the task of translating the resources, the translated text is merged back to sources. The Export/Import module is again employed, this time for generating a translated resource file. The translated resource file is similar to the original resource file, except that any necessary translations (e.g., translating an English text string into a French text string) have been carried out. In addition to translating text strings, other graphical user interface modifications, such as resizing of resources, have also been carried out.

Once the translated resource file has been generated, the target product is rebuilt with the new sources. The file may be simply stored back with the source files, as a translated resource file(s); or, the translated resource file may be compiled and bound back into the target program directly. In either instance, the underlying program code (i.e., the code which the programmer has written to carry out the functionality of the program) has remained untouched by the process.

The system of the present invention provides translators with a common user interface and translation platform, so that one need not continually learn new tools every time a new product requires translation. Thus, the system of the present invention provides a standard set of translation tools which may be employed for all translation processes. Resources for products to be translated are stored in an external resource file in a standard format. Thus, the translation process need not interfere with the executable binary (i.e., main program) of a product. In this fashion, changing a product from one locale to another can be reduced to the simple process of swapping out resource files.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system in which the present invention may be embodied.

FIG. 2 is a block diagram of a software system of the present invention, which includes operating system, application software, and user interface components.

FIG. 3 is a block diagram of a Software Translation Kit (STK) system of the present invention.

FIG. 4A is a bitmap screenshot illustrating a screen dialog box, which includes children components (e.g., screen buttons).

FIG. 4B illustrates the relationship between the dialog of FIG. 4A and underlying resource information (which orginally had been provided by the programmer creating the application).

FIG. 4C a diagram illustrating the relationship between source information (e.g., represented in Microsoft Windows resource format) and runtime API (Application Programming Interface) Windows call, CreateWindow.

FIG. 5A is a bitmap screenshot illustrating Windows Notepad--a simple Windows application for illustrating operation of the STK system of the present invention.

FIG. 5B is a diagram illustrating resource information for a screen menu of the application of FIG. 5A.

FIG. 5C is a bitmap screenshot illustrating the File.vertline.Open command of Notepad.

FIG. 6A is a bitmap screenshot illustrating a Graphical User Interface (GUI) or workspace for the software translation system of the present invention.

FIG. 6B illustrates a translation table of the present invention, which serves as a data container for storing translatable information.

FIG. 7 is a bitmap screenshot illustrating a TShell dialog interface, which serves as a front end for operating the system.

FIG. 8A is a bitmap screenshot illustrating a string editor of the present invention.

FIG. 8B is a bitmap screenshot illustrating a menu editor of the present invention.

FIGS. 9A-B are bitmap screenshots illustrating a dialog editor of the present invention.

FIGS. 10A-F are bitmap screenshots illustrating the process of translating a particular resource, Windows Notepad "Page Setup " dialog.

FIG. 11 is a block diagram illustrating layout of the translation table of the present invention.

FIG. 12A is a flowchart illustrating an Export/Import method of the present invention.

FIG. 12B is a flowchart illustrating a "Build" method of the present invention.

FIG. 12C is a flowchart illustrating a "FillFields" method of the present invention, for use with dialog controls.

FIG. 12D is a flowchart illustrating a "FillFields" method of the present invention, for use with controls.

FIG. 12E is a flowchart illustrating an "Update File" method of the present invention.

FIG. 12F is a flowchart illustrating a "CreateChilds" method of the present invention, for use with dialog objects.

GLOSSARY

ASCII: American Standard Code for Information Interchange; a sequence of 128 standard characters.

Code page: A character set, such as available in MS-DOS versions 3.3 and later, that provides a table for relating the binary character codes used by a program to keys on a keyboard or to the appearance of characters on a display.

Database: An organized collection of information.

Database Management System (DBMS): System that controls the organization, storage, and retrieval of information in a database.

Enabling or Internationalization: Designing and coding a product so that it can be made to function for international use. A product is enabled if a national language version can be created at minimal expense and if it does not interfere with current or planned national language support of other products.

File: A collection of information stored under one name on a disk. For example, the system tables are stored in files.

Index: A file that determines an order in which the system can access the records in a table.

Glyph: A graphic representation of a single character.

Localization: Translating and adding functions to an enabled product to accommodate a country's languages, conventions, and cultures.

National Language: A language or dialect spoken by any group of people.

National Language Support: The features of a product that accommodate a specific country, national language, local convention, culture, and the like.

National Language Version: A variant of an original product that implements National Language Support and is targeted to a particular market.

Retrofitting: Redesign and modification of a product that has not been enabled.

Table: A structure made up(fields) that contains columns (fields) that contains information.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The following description will focus on the presently preferred embodiment of the present invention, which is operative in the Microsoft.RTM. Windows environment operating on Intel-compatible computer system. The present invention, however, is not limited to any particular one application or any particular windows environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously applied to a variety of system and application software, including database management systems, wordprocessors, spreadsheets, and the like. Moreover, the present invention may be embodied on a variety of different platforms, including Macintosh, UNIX, NextStep, and the like. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

General Architecture

The present invention may be embodied on a computer system such as the system 100 of FIG. 1, which includes a central processor 101, a main memory 102 (e.g., random-access memory or RAM), an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display device 106, and a non-volatile or mass storage 107 (e.g., hard or fixed disk, optical disk, magneto-optical disk, or flash memory). Processor 101 includes or is coupled to a cache memory 109 for storing frequently accessed information; memory 109 may be an on-chip cache or external cache (as shown). System 100 may also be provided with additional input/output devices, such as a printing device 108, as desired. The various components of the system 100 communicate through a system bus 110 or similar architecture, as shown.

Illustrated in FIG. 2, a computer software system 200 is provided for directing the operation of the computer system 100. Software system 200, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system (OS) 240 and a windows shell 250. One or more application programs, such as application software 225 or windows application software 245, may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100.

System 200 includes a user interface (UI) 260, preferably a graphical user interface (GUI), for receiving user commands and data. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating module 240, Windows 250, and/or application modules 225, 245. The UI 260 also serves to display the results of an operation, whereupon the user may supply additional inputs or terminate the session. Although shown conceptually as a separate module, the UI is typically provided by Windows shell 250, operating under OS 240. In a preferred embodiment, OS 240 is MS-DOS and Windows 250 is Microsoft.RTM. Windows; both are available from Microsoft Corporation of Redmond, Wash.

System 200 also includes a Software Translation Kit (STK) system 300 of the present invention for aiding the translation of software programs to other target languages. As shown, the STK system 300 interfaces with the system 100 through Windows shell 250, as well as interfacing directly through OS 240. The construction and operation of the STK system 300 itself will now be described in detail.

Software Translation

A. Introduction

Consistency and upgradability are fundamental to a successful localization project. As a translated product is upgraded (to a new version), applications created using previous versions of the product should also work with the upgrade. This requirement is becoming increasingly important as vendors strive to release localized versions simultaneously with their main (e.g., English) version. In such an instance, changes occur with practically every new "build" of the product, with each product typically requiring hundreds of builds before commercial release.

In prior art systems, limitations exist on the ability of such systems to store resources in an external resource file. For instance, various parts of a product might be developed or acquired from third parties. Moreover, a particular piece of the product might not lend itself to storage in an external resource file. Examples include, for instance, application macro languages and binary objects created by the product. Another example includes a program sample where proper resourcing might render the sample too complex (and defeats the purpose of providing a simple sample). As will be described below, the present invention includes novel methods for extracting resource information into a platform-independent Translation Table.

So that translation work can be done by individuals with a broad range of technical skills, the system of the present invention focuses on ease of use and standardization; translators who are not programmers (i.e., might not understand how to trace through C++ source listings) can nevertheless still use the system. The system applies a standardized approach so that training can be minimized between projects; the same translators can be employed in different projects with minimum downtime. The approach also allows one to minimize the time needed to recreate new tools for every new project. At the same time, the system is powerful enough to provide translators with the ability to manipulate translation data, provide contextual information, and provide an interactive interface (i.e., emulating the build of the product and checking whether the final product is functional). Finally, the system is flexible enough to address the requirements for handling different types of resource files.

The STK system 300 provides end-user translators with a common user interface and standard translation platform, and localized graphic user interface products (e.g., ones operating under Microsoft Windows and IBM OS/2). Resources for products to be translated are stored in an external resource file in a standard format. The standard platform allows translators to act independently of the product they are translating. By providing generic tools and building blocks, the system affords quick translation of software and eliminates redundancy in development. The enduser translation need not continually learn new tools every time a new product requires translation.

B. Datacentric approach

Present day translation systems generally construct a database which stores only a token that uniquely identifies a string to be translated, the characters which comprise the string, and a translation string. In many cases, however, translation is performed directly over "source" files, that is without using a database at all.

In the system of the present invention, the approach adopted for translating software is "datacentric." During the translation process the focus is on the data: what data need to be extracted from resource files, translated into the local language, and reinserted into the sources (to be used to build the final localized product). Tools are written based on a central data structure--a Translation Table--which is generated by a parsing engine of the system.

In the system of the present invention, the Translation Table contains all the information needed to build editors which can simulate the target UI (User Interface) without having access to the sources or actual binary of the product to be translated. Having the data with this level of detail enables the system of the present invention to extract data from the source files and perform upgrades at a high level. Moreover, by storing the information in database format, the approach benefits from database features, such as a fourth-generation database manipulation language for manipulating the data (e.g., sorting, performing queries, and the like) and creating database forms and reports.

During system operation, all translatable strings are parsed out of original source format. User interfaces to be used as a translation interface are based on, or generated from, information contained in the central data structure. In this manner, data manipulation and upgrade can be performed either between tables or at the parsing extraction level.

Using a "datacentric" process, the translation system of the present invention implements a standard data (container) format, generic extraction tools, and generic editors. The standard format is defined for extracting and storing translation data; the format also specifies how editors will access the data. To ensure that translation work done for one version of a product can be carried forward to future versions automatically, every translatable item is uniquely identified by assigning it an ID which remains static throughout the life of the product. In other words, every translatable item extracted to the data structure is uniquely identified.

C. System Modules

FIG. 3 illustrates the functional modules of the STK system 300. Generally under control of TSHELL 310, a common front end and user interface to the translators, the various modules operate as follows. First, the sources are parsed to a translatable format. As shown, a resource file 325 for the original program may be obtained (e.g., from the original source files 313). Alternatively, the resource file may be generated from the original program 317 by using a commerical Resource Decompiler 320, such as Borland's Resource Workshop.RTM., which decompiles resources bound to a program into a resource file 325 (e.g., Microsoft Windows .RC format). From there, EXPIMP (Export/Import) Resource Parser 330 parses the resource file 325 into a Translation Table 340, which is typically stored as a database ta