Method of operating a computer system to provide customed I/O information including language translation4870610Abstract A method of operating a computer system to effect user-customization, primarily foreign language translation, of standard system-supplied screen displays without the need to modify underlying system source code. A transltion environment includes an autonomous processor (250) interposed between a host system (100) and access devices (201,202). Information transmitted between the host and access device is diverted to the processor for intermediate processing. One phase of this processing generates a translation file (500) which stores a mapping relationship between a first language screen and its second language counterpart. This translation file is invoked during the secod processing phase to effect a translation from the first-to-second language upon a host response and from the second-to-first language upon a host request. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
DISPLAY 1
* GOC LOGON/OFF *
ENTER RRO: ------
ENTER PASSWORD: --------------
PF KEY ASSIGNMENT
1 : FIND
DISPLAY LOGON STATUS
4 : ADD
LOGON
8 : REFRESH
REFRESH SCREEN
10: DELETE
LOGOFF
______________________________________
The user supplied fields have the following meanings: RRO--Responsible Reporting Office (i.e., user identification) PASSWORD--valid password to enable the user to access host system 100. The information with the heading "PF KEY ASSIGNMENT" (PF means Program Function) lists the allowed response keys which then initiate one of the following actions: FIND--Displays requested RRO ADD--Log-on to host system REFRESH--Clear all fields on the screen DELETE--Log-off host system It is supposed that the user responds first by entering data in the two fields, namely, RRO is filled in with, for example, the three character string "DFB" and PASSWORD contains the six character string "PASSWD", and then the user strikes the "PF4" key. In general, screen display 202 may contain up to 1920 character positions as determined by 24 lines per screen at 80 characters per line. VDT 200 recasts the characters as well as the character position information into a form suitable for transmission over channel 210. The striking of the "PF4" key by the user signifies that the user has completed the screen entries and that the character information is to be converted within VDT 200 and then transmitted over channel 210 to host 700. If the information supplied by the user at "log-on" is complete and accurate so that it is acceptable to host 100, the next response returned by host 100 to VDT 200 is shown in excerpted form in DISPLAY 2, which is essentially DISPLAY 1 above augmented with the additional line (line 24 of the screen display):
______________________________________
DISPLAY 2
* GOC LOGON/OFF *
ENTER RRO: ------
ENTER PASSWORD: --------------
PF KEY ASSIGNMENT
1: FIND
DISPLAY LOGON STATUS
.
.
GC10101I LOGON SUCCESSFULLY COMPLETED
______________________________________
After successful log-on, the user is now prepared to select the next work activity. It is important, however, at this juncture to reiterate some characteristics of the user utilization of host system 100. As depicted, accessing is interactive in that a user submits input information viewable on a screen, evaluates a response viewable on the same screen, then supplies another input, and so forth. The screen information must be presented in human readable format so the user may understand and interpret responses, and thereby plan and submit the subsequent work activity. Presuming log-on is successful, the user now moves to the next work iteration. For this step, a new blank format is called into view. By way of another example, the user types the new format name, now designated "gcocs1", and strikes the appropriate enter key. Host 100 responds with the requested format and it is displayed on screen 202; FIG. 2 depicts the exemplary version of the screen as provided by host 100. The unpopulated format screen of FIG. 2 comprises capitalized acronym fields each followed by a colon; for example, "OIY","CLO", . . . ,"CKT", . . . ,"REMARKS" and "CSTAT" are screen fields. These acronyms are referred to generically as Field Identifiers (FIDs). (The first FID, namely /FOR, is a special identifier which is filled-in and returned by the host to remind the user of the format under consideration.) Underscored locations following the FIDs comprise data fields for the user-supplied data. Not all data fields are filled in every instance and they may remain blank upon submission to host 100. When the unfilled screen is first received by VDT 200, certain data fields have a series of underbars to indicate where data may be entered and the total length of acceptable data. Data fields with these underbars are referred to as unprotected data fields, that is, fields for which it is expected that the user may supply input information. There is another type of data field, designated as a protected field, which the user cannot populate, but which displays output data from host 100. The two data fields in the upper right corner of FIG. 2, namely, the "date" and "time" data fields, are examples of protected data fields. It is not important at this juncture to define the meanings of the FID acronyms. Rather, the concept to understand is that for each type of format, whenever the format is requested, FIDs are displayed with indicators as to the position and length of anticipated data, and the user enters only the subset of data deemed appropriate by the user. After the user is satisfied with the data entries, the contents of screen 202 are transmitted to host 100 via an appropriate Program Function Key. In order to introduce other aspects of the present invention to be discussed in detail later, a filled, submitted and executed counterpart to FIG. 2 is shown in FIG. 3. In FIG. 3, certain data fields are shown as filled--by either the user upon input or by host 100 upon generating a response. The last line (so-called "line 24"), however, is a system generated response (the line containing ORDER AND ITEM(S) ADDED SUCCESSFULLY). Oftentimes messages that appear on the bottom line must be constructed by the application executing on host 100. Messages are not simply placed in a look-up table, but must be pieced together dynamically. Thus, the translation of the English version of a message to a foreign language is not a straight-forward procedure. Since messages are constructed from individual words or phrases, a simple translation of each word or phrase as it appears and then concatenating the translated words and phrases leads to a confusing, if not erroneous, message in the foreign language. Although messages may not be directly translated and therefore require special handling because of this non-table look-up environment, it is generally possible to directly translate FIDs. However, translated FIDs may still pose a problem because foreign word or phrase lengths generally differ from their English version counterparts. Moreover, linguistic interpretation may have more meaning if the translated FIDs are positioned at different screen locations. Finally, it may be necessary to process different units of data (e.g., meters versus feet) and different order of data (e.g., month-day-year versus day-month-year) in translating between the English and the foreign language counterpart. If all word/phrase translations, FID location changes and data conversions are effected in a manner that is transparent to host 100, then no modification to the underlying source code of host 100 is required. Associated with each FID and with each data field of either the protected or unprotected type is a so-called attribute. The attribute parameter is a standard feature of the Model 3279 data stream in communicating between host 100 and VDT 200. Each attribute, although not actually displayed on screen 202, summarizes display information about its corresponding FID or data field, including such information as the color of the display characters at the FID or data field locations and whether or not to highlight the associated characters. As an indication of the association of attributes with FIDs and data fields, a portion of the second line from FIG. 3 is shown below with the location of each attribute in the line shown with an exclamation symbol: !CLO:!TPS!200831!ORD:!TPS200831! . . . In this representation, the exclamation symbol before each FID or data field identifies the storage location (one of the possible 1920 screen locations) for its associated attribute. Moreover, attributes grouped as pairs are considered as marking or encompassing FID and data field locations. For instance, the attribute for the data field having "TPS" as data and the attribute for the data field having "200831" as data encompasses the "TPS" data field (!TPS!). Thus, pairs of consecutive attributes act as spacers, so a search over a screen display to locate a FID or data field may be effected by identifying the locations of consecutive attributes. This capability will be utilized later by one aspect of the present invention. 2. Illustrative Embodiment of the Present Invention In FIG. 1, the user is viewed as communicating with host 100 in an interactive mode via VDT 200 which, in turn, maintains an on-line connection to host 100 over channel 210. Now, with reference to FIG. 4, the user is viewed as still operating VDT 200, but translation processor 250 is now interposed between host 100 and VDT 200. Translation processor 250 is linked to VDT 200 via channel 211 and is linked to host 100 via channel 310. Channels 211 and 310 operate in basically the same manner as channel 210. FIG. 4 represents the most general configuration according to the present invention in that processor 250 is shown as a stand-alone processing element. However, in the illustrative embodiment to be discussed, processor 250 is actually implemented by the on-board personal computer portion of an IBM 3270 PC Terminal. This particular terminal also comprises a screen display and a keyboard that function as screen 202 and keyboard 201, respectively. Accordingly, as depicted in FIG. 5, VDT 300 is shown as an integrated unit comprising previously described elements 201 and 202 as well as local computer 250. VDT 300 is linked to host 100 via channel 310, which is again an IBM 3274-type Controller for this illustrative embodiment. In the processing environment engendered by processor 250, digital data propagating between host 100 and screen display 202 over channel 310 is, in effect, intercepted and diverted to processor 250 for intermediate processing. Once processed by processor 250, the new data corresponding to the intercepted data is redirected to the element (either host 100 or screen 202) that was originally to receive the data. For the illustrative embodiment, the intermediate processing is subdivided into two major processes executed serially. The first process allows the user to customize the screen formats; possible customizations include FID translations/modifications, data field movements/deletions and data field conversions. The results of the first process produce a file containing the information needed to translate from the original screen to the customized screen and vice versa during the actual translation execution processing, the second major processing stage, which will be discussed shortly. Format Create Processing To provide visual insight into this first process, reference is first made to FIG. 6. In FIG. 6, a complete, standard version of the "gclogo" format image is shown (recall only an excerpted version was shown in DISPLAY 1) as this format appears on screen display 202 when requested by a user. (For consistency of terminology, the "format" is what is defined by source code and the "image" is the actual appearance of the "format" on the screen display.) Screen rows are labeled 1-24 whereas screen columns are labeled 1-80. Associated with rows 1-24 are the corresponding character data locations. For instance, row 1 contains locations 1-80, row 2 has locations 81-160, . . . , and row 24 has locations 1841-1920. Locations shown with underbars represent unprotected data fields that may be filled by the user. For instance, locations 252-254 are reserved for RRO data. Also, as an example of a protected data field, locations 46-51 are used to display the current date in the protected date data field. The screen of FIG. 6 is an unfilled original screen image displayed as a result of the standard format request-response procedure occurring between host 100 and VDT 300, as described in the previous subsection for host 100 and VDT 200. Once displayed, the user may begin the process of translating from the original screen image to the so-called translated screen image. FIG. 7 provides a pictorial representation of the screen images invoked by the first process, which is the so-called format create process as implemented by format create controller 400 of FIG. 7. As suggested by FIG. 7, there are two related screen images that are accessible during the format create process, namely, original image 202-1 and auxiliary image 202-2. Either may be called alternately into view on screen display 202. As suggested by FIG. 7, exemplary screen images 202-1 and 202-2 have more detailed counterparts as shown in FIGS. 6 and 8, respectively. With reference to FIG. 8, a complete screen image counterpart to the original screen image of FIG. 6 is depicted. This image is designated as the auxiliary screen image and it is the initial working screen presented to the user so the user may begin the activity of screen image translation to arrive at the final or translated screen image; thus, the auxiliary image is transitory or ephemeral in nature. The image of FIG. 8 results from invoking create controller 400 to process the screen contents of FIG. 6. In FIG. 8, all unprotected data fields are highlighted by "slash" shading (e.g., the fields following "RRO" and "PASSWORD"). Highlighted fields indicate those data fields that are to be automatically mapped from the original image to the translated image during the translation process (discussed shortly). The user can, however, highlight normally protected fields such as the field following the "DATE" FID (shown with "backslash" shading in FIG. 8). Protected but highlighted fields will also be mapped upon phase two or translation processing. FIDs may be changed from their English spelling to any other desired combination of characters. FIDs in a foreign language will generally be longer than their equivalent English FIDs. This requires that create controller 400 have the capability to move FIDs, under user control, to other screen locations. For example, controller 400 is generally arranged with a screen editor that allows the user to "mark" a FID to be moved, position the screen cursor to a desired new location and then depress the required "move" key to relocate the FID. Similarly, data fields may be marked and moved. Create controller 400 keeps track of both data fields and FIDs in the original image as well as their locations on the auxiliary image, which when finalized by the user, becomes the translated image. Unprotected and protected data fields as well as FIDs may be blanked out during translation processing. Again, the screen editor of create controller 400 is implemented with an appropriate blanking key. Each highlighted field may be converted (e.g., yards to meters) during translation execution mapping. Such a field may be converted during original-to-translation or translation-to-original processing during the translation execution phase. The screen editor of create controller 400 is again utilized to define the desired conversion formula. One particularly important data field requiring a special conversion procedure is the message line or line 24 shown highlighted in FIG. 8. As alluded to earlier, concatenated versions of translated English words and phrases may not produce correct foreign versions. To handle this situation, a message field database is constructed for all the potential messages and a message field converter processes this database by keying on a set of predefined positions in the English messages. The database takes into account multiple messages having similar keys as well as messages having data fields. To summarize aspects of the above discussion, reference is made to FIG. 9. FIG. 9 represents the translated, Spanish version counterpart to the original image of FIG. 6 after the auxiliary image of FIG. 8 has been translated by the user. In row 1 of FIG. 9, at locations 40-45, the word "FECHA" has replaced the FID "DATE" shown in locations 41-45 of FIG. 8. As is also witnessed in comparing FIGS. 8 and 9, FIDs have been adjusted in size to accommodate the foreign language translations, but no FID has been moved in this simple example. As indicated earlier, an information file, corresponding to translated image file 500 of FIG. 7, tabulates the changes between the original image and translated image. File 500 for this exemplary format may be stored, for instance, on a hard disk file designated "gclogo.term". Translated image file 500 corresponding to the translation from the display of FIG. 6 to the display of FIG. 9 is shown below in DISPLAY 3.
__________________________________________________________________________
DISPLAY 3
NUMBER OF FIDs: 9
1 /FOR:
20 * GOC LOGON/OFF *
40 FECHA:
241
ENTRAR RRO:
481
ENTRAR PALABRA DE PASO:
561
(SI ES REQUERIDO)
801
EXTRAR CORRESPONDENCIA ?:
1041
ASIGNACION DE LAS TECLAS PF
1281
1:
CONSULTAR
MUESTRA EL ESTADO DEL LOGON
4:
ANADIR
LOGON
8:
REPONER
REPONER LA PANTALLA
10:
ANULAR
LOGOFF
NUMBER OF DATA FIELDS: 6
7 7 8
47 47 6 0AEDATE
252
253
3
497
505
8
815
828
1
1840
1840
80 OGOCERR
__________________________________________________________________________
In DISPLAY 3, basically two sets of data are shown, namely, the set associated with the "NUMBER OF FIDs" and the set associated with the "NUMBER OF DATA FIELDS". As indicated, there are nine FIDs being tracked. For each such FID, there is an indication as to its starting location and then the actual FID is defined. For example, FID "FECHA" starts at character location 40, as noted earlier. (Not shown in DISPLAY 3 are the attributes associated with the FIDs. Their location in file 500 is discussed shortly.) With respect to the data field set, there are six data fields being tracked. For each such data field, there is an indication as to the starting location in the original screen image, the starting location in the translated screen image, the field length and whether a conversion process applies in going from original-to-translated or vice versa. For example, the data field starting at location 47 is to undergo a conversion from original-to-translated (0 before "AEDATE") designated by the routine "AEDATE". This routine converts dates from month/day/year to day/month/year. Also, the data field at location 1840 (the message line) is to be converted using the "GOCERR" database, as suggested earlier. As a second example, the "gcocs1" format image considered in the discussion relating to FIGS. 2 and 3 is now translated via the format create controller process. FIG. 10 depicts the translated image corresponding to the original image of FIG. 2. The display of FIG. 10 is the screen presented to the foreign language user for fill-in. FIG. 11 shows a filled-in version of FIG. 10 just prior to the striking of the "enter" key by the foreign language user. It is noted that the foreign language user inputs data in a form that is understandable in either English or the foreign language, that is, the lower case notation is the same for both versions. FIG. 12 depicts the display on VDT 300 after host 100 has processed the contents of the display of FIG. 11. Certain data fields not populated upon the request are now populated upon the response: in particular, line 24 now contains an appropriate message. FIG. 12 is the Spanish language counterpart to FIG. 3. DISPLAY 4 below shows an excerpted version of the contents of translation file 500 for the translated "gcocs1" format.
______________________________________
DISPLAY 4
NUMBER OF FIDs: 93
1 /FOR
17 * TIRKS CONTROL DE ORDEN (ESPECIALES) *
57 OIY:
80 CLO:
.
.
320 TIPO ORD:
.
.
.
1440 OBSERVACIONES:
.
.
.
1673 ESTA-L
NUMBER OF DATA FIELDS: 113
7 7 8
62 62 8
65 65 1 0AEDATE
.
.
.
405 410 6 0AEDATE 1AEDATE
421 427 6 0AEDATE 1AEDATE
.
.
.
1517 1436 2
.
.
.
1840 1840 80 0GOCERR
______________________________________
The process flow of format create controller 400 is shown in greater detail by the block diagram of FIG. 13. When host 100 transmits the requested screen image, processor 250 captures the data stream from channel 310 and stores the stream in original screen image buffer 260. Processor 250 is configured upon initialization with at least two windows or views, namely, views A and B in FIG. 13, which may be called alternately into view on screen 202. As depicted, the B view displays the contents of buffer 260 whenever invoked by the appropriate keyboard entry. After buffer 260 is filled, process 400 is started, as depicted by block 401. The first activity, shown by block 410, is that of generating a replicated version of original screen image buffer 260 and placing the replicated version in a work buffer (not shown) in processor 250. The generation of the replicated version is aided by the High Level Language Application Program Interface (HLLAPI) software system supplied as a standard product release by IBM. This software effects the transfer of memory contents associated with the terminal mode portion of VDT 300 to the personal computer mode portion of VDT 300. The process represented by block 420 is then automatically invoked to read attribute information from the work buffer to, for example, highlight unprotected data fields and select appropriate colors for display of the FIDs and the data fields. The modified work buffer is then stored in translated screen image buffer 270; recall the initial contents of buffer 270 contain the auxiliary image. The contents of buffer 270 are automatically displayed to the user, as view A, on screen 202. Process 400 then awaits keyboard input from the user, as suggested by block 430. FID modifications, data field conversion, and so forth are invoked through appropriate function keys; five exemplary keys are shown by blocks 432-436 in FIG. 13. Block 432 depicts the set of command level activities that may be invoked to operate on the work buffer. The SAVE command is ultimately the command used to write the contents of buffer 270 to translation file 500. Block 433 associates a converter routine with a data field (e.g., AEDATE with the DATE data field.) Block 434 invokes a process to highlight protected data fields. The process of block 435 provides the editor-like functions to mark and move FIDs and data fields. Finally, block 436 is invoked to suppress mapping of data fields from the original to the translated image. The processing associate with block 431, the so-called "JUMP" key, is used to select which view (A or B) is desired by the user. Process 400 is terminated by invoking the window of block 432 and either saving buffer 270 in translation file 500 or exiting to initiate any new work activity. Translation Execution Processing As alluded to above, there is a second phase to the intermediate processing, namely, the translation execution process. This process performs the actual execution time translation and display of the request-response screens to the foreign language user. In typical fashion, host 100 transmits a screen display to VDT 300 and this transmission is intercepted by translation execution process controller 600, as depicted generally in FIG. 14. Process controller 600 determines initially the screen format being transmitted from host 100 over channel 310, which is now depicted in FIG. 14 as having two unidirectional paths corresponding to host-to-terminal transmissions and terminal-to-host transmissions, respectively. After determining the format, the translation file from file 500 corresponding to the previously translated format is read into controller 600 and translations commence. The foreign language FIDs for the format are translated to the foreign language and, upon completion of the translations, the translated image corresponding to the format is displayed on screen 202. The foreign language user may then fill the display with desired data. A filled-in screen was depicted in FIG. 11 for the "gcocs1" format. The foreign language user then indicates to controller 600 that the filled-in screen is to be transmitted by striking the appropriate "ready" key. The translated image, now with non-blank data fields, is again intercepted by controller 600. The entered data, if required, is converted within controller 600 and then entered into the proper locations on the English screen image. Once completed, the English screen image, along with the "ready" keystroke, is forwarded to host 100. Thus, controller 600 renders all foreign user terminal entries transparent to host 100. The flow of translation execution process 600 is shown with detailed specificity by the block diagram of FIG. 15. The operation triggering process 600 is the transmission of an English screen to VDT 300 from host 100 via channel 310. The initial activity, as effected by the processing of block 610, is the determination of the English screen format name (e.g., "gclogo" or "gcocs1") returned by host 100. Once determined, the portion of translation file 500 corresponding to the format name is read into memory by the process represented by block 620. As the translation file for this particular format is read-in, a skeleton screen image buffer comprising only FIDs is constructed, as represented by block 630. In FIG. 15, an expanded view of the translation file for a general format is shown to the right of file 500. As suggested above by DISPLAYS 3 and 4, there are basically two sets of data corresponding, respectively, to FID and DATA FIELD information. The FID information, besides containing the screen location and the FID itself, is now shown to contain the ATTRIBUTE parameter for each FID. From the attribute, screen location color requirements and highlighting, if any, are obtained. Whereas translation file 500 contains the ATTRIBUTE parameters for FIDs, the ATTRIBUTE parameters for DATA FIELD information are obtained directly from the format image received initially from the host. Data field attributes have a flag position to tabulate only those data fields that have data modified by the user once the translated screen image is presented to the user. Because of this flag, processing speed is increased since only changed data fields are returned for processing. Thus, as depicted by "loop" block 640, the first activity in the loop operation is to move the attribute of the data field to the skeleton screen buffer, as shown by block 641. The data field of the FID undergoing processing by the loop, called the "mapped" field in block 640, is then read from the intercepted English image by the process of block 643. If there is a conversion process in going from the original-to-translation (0--T) as determined by decision block 645, then the particular conversion routine listed in the DATA FIELD information for this particular FID is invoked by the process of block 647. The particular data either generated or passed directly, depending upon the test condition resulting from processing by block 645, is placed in the data buffer of the skeleton screen image; this operation is depicted by block 649. Upon completion of processing for all "mapped" FIDs, the translated screen image stored in the buffer is displayed to the user on VDT 300, as per block 650. This display is the only one actually viewed by the foreign language user. The English image version of the screen, depicted in FIG. 15 as also being received by VDT 300, remains in the background and is transparent to the foreign language user. Process 600 is now placed in a wait mode awaiting user data field input and activation via a "ready" key; the wait mode state is depicted by block 660. When the "ready" key is depressed, VDT 300 sends the present contents of the foreign language screen image for processing, as represented by block 670. Again, block 670 depicts the initial processor in a loop having blocks 671, 673, 675 and 677 as remaining processing blocks. These latter four blocks represent the translation-to-original counterparts to blocks 643, 645, 647 and 649 described above in the original-to-translation direction. Because of the attribute flag, however, only modified data fields are processed. After all modified fields have been processed, the revised English screen version and the "ready" key are sent to host 100 via VDT 300; this is depicted by processing block 680. This description of the processing represented by FIG. 15 forms one complete cycle of translation execution. The process repeats for successive screen images transmitted by host 100. From the foregoing, it is evident that each foreign language interface (e.g., Spanish, German, French and so forth) to the host system resides in the translation file, which is a user-specified composite of individual translated screen images. Then, utilization of the host system by a non-English user merely involves the loading of the corresponding version of file 500 and invoking of translation execution. It is to be understood that the above-described embodiment is simply illustrative of the application of the principles in accordance with the present invention. Other embodiments may be readily devised by those skilled in the art which may embody the principles in spirit and scope.
|
Same subclass Same class Consider this |
||||||||||