|
The original Call For Participation for this TC may be found at http://lists.oasis-open.org/archives/tc-announce/200211/msg00006.html
The charter for this TC is as follows.
Name
Translation Web Services
Statement of Purpose
Many translation and localisation projects involve a multiple of complex tasks carried out in different countries by different companies. The management of this is a very complex business. Determining the cost of a software localisation project involves sending files, data, and other information to different companies to get information on their estimated charges. As the project progresses a lot of time is spent by project managers chasing up status information from the various vendors. Even receiving the translated files can be cumbersome with the project manager having to collect files from different ftp servers.
The need for 'Joined-up localisation' has long been a dream of many in the translation industry. Why is it not possible to automate much of these processes? Why can't the Web be used to transfer data and information effectively without contant human intervention? Why can't Project Managers see a project's status on a single screen regardless of which vendor is used? However these efforts remained dreams as the technology was not there to provide 'Joined-up localisation'. Web Services has changed that. By allowing computer to computer communication over the Internet, automation of many localisation processes is now possible. A publisher of software or documentation could use Web Services to get not just one quote but multiple quotes for different tasks and from different vendors. Web Services could be used as the backbone to a workflow automating the links between the different tasks that comprise a complex software localisation project. And reporting project management information from a number of sources into one consolidated screen at the customer's computer is possible with the aid of Web Services.
The Translation Web Services TC proposes to define a standard that provides an encapsulation of all the information required to support the following value proposition through the framework of the Web Services intiative: "Any publisher of content to be translated should be able to automatically connect to and use the services of any translation vendor, over the internet, without any previous direct communication between the two".
Web services connect tools and suppliers automatically without the need for direct communication. Articles or sections from web sites will find their way to the translator fully automatically. No phone conversations, no faxes, no FTP, no emails (except perhaps automatically generated emails). Translation memory matches will be retrieved fully automatically from anywhere in the network. And for real-time translation the web services architecture will fully automatically route texts to a machine translation engine. No pre- and post-processing, no translation folders and no so-called translation engineering. Web services allow us to build the intelligence into the infrastructure, in standard definitions that communicate openly with any tool and any supplier that comply with the standard.
At the core of a localisation Web Service is the ability for publisher to submit content that requires translation, request quotes for service and/or request other services from vendors 1, 2 and 3 and for each party to understand what the other is asking of them. To do this the, metadata used within a localisation Web Service must be standardized and publicly published. Therefore, a key objective of the Translation Web Services TC will be to establish a set of business process terminology that the software/content localisation and translation industries shall find to be comprehensive and complete. For example it is possible that a publisher would like a document translated and wants to use Web Services to achieve this. One vendor could use the text 'translation' for the translation task, another might use 'trans' another 'trns'. The TWS business process terminology specification will ensure that when a publisher submits a document to be translated they use one set of terminology that is universally understood by all vendors providing the service.
In its simplest generic form, a Web Service is comprised of a service application, a client application and a UDDI registry. An example of a localisation web service application might be a service that provides online translations. The interface to this application is opened over the Internet using SOAP (Simple Application Access Protocol) and details of the interface are published in a .WSDL (Web Services Definition Language) file. This WSDL file is published to the UDDI registry. The client application searches the UDDI for an appropriate service and finds the published WSDL, which provides the publisher with information about how to access the service over the Internet.
Web Services have recently become a popular and effective method for distributing automated business processes over the Internet. However, the benefit of Web Services is significantly minimized if a publisher must rewrite their corporate Web Services in order to talk to new or added localisation vendors who have their own incompatible Web Services. The TWS TC is proposing to lead the software and content localisation and translation to define industry standard business process terminology which will then drive the development of an industry standard WSDL file and UDDI businessservice entries.
The first phase of the workgroup will be to define the service types that are relevent to the software/content localisation and translation industry. These will be defined and published within a specification with a public call for comment.
The second phase will be to define the service types in the first phase, and describe them with service interface definition WSDL documents. This will be done for each of the areas covered. For example human translation services may have a separate WSDL to machine translation services.
During the third phase, the WSDL documents will be published as UDDI tModels with the overviewDoc field in each of these tModels pointing to the relevant WSDL documents.
Relationship with XLIFF
The Translation Web Services TC is working within the same industry as the OASIS XLIFF TC and it is hoped that there will be a close working relationship between the two TCs. It is likely that XLIFF will be one of the formats which is transported using Web Services based on the work of the Translation Web Services TC but it will not be the only format and the TC will not presume that XLIFF will be used.
List of Deliverables
- TwS 1.0 TWS Business Process Terminology Specification; 12 weeks after 1st meeting
- TwS 1.0 WSDL Documents; 20 weeks after 1st meeting
- TwS 1.0 UDDI Deploy WSDL as UDI tModels; 24 weeks after 1st meeting
|
