TMS-centric localization

Figure 1 reflects some of the largest issues in managing TMS-centric localization programs, which cause bottlenecks and lack cross-department collaboration.

Global content scaling used to be about the number of languages a product is able to support. However, as companies grow, so does their content structure. Combine that with the speed and volume of content generation that AI enables, and we’re now dealing with an equation that essentially multiplies the number of languages by the number of content entry points. This means that a TMS-centric localization now needs to support not just the language count — a substantial consideration on its own — but also content coming in from an increasing number of sources throughout the organization.

After discussing this with a sizable pool of start-up and scale-up founders and localization managers, the overwhelming consensus is that this is where a localization infrastructure centered around a TMS is starting to fall off. Buyers that increase the number of content-based services around their product beyond TMS capacities again are facing manual string management and content labor that the TMS was introduced to eliminate in the first place.

Component-based localization

Instead of making the TMS a centerpiece, organizations can use it as part of a larger content ecosystem and as a component for string management, as illustrated in Figure 2. This eliminates the bottleneck of content flow and empowers product teams to handle localization at their own pace and on their own terms. In addition, in-house localization teams are no longer overloaded with manual string management, but instead function as an organizational support communication facilitator and fulfill a strategic role for content operations as a whole. For organizations without localization teams, an LSP can fill that role effectively.

In a component-based system, integrators are the backbone for the whole infrastructure. An integrator can be visualized as a highway that creates two-way exits and entrances for components, as well as purposeful loops that lead content through different stages before returning back on the highway and finally arriving at the final destination: the customer. I also like to think about it as a physical backbone that connects the nerves throughout the body and creates a unified, living organism of interlocking content.

Beyond content fluidity, there are other benefits of applying component-based thinking when it comes to localization program management. Some of them are financially beneficial, while others allow for unlimited feature and component testing. Having the choice and the ability to add and remove components needed at a particular point in a product’s content journey enables companies to handle costs associated with each component. Let’s say you need to generate a synthetic voiceover of your blogs to increase exposure and enable your users to consume your content on the go. This is not a feature you’ll need indefinitely. An integrator easily adds this functionality to your ecosystem, and when the job is done, removes the feature that is no longer being used.

We can also look at machine translation (MT) functionality as an example. An integrator-first structure allows companies to add, test, and evaluate MT engines to find the right fit for their language and content specifics. While this is partially enabled by a TMS, the versatility really opens up when we look beyond the offerings provided through a TMS.