Why the best product localization stories are the ones nobody tells (and how product teams get there)

The best market launches are the ones you forget happened. 

No last-minute translation scramble and no war room…just a new locale going live roughly on time while the team gets on with the next thing.

Call it the non-event: localization that ships without anyone noticing it did. For product managers running global products, that’s the ambition, and the teams who reach it are usually closer than they assume. It’s a little like being a goalkeeper or drummer: when you’re doing it right, no one notices you. But what gets them there has less to do with budget or tooling than with how localization was set up to work in the first place. 

Most teams start out doing it by hand: files shared over Slack, translators chased across time zones, or handoffs held together by goodwill. It works until the product grows and the number of connected systems climbs, at which point the manual approach starts to fall behind. What follows maps the gap between that and the non-event, drawn from conversations with four people at Phrase who work on it every day.

Scale is a systems problem before it is a language problem

The first thing worth rethinking is the unit of measurement. Teams tend to size up localization by language count: five feels manageable, fifteen serious, twenty-five a different kind of operation. It’s the wrong measure.

As Jozsef Hodos, a senior product manager on Phrase’s integrations team, puts it: “Scale isn’t how many languages you support. It’s how many systems you’re managing.”

Picture a team running five languages across half a dozen systems: a CMS, a help desk, a mobile codebase, a marketing tool, a documentation site. It can be carrying more load than a team running fifteen languages through one well-configured integration.

Languages drive translation volume. Systems drive maintenance, and maintenance is the cost that builds up until it starts setting the agenda.

So the better question is about systems, not languages: how many need to talk to each other, and who gets the call when one of them changes?

Building integrations is easy. Maintaining them is the cost.

When manual localization starts to chafe, the instinct is to build something: a custom connector, a point-to-point API integration, a script that moves files from one place to another. It’s reasonable. The team knows its stack, the problem looks specific, and building in-house avoids another vendor dependency. The first version works, and the problem looks solved. Then time passes.

Integrations like these aren’t hard to build, Jozsef says, having spent the past year on exactly this with customers. The trouble comes later: “they are super challenging to maintain.” Localization brings requirements a developer may not anticipate, like how layout behaves in right-to-left scripts, or how content needs structuring to stay useful in a translation memory. Edge cases that never showed up in testing appear in production, and because these integrations get built one at a time, each carries its own quirks and its own upkeep.

Infrastructure teams call this deferred maintenance: a cost that goes unnoticed while everything works, then shows up later in a worse form.

The wider economics reinforce it. Nimdzi’s connector analysis found native integrations across ten major TMS platforms reach under 13% of the business applications enterprises commonly use, which leaves the rest to custom work. And custom work is where the cost hides. In its 2026 review of the TMS market, Nimdzi warns that teams now tempted to build their own tooling with AI “often underestimate the timeline, complexity, and change management for creation, launch, and maintenance of such tools.” The first version is rarely the expensive part.

Where native integrations still need real work

The alternative is to use native integrations: connectors a platform maintains for you. That removes the build and the upkeep, and raises a different question, getting them configured well.

Even more correct would be: Take Automated Project Creation, which spots new content in a connected platform via an integration and automatically opens a translation project. Done well, it’s what makes localization close to invisible: content appears, a project opens, translations come back. In practice, Tomáš Doischer, Phrase’s integrations team lead, says most setups need a second pass to get right. Every environment is different enough that no template fits cleanly, however skilled the team.

There’s an organizational dimension that rarely gets enough airtime. Localization managers are experts in localization, but the systems they connect to are usually owned by other people: the CMS by the web team, the CRM by sales, and the drive where marketing keeps its assets. Setting up an integration needs credentials and access a localization manager often can’t grant alone, which creates dependencies across teams that don’t work together day to day.

Anyone who’s run one of these projects knows the shape: the person with the credentials doesn’t work in localization, the person who lives in localization doesn’t have the credentials, and the administrator who could bridge the two is on holiday until Thursday. That’s where the real work lives, and it’s the most useful thing to know before you start.

Why preparation beats technical firepower

Alejandro Medina, an enterprise solutions architect at Phrase, has run enough of these projects to know what separates the smooth ones from the painful ones, and it isn’t technical horsepower: “The specific role or technical background of who’s involved doesn’t determine success. What matters most is understanding the client’s environment and asking the right questions.”

He describes two teams with near-identical setups. One was integrating GitHub across four repositories. Before configuring anything, they read the documentation and spotted a problem: working in pull-request branches whose names changed each release would clash with how the integration tracked content. So they redesigned the workflow first, scheduling imports through the integration and handling exports through GitHub Actions. The second team, almost the same setup, hit the same issue weeks after going live. Same integration, very different week.

The flip side of good scoping is what it makes possible. Phrase’s Figma integration with Phrase Strings is a neat example: when designers create translation keys in Figma, the integration pulls screenshots and automatically highlights the position of each string. Translators see the source in its real visual context, a button or a settings screen, without anyone preparing it by hand, and nobody’s left guessing what “btn_confirm_2” means. The context travels with the content.

As Francesca Sorrentino, our Director of Localization, puts it: “Integrations are the foundational layer. But they don’t solve every problem in a full use case. The teams that get this right understand what the integration is for and build around it accordingly.”

The teams that do well aren’t the most technical. They’re the ones who understand their own setup before they automate it, and that, more than any connector, is what keeps a launch calm.

The earlier product managers get involved, the smaller the problem

Product managers usually arrive once something has gone sideways. They’re useful then, often the only person who can see how the systems connect and what the feature is actually meant to do. But by then the scope is set, and the best contribution has passed.

What changes when they’re involved earlier is that the information localization most needs lives with them: what the feature does, where its content appears, and which markets are in scope. That rarely reaches localization in any structured way. An engineer picks up a ticket, creates the keys, pushes the code. The localization manager gets the keys, and the context that would let them brief translators before the work lands is gone.

That missing context is the difference between a translator who knows what a string means and one guessing from a key name.

Marty Cagan and Bob Baxley, writing about global product management on the Silicon Valley Product Group blog, name the error: localization gets treated as a downstream handoff rather than a platform concern, something to design for rather than bolt on. Aude Moras, Head of Product at Tablecheck, puts it more bluntly: “You don’t want to get ready for the market and then two weeks before launch start thinking about localization.”

Tomáš Doischer’s (Team Lead, Integrations at Phrase) version lands in the same place. He says the failure he sees most often is teams recreating their old workflow in a new system instead of asking what it was for: “Mapping your old process one-to-one to a new system is like trying to apply your recipe for making pizza to making hamburgers. Focus on what problem the existing process was solving. Then design for that outcome.”

In my view, this is the product manager’s key contribution:
Well before anything catches fire, they bring the timing and the product context into the room early enough for localization to be built in, rather than bolted on at the end with a request to make it global by Friday.