I Translated a Blog Into 11 Languages Cheaply

I needed to translate an entire blog into eleven languages, every post, with hero images and internal links kept in sync, and I needed to do it without the bill quietly turning into a second project. The naive version of this is easy to imagine. Point the strongest model I have at every file, loop over the languages, and wait. That version works, and it is also the wrong way to do it. The strongest model is the most expensive model, and for the bulk of this work it would have bought me nothing. The interesting part of this build was not the translation itself. It was deciding, per job, which tool was actually right, and then building something that could prove the result was whole when the loop finished.

The Job Was Mostly Mechanical, So I Treated It That Way

The first thing I did was be honest about what kind of work translation actually is. For a blog full of explanatory prose, translation is mostly a mechanical transformation. Take a sentence in one language, produce the equivalent sentence in another, preserve meaning, preserve tone, keep the formatting intact. That is a well-defined problem with a well-defined output, and it is the kind of problem the industry has been solving with dedicated machine-translation systems for years.

It is tempting to reach for a frontier reasoning model because it is sitting right there and it is genuinely good at language. But a reasoning model is built to deliberate. You pay for that deliberation on every token, and most of it is wasted when the task is "say this same thing in French." Reserving the expensive model for this would have multiplied the cost across eleven languages and many posts, and the output would not have been measurably better. Past a certain point, more reasoning does not make a faithful paragraph more faithful. It just makes it slower and more expensive to produce.

So I drew a line. Bulk, high-volume, mechanical translation goes to tools built for exactly that. A dedicated machine-translation API handles the languages it is strong at, and a small, fast, cheap language model handles the rest of the volume and the places where a little flexibility helps. The expensive model stays out of the hot loop entirely. This is the whole thesis of the build, and it is the lesson I want you to take. Cost-aware AI is not about always choosing the cheapest thing. It is about refusing to pay frontier prices for commodity work.

Matching Each Tool To What It Is Good At

In practice the split came down to two workhorses, and knowing which one to point at a given chunk of text.

A dedicated machine-translation API, in my case DeepL, is purpose-built for exactly this transformation. It is fast, it is consistent across a whole batch, and for the language pairs it supports well it produces clean, idiomatic output without me coaxing it. There is no prompt to engineer and no system message to tune. You hand it text and a target language and you get translated text back. For the core of the volume, that is precisely what you want. Consistency across hundreds of posts matters more than cleverness, and a system designed for the task is more consistent than a general model asked to improvise.

A small, fast, cheap language model fills the gaps. There were cases that benefited from a bit more flexibility than a straight machine-translation pass. Strings that needed context to read naturally, the occasional place where a literal translation would have been stilted, or a language where I wanted a second option to compare against. A lightweight model is good enough for that, and it is cheap enough that I could run it freely without watching the meter. The reader cannot tell which tier of model rendered a clean sentence, so paying for the top tier is paying for something nobody receives.

What I deliberately did not do was use a heavyweight reasoning model as the default engine. If a specific edge case had genuinely needed deep reasoning, I would have escalated to it for that case alone. None did. The mechanical majority went to the mechanical tools, and the cost stayed proportional to the work instead of proportional to the model I happened to have access to.

Scripts So Scale Did Not Become Chaos

Translating the words is only half of localizing a blog, and arguably the easier half. The other half is everything around the words. Each language is its own set of pages. Each of those pages needs a hero image, and ideally the same hero image as its counterparts so the visual identity is consistent across the whole site. Each post needs to be converted into the format the blog actually serves and placed in the right location for its language. Internal links have to point at the right targets so a reader in one language does not get bounced into another. Do this by hand across eleven languages and you will make mistakes, and the mistakes will be the silent kind that nobody catches until a reader hits a missing page.

So I wrote scripts to do the assembly. One script syncs hero images across the language variants, so every translated post inherits the correct image rather than relying on me to copy files into eleven folders without slipping. Another converts each translated post into the right format and places it where that language expects it, with its links wired correctly. The point of moving this into scripts is not just speed, although it is much faster. It is determinism. A script does the same thing every time. It does not get bored on the ninth language and forget a step. When the work is mechanical and repeated across many units, the worst tool for it is a human doing it carefully, because careful humans still drift over hundreds of repetitions. Code does not drift.

This is the same principle as the model choice, applied one layer up. The translation engine should be a translation engine. The file plumbing should be a script. Neither of those should be a person, and neither should be an expensive model reasoning its way through a copy operation.

The Audit That Proved The Batch Was Whole

Here is the part I am most glad I built, and the part most people skip. When you fan a job out across many workers the same way I do for eleven languages and a whole library of posts, you cannot eyeball whether it worked. The failure mode is not a loud crash. The failure mode is quiet. One language is missing one post and now there is an orphan, a page that should exist and does not, or a page that links to something with no translated counterpart. One hero image did not sync and now a post renders with a broken image that you will never see because you are not browsing the site in that language. At small scale you would notice. At eleven-language scale, across every post, you will not. The whole thing can be ninety-eight percent right and still feel broken to the specific reader who lands on the two percent.

So I built a parity audit. It checks that every language has every post, so nothing is missing and nothing is orphaned. It checks that every image referenced by every post actually resolves, so there are no broken heroes hiding in a language I do not read. It is not glamorous code. It is a loop that asserts completeness and reports anything that fails the assertion. But it is the difference between hoping the batch is whole and knowing it is. After every run I could look at the audit instead of clicking through hundreds of pages in languages I cannot proofread by eye. If the audit was clean, the batch was clean. If it was not, it told me exactly which language and which post to go fix.

The audit is the safety rail that makes the cheap, automated approach safe to trust. Without it, going fast and going cheap is just a way to ship broken pages quickly. With it, scale stops being a source of silent failure and becomes something you can verify in one pass. The audit is what lets you sleep after pressing go on a job too large to inspect by hand.

What I Would Tell Anyone Doing This

The mistake I see most often is reaching for the most powerful model by reflex, as if capability were free. It is not free, and most work does not need it. Before you point your strongest tool at a job, ask what kind of job it actually is. If it is mechanical, bulk, and well-defined, the right tool is a specialized system or a small cheap model, and the expensive one belongs on the bench until something genuinely hard shows up. Then, whenever you fan that work out across many units, build the audit that proves the result is complete, because at scale the failures hide instead of announcing themselves. Match the tool to the task, and prove the batch is whole. Those two habits did more for this project than any single clever line of code, and they transfer to almost anything you automate.

I build things like this for clients, full-stack apps, AI agents, and automation pipelines, usually shipped faster than expected because I work with AI tooling every day. If you want something built, book a call.