# The Translation Was Still There. That Was the Bug. > Source: > Published: 2026-09-27 16:22:29+00:00 I changed a checkout button from **`Pay now`** to **` Continue to payment`**. Nothing failed. The app built normally, the translation keys were still present, and every locale file was perfectly valid. But the French and German strings were now translations of something the product no longer said. That is a strange kind of bug because, from the application's point of view, there is no bug at all. When I originally built Translatron, translation itself was the focus. Give an LLM some source strings, generate the target languages, save the JSON. The more I worked with it, the less interesting that part became. Modern models can translate text well. The real engineering problem starts once the translated text has to survive inside a product that keeps changing. A string like **`Continue`** is a simple example. It might mean continue checkout, continue onboarding or continue reading. The source string alone isn't enough to understand it. The same applies to product rules. Perhaps `Workspace` should never be translated. Maybe checkout buttons must stay short. Maybe somebody on the team manually corrected the French version because the generated sentence sounded unnatural. Those aren't edge cases. They're part of the history of the translation. **A translation is not just output. It's output produced under a particular set of assumptions.** If those assumptions change, the translation may need attention. If they don't, regenerating it is unnecessary — and can sometimes make things worse. That's the direction Translatron has been moving toward: identify what was affected, update those translations, and leave unrelated or intentionally human-edited work alone. When I came up with **Translatron**, *Transformers* was part of the inspiration. Originally the joke was obvious: one language transforms into another. After building the project further, I think the reference works better in another way. The goal isn't to transform everything whenever the tool runs. It's to figure out what actually needs to change. That has become the principle I like most: **Transform what needs transforming. Preserve what doesn't.** Somewhere along the way, that also made Translatron feel less like an AI translator and more like a localization compiler. Something changes. The affected output is identified. The necessary pieces are regenerated and validated. Everything else stays where it is. And your application still receives ordinary JSON at the end. That's the kind of AI tooling I want to build: useful where uncertainty exists, predictable everywhere else. Translatron is open source at `[github.com/Msalways/Translatron](https://github.com/Msalways/Translatron)`. If you've dealt with localization in production, I'm curious how your team knows when an existing translation needs another review.