Software tool to perform concurrent national language translation builds

[0002] 1. Technical Field

[0003] The present invention relates in general to software applications, and in particular to a method and system for facilitating translations during the build process of software applications on a data processing system. Still more particularly, the present invention relates to a method and system for performing concurrent national language translations builds of software applications on a data processing system.

[0004] 2. Description of the Related Art

[0005] The global nature of the world today has created an increased market for computer software applications which may be simply translated into a large number of foreign languages. Indeed, National Language Support (NLS) is increasingly important as the market for data processing systems is ever expanding. While the demands upon hardware systems are minimal for NLS needs are often solved by the provision of a small number of special keyboard characters, the large textual content of many software applications lead to a more difficult NLS problem.

[0006] The translation of a software application into a foreign language for utilizating a batch process wherein the text may be edited with a text editor. The resultant translation must then be verified with a simulation of the display screens of the software application or by executing the program after translation and building of the application have occurred. Additional changes brought about by variations induced due to the contextual nature of a text entry or as a result of simple size differences between a textual entry in two different languages must then be edited in the batch process and the verification program repeated.

[0007] NLS builds need to have concurrent product release dates. Before shipping US products, the development group must complete all translation packages. To adhere to this requirement, the US ship date is often held up by 30 days. Exceptions are often made for double-byte character string (DCBS) packages and Right-to-Left packages, resulting in further delays.

[0008] The current NLS build process is a post-process condition. The development and build teams do not know a build will break (i.e., not execute correctly) until after the build has completed. When developers create new files in the English release, for example, they must also send them to the translation centers for translation. Sometimes these files are overlooked until late in the development cycle. These files are then expedited to the translation packages which often is a costly, confusing and major issue.

[0009] Some NLS processes utilize Configuration Management Version Control (CMVC) “file linking” for NLS support. Linking solves some initial seeding problems where sparse CMVC release trees existed. This method causes library control performance issues. In addition, some products are reaching the CMVC maximum limitation of 26 linked releases. This method also has problems when new files were created. File linking would need to be redone against all NLS releases. Additionally, the file linking method did not provide merge support.

[0010] Other processes solved the sparse tree problems by doing NLS builds in a serial fashion. First the English files are downloaded, and then the translated files are downloaded, overlaying the existing English files. This method by-passes the library control system to control the NLS builds. The English files merged into the NLS build are not recorded on the build machine making reproducible builds a difficult process.

[0011] Among the problems with current NLS is the fact that sparse tree support is not provided under CMVC. Sparse tree means only a subset of the total translatable files were translated. This results in the number of first language files being different from the number of second language files in a library. Creating an application from the second language files results in a break as not all the files required to build the application are present. Thus a merge process is required wherein the first language files not present in the second language block of files are merged with the second language files to create a combined target object. Additionally, MRI builds are not presently reproducible under CMVC. The delta build process is extremely complicated and the reaction to problems is post-build when it is even more difficult to solve.

[0012] Current NLS build processes usually by-pass library control features. English files are copied from the library control machine then overlaid by the NLS files. Problems occur when English files are updated. The English files remaining on the NLS build machine become downlevel and the ability to re-create the NLS build becomes very problematic.

[0013] It is therefore desirable to have a method and system to perform concurrent national language translation builds to eliminate the aforementioned problems of building NLV applications. It is also desirable to perform concurrent national language translation builds to prevent delays in completion and shipping of software packages to the consumer.

[0014] It is therefore one object of the present invention to provide an improved software application.

[0015] It is another object of the present invention to provide a method and system for facilitating translations during the build process of software applications on a data processing system.

[0016] It is yet another object of the present invention to provide a method and system for performing concurrent national language translation builds of software applications on a data processing system.

[0017] The foregoing objects are achieved as is now described. A method is disclosed to provide concurrent national language support builds in a second human language during development of a computer software in a first human language on a data processing system. This method includes first tracking all baselevel changes of said software in a first human language, then storing the baselevel changes in a library control database field. At some point, a report of said baselevel changes is generated including a list of all newly created or updated files in the first human language which have not been translated into the second human language and all translated files in the second human language which are downlevel. The report is analyzed to give a real-time status of build to a developer of said computer software. The report permits the builder to decide whether or not to send the downlevel second language files to a national language center for translation.

[0018] In the preferred embodiment of the present invention, the invention first creates a baselevel field in a configuration management version control (CMVC) system with a library control database field. The baselevel field permits a baselevel value to be entered corresponding to the baselevel of a file of the computer software. All the files of the software are logged in the library control database field along with a corresponding CMVC version identification (VID) and related baselevel. During implementation, the files are extracted from the library utilizing a tool which creates a control file for each new update of a software and marks the control file with the proper information for the baselevel of the file extracted based on the baselevel of the file in said first language. When a file is submitted to a translation center and returned, its baselevel is automatically updated in the library control data base by the control file.

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

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

[0021] FIG. 1 is a block diagram depicting a data processing system utilized in accordance with the preferred embodiment of the present invention; and

[0022] FIG. 2 is a flow chart depicting the general build process utilizing the tool in the prebuild phase in accordance with a preferred embodiment of the present invention.

[0023] With reference now to the figures and in particular with reference to FIG. 1, there is depicted the basic structure of a conventional data processing system 10 utilized in the preferred embodiment of the invention. Data processing system 10 has at least one central processing unit (CPU) or processor 12 which is connected to several peripheral devices, including input/output devices 14 (such as a display monitor, keyboard, and graphical pointing device) for user interface, a permanent memory device 16 (such as a hard disk) for storing the data processing system's operating system and user programs/applications, and a temporary memory device 18 (such as random access memory or RAM) that is utilized by processor 12 to implement program instructions. Processor 12 communicates with the peripheral devices by various means, including a bus 20 or a direct channel 22 (more than one bus may be provided utilizing a bus bridge). Data processing system 10 may also include firmware 24 connected to the other components of the system.

[0024] Data processing system 10 may have many additional components which are not shown such as serial, parallel, and Universal Serial Bus (USB) ports for connection to, e.g., modems or printers. The invention is software implemented in a program integrated information (PII) tool in the preferred embodiment. Data processing system hard-drive is loaded with the software application containing the PII tool which is utilized to implement the invention. PII tool manages national language text for native language translations. It replaces machine readable information (MRI) which is program information that is translated.

[0025] PII tool provides a method to perform concurrent national language translation builds. In the preferred embodiment, PII tool is a build-tree merge tool which provides a method that allows the development team to perform concurrent builds on all the NLS build releases at any time during the development cycle. The invention also allows the development and build teams to discover NLS problems early in the product cycle. In the preferred embodiment, the invention provides library control “sparse” merge tree support.

[0026] Reports are generated during the implementation of the invention which are utilized to fix problems before actually starting the build “pre-build condition.” These reports list all translated files that are downlevel, and lists newly created first human language files which have not yet been translated. The invention further provides real time NLS status for all interested groups which allows a concurrent NLS build process in the preferred embodiment. Finally, in the preferred embodiment, PII tool creates blueprint reports utilized for NLS build recreate ability.

[0027] PII tool utilizes library control features to implement the invention. It expands the configuration management version control (CMVC) to include a baselevel field. It utilizes an available field of database to hold a file translation tracking tag. In the preferred embodiment, this tag is referred to as the “baselvl” field. This library control database field is utilized to track all changes to the language source file that would require a translation. Those skilled in the art are familiar with CMVC and its applications.

[0028] Utilizing the “baselvl” field, the tool determines if a translated file is downlevel compared to the equivalent language file, for example, an English file. The PII tool creates various reports and “file extract” commands. These reports and command files are based off of the information stored in the “baselvl” database field.

[0029] PII tool consists of several executable files including “showbrk.cmd” and Piifile.cmd. In the preferred embodiment, these files are written in REXX programming language. Those skilled in the art appreciate that any comparable programming language may be utilized to create these files.

[0030] In the preferred embodiment, PII tool supports all language packages including double-byte character string (DECS), single-byte character strings (SBCS) and Right-to-left packages.

[0031] The output of the invention is presented on a Graphical User Interface (GUI). In the preferred embodiment, the settings of a basic CMVC file are adjusted so that the “baselvl” field is displayed. Those skilled in the art will appreciate the configurations of and the process involved in adjusting the settings of a CMVC file. In one embodiment of the invention, the GUI interface does not update the “baselvl” field automatically and the command line tool “piifile” is utilized to update a file's “baselvl”.

[0032] In the preferred embodiment, CMVC “piifile” tool is utilized to perform functions on files that have changes that require updates to the baselvl field. This tool keeps the “baselvl” fields correct.

[0033] The PII tool fixes current build problems such as “file linking” and increases productivity in the NLS process. The file linking method is no longer required. In the preferred embodiment, the PII tool records each file's library control version utilized for a build. Recording the versions helps solve the problem of having to recreate older builds. Developers need only to update files in the release of the development language, such as English. They no longer have to ensure the file is seeded in all the NLS releases.

[0034] In the preferred embodiment, the tool is utilized by developers, build captains and PII coordinators. Developers utilize reports to debug translated build breaks and determine estimates of changed PII files. The tool also provides them the ability to build most current PII files.

[0035] Build Captains review translated builds before starting builds. The tool provides them with the ability to blueprint PII builds and increase build repeatability. PII Coordinators utilize the tool to estimate and manage PII file changes and to help control sparse CMVC releases.

[0036] To run the application the following code is utilized:

[0037] The SHOWBRK algorithm controls most of the processing of the invention and thus makes up an integral component of the PII tool. In the preferred embodiment, its syntax is as follows:

[0038] The above algorithm when implemented provides a plurality of output files including BLDEXT.CMD, BLDSPC.CMD, SHOWBRK.MAT, and SHOWBLD.RPT.

[0039] BLDEXT.CMD performs the CMVC extracts utilizing a command file which is similar to SHOWBLD.RPT, but in “.CMD” format. BLDSPC.CMD extracts only the mis-match files and error files. This file is a subset of “BLDEXT.CMD” and is a special request for Aurora and Lan Migration.

[0040] SHOWBRK.MAT shows the file delta mismatches and error report (contains Xlate to US mismatches and error report). The SHOWBRK.MAT report is utilized before performing a build to review if potential build breaks exists. In the preferred embodiment, this report is generated by the showbrk tool if the “baselvl” fields are mismatched, the translated “baselvl” is greater than the first human language level, or a new file exists in the first human language release, but not in the translated release. This report is also generated if any of the user's “force” files were not found in the extract file (BLDEXT.CMD). An illustration of a mismatched report, errors report and new file create report follows:

[0041] SHOWBLD.RPT shows what files will be pulled from CMVC (contains build report/blueprint/extract information). In the preferred embodiment, the SHOWBLD.RPT is generated when the SHOWBRK tool is run. Further, in the preferred embodiment, the report parallels the CMVC build extract file named (BLDEXT.CMD). For example, for every line in the BLDEXT.CMD file, there's an equivalent line in SHOWBLD.RPT report. The SHOWBLD.RPT gives a detailed, readable report of the PII files that are targeted for the build. A user reviews this file to determine the reason a PII file was chosen from the first human language release or translated release.

[0042] The following illustration depicts a portion of a typical SHOWBLD.RPT file. In the illustrative embodiment, each line written to the file represents the file chosen for the build. The development language “baselvl” is in the far-left column. For the purposes of this and other illustrative example, the English language is utilized as the development language. The remaining columns pertain to the file chosen for the build.

[0043] In the illustrative embodiment, the columns represent the following:

[0044] English Baselvl represents the CMVC “baselvl” English file utilized to help determine the file choice for the build;

[0045] NLS Baselvl is the CMVC “baselvl” NLS translated file;

[0046] Force indicates if the file was forced. If so, then the yes character “Y” appears in this field. A file force means that the tool has found a file that is down-level, but the user requested the translated file;

[0047] Release gives the CMVC release name of the file chosen to build;

[0048] Current Version gives the CMVC version of the file being utilized; and

[0049] Path Name provides the CMVC source name of the file.

[0050] In the illustrative embodiment, each line of the SHOWBLD report has a corresponding line number. The SHOWBLD.RPT line numbers represent a particular report. Following is an explanation of each line number:

[0051] Line1: Translated file matches English file (0=0);

[0052] Line2: Translated file matches English file (11=11);

[0053] Line3: Translated file is down-level from English file (26>25);

[0054] Line4: Translated file matches English file (blank=blank);

[0055] Line4: Blanks or empty strings are equal to zero (blank=0);

[0056] Line5: Error—the translated file is greater than the English file (16<967); and

[0057] Line6: The dash in the “baselvl” field indicates that no translated file exists.

[0058] In the next illustrative embodiment, a merge report is created by the showbrk tool. The output file contains the merged report output of the release “c.piitool.en” and “c.piitool.fr.” In this illustrative embodiment, the files merged is created utilizing a typical. CMVC query such as:

[0059] Report -general fileview -select “pathname, releasename, compname, nuversionSID, basevid” -where “releasename=‘c.piitool.en’ and dropdate is null”

[0060] This yields the following output:

[0061] English files

[0062] . . . . . . . . . . . . . . . . . .

[0063] mri/en/aaaa.txt¦c.piitool.en¦nls¦1.1¦26*

[0064] mri/en/bbbb.txt¦c.piitool.en¦nls¦1.1¦12

[0065] mri/en/cccc.txt¦c.piitool.en¦nls¦1.1¦16

[0066] mri/en/dddd.rc¦c.piitool.en¦nls¦1.1¦

[0067] mri/en/eeee.rc¦c.piitool.en¦nls¦1.1¦

[0068] mri/en/ffff.rc¦c.piitool.en¦nls¦1.1¦

[0069] mri/en/gggg.rc¦c.piitool.en¦nls¦1.1¦

[0070] mri/en/hhhh.rc¦c.piitool.en¦nls¦1.1¦

[0071] mri/en/iiii.rc¦c.piitool.en¦nls¦1.1¦

[0072] mri/en/jjjj.rc¦c.piitool.en¦nls¦1.1¦

[0073] mri/en/kkkk.rc¦c.piitool.en¦nls¦1.1¦

[0074] mri/en/llll.dlg¦c.piitool.en¦nls¦1.1¦42

[0075] mri/en/mmmm.dlg¦c.piitool.en¦nls¦1.1¦43

[0076] mri/en/nnnn.dlg¦c.piitool.en¦nls¦1.1¦*

[0077] mri/en/wwww.acs¦c.piitool.en¦nls¦1.1¦22

[0078] mri/en/xxxx.acs¦c.piitool.en¦nls¦1.1¦22

[0079] mri/en/yyyy.acs¦c.piitool.en¦nls¦1.1¦22

[0080] mri/en/zzzz.acs¦c.piitool.en¦nls¦1.1¦28*

[0081] mri/en/zzzzmore.end¦c.piitool.en¦nls¦1.1¦

[0082] French files in a mocked sparse tree

[0083] . . . . . . . . . . . . . . . . . . . .

[0084] mri/fr/aaaa.txt¦c.piitool.fr¦nls¦1.1¦25*

[0085] mri/fr/bbbb.txt¦c.piitool.fr¦nls¦1.1¦12

[0086] mri/fr/cccc.txt¦c.piitool.fr¦nls¦1.1¦16

[0087] mri/fr/llll.dlg¦c.piitool.fr¦nls¦1.1¦42

[0088] mri/fr/mmmm.dlg¦c.piitool.fr¦nls¦1.1¦43

[0089] mri/fr/nnnn.dlg¦c.piitool.fr¦nls¦1.1¦12*

[0090] mri/fr/oooo.inp¦c.piitool.fr¦nls¦1.1¦22

[0091] mri/fr/pppp.inp¦c.piitool.fr¦nls¦1.1¦22

[0092] mri/fr/qqqq.inp¦c.piitool.fr¦nls¦1.1¦22

[0093] mri/fr/rrrr.inp¦c.piitool.fr¦nls¦1.1¦22

[0094] mri/fr/ssss.inp¦c.piitool.fr¦nls¦1.1¦22

[0095] mri/fr/tttt.inp¦c.piitool.fr¦nls¦1.1¦22

[0096] mri/fr/uuuu.inp¦c.piitool.fr¦nls¦1.1¦22

[0097] mri/fr/vvvv.inp¦c.piitool.fr¦nls¦1.1¦22

[0098] mri/fr/xxxx.acs¦c.piitool.fr¦nls¦1.1¦22

[0099] mri/fr/yyyy.acs¦c.piitool.fr¦nls¦1.1¦22

[0100] mri/fr/zzzz.acs¦c.piitool.fr¦nls¦1.1¦22*

[0101] mri/fr/zzzzlast.end¦c.piitool.fr¦nls¦1.1¦

[0102] mri/fr/wwww.acs¦c.piitool.fr¦nls¦1.1¦22

[0103] In the preferred embodiment, the “*” in the output shows where a mismatch or error occurred in the merge process.

[0104] In one illustrative embodiment, the PIIFILE Tool is utilized with the following command line: piifile -checkin src\itools\piitools\showbrk.cmd -release c.piitool.en -fam os2-defect #

[0105] In the preferred embodiment, if the PIIFILE does not know how to handle a CMVC function (for example, “-extract” and “-resolve” commands), then the commands are passed to the CMVC “file” command. A list of the CMVC functions handled in one embodiment of the “piifile” includes:

[0106] -checkin=>updates the “baselvl” field by one;

[0107] -create=>creates a default “baselvl of 1;

[0108] -undo=>backs out defect and decrements baselvl;

[0109] -verify=>check release to ensure valid baselvl fields exist;

[0110] -unbump=>reverse action of option “-modify”;

[0111] -show=>displays fileview information plus shows entire baselvl field;

[0112] -modify=>updates the “baseLvl” field; and

[0113] -undo=>“piifile” will undo defect then decrement the “baseLvl” by one.

[0114] The “modify” function has some considerations in updating the baselvl field. In the preferred embodiment, the “-baselvl” option must exist; otherwise, piifile passes the command line to the CMVC “file” command with no changes. A “-baselvl” option with no value will set the file's “baselvl” field to zero. If a file has an existing “baselvl” field, then the existing “baselvl” field is incremented by one. Also in the preferred embodiment, the “-force” parameter is utilized when the user wants all files to be set to the value entered on the “-baselvl” regardless of existing values.

[0115] “Piifile” will accept files from Standard-In (“stdin”) or the keyboard input in the same manner as the CMVC “file” command. In the preferred embodiment, the CMVC “file” command “stdin” switch is the “-” character. This switch must also be utilized with “piifile”. For example, to read files from the file CHANGE.IN the syntax would be:

[0116] piifile -modify - -release c.piitool.en -family os2 -baselvl 6 -force<change.in

[0117] In the previous syntax, if a developer wanted to type files from the keyboard, the “<change.in>” is omitted and the file names are manually typed in. To close “stdin” after the name has been typed, the user enters <Ctrl-Z>.

[0118] In one embodiment of the present invention, where “piifile” doesn't recognize the CMVC function entered, “piifile” attempts to pass the command along to the CMVC “file” command for processing. If the user has chosen to use the standard in switch ‘-’, “piifile” is unable to pass “stdin” handle to the CMVC “file” command and returns an error to the user.

[0119] In the preferred embodiment, a typical CMVC “baselvl” field format looks like this:

[0120] “4_—1.20,3_—1.8,2_—1.5,1_—1.1”

[0121] In the previous example the “baselvl” field contains four baselvl entries. Following is the format of one “baselvl” unit, for example: 4_—1.20, where:

[0122] “4”=“baselvl” value;

[0123] “_”=Separates the “baselvl” value from the CMVC version number;

[0124] “1.20”=The CMVC version control number (when the “baselvl” was recorded); and

[0125] “,”=Commas separate individual “baselvl” units.

[0126] Also in the preferred embodiment, the CMVC “baselvl” field specifications includes the following characteristics:

[0127] 1. The latest “baselvl” value is at the head of the field. The example shows the current “baselvl” is “4”;

[0128] 2. The CMVC default value for the “baselvl” is a NULL string;

[0129] 3. The “baselvl” field cannot be set with a NULL string;

[0130] 4. Zero and NULL are both equal values, i.e., 0=“ ”;

[0131] 5. The “baselvl” field is an alpha-numeric entry field;

[0132] 6. Use the character “_” to separate baselvl value from CMVC version ID, with no whitespace;

[0133] 7. The “baselvl” units need to be separated by commas. Leave no whitespaces;

[0134] 8. New entries are always added to the head of the field;

[0135] 9. If needed, oldest entries are scrolled from end of field to ensure room for newest “baselvl” unit;

[0136] 10. The “baselvl” units cannot be removed from the middle of a field, only beginning or end units may be removed; and

[0137] 11. The “baselvl” values must be integers.

[0138] The invention when implemented with SHOWBRK provides sparse tree support under CMVC. However, some files are not translated for all countries and some PII files do not have PII text. Further, MRI builds are reproducible utilizing the SHOWBRK blueprint file. The SHOWBRK tool also eliminates the complexity of delta builds. Most importantly, the invention provides that ability to identify and fix build problems prior to build entry (e.g., English MRI is newer than translated text). Additionally, the invention identifies MRI mismatched files and assists NLV planning by providing real-time PII reports during all phases of the project. Finally, it eliminates NLS linking performance issues.

[0139] The following illustrative example explains the user interface during the implementation of the invention. In this illustrative embodiment, the history of two files (FOO.C EN and FOO.C FR) is tracked as they proceed through a NLS build cycle:

[0140] Initially, the French FOO.C file is at version identification (vid) 1.1. The “baselvl” field is blank. The English FOO.C file fields are: vid=1.5, “baselvl”=15. The French file “baselvl” field is downlevel which, in the preferred embodiment, indicates the file needs to be translated (France baselvl: 0<15 English baselvl).

[0141] The NLS group, utilizing a tool named PIISHIP, extracts this file (and others if needed). PIISHIP creates a control file for each shipment and marks the control file with the proper information for the “baselvl” of the FOO.C, which is based off the English file “baselvl”=15.

[0142] In the illustrative embodiment, a non-translation type correction was made to the English version of FOO.C moving the vid to 1.6. In the preferred embodiment, this correction and other such typical minor “typo” errors do not require a translation effort; hence, the baselvl” of the EN FOO,C file stays at baselvl=15.

[0143] Once the PII package from France returns, the file is checked into CMVC. In the illustrative embodiment, the French FOO.C vid is now 1.2 and the tool PIISHIP changes the French “baselvl” field to the value stored in the PIISHIP CONTROL file to baselvl=15.

[0144] In the illustrative embodiment, the last entry in the table for the English FOO.C file shows the vid at 1.10. This shows that four more development deltas were applied to the EN FOO.C file, and none of those changes required a translation. Thus, in this illustrative embodiment, the “baselvl” field remains at 15.

[0145] Development deltas refer to the log of each file which represents an upgrade of a software application. During a standard development process hundreds of deltas may be developed. Only some of these delta involve changes which are important to national language builds. The invention is able to check the development deltas and extract the most recent deltas during its extraction stage. This greatly reduces the time required to check the files in the database. The previous methods would have to analyze all of the development deltas to complete such a determination.

[0146] Merging of releases is a next important aspect of the present invention. During the merging process, a file in the development language release is merged with a file in the target build language (eg. English with French.) A final run is made which results in a final report being generated which compares the two releases. The PII Tool examples below show how the tool merges releases.

[0147] The following example shows how the tool makes decisions on the “baselvl” fields. In this illustrative embodiment, the file being evaluated is “release” FR FOO.C, baselvl=1.2. FR FOO.C baselvl is checked against the English baselvl.

[0148] In this illustrative embodiment, the FR file is utilized because it is the same “baselvl” as the English file. This means the FR file will not cause a build break.

[0149] Another illustrative example is presented below.

[0150] In this illustrative embodiment, the evaluation results in baselvl's not being equal or matching. When this occurs, in the preferred embodiment, the English file is utilized because the FR baselvl is downlevel. This means the FR file could possibly cause a build break.

[0151] In the preferred embodiment, the vid's and “baselvl” fields are not entered or maintained by the user of the tool. The fields are automatically updated by the tool when the files are “checked in” to the library control system.

[0152] Returning now to the figures, FIG. 2 depicts a flow chart of the build process in which one embodiment of this invention is implemented. The process begins (step 201) when the developer seeds the build tree (step 203). Seeding the build tree involves getting sets of files from language objects within CMVC. Files in the English version and the Japanese version of an application, for example, may be utilized. The tool is then run which completes the merging of files (step 205). In the preferred embodiment, running the tool requires running the BLDEXT.CMD algorithm and the BLDSPC.CMD algorithm. BLDEXT.CMD creates a superset of all combined files while BLDSPC.CMD creates a subset of the files which representing those files which require a translation. The features associated with the running of these algorithms are described above in detail. The tool then determines if there are MRI mismatches(errors) (step 207). This shows if there are potential breaks in the build due to files being downlevel and requiring translation. If there are MRI mismatches, then the tool permits the developer to determine whether or not to send the downlevel files to the MRI for translation (step 208). A developer may choose to do so and the files are sent to the NLS where they are translated (step 210). Once translated, the PIIFILE tool checks the file into CMVC which results in the files baselevel being automatically updated and stored (step 212). In the preferred embodiment, a control file monitors the files being sent for translations. When the file returns, the tool checks it into the CMVC and the control file gives the translated file the same baselevel as that of the first language file. A developer may decide not to send the files to MRI. In this case, the MRI files are fixed or the build is completed with the first language file (step 209). When this occurs or when there are no MRI mismatches, the files are then physically extracted and placed on a staging area or server (step 211). The staging area is a memory location or sever which may be overwritten with data and accessed by a build machine. In the preferred embodiment, the staging area is connected to the library system (CMCV) with a high speed wire. Although the above process has been shown to include decision steps, an alternative embodiment of the invention allows the process to be completed without external decision making. In such an embodiment, the process is fully dynamic and runs from (step 205) directly to (step 209).

[0153] In the preferred embodiment, the entire process occurs within the database and the tool conducts database queries and produces reports of all the files that fit a given criteria. No physical extraction occurs until the staging step in the process. The extract objects of the tool is a report of the extraction package which contains the combined language files. Developers may force a break by selecting files which are not latest versions. Further, the invention may be instantiated at any time without continuing on to a build stage. In FIG. 2 the process of continuing to the build stage is shown. Once the files are written on the staging area (step 211), they are then utilized to build the application (step 213) before the process terminates (step 215).

[0154] While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. For, example, while the invention has been describe with references to a single second human language, it is understood by those skilled in the art that the invention permits the updating of all language sets automatically.