OASIS标准组织正在制定的Translation Web Service就是基于以上设想制定的国际本地化行业新标准，它的目标是“任何需要翻译服务的内容出版商都可以使用Internet自动地连接和使用翻译服务商提供的服务，不再需要像以前那样双方直接交流。Translation Web Service为解决大型项目的本地化带来了可能的解决技术，通过规范文件内容和格式，采用Internet上特定本地化的后台服务程序，本地化服务商和客户可以把本地化流程实现自动化，客户可以直接把项目采用计算机网络自动发到Vendor，自动化与以前的翻译内容进行匹配和预处理，随时浏览项目的执行进度状态。翻译服务商可以根据Web Service完成文件的本地化，本地化后的文件可以自动化的保存在设定的位置，从而彻底降低了项目管理的难度，节省了本地化成本。我个人认为，Idiom 公司开发的Worldserver本地化管理系统是根据这个标准的思想设计的，这将是未来本地化项目管理系统和内容管理系统发展的方向。
OASIS Translation Web Service技术委员会的成员来自Idiom Technologies, Inc，Localisation Research Centre，National Information Society Agency，Product Innovator Ltd.，SDL International和XML Intl.
以下是关于这个标准的详细介绍（摘自OASIS网站）。有关Translation Web Services标准开发的最新进度情况，请阅读2007年5月16日发布的“Translation Web Services - draft committee specification”，网址是http://www.oasis-open.org/committees/download.php/24350/trans-ws-spec-1.0.3.html。
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
OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries.
OASIS is distinguished by its transparent governance and operating procedures. Members themselves set the OASIS technical agenda, using a lightweight process expressly designed to promote industry consensus and unite disparate efforts. Completed work is ratified by open ballot. Governance is accountable and unrestricted. Officers of both the OASIS Board of Directors and Technical Advisory Board are chosen by democratic election to serve two-year terms. Consortium leadership is based on individual merit and is not tied to financial contribution, corporate standing, or special appointment.