Expanding to multiple markets? Want to use a translation tool? Good luck with that.

If you’re buying a translation management system (TMS) for your SaaS-product company, congratulations. And also — good luck!

Congratulations are in order because it’s an important step in your company’s road to global success. After all,?a robust TMS?can directly contribute to?faster time-to-market, better content quality and reduced engineering workload.?Please note that the previous sentence says “contribute to” and not “single-handedly enable” — regardless of the tools, solid processes and strategic positioning of localization are always needed.

The “good luck” wish?is there for another reason — not only will you be facing the?same process-related risks when choosing a TMS as when buying any other company-level tool, but translation tech will also bring its own set of challenges.

Hit the target and miss everything else

Many companies approach the TMS selection process in the most straightforward way possible. They analyze the needs of primary stakeholders (Localization Department), write down their requirements and then venture out to find the best available tool. In the end, the TMS provider with the best mix of features and price — and sales skills — typically gets chosen. All clear, right? Well, this approach might work for smaller SaaS companies but for any mid-size and large ones it’s THE reason why translation technology often runs into so many implementation problems later. The core issue can be summed up nicely with the following saying — by hitting the (small) target, we inevitably?missed everything else.

It’s true that the Localization Department is the one who needs this system the most, but that doesn’t mean other departments have nothing to do with localization. Au contraire — the bigger picture tells us that?it actually “takes a village’ to successfully sell products globally. Surely there are?other stakeholders in the global process who won’t use the tool daily but they are an integral part of your global efforts nevertheless.?Ignoring their?realities and needs will?severely affect the subsequent implementation of any piece of translation tech — hinder its benefits and success, to be more precise.

For example, when you’re working on a software product, the hunt for TMS requirements should perhaps start outside of the localization team - your engineering team might need to be consulted first when selecting the translation tool. Just check the following set of questions that matter to?that?department: Do they need API integration, do they need automation to get UI strings in and out of the TMS, do they have backend strings that also need translation, does the TMS support their preferred file format, can the tool logic keep up with the delivery pace that product and engineering teams are following? The Localization Department should not — and must not — answer those questions on their behalf or skip finding out the answer altogether.

The buck doesn’t stop there — what about your?content or tech writer teams??The content that they create gets translated too, but in a pretty different way than UI strings — these teams most likely use some CMS system, have lots of flattened-text screenshots in their articles and numerous cross-links within the content. The features needed to solve for all these challenges might not be available in the tools that fit the Engineering Department’s bill — therefore,?what works for one team may not be enough for the other. Lastly, if you have marketing or sales in your target markets, will they be asked to?review the final translations (in-country)??If yes, there must be a dead simple way for them to do it — otherwise they’ll literally run away from review tasks if they need a 3-day training to do it. They’re too busy with their core jobs anyway.

One would think that the best solution would be to take the easy way out and simply choose?different TMSs for each department. However, such a double or triple set-up will inevitably create a split-brain problem in your localization infrastructure — you won’t be able to build an integrated localization infrastructure?because language assets and processes will not be shareable or reusable easily. For that reason, this multiple-TMS approach should probably be avoided unless you have some very good reasons to do it, to outweigh all the cons.

Having all this in mind, it’s not difficult to see why choosing a TMS based just on that cool translation editor feature, great terminology management module or WYSIWYG preview for Word documents is actually trivial — they will not help solve the?deeper organizational challenges?nor boost the productivity of the whole company. So,?if a translation tool is being chosen, it must be done with the whole company in mind?— not only the core localization team.

Sign the deal and then adjust the tool to your process

The next big risk is particularly applicable to companies with established localization programs and processes. It’s caused by the intrinsic need of every company to look for a tool that they can simply plug into their processes and just continue full-speed ahead. Unfortunately, things rarely work that way in real tech life.

There are countless examples of companies buying translation (but also other) tech solutions based on that initial list of requirements, a short testing phase and promises of the tool vendor (“we’re working on that exact feature right now, it will be shipped soon”, “we plan to improve that exact thing later”). Many tool buyers sign the deal in this phase but it is only when they get into the nitty-gritty of the implementation that they find the proverbial devil, hiding in the details.?Localization processes are notorious for being different for every single company out there, so there’s basically?no tool that can ever be a perfect fit?to what some company already has in place. There are simply too many specifics, workarounds and patches that affect localization — due to how a given company operates — and that’s just how it is. But many companies forget this and convince themselves that their localization processes and flows are almost universal and can easily fit into any 3rd party tool. Even if something is still not fully aligned, it’ll surely be easy to be added later — at least that’s what the TMS salesperson said.

Relying on TMS promises would not have even been such an issue had there not been another notorious fact —?translation tech companies are usually amazingly small. Their development capacity is often an order of magnitude smaller than their SaaS clients’. The direct consequence of this is that, unless you’re Google or you’re paying a hefty price for some Enterprise plan, the tool vendor will not have the time, capacity or interest to make custom changes just to fit your process. Especially after the deal has already been signed and sealed, for obvious self-interest reasons. So, you’ll inevitably end up creating some workarounds in order to make an otherwise-perfectly-logical system work according to your process. I’ve personally seen a lot of weird set-ups stemming from this particular root cause. (On a side note, given that Google has built its own custom TMS, the chances are that even being Google wouldn’t help you much in this respect.)

Of course,?the ideal solution to this industry-wide problem would be that TMS providers make their systems?more modular, workflow-agnostic and customizable from the ground up?— to take into account the inevitably customized needs and setups of an average client that will come their way tomorrow. But no TMS is like that now.?Their makers?are too often assuming on their own how their clients should handle localization, thus (un)intentionally enforcing their own way of thinking on everyone else.

Unfortunately, the?existing TMSs can hardly be retrofitted now to become modular?(that feat usually requires different architectural thinking upfront), so I guess we’ll simply?have to wait for someone new to fill this unmet need in the translation tech space. But until that happens, the question is — what can be done to avoid buying a brand new TMS and then have to patch it up, right from the start? Only two options basically: 1)?build your own system?like Google did — what is a very expensive and questionably smart move, or 2)?adjust your own processes?around the already available tool that you can/plan to buy.

I’m of course aware of the costs and change management required for such an adjustment. But as someone who’s seen and used his share of TMSs, I’m of the opinion that?adjusting your processes wherever you can still tends to be the?lesser evil?here. Most TMSs out there tend to have a very rigid underlying architecture, so doing any serious modifications is simply not possible and should not be counted on.

Additionally,?since tech evolves so quickly, chances are that your localization program is due for a refresh anyway. So, buying a new TMS can be the perfect opportunity to adjust some of the steps and fit in naturally into what your selected tool offers by default. It will?make the overall investment pay off faster, and you’ll have better chances that those few tweaks that you really need can actually be delivered by the tech vendor.?Being closely aligned to their idea of the localization flow dramatically increases your chances that they might already be working on exactly what you need.

In this respect, new or immature localization programs are always easier to set up with a new tool. They don’t have much legacy, and no past-related baggage to think about.

NOTE: Early reviewers of this article have pointed out to me that there’s a third option too — to?combine several unrelated tools to work together?and support your multilingual processes. The advantage is that this can cover the whole content pipeline, and not treat localization as a separate thing at the end of content creation process, but it’s not a simple feat to make them communicate seamlessly. Anyway, for the purposes of this article, we’ll limit the discussion on only components offered by a single TMS.

Choosing the tool for today’s needs

The next item has partially been addressed in the previous part but there’s another angle to it. If you have an established program,?choosing the tool to reflect exactly your current processes?seems, of course, like the logical way to go. The problem is, though, that you might be?heavily investing now into something that might be?obsolete?in just a year or two.

It’s like buying a brand new car with the basic equipment trim — it’s always just good enough for most of your needs today, plus it saves you a lot of money. Win-win? Well, the problem is that even in just 2 years you may find yourself feeling that?your new car is somehow out of date — lagging behind what everyone else seems to be talking about and buying at that moment. But you won’t be able to change anything — you haven’t even paid out the car enough to make another change.

Pardon the oversimplification, but that’s essentially what happens if you look only at what’s in front of you now, instead of what your company is most likely going to need in a year or two. And that can literally?hurt your company’s competitiveness?in the global race towards customers. The future is of course always tough to predict, but some trends are easy to spot in advance. And you should?keep that in mind, unless you want localization to become the bottleneck for your new features’ time-to-market.

For example,?headless CMS integrations?today seem like optional equipment — but in 2 years many of your competitors might be using that and cut down on the time needed to deliver localized products.?Integration with MT hubs?today looks like an unnecessary tech-luxury piece today, but with the NMT advances and emerging customization of MT that’s exactly how companies will be translating their huge tech content repositories or e-learning lessons. Lastly, if you believe (like us in?The Early Adapters?group do) that the future of localization for tech clients lies in being truly Agile for localization too (which is enabled by working with freelancers directly, among other things), then you should?select a TMS that supports a variety of workflows and vendors?too. So,?it’s all about future proofing your localization processes.

It’s exactly here, however, that many companies run into problems — their?localization team?is positioned just as an internal translation agency and typically is?not given access/exposure to overall company operations and future tech stack plans. However, it’s extremely important for them to know things like whether the company will start offering a mobile app next year, or will want to get all tech documentation finally translated, or will change from using multiple CMSs to just one.?If localization were treated as a strategic function and its leaders regularly informed of the company’s future plans and the underpinning technologies for that future, the decision for selecting a TMS would be a much more informed one and, in the long run, more beneficial to the whole company.

IBM and translation

There’s an old saying in tech industry that nobody ever got fired for buying IBM — referring to the fact that it’s a “play it safe” solution albeit a very expensive one. I like that analogy a lot, mostly because it sets the right scene for the last thing I want to mention.

If you’re in the business of creating any kind of a digital product, chances are you’re already applying Agile principles for delivering that product to your users. If we ignore some incorrect applications of Agile methodology, that framework is probably one of key enablers of globally successful products. Unfortunately, what has become a norm in the last decade in tech has still?not gained traction in the localization space.

Just to be clear, I’m not trying to say that localization teams or LSPs should start applying Scrum or anything like that. It’s just a reference to that?painfully visible mismatch between how the translation industry (most LSPs and some tech providers) tells us to approach localization and what that actually looks like in Agile-practicing companies. It’s hard to shake off the feeling that some of them?don’t understand that it’s localization that must be adjusted to the Agile flows, not vice-versa.

There’s almost no time now to do translation in the way it was done in the 90s and 00s. Having translators hidden away from the clients, working with offline tools and within clearly outlined project timelines CANNOT support the needs of an Agile company. So, here’s an unsolicited tip for those working in SaaS product companies — you can learn more about how to set up your localization process from the?Agile manifesto and your engineering peers?than from most LSPs or traditional tech vendors out there.

So, in this case, SaaS companies may run into problems?precisely?because of buying that proverbial IBM — the most expensive option might be the least efficient one.