DEV Community: Ash

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?