build.allanninal.dev

Part 1 of 7 · Translation relay series ~5 min read

A translation relay on AWS for a few dollars a month

A small business sells to people who don’t all speak the same language. A customer in São Paulo writes in Portuguese. A supplier in Osaka replies in Japanese. A new buyer in Berlin asks a question in German. Your support team speaks English and maybe one other language between them. Hiring a fluent speaker for every market isn’t realistic, and pasting messages into a free translate box is slow, leaks customer data, and quietly mangles the one figure that mattered. This post walks through the design of a small relay that translates each message in, lets a human write the reply, and translates that reply back — while keeping every name and price exact.

Key takeaways

  • Messages arrive two ways: by email and through a small web widget on your site.
  • Three pieces inside AWS: detect the language, translate in for staff, translate the staff reply back.
  • A person always writes the reply. The relay never sends a machine-written message to a customer.
  • Names, numbers, and prices are locked before translation and put back after, so they stay exact.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: two inputs, three pieces inside AWS At the top, three external boxes in a row. Far left, "Customer message" — a note arriving in any language, either by email to your support address or through a small web widget on your site. Centre, "Glossary and voice" — a Drive folder with a glossary of protected terms (brand names, product names, account IDs that must never be translated) plus a short note on your team's working language and tone. Far right, "Your team" — the staff members who read the translated message and write the reply in their own language; the customer only ever sees their own language. Each connects via an arrow to the AWS account container below. The customer message has an outgoing arrow into AWS. Glossary and voice feed in to keep every translation grounded. Your team receives the translated message with the original alongside, writes a reply, and sees a plain-language check before it sends. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Detect — reads which language the incoming message is in, cleans off signatures and quoted history. In the middle, the Translate-in — turns the customer message into the team's language, masks protected terms first, and flags low-confidence passages. On the right, the Translate-back — takes the human-written reply, turns it back into the customer's language, shows a round-trip check, and waits for a person to press send. Internal arrows flow left to right. A note at the bottom reads: a person always writes the reply — the relay translates, it never speaks for you. Customer message email or web widget Glossary and voice terms, language, tone Your team reads and replies message in grounds reply written here AWS account Detect clean the message, read its language Translate-in into team language, flag what's unsure Translate-back human reply out, round-trip check text reply A person always writes the reply — the relay translates, it never speaks for you.
Fig 1. Two inputs outside, three pieces inside AWS. Messages flow in by email or a web widget. Detect reads the language, Translate-in turns it into your team’s language, and Translate-back carries the human-written reply out in the customer’s language.

What you set up once (the outside)

  • Customer messages. Two ways in. The first is email — you point your support address (or a copy of it) at the relay, and any message a customer sends lands in the system. The second is a small chat widget you drop on your website with one line of code; a visitor types in their own language and it goes straight to the relay. Either way, the customer writes in whatever language they want and never has to think about translation.
  • A glossary folder. Two short things in a Drive folder. The glossary is a Google Sheet, one row per term that must never be translated or changed: your brand name, your product names, account or order IDs, and any phrase that has to land word-for-word. The voice note holds your team’s working language (say, English) and a line or two on tone — warm and plain, or formal, or however your business sounds. Editing either one doesn’t need a deploy; a small sync job picks up the change within fifteen minutes.
  • Your team. The people who actually answer customers. They read every message in their own language with the original sitting right next to it, write the reply in their own language, and get a plain check of what the relay will send before they press send. They don’t need to speak the customer’s language — they just need to do their normal job.

What runs on every message (the inside)

  • Detect. When a message arrives, the relay first cleans it — strips the email signature, the quoted history, the “sent from my phone” footer — so it’s looking at the actual new text. Then it reads which language that text is in. Most messages are easy. Short ones (“ok thanks”), mixed-language ones, and ones full of product codes are harder, so the detect step has a cheap first pass and a careful fallback. Part 2 covers this in detail.
  • Translate-in. The relay translates the customer’s message into your team’s working language using Bedrock with Claude Haiku 4.5 — a small, fast, inexpensive model that handles almost everything. Before it translates, it locks every protected term from the glossary and every number and price behind a placeholder, so the model can’t touch them. The staff member sees the original and the translation side by side, with any passage the relay wasn’t sure about highlighted. If a passage is genuinely tricky — slang, sarcasm, a mixed-language sentence — it gets a second pass from the stronger Claude Sonnet 4.6 before a person sees it.
  • Translate-back. The staff member writes the reply in their own language. The relay translates it back into the customer’s language, again locking the protected terms and figures first. Then it does one more thing: it translates that outgoing message back into the staff language and shows it next to what they wrote, so they can confirm the meaning carried before anything goes out. Nothing sends until a person presses the button. Then the reply leaves by email or appears in the web widget, in the customer’s language, looking like it was written by a fluent speaker.

In plain words

A customer in São Paulo emails your support address in Portuguese: “Meu pedido #4471 chegou com a tampa quebrada. Posso trocar?” The relay cleans the message, reads that it’s Portuguese, locks the order number #4471 behind a placeholder, and translates the rest into English for your agent Sam: “My order #4471 arrived with the lid broken. Can I exchange it?” Sam doesn’t speak a word of Portuguese. He reads the English, checks the order, and writes back in English: “So sorry about that — yes, we’ll send a replacement for order #4471 today, no charge.” The relay translates that into Portuguese, keeps #4471 exactly as written, and shows Sam a plain English read-back of the Portuguese so he can confirm it says what he meant. He presses send. The customer gets a fluent Portuguese reply in the same few minutes any other ticket would take, and never knows a translation happened.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is the market you don’t serve because nobody on the team speaks the language — or the refund you gave on the wrong order because a free translate box swapped a digit and nobody caught it.

Design rules that shaped every decision

  • A person always writes the reply. The relay translates both ways but never sends a machine-written message to a customer.
  • Names, numbers, and prices are locked before translation and restored after. The machine can’t change a figure.
  • Every translation comes back with a confidence read. Low-confidence passages are shown to a human with the original.
  • The cheap model handles almost everything; the stronger model runs only on the genuinely tricky passages.
  • The glossary lives in Drive. Adding a protected term or changing tone doesn’t need a deploy.
  • Every turn keeps both the original and the translation. Audit a conversation later and you can read both sides.

Why this shape

Most small teams handle a foreign-language message in one of three ways: they paste it into a free translate box, they forward it to the one bilingual person on staff and wait, or they quietly ignore it. The translate box is fast but it leaks customer data into a third party, mangles the numbers that matter, and gives you a wooden reply that reads like a robot wrote it. The bilingual colleague is great until they’re on holiday, or they leave, or the message is in a language nobody on the team speaks. And ignoring it is a lost customer who tells their friends.

The setup above keeps the human exactly where they add value — understanding the customer’s problem and deciding what to do — and puts the machine exactly where it’s reliable: turning words from one language into another, under guardrails, with the risky bits flagged. The agent never has to trust a translation blindly, because the original is always right there and the figures are never touched. The customer gets served in their own language, fast, by a team that doesn’t speak it.

The next four posts walk through each piece in turn: how a message gets its language detected, how a message gets translated for staff, how a reply gets translated back, and how names and prices stay exact through both directions. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts