I've spent over 15 years managing localization, from Red Hat's enterprise documentation ecosystem to building real-time AI translation at Reservio. And here's what I’ve learned: as tools become more feature-rich, they often become less useful for the teams that need them most. Let me show you why, in localization, less is often more, and when it absolutely isn’t.
🧑🏻💻 How I accidentally became a localization engineer 🔗
My career as a localization manager started at Red Hat, where I coordinated translators and managed vendor relationships. Their culture demanded technical fluency: everyone had Linux backgrounds, open-source mindsets, and at least some scripting ability. I'd already been writing bash scripts and tinkering with HTML and PHP, so when technical challenges came up that required coding, they landed on my desk.
In fact, I didn’t set out to become a localization engineer. The role found me as I ended up straddling two worlds: classical localization management on one side, engineering and automation on the other. My official title never changed, but my actual work shifted dramatically. Instead of assigning translation tasks, I was building CI/CD integrations. Instead of reviewing translator output, I was training machine translation engines and writing scripts to sync content across platforms, and so on.
At the moment, I see myself professionally sitting between classical localization management and IT engineering. When you’re processing millions of words across large projects, you can prompt AI quite efficiently to use glossaries and make it translate the way you want. For automation, you need someone who can write scripts to integrate localization tools with code repositories, publication platforms, and dev pipelines. And honestly, I think this blend of localization expertise and engineering mindset is the future of how most localization teams will operate.
🛰️ Localization is splitting under the radar 🔗
Nowadays, we seem to be doing less and less of the usual localization management we used to deal with. Vendor coordination, human translator assignments, quality checks on every string… The traditional workflow is increasingly reserved for specific content types that genuinely need it.
Marketing campaigns, brand messaging, content that requires transcreation and deep cultural adaptation — those do need seasoned localization managers who know their translators and can guide nuanced creative work. But product documentation, support knowledge bases, or mobile app UI strings that update daily end up being handled by automation. It simply wins on every metric that matters: speed, cost, and scalability.
We're doing less and less of the usual localization management we used to deal with. Traditional workflows are increasingly reserved for specific content types that genuinely need it. Product documentation, knowledge bases, or mobile app UI strings end up being handled by automation
The industry is quietly splitting into two camps, and most people haven't noticed yet. One camp still needs comprehensive TMS platforms with extensive vendor management. The other thrives on lightweight and API-first tools that integrate seamlessly with development pipelines. I've worked in both, and the engineering approach is spreading fast.
😬 Why ‘heavy’ tools started driving me crazy 🔗
A short recollection of Memsource, now Phrase. When I first started using it, I loved it. Clean interface. A well-documented API that looked like a customizable sandbox for my own use case. A simple spreadsheet view with source strings on the left, target strings on the right. Lightweight, fast. Exactly what I needed.
Then came the evolution. Plugins, proprietary machine translation, integrated AI. Each addition made the platform more "complete" and significantly more expensive. They forced customers toward their own MT engines, limiting access to alternatives, and every new feature came with hidden costs and opaque pricing.
The pattern repeats across the industry: tools add integrations to create value, but each integration becomes a potential failure point. And here's the thing that drove me up the wall: there are always edge cases where integrations don't work.
That's why I prefer to write my own integrations now. I'll make exceptions for truly excellent connections, such as Localazy's Figma plugin or Crowdin's GitHub integration, both working beautifully in my experience. But for custom CMS connections or publication workflows? I'd rather control it myself.
Localization tools tend to add integrations to create value that become potential failure points. They also make their platforms more "complete", opaque and expensive, adding features with hidden costs
🪶 ‘Lightweight’ in localization properly defined 🔗
So, as a localization engineer, what am I actually looking for in a localization tool?
- Documented APIs: If I can't programmatically connect your tool to my development workflow, it doesn't matter how many features you have. API-first architecture is non-negotiable.
- Selective integration: Do a few things exceptionally well rather than attempting to support everything mediocrely. The best lightweight tools excel at core workflows, not everything imaginable.
- Transparent pricing: I need to know what I'll pay when processing millions of words across 20 languages. No surprise costs for volume. No forced bundles of proprietary engines.
Here's what changed my thinking: AI reduced our dependency on traditional TMS features. You can now prompt AI tools to use glossaries effectively and you’re done. Previously, it required sophisticated term bases and translation memory systems. Now, a well-structured prompt achieves the same result.
In addition, vibe coding made programming available to anyone with a basic technical skillset. You can now build your own basic integration, write a Python script to process large data sets, or create a bash script for a server to communicate with your Slack channel.
TMS tools, however, are still essential when you need to collaborate with human translators. At Reservio, even though AI handles initial translation, our TMS provides the interface for human QA. Translators see strings in context and can correct them directly. That workflow still needs a proper platform.
The tools that actually work 🔗
To me, the lightweight philosophy is embodied perfectly in Localazy, together with a couple other tools, like Crowdin, that excel at what matters: documented APIs that let engineers build custom integrations, selective excellence in core workflows rather than mediocre support for everything, and transparent pricing that makes sense at scale. And implementation is fast. If you need to switch tools or add a second platform, it's a week of engineering work, not a migration project.
👉 My choice: a split strategy 🔗
My advice is that you don't have to choose one approach for everything. I use lightweight tools for product documentation and UI strings and traditional workflows for marketing campaigns that need transcreation. The content type usually dictates the treatment.
Before choosing tools or workflows, it is important to answer the following questions:
What's your primary content type? 🔗
Technical documentation, knowledge bases, and UI strings? Go lightweight. Marketing campaigns, brand-critical creative content, or highly specialized fields like legal or medical? Traditional workflows will likely serve you better.
What's your update frequency? 🔗
Daily deployments? Real-time AI makes sense. Monthly releases? You have time for human cycles.
What's your volume? 🔗
Millions of words across dozens of languages? Automation becomes economically necessary. Tens of thousands of words in 3-4 languages? Human translation and/or review remains cost-effective.
What's your team composition? 🔗
Engineers managing localization? Lightweight tools align with their workflows. Traditional localization managers? They'll need comprehensive platforms.
💪 Build systems that scale, not just survive 🔗
A common pattern I see is treating localization as a translation problem when it's actually a system problem. Your localization workflow should match your actual constraints, not some idealized best practice. The hard part isn't choosing between lightweight and heavyweight tools. It's recognizing what your content actually needs and having the courage to build different workflows for different use cases.
And it’s not about doing less work, either. It's about doing the right work at the right time with the right tools, where AI acts as a force multiplier, not a replacement. Its job is to handle volume so humans can focus on nuance. It enables speed so quality assurance can happen thoughtfully rather than frantically. It reduces costs so you can afford expert review where it actually matters.
Your localization workflow should match your actual constraints, not some idealized best practice. You need to recognize what your content needs and build different workflows for different use cases
Early in my career, I thought success meant finding the perfect tool or the best translators. Now I know it's about building processes that don't break under pressure.
💙 A note about Localazy's lightweight philosophy 🔗
In the words of the Localazy CEO, Václav Hodek... ⬇️
"We build Localazy around a simple principle: AI handles volume so humans can focus on detail. A functional TMS shouldn’t be a bottleneck. It should drive the localization process forward.
The real value of localization isn’t in handling files or running automatic translations. Any modern TMS can do that. The real value is enabling collaboration between translators, developers, and reviewers to deliver translations your users can trust.
Localazy takes care of the entire localization infrastructure. Configure the workflow once, define quality gates, set translation triggers, specify who reviews what, and Localazy runs it automatically. Your localization team handles context, nuance, and quality, while you stay focused on building your product and shipping features without interruption. This gives you translation management that doesn't slow development and full control over the automation. Tools coordinate both AI and human translators without requiring your attention.
Lightweight doesn't mean fragile. It means intentional."
