Long before I’d ever heard the term ‘continuous localization’ I was already very familiar with the problem it’s meant to solve.
I spent years working as an iOS developer before I moved into product. At the time, localization wasn’t my main job but it became one of the many things competing for my attention. Some of the trickiest projects I worked on involved building apps in codebases that needed to handle dozens of countries, address formats, and payment providers with full software internationalization and localization across the lot.
Most teams still handle localization workflows the way I did back then: as a separate track that runs alongside development and a patchwork of time consuming manual workflows. But there are ways to make the process less burdensome.
For some workflows the fix is continuous localization, where translation moves in step with your code instead of on its own schedule. For the rest it’s just about reliable automation, and not asking devs to catch what a system could easily catch instead.
If any of that sounds familiar, this one’s for you. I’m going to walk through five localization workflows that developers (rightly) find infuriating and show you just how much can change when a localization platform handles sync, machine translation, key linking, translation triggers, and context storage, instead of leaving it all to you.
Workflow #1: The swivel-chair integration saga
How do I stop manually syncing translations with my codebase?
Swivel-chair integrations. They’re basically a rite of passage in software localization. You pull the latest resource file from the repo, email it to whoever coordinates localization, they turn it into a spreadsheet, send it to the translation agency, and days (or weeks) later a spreadsheet comes back for you to turn back into property files.
By hand.
One developer I spoke to described how he would extract the files, send them off, and by the time they’d come back, he’d almost always forgotten there was anything pending. Worse, sometimes his team would ship a new build in that time with a second file out for translation before the first one had come back. He’d be left with not one, but two different localization revisions, sometimes with overlapping or divergent translations to merge back into the code.
Sound familiar?
Honestly, there’s no single point of failure here, it’s just that the process is inefficient and disruptive. The fix requires building the process into your localization pipeline instead of routing it through people. Connecting your code repository directly to a translation management system (TMS) means strings can move in both directions automatically instead of passing through emails and spreadsheets.
For example with Phrase that looks like connecting your repository to Strings once. From that point, new strings are pulled in automatically and translation jobs get created and assigned without anyone having to forward a spreadsheet. Once translations are approved, they just sync back to your codebase.
My colleague Michael Blum, who is a Senior Software Developer in our Strings Connect team summed it up nicely: “you don’t even need to log into the Strings platform after connecting it. You only have your codebase, your translation file, commit it into the repository and forget about it.”
Workflow #2: The placeholders nobody warned you about
Why does machine translation keep breaking my code?
Ever had a build break because a translator accidentally deleted a curly bracket?
Human translators and machine translation get placeholders, plural notation, and text that shouldn’t be translated at all (things like brand names and error codes) wrong constantly. And the risk is bigger than a slightly awkward sentence here or there. These errors will break your build and require you to fix each of them manually, delaying your releases.
If you’ve ever tried working around this manually, you’ll know how tedious it can be. You have to strip out anything fragile before sending the text off, then carefully reverse the process on the way back in hoping nothing gets missed in-between.
It’s exactly the kind of task a machine should be handling, not a person double-checking spreadsheets for missing brackets. Unfortunately, it’s not something all general purpose machine translation tools are built to prioritize. The tools that get this right preserve placeholders and tags rather than treating them like any other regular text to translate.
Workflow #3: The language inconsistency drama
Why isn’t terminology consistent across surfaces?
You’d think being able to keep surfaces speaking the same language was a given. But without a shared source of truth for your translations, it’s absolutely not.
I’ve seen this situation play out frequently in businesses with multi-surface setups (aka every business, everywhere). Most companies have a mobile app, a website, and probably some campaign-specific microsites flying around as well. Typically, translation is scoped per-repository instead of per-organization and each surface lives in its own repo, with its own resource file.
Everything’s fine until you notice that your website calls it a “bag” and your app calls it a “cart”.
Usually nobody catches this until it’s already shipped and then it’s a manual fix. Why? Because no single system tracks terminology across every surface. So, now your brand’s terminology is noticeably inconsistent in a way that customers notice and your brand manager is very unhappy.
To solve this you’ve got to treat translation as something shared across your entire organization, so the same term resolves the same way no matter which team or surface it’s used by. That’s what I mean by a ‘shared source of truth’. In Phrase Strings, that looks like shared keys linking the same source text and translation across surfaces.
It buys you fewer inconsistencies and time saved. In other words, “bag” stays “bag” everywhere.
Workflow #4: The human translation bottleneck
Where does continuous localization fit into human translation?
In language translation, human review still plays an important and valuable role. But if you’re still sending individual content pieces through human translators end-to-end for every language (and lots of teams are) delays and slow turnaround times will be unavoidable.
The risk then becomes launch delays and situations where you’re forced to ship incomplete translations (maybe half the interface is still only available in the source language).
Speeding things up doesn’t mean removing human judgement from the process completely. Just make it a review stage wherever quality standards call for it rather than the default step for every string in every language. And, most importantly, after automated translation has already covered the first pass.
That’s continuous localization in practice. Source text gets machine-translated the moment it’s written, with results pushed straight back into the codebase so every language ships at the same time instead of one by one. The human step is still there, it just doesn’t cause a bottleneck anymore. We build this process into Phrase Strings, but the part that matters most is ensuring translation happens at write-time not after the fact.
Workflow #5: The context problem
Why do translators keep asking me the same questions?
If you’re asking this question, you’ve got a context problem.
Property files usually contain a key and the source text only. No context. That means when a translator hits an ambiguous word (does “save” mean rescue, or does it mean the save button?), someone has to go find out.
A request gets forwarded to a developer, who takes a screenshot, writes a description, sends it over, and then the exact same question gets asked again next cycle, because none of that context was stored anywhere permanent.
The way to fix this is giving context somewhere permanent to live. Attaching it to the string itself instead of leaving it scattered across email threads and spreadsheets that nobody keeps track of and that don’t carry from one cycle to the next. Take the way we’ve built it at Phrase as an example. All that context (Figma links, descriptions, notes) lives directly within the key and can be attached automatically through the localization API as keys get created and updated.
Ultimately, the most important thing is that context has a permanent home and the next cycle’s translator can pick it up exactly where it was left off.
What changes when localization stops being manual?
None of the workflow adaptations I’ve discussed replace the people who actually do translation and localization work in your business. They still send out text, check quality, and run content to their cadence. What does change are all the annoying bits that weren’t actually your job but landed on your desk anyway just because you were closest to the code when the process was built.
Exporting files, merging in two places, re-explaining context, chasing down different teams. None of that is coordination you should be doing on top of shipping features, any more than I should have been debugging translation files on top of building a checkout flow for a dozen countries.
Curious what it looks like to hand that coordination off? Talk to us about connecting your workflow to a localization API.
