Translation has evolved over the last thirty years. Passing documents by fax and FedEx was part of the standard workflow as late as the 1990s. Then, email quickly became the standard, followed by FTP sites, customer portals and cloud drives—all to move documents through the process of requesting quotes, carry out translation production and delivering translated documents.
As the Internet evolved, documents were redefined, providing convenient containers to handle all types of content since the first papyrus scrolls were invented. In the digital age, we still manage lots of documents as files. If anything, thanks to cloud storage, we’ve become digital hoarders of all manner of files. Corporate communications are still firmly rooted in Microsoft Word, Excel and PowerPoint documents. However, as written communication continues to evolve, we have shifted from documents to content. Content is king, after all. Documents don’t make a lot of sense in the era of endless scrolling. By the time we hit the Wiki craze of the naughts, structured content had finally gained enough popularity in technical communications to finally allow widespread adoption of XML and single-source authoring and publishing.
From Documents to Content
How has the evolution from documents to endlessly streaming written content impacted the translation process? If anything, modern translation processes have anticipated the evolution of discrete documents to silos of content. Starting in the late 1990s, computer-aided translation technology began to tackle the separation of content from structure with the introduction of document filtering. Document filtering transforms documents into a content stream by parsing sentences to a flow of segments that the translator works on. The defacto standard is the “translation grid”.
Figure 1: Translation grid from MadCap’s Lingo software
This brings us to the topic of “connectedness”. Once content has been de-structured and is now generated and written in a more open format, it begins to flow. Maintaining the flow across the supply chain becomes a critical factor in gaining more efficiency and keeping up with the world’s insatiable demand for information. The flow from author to designer to publisher to translator to publisher must advance unimpeded. This requires that everyone in the supply chain be plugged in and connected.
The challenge to the translation industry is the myriad types of content that need to be translated, such as, social media content (blogs, reviews, tweets, website content and all manner of posts), software user interfaces, captioned video, e-learning modules, wiki articles, technical documentation published as JSON, HTML5, PDF, or Word documents.
Add to this, how content is stored and managed within organizations large and small. Some companies may have document management systems, others may have content management systems that house repositories of XML or other structured formats. The software industry prefers source control, following a software development-based process versus a traditional authoring process. If it is e-learning content, then access to an LMS (learning management system) will be necessary. For websites, there are myriad platforms for managing website content, such as Drupal, WordPress, Joomla, DotNetNuke, Magento, Hubspot, and Adobe Experience Manager, to name but a few.
Middleware: The New Middleman
If this were the age of Star Trek, we would simply build a “universal connector” and have access to all these content stacks and silos. Perhaps, artificial intelligence will have a hand in making this dream a reality. Until then, connecting a Translation Management System—the software infrastructure that brings content into the translation grid and back out again—to company content can be a laborious and a capital-intensive undertaking. There are, of course, companies addressing this issue. So-called “middleware” has been around in the content management space since the late 1990s. These companies focus on creating connections between TMSs and CMSs using APIs. And if I tried harder, I could have found another three-letter acronym to include in that sentence! All this means is that there are ways to create connections between translation management systems and content management systems using application program interfaces. These custom connections are achievable but aren’t cheap to create. The largest companies with a high-volume of translation typically can justify the expense of creating these customized connectors. In some cases, developers will negotiate the rights to resell the custom connector to other customers, allowing the development to benefit more than just one company. However, in most cases, the technology is considered proprietary and the API connector will have a negligible impact in the translation marketplace.
“Connectedness” for the Rest of Us
Even if your organization’s translation demands are not huge, your translation provider should be able to minimize the amount of effort on your part to create the most efficient workflow. For example, if you have an online Help system built in a tool such as MadCap Flare, your provider should be able to handle your Flare project files directly. If they ask you to generate a Word file or a PDF, then they are not ready to support you with an efficient process.
Kill Copy & Paste
When it comes to translation support, your company is paying for a service. If engaging that service increases your organization’s level of effort significantly to enable the translation, you must make connectivity a criterion in your vendor selection process. I have heard stories of companies having to manually save all of their web pages to discrete HTML files or having to copy and paste their site content into a Word document, or else their translation provider would not accept the project. With that level of effort, you might as well just fax them a printout! Looking for a technical translator or localization provide, request a free quote.