It should be apparent from the preceding 'Utopian' description that the most immediately useful Web service is the translation vendor Web service.At its simplest, it allowsthe automatic submission of translatable content to a Web vendor. Essentially, it is the next step in terms of automating job submissions:
- Email submission—generally requires human interaction both to submit and on receipt by the vendor
- Web site-based submission—receipt is automated but a user with a browser still needs to submit
- Web service-based submission and receipt can both be automated
As an interface, it is also equally applicable to human translation, machine translation and translation memory, in the sense that it involves submitting a file (or files) for translation. Obviously the interoperability of these depends on the formats used to present and retrieve the translations. However, if XLIFF is used to submit/retrieve the files, then it should be possible to integrate them smoothly.
The model described in Figure 2. may seem familiar to some readers. In fact there have been several 'application-specific' approaches similar to this already, where a translation vendor would write both the client and the service portion of the system. However, there were several problems with this approach:
- Generally, only a single client is supported
- Single translation vendor supported (no comparison shopping)
- Only worth doing for very large customers
- Customer is locked in to this translation vendor
- Customer is tied in to this process (generally a single process was assumed)
The key to using Web services is the openness of the approach:
- Once the service is published, anyone can write a client
- A client can be written for any process
- The client can talk to any number of vendors who support the service
The details of this service are still very much at the high-level discussion stage. Here is some of the basic functionality that you might expect from a translation vendor service:
- Query support—if you are going to do business with someone by using Web services, need to know what they can provide. This could include a list of language pairs, and possibly some areas of expertise. It might also include the technologies they use (e.g. can you localize my .gif), and what kind of status (see below) can be queried
- Get quote—based on a submitted word-count (or file) and possibly including user identification so that corporate or volume rates can be offered, a total cost can be returned.
- Submit job—initiate translation. At this stage a job identifier should be made available so that its status can be queried.
- Review job status—begun/percentage complete/completed/reviewed. This may depend on the specific vendor. It may be possible to retrieve an entire HTML page for describing the status of a job.
- Get translation—once the translation is complete, it obviously needs to be possible to download the completed translation
- Each service used can be implemented internally or an external service can be used if appropriate and available.
- If there are multiple providers of a service, it could be possible to comparison shop for best pricing.
- This process maximizes automation and therefore shortens turnaround times.
Workflow service
A workflow service could allow a user to route translation requirements through various services as appropriate. For example, a large international corporation that modifies their internal content management system to create an appropriate translation workflow for any new site. The workflow service may be offered by an internal globalization group, who will monitor as required (and who implement clients for all the other related services), or who may choose to outsource the entire process to a vendor.
A separate initiative exists for standardizing the definition of such a system, called the WSFL (Web Services Flow Language).{{{ A relevant link is included below if you wish to find out more}}}
Change detection service
This service can be configured by submitting a source site for monitoring (for example, an FTP site, or a database). On a scheduled basis, or via a return service, the change detection service can return a complete list of modified content, thereby providing a list of required translations.
XLIFF segmentation service
XLIFF is an emerging XML-based standard for translation interchange. It allows for the storage of source and translated content in a standard translatable way regardless of the original content type. These could be, for example, XML, Word, or proprietary files. An XLIFF segmentation service could be offered that understands a wide variety of document formats, and will convert them to (and from) XLIF. Once in XLIFF, any translation tool or service that understands XLIFF can edit the content. This service could also be implemented internally, where a company might sue different XML formats (something that is becoming commonplace for Web applications), each of which has their own translation requirements.
Translation vendor Web service
Obviously one of the most useful localization Web services would be a translation vendor service. Several translation vendors already allow for submission of jobs online. Making this process available as a Web service would mean that the submission of jobs could be automated or included in a client Web site. For example, a content management system could offer a "Send for translation" button that submits the content for translation to the company's preferred translation vendor, or a "Cost translation" button that would query several translation vendors for price quotes.
In Figure 1 above, this service appears three times, as it should be general enough to deal with different types of translations. If XLIFF is used to transport the content, then it becomes reasonably easy to submit to one service for applying translation memory, another for machine translation options and finally to a human translation service. A translation vendor can choose to support one or more of these services.
Translator access service
As a translation vendor typically uses a number of translators, who may or may not work in-house, it would be useful for translators to use a Web service to access available translation jobs. If this service was standardized, translation tools could be made "Translator Access Service" aware, so that jobs could be queried, downloaded and uploaded from within a given translation environment.
The rest
In all of this it may be noted that some of the details of the translation process have not been explicitly addressed:
- Data access. This is assumed to be known by the workflow process and specified as part of the site submission to the change detection service. The types of data that can be dealt with could well be a differentiator for providers of this service
- Review approval. This is assumed to be either part of the workflow process or the translation vendors internal process (or initially both)
- Translation delivery and reinsertion. Again, it is assumed the workflow process knows enough to enable this—there could possibly be another service offering here.
- Accounting and billing. Although we need the ability to supply and respond to quotes in this system, accounting and billing are general enough processes that they should be handled separately.
|
