Even with all the advancements that CAT tools have made since their inception in the 1990s, online CAT tools are holding us back. Why? They are still lacking critical features like advanced terminology management, a customizable QA framework, segment-based metadata, screenshots, post-editing productivity statistics, query management, and an LQA framework (to name a few). And if the functionality is actually in the tool, it’s not customizable enough to meet varying project needs.
At Moravia, we engage with CAT tool providers to request enhancements and added features, but often the custom development needed to accommodate a mid-sized project simply doesn’t produce a positive ROI. Of course, if there is an urgent improvement or bug fix with clear benefit to all CAT tool users, then the implementation time is within weeks. But the wait for project-specific features can be up to ten months. Meanwhile, quality and turnaround times suffer.
The good news is that we’ve found a way to overcome this limitation and offer our clients the flexibility they require. In fact, my solution won the Process Innovation Challenge at LocWorld 35 in Silicon Valley. This award recognizes the value and effectiveness of creative technical solutions for resolving client business challenges.
Here’s more on my solution.
Currently, there is a handful of widgets that connect directly into web browsers, like browser extensions. They offer a very appealing concept—to be able to create new features independent of the CAT tool provider. But these widgets aren’t perfect. One difficulty is that they depend on the DOM (Document Object Model) of the underlying webpage. In short, that means that any time a CAT tool developer changes their HTML objects, the widget could break. And since such changes are being made every other week, it’s simply too risky to put your project in danger and make it dependent on such a fragile piece of technology.
This pushed me to formulate a new framework for how user-built extensions can be made more robust and ready for real-life production. My proposed solution involves a set of functions to be implemented by CAT tool developers that will ensure proper and reliable interaction between the extension’s code and the rest of the online application—the online CAT editor in our case. Such functions will ensure proper display and entry of all important information, such as the source and target texts, segment status, comments, and segment IDs. And of course, there should be a dedicated section of the UI (dialog, panel, etc.) where the extension could visually present its results. It’s important to make sure the extension doesn’t break the layout of the online CAT editor’s UI.
This set of online CAT tool amendments will be documented and published as a new type of API—the “Translation DOM API”—so any user can refer to this specification and create their own extensions.
If this sounds great so far, let me take my idea to the next level. A hindrance of current extensions from the LSP perspective is that the code is stored and running on the translator’s computer. Since it’s the translator’s responsibility to activate the extension, it’s very hard for LSP project teams to make sure that every translator is really using it. This situation can be eliminated by storing the extension code on the CAT tool’s back-end servers instead. This means that the extension’s code is saved in the CAT tool in the same way that segmentation rules or any other settings are stored. The project settings will ensure that any file opened in the online editor will also have the proper extension activated. You can define a tailored set of features for each project in the online CAT editor, and you don’t have to worry about whether the translator activated the extension or not—it will be done automatically.
Another suggestion for improvement is to standardize the Translation DOM API functions. This will ensure that the piece of code will work across multiple CAT tools, and translators don’t have to develop custom extensions for each tool they use.
With these innovations, online CAT tool editors might finally get to the same level of flexibility that we see in desktop tools like Passolo. What’s more, by developing these extensions in the new visual style of development based on Google Blockly, we might decrease the time spent debugging, and open up the ability to develop extensions to all technically savvy CAT tool users.
My colleagues and I have already moved forward with creating some of these extensions, and we’ve found that this new way to expand CAT tool functionality makes the lives of translators and project managers easier, not to mention brings quality and turnaround time benefits. The future of online CAT tools is looking bright indeed…and we are thrilled to take part in driving it.
If this blog post piques your interest about advances in translation technology, check out this webinar: What Blows Our Minds About the Latest Translation Tech.