How do you reduce the cost of a translation project? Much depends on the nature of the project, of course. In some cases, the answer is to use raw machine translation (MT), especially when awkward, mistake-ridden text is acceptable. In other cases, crowdsourcing — outsourcing tasks to a distributed group of people — could work, although it isn’t proven that even properly managed crowdsourcing always reduces costs. Many in the translation industry believe that another approach, MT that is post-edited by humans, will dramatically increase in volume in the near future. This does not mean, however, that the volume of translation produced by professional human translators will decrease in turn.
In any case, whenever humans are involved, a substantial portion of the total cost of a project can be eaten up by overhead tasks that are not actual translation (Figure 1).
There are two easily identifiable solutions to the problem of increasing translation efficiency. The first approach is to develop one universal translation management system (TMS) that everyone in the world will use for all translation projects. Given the abundance of TMS products on the market, the lack of a clear winner and the frequent appearance of new TMS products, we believe this solution is not viable. The exception would be a single organization that imposes a particular vertically integrated solution — one TMS, one content management system (CMS), one translator tool. This integrated solution would have to be imposed on everyone involved in the document production chain, on both its in-house and freelance translators, and even those requesting translation services.
A second approach, although ambitious, may be more realistic: develop one universal package format for translation pro- jects and gradually convince TMS developers and translator tool developers to implement and integrate it with their systems. This could greatly enhance interoperability among various tools, and thus increase efficiency by reducing the “friction” that is encountered when passing a pro- ject between tools.
In a recent article in the April/May 2012 issue of MultiLingual, Don DePalma of Common Sense Advisory predicts the emergence of standards for packaging content and “transporting it around supply chains” and supports the universal package format.
A new initiative called the Linport project aims to address the problem of translation package compatibility and high overhead involved in a translation project while keeping all the relevant project information together, organized and efficient as it is passed from one tool to another with minimal loss of information (ideally, none at all); and also while communicating clearly among all participants about project requirements.
Linport stands for Language Interoperability Portfolio, where portfolio is to be thought of as a package containing all the elements required for a translation project. The primary purpose behind the Linport project is to simplify and standardize a key part of the translation process, while still allowing essentially anyone who would like to implement it to be able to. At the March 2011 LISA Conference, Smith Yewell from Welocalize demonstrated a similar dilemma by showing how the worldwide shipping industry has implemented the International Organization for Standardization (ISO) standard for shipping containers. This has created a global understanding of what sort of package is expected, but has still allowed individual shipping companies to determine how they want to handle and transport the containers, from using the smallest boat and dock to the largest cargo ship or airplane (Figure 2). Before ISO containers, there was a significant amount of manual unloading and reloading of the same contents as materials were transported by sea, air, rail and road in various incompatible containers. The ISO container standard changed that, making shipping much more efficient. The Linport project will do the same thing for the materials needed for a translation project, and it will be something that can be used by small and large companies, whether they be translation requesters, translation providers or tool developers.
Any standard package format universally adopted by tool developers would address the business need of maintaining the integrity of a translation project as it passes between tools. However, a standard package format does not necessarily address a second business need: communication among all project participants about project requirements. Fortunately, a standard way to structure translation project specifications has been developed as ISO/TS 11669. The informal name of this standard is ISO Translation Guidance, and the core framework for structuring project specifications is freely available to the general public at www.ttt.org/specs. There you will find 21 primary translation parameters in five categories: descriptions of the source content; linguistic requirements for the target content; production tasks to be performed; environment requirements, such as resources to be consulted; and requester-provider relationships, such as due date and compensation.
The full ISO Translation Guidance standard was published in May 2012, and many organizations are expected to use it as a guide to best practices for developing structured translation project specifications.
Dealing with competing
analogous formats
A universal translation package for- mat should increase interoperability and improve communication, and thus efficiency, among the many competing software systems for project managers and translators. As David Filip and Rahzeb Choudhury both mention in their respective articles in the April/May 2012 issue of MultiLingual, translation and localization industry standards should also be open rather than proprietary, which includes transparent development and freedom from royalty payments. However, problems may still arise.
Even when the package specification is publicly available, there is a potential problem in that many organizations may have their own interpretation or view of how a package should look. This can lead to two or more organizations developing similar standards to address the same business problems. These standards can then also end up competing for the attention of translation technology vendors. As Jost Zetzsche pointed out last year in the 198th Tool Box Newsletter, there are already a number of proprietary translation project package formats associated with different tools.
As is the case with numerous standards both inside and outside of the localization industry, trying to do too much with one standard typically results in the standard failing. Standards developers often get into a mindset where they believe they need to cover every possible scenario. Although it is good to be thorough, trying to be all encompassing tends to lead to a large, verbose standard that never gets completely finished or implemented; may become outdated before it is finished; and is too complex and confusing for the average user or company to be willing or able to implement. All of this means the standard does not get the acceptance and buy-in of the industry in general.
The Linport project avoids these two dangers by giving a high priority to cooperation. The object is not to try to crush the competition, as is often the case, but rather to interact with all organizations developing similar projects, with the objective of joining forces and combining good ideas. The standard also clearly focuses on the container format and interoperability rather than trying to standardize complex workflows.
Typical payloads such as XLIFF, TMX and TBX will be identified, while only minimal workflow information, such as a unique ID for a package or the task the recipient is expected to perform, will be defined. Complex workflow — such as the stages a package must pass through, who approves the package at each stage or how its history and version are recorded — will, at least initially, be left to the TMS. The TMS will only need to maintain the abstract data model for the structure of a translation package throughout the various workflows.
Three streams converging
In June 2011, there were three major projects that were identified in the industry that were all working toward some kind of universal translation package format. The first stream was the Container Project. What is now known as the Linport project, from one perspective, began March 2011 at the last LISA Standards Summit in Danvers, Massachusetts. While digesting the news of the demise of LISA as an organization, various organizations were discussing how the standards territory that was suddenly unoccupied might be divided up. The only thing the diverse group of participants representing content owners, service providers, tool developers, and research centers could agree on was that the next industry standard needed is a container standard including structured project specifications.
The Globalization and Localization Association (GALA) and the Localization/Translation and Authoring Consortium (LTAC) were asked to prepare a draft version of such a standard and discuss it with various stakeholders. It was named the Container Project, based on the idea from the presentation by Yewell about the huge impact of the ISO standard for shipping containers on the world of shipping by land, sea and air.
The first presentation of the Container Project took place the following month in Torino, Italy, at the annual translation technology conference sponsored by the United Nations. After this presentation, Josep Bonet from the Directorate General for Translation (DGT) of the European Commission indicated that a similar project was underway within the DGT. The project was called Multilingual Electronic Dossier (MED). Bonet introduced the MED project leader, Tomas Carrasco-Benitez, to the Container Project team.
After a number of discussions, in July 2011, both teams agreed to merge the two projects under a new name, Linport. Then, the complex process of bringing together disparate views on how to accomplish essentially the same task began, which included an early point of agreement on how to include ISO-style structured specifications in Linport packages.
In the summer and fall of 2010, software developers and business managers from tool vendors, localization service providers and corporate translation teams came together with the goal of improving interoperability between tools in the translation supply chain. The newly formed Interoperability Now! (IN!) team started drafting a representation guide for an XLIFF 1.2 document optimized for tool interoperability. Unbeknownst to the Linport team, IN! was also working on a companion translation package called the TMS Interoperability Protocol Project (TIPP) as part of their overall Translation Interoperability Protocol work. At some point during the Linport symposium held in Luxembourg in September 2011, the Linport team became aware of IN! A series of discussions from October 2011 into the first quarter of 2012 finally led to an agreement to work toward merging the TIPP format into the Linport project, specifically with the purpose of avoiding similar, competing formats in Linport and IN! package formats. This agreement avoids the danger of multiple standards for the same purpose, and focuses all development and standardization efforts on the same format.
Where do we go from here?
The objective of the Linport project, which is hosted by a nonprofit corporation called LTAC Global, is to develop a degree of consensus on a translation package format that would allow delivery of a “blueprint” to the OASIS open standards organization. From there, OASIS can open a Linport project and develop an industry standard. The European Telecommunications Standards Institute will set up a coordinating group to provide input to the OASIS Linport technical committee.
Once Linport becomes an OASIS industry standard, a process will be started to put Linport on a fast track to becoming an ISO standard as well. This will be particularly beneficial in that many organizations, particularly governmental organizations, have an official preference for ISO standards. The appropriate ISO technical committee for the future Linport standard is 37. This committee oversees terminology and other language resources.
The current plan is not to have the ISO version of Linport replace the OASIS version of the standard. Instead, there should be a copublication agreement, such as the one that was in place between ISO and LISA. The reason for this is to make the standard more accessible in that it can be sold by ISO, but will also be available as a free download from OASIS.
There are two distinct approaches as to how a Linport package can be used. One approach is to actually pass packages around over some kind of network, such as the internet, a local area network or a virtual private network, among various software applications. Each application processes a package locally. The second approach is for a package, or at least its contents, to stay on a server while multiple tools access components of the package remotely using web services.
In both approaches, the local approach and the remote approach, all stakeholders involved with the translation project still benefit from having a standard package format. The stakeholders in this process would typically be defined as content owners (translation buyers); language service providers of various sizes; and translators, revisers, reviewers and post-editors.
Figure 3 illustrates the potential points of contact for the package through the package translation life cycle, starting with the authoring of the document to the delivery of the document back to the buyer or content management system.
In this diagram, there are four TIPP-aware tools controlled by separate organizations. A translation buyer stores its content in the CMS. At the start of a translation cycle, the buyer passes content to a multilanguage vendor (MLV) that uses a TMS to manage the work. The MLV in turn passes the content to a single-language vendor (SLV). A translator in the employ of the SLV uses a translation workbench to perform the translation.
Once the Linport project has produced a standard format for translation packages and the standard has been implemented by a variety of translation tools, the industry should start reaping the desired benefits discussed in this article: maintaining everything related to a translation project together in one package and improving communication among all parties about project requirements.
