Integration with other software

In 1.3.1, it has been pointed out that current translation environment tools package dier- ent applications. Still, some applications do not belong to the core of translation environ- ment tools.

Authoring tools, for example, are intended to ease the creation of documentation. Therefore, they are not primarily intended to be used by translators. One of the basic ideas behind the integration of authoring tools and translation environment tools is reusing what has been written before (so that less content has to be translated) and keeping new formulations as close as possible to previous ones (so that fuzzy matches are likely to be produced). The integrated tools oered e.g. by Across,38 _{SDL Trados and Star are called}

authoring memory systems or authoring memories. It is not clear if additional translation environment tools are going to oer similar products, see (García and Stevenson, 2010,

35_{The impact of dierences concerning segmentation should not be underestimated because they can}

result in the loss of several percentage points of eectiveness in TM leverage, (Lommel, 2006, 232). Consequently, these few percentage points' worth of lost 100% matches could translate into a direct cost in the tens of thousands of dollars [...], (Lommel, 2006, 233).

36_{Anastasiou (2010) presents a small survey on the level of awareness concerning XLIFF.}

37_{Some reasons for the slow adoption of TBX are provided by (Lommel, 2006, 234) and (Wright, 2006,}

269).

38_{For more information on the specic integration in Across of authoring tool and TM system, see}

19). However, this integration seems crucial for products aimed at large-scale enterprises, in particular when combined with the adoption of controlled language (see Geldbach (2009) for a discussion of controlled language checkers, applications that allow for sophisticated linguistic checks).

When considering the means of inputting a translation, it is natural to think about the keyboard. However, the use of speech recognition is nothing new. (Fulford and Granell- Zafra, 2005, 9) note that few respondents made use of voice recognition software, but give no percentage. Zetzsche (2007a) pleads for a better integration between translation environment tool editors and speech recognition applications and criticizes that the latter are often less than optimal. Interestingly, a more recent survey also reports that discus- sions relating to the use of voice recognition software (VRS) and translation environment tools were not extremely common [...], (McBride, 2009, 110). The last few years do not seem to have witnessed any signicant shift in this eld. However, it is at least conceivable that a major breakthrough in man/machine interaction using voice technology will occur in the next decade.

Ongoing research aimed at closer integration going beyond simple dictation is described by Vidal et al. (2006): the human translator determines acceptable prexes of the sugges- tions made by the system by reading (with possible modications) parts of these sugges- tions, (Vidal et al., 2006, 942). A similar research activity is presented by Khadivi (2008).39

The integration of speech recognition and statistical machine translation for MAHT is also under research, see Reddy and Rose (2010). So far, no commercial translation environment tool oers similar features.

The users of translation environment tools frequently use applications that perform optical character recognition (OCR), see (Bowker, 2002, 26-30). OCR tools are a commonly requested plug-in for translation environment tools, see (Lagoudaki, 2008, 98), because they are believed to enhance translator productivity (Lagoudaki, 2008, 180). Interestingly, the ndings presented by McBride (2009) show that OCR software is not debated that frequently in translator forums. The trend towards digital content is complete in several areas (e.g. technical documentation) and it is likely that it will continue to embrace nearly the totality of the documents to be translated. On the other hand, as long as documents are made available in electronic form, but in non-editable formats (e.g. sometimes PDF), OCR will still remain an interesting option for some projects.

Process management tools are often integrated into translation environment tools, par- ticularly into corporate versions, see Sikes (2009). However, there are also external solutions that serve the same purpose, see (Reinke, 2009, 175-177). The main drawback of internal solutions is that they cannot be used in conjunction with other translation environment tools. As long as only one translation environment tool is used, this is not a problem. But many LSPs employ several: in such cases, a third-party application, which is capable of interacting with all translation environment tools, may be preferable. It is therefore unlikely that external process management tools will become obsolete.

A similar situation applies to quality check tools. Translation environment tools in-

tegrate many check functions and can apply them during translation: when an error is spotted, it is immediately reported, e.g. by highlighting the segment and providing a de- scription of the error in question. For example, memoQ and SDL Trados support this type of quality assurance. QA Distiller and ErrorSpy can be cited among the third-party quality control tools that can be used after the translation.

The QA/QC components of current translation environment tools usually do not sup- port the quality measurement and assessment provided by third-party solutions, see (Reinke, 2009, 174). As translation environment tools improve and extend their QA/QC compo- nents, it is likely that third-party solutions will focus on special checks, e.g. compliance with company-specic rules where linguistic knowledge is necessary. While translation en- vironment tools can integrate such tools, similar to Across in its crossAuthor Linguistic module for authoring purposes, see (Sikes, 2009, 18), it is unlikely that they will eventually merge.