When Translation Stops Being a Task
At first, it’s just “one more language.” A duplicate entry. A few copied fields. Someone double-checks relations. Someone else fixes formatting. It’s annoying, but manageable.
Then content keeps growing.
More pages. More components. More dynamic zones. More people touching the same entries. Suddenly translation is no longer a task—it’s a process. And that process starts leaking time, confidence, and consistency in places that are hard to explain but easy to feel.
What makes this worse is that nothing is technically broken. Pages publish. Content exists. Yet every new locale increases friction. Every update feels risky. Every manual step becomes another place things can silently go wrong.
This is the point where teams usually argue about tools, costs, or headcount.
That’s the wrong conversation.
The real issue isn’t language. It’s scale. And scale doesn’t care how careful you are—it only responds to systems.
This case study looks at what happens when translation is treated not as a feature, not as a button, but as infrastructure.
Why not use Strapi’s built-in AI translator?
It’s not automated, offers limited support for bulk translation, and still requires manual work to set up relations, publish pages, and handle images. Once you manage more than 10 languages with a small team, doing this by hand stops being realistic.
Solution Architecture and Data Flow
A custom translation extension for Strapi CMS that processes translations as background jobs with real-time progress tracking, handles complex nested content structures such as components, dynamic zones, and blocks, and preserves HTML, Markdown, URLs, placeholders, and other special formatting.
It also supports job cancellation, retry logic, and robust error recovery, while providing a polished admin UI that allows users to select models and configure translation settings with ease.
Key Features
Background Job System
Translations are processed as background jobs managed by a dedicated job manager. This enables long-running operations, real-time progress tracking, cancellation, and retry behavior without blocking the Strapi admin UI.
Smart Content Extraction
A content extractor walks Strapi entries, components, and dynamic zones to locate translatable fields while preserving non-translatable structures like IDs, relations, and media references.
Multi-Model Support
The translator supports multiple OpenAI GPT models so teams can balance cost, speed, and quality depending on the project and target locale.
Intelligent Batching
Fields are grouped into batches to keep token usage efficient while staying within rate limits. This batching is key to reaching 1000+ pages within a 24-hour window.
Translation Behavior Settings
Admins can configure how literally or loosely content should be translated, whether to preserve brand terms, and how to handle placeholders, HTML, and Markdown.
Prompts sent to GPT models are configurable, making it possible to tune tone of voice, formality, and locale-specific preferences per project.
Relation Handling
The system respects and rebuilds relations between entries after translation so localized content remains correctly linked across locales.
Throughput and 1000 Pages Estimation
Assuming an average of 50 translatable fields per page and 5 target languages:
1000 pages × 50 fields = 50,000 fields to translate
50,000 fields ÷ 20 batch size = 2,500 API calls
2,500 calls × 5 seconds average = 12,500 seconds =
~3.5 hours per language
5 languages × 3.5 hours = ~17.5 hours total
+ Overhead (extraction, saving, relations) = ~20–24 hoursWhat's Next
Once content reaches a certain size, effort stops scaling linearly.
What works at ten pages quietly breaks at a hundred. What feels manageable in one language becomes fragile across ten. Not because people stop caring—but because manual processes don’t survive growth.
The most expensive failures are rarely obvious. They show up as hesitation to edit content, fear of publishing, or workflows no one fully trusts anymore. By the time these problems are visible, they’ve usually been around for a while.
That realization is what led us here.
This translation system didn’t begin as a product or a feature—it began as a response to real constraints in a production environment. And it quickly became clear that this problem isn’t unique to one team or one project.
So we’re opening it up.
We’re preparing to open source the entire system—not a demo, not a simplified example, but the actual infrastructure that runs this pipeline in production. The job system, the content handling logic, the batching strategies, the safeguards—everything that makes it work at scale.
We’re currently finalizing documentation and cleaning the last rough edges before publishing the repository.
If you want to know when it goes live, get early access, or follow how this evolves in the open, subscribe.
I also share practical lessons from building and running systems like this—CMS scaling, AI in production, and the tradeoffs that don’t show up in tutorials.
No hype. No fluff. Just things that work.
If that sounds useful, you know what to do.
