How we helped a client who quickly outgrew their TMS
When our client’s TMS could no longer handle the size of their files, the tool became a roadblock. Luckily, they partnered with Rubric, and we had the knowledge, expertise, and tools to work around the limitations of their TMS.
If you’ve invested in a translation management system (TMS) for your global business, you probably had high expectations about how it would transform your localization process, saving you time and money. But increasingly, we’re hearing from clients whose TMS isn’t delivering as they hoped.
This could be because they hadn’t fully understood the purpose—and limitations—of a TMS. It’s also common for clients to underestimate the level of expert configuration and ongoing maintenance required to get the most from their TMS.
But an issue that comes up time and time again is scalability and longevity. As a client’s business grows and evolves, a TMS that initially seemed like the dream ticket proves unable to keep up with increasing demand and content complexity. This is undoubtedly frustrating for the client, but as a trusted localization partner, we can often take on some of their pain and provide support and practical solutions.
When your business needs evolve—and your TMS can’t keep up
One of our clients (who wished to remain anonymous) found themselves in this exact situation. They had purchased a cloud-based TMS, which is designed to be a secure and efficient way to manage, store, and collaborate on translations, regardless of format or location. Cloud-based TMSs are sold as easy to use, and some boast additional AI and machine translation functionality to further boost efficiency.
Unfortunately, this client quickly found that the files for a new content type (from their Product Information Management system or PIM) were too large for their TMS to support. The system would crash when users tried to set up projects, and client-side reviewers found themselves unable to load files in the online editor.
The client approached the tool provider for help resolving these issues, but progress was frustratingly slow.
It was vital that this content be localized in a timely manner, so Rubric implemented a workaround to the first problem – being able to set up the project.
A custom approach: working around TMS limitations
Eventually, after much trial and error, Rubric identified the maximum workable file size: a disappointingly small 4MB. Our IT Director, Dominic Spurling, comments:
“4MB is a small amount of data. It is around 200,000 words. The whole project is 1 million words and really that shouldn't be a problem for this kind of enterprise-level tool.”
Armed with this information, we were able to develop a custom automation process to split the files at the maximum size. They then need to be uploaded in small batches in order for the project set-up to succeed.
It’s progress, but it’s not perfect. We have automated the upstream process as much as possible, but the workaround still takes up unnecessary time and effort and means the process is inherently inefficient. And the client incurs additional costs as a direct result of their TMS’ limitations. As Rubric CEO Susannah Eccles explains:
“We are having to do lots and lots of workaround to mitigate for the limitation of the TMS.”
“When they bought this TMS this project wasn't on the horizon, it came later and their TMS is not fit for the job. Luckily they work with us so we can work around the problem.”
The reality: long waits for tool fixes
The issue with the online editor remains unresolved by the tool provider at the time of writing, more than 12 months after it was first raised with them. The cause has been identified—it is the large Translation Memory (TM) that is causing the online editor to crash, but reducing TM size is not a viable option without impacting content quality and consistency.
Again, Rubric have worked around the limitations of the TMS, but the shortcomings of this feature are a big disappointment to our client—allowing in-country reviewers to see TM matches in the online editor whilst reviewing was an important factor in their decision to purchase this TMS over its competitors.
A 12 month timescale might sound surprising, but it’s actually not uncommon for clients to wait many months for TMS issues to be resolved. TMS providers supply numerous clients, all with different support needs. We’ve found that very often a client’s problem isn’t very high on the tool provider’s to-do list. Even minor changes to configuration can take much longer than clients expect, whilst the impact on business operations can be significant.
A partnership that gets more from your TMS
At Rubric, we’ve seen it all when it comes to TMSs—we’ve experienced plenty and we can often help fix or work around problems clients have with their TMS.
Recent Rubric work arounds
If Translation Memory (TM) management is poor, and the TMS is selecting inappropriate TM matches, we can implement automated quality assurance (QA) checks to identify errors using our highly configurable RubricCatcher tool.
If a client’s TMS can’t handle a particular content type, if the set-up isn’t working for translators, or if tool provider support is slow, we can use our own tools to standardize the content for TMS consumption.
If a TMS’s in-built QA checks don’t cover all of a client’s requirements, we carry out additional checks downstream using our fully configurable QA tool.
If the TMS doesn’t have a connector for the client’s content repository, we can implement an automated pull-and-push process using RubricConnect, saving manual effort.
Unfortunately, TMS limitations are often in-built or out of our control, and can’t be resolved. Our experience is that TMS tool providers often prioritize client-facing features over functionality for the heaviest users – translators and project managers. This has a direct impact on the tool’s efficiency and effectiveness, and the time, cost and quality of translation projects.
Some problems we couldn’t fix
Inefficiencies in project set-up can result in a lot of time being spent on manual steps, which slows down projects and causes frustration.
Some TMSs don’t support the use of industry-leading computer-assisted translation (CAT) tools. The translators must work in the TMS’s in-built CAT tool, some of which offer a poor user experience, are very slow to work with, or are missing key functionality. Not only is this frustrating and time-consuming for translators, but it can actually impact translation quality.
If a TMS doesn’t offer the grouping or prioritization of TMs, the set-up won’t be optimized for translators to use.
What sets Rubric apart is that we recognize a TMS can’t do everything—it’s one tool, designed to support one piece of the complex localization jigsaw. We look at every step in a client’s workflow and figure out the best tools and technologies to handle each task. This might be one of our own bespoke tools, or we might choose another best-in-class solution.
We call this big-picture approach orchestration, and it involves us plugging into clients’ own TMSs to streamline and optimize the entire workflow. For example, if the TMS can’t handle certain file types, our tools can carry out the pre- and post-processing upstream and downstream from their TMS needed for a seamless transition, eliminating manual effort.
Another option that can save clients a lot of hassle is to use our TMS, instead of buying their own. This way, they don’t have to worry about configuration—we’ve already anticipated the issues and customized the system for growing global businesses like theirs. It also means we can be agile and take action to resolve problems swiftly. Because we administer our own TMS we can optimize and customize it to meet our clients’ needs—unlike in this story, where we didn’t administer the client’s TMS so were unable to implement any fixes in the tool itself.
No TMS is perfect, but at Rubric we’ve got your back. When you partner with us, we won’t rest until we’ve made your global content localization as efficient as it can possibly be.