Method system and computer program product for storing bi-directional language data in a text string object for display on non-bidirectional operating systems

[0002] The present invention is related to the subject matter of the following commonly assigned, copending U.S. patent applications: Ser. No. 09/211,810 entitled “METHOD, SYSTEM, AND COMPUTER PROGRAM PRODUCT FOR PROVIDING A USER INTERFACE WITH ALTERNATIVE DISPLAY LANGUAGE CHOICES” and filed Dec. 15, 1998; Ser. No. 09/211,809 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR CAPTURING LANGUAGE TRANSLATION AND SORTING INFORMATION INTO A TEXT STRING CLASS” and filed Dec. 15, 1998; Ser. No. 09/211,808 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR SORTING TEXT STRINGS” and filed Dec. 15, 1998; now U.S. Pat. No. 6,389,386 Ser. No. 09/211,803 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR STORING TRANSLITERATION AND/OR PHONETIC SPELLING INFORMATION IN A TEXT STRING CLASS” and filed Dec. 15, 1998; Ser. No.09/211,799 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR ROTATING THROUGH A SEQUENCE OF DISPLAY STATES IN A MULTI-FIELD TEXT CLASS IN A GRAPHICAL USER INTERFACE” and filed Dec. 15, 1998; now U.S. Pat. No. 6,388,686 Ser. No. 09/211,802 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR CONTROLLING THE GRAPHICAL DISPLAY OF MULTI-FIELD TEXT STRING OBJECTS” and filed Dec. 15, 1998; Ser. No. 09/211,813 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR DISPLAYING THE CONTENTS OF ALL FIELDS IN A MULTI-FIELD TEXT STRING OBJECT” and filed Dec. 15, 1998; Ser. No. 09/211,801 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR DYNAMIC LANGUAGE SWITCHING N A MULTI-FIELD TEXT STRING OBJECT VIA MESSAGING” and filed Dec. 15, 1998; and Ser. No. 09/211,812 entitled “METHOD, SYSTEM AND COMPUTER PROGRAM PRODUCT FOR AUTOMATIC CHARACTER TRANSLITERATION IN A TEXT STRING OBJECT” and filed Dec. 15, 1998. The content of the above-referenced applications is incorporated herein by reference.

[0003] 1. Technical Field

[0004] The present invention relates in general to display of bidirectional text within a data processing system user interface and in particular to proper display of bidirectional text utilizing normal, left-to-right only directional display controls. Still more particularly, the present invention relates to employing a multi-field text string class to enable proper display of bidirectional text on both bidirectional and non-bidirectional systems.

[0005] 2. Description of the Related Art

[0006] Multinational companies often run information system (IS) networks which span multiple countries spread around the globe. To maximize the usefulness of such networks, operations within each country tend to run in the local language of the country. Where possible, names of abstract objects in user applications are in the local language and match the local language organization, city, or human names which the abstract objects represent. In the case of system management software, often abstract objects would represent each of a global enterprise's local offices.

[0007] Transferring data from one system to another within such a multinational network presents numerous challenges. One obstacle which must be overcome is the transfer of human language directionality. Unlike English and many other languages, certain human languages are customarily written from right-to-left rather than from left-to-right, or may be written in either direction. Hebrew, for example, is conventionally written right-to-left.

[0008] For transnational data exchange, language directionality may be addressed in the manner in which the text is encoded. The Unicode specification, for example, assigns a directionality to characters and defines a complex algorithm for determining the proper directionality of text. If a right-to-left text string is encountered, a user agent conforming to the Unicode specification is required to apply the Unicode bidirectional algorithm to display the characters within that string. Similarly, the HyperText Markup Language (HTML) offers higher-level markup constructs which do the same thing, such as the “dir” attribute (which is distinct from the DIR element) and the “BDO” element.

[0009] Support for bidirectional (“bidi”) text, or support for displaying text in either direction (right-to-left or left-to-right) depending on the cultural convention associated with the human language in which the text is written, is typically integrated into the operating system or application (e.g., browser), if provided at all. Normally bidi text cannot be displayed properly in the user interface of a non-bidi version of an operating system or application without implementation of specialized text display controls.

[0010] It would be desirable, therefore, to provide a mechanism allowing normal left-to-right only directional user interface display controls to properly display bidi text in a user interface.

[0011] It is therefore one object of the present invention to provide an improved method, system and computer program product for display of bidirectional text within a data processing system user interface.

[0012] It is another object of the present invention to provide a method, system and computer program product for proper display of bidirectional text in a data processing system user interface utilizing normal, left-to-right only directional display controls.

[0013] It is yet another object of the present invention to provide a method, system and computer program product for employing a multi-field text string class to enable proper display of bidirectional text on both bidirectional and non-bidirectional systems.

[0014] The foregoing objects are achieved as is now described. For languages requiring bidirectional (left-to-right and right-to-left) text display support, a multi-field text string object encapsulates both a normal logical ordered version of the text string entered and a reverse ordered version in separate fields. A bidirectional-support property of the multi-field text string object is set based on whether the host system supports bidirectional text displays. In response to a display request, the multi-field text string object checks the bidirectional-support property. If bidirectional text display is supported, the multi-field text string object sets the field containing the normally-ordered character sequence for the text string as the display field. If bidirectional text display is not supported, the multi-field text string object sets the field containing the reverse-ordered character sequence for the text string as the display field. Display controls receiving the normally-ordered character sequence should display the text string with the proper directionality (right-to-left). Display controls receiving the reverse-ordered character sequence will display the display field contents with the incorrect directionality (left-to-right) but, as a result of the character sequence reversal, will effectively display the text string with the proper directionality. Bidirectional text may thus be displayed on systems which do not support bidirectional text display, using only conventional, left-to-right only directional display controls.

[0015] The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.

[0016] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0017] FIG. 1 depicts a block diagram of a data processing system network in which a preferred embodiment of the present invention may be implemented;

[0018] FIG. 2 is a functional diagram of a data processing system within a data processing system network in accordance with a preferred embodiment of the present invention;

[0019] FIG. 3 depicts a diagram of a multi-field text string class employed in supporting display of bidirectional text on both bidirectional and non-bidirectional systems in accordance with a preferred embodiment of the present invention; and

[0020] FIG. 4 is a high level flowchart for a process of employing a multi-field text string class to support display of bidirectional text on both bidirectional and non-bidirectional systems in accordance with a preferred embodiment of the present invention.

[0021] With reference now to the figures, and in particular with reference to FIG. 1, a block diagram of a data processing system network in which a preferred embodiment of the present invention may be implemented is depicted. The data processing system network depicted includes a data processing system 100, which may be, for example, one of the Aptiva® models of personal computers available from International Business Machines Corporation of Armonk, N.Y. Data processing system 100 includes a processor 102, which in the exemplary embodiment is connected to a level two (L2) cache 104, which is connected in turn to a system bus 106. In the exemplary embodiment, data processing system 100 includes graphics adapter 116 connected to system bus 106, receiving user interface information for display 120.

[0022] Also connected to system bus 106 is system memory 108 and input/output (I/O) bus bridge 110. I/O bus bridge 110 couples I/O bus 112 to system bus 106, relaying and/or transforming data transactions from one bus to the other. Peripheral devices such as nonvolatile storage 114, which may be a hard disk drive, and keyboard/pointing device 116, which may include a conventional mouse, a trackball, or the like, are connected to I/O bus 112.

[0023] The exemplary embodiment shown in FIG. 1 is provided solely for the purposes of explaining the invention and those skilled in the art will recognize that numerous variations are possible, both in form and function. For instance, data processing system 100 might also include a compact disk read-only memory (CD-ROM) or digital video disk (DVD) drive, a sound card and audio speakers, and numerous other optional components. All such variations are believed to be within the spirit and scope of the present invention.

[0024] Data processing system 100 is coupled to data processing system 122 via communications link 124, to data processing system 126 via communications link 128, and to data processing system 130 via communications link 132. Data processing systems 122, 126, and 130 may exchange data including human language text such as files or system messages with data processing system 100. The human language text data transferred from any of data processing systems 122, 126, and 130 to data processing system 100 may include bidirectional language.

[0025] The data processing system network which is depicted and the Java implementation examples below are provided solely as examples for the purposes of explanation and are not intended to imply architectural limitations. Those skilled in the art will recognize the numerous programming languages which may be utilized, all of which are believed to be embraced within the spirit and scope of the invention.

[0026] Referring to FIG. 2, a functional diagram of a data processing system within a data processing system network in accordance with a preferred embodiment of the present invention is illustrated. As is known in the art, an operating system 204 runs on the hardware 202 making up data processing system 100. Hardware 202 includes the components depicted in FIG. 1 for data processing system 100. Operating system 204, as depicted in FIG. 2, is meant to include all software routines which control interaction with hardware 202, such as a basic input/output system (BIOS) allowing data reads and writes to a hard disk drive or other nonvolatile memory, as well as those software routines which enable an application to be utilized on data processing system 100. Operating system 204 may be, for instance, any of the Windows™ operating systems available from Microsoft Corporation of Redmond, Wash., including Windows NT.

[0027] In the preferred embodiment, data processing system 100 also includes an applications 206a-206nrunning on top of operating system 202. Applications 206a-206nmay be distributed applications executing on a network or group of networks spanning different systems or platforms.

[0028] Applications 206a-206nin the exemplary embodiment preferably have some communication directly with operating system 204. Operating system 204 includes a locale property 208 specifying the cultural conventions employed for display of text within the user interface 212 of operating system 204 and the user interfaces 212a-212nof applications 212a-212n. Locale property 208 preferably specifies cultural conventions relating to directional display of user interface text.

[0029] In the present invention, a language property (not shown) may be employed in addition to locale property 208 and the structure of the cultural support features may be split between the locale property 208 and language property. Locale property 208 may be employed to support cultural conventions such as regional holidays and religious dates, observance of daylight savings time, etc., and display formatting of currency, numbers, dates, and the like, while the language of user interface and system message text is based on the language property. In a preferred embodiment, locale property 208 contains a upper-case, two letter ISO Locale Code as defined by ISO-3166 (e.g., “US” for United States or “JP” for Japan). Locale property 208 is employed in conjunction with a multi-field text string object as described below to enable display of bidirectional language text on systems which do not support bidirectional text display.

[0030] With reference now to FIG. 3, a diagram of a multi-field text string class employed in supporting display of bidirectional text on both bidirectional and non-bidirectional systems in accordance with a preferred embodiment of the present invention is depicted. International String Control (“IString”) class 302 may be utilized in conjunction with the language property described above, particularly within data processing system networks spanning multiple countries around the globe. A fundamental problem in multinational computing environments which need to display or process data in multiple human languages is that a representation in one human language may become meaning-less as the data migrates to a system running in a different human language. A need exists, therefore, to capture alternative human language representations. This need is satisfied by IString class 302.

[0031] IString class 302 is preferably a Java class similar to the Java String class, which behaves like the String class by including similar methods. Most of the original behavior of the String class should be preserved, with additional functionality added and utilized only as needed. IString class 302 is a datatype which captures some of the meaning of spoken words which is normally lost when the word is reduced to a visual representation. IString class 302 is preferably utilized for all object names and system messages within a system.

[0032] The IString class 302 structure includes three different strings for each name, message, data, or text object: a baseString 304, a sortString 306, and an altString 308. BaseString 304 is the string within IString class 302 employed by default in the user interface display and may contain any text, usually the original text entered by the user in the local language where the IString object is created. SortString 306 may also be any text and is employed to allow correct sorting of non-phonetic languages and languages which are difficult to sort based only on the binary value of basestring 304. AltString 308 may be any text but should conventionally be filled with a latin character set representation of the pronunciation of the data contained in basestring 304. Thus, IString class 302 includes the original text (basestring 304), a sort key (sortString 306), and a pronunciation key (altString 308) for object names, system messages, and other data.

[0033] When implemented in Java, a constructor for an IString class 302 object may be composed of the following fields:

[0034] /** The base text String */ protected String baseString;

[0035] /** The related text String for proper collation */ protected String sortString;

[0036] /** The related alternate text String (pronunciation key) */ protected String altString;

[0037] /** The source locale, as an ISO-3166 code; used for collation */ protected String sourceLocale;

[0038] /** The source language, as an ISO-639 code */ protected String sourceLanguage;

[0039] /** The source variant defined for EBCIDIC and case mapping */ protected String sourceVariant;

[0040] /** The target locale, as an ISO-3166 code */ protected String targetLocale;

[0041] /** The target language, as an ISO-639 code */ protected String targetLanguage;

[0042] /** The target variant defined for EBCIDIC and case mapping */ protected String targetVariant;

[0043] /** The bidi support, either “true” or “false” */ protected String bidiLocale;

[0044] Complete listings of the upper-case, two letter ISO Country Codes defined by ISO-3166 and the lower-case, two letter ISO Language Codes defined by ISO-639 are readily available from a variety of sources on the Internet.

[0045] Table I illustrates how data within the IString data type 302 looks when represented as a table:

[0046] The input of data into fields baseString 304, sortString 306 and altString 308 by data input methods 310 with data derived from transliteration engine 320 or input method editor (IME) 324, and the display and manipulation of the contents of basestring 304, sortString 306 and altString 308 with or without messaging methods 326, as well as the operation of IString 302 with respect to those fields for different values of sourceLocale field 312, sourceLanguage field 314, targetLocale field 316, and targetLanguage 318, are described in greater detail in the related applications. For the sake of clarity, those subjects will not be again described herein.

[0047] In the present invention, IString class 302 includes bidiLocale field 330, which contains either a “true” value or a “false” value. The bidiLocale field 330 is set based on the locale property of the underlying operating system, which specified whether bidirectional text display is supported. If the operating system locale property does not directly specify whether bidirectional text display is supported, a lookup table of locales for each operating system may be necessary to properly set the value of bidiLocale field 330. Alternatively, however, in the absence of specification by the operating system of whether bidi text is supported, bidiLocale property 330 may be set to a default value of “false” and the normal, left-to-right only directional display controls of the operating system may be employed to display the bidirectional text properly.

[0048] In the present invention, text strings entered into IString class 302 in a language (specified by sourceLanguage field 314) for which bidirectional support is required, baseString field 304 will contain the entered bidi text string in its logical order, which is the normal method of storing such data. The sortString field 306 will be employed to store the entered bidi text string in reverse order. The altString field 308 will contain an English transliteration of the entered bidi text.

[0049] When a display request for the data stored within IString class 302 is received, the IString class 302 checks the value of bidiLocale field 330. If bidiLocale field 330 is set to “true”, the contents of baseString 304 are returned in response to the display request. However, if bidiLocale field 330 is set to “false”, the contents of sortString 306 are instead returned in response to the display request.

[0050] Because both the normal logical order and the reverse order of an entered bidi text string is encapsulated within IString class 302, the entered bidi text string will be properly displayed regardless of whether bidirectional text display is enabled or not. If bidirectional text display is supported, the normal logical order of a right-to-left text string is presented from baseString 304 to the display control. The text control should then display the string from right-to-left. If bidirectional text display is not supported, however, the reverse ordered text string is presented from altString 306 to the display control, which should display the reverse-ordered string from left-to-right, thus effectively displaying the text string from right-to-left.

[0051] An example of employing the IString class 302 in the manner described above is set forth below:

[0052] //

[0053] // Hebrew calendar

[0054] //

[0055] // The following is IString data using the IString constructor

[0056] // The fields are laid out and used as follows:

[0057] // baseString—correct Hebrew; sortString—reversed Hebrew;

[0058] // altString—English transliteration

[0059] //

[0060] new IString(“\u05 ea\u05e9\u05e8\u05d9”, “\u05d9\u05e8\u05e9\u05ea”, “Tishrei”, new Locale (“iw”, “IW”), new Locale (“en”, “US”)),

[0061] new IString(“\u05d7\u05e9\u05d5\u05df”, “\u05df\u05d5\u05e9\u05d7”, “Heshvan”, new Locale (“iw”, “IW”), new Locale (“en”, “US”)),

[0062] new IString(“\u05db\u05e1\u05dc\u05d5”, “\u05d5\u05dc\u05e1\u05db”, . . . “Kislev”, new Locale (“iw”, “IW”), new Locale (“en”, “US”)),

[0063] Only three month names are addressed in the above example, but the remaining Hebrew month names may be similarly addressed. In the first two fields (baseString and sortString) of each IString month name, Unicode Hebrew characters are specified. Thus, for example, the first IString month name would contain “” in the basestring field and “” in the sortString field. The altString field contains the English transliteration of the baseString field contents, or the month name in English.

[0064] Display code for passing the correct field of an IString month name to a display showing a calendar might be:

[0065] The value of “isMonth” may then be passed to the display control requesting the month name. If bidirectional text display is supported, the value passed will be the contents of basestring 304; otherwise the value passed will be the contents of sortString 306.

[0066] The use of sortString 306 to store a reverse order version of a bidirectional text string in the present invention need not interfere with the use of sortString 306 for other functions. The functionality of storing a reverse-order text string in sortString 306 may be limited to languages requiring bidirectional text support. Sort algorithms depending on sortString 306 may check the sourceLanguage 314 and reverse the contents of sortString 306 if the language identified requires bidirectional support.

[0067] Referring to FIG. 4, a high level flowchart for a process of employing a multi-field text string class to support display of bidirectional text on both bidirectional and non-bidirectional systems in accordance with a preferred embodiment of the present invention is illustrated. The process begins at step 402, which illustrates a display request being received for bidirectional text encapsulated in a multi-field text string (IString) object.

[0068] The process passes next to step 404, which illustrates checking the value of the bidiLocale property for the subject IString object, and then to step 406, which depicts a determination of whether the IString bidiLocale property is “true”. If so, the process proceeds to step 408, which illustrates setting the baseString field of the subject IString object as the default display field for the subject IString object. The display control making the display request, which supports bidirectional text, will therefore receive the normal logical ordered contents in the baseString field and should then display the retrieved contents in a right-to-left fashion, which is the proper directionality.

[0069] Referring back to step 406, if the IString bidiLocale property is not “true”, the process proceeds instead to step 410, which illustrates setting the sortString field of the subject IString object as the default display field. The display control making the display request, which in this case does not support bidirectional text display, will receive the reverse ordered contents of the sortString field which it should then display in a left-to-right fashion. Since the ordering is reversed, however, the display control will effectively display the text string in right-to-left fashion, which is the proper directionality.

[0070] From either of steps 408 or 410, the process passes next to step 412, which illustrates the process becoming idle until another display request is received for a bidirectional text string encapsulated in a IString class object in accordance with the present invention.

[0071] It should be noted that the exemplary embodiment employs the operating system or application support for bidirectional text display as the criteria for determining which field to set as the default display field. Typically a display control within an application or operating system which supports bidirectional display will also support bidirectional display. However, should a display control which is within an application or operating system which supports bidirectional display NOT support bidirectional display, the criteria for selecting the default display field may be based accordingly. Thus, both the operating system and the display control may be examined to determine if support for bidirectional text display is available.

[0072] The present invention allows bidirectional text to be displayed on a system which does not support bidirectional text display, using only the left-to-right only directional display controls which should be available on any system. Additionally, the present invention allows bidirectional text strings to migrate from system to system, with the text string being displayed properly on all systems regardless of whether bidirectional text display is supported.

[0073] It is important to note that while the present invention has been described in the context of a fully functional device, those skilled in the art will appreciate that the mechanism of the present invention and/or aspects thereof are capable of being distributed in the form of a computer usable medium of instructions in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of computer usable media include: nonvolatile, hard-coded type media such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), recordable type media such as floppy disks, hard disk drives and CD-ROMs, and transmission type media such as digital and analog communication links.

[0074] While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.