Platform-independent real-time interface translation by token mapping without modification of application code

[0001] This application claims the benefit of U.S. Provisional Application Ser. No. 60/353,487 filed on Feb. 1, 2002 and titled “INTEGRATED MULTIMEDIA INTELLIGENCE ARCHITECTURE” which is incorporated herein by reference in its entirety for all that is taught and disclosed therein. This application is also related to Application Serial No. 10/357,326 filed on Feb. 3, 2003 titled “System and Method for Analyzing Data”, now U.S. Patent Application Publication 2003/0187633 A1, now allowed, by the same inventor as this invention, and to Application Serial No. 10/357,288 filed on Feb. 3, 2003 titled “System and Method for Managing Memory,” U.S. Patent Application Publication 2003/0182529 A1, now U.S. Pat. No. 7,103,749, by the same inventor as this invention, both of which are incorporated herein by reference in their entirety for all that is taught and disclosed therein.

[0002] The process of ‘localizing’ a software application (i.e., changing it to display its user interface in another language other than English) has historically been a very expensive and time-consuming business. So much so that the majority of software programs are never localized to any other language. An industry has sprung up to try to help companies localize their software by providing localization experts and target language speakers. These services are expensive and require the disclosure of sensitive trade secrets, such as source code, to third parties. In the last five years or so, the operating system manufacturers and programming language designers have made some steps towards trying to alleviate these problems. In all such cases, however, the basic approach is to have all user interface strings come from a ‘resource’ that is loaded from a different location depending on the language that is being used by the program. In this way, as long as the programmer always obtains text from this source through the mechanism provided, the code written should operate equally well in another language provided that all of the corresponding resources are available in that language. This approach, while an improvement over the previous situation, still has many shortcomings.

[0003] One problem with this approach is that it forces all code to be written from the outset with localization in mind. The programmer is no longer free to simply add or alter the text content of the user interface and certainly cannot use a string constant in the program source code. Because there is a natural tendency for programmers to use such content, however, it will often happen regardless of localization policies. The result of this approach to localization is that the program becomes unreadable, since it is very difficult to see by examining the code what is being ‘said’. Another problem with this approach is its limited ability to handle variable strings (i.e., those strings in which a portion of the string, such as the time, varies while the rest is constant). Yet another negative in this approach, regardless of the particular flavor (since all are basically similar), is that when strings are read back from the user interface elements (e.g., the name of a button), the strings can no longer be assumed to be in English and thus code that manipulates the UI cannot perform simple operations like checking if the button name is “OK” but must instead find a localization agnostic way to achieve this simple operation.

[0004] The end result of all these shortcomings is that designing a program for localization takes a lot of work and discipline, makes the code base obscure and highly dependant on the localization metaphor, and denies to programmers the simplifying model that their application is running only in English. What is needed then is another approach to localization that does not require any special calls from the programmer, does not deny the use of simple English string constants, is platform and language independent, and maintains the ability to read back English from the elements of the UI.

[0005] The present invention provides a localization system that is completely platform independent, requires no support from the underlying language or operating system, meets all of the goals listed above, and also provides some other significant benefits not possible with traditional resource based approaches. In the preferred embodiment, the only time text is localized is as the text is actually drawn to the screen, it is not even localized within the building blocks (controls, windows etc.) of the graphical user interface (GUI) environment being used. Initially, the GUI environment makes a call for the translation immediately prior to rendering the interface on screen. This callback can be facilitated via a single entry point in the “draw string” call which is generally made to the underlying OS by the GUI environment. The dictionaries for a given GUI are built up automatically at the time of rendering and do not need to be predefined or set up. The key to this approach is the ability to very rapidly look up English language strings in a number of translation dictionaries so that the strings can be translated in real-time and on-the-fly. In one embodiment, the dynamic and fast inverted file dictionary used for this purpose is the lexical analyzer functionality described in Appendix 1 combined with the “string list” capability described in Appendix 2. Alternatively, the “string list” capability, or indeed any rapid string lookup facility, will suffice.

[0006] The primary components of this invention are:

• • [0007] A lookup mapping between text fonts in English (e.g., Courier, Geneva etc.) and the corresponding font to be used in a foreign language. Often there is a ‘bilingual’ font, which is one whose character encodings can display both English text and foreign text (usually for 8-bit encodings these characters have the most significant bit set for non-English characters).
  • [0008] A set of dictionaries mapping English phrases into the corresponding phrase in another language as expressed in the text encoding for the mapped font selected for that language.
  • [0009] Preferably, a GUI environment that is capable of making a callback whenever it is about to write a string to the interface. Alternately, one can ‘patch’ the DrawString( ) call of the underlying OS (which will be used by virtually any GUI environment) so that the GUI environment can be trapped when it draws and caused to translate. This patching approach, while practical, is less desirable and provides less control over some of the more exotic features described below. The parameters to the DrawString( ) callback (or patch) must include the English string to be drawn (modified on translation), the bounding rectangle into which the string will be drawn (may be modified), the font characteristics (font, size, style etc. may be modified), and the text justification (may be modified).

[0013] Appendix A (attached) provides a sample C language Application Programming Interface (API) to the translation facility of this invention.

[0014] A key difference with conventional approaches and the present invention is that the dictionaries of the present invention need not be pre-defined but can instead be created dynamically at the time of rendering. Referring now to FIG. 1, the “callback” translation process is illustrated. When a program is running in foreign language ‘X’ and it makes a call 110 to render the string “the cat sat on the mat” in that language, the callback looks 120 for a translation of this phrase and if not found 130, adds 135 the phrase to the dictionary of phrases that need to be translated. If found 140, the phrase associated with the string in the dictionary of phrases is rendered 145 by the program. This means that the dictionary creation happens automatically as a result of program execution without regard to where the string itself came from. This also means that the programmer is free to use English string constants in his code while being assured that such constants will translate just like any other strings. This is a huge simplification of the programming model. The preferred way to dynamically build dictionaries and rapidly look up large numbers of phrases being drawn to the UI in these dictionaries, is to use the lexical analyzer facility described in Appendix 1 in combination with the “string list” capability described in Appendix 2. Alternatively, almost any sufficiently rapid string lookup capability will suffice. The approach described in the preferred embodiment (i.e., to use dynamic lexical analyzer and string list construction) is both fast and capable of very large dynamic dictionary building.

[0015] The lexical analyzer and string list tables that make up the “inverted file” dictionary lookup are saved between runs into files, and each dictionary is named based on the context of its use. There may be any number of distinct dictionaries in the system depending on how may different subsystems make calls back into the translation API and for what purposes. The primary routines involved in this dictionary construction and reference process (in addition to the DrawString( ) callback) are XL_GetString( ), XL_vSprintfCatHdl( ), XL_SprintfCatHdl( ), XL_GetDictionary( ), XL_SaveDictionary( ), and XL_FlushDictionaries( ).

[0016] The routine XL_GetDictionary( ) returns a reference to a named source (English) or target (other language) dictionary. If the dictionary is not currently in memory, it is loaded. If it does not exist, it is created (empty) as is the corresponding dictionary file. A programmer can use this function to explicitly force pre-loading of a dictionary before use. Alternatively, automatic saving may be suppressed, the handle to the source dictionary obtained and then a save can be forced by the routine. This is most useful when it is expected that many words will be added to the dictionary at once as this approach optimizes the process so that only a single save is required. Referring now to Appendix A, pseudo code for this routine is provided. In this example, if the current language is English and 0 is passed for ‘aLanguage’, this function will return NULL since there is no target dictionary for English. To obtain the source dictionary, ‘kAmericanEnglish’ (in this example, the language from which all others are translations) must be passed explicitly. If a dictionary has already been referenced and is thus loaded into memory cache, it is simply returned.

[0017] XL_SaveDictionary( ) saves a dictionary to the corresponding dictionary file. This action is normally automatic unless dictionary saves are suppressed (using the option described above). In such a case, the dictionary reference will need to be passed using this routine in order to “force” a save after all additions have been made.

[0018] Another routine is provided, XL_FlushDictionaries( ), which forces any un-saved dictionary changes to be flushed to file. This would be most applicable when automatic saves have been suppressed.

[0019] Another routine is provided, XL_GetDictionary( ), which provides basic dictionary building operations. For each dictionary(ies) involved, the routine looks up the English language phrase in that dictionary, and if not found, adds the phrase to the target dictionary (and the source if not found there). This process is illustrated in FIG. 1.

[0020] In the preferred embodiment, this invention maintains a list of those languages that are supported and the corresponding language name and language code (which is basically a lookup index into the various tables required to support the language). A parameter, ‘aLanguage’, corresponds to the index necessary to locate the language concerned in the supported language tables. Two special cases are defined. A language code of ‘kCurrentLanguage ==0’ is interpreted to mean the language currently in effect (saved in a global). Most if not all calls to the translation facility will specify a language code of zero, which will cause the result to automatically track the language the user has selected. This language may be changed as the program is running which will result in the immediate and dynamic translation of the UI into the newly selected language. This is a far more powerful capability than most localization approaches which tend to work only in one language. Indeed, it is so useful to be able to dynamically flip languages that language code ‘kAlternateLanguage’ is a special case to mean the ‘alternate language’ which is a user configurable preference (saved in a global). This improvement reflects the fact that most users of foreign languages may still need to flip dynamically back and forth between that language and English as part of their normal workflow. As a result, any application built to work in conjunction with this translation methodology can provide a user with the ability to flip the language used to render the UI “on the fly.”

[0021] For any supported language, this methodology also provides certain basic mapping tables indexed by language code. These are as follows:

• • [0022] A sort order mapping. This maps each character encoding for the language into their corresponding lexical sort order. This is used so that list sorting in the UI occurs properly. Access to this capability from the UI and code is via the routines, in this embodiment XL_strcmp( ), XL_strncmp( ), XL_strcmpNC (case insensitive), and XL_strncmpNC(case insensitive). These functions are essentially identical to the standard C libraries of the same name but utilize the language code to select the necessary sort order mapping table.
  • [0023] A list of additional punctuation characters specific to the target language.
  • [0024] A table mapping language code index for such things as language name, script system (e.g., Roman, Cyrillic etc.), sort order mapping table, and punctuation character list.
  • [0025] A table encoding for each character in the language knowledge of whether that character is a letter, number, etc. These characteristics provide language dependant capabilities identical to those provided for English by the standard ANSI C library functions. In the illustrated embodiment, these capabilities can be accessed via the following functions: XL_isalnum( ), XL_isalpha( ), XL_iscntrl( ),XL_isdigit( ), XL_isgraph( ), XL_islower( ), XL_isprint( ), XL_ispunct( ), XL_isspace( ), XL_isupper( ), XL_isxdigit( ), and XL_isdiacritic( ). The last routine is applicable only to non-Roman script systems and has no ANSI correlate. This routine determines if the character involved is in fact a diacritical mark (e.g., the French circumflex accent) and not a basic character in the alphabet. Diacriticals are crucial in constructing some non-Roman script languages such as Arabic.
  • [0026] A pair of tables mapping upper and lower case characters to the alternate case equivalent (if relevant in the script system concerned). These mappings could also be accessed by separate routines, XL_tolower( ) and XL_toupper( ), which are language dependant versions of the ASCI C equivalents.

[0027] In the preferred embodiment, a number of API routines are also provided that can be readily implemented as simple operations on these mapping tables and are not further described herein.

[0028] The key algorithm of this invention is the routine XL_GetString( ). This routine, as illustrated in FIG. 1 above, translates an English String to another supported language. If the translation cannot be performed, the English string is copied over unmodified and the function returns FALSE. Otherwise the ‘xlatedStr’ output will contain a pointer to the translated output string. In the case that a translation cannot be made, the un-translatable string is added to the specified dictionary (which is updated/saved). This means that at a later time, either a person or a separately automated process can enter the necessary translation in the target language into the dictionary. Alternatively, the dictionary can be exported as a glossary containing a series of English strings together with the translated string on each line where the two parts are tab delimited. Such glossaries can be bulk translated by language experts and then re-imported to form the corresponding run-time dictionaries.

[0029] The details of this import/export process can be readily deduced by application of the other API functions described herein. If a dictionary selection string is set to NULL, the function XL_GetString( ) will attempt to find a translation in all available dictionaries, starting with the last one in the list and ending with the standard built in dictionary. By starting with the last dictionary on the list, custom dictionaries may be used to override a standard dictionary. In this NULL case, the English string associated with a failed translation will be written to the standard dictionary and saved. In addition to simple translation of strings, this function can perform complete sprintf( )-like functionality including the independent translation of each substitution sequence once it has been substituted.

[0030] The present invention is also capable of re-mapping the substitutions to a different order within the output string in order to account for the different grammar of other languages. To illustrate this, assume that the call below that requests a translation of a dynamic English string into the equivalent Arabic:

[0031]

	XL_GetString( NULL,kArabic,&resultStr,
	“Schrodinger's cat %s has %5.3f lives left out of%d”,
	kDoSprintfTranslate,catName,livesLeft,9);

and that in the Arabic standard dictionary, the translation of the string above contains: “. . . arabic1. . . %2. . . arabic2. . . %0. . . arabic3. . . %1”. In this case, the number and type of the substitution specifiers must exactly match the number in the English string, however, the order may be different (to account for different word ordering between languages). In this example, the correct re-ordering operations are performed by substituting the specifier ‘%’ in the translated string followed by a decimal number (which gives the zero based index of the corresponding substitution string in the original English string). This process allows the translation capability to easily handle variable strings without causing undue dictionary clutter, and is yet another advantage of the translation scheme of this invention. This capability is not supported by other existing translation schemes. Substitutions that cannot be translated will be made in English into the foreign string. Numeric values are translated into the appropriate foreign symbols when appropriate (e.g., Arabic) unless suppressed using ‘kNoNumericTranslate’ option.

[0032] Referring now to Appendix A, the pseudo code for the algorithm involved in XL_GetString( ) is provided. The routines XL_vSprintfCatHdl ( ) and XL_SprintfCatHdl ( ) are merely specialized forms of calls to XL_GetString( ), which both call, and are provided primarily as a convenience.

[0033] The process of looking up and mapping the strings detailed in the algorithm above is, based on the routine LX_Lex( ) which yields a string list offset (ET_Offset-Appendix 2) to the translated string, while adding strings to the dictionary is essentially a call to LX_Add( ). Both lexical functions are fully described in that application, which is expressly incorporated herein.

[0034] Another algorithm involved in the preferred embodiment of this invention is the DrawString( ) callback that makes the actual transformation prior to rendering to the screen. The pseudo code for this function is provided in Appendix A (depending on GUI support level). This callback first determines the current language selected (via a global) and the font and other settings passed in on the call from the GUI framework. In one embodiment, the callback could include logic associated with text justification and font mapping, which can be implemented in any number of ways that would be obvious to those skilled in the art. In the preferred embodiment, the callback would also include two other calls. The first is a call to XL_GetString( ) to make the actual translation (explained above). The second call is to a routine, hereinafter called UI_ShrinkToFit( ). This function will attempt to modify a string's drawing attributes to get it to fit within a specified rectangle. This function will condense, and/or modify the text style, and/or shrink the text down to a size that fits within the bounding rectangle. The font size lower limit is 6 points. In the end the text will have its Font size and Font Style manipulated to get as much of the text in the text rectangle. in the preferred embodiment, the function will also return the fixed number of pixels that would be required to adjust the rectangle to keep the text centered vertically. This routine would be particularly useful if the translated string contained a vastly different number of characters than did the original and thus may no longer fit comfortably in the bounding rectangle originally specified on the screen. Since the bounding rectangle of the text cannot be grown without the risk of it clobbering other aspects of the GUI, this routine is responsible for making whatever adjustments are necessary to accommodate the new text into the space originally laid out for the English control text. In many cases, this routine will reduce the font size which may in turn result in text that is not vertically centered. In such a case, this ‘fix’ amount would be returned by UI_ShrinkToFit( ) and used to adjust the bounding rectangle in order to keep the text centered.

[0035] The exact details of this shrinking process depend on the underlying font support of the native operating system. The basic approach, however, is to loop attempting successive modifications to the font rendering characteristics until the text can be made to fit including (in order) adjusting:

[0036] a) The number of lines of text displayed (including use of word wrapping)

[0037] b). The bounding box itself (within clipping limits)

[0038] c) The text style may be changed to ‘condensed’

[0039] d) Other style attributes such as ‘bold’, ‘outline’, ‘shadow’ etc. may be stripped off

[0040] e) The font size may be reduced gradually down to a 6-point lower limit.

[0041] Referring now to FIG. 2, an “Error Browser” window is illustrated running in English and the user is in the process of selecting the Arabic language from the language selector menu. FIG. 6 illustrates the appearance of the same window after translation into Arabic. As FIG. 3 illustrates, no translation for the English phrase “Browser” 310 was found (nor for the titles of the columns 320 in the top list) in the dictionaries and thus these strings 310, 320 are still displayed in the original English (see the algorithm for the DrawString described above). If the user subsequently added a translation for these phrases then these strings also would be translated in future window invocations. Note also that in addition to translating the window text, the UI has been flipped automatically from left to right. This is because Arabic is a right-to-left script and thus window layouts should be reversed for natural operation in this script. This tie-in to the window layout has not been discussed above since the mechanism for achieving this is highly dependant on the GUI environment in use; however, the ability to make these dynamic GUI layout changes is another key advantage of the Just In Time (“JIT”) translation approach because any such operations can simply be added to the rendering process (described above). Note also that the Arabic font used in certain buttons 330, 340 (e.g., “Search” and “Sort”) has been reduced in size from that in the English equivalent and also un-bolded (while maintaining text centering in the control). This is because the corresponding Arabic text would not fit in the available control text area in the original size and style. Again this process is accomplished within the routine UI_ShrinkToFit( ) as described above. As part of the translation process, the justification of the strings has also been flipped from left/right to the opposite thus ensuring that in the translated window, the labels adjacent to the field boxes now correctly butt up against the controls after the UI has been flipped. Finally, note that many of the buttons and labels end in punctuation 350, 360 (e.g., ‘. . . ,’ and‘:’). The DrawString( ) callback is designed to strip off this punctuation and then re-append it in translated fonTn after the main body of the text has been translated. This reduces clutter in the dictionaries by avoiding the need to have two translations for a given string, one with punctuation, and one without.

[0042] The foregoing description of the preferred-embodiments of the invention has been presented for the purposes of illustration and description. For example, although described with respect to English, any language could be used as the “base” language from which the dictionaries are generated. This term should not be narrowly construed to only apply to English based translation as the method and system could be used to convert between any two languages. Additionally, the claimed system and method should not be limited to text based translation. This invention could be applied to any system in which one or more pieces of information being communicated over a medium (a “token”), such as text strings, sound waves and images, could be translated into a “foreign” language. The descriptions of the header structures should also not be limited to the embodiments described. While the sample pseudo code provides examples of the code that may be used, the plurality of implementations that could in fact be developed is nearly limitless. For these reasons, this description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.