Web Services for Translation

By Peter Reynolds

Bowne Global Solutions &
OASIS Translation Web Services Technical Committee

Founded in 2003, OASIS’s Translation Web Services Technical Committee has been actively pursuing standards to facilitate communication between partners in the localization process and help eliminate some of the most time-consuming management tasks that those involved in localization face. In this article Peter Reynolds, chair of the Technical Committee, discusses the rationale for Translation Web Services, the evolving specification, and future plans to extend the benefits of Web Services to all those involved in localization.

Building and managing multilingual Web sites or other applications involves many interrelated and complex tasks. Publishers may have databases, content management systems and other tools which enable them to manage their original content, while vendors may have systems to manage translation such as translation memory systems, terminology tools and project management systems. Wonderful flowcharts can be presented to show how all these systems work together, but system A on the publisher side and system B on the vendor side rarely work together as smoothly as simple diagrams indicate: while the flowchart might show a straight line from one system to another, the reality is that files are being transferred by FTP, e-mail, or other means, while instructions are being communicated between the various parties through a variety of inconsistent means, including verbal instruction, e-mail, read-me files.

Web Services is an answer to the problem of systems integration. It uses Internet technologies to allow computer-based systems to communicate and transfer data in a seamless and automated manner. Web Services are currently being adopted by many companies and industries, and over the next few years will increasingly automate processes and integrate systems. The OASIS Translation Web Services Technical Committee is creating a standard way for Web Services to be used within the translation and localization industry. This article describes the Web Services technology and provides a real life case study showing how it is now being used.

The idea of a standard for Web Services within translation was first put forward by Bill Looby of IBM in Limerick, Ireland at the eLocalisation 2001 conference. Mr. Looby delivered a paper which showed a vision of how the industry could benefit from a common way of using this technology. The conference also included a practical demonstration of how Web Services were already being used: Bowne Global Solutions (then Berlitz GlobalNET) gave a demonstration of work being done for the 2003 Special Olympics Web site, which it sponsored. Using Web Services, an XLIFF (XML Localization Interchange File Format) file was sent from the Web site to Elcano, Bowne’s online translation service, and back to the Web site.

This conference ended with a small group of people getting together to look at how they could progress with the idea of using Web Services within the translation industry. The steering group formed at that time decided that OASIS, as the standards body most involved with Web Services, would be the natural home for their efforts. OASIS was established in 1993 and is focused on XML standards for the IT industry. XLIFF was already being developed by an OASIS Technical Committee, and there was considerable support for the localization industry within OASIS. The OASIS Technical Committee was formed at the beginning of 2003 and members included representatives from Oracle, Microsoft, IBM, Connect Global Solutions, thebigword, LISA, LRC, and Bowne Global Solutions, as well as individual members.

What is Web Services?

Before detailing the main features in the draft specification from the Translation Web Services Technical Committee, I would like to give some background on Web Services. The World Wide Web is a collection of interlinked documents which sits on the Internet, a huge computer network. Traditionally Web sites were accessed by a person at a computer, who viewed pages with a Web browser. With Web Services, in contrast, the Internet is used for machine-to-machine communication, rather than for machine-to-person communication. Protocols such as HTTP and standards such as XML and SOAP are combined in Web Services to enable this machine-to-machine communication, enabling different systems to work together and allowing for more powerful functionality and automation.

A simple example of a Web service shows how a home gardener might use a web service to automatically water his garden while he is on vacation. If a weather forecasting company created a Web service and allowed it to be accessed, weather forecasts could be queried by remote computers all over the Internet, based on an XML document called a WSDL (Web service definition language) that describes the services available and what parameters will be sent and received for each of these calls. A protocol called SOAP (simple object access protocol) handles the queries themselves, and while the gardening enthusiast is away, his computer could query the web service to determine if it will rain that day, and control his water sprinkler accordingly.

Translation Web Services

Since January 2003, the Translation Web Services Technical Committee has been working to create a standard way for Web Services to be used in a multilingual context. It has concentrated on creating a standard relating to the communication between publisher and vendor companies. At the simplest level this will allow for translation and other work to be sent by the publisher to the vendor and, once translated, sent back. The draft specification covers the following areas:

Service support.The service support functionality allows queries concerning which languages and types of work the vendor offers through Web Services. Web Services allows for the use of a directory of available and registered services called a UDDI, which can be used in conjunction with service support functionality.
Translation and request quote. These are the calls which enable the publisher to submit documents and receive quotes. Documents can be submitted either after a quote has been requested and received or as part of an ongoing relationship where the cost of any individual job will be known to the publisher. The quote is based on information such as the language pairs, what sort of work is to be performed, and the size of the documents.
Status, notification and delivery. These calls enable the publisher to query the vendor’s Web Services and determine the status of documents. Document status could be automatically polled at regular intervals to provide status information. When the status changes to “complete,” the documents can be delivered.
Reference files. In the translation process, reference material such as translation memories, previous translations and glossaries are essential tools for translators. These calls allow for the association of reference material with a particular job.
Security. The draft specification requires security around identification and data transfer. Identification provides a way to authenticate each party via security tokens such as username/password, Kerberos tickets or x.509 certificate. Data transfer security could be achieved using SSL (Secure Socket Layer). It is the intention of the Technical Committee to stay current with the work of the OASIS WS-Security group and, where appropriate, implement its recommendations.

Web Services in Action

Although the specification from the Translation Web Services Technical Committee is still at the draft stage, there has been some significant work done with Web Services in the translation industry. Bowne Global Solutions has implemented a number of solutions based on Web Services which have linked content management and other systems with Elcano, its online translation portal.

The diagram above shows a solution which was built for a large chemical company. Its translation process was time-consuming and error-prone. The process required more than forty separate manual steps for each file to be translated. This led to a localization process that was not cost-effective and where delivery to target markets was unnecessarily delayed.

Working together with the company and its systems integrator, Bowne was able to propose a solution to standardize and automate parts of the process, reduce the manual effort required, and provide a more cost-effective and time-efficient way to translate the content stored within the TeamSite CMS (Content Management System).

The solution BGS proposed to the company was to connect Interwoven’s TeamSite to Elcano™. Elcano offers a Web Services interface providing simple and direct programmatic access to Elcano from any CMS or content repository. The Elcano Web Services solution makes use of two language industry standards - both under the auspices of OASIS. XLIFF defines the structure of translation data, and Translation Web Services defines the communication between TeamSite and Elcano. Using these data transfer standards to connect to Elcano allows source content of any type to be posted directly into Bowne’s translation production process, its status to be tracked from the CMS during translation and, for completed translations to be retrieved without unnecessary manual intervention. In addition, once extracted from the CMS, BGS can make use of a variety of translation productivity tools to ensure the consistency, accuracy, and timeliness of the translation.

Conclusion

The idea that companies which are competing aggressively with each other should come together and put considerable effort into agreeing on a common standard might be a curious one. However, there are many examples where creating an industry standard benefits everyone. Companies as large as IBM, Oracle and Microsoft have recognized that there are areas where they benefit greatly by working on common standards. Within our industry, standards such as XLIFF and TMX have greatly helped us in our work. The Translation Web Services standard provides the road whereby a customer can travel to the various vendors. Making it possible to relatively easily change vendors ensures that the power is with the customers. All vendor companies want a long and successful relationship with their clients, but this should be based on their adding value to the customers work and not the fact that it is difficult to change from one vendor to another.

Translation Web Services will work with other standards by providing them with the means of transferring content. In the case study above I showed how Bowne was extracting an XLIFF file from a database. The view taken by the committee has been to use other standards where appropriate rather than re-inventing something which has already been done well by someone else. Where appropriate, other Web Services standards such as Web Services Security will be used within this standard, and localization standards such as XLIFF or TMX can be transferred using the standard.

The Translation Web Service standard Technical Committee has just completed (May 2004) a face-to-face meeting which was held in the Dublin offices of Bowne Global Solutions. During this meeting, the committee agreed on a draft specification which will, after a review period, be proposed as a committee specification. This is the first step towards it becoming a standard which can be used within the translation industry. The roadmap for achieving this is for the committee specification to be agreed to by the beginning of the summer. After there has have been a number of implementations, we will start the work in the autumn to make it an OASIS standard.

Peter Reynolds works in Bowne Global Solutions Dublin office as manager of the software development team. His team is responsible for developing some of the software which BGS uses to run its business. Peter is secretary of the XLIFF technical committee, and chair of the Translation Web Services technical committee, and has been active in both since their inception. Peter holds an MBA from the Open University.