DEV Community: Aditya Nile

I Tried to Translate a 300-Page Scanned Textbook to Marathi: Here's Why "OCR + Translate" Isn't Enough

Aditya Nile — Sat, 18 Jul 2026 12:41:23 +0000

I needed to convert a 300-page scanned English textbook into Marathi while keeping the original layout intact — headings, tables, the works. The "obvious" approach (OCR the pages, translate the text) works right up until it doesn't: OCR throws away structure, and generic machine translation throws away meaning the moment your input has any noise in it. This post walks through the four architectures I evaluated, the one bug that killed my first real approach, and the pipeline I ended up shipping for under $5.

Repo: github.com/adityanile/BookTranslationPipeline

The problem

Scanned English textbook. 300 pages. Old print, imperfect scans, dense paragraphs, tables, section headers. Goal: Marathi translation that looks like the original — not a wall of translated text that's lost every bit of structure the source had.

Three things had to be true at the end of this:

Layout preserved. Headings stay headings. Tables stay tables. Reading order stays intact.
Meaning preserved. This is literary/educational content — word-for-word translation that mangles meaning is worse than useless.
Proportionate effort. This is a one-time job, not a product. It doesn't need a platform, it needs a script that works.

First attempt: the "obvious" pipeline

Step one was Azure Document Intelligence's Read API solid OCR, extracts text cleanly. Except the moment you extract to plain text, you lose all structural information. Tables become soup. Headings look identical to body text. That's a non-starter when layout preservation is a hard requirement.

So I moved to Azure AI Content Understanding, which outputs Markdown instead of flat text meaning headings, tables, and reading order survive extraction as actual Markdown syntax (#, |, list markers) rather than getting flattened. This solved layout. It did not solve translation.

Four ways to translate the extracted text

At this point I had clean, structured English Markdown for every page. The question became: what actually translates it well? I evaluated four options.

#	Approach	The catch
1	Multimodal LLM directly on page images	Simple, but no guaranteed formatting consistency across 300 independently-prompted pages
2	Markdown → raw LLM translation call	Great quality, but ~5x the per-page cost of what I ended up using
3	Markdown → Azure Translator (GPT-5.1 backed mode)	Cheapest, and — this is the twist — the most robust
4	Feed the scanned PDF straight to Azure Document Translation	One API call, internal OCR — but zero visibility into what it's actually extracting or how it reconstructs the layout

Cost, on its own, barely separated these at 300 pages, every option landed somewhere between $5 and $25 total. The real differentiator turned out to be something I hadn't planned to test for.

The bug that decided the architecture

Old scanned print isn't clean. Content Understanding, running OCR on aged pages, occasionally produced small artifacts the kind of thing you'd never catch by eyeballing a summary. One page had the word "oral" extracted as "or al."

Here's where it got interesting. I ran that corrupted fragment through two different translation paths:

Azure Translator's classical NMT engine (the default, statistical model): translated it literally — "or" and "al" as separate fragments — and quietly changed the meaning of the sentence. No error, no warning. Just wrong.
Azure Translator's GPT-5.1-backed mode (Azure now offers "flexible translation" through foundation models, not just the classical engine): correctly inferred the intended word from context and translated the sentence properly.

That one test case ruled out the default translation engine entirely. It wasn't a fluency preference — it was a correctness requirement. If your source material has any realistic noise in it (and scanned historical print always does), a foundation-model-backed translator isn't a nice-to-have. It's the difference between a pipeline that silently corrupts meaning and one that doesn't.

The architecture I shipped

Scanned Pages
     │
     ▼
Content Understanding  ──► Markdown (structure preserved)
     │
     ▼
Storage (Source / Markdown / Target containers)
     │
     ▼
Azure AI Translator — Text Translation, GPT-5.1 backed
     │
     ▼
Marathi Markdown (structure intact, meaning intact)

A Python script orchestrates the whole thing — no Durable Functions, no Logic Apps, no managed workflow engine. This was a deliberate call: it's a one-time job, and a manifest-driven script that tracks each page through extracted → translated → done gives you the same resumability a hosted orchestrator would, without any of the deployment overhead. If a run dies at page 220 of 300, you rerun the same command and it picks up where it left off.

Three storage containers Source, Markdown, Target act as durable checkpoints between stages. The Markdown checkpoint matters more than it looks: it's an inspectable, human-readable English artifact you can spot-check before you spend a single translation call on it. Skip that checkpoint (like Option 4 does, translating straight from the scanned PDF) and you lose your only chance to catch an extraction error before it's baked permanently into the output.

Managed Identity handles all service-to-service auth no keys sitting in config files.

What it actually cost

Stage	Cost
Content Understanding extraction	~$1.50
Contextualization overhead	~$0.30
Translation (GPT-5.1 backed, via Translator)	effectively $0 — inside the 2M characters/month free tier
Total for the full 300-page book	under $5

Routing translation through the managed Translator service instead of calling a foundation model directly for full-page translation is what made this free the free-tier character allowance doesn't exist for raw model calls, only for the Translator service itself.

What I'd tell past-me

Test your worst input, not your average input. The whole architecture pivoted on one degraded OCR case. If I'd only benchmarked against clean pages, I'd have shipped the classical NMT path and never known it was silently mistranslating noisy sections.
Keep an inspectable checkpoint between every stage that costs money. Going straight from scan to translated output is simpler to build and much harder to debug when something's wrong three stages downstream.
Don't reach for a managed orchestrator out of habit. Durable Functions is the right tool for a recurring pipeline. For a run-once job, a manifest file and a plain Python script gets you the same reliability guarantees for a fraction of the setup.
"GPT-backed" translation isn't just a quality upgrade sometimes it's the only thing standing between you and silently wrong output.

Full implementation, orchestrator code, and the architecture diagram are in the repo: github.com/adityanile/BookTranslationPipeline

If you're building something similar — scanned documents, layout preservation, low-resource language pairs happy to talk through what worked and what didn't. Drop a comment or open an issue on the repo.

AKS vs VMs: what I learned scaling a multi-region AI platform on Azure

Aditya Nile — Wed, 01 Jul 2026 19:00:50 +0000

When I started designing the infrastructure for Clynto AI an AI-first Customer Success platform launching in both the US and India at the same time the first real decision wasn't which cloud to use. It was simpler than that, and also harder: do we run this on VMs, or do we put it on Kubernetes from day one?

There's a version of this post that just says "Kubernetes wins, obviously." That's not useful to anyone actually making the call. So instead, here's what the VM path would have actually cost us, what AKS bought us, and where I think VMs would still have been the right answer if Clynto's requirements were different.

The full architecture, CI/CD pipeline, and implementation write-up for this build are in the Clynto AI case study repo if you want the complete picture beyond this comparison.

The setup

Clynto needed two regions East US and Central India each with its own production and staging environment, each carrying different compliance obligations (GDPR in one, PCI-DSS in the other), all behind three public domains routed through a single edge. It's a small platform team's worth of complexity for what's still an early-stage company.

Azure Front Door routes by domain and tenant to regional Application Gateways, which front isolated prod/staging AKS environments in East US and Central India.

That last part matters. A lot of the AKS-vs-VM debate online assumes you're either a five-person startup or a thousand-engineer org, and the answer to "use Kubernetes?" looks different at each end. Clynto sat in an uncomfortable middle: compliance and multi-region requirements of a bigger company, headcount of a much smaller one. That tension is what actually decided this, not a general preference for containers.

Where VMs would have struggled

If I'd gone with VM-based deployment say, VM Scale Sets behind a Load Balancer, which is the natural Azure equivalent here's where it would have gotten painful:

Replicating two regions by hand. With VMs, "mirror this environment in another region" usually means re-running a setup script, or maintaining two slightly-diverging sets of ARM templates / Ansible playbooks. With AKS, the cluster is just another Terraform module with a different region variable. I provisioned both regions' clusters, and both environments (prod/staging) within them, off the same module set. The VM version of this would have meant four mostly-similar-but-not-identical environments to keep in sync by hand.

Enforcing policy below the application layer. A chunk of Clynto's compliance requirement isn't "is the app secure," it's "can we prove the platform itself enforces controls." On VMs, that means OS hardening baselines, config management tooling, and manual audits of who can SSH into what. On AKS, Kyverno enforces policy at the Kubernetes API level no privileged containers, no images from outside the approved registry and that's enforced automatically on every deploy, not checked quarterly.

Zero-touch deployment. GitOps with Argo CD means there's no ssh step in the release process at all. On a VM fleet, even a well-built CI/CD pipeline usually ends in something touching the box directly a deployment script, a config push, a service restart. That's a smaller surface area difference than people think, but it's a real one when you're trying to make "no manual production access" a literal architectural guarantee instead of a policy on paper.

Bin-packing under unpredictable AI workload. Clynto's workloads sit next to Azure OpenAI calls through Microsoft Foundry, and load isn't steady it spikes with usage patterns that don't map cleanly to a fixed VM count. I used the Vertical Pod Autoscaler to right-size pod resource requests and tuned Horizontal Pod Autoscaling against real Azure Monitor metrics. Getting equivalent elasticity out of a VM Scale Set means scaling whole machines up and down, which is coarser and slower, and it's harder to right-size a VM than a pod.

Where VMs would have actually been fine or better

I want to be fair to the other side of this, because most "AKS is better" posts skip it.

If Clynto were single-region, single-environment, low-compliance-burden say, a single-tenant internal tool a couple of VMs behind a load balancer would have been less infrastructure to operate, less to learn, and genuinely simpler to reason about. Kubernetes has a real operational tax: cluster upgrades, node pool management, learning Argo CD and Kyverno in the first place. If you don't need the multi-region or policy-enforcement benefits, you're paying that tax for nothing.

If the workload were a single monolith with predictable, steady load, autoscaling pods buys you very little over a couple of right-sized VMs with a basic autoscale rule. The complexity of containerizing an app that doesn't need to scale dynamically is sometimes just complexity.

Debugging is genuinely harder on Kubernetes when something goes wrong at 2am. A VM you can SSH into and look at logs directly. A pod that's crash-looping inside a cluster with network policies and admission controllers has more layers between you and the problem. I don't think this is a reason to avoid AKS for Clynto's case, but it's a real cost, not a myth.

What actually tipped it for Clynto

Two regions, two compliance regimes, a staging environment that needed to be a faithful mirror of prod, and a one-person platform team trying to keep all of that consistent without drowning in manual config drift. That combination is where Kubernetes specifically AKS with Terraform, Argo CD, and Kyverno earns its complexity. Not because containers are inherently superior to VMs, but because the thing I actually needed wasn't "run my app," it was "run four nearly-identical, policy-enforced, audit-ready environments without doing the same setup four times by hand."

If you're making this call for your own platform, the question I'd actually ask isn't "Kubernetes or VMs" it's "how many environments do I need to keep consistent, and how much of my compliance story needs to be enforced by the platform instead of by a person checking a box."

This post is based on an independent freelance engagement as the Azure Cloud Architect for Clynto AI. Architecture and implementation details reflect the actual platform delivered.