Method and process to automatically perform test builds of translated files for a software product

A method, apparatus, and computer program instructions for automatically performing test builds of natural language translated files for a software product. When a translated file is received from a translator, a test build of the translated file is executed in a translation test build environment, wherein the translation test build environment is separate from the main software product build environment. A determination is made as to whether the test build of the translated file is successful. If the test build is successful, the translated file is submitted to the main software product build environment. If the test build is unsuccessful, a log file containing error information is sent to the translator to allow the translator to fix compile errors identified in the translated file and resubmit the translated file to the translation test build environment.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to an improved data processing system and, in particular, to multiple language program development. Still more particularly, the present invention provides a method, apparatus, and computer program for automatically performing test builds of natural language translated files for a software product.

2. Description of Related Art

In a typical software development environment, software products are created in one particular language. At a later time, these software programs may be adapted to operate in a market or country other than the one for which it was originally designed. In order to “localize” the software product, translators are used to translate the software products and adapt the software to ensure the most current use of technical terminology and local norms and idioms.

Natural language translation of software products is difficult, as it is compounded by a number of factors. The setting of an application lies in the interfaces that communicate with the user. As the text that is to be translated is disassociated from the interface and moved into resource files, a translator may have little experience with the program content and the actual interfaces from which the context is derived. As a result, certain key elements in the resource files, when incorrectly translated, can cause product build breaks.

Because translators are not normally software developers and typically do not work in a software development environment, translators do not always have the tools or skills available to ensure that the files they are translating will not break product builds when the translated files are incorporated into the build. Build breaks, when they occur, negatively impact software product release schedules, as well as increase the cost of development of the product.

Therefore, it would be advantageous to provide a mechanism for automatically performing test builds of translated files for software products in multiple natural language application development.

SUMMARY OF THE INVENTION

The present invention provides a separate, simplified, remotely accessible, and automated build environment for natural language translators to use. The build environment of the present invention provides for automatically performing test builds of translated files for a software product. When a translated file is received from a translator, a test build of the translated file is executed in a translation test build environment, wherein the translation test build environment is separate from a main software product build environment. A determination is made as to whether the test build of the translated file is successful. If the test build is successful, the translated file is submitted to the main software product build environment. If the test build is unsuccessful, a log file containing error information is sent to the translator to allow the translator to fix compile errors identified in the translated file and resubmit the translated file to the translation test build environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the depicted example, server104is connected to network102and provides access to storage unit106. In addition, clients108,110, and112are connected to network102. These clients108,110, and112may be, for example, personal computers or network computers. In the depicted example, server104provides data, such as boot files, operating system images, and applications to clients108-112. Clients108,110, and112are clients to server104. Network data processing system100may include additional servers, clients, and other devices not shown.

Software developers may provide application source and resource files at a client, such as one of clients108,110,112. These files may be stored at the client workstation or at a server. For example, application source and resource files may be stored in storage106. Server104may facilitate access to the files in storage106using, for example, File Transfer Protocol (FTP) or HyperText Transfer Protocol (HTTP).

Application files may be provided to a natural language translator at a client, which may be another one of clients108,110,112. The translator may receive application files through, for example, direct file transfer, electronic mail, or by download from server104.

However, once the software files are translated, translators do not currently have a testing environment to test the translated file for potential compiling problems. Since natural language translators are not normally software developers and typically do not work in a software development environment, these translators do not have the tools or skills available to ensure that the files they are translating will not break product builds when the translated files are incorporated into the build.

For example, when a translator receives a text string for translation, the translator may open and edit the file with any text editor. The translator translates the text, and then sends the translated file to the server to be incorporated into the product build. If the translated file containing an error is incorporated into a product release, when a build is performed on a product release, the translated file can result in a compiler break. When a break occurs, the translator must fix the translated file and resubmit the file into the product build. The back and forth iteration between the translator and the server to fix compile errors and achieve a successful product build is labor intensive.

The present invention overcomes this problem by providing an automated test build environment for natural language translators of software products to use. The present invention provides a mechanism for automatically performing a test compile on a translated file prior to accepting the file from the translator and integrating the translation into the product build. Although the individual components used in the present invention may be conventional devices, the combination of these components to form an automated test build environment is unique and original for the applicable software development environment.

The automated test build environment is separate from the main build environment where the base software product is built; any compile problems encountered during the test build of the translated file will not affect the base product. In addition, the build environment is simplified as it may be customized to only build the translated material supplied by the translator. Consequently, the natural language translated material should build very quickly.

Furthermore, for the convenience of translators, who are typically located in different countries, the test build environment of the present invention is remotely accessible via a Web browser. Thus, a translator at any location may access the test build environment through the translator's Web browser. In addition, the test build environment is automated and available at all times to accommodate work hours from any time zone.

With reference now toFIG. 3, a block diagram illustrating a data processing system is depicted in which the present invention may be implemented. Data processing system300is an example of a client computer. Data processing system300employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor302and main memory304are connected to PCI local bus306through PCI bridge308. PCI bridge308also may include an integrated memory controller and cache memory for processor302. Additional connections to PCI local bus306may be made through direct component interconnection or through add-in boards.

In the depicted example, local area network (LAN) adapter310, SCSI host bus adapter312, and expansion bus interface314are connected to PCI local bus306by direct component connection. In contrast, audio adapter316, graphics adapter318, and audio/video adapter319are connected to PCI local bus306by add-in boards inserted into expansion slots. Expansion bus interface314provides a connection for a keyboard and mouse adapter320, modem322, and additional memory324. Small computer system interface (SCSI) host bus adapter312provides a connection for hard disk drive326, tape drive328, and CD-ROM drive330. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

As another example, data processing system300may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system300comprises some type of network communication interface. As a further example, data processing system300may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.

Turning next toFIG. 4, a block diagram illustrating components used in test compiling translated files for a software product prior to accepting the files from translators is depicted in accordance with a preferred embodiment of the present invention. Clients402,405, and417are examples of a client, such as clients108,110, and112inFIG. 1. Clients402,405, and417may be executing on a data processing system, such as data processing system300inFIG. 3. Web servers404and405are examples of a server, such as server104inFIG. 1. Web servers404and405may be executing on a data processing system, such as data processing system200inFIG. 2.

A translator triggers the automated test build process of the present invention by submitting the translated file to Web-based application for remote file management408. In this illustrative example, Web-based application for remote file management408is located within Web server404. Web-based application for remote file management408may provide the only interface with which the translator needs to interact. It hides the complexities of the configuration components used to build and store software product releases, as well as the automated test build environment. One example of such a Web-based application is Web File Management (WebFM), a product developed by International Business Machines Corporation. WebFM enables the remote manipulation of files using a standard Web browser interface. Examples of such file manipulations include the check-in of files into a configuration management tool, file naming, and path substitutions. WebFM also performs static analysis on file contents, such as file encodings.

In this example, a translator at client402first connects to Web server404using a universal resource locator (URL) to establish the Web server identity by reference. The translator at client402then submits a translation to Web server404. The translation submission may take many forms, such as a zip, hex, tar, tpt, or any other archive package of individual files. The submission contains translated text of a software product. The submission of translations is facilitated through Web-based application408. For example, when the translator is ready to send the translation, the translator may select a “submit files” button provided by the Web-based application to send the translation to Web server404.

When Web-based application408in Web server404receives the translated text, Web-based application408automatically checks the translation into a configuration management tool. In this illustrative example, configuration management tool is hosted in a client machine, such as client405. Configuration management tool406may be any configuration management product that allows for retaining versions of individual files and recording configurations of product releases. Configuration management tool406is used to retain versions of individual files and record exact configurations of larger software entities such as product releases. An example of such a configuration management tool is Configuration Management Version Control (CMVC), a product of International Business Machines Corporation.

Configuration management tool406comprises, in this illustrative example, permanent release component412and staging release component414. Permanent release component412is used to retain accepted translations. Staging release component414is used to retain translations submitted from the translator prior to the translations being accepted into permanent release component412. When a translation is received from client402, Web-based application408checks the translation into configuration management tool406under staging release component414. It should be noted that those of ordinary skill in the art will appreciate that the present invention is not limited to configuration management systems with release component schemas. For example, rather than having a translation reside in a release component in the configuration management tool as described above, a translated file may simply exist in a staging directory in a file system, awaiting build results.

When Web-based application408receives the translated text, Web-based application408also automatically interfaces with build environment410. Build environment410comprises build automation system416and build machine418. Build environment410is separate from the main build environment and may be used to build only those translations submitted by the translators.

Build environment410is made transparent to the translator by Web-based application408and may be customized to only build the translated material supplied by the translator. A test build of the submitted files is automatically scheduled by Web-based application408. As build environment410is isolated from the main build environment where the base software product is built, any compile problems encountered during the build of the translated file will not affect the base product.

In particular, Web-based application408interfaces with build automation system (BAS)416in build environment410and submits a test built request to BAS416for the translations in staging release component414. In this example, BAS416is hosted within a Web server, such as Web server415. BAS416is used to schedule and initiate product builds. Rather than requiring the translator to initiate a test build, the present invention provides a command line interface in BAS416, which is used by Web-based application408to submit the test built request. In this manner, Web-based application408may automatically initiate a test build, thus trivializing that task for the translator.

In response to receiving a build request, BAS416extracts the translations retained in staging release component414in configuration management tool406. BAS416places the extracted translations into build machine418. BAS416then signals build machine418to execute the test build. In this example, build machine418is hosted in an independent client machine, such as client417.

The test build, if successful, means that the translated file will not cause a compiler break when the translated file is incorporated into the main build of the software product. If the test build is successful, BAS416sends a signal back to Web-based application408indicating that the translation is acceptable. In response, Web-based application408checks the translation into configuration management tool406under permanent release component412.

In one embodiment, when Web-based application408receives the signal from BAS416that the test build was successful, the translator is notified through Web-based application408that the translation is acceptable. For instance, in the previous example, a “submit files” button was presented to the translator to allow the translator to send the translation for testing. At this time, a second button, which was disabled prior to the translation test build, is presented to the translator via Web-based application408. The second button, such as a “finish” button, is used to check in the translated files into permanent release412.

If the test build is not successful, BAS416creates a log file of the test build. The log file contains detailed debugging information regarding the unsuccessful build. BAS416sends the log file to the translator at client402. BAS may send the log file to the translator via Web-based application408or via an email notification. The translator may use the log file to fix compile errors identified in the defective translated files, and then resubmit the translations to Web-based application408.

Although the illustrative example inFIG. 4shows Web-based application408and build automation system416hosted in independent servers, and configuration management tool406and build machine418hosted in independent client machines, those of ordinary skill in the art will appreciate that the configuration of these components depicted inFIG. 4may vary. For instance, Web-based application408and build automation system416may be hosted in the same Web server, while configuration management tool406and build machine418are hosted in separate client machines.

In another embodiment, configuration management tool406, Web-based application408, and build automation system416may be hosted in the same Web server, while build machine418is hosted in a separate stand-alone build machine (client). Build automation system416and build machine418still comprise build environment410.

Alternatively, configuration management tool406, Web-based application408, build automation system416, and build machine418may be hosted in the same Web server. However, in practice, this single server configuration may place too many resource demands and constraints on the host machine.

FIG. 5is a diagram illustrating an exemplary user interface that may be presented by Web-based application408fromFIG. 4. In this example, window500is an example of a Web browser window that may be shown on a client, such as clients108-112inFIG. 1. Window500is presented for purposes of illustration and not meant as a limitation as to how translated files and may be presented, translated, and submitted.

In this illustrative example, window500comprises a directory list of translated files being submitted. This directory list allows the translator to view the translated files and select translated files for submission to the server. In an alternative embodiment, not only is the translator able to select a translated file for submission using the directory list, the translator may also be provided with the ability to perform a Web-based natural language translation by allowing the translator to actually translate a file using the interface, or window500. Window500may also contain menu options such as “submit files” button504and “finish” button506. When the translator is finished analyzing a file, the translator may select the translated file in pane502and submit the translation to the Web server (and the test build environment) using a menu option such as “submit files” button504. At this point, since the translation has not yet been accepted by the configuration management tool, “finish” button506is not available to be selected by the translator. For example, the finish button may appear on window500, but may be disabled and not selectable. Alternatively, the finish button may not appear on window500at all.

Once a test build is performed, and if the text build is successful, “finish” button506is enabled on translation window500. In this manner, the translator may only submit the translation to the Web server as “finished” (i.e., to be incorporated into the permanent release) when it has been determined that the translated file will not cause a compiler break. If a test build has been performed and the test build is unsuccessful, “finish” button506remains disabled to the translator. The translator must fix the compile errors in the translated file and resubmit the translation to be tested in the build environment using “submit files” button504.

As can be seen, the translation window of the present invention illustrated inFIG. 5provides the translator with means to submit and finalize translations. Although the example inFIG. 5illustrates a particular display list of translated files and selectable buttons for submitting the translations, it should be noted that any manner of presenting and submitting translations or translation files may be used.

FIG. 6is a flowchart illustrating a process for automatically performing a test build of natural language translated files for a software product in accordance with a preferred embodiment of the present invention. The process illustrated inFIG. 6may be implemented in a distributed data processing system, such as network data processing system100inFIG. 1.

The process begins with a translator submitting a natural language translation to a Web server via a Web-based application, such as, for example, WebFM (step602). The translation is checked into a configuration management version control component such as, for example, CMVC, and placed within a staging release (step604). The Web-based application then automatically interfaces with a build automation system in the test build environment and submits a test build request for the translation retained in the staging release (step606).

Next, the build automation system extracts the translation from the staging release in the configuration management tool (step608) and sends the translation to a build machine (step610). The build machine then executes the test build (step612). A determination is then made as to whether the test build is successful (step614). If the test build is successful, the build automation system sends a signal to the Web-based application (step616) that the translation is acceptable. The Web-based application initiates the move of the translated file from the staging release in the configuration management tool to the permanent release (step618). The Web-based application also notifies the translator that the translated files check-in was successful (step620). This notification may be performed through the Web-based application or via an email notification.

Turning back to step614, if a determination is made that the test build was not successful, the build automation system notifies the translator of the defective submission (step622). The build automation system creates a log file containing detailed debugging information and sends the log file to the translator. In this manner, the translator may use the log file to fix the defective translated file (step624). Once the translation has been corrected, the process returns to step602as the translator resubmits the translation to the Web-based application.

Thus, the present invention provides a method, data processing system, and computer instructions for automatically performing test builds of natural language translated files for software products in multiple language application development. The present invention provides advantages over the current art by providing an automated test build environment that is convenient to use, since it is accessible via a Web browser and is available at all times to accommodate work hours from any time zone. In this manner, the present invention provides translators with an automated testing environment that allows translators to ensure that the files they are translating do not contain potential compilation problems.