DEV Community: Ash

Adding a translation MCP server to my i18n workflow: setup, real responses, and gotchas

Ash — Mon, 07 Sep 2026 21:19:42 +0000

TL;DR: two tools (smart_translate, list_languages), a remote MCP server at https://www.machinetranslation.com/mcp, no API key, about a minute to connect. Every response below is real output from my own runs.

Last sprint I shipped a settings page into eight locales. The strings lived in en.json. The workflow was: open a translation tab, paste a value, copy the result, paste it into de.json, repeat about forty times, then sit there wondering whether the German I just pasted said "Discard" or "Throw away."

The tab switching was not the problem. The problem was that every string went through one model, and I had no idea when that model was guessing. Short UI strings are where machine translation is weakest. "Save" with no context can come back as the verb for saving a file, saving money, or rescuing someone, and nothing in the output tells you which one you got.

So I moved translation into the assistant I already have open, using an MCP server.

Disclosure: I work on MachineTranslation.com, which builds the server below.

What the server does

MCP is the open standard that lets an assistant call external tools inside a conversation. This server exposes two:

smart_translate(text, source_language_code, target_language_code)
list_languages()

smart_translate is the interesting one. Instead of routing your text to a single model, it runs it through 22 AI models in parallel and returns the translation they converge on. MachineTranslation.com calls this SMART consensus and puts the error reduction at roughly 90% against single-model output. Take the number as the vendor's, which it is.

The mechanism is the part I care about. On a short, context-free string, disagreement between models is the signal that the string is risky. Consensus acts on that signal without me prompting three assistants and eyeballing the difference myself.

Setup

No config file to hand-edit, no API key to paste. It is a remote server behind a login.

Open your assistant's connector, integration, or MCP settings.
Choose the custom or "add by URL" option.
Paste https://www.machinetranslation.com/mcp.
Log in with your MachineTranslation.com account when the OAuth prompt appears.

Authorization sticks across sessions, so this is a one-time thing. It works in Claude, ChatGPT, Cursor, and anything else that supports custom MCP connectors.

One caveat before you spend time on it: the MCP server is on paid plans only, including the 24-hour pass. If you want it for a single afternoon of locale work, the day pass covers it.

First call: the language list

I ran list_languages() first, because the codes decide whether this fits an existing locale structure or fights it.

{
  "languages": [
    { "code": "af", "name": "Afrikaans" },
    { "code": "es-419", "name": "Spanish (Latin America)" },
    { "code": "es-MX", "name": "Spanish (Mexico)" },
    { "code": "pt", "name": "Portuguese (Brazil)" },
    { "code": "pt-PT", "name": "Portuguese (Portugal)" },
    { "code": "sr-Latn", "name": "Serbian (Latin)" },
    { "code": "sr-Cyrl", "name": "Serbian (Cyrillic)" },
    { "code": "zh-TW", "name": "Chinese (Traditional)" }
  ],
  "count": 333
}

333 codes, and the regional splits are the reason to read the list rather than assume.

pt and pt-PT are separate targets. So are es-419, es-MX, es-AR, es-CO, and es-ES. Serbian ships in both scripts, Somali in Latin and Arabic, Uzbek in Latin.

If your locale directories are already named pt-BR and pt-PT, you can map them one to one instead of translating once into "Portuguese" and hoping nobody in Lisbon files a bug.

The test that decided it

Machine translation eats interpolation placeholders. That is the most common way a translated string breaks a build or renders {count} as literal text to a user. So this was the first real string I sent:

smart_translate(
  text: "Delete {count} items from your workspace?",
  source_language_code: "en",
  target_language_code: "de"
)

Response:

{
  "translation": "{count} Elemente aus Ihrem Arbeitsbereich löschen?",
  "source_language_code": "en",
  "target_language_code": "de",
  "word_count": { "source": 6, "target": 6 },
  "credits_used": 30,
  "request_id": "b0cea79d-fa11-4d21-be6a-9f2b0ef79b3c"
}

The placeholder survived, and it moved to the front, which is where German syntax wants it. That reordering is what a naive find-and-replace pipeline gets wrong.

Second test, a longer engineering sentence into Japanese:

{
  "translation": "デプロイメントが失敗しました。キャッシュが冷えていたためです。以前のビルドにロールバックしてください。",
  "source_language_code": "en",
  "target_language_code": "ja",
  "word_count": { "source": 15, "target": 51 },
  "credits_used": 30,
  "request_id": "3b577571-1ead-4e7a-950e-aae1e69eb3b6"
}

It split one English sentence into three Japanese ones, which reads better than a single clause would have.

Read the response fields

Three of them do real work once you are doing this at any volume.

request_id is a traceable ID per translation. I paste it into the PR next to any string I did not review by hand, so there is a record of which lines came from a machine.

credits_used came back as 30 on both calls, one for a six-word string and one for a fifteen-word string. Budget per call, not per word, until you have measured your own mix.

word_count is counted the way the target language works. English to German came back 6 and 6. English to Japanese came back 15 and 51, because Japanese has no spaces and the count is character-based. If you log these for cost or capacity, source and target are not comparable across scripts.

How it fits the day

I paste a block of English strings into the assistant, name the locales I need, and it calls the tool once per string and hands back JSON shaped the way my locale file already is. I read the output, fix the two or three strings I disagree with, and commit. No tab, no clipboard, no losing my place in the file.

It works in the other direction too. When a translation arrives from somewhere else and I cannot read it, running the same string through consensus tells me fast whether it is in the neighborhood of correct.

What it does not do

It is not a TMS. Two tools, text in and text out. No translation memory, no glossary enforcement, no term base. If you need "Workspace" to render identically across 400 strings, you still enforce that yourself.

There is no batch or file tool in the MCP surface. You loop over strings in the conversation. Fine for a feature's worth of copy, wrong for a 4,000-key migration. For build-time or CI work, use the API instead.

Consensus is not review. It lowers the odds of a bad string, it does not certify one. Legal copy, medical text, and anything on a pricing page still gets a human.

Paid only. No free tier for the MCP server.

Try it

Server URL for your connector settings:

https://www.machinetranslation.com/mcp

Docs and tool reference: developer.machinetranslation.com/mcp
The platform, if you want to see consensus output in a browser first: machinetranslation.com
How far apart single models land on the same text: Claude vs. ChatGPT for translation

If you connect it, run list_languages() before you translate anything and check your locale codes against the list. The regional variants are the difference between a string that ships and a string that gets reported.

What locale codes does your project actually use, and has anyone here found a reliable placeholder-safety check.

Have You Heard About MachineTranslation.com? It Compares Multiple AI Translators Instead of One

Ash — Mon, 22 Jun 2026 11:58:40 +0000

Most AI translation tools give you a single answer and expect you to trust it.

But recently, I came across MachineTranslation.com, and one thing stood out to me: instead of relying on one model, it compares outputs from multiple AI translators and uses consensus technology to help determine the strongest translation.

That got me thinking.

Why Do We Trust Just One AI?

If you've ever used AI for translation, you've probably noticed that different models often produce different results.

Sometimes one sounds more natural.

Another preserves technical accuracy better.

And another might capture the tone you're aiming for.

So why should we assume that one AI model always knows best?

The Consensus Approach

MachineTranslation.com takes a different route.

Rather than providing a single translation, it analyzes outputs from multiple AI translation engines and identifies areas where those models agree.

In other words, it tries to answer a different question:

What happens when multiple AI systems collaborate instead of competing?

The concept reminds me of ensemble methods in machine learning, where combining several models often produces better and more reliable results than relying on a single one.

Why This Matters

Translation isn't just about converting words.

Context, tone, terminology, and intent all matter.

And AI models don't always agree on those things.

That's actually useful.

When several models independently arrive at similar wording, confidence in the translation increases. When they disagree, it highlights sections that might deserve a closer look.

That seems especially valuable for:

Technical documentation
Localization projects
Marketing content
Product descriptions
Multilingual SEO
User manuals

Instead of hiding the differences between models, MachineTranslation.com turns those differences into information.

Transparency Over Blind Trust

I think one of the more interesting aspects of this approach is transparency.

Many AI tools aim to hide complexity and provide a single "best" answer.

MachineTranslation.com exposes alternatives and lets users compare them.

In a way, it's less about asking:

Which AI model is the smartest?

And more about asking:

What can we learn when several AI models agree—or disagree?

As AI continues to evolve, I wonder whether consensus-based systems will become more common across other domains, not just translation.

I'm curious what other developers think.

If you had to choose between:

One AI model giving you a single answer, or
Multiple AI models whose outputs are compared through a consensus system,

which approach would you trust more?

Your app doesn’t break in translation… it mutates

Ash — Mon, 08 Jun 2026 05:49:55 +0000

I used to think localization was simple.

You take your English UI → translate it → ship → done.

Then I saw a Spanish version of a feature I built and realized something uncomfortable:

The app still worked…
but it didn’t feel like my app anymore.

Same screens. Same flow.
Different personality.

That’s when it clicked: translation doesn’t just convert text, it changes behavior.

The bug no one logs

In code, we track:

crashes
latency
UI breaks

But there’s a silent failure that never shows up in logs:

The product’s intent changes across languages.

A button that feels “friendly” in English might feel “commanding” in another language.
A “quick tip” might sound like a warning.
A “simple onboarding step” might suddenly feel like bureaucracy.

Nothing is technically wrong…
but user trust quietly drops.

I tried stress-testing translations differently

Instead of asking “Is this correct?”, I started asking:

Does this still sound like us?
Would a user behave differently after reading this?
Does this feel consistent across 5 different language versions?

That’s how I ended up digging into MachineTranslation.com

What stood out wasn’t the translation itself, it was the variance.

Seeing multiple translation outputs side by side exposes something most devs never notice:

There is no single “correct” translation.

There are only tradeoffs:

tone vs precision
literal vs contextual
safe vs expressive

And each choice slightly reshapes the product.

*The part most dev teams miss
*
We obsess over:

UI polish
performance
onboarding funnels

But ignore the fact that:

Language is part of the interface.

And unlike design systems, translation systems drift unless you actively control them.

A weird realization

If you localize early enough, you’re not translating an app.

You’re designing multiple versions of the same product personality, one per language.

And they will not naturally stay aligned.

Not without intention.

Curious how others handle this

For devs building multilingual products:

Have you ever noticed your product “feels different” in another language?
Do you review translations as a team, or trust tools and move on?
Would you rather optimize for consistency or speed of shipping?

I’m genuinely curious where people draw the line between:

“localized product” vs “same product in different languages”

Because that line seems a lot blurrier in practice than in docs.

I thought translation was “solved”… until I shipped an app to users who didn’t speak my language

Ash — Mon, 08 Jun 2026 05:36:47 +0000

Most developers don’t think about translation until it hurts.

It usually starts like this:

You launch your app in English → you get traction → then suddenly users from Brazil, Japan, or Germany start showing up.

And that’s when reality hits:

Your UI breaks in other languages
Auto-translation changes meaning in weird ways
Your “simple” onboarding flow suddenly feels confusing
You realize localization is not just “text replacement”

I went down that rabbit hole recently while experimenting with multilingual product flows, and I ended up revisiting a category I used to ignore: professional translation services like Tomedes.

Their approach is interesting because it’s not just “translate this text,” but more like:

“Here’s the context of your product, now preserve meaning across languages.”

That distinction matters more than most devs expect.

Because in real apps, you’re not translating words.

You’re translating:

intent
UX flow
tone
edge cases users complain about in feedback forms

Where devs usually underestimate localization

A few things I’ve personally seen break:

Product UI strings
“Cancel” vs “Stop” vs “Dismiss”, some languages don’t treat these as interchangeable.
Error messages
A “soft error” in English can sound like a critical failure in another language.
Onboarding flows
Step-by-step instructions can become culturally awkward or too literal.
Marketing copy inside the product
This is where most “machine-only translation” approaches fall apart.

The uncomfortable truth

If you’re building indie SaaS or side projects:

You can’t always brute-force your way with automated translation and hope UX stays intact.

At some point, you either:

localize properly
or accept that non-English users are getting a degraded experience

Curious how others handle this

For devs here who’ve shipped multilingual products:

Do you rely purely on AI translation?
Do you mix human + AI workflows?
Or do you just stay English-first until it hurts too much?

I’m especially curious how you handle:

maintaining tone consistency across languages without slowing down shipping velocity

Drop your setup or workflow, I’m trying to compare approaches.

I built/played with two language tools and it changed how I think about “learning vs translating”

Ash — Thu, 04 Jun 2026 03:31:23 +0000

I didn’t expect to care this much about language tools.

I started messing around with two different projects, Linguaboard and Parley, mostly out of curiosity. What I got was a surprisingly clear look at two very different ways we interact with language as developers and builders.

Linguaboard: translation as exploration, not just output

Linguaboard isn’t trying to give you the translation.

Instead, it feels more like it’s saying: “Here are several valid ways this could be expressed, pick what fits your intent.”

That shift is subtle but important.

Most translation tools optimize for a single “correct” answer. Linguaboard leans into ambiguity in a way that actually helps you understand nuance instead of hiding it.

I found myself thinking less like:

“What does this mean?”

and more like:

“How should this sound in context?”

Parley: learning through interaction, not memorization

Parley takes a completely different angle.

Instead of treating language as something to decode, it treats it as something to use. You’re not just passively consuming translations, you’re engaging with patterns, context, and recall in a more active loop.

What stood out to me is how quickly it shifts you out of “study mode” and into “usage mode.”

It feels closer to building intuition than studying rules.

The interesting contrast

What I didn’t expect is how well these two complement each other:

Linguaboard → helps you understand nuance and meaning
Parley → helps you internalize and use language

One is about interpretation, the other about retention through interaction.

Put together, they highlight something a lot of dev tools miss:

Language work isn’t one problem. It’s at least two: understanding, and using.

Why this matters (especially for devs)

If you’re building anything with multilingual UX, AI translation, or global audiences, you’ve probably hit this wall:

Translation APIs give you “correct” text
But correctness ≠ clarity, tone, or intent

These tools made that gap feel very obvious to me.

And once you see it, you can’t unsee it.

I Thought Translation Was a Solved Problem. Then I Tried Shipping a Multilingual Product.

Ash — Wed, 03 Jun 2026 02:52:10 +0000

Like many developers, I assumed translation was basically a solved problem.

Need another language? Send the text to an AI model, get the output, ship it.

Simple.

Then I started working on a project with users from different countries, and I quickly discovered that "technically translated" and "actually understandable" are two very different things.

One model would translate a phrase perfectly.

Another would miss the context entirely.

A third would sound fluent but subtly change the meaning.

The frustrating part wasn't that AI made mistakes. It was that different AI models made different mistakes.

So I started comparing outputs instead of trusting a single model.

What surprised me was how often the best translation wasn't from the model I expected. Sometimes the strongest result was the one that multiple models independently agreed on.

That got me thinking about a broader pattern in software development.

We rarely trust a single source of truth.

We use multiple tests.

Multiple monitoring signals.

Multiple reviewers.

Redundancy is everywhere.

But with AI, many of us still send a request to one model and assume the answer is correct.

Now whenever I'm working with multilingual content, I compare outputs from several models before making decisions. I eventually landed on MachineTranslation.com because it let me compare outputs from multiple AI models at once rather than trusting a single translation.

The bigger lesson wasn't about translation.

It was about AI in general.

The most useful AI workflow I've found isn't asking, "Which model is best?"

It's asking:

"What happens when several models disagree?"

That's usually where the interesting insights start.

Have you run into situations where multiple AI models gave completely different answers to the same prompt? I'd love to hear the weirdest example you've seen.

I Let AI Teach Me a Language. It Failed in a Way I Didn't Expect.

Ash — Wed, 03 Jun 2026 02:45:01 +0000

Like a lot of developers, I got excited when AI tutors started appearing everywhere.

The promise sounded amazing:

Personalized lessons
Instant feedback
Infinite conversations
No expensive tutors

So I decided to build Parley, a language learning game that uses AI as the teacher.

What I expected was that the biggest challenge would be translation accuracy.

I was wrong.

The real problem was boredom.

Most AI language apps are technically impressive, but after a few days they start feeling like the same conversation repeated forever:

"How are you?"

"What is your favorite food?"

"Tell me about your hobbies."

The AI wasn't bad.

The experience was.

That realization completely changed how I approached building Parley.

Instead of treating AI as the product, I started treating it as a game engine.

Players aren't just chatting with a bot. They're completing missions, unlocking new scenarios, making choices, and using language to achieve goals.

Something interesting happened during testing.

People spent less time worrying about grammar mistakes and more time trying to complete the objective.

And that's exactly what happens in real life.

When you're ordering food in another country, you're not thinking about perfect grammar. You're trying to get the food.

The language becomes a tool instead of the goal.

Ironically, making learning feel less like learning made people practice more.

It reminded me of something many AI builders overlook:

Users don't care how intelligent the AI is.

They care whether the experience is engaging enough to come back tomorrow.

Sometimes the hardest problem isn't building better AI.

It's building something people actually want to use.

Building a Language Learning Game Taught Me Something Unexpected About AI

Ash — Tue, 02 Jun 2026 03:41:14 +0000

When we started experimenting with AI translations, we assumed the biggest challenge would be accuracy.

We were wrong.

The harder problem was preference.

Give two AI models the same sentence, and both translations can be technically correct. Yet people almost always have a favorite.

One sounds more natural.

One feels more human.

One is the version they'd actually use.

That observation eventually led us to build Parley, a simple game where players compare two translations and choose the better one.

What happened next surprised us.

People became highly engaged with a task that looked almost trivial. They started debating word choices, discussing tone, and noticing subtle differences between translations. Some users spent far longer interacting with translation examples than they ever would reading documentation or language-learning materials.

It highlighted something interesting about AI products: evaluation can be more engaging than generation.

Most AI interfaces focus on creating content. But humans are often much better at judging quality than producing it from scratch. Asking someone to choose between two outputs requires less effort while still training their intuition.

The experiment also changed how I think about language learning.

Traditional language apps often rely on memorization and repetition. But comparing alternatives forces you to think about meaning, context, and natural expression. You're not just learning vocabulary, you're developing taste.

And in a world where AI can generate endless content, taste might become one of the most valuable skills we can build.

Have you seen similar patterns in AI products where evaluation turns out to be more engaging than creation?