DE4325096C2 - A data processing system that enables a user dialog in several natural languages - Google Patents

Description

The invention relates to a method for providing a User dialog via a text interface in several na natural languages in a computer system with a Zen central computer with a variety of user stations is connected via communication links with a Processor for executing a plurality of application pro gram by a large number of users at the same time be used and a memory that with the Processor is connected to at least one message file to save, with a message file text information a natural language for one of the application programs includes, with different text information for un Different application programs are provided.

Most data processing and computer systems possible user dialog only in a natural way Language, such as English, French or German. Such natural languages are those that make people speak use and differ from computer or program foreign languages. Due to international development, in  the increasing use of computers is a need on data processing systems that came with the user zer in one of several natural languages, the "dialog Languages ".

In most data processing systems, the Dialogue with a user sending and receiving messages aim between the user and the data processing system stem. To send and receive such messages a data processing system normally has to perform Standard commands to send output messages for loading users and also standard commands for translating the data from the Be user received messages. An application programmer uses these commands in an application program by one Dialogue between a user and the data processing system enable stem when the program is running, d. H. if that System is configured by the program and by the Program described procedure by the configured Sy stem are executed.

A known technique for sending and receiving messages ten includes data from output and input messages for an application program in a file or on one of the To application program separate point. Such news who ver by the application program with codes or indexes see. This technique is known as "externalization". Ge the application programs occasionally receive messages, d. H. if they are not for sale, for example for Use as standard messages. Sometimes these Messages also referred to as "hard-coded".

If an application program and corresponding, ver external message files used in a system then a connection between between the application program and the message file  create. This connection specifies that the message Use the file in conjunction with the application program that's about output and input messages for the program to provide. In current systems either the user or the application programmer sends the message trend file used with the application program should explicitly specify. So the connection is for not visible to the programmer and both the user programmer as well as the user must use the names of know the available message files. In a system which If several dialog languages are supported, several will be Message files needed so that on the program load and the load on the user is increased.

A current multilingual system based on one "Externalization" is the Native Language System (NLS). NLS is a system interface developed by X / OPEN Job. X / OPEN is a community initiative by members of the economic community for developed standards in a common, advantageous and continuing strate to integrate. The system interface is a group of commands for use in application programs are available to configure a data processing system and manipulate. There are many confusions to support the NLS interface, but all Realizations are based on that of X / OPEN in their porta bility guide, 1989, (see especially volume 2) Functionality.

In the NLS, every salable message file is a user program, the output and input messages in egg contains a dialog language, identified by an as "Catalog descriptor" well-known concatenated name. With the NLS requires an application programmer to use the catalog descriptor know for a message file to this message file  into memory and to retrieve messages from it fen. The catalog descriptor can consist of a standard word, such as a system-wide standard or a per-user standard be educated. The user default word overwrites in the NLS the system standard and can also be used for the standard overwrite dard for an application program. A fa The ability to nest is not created. When a Message file in a desired language for a user program is not available, then the user receives normally hard-coded messages from the application pro grammes. Because the application programmer got the name of the Message file used in the application program and because he's also opening and closing message files carries out problems in the development of users programs.

A first problem with the NLS system is the expl the involvement of the application programmer in the Handling of message files. Message files for an application program are regularly modified or new message files are used by the To application program added. Such modifications and Additions can make changes in application programs that the modified or added message files meet, make necessary. It follows that if such message files are available to a customer that the application program is also updated must be so that both the manufacturing cost of the user program as well as the material costs of the customer gene.

A second difficulty of the NLS system is that it has one Application programmer requires to have a program on hand to develop purposes in the event that a night Straighten file while trying to open a file  or retrieve a message from a file, not found that will. Such a program typically provides one standard hard-coded message ready to use when a message or message file not found becomes. However, such standard messages are only provided to the application programmer. So An application programs through various application programs were manufactured, possibly not uniform Chen standard mechanism. Therefore, such correspond Application programs do not meet the relevant requirements.

After all, these systems are partly due to the man because of transparency and reliability, not in the Location of the "nesting" ability of a system Ge need to do. That is, if one application program is another res application program (i.e. it makes a "ver nested "call), then the information about the Dialog language not "nested". So is a user unable different languages for different To specify program levels.

Application dictionaries are usually used in large numbers specialist user systems used and contain common Un ter programs to which a variety of application programs access. Access to these application dictionaries be often contains a kind of nested call. Without that Creating multilingual support for chess Subsequent application programs or dictionaries can be used Directional handling for application dictionaries is unreliable or even be unpredictable.

The invention is therefore based on the object of a method to create a message file with a user application program or with a library without an operator ner dialogue connects.  

The object of the invention is characterized by a method characterized by the following steps:
Providing a connection table with a plurality of connections between the application programs and message files, a connection storing values related to an application program, a natural language and a storage location for a message file associated with the application program and the natural language in the memory, Clues;
Selecting a natural language through the application program;
Accessing the connection table to select the space allocated to the application program message file in the selected natural language;
Retrieving the text information from the message file; and
Output of the relevant text information to the user.

This is a method of operating data processing system has been created, which application programs and which the dialogue with a Be users in multiple natural languages. A Be Users can use a program in one language and with an egg communicate with another program in another language. Other users can still work with the same program different languages. Any application program has at least one corresponding message file containing messages in a natural language. The data processing system stores application programs and corresponding message files and maintains the ver  steps of the stored application programs out. An application program can be messages from one ner corresponding message files in one out chose to retrieve natural language. To get the message off call, the data processing system stores connections in a connection table in which each connection egg nes application program or a dictionary the location of the Corresponding message file that the Messages in the for the application program or the word contains given natural language. For an arrival Application program or a dictionary can in the data work system side by side several natural languages, preferably by the operating system, who is available the. A connection in the connection table is preferred wise through the process of loading a message file nes application program created in the memory. The Ver Loyalty table is scanned to the message file for find out and select a natural language the desired message is then closed by the Connection displayed message file found. The out chosen, natural language is at least from the moment used dialog language of a given application program mes and a standard language selected. Save the system preferably saves both the current dialog language and also the standard language. Usually the standard Language initializes when a user starts the data processing system to use. The current dialog language is determined when an application program is activated.

A dialog language is used when retrieving messages selected from at least one current dialog language and the standard dialog language. Then a message will appear below Called using the selected dialog language.

Once the data processing system has been instructed,  executing an application program, the current slide Log language in one of the application program and the user initialized obviously. The current dialogue language che is usually set as the default language; however a desired dialog language can be determined if the Program is called. As soon as a dialog language is determined is the current dialog language as the desired one Dialog language set, if it is available.

The system also preferably stores nested ones Language information for use in connection with ver nested application programs or layered procedures steps. If an application program is another type application program or a dictionary, then the current dialog language as the nested language information mation saved. This nested speech information is preferably a stack register or a connected Li ste. Then the current dialog language is at least egg set one of the following languages: a displayed, ge desired dialogue language, the previous current dialogue language or a standard language. If a nested Application program is finished, the previous to application program saved again and for the previous Application program becomes the current dialog language reset to the previous dialog language. The before outgoing dialog language and the nested language information mation for the saved application program then the means for storing nested speech information can be retrieved.

By using standard languages Application dictionaries with multilingual input and output skills. Subroutine calls to applications dictionaries can be nested in a similar way Application programs are treated.  

Processed in the preferred embodiment of the invention the operating system multilingual dialogs. An application pro grams instructs the operating system, a message file to load and retrieve messages from it.

An embodiment of the invention is in the figures shown.

Show it:

Figure 1 shows a block diagram of a data processing system suitable for carrying out the invention;

FIG. 2 shows a three-dimensional view of a typical user station of the data processing system according to FIG. 1;

FIG. 3 shows a block diagram of the structure of the central computer according to FIG. 1;

Fig. 4 shows a schematic representation of the division of the memory according to Fig. 3 into private and common sections;

Fig. 5 shows a diagram of a data structure of a connection table for storing connections between output message files and application programs and dictionaries;

Fig. 6 is a diagram of a data structure of a system-in formations table for storing Informa tion shows capacities of the current status of the Dialogkapa;

Fig. 7 is a diagram of a data structure of a voice system table shows for storing voice names and corresponding language code;

Fig. 8 is a diagram of a data structure of a system enable table for storing INFORMATIO on releasing the dialogue shows capacities;

Fig. 9 shows a diagram of a data structure for storing the language code for the user standard language;

Fig. 10 shows a diagram of a data structure of a user-encrypted language stack for storing dialog language information for nested programs;

FIG. 11 is a diagram of a data structure of a user speech table shows for storing information about the use of a particular user dialog languages;

FIG. 12 is a user language correspondence table for storing dialog-language names and codes is a diagram showing a data structure of a user and corresponding Systemkodes;

FIG. 13 is a diagram of a data structure of a user information table for storing Informa tion about the current dialog capacity ei shows nes user;

Figure 14 shows a flow diagram describing how the data processing system of Figure 1 can be configured to be fully enabled to communicate in multiple languages;

FIG. 15 shows a flow diagram which describes how the data processing system according to FIG. 1 can be configured to communicate in a predetermined number of languages;

Figure 16 shows a flowchart describing how an operating system default language can be changed;

Fig. 17 shows a flowchart describing how a dialog language message file can be loaded for a common application program;

Fig. 18 shows a flowchart describing how a common application program can be loaded into the memory;

Fig. 19 shows a flow chart which describes how the data processing system may be configured and how it can be released private programs dialog in different languages for exclusively private application;

Fig. 20 shows a flow chart which describes how multi-language dialogues to a user via ei ne first use of the data processing system can be initialized;

Figure 21 shows a flow diagram describing how the user default language can be changed;

Figure 22 shows a flowchart describing how an application program can be called for multilingual use;

. FIG. 23A to 23B are flow charts showing the steps of the invention on a message file and the charge of the message file into the memory;

Fig. 24 shows a flowchart describing how an application program message file can be transferred to per-user memory;

Figure 25 shows a flow diagram describing how a user speech table can be expanded;

Fig. 26 is a flowchart showing the steps of finding a message for a standard task function;

Fig. 27 shows a flow diagram showing the steps for finding a message for a common application program;

Fig. 28 is a flowchart showing the steps of finding a message for a private application program;

Fig. 29 shows a flow diagram that describes how a user's input in a natural language by the data processing system can be stood ver;

Figure 30 shows a flow diagram describing how an application program or dictionary and its message files can be returned from memory or use;

Fig. 31 shows a flow chart describing how an application program level after the termination of a call can be nested chert abgespei again;

Fig. 32 shows a flow diagram describing how a list of existing dialog languages of an application program can be provided; and

Fig. 33 shows a flow diagram describing how a list of available dialog languages can be provided.

Figs. 1 to 4 illustrate the structure of a data-processing system 38 for carrying out the invention. The Since tenverarbeitungssystem 38 includes at least one central computer 40, which is connected to at least one user station 42 by a communications link 44, such as a cable or a communication bus welchselseitig is. In addition, the central computer 40 and the user stations 42 can be mutually connected to the system in a similar manner. Fig. 1 shows K with the central computer connected user stations 42. Each user station is identified with index n, where n = 1 ... K can be. Each user station 42 allows a user to reciprocally communicate with the central computer 40 ; so that multiple user stations 42 allow more than one user to use the system simultaneously. Likewise, more than one user can use a user station. User station 42 ( FIG. 2) may include a keyboard 46 , monitor 48, and other devices that enable the user to receive and transmit messages in a natural language.

As shown in FIG. 3, the host computer 40 may include a data processing unit 50 , a memory 52 , namely a random access memory, and a long-term memory 53 , namely a disk storage mechanism. The data processing unit 50 has a read and write access to both the memory 52 and the long-term memory 53 . The memory 52 can receive a copy of an application program for its execution by the data processing unit 50 . Memory 52 may also hold a message file for the application program. The data processing unit 50 is connected via communication connections 44 to the respective user stations 42 .

The memory 52 , as shown schematically in FIG. 4, is preferably divided into logical sections such that a user has both exclusive read and write access to a private section (private memory) 54 of the memory and read access to a shared section (shared memory). 56 , which the user shares with other users. The shared storage 56 houses application programs and message files that can be used by multiple users. The private memory 54 can hold private application programs and message files. Figure 4 shows three private storage sections (labeled user / ₁ , user / ₂ and user / _K ) and the shared storage (labeled "all users").

User / ₁ can read and write access corresponding only to the user with Be / ₁ private memory 54 and Lesezu handle to the shared memory 56 have. In the same way, user / _{K can have} read and write access only to the private memory 54 corresponding to user / _K and read access to the shared memory 56 . Write access to the shared memory is only created in special circumstances, namely for a system administrator.

A suitable data processing system 38 is the Prime 50 computer series marketed by Prime Computer of National, Massachusetts. for purposes of illustration, the following description focuses on implementation using this system. Such a Prime 50 data processing system can be configured using the programming language "SPL" (which is similar to the PL / I) to implement the data structures and the processes described below. The memory structure preferably has an annular architecture, but other standard memory structures may also be suitable. The above description in connection with FIGS. 1-4 is purely descriptive. Other shared and private storage multi-user computer systems are also suitable for practicing the invention. Based on this technical teaching, the average person skilled in the art knows how to change the data structures and flow diagrams described here in order to be able to use them on other architectures or other systems.

To multilingual dialogues with on one described above To be able to execute system-running application programs, an application program has to correspond to at least one the news section. A message file contains input and output messages for an application program in one natural language. Message files that contain messages in  different natural languages are available preferably stored separately. A message file should to be referred to as the name of a message file simply determined by the application program and the language can be. A suitable format is "<application name <. <Language <. msg ". The person skilled in the art also knows other suitable ones Formats. The format chosen often depends on the computer on which the system is implemented.

A suitable message file, namely "example. Eng lish. msg "contains two messages:

Max user exceeded "The system does not allow users zer at this moment ".

Unavailable "Your original directory may be missing tan cannot be reached ".

Such message files can be from a message Source file to be developed that the news for everyone Languages included. The source file can be compiled around to generate different message files. A source file helps the accuracy of translations of a message by ensuring that they share this in one File placed so that a user can be can try. Such a source file is in Table I shown.

If the message source file is compiled, then can a transfer of mnemonics (like "max-user-about steps ") in numbers are also carried out to save save space. The ver. In the message source file used language names and the names of the message files can and must be other characteristics of the language name  does not correspond to the correct name, for example English chen. These other labels can be abbreviation codes, like the ISO standard 639 or the country code.

TABLE I

LANGUAGES
0'English '
1'francais'
2'German '
max users exceeded
0'System not admitting users at this time '
1'Nombre maximum d'usagers depasse.
2'Maximum number of users is exceeded. '
unable to at or
0'Unable to attach to your initial directory. '
1'Incapable de vous relier a votre boite initiale. '
2'Your original directory cannot be reached '.

If an application program (or a dictionary) is loaded into memory, then a message file for the program must also be loaded into memory. In order to connect the application program, the message file and the user to one another so that the application program is able to retrieve messages from a message file, a connection must be established between the application program and its message file. For a user, a connection table 60 ( FIG. 5) stores connections for programs loaded by the user.

The connection table 60 is available in the private memory 54 for each user for private application programs. The shared memory 56 ( FIG. 3) also contains a connection table 60 for shared application programs.

An additional connection table 60 for the operating system, which differs from the connection table of the shared memory, can also be provided. For the sake of illustration, the following description of the operation of the system assumes that a separate connection table for the operating system is provided.

A connection 65 of a connection table 60 contains an identifier of the application program, the language for a message file and the storage location of the message file in the memory. A preferred form of connection includes a program field 62 , a voice field 68, and a pointer field 66 . A program field 62 identifies an application program which uses the name of the application program or alternatively the area of the memory location of its method code in the memory. A language field 68 identifies the natural languages in which the messages of the loaded message files are written. A speech field 68 can store the name of the language, a number or, alternatively, a mnemonic code and has a size that depends on the implementation. A pointer field 66 contains a pointer to the location in memory where the message file is loaded.

A connection is established in a connection table 60 when a message file for an application program is loaded in a shared memory 56 or private memory 54 . The language indicated by an established connection is "installed" for the application program. The installation of languages and other modes of operation of the system will be described in detail below.

Figs. 6-8 are diagrams of data structures, such as the data processing systemes occur in shared memory 56 38. These structures provide basic support for operating the system in the multilingual dialog for community applications. These structures include a system information table 70 ( FIG. 6), a system language table 76 ( FIG. 7) and a system release table 90 ( FIG. 8). The system information table 70 ( FIG. 6) contains information regarding the status of the multilingual dialog capacities. The system language table 76 ( Fig. 7) is used to match language names with language codes. The system release table 90 ( FIG. 8) provides information regarding the status of the release of the system.

The system information table 70 ( FIG. 6) will now be described in detail. The system information table 70 includes a field 72 that indicates the maximum number of languages that can be installed in the system. The system information table 70 also contains an installed language field 74 which indicates the number of natural languages currently installed on the system. Both field 72 and field 74 are one byte in size. The value of the installed speech field 74 is limited by the value of the maximum speech field 72 . A system language table 76 , as described below in connection with FIG. 7, may also be included in the system information table 70 .

The system information table 70 further contains a pointer field 78 , which is used to identify the location of the connection table 60 for the operating system in the memory 52 . In the system information table 70 , a pointer field 79 is also created in order to identify the locations of the connection table 60 for the shared memory ( FIG. 5) in the memory 52 ( FIG. 3). Although it is possible for both pointer fields 78 and 79 to be moved by the current connection table 60 to which they point, it is advantageous to separate the connection tables 60 from the system information table 70 for two reasons. This separation allows the connection table 60 to be assigned dynamically, while allowing the system information table 70 to be assigned statically. Because the system information table 70 has a fixed size, dynamic allocation is not required for this table. Due to the presence of various connection tables for the operating system and for community programs, access to the connection table 60 for the operating system is restricted by the system, so that greater security is created for the operating system.

The system language table 76 , shown in FIG. 7, has entries 80 which contain a language code 82 and a corresponding language name 84 . An example of a language name 84 is "English".

Speech code 82 is preferably a numeric code, but other codes such as mnemonic codes such as "ENG" or numbers can also be used. The size of the Sprachko des 82 is preferably one byte. Entries in the system language table 76 can be accessed either by the entry of the language code 82 or by the entry of the language name 84 . The field of the language name 84 is made up of 10 dynamically assigned characters.

The system language table 76 is allocated enough storage space to store the maximum number of entries 80 , which corresponds to the maximum specified number of language fields 74 . Thus, the system information table 70 has a fixed, predetermined size. Field 72 is set to a predetermined value, for example "16", during system initialization.

The system release table 90 ( FIG. 8) is created to indicate the status of the release of the dialog capacity of the system, as already described above. The status of the dialog can be either "private release" or "full release". The system is privately released when the system is able to communicate with a user through an application program loaded into private memory 54 or a dictionary in multiple natural languages. The system is fully released when the system is able to communicate with a user through shared and private application programs and through the operating system in multiple natural languages.

The content of the system release table 90 differs in the different release states, as shown in columns 91 and 93 in FIG. 8. Field 92 is used to indicate whether the system is at least privately released. That is, field 92 contains an incorrect value, for example 0, if the system is not released for private use. Field 92 can be implemented by a single bit that can be switched between a logic 0 and a logic 1. The use of this field 92 enables multilingual dialogues with private application programs (that is, the system can be privately released) without the dialog with the operating system and the collaborative applications (ie, when the system is not fully released). This capability is particularly valuable in areas where the operating system and / or collaborative applications are provided with only one (or no) dialog language message file, but where users have private application programs with multiple message files.

The system standard language field 94 has the size of one byte, and is therefore also present in the system release table 90 in order to display the natural standard language of the operating system for dialogue with a user. If a user uses a private or a shared application program for which the user standard language is not available, the system tries to use this standard language. Finally, a pointer field 96 is provided to indicate the memory location of the system information table 70 in the memory 52 .

The structures of FIGS. 6-8, which can be found in the common memory 56 ( FIG. 4), create a basic structure for multilingual dialogues with the operating system and common application programs. Such dialogues are preferably provided in a way that can be easily released and blocked. For this purpose, preferably only the system release table according to FIG. 8 is maintained as a permanent structure of the system. Therefore, other information and structures do not need to be assigned if a multilingual dialogue is not fully available.

Referring to FIGS. 9-13, the data structures assigned on a per-user basis will now be described in a preferred embodiment of the invention. The following data structures are kept ready for the user in private memory 54 , together with a connection table 60 for private memory: A user standard language field 100 (similar to system standard language field 94 ( FIG. 8)) ( Fig. 9), a user voice table 110 similar to system voice table 76 ( Figs. 11-12); a user information table 130 similar to the system information table 70 ( FIG. 13) and an interleaved speech stack register 102 ( FIG. 10) for storing interleaved speech information.

The user standard language field 100 ( FIG. 9) is used to store the preferred dialog language of a user and has a size of one byte. If the structure 100 is assigned to a user, then it uses the value of the system default language field 94 ( FIG. 8) unless explicitly changed by the user. By executing a command from the user station, the user is able to change this default language. This command should preferably be executed in the form of the name of the desired language, such as "French". The steps of this command will be described in detail later in connection with FIG. 21. If the system is approved for multilingual dialogue, field 100 displays a language by a language name, a language code or by some other type of identification (column 101 ). Otherwise it contains a non-spoken word, for example -1 (column 99 ). The field 100 for the user language is preferably stored in the memory 52 , which is not re-initialized when a user process is re-initialized. In a ring-shaped architecture, a ring can meet this requirement. For the system and community applications, this field 100 is analogous to the system standard language field 94 . It indicates a default language to use when no other language is specified or available for the operating system or application programs or dictionaries. If this language is not available, the system can use the default language.

An interleaved speech stack 102 ( FIG. 10) is also provided to a user. It can be used in conjunction with a standard application program nesting mechanism. This nested voice stack 102 is constructed like a stack or a structure similar to a linked list or field. An entry 104 in the interleaved speech stack register 102 includes a field 106 which indicates the language in which a previously run collaborative application program communicated with the user and a field 108 which indicates the language in which a previously run private application Application program communicated with the user. In an entry 104 , one of these fields indicates a language and the others store a non-language word. Each field is preferably one byte in size.

A user language table 110 ( FIG. 11) is provided to a user for storing information about available or installed private dialog languages. The installed language field 112 is designed to display the number of languages that are installed and is preferably one byte in size. Because a code, preferably a number, is attached to an installed language, the number of languages installed can be used to generate the code for a newly installed language.

A user's code for a private language may differ from the system language code for the language found in the system language table 76 . Therefore, a user language membership table 114 is created that shows the association between a specific user language code and language name with the system-wide language codes. The structure of the user language membership table 114 is shown in more detail in FIG . In the user language affiliation table 114 , an entry 116 can either use a field 118 for the user language code or use a field 120 approximately 10 characters long to indicate the associated language name and a field 122 which indicates the language code used by the operating system, as indicated by the system language table 76 ( FIG. 7). Fields 120 and 122 can be approximately 1 byte in size. The user language membership table 114 is used because the language code used by a user to represent a language may differ from the code used by the rest of the system.

The user information table 130 ( FIG. 13) is similar to the system information table 70 . This table is used to summarize the user-specific information and to provide connections to the system-wide information. This table contains four pointer fields 132 , 142 , 144 and 146 . Columns 131 and 133 show representative values for a released system and a non-released system. The pointer field 132 indicates the location of the user interleaved voice stack 102 ( Fig. 10). The pointer field 142 indicates the location of the connection table 60 ( FIG. 5) in the private memory 54 , which is provided for a user of a private memory 54 . Pointer field 144 indicates the location of system information table 70 ( FIG. 6) in shared memory 56 ( FIG. 3). Finally, the pointer field 146 indicates the location of the user voice table 110 ( FIG. 11). One or more of these pointer fields can be replaced at any time by the structures they point to. However, if the system's multilingual dialog is not released, then separating these structures saves space. If the user information table 130 contains structures of different sizes, then it no longer has a fixed size, which is possible but not preferred.

The remaining fields of the user information table 130 ( FIG. 13) contain a field 134 which indicates the dialog language for the currently running private application program and a corresponding field 136 for community application programs. A field 138 indicates the current maximum number of private languages in which a user can communicate with the system. This number can expand dynamically, preferably in steps of 4, if necessary. Finally, a field 140 is used to indicate the maximum amount of private storage 54 that a user can have. All of these fields are preferably 1 byte in size.

The multilingual operation of a preferred embodiment of the invention will now be described in connection with FIGS. 14 to 33.

In general, the operation can be in the following way be written. An application program can input and Output message commands containing that in monolingual Commands used in systems appear similar. Nevertheless, an application program can only do the desired Show messages that have a message number or a Use mnemonics. The operating system of a computer or a multilingual processor receives this command and determines the message file from which the displayed after to be called up. The preferred dates above structures and the preferred processors below support this dialogue by making the more recognizable language dialog for the application programmer and Be user.  

The configuration of a system for fully released, multi-lingual dialogues with users, as shown by way of example by FIGS. 1 to 4, is described in more detail in connection with the flow diagram according to FIG. 14. The configuration process includes the initialization of system variables or arguments and the loading of message files for the operating system, as well as the establishment of connections to them. This configuration begins with the search (step 150 ) of suitable message files for the operating system. A count variable or argument, e.g. B. Name "X" is set as the number of languages found. If desired, the number "X" can be easily set by a user to facilitate the search in step 150 . This option is desirable if the number of languages is known. Then the system is configured for use with the number of "X" languages in step 152 . Step 152 of configuring the system to use "X" languages is described in detail in connection with FIG. 15. If step 152 of configuring the system is not successful, as found in step 154 , then an error is signaled (step 158 ). If the configuration of the system is successful, execution continues with step 156 by loading message files for the available languages. The process of loading a message file is described in more detail in connection with FIG. 17.

The process of configuring the system for multilingual dialogs with a number "X" of natural languages is illustrated by the flow chart of FIG. 15. In this process, it is first determined in step 160 whether the system has already been configured or has been fully released, preferably by checking pointer field 96 ( FIG. 8), which indicates whether system information table 70 has been initialized. Because a configured system should not be reconfigured as long as other users are using it, an error is signaled (step 162 ) if a reconfiguration has been attempted. Otherwise, the system is configured in step 164 by reducing the storage space for the system information table 70 ( FIG. 6) and the connection tables 60 ( FIG. 5) for the operating system and for common application programs.

The size of the system language table 76 ( Fig. 7) for which a reduction (step 164 ) was performed is determined by the number of languages indicated by the value "X". Through this decrease step 164 , the pointer fields 78 and 79 of the system information table 70 ( FIG. 6) are set. The pointer field 96 ( FIG. 8) of the system release table 90 is also set in step 164 . The remaining values of the system information table 70 , ie the installed language field 74 and the maximum number of languages field 72 for the maximum number of languages, become in step 166 the number of languages installed and the maximum Number of languages, e.g. B. the value of "X" set. The multilingual dialog for private application programs is then released in step 168 by filling the field 92 of the system release table 90 with a "true" value (step 168 ). After completing the configuration step, the connection tables 60 remain empty and there are no language words in the language tables. Furthermore message files have to be installed (field 72 ) and a standard dialog language (field 94 ) has to be set.

The standard operating system dialog language (field 94 ) can be changed by a person with sufficient system authorization, such as a system administrator, using a process described in FIG. 16. The system administrator calls the process that displays a desired new dialog language. Because the system's default language should not be changed unless the system is being configured, such a configuration should be checked (step 170 similar to step 160 of Figure 15) and an error displayed (step 172 ) if the system is not configured is. If the system is configured, then it is determined (step 174 ) whether the message file for the desired dialog language is loaded into memory. If the desired dialog language is not loaded in the memory, an error is signaled (step 175 ) and the operation is terminated. Otherwise, the field 94 of the standard dialog language of the operating system ( FIG. 8) is set (step 178 ) to display the desired language. This system default language is not the same as the user's default language. The former can only be changed by the system administrator or the like; the latter by the user, although both can display the same language.

Once the system has been configured, application pro programs are loaded and executed and connections are made between programs and message files.

The process for loading a dialog language message file for a collaborative application will now be described in connection with FIG. 17. The desired dialog language for the application program has already been set up for this process. The first step in this process is step 180 (similar to step 160 ), which determines whether the system is approved for multilingual dialog. If the system is not fully enabled, an error is signaled (step 182 ) and the process is terminated. If it is determined in step 180 that the system has already been configured for a multilingual dialog, then the language code for the desired dialog language is searched in the system language table 76 ( FIG. 7) in step 184 . If the code is not found and if table 76 is full, which is determined in step 186 , then an error is signaled (step 188 ) which indicates that the maximum number of languages has already been installed on the system.

If the language code is not found in step 184 , but the system language table 76 is not full, then an entry 80 is added to the system language table 76 (step 190 ) for that language code and its associated language name. After the language code for the message file of the dialog language sought is found in the system language table (step 184 ) or placed therein in step 190 , the storage space in the shared memory 56 for this message file is reduced (step 192 ). Following step 192 of space reduction, the connection table 60 ( FIG. 5) for the shared memory is searched to determine whether an old pointer to a message file for that dialog language exists. If an old pointer is found, it is temporarily saved by step 194 . Following the saving of the old pointer in step 194 , the new pointer to this message file is stored in the connection table 60 (step 196 ), which in turn is followed by a step 198 which is an old non-zero pointer previously saved in step 194 rearranged.

Message files for a shared application program are normally not loaded unless the application program is loaded in shared memory 56 . The process described above assumes that a collaborative application program is loaded into memory 52 and that the message file exists for the desired dialog language. The existence of a shared message file is checked in step 150 ( Fig. 14) for message files of the operating system and step 206 ( Fig. 18) will be described later for shared application programs.

A collaborative application program, but not the operating system, is normally loaded by a person with sufficient authorization, such as a system administrator, through the introduction of a load command. The process of loading is outlined by the flow diagram of FIG. 18. Loading a shared application program in response to a load command begins at step 204 , which loads the application program into shared memory 56 . It is next checked in step 205 whether a multilingual dialogue with the system is fully enabled by checking the pointer field 96 of the system release table 90 ( FIG. 8). If a multilingual dialog is not fully released, the loading operation is complete. Otherwise, the operation continues to step 206 , which determines the available message files for the collaborative application program. Any available message file is then loaded into shared memory 56 (step 208 ) according to the process described above in connection with FIG. 17.

If the processes according to FIGS. 14 and 15 have been successfully completed, then the system is fully released for a multilingual dialog with the operating system and any other common application program loaded by the process according to FIG. 18. The release of a multilingual dialog with private application programs will be described in connection with FIGS. 19 and 20.

To enable a multilingual dialog for private application programs, step 210 ( FIG. 19) of the initialization of the field 92 ( FIG. 8) is carried out in order to set the field 92 and to indicate that a multiple dialog for private application programs is released . This initialization step 210 is the same as step 168 , which is performed as part of the system configuration ( Fig. 15). Initialization step 210 may also be performed to enable multilingual dialog with private application programs if the system is not configured for such dialogs with the operating system and other collaborative application programs, although this will make the system private but not fully enabled. So that such an approval process can be carried out, a user should have a suitable authorization to access the field 92 , namely the authorization of a system administrator or the like. This process is performed before other users communicate with private application programs in multiple languages.

When a user begins to use the data processing system, typically by "logging into" the system from a user station, then the per-user data structures, particularly the user voice table 110 ( FIG. 11), are accessed through the initialized the flow diagram according to the process described in FIG. 20. The initialization begins with step 220 , which initializes fields 134 and 136 for voice codes and pointer field 144 to the system information table 70 ( FIG. 6) of the user information table 130 ( FIG. 13). The language codes of fields 134 and 136 are initialized with a non-language word and the pointer field 144 of the system information table is set to the storage location of the system information table 70 that comes from the corresponding pointer field 96 of the system release table 90 ( Fig. 8) is obtained. If the system is not at least privately released for a multilingual dialog (it can also be fully released), which is determined in step 222 , then the remaining pro user fields are filled with non-released default values. That is, the maximum number of user languages 138 , the maximum amount of private memory in field 140 , the pointer field 142 pointing to the connection table 60 for the private memory and the pointer field 146 pointing to the user language table 110 all become set to, for example, "0", "0", "zero" or "zero" (step 224 ). In this way, storage space is neither allocated for the connection table 60 for the private storage nor for the user voice table 110 and thus storage space is saved. If a multiple dialog for private application programs has been released, as determined in step 222 , then the user voice table 110 and the connection table 60 for the private memory are allocated space (step 226 ). Pointers 142 and 146 , which point to the memory locations in memory, which were respectively assigned to the two structures, are set. In step 228 , field 138 , which indicates the maximum number of user languages, is determined with a predetermined fixed value, e.g. B. 4 occupied. The maximum size of field 140 is similarly initialized. The method now continues with step 230 , which makes an entry 116 in the user language membership table 114 for the field 122 for the language code and the field 120 for the language name of the standard dialog language of the operating system, which it makes in the system standard - Language field 94 ( Fig. 8) of the system release table 90 fin det. Field 118 is set to hold the first language code, for example "1". The language field 112 of the user language table 110 ( FIG. 11) is set to "0". The initialization of the per-operator data structures is ended by step 234 , which sets the standard dialog language of the user of the operating system and initializes the field 100 ( FIG. 9) for the user language.

After a user language has been initialized, the data processing system is fully released (if the system configuration is complete) or otherwise privately released for a multilingual dialog with the user. If the system is predominantly shared with private users and is not configured for community applications, then no storage space is allocated to the community data structure, except for the system approval table 90 ( FIG. 8). In this table, field 92 indicates that multilingual use is released for private use. The standard dialog language for operating systems (system standard language field 94 ) is with a non-language word, for. B. "-1" is occupied, the storage location of the system information table 70 indicating pointer field 96 is occupied with a "zero" word. The words in the user information table 130 are initialized with the words displayed in column 133 ( FIG. 13) and as already described above in connection with FIG. 20. The private system information for a user (FIGS . 9 to 13) depends on the configuration of the shared system information ( FIGS. 5 to 8) at the time of initialization for this user.

Another capability that this data processing system preferably has is that a user has the option of changing the standard language of the user found in field 100 ( FIG. 9) for the user language (cf. FIG. 21). The user communicates with the operating system and with application programs that were called up without specifying an alternative language in the standard user language. When the user orders a change of the standard user language, it is first determined (step 370 ) whether the message file for the desired dialog language of the operating system has been transferred in the memory. If it has not been transferred to memory, then an error is signaled in step 372 . Otherwise, the user language field 100 is populated with the new language displayed by the user. This language is then added to the user language table 110 in step 376 . If the user language table 110 becomes full, then it is expanded in step 378 in a manner that will be described hereinafter in connection with FIG. 25. A message is then sent to the user via the user station 42 to inform the user whether the standard language has been set.

During the dialog with the data processing system, a user can call private and / or collaborative application programs, which may indicate a desired dialog language that differs from the standard user language. This is useful when an application program is available in a language that is not available to the operating system, that is, that cannot be a user standard language. The process of calling an application will now be described in connection with the flow chart of FIG. 22.

If an application program is called, in step 242 the readiness of the called application program to be executed is checked. If the system is not released for private, multilingual dialogues with private application programs, which is checked in step 244 and if a desired dialog language was specified when the application program was called, which is determined in step 246 , then an error is signaled in step 248 and the call is canceled. If no desired dialog language is displayed, the application program is simply executed.

If the multilingual system is approved for multilingual dialog with private application programs, which is determined at step 244 , then the values of fields 134 and 136 ( FIG. 13) are set to the user interleaved speech stack 102 ( FIG. 10) and fields 134 and 136 are reinitialized with non-language words. And then it is determined in step 250 whether a desired dialog language is displayed and in step 252 an argument is set for the desired language. If no desired language is displayed, then this argument is filled with a "zero" word in step 254 . Assuming either an argument has been made in step 252 or step 254 , a language has not yet been selected, and a message file has been displayed for the application program for the selected language, which steps 257 and 258 determine, then step 260 goes to Errors signaled and the call of the application program is aborted. If no desired dialog language is displayed and no message file was found at step 256 , then the returned language code displays a non-language word and the appropriate fields 134 and 136 ( FIG. 13) are filled (step 262 ). If a dialog language message file was found in step 256 , then fields 134 and 136 are populated with the returning language. If the called application program is a private application program, then the private field 134 is populated with the language code of the loaded message file and the shared field 136 is populated with a non-speech word. Conversely, fields 134 and 136 are set for a collaborative application program.

Figs. 23a and 23b outline the process of selecting one language and of finding and loading a Nachrichtenda tei program for the selected language of the called application. First, it is determined in step 264 whether the application program is a collaborative application program, for example, by checking the memory address in which the process code is loaded. If it is not a collaborative application program, then it is a private application program, for which the method of selecting a language and finding and loading the message file is described in Fig. 23b. If the application program is a collaborative application program, then it is assumed that its message files are loaded because only then does a language need to be selected.

For a collaborative application program, the process continues to check the argument indicating the desired dialog language (step 266 ). If a desired dialog language was displayed, then the system language table 76 ( FIG. 7) is searched for this language (step 268 ). If the search step 268 does not find the desired language, then a non-language value is returned in step 270 indicating that the desired dialog language is not available for this collaborative application program because if a collaborative application program is loaded, then its associated message files are loaded in the shared memory 56 and entries for the associated languages are made in the system language table 76 . If a desired dialog language for a common application program has not been found in the system language table 76 , then this language is therefore not available for this application program.

If the language has been found in the system language table 76 , then the common connection table 60 is checked (step 272 ) to determine whether the message file for the desired dialog language is loaded into the common memory 56 of the common application program. If a connection for the language and the program is not found in the shared connection table le 60 , then a non-language word is returned (step 274 ). If a connection has been found in the connection table 60 during step 272 , an entry 116 for this language is placed in the user language table 110 ( FIG. 11), if none should yet exist. When the user voice table 110 is full, it is expanded, as will be described in more detail below in connection with Figure 25 (step 276 ). Referring to step 266 , if the dialog language argument was a non-language word, then the current dialog language is checked in step 278 to determine if a dialog language is currently in use, as indicated by fields 134 and 136 ( FIG. 13 ) is shown. If a dialog language is currently in use, then the process continues to step 280 , which populates the current language word with an argument. If the current language is for a private application program, then the system's language code is retrieved from the user language membership table 114 . If the language is intended for a community application program, then this value is filled with the language argument.

The method continues with step 282 , which looks for the message file in the shared connection table 60 , similar to the step 272 previously described. If the message file has been found in the connection table 60 , its associated language code is sent back (step 284 ). Otherwise, the method continues with step 286 . Step 286 is also performed if it is determined in step 278 that no dialog language is currently available. Step 286 includes checking the user default language as indicated by field 100 ( FIG. 9) for the default language. If the user default language code is a non-language word, then a non-language word is returned in step 274 . Otherwise, the common link table 60 is searched for the message file of that dialog language, as was done in step 272 previously. The process of loading the message file is then completed by step 274 or step 276 , as previously described.

If, as previously described with respect to step 274 , if the application program is determined to be a private application program, then the process continues to step 290 ( FIG. 23b) where it is determined whether a desired dialog language has been specified. If a dialog language was specified, then the user language table 110 ( FIG. 11) is searched for this language in step 292 . If this language is found in the user language table 110 , then the connection table 60 for the private storage is checked in step 294 to determine whether the message file of that language has been transferred to the private storage 54 . If the message file has been transferred, then in step 296 the language code is returned.

If the alternative language message file has not been transferred, as determined in step 294 , then it is determined in step 298 whether this message file has been previously searched for. If it has not been searched for before, then an attempt is made in step 300 to convert this message file to this dialog language. This attempt is also made if the desired dialog language was not found in the user language table 110 in step 292 . If the attempt to transfer this message file in step 300 is successful, the language code for this message file is returned in step 302 . If this message file was not found, then the process continues to step 304 (as will be described later). If it is also determined in step 298 that a dialog language message file has previously been searched, then the process also proceeds to step 304 to be described.

If, with reference to step 290 , no desired dialog language is displayed, then fields 134 and 136 are checked in step 306 to determine whether a dialog language is currently being used. This determination step 306 is similar to step 278 previously described in connection with the flow chart of FIG. 23a. If a dialog language is currently being used, it is selected and the process continues with step 294 , already described above. Otherwise, the method continues with step 304 , which determines whether a dialog language has already been selected by the user for use with the operating system. This is done by checking the field 100 ( FIG. 9) for the user language. If the user language field 100 indicates a non-language word, e.g. B. "-1", then a non-speech code value is returned in step 307 . Otherwise, the private storage connection table 60 is checked to determine whether the message file of the language indicated by field 100 has been transferred to private storage 54 (step 308 ). If the file has been transferred to private storage, then in step 310 the language code is returned. Otherwise, an attempt 312 is made to transfer this language into the private memory 54 . If the attempt 312 is successful, then in step 310 the language code of the message file carried over is returned. Otherwise, a failure is indicated and a non-spoken word, e.g. B. "-1" will be returned.

The process of transferring a message file to private storage 54 (steps 300 and 308 of FIG. 22b) will now be described in detail in connection with FIG. 24. This process depends on receiving an argument indicating the desired language, and the argument is checked in step 320 to determine if the argument is a language code or name. If the argument is not a language name, then the process continues to step 322 , in which the name of the language associated with the language code is obtained. In step 322 , the name determination is performed using the user language membership table 114 ( FIG. 12). If the voice name is not found in step 322 , an error message is returned (step 324 ). Otherwise, the process continues to step 324 by giving the language name an argument, e.g. B. "Name" is buried, which is either given or which is obtained from a given language code. A file name for the desired message file is put together from the argument "Name". The format of this file name depends on the specific operating system of a given data processing system. However, this file name usually indicates both the application program name and the selected language name (step 326 ). The composition of the file name is followed by step 328 by searching for the message file in the long-term memory (eg a hard disk) of a data processing system. If the message file is not found, then an entry 64 is made in the private storage connection table 60 (step 330 ). This entry step 330 includes setting the program field 62 to indicate the call of the application program, setting the language field 68 to the desired dialog language and setting the pointer field 66 for the message file to, a non-zero word and a non-pointer word that indicates that the message file was searched for but was not found (step 330 ). An error is then signaled in step 332 . If the message file has not been found, then the user language membership table 114 ( FIG. 12) is searched for the language code associated with the name of the desired dialog language (step 334 ). If no language code was found for this entry in step 334 , then an entry 116 is made which fills the field 118 for the user language with the given code, which fills the field 120 with the dialog language name and which fills the field 122 with the system code from the system language table 76 ( FIG. 7) which corresponds to the language (step 336 ). The entry step 336 also includes the step of expanding the user voice table 110 if it is full. This table expansion will hereinafter be described in detail in connection with FIG. 25. Once it is determined that the language has been entered in the user language belongingness table 114 through the steps 334 and possibly 336, then the message file for the desired dialogue is PRACHE transferred to the private memory 54 in step 338th Then, in step 338, an entry 64 is made in the connection table 60 for the private memory by setting the pointer field 66 for the message file in such a way that the storage location into which the message file has been transferred is displayed. Finally, in step 342 , the per-user language code for the desired dialog language is sent back.

The process of expanding the size of the user voice table 110 ( FIG. 11) (steps 336 of FIG. 24, 276 of FIG. 23a and 378 of FIG. 21) will now be described in detail in conjunction with FIG. 25. The process begins at step 350 , where, as indicated in field 338 , the user information table 130 , the maximum number of possible user languages is increased. The increase in the number of user dialog languages is followed by step 362 , in which more storage space is allocated for a larger user language table 110 . This new table is then initialized with zero words (step 354 ). After the table is initialized, the data from the old user language table 110 is copied to the new table (step 356 ). After the old words have been copied into the new table, the old memory space can be released in step 358 .

If the number of user languages has increased, the size of the connection table 60 for the private memory can also increase. Therefore, in step 360, memory space is allocated for a new connection table 60 , which is followed by step 362 by initializing the new connection table 60 with zero words, which in turn is followed by step 364 by copying the old data in and then the memory space of the old connection table 60 released. In this way, the size of the connection table 60 for private storage and the user voice table 110 can grow dynamically. The frequency of expanding these tables is minimized by increasing them not only by one entry, but by four entries at the same time.

During the execution of an application program, a message can be sent to a user in a user language chosen for this purpose. If the application programmer has specified a standard output function for a typical data processing system, then this function can be modified to enable it to find the correct message in an established dialog language of the user. In the first step 390 it is determined whether it is a community or private application program. After this determination, the release status is checked by examining the system release table 90 to determine that the system is either fully shared or privately released. These determination steps are steps 392 and 394, respectively. If the system is not properly enabled for multilingual dialogs, then a message pointer is set with a null word in step 396 , as if no multilingual message was found. If it is determined in step 392 that the system is fully approved for shared use, then the process continues to step 398 in which the message is to be found in the shared message file. Step 398 , namely finding the message, will subsequently be described in more detail in connection with FIG. 27. If it is determined in step 394 that the system is privately released, then the process continues to step 397 in which the message is to be found in the private message file. This process will be described in connection with FIG. 26.

Upon completion of one of the steps 396 , 397 or 398 , the message pointer either indicates zero or the location of the desired message. In step 400 , it is next determined whether a message has been found by checking this pointer. If a message is not found, that is, if the message pointer is zero, then the process continues to step 402 , which handles the output of a standard message. Otherwise, the process continues to step 404 where the desired value for the message is. This value may be the pointer to the message, the message string itself, the buffered message, or the message string sent to a user at a corresponding user station 42 .

The process of finding a message from a messaging file of a collaborative application program (step 408 , FIG. 26) will now be described in detail in conjunction with FIG. 27. The first step in finding the message is to determine (step 410 ) whether a dialog language is currently being used for this application program. The determination step 410 includes the checking of the fields 134 and 136 ( FIG. 13), which indicate the language code of the currently running private or community application programs. If both fields indicate a non-language word, then the process continues to step 412 where it is determined whether the message file of an operating system standard language has been transferred to the memory of the common application program. If this message file has not been transferred to memory, then a null message pointer is returned in step 414 . Otherwise, the pointer to the message file is retrieved from the common application program connection table 60 and the pointer to the desired message is retrieved (step 416 ) from this message file. If a current dialog language is available for an application program, which is determined in step 410 , then in step 416 the pointer pointing to this message file and subsequently the message itself is retrieved.

The process of finding a message from a message file for a private application program (step 396 , Fig. 26) begins at step 430 ( Fig. 28) by determining if a current dialog language is being used for an application program. This determination step 430 is performed by examining fields 134 and 136 ( FIG. 13) which indicate the language code in which an application program currently running communicates with a user. In step 434 , by examining the connection table 60 for the private memory, it is next determined whether the current language message file for this application program has been transferred to the private memory 54 and the entry 64 for this application program and the pointer field 66 ( FIG. 5). is called for the message file. If the message file has been transferred to private storage, then the pointer indicating the location of the message file in private storage 54 can be used by step 436 . If it is determined (step 434 ) that the message file has not been transferred to private storage, then it is determined in step 438 whether it has been searched for in step 438 before. If previously searched for, then the pointer field 66 displays a non-zero word and a non-pointer word as set in step 330 of FIG. 24. However, if no attempt was previously made to find this message, then an attempt is made in step 440 to transfer it to private storage. This step 440 of transferring the message file to private storage has already been described in detail above in connection with FIG. 24. If the attempt to transfer is successful, then the message file pointer field 66 is set and used to return a pointer pointing to the desired message in step 436 , as described above.

If the attempt 440 to transfer a message file to private storage fails or if such an attempt has been made previously, which was determined in step 438 or if it was determined in step 430 that no current dialog language is displayed for this application program , then the process proceeds to step 442 by selecting the user default language as indicated by field 100 ( FIG. 9). If no language has been set, then a null pointer is returned in step 444 . Otherwise, it is determined by examining the connection table 60 for the private memory (step 446 ) whether the message file in the user standard language for this private application program has been transferred to the private memory 54 . If a pointer pointing to this message file has been returned from pointer field 66 ( FIG. 5), then the pointer pointing to the message can be called from the message file in a manner similar to step 436 described above. If it is determined that the message file has not been transferred to private storage, then the process continues to step 450 by determining in a manner similar to step 438 described above whether it has been previously searched for. If this message file was previously searched for, then a null pointer is returned in step 454 . Otherwise, an attempt is made in step 452 to transfer this message file to private storage 54 , as previously described in connection with FIG. 24. If this attempt 452 is successful, then a pointer pointing to the desired message can be called using a location of the message file in private storage as in step 448 . If the attempt 452 fails, a null pointer is returned in step 454 .

The system's ability to respond to natural voice input from a user using user station 42 can also be created. Standard input processing functions can be modified to include the steps described below in connection with Figure 29 11328 00070 552 001000280000000200012000285911121700040 0002004325096 00004 11209. For this process, a message file also contains input from a user in natural language, e.g. B. "Yes", "No" and "Leave". These input messages can be included in the message file along with output messages. The first step of processing natural language inputs includes step 460 , in which it is determined whether the multilingual properties of the system have been appropriately released according to the type of application program (ie, shared or private). If this property is not released, then a false value is sent back in step 462 . The type of program can be determined by examining the location in which it is stored. The release status can be determined from the system release table 90 ( FIG. 8); and in particular in field 92 for private applications and in pointer field 96 for joint applications. If it has been determined that the application program is a collaborative application program and the system is fully enabled, then the process continues to step 466 , in which the first message to be compared to the user's input is is set. An application programmer would normally expect an input from a user that corresponds to a complete list of possible input messages. The application programmer can then compare the input to each of these expected responses. Even an argument "N" to the first of these expected messages. The process continues to step 468 in which this expected message is to be found in a message file. If the message is not found, then steps 474 and 468 look for the next expected message. If a message has been found, then this message is compared in step 476 with the input of the user.

Step 476 of matching the retrieved message with the user's input can be performed in a variety of ways; an adjustment can be partial, similar or exact. If the message matches an input from the user, then the input, the message, or a true value can be returned in step 478 . It is possible to continue this comparative search to find other matches with messages and to return a list of partial matches rather than a single and first match. If the user's input does not match the retrieved expected message, then the next expected message is called in step 474 and the process continues with step 468 already described above. If there are no remaining, expected messages, and if none was found that matches the user's input, then a false value is returned in step 480 . This step 480 may alternatively send back the list of previously found partial matches. In this case, the list is initialized with a false value.

In the event of user input for a private application program, the process of matching the message begins at step 482 , in which the first expected message is selected, provided the system is at least privately released. The process continues to step 484 in which the message is to be found in the message file for this private application program. Steps 490 , 492 , 494 and 496 remaining for this process of matching input to a message are similar to steps 476 , 478 , 474 and 480 for finding a message for a collaborative application program. In any case, a user's input in natural language is compared to a group of expected inputs so that full dialogue between a user and the data processing system in a natural language is enabled.

In due course, it may be desirable to remove an application program or dictionary and its message files from memory or use ( Fig. 30). The first step 500 of removing an application from use is to identify the location of the process code or other identifier of the application program. The identifier found in step 500 is used in step 502 as a search index for the connection table 60 and the entry 64 is called. For the corresponding message file displayed in the pointer field 66 , the assignment is withdrawn and the entry 64 is removed from the connection table 60 (step 504 ). The assignment can then be withdrawn for the application program or the dictionary itself (step 505 ).

If an application program is a nested application program, ie if it was called by another application program, the program level is restored as shown in FIG. 31. The language stack register 102 interleaved by the user is used to call an entry 104 for the application program that was previously running. This entry 104 ( FIG. 10) is used to set fields 134 and 136 ( FIG. 13) of the user information table 130 , which indicate the language in which the current application program is running (step 506 ). The pointer field 132 pointing to the interleaved language stack register ( FIG. 30) is then reset to the next entry 104 of the language stack register 102 (step 508 ).

For a multilingual data processing system it can may also be desirable to authorize a user or to get a list of dialog languages for one Application program are available. Two types of lists are possible. The first of these lists contains the languages for an application program for which message files transferred to private or shared storage or ge have been loaded. The other type of list is a list the dialog language message files that are needed for a given Application program exist on a hard disk. The the former is mainly for community applications desirable. The second is preferably for private individuals applications whose message files are not all in the Pri vat storage were transferred.

The first list type will now be described in connection with Fig. 32. This construction begins at step 510 , in which it is determined whether the multilingual dialog on the system is appropriately released for the type of application program. If it is not released, the user is notified that no languages are available for this application program (step 512 ). Otherwise an argument, e.g. B. Set "N" to the maximum number of languages (step 514 ) as found in field 72 of the system information table 70 ( Fig. 6) (step 514 ). A second argument, e.g. B. "L" is set to "zero" (step 516 ). The second argument is then compared to the first argument in step 518 . If the second argument "L" is greater than the first argument "N", then this indicates that the number of languages searched is greater than the number of maximum languages and the process then ends (step 520 ). Otherwise, it is determined whether the message file of a dialog language having a language corresponding to the second argument "L" has been installed by examining the suitable connection table 60 and by examining the pointer field 66 for the message file for the program field 62 and the language field 68 ( FIG. 5) . If it is found in step 522 that the language message file has been loaded, then in step 524 a message is sent to the user in an appropriate dialog language indicating that the language corresponding to the second argument "L" is available. If the language is not installed, or if the second argument "L" was incremented in step 526 after the message indicating that it was installed was sent to the user, then the process will continue to compare step 518 as already described above. In this way, the user at the user station receives a stream of output messages indicating which languages are available for the selected application program.

The structure of the second list type of available dialog languages will now be described in connection with FIG. 33. The first step in this construction is step 530 , in which it is determined whether a multilingual dialog has already been released for the system. If it has not yet been released, then a message is sent to the user in step 532 indicating that no languages are available. Otherwise, the data processing system memory is searched in step 534 to find the message files of a given application program. This search is performed using a file name based on the application program and the file type of a message file, with any language name that is in the message file being accepted. For each message file found in step 534 , the language name corresponding to that message file is made part of a message that is sent to the user to indicate that that dialog language is available for the given application program (step 536 ).

With the embodiment described above, a user can specify a desired dialog language so that then the dialogue with the data processing system in this language che can be carried out if this language for a ge given application program is available. Such a system can be used in a variety of multilingual environments be useful.

Claims (12)

1. A method for providing a user dialog via a text interface in several natural languages in a computer system with a central computer, which is connected to a plurality of user stations via communication links, with a processor for executing a plurality of application programs that run simultaneously to be used by a variety of users and a memory connected to the processor to store at least one message file, a message file containing natural language text information for one of the application programs, with different text information for different application programs are provided with the following steps:
Providing a connection table with a plurality of connections between the application programs and message files, a connection storing values associated with an application program, a natural language, and a storage location for a message file associated with the application program and the natural language in the memory is, point out;
Selecting a natural language through the application program;
Accessing the connection table to select the space allocated to the message file for the application program in the selected natural language;
Retrieving the text information from the message file;
Output of the relevant text information to the user. 2. A method according to claim 1, further comprising the steps of:
Storage of a current dialog language; and
Storage of a standard language, with the step of selecting the natural language between the current dialog language and the standard language. 3. A method according to claim 1, further comprising the steps of:
Storage of a current dialog language;
Storage of nested speech information; and
Replace the current dialog language with a dialog language to be assigned to another application program in response to a command of the application program to call another application program and save the previous, current dialog language. 4. A method according to claim 1, with the further step ten: Load the message file of the current dialog language of the called application program into one Contains memory and create a connection in the Connection table in response to the step of La message file. 5. A method according to claim 3, further comprising the Step of selecting the dialog language to be assigned between the current dialog language and a Stan default dialog language is used. 6. A method according to claim 5, wherein the step of Selection of the dialog language to be assigned the step of Load the message file of the dialog to be assigned language of the called application program into one Memory and then the step of creating lens of a connection in the connection table holds. 7. A method according to claim 6, wherein:
the call of another application program contains at least one possible dialog language; and
the selection of the dialog language to be assigned is made from the possible dialog languages. 8. A method according to claim 7, further comprising the steps of:
Replacing the current dialog language in response to a termination of the called application program with a previous dialog language from the stored, nested language information; and
Removing the previous dialog language from the stored, nested language information. 9. A method according to claim 8, wherein the stored, nested speech information in a batch register is saved. 10. A method according to claim 8, wherein the nested Speech information saved in a linked list chert is. 11. A method according to claim 10, further comprising:
Storage of a current dialog language; and setting the current dialog language in response to a command from a user to invoke an application program using a desired dialog language if a message file containing messages in the desired dialog language is available; and
Set the current dialog language as a standard dialog language if the desired dialog language is not available. 12. A method according to claim 11, further comprising the step of:
Loading the message file of the current dialog language of the called application program; and
Create a connection in the connection table for the loaded message file and the current dialog language.