Building a Translation Pipeline at the Edge in the AI Era

A few weekends ago I tried something. I wanted to see if I could build a working multilingual version of my blog using only AI translation, edge compute, and a small amount of glue code. No managed translation service. No long contract. Just modern building blocks, wired together at the edge.

It worked. My blog at sbtechlabs.blog now has a Spanish version at espanol.sbtechlabs.blog. The same English source content is rendered in Spanish on the fly, with a custom-trained translation model handling anything the approved Translation Memory does not cover. Total cost so far is about a quarter. Steady-state monthly cost is in the tens of dollars.

What surprised me was not that it worked. It was how natural the architecture felt now compared to even two years ago. The pieces are mature. The pricing is friendly. The control surface is clean. The AI era really did change what is possible here, and I think more enterprises should know about it.

This is the high-level story of what I built and why it matters. If you want the technical details, the source code, or a working demo, reach out through the Contact Me page on this site.

What I built

A user lands on espanol.sbtechlabs.blog. Behind the scenes, a small piece of edge compute fetches the English source, walks the page, and serves a fully Spanish version. There is no separate Spanish content authored anywhere. One source of truth. Two languages. A simple toggle in the site header switches between them.

The translation work happens in three layers, tried in order.

The first layer is a Translation Memory. These are the approved Spanish translations I curated by hand. They live in a standard TMX file in the source repository. When the edge worker sees an English string that matches an approved entry, it uses the approved translation directly. No AI involved.

The second layer is a machine translation cache. When the Translation Memory does not have an entry, the worker checks a cache of previous AI outputs. If the same string was translated before, the cached result is reused.

The third layer is a custom-trained AI translation model. When both the Translation Memory and the cache miss, the worker calls the model with the English text. The model returns Spanish. The worker uses the result for the response and writes it to the cache for next time.

The model is custom-trained on the same Translation Memory I use as Tier 1. That means it already knows my preferred terminology, my brand names, and the phrasing I want preserved. Generic AI translation can be hit or miss on terminology. A custom-trained model is much closer to publication quality out of the box.

The diagram for this post shows the full picture, including the approval and promotion flow that closes the loop between AI outputs and the system of record.

Why this is interesting now

Translation has been a well-understood problem for enterprise sites for over a decade. The standard approach is a managed reverse-proxy service that handles the entire pipeline. That model has worked for many companies and continues to work. The interesting question now is whether there is a complementary path that gives teams more direct control over the parts they want to own.

What is new is that the underlying technology has become a commodity. AI translation models are now good enough out of the box to handle most content with a small amount of customization. Edge compute platforms make it trivial to put a worker between users and an origin. Object storage costs essentially nothing at the scale of a typical website. Custom-trained models can be created in a portal in under an hour and called via a standard API.

In the AI era, all the components of an enterprise translation pipeline are available as separate services. Each one is mature, well-documented, and priced for individual use. You no longer have to buy them as a single bundle from a vendor that sits in the request path.

This is the same shift that happened with email, hosting, content delivery, search, and analytics. Each of those used to be an enterprise contract with a single provider. Now each is a stack of replaceable parts you can assemble to fit your needs. Translation is the next domain where this shift is happening.

Three things enterprises gain

When I think about what an enterprise gains by building this kind of pipeline themselves, three things stand out.

Cost predictability. Most translation contracts price by character or by word. The meter never stops. With a self-built pipeline, your costs are dominated by the AI model fee plus a tiny amount of edge compute and storage. The cache eliminates re-translation of the same string. After a page has been visited a few times, the marginal cost of serving a localized version of that page is essentially zero. Your monthly bill stops scaling linearly with traffic.

Control over the request path. When you own the edge code, you decide what happens in a request. You can apply business logic mid-request. You can route specific URLs differently. You can integrate with your authentication. You can selectively bypass translation for legal pages, regulatory disclosures, or sensitive content. None of this is easy when the translation layer is a managed service that owns the request lifecycle.

Control over the model and terminology. The custom-trained model is yours. The training data is your Translation Memory, in your repository. Your trademarks and approved phrasing are not mixed with another customer's data. You can retrain on your own schedule. You can audit every translation. You can run linguistic quality assurance on your own cadence. Updates to terminology flow from your TMX into the model, and the next call benefits from the change.

These three things together change the conversation. Translation becomes an internal capability rather than an external dependency.

How the cost actually plays out

For my blog, the numbers are concrete.

About 20 to 30 page loads during the build phase. Each fresh page sent 30 to 50 strings to the AI for translation. Total characters translated during testing was around 15,000.

Cost so far: about 15 to 25 cents.

After the cache warmed up, repeat visits to any page returned zero outgoing AI calls. Spanish content is served from cache.

Steady-state monthly cost: roughly 10 to 15 dollars a month, dominated by the hosted model fee.

For an enterprise site at much larger scale, the math gets even more favorable. Cache hit rate goes up with traffic. Per-page translation cost goes down as more pages have been seen at least once. A site that publishes a few articles a week with millions of monthly visits would be looking at low hundreds of dollars a month in translation infrastructure. The exact number depends on content volume and how often the model needs to be retrained, but the order of magnitude is consistent.

The bigger insight is that runtime cost is no longer the bottleneck. When the runtime is essentially free, enterprises can spend the budget on the parts that actually matter: linguistic review, terminology curation, and publishing workflow.

The high-level steps

The build was about a week of focused work. Here is the order I followed.

Set up the edge infrastructure. Create a worker. Bind it to a custom subdomain. Add object storage for the Translation Memory and the AI cache. Add a small key-value store for tracking daily usage.

Author the Translation Memory. I curated 100+ segments by hand. For an enterprise, this would start with the existing Translation Memory exported from the current setup. The TMX format is open and portable.

Set up the custom AI translation model. Create a project. Upload the TMX as training data. Train. Publish. The platform returns an identifier the worker uses on every API call to route requests to the trained model.

Write the worker code. The cascade logic is straightforward. Walk the page. For each translatable text node, check Translation Memory, then the cache, then the AI model. Apply translations on the way back. Cache the new ones for next time.

Add cost guardrails. A per-text-node character cap. A per-request character cap. A per-day character cap. Bot user-agent detection that skips translation entirely. These four limits put a hard ceiling on the bill regardless of traffic patterns.

Test, tune, and verify. This is where I hit and resolved a few interesting bugs. The details are worth a separate conversation, but none were blocking.

Closing the loop with approval and promotion

The runtime cascade is enough for a personal blog. For an enterprise site there is a second loop that matters just as much. Anything the AI produces should be reviewed by a human before it counts as approved. And once it is approved, that approval should flow back into the system of record so the same string never has to be machine-translated again.

This is the bottom zone of the diagram. Here is how it works.

Pending state. When the AI translates a string, the worker writes it to the cache with a status of auto. The user gets the translation immediately, but the system knows it has not been reviewed.

Approval dashboard. A reviewer opens a separate admin interface that lists every pending entry. Each row shows the source, the AI output, the timestamp, and three actions: Approve, Edit, Reject.

Promotion to the system of record. Approved entries are exported in TMX format and appended to the Translation Memory file in the source repository. The TMX file is the durable system of record.

Two downstream updates triggered by the commit. First, the build pipeline regenerates the runtime Translation Memory in object storage so future page loads hit the approved tier directly with no AI call needed. Second, the same TMX is uploaded to the model training project and the model is retrained. The retrained model knows your terminology preferences and translates similar phrases more consistently going forward.

The whole loop runs on a cadence that fits your team. A weekly approval review and a monthly retraining cycle is realistic for most enterprise sites.

What is special about this loop is how the AI gets smarter over time without any heavy ML engineering. Every approved correction becomes training data. The model that translates next month's content has been shaped by the corrections the team made on this month's content. Quality compounds.

The AI era in one sentence

The pieces that used to live inside a managed translation contract are now individually available as commodity services, and an AI translation model that has been custom-trained on your Translation Memory is good enough to be the engine of a real production pipeline.

That is the shift. The technology is here. It is mature. It is cheap to run. It is yours to control.

What is built and what is next

The runtime cascade is built and running on my blog right now. Visit espanol.sbtechlabs.blog and you can watch it work. The architecture diagram shows the full picture including the governance flow.

The approval dashboard, the promotion job, and the retraining trigger are designed but not yet implemented. They are the next milestone for this experiment. They are not architecture changes. They are governance tooling on top of what already exists.

For an enterprise rolling this out, the runtime is the easy part. The governance flow is where the real engagement happens. Approval workflows, audit logs, role separation, integration with existing translation management systems, all of that belongs in the bottom zone of the diagram and all of it is where the value is delivered.

Want to know more

This post is the high-level overview. The implementation has interesting details, including the actual worker code, the bug fixes that came out of testing, the cost guardrail logic, and what a migration path looks like for an enterprise that already has a Translation Memory and wants to bring translation in-house.

If you are responsible for translation modernization at an enterprise, or you are exploring what AI-driven options look like compared to your current setup, I would love to talk. Use the Contact Me page on this site to reach out. I am happy to walk through the implementation, share the source, and discuss what migration could look like for your specific situation.

We are in a moment where the technology to build this kind of pipeline is finally accessible to anyone who wants to assemble the parts. The harder questions are about governance, change management, and helping a team get comfortable with a new way of working. Those are the conversations I find most interesting.