The Missed Opportunity of Translation Management Systems

Recently, I had been having a discussion with a TMS vendor about potential new directions for  Translation Management Systems to evolve in, when Luigi Muzii, in an independent and unrelated interaction, suggested this new post based on some of his own observations about TMS systems. So based on this unplanned synchronicity, I felt it would be good to air this. I invite others, especially from the TMS vendor community to come forward with their perhaps more informed views.

It has seemed to me that TMS systems in general, focus largely on the translation management problems of yesteryear, rather than the current ones, let alone emerging needs where there is a much greater need for intelligent data technology, beyond translation memory. The data in most TMS systems is in what I would call a dumb repository. The data is tagged by project and customer, but rarely by more extensive metadata that would be valuable to leverage it for future translation projects. No TMS today can help you extract, for example, all the TM related to hybrid automobiles in your total data repository or identify key terminology for hybrid automobiles from the total repository. Look at what is possible with Linguee.  Why are these TMS systems not able to do this, at least on your own data? Data could be catalogued at various levels of granularity by PMs who are not chasing errant freelancers down so relevant chunks can be retrieved when needed. This is what I mean by intelligent data, which understands the relative importance of phrases, some semantics and even relative overlap of ALL data resources with new project work. It should be able to respond to reasonable questions that involve a combination of words/phrases as any supportive automation should. The kinds of tools we use will confine us to certain kinds of work (software and documentation translation) if you want to solve big translation problems like eBay, Microsoft, Facebook is doing, you are going to need better tools. 

MT involves the use and management of large volumes of translation memory and other linguistically relevant data and it would be very useful for TMS systems to provide linguistic data analysis, manipulation, and transformation capabilities. Many of these corpus tools already exist in open source as Juan Rowda has pointed out, but it would be good, and of great value to any global enterprise and large agency users, to have these kinds of tools closely integrated so that they can easily interact with large-scale TM repositories.  The future TMS system needs to be much more useful to, and supportive of, large-scale translation projects that involve tens of millions of words, and both MT and post-editor feedback, as these kinds of projects, will become much more prevalent. No TMS tools I know would be helpful to do normalization and standardization of MT training data even though they keep all of the TM. It would also be very useful for next-gen systems to also provide a sense regarding the relative similarity or dissimilarity of subsets of data

It also seems somewhat archaic that TMS systems still need to break large TEP projects into smaller translation packages to hand off to individual freelancers and does not have a more elegant form of collaborative translation where this disassembly and re-assembly is NOT necessary. SmartCAT is refreshing and interesting because it solves this very basic problem and is also free. The translation collaboration outlook is still pretty bleak but I think better collaboration is one area that TMS vendors should really focus on and make more easily implementable. 

 I don't speak German so not really sure what this says, but I really like the question being asked.😁


What are the most important areas for Translation management systems to develop in future?  Here is a list I came up with as potential areas for improvement, which is easy for me to dream up since I don't have to actually do it.

• Better database management so that systems can handle tens of millions of segments and can slice and dice these segments in every which way as needed.
• Data anonymization and randomization capabilities so that TM can be leveraged for new kinds of translation problems without compromising data security or privacy.
• NLP capabilities to help understand data characteristics at a corpus level and do the kinds of things that Linguee and Google allow you to e.g. predictive and auto-guessing words and phrases.
• Translation collaboration that reduces the burden on project managers and actually frees them from policing roles to handling policy and overall quality driving processes.
• Better integration with MT so corpus can be modified and prepared to raise quality of results and so that PEMT can be better integrated into advanced learning processes
• More Flexible Workflow Design capabilities so that every client is not forced into a one size fits all mode of operation.
• More automation of basic project management functions so human involvement is focused only on special exception situations.
• More measurement metrics on job efficiency and expanding Key Performance Indicators by JobID, PM, language, client etc..

 The emphasis below in Luigi's post is all mine.

-----------------------------------------
↓↓↓↓↓↓↓↓↓↓

I have observed that people in the translation community, no matter how high they rank in their functional area or organization, are generally reactive rather than proactive. The latest financial events where Private Equity is moving in (i.e. Moravia, ULG, and LIOX) are a further confirmation of this attitude, although the recent history of the industry should have enough to tell, for any unbiased reader.

This reactive attitude results in a situation that industry outsiders are forced to introduce innovation into a field other than their core business because of the inability of their translation business partners to do it. And thus we see that these outsiders end up driving the "translation industry" forward and eventually the industry is ruled by customers rather than the original industry players.

While basic business and production processes have remained nearly unaltered for centuries,  technological development has been brought in and implemented following the request, when not actually the directive, of the most affluent, and tech-knowledgeable customers. In most cases, the most significant advancements, and indeed improvements, have been pioneered by those customers; technology providers have followed suit, rarely with striking results. In almost three decades, progress in translation has mostly consisted of some trivial outcome of the amelioration frenzy of software applications exploiting long-established technologies, with the claim, every time, to revolutionize the industry and the profession.

An examination of the translation management systems (TMS) in the market is quite representative of this behavior. TMSs are supposed to be the equivalent of workflow management systems (WFMSs), which date back to the early 1990s if you look at the broader business market. Curiously, or possibly not, TMSs generally lack most of the features of a typical mature full-fledged WFMS that can be found in virtually any business of some significance.

Lionbridge’s current CEO, Rory Cowan, summarized the at best, disappointing, NASDAQ experience of the company he has been leading for quite a few years, with a statement that is as simple as it is sad: “The U.S. markets really do not appreciate the translation industry.”

As a matter of fact, none of the top-ranking translation companies is an innovation champion, nor is it yet remotely comparable, financially, technologically, structurally, and operational sophistication, to even mid-level companies in most other service industries.

Typically, a WFMS is an application framework for building, managing and automating, as much as possible, a set of tasks forming one or more business processes. Some tasks may require human intervention, such as the development of content and/or its approval. Also, the system must allow users to introduce new tasks or describe new processes and typically comes with some form of process flow designer to create new workflow processes and applications through it.

On this basis, WFMS must allow users to define different workflows for different types of jobs or processes, associate one individual or group for any specific task at each stage in a workflow and establish dependencies for process management from top to lower level.

WFMSs should also allow for application integration to form a middleware framework.

Finally, WFMS should also consist of a project management module to help plan, organize, and manage estimation and planning, scheduling, cost control and budget management, resource allocation, collaboration, communication, decision-making, quality management and administration. Similarly, any TMS should enable translation businesses and customers to control their projects and monitor every task according to an established and agreed upon workflow.

A TMS is supposed to allow for automating all or at least most of the translation process while maximizing its efficiency by having repeatable and non-essential work be done by software. However, most state-of-the-art TMSs only provide some basic translation management functions. The thing is that no two people in the translation community would agree on what exactly the creative part of the process is, that can’t be left to machines.  And sadly, no two linguists can even come to an agreement and be able to describe and define the special skills and abilities that define and dignifies themselves as knowledge professionals.

Contrary to what happens in almost every other type of business, no TMS still exists with all the features described above. Specifically, all lack a comprehensive graphical workflow designer. Only one or two provide some very basic capabilities.

So, forget about Leibnitz[*].

As a matter of fact, most players in this industry are generally oblivious or at least uncomfortable with simple diagrams like activity diagrams and even flowcharts, which are graphical representations of workflows or processes. Although pertaining at large to the field of software engineering, modeling languages have long been established this approach as a standard way to visually describe the business and operational step-by-step activities in a system. However, most translation people are still incapable of envisaging a slightly more articulate process than the typical middleman-based agency model.

If this were not bad enough, translation project management is way far afield from real project management, and, not surprisingly, only a small bunch of translation/localization project managers hold a PMI certification.

The supposed and long-touted peculiarity of translation, together with the utter and thick rejection of any real business focus, despite the beloved acquaintance with rates and any relevant discussion related to these rates, is possibly a reason why TMSs are so estranged to WFMS and ERP.

To allow users always to find the best solution and resource as fast as possible a TMS should first be a central repository for language data and the vendor database. The aim of a TMS should be helping users cut out middlemen from the procurement process while enabling project managers to plan the best schedule and budget and pick the best resources. In such a way, TMSs are also expected to reduce overhead and hence costs and time.

Therefore, any current TMS with one-fits-for-all process model is somewhat problematic at least. Customers should be able to design their workflow and control where, when and how much human involvement is requested or needed for differing project needs.

Indeed, TMSs might have a dramatic impact when collaborative translation is effectively implemented, through parallelized process, but, for the same reasons why workflow graphical design features are almost absent from TMSs, real collaborative translation features are yet to come too.

Finally, most TMSs have already moved or are being moved into the cloud; however, while reducing capital expenditure and allowing for faster software deployment, the SaaS model presents some serious drawbacks in lower flexibility and higher customization costs. Of course, the features offered by TMSs depend on the level of sophistication, but the technical intricacies of such TMSs preclude them to be adopted by most LSPs and even by most customers.

TMSs might have been the means to lead customers rather than letting them dictate, but the chance has been wasted. So far.

[*] It is unworthy of excellent men to lose hours like slaves in the labor of calculation which could safely be relegated to anyone else if machines were used.

---------------------------

Luigi Muzii has been in the "translation business" since 1982 and has been a business consultant since 2002, in the translation and localization industry through his firm. He focuses on helping customers choose and implement best-suited technologies and redesign their business processes for the greatest effectiveness of translation and localization related work.

This link provides access to his other blog posts.