The Translation Was Still There. That Was the Bug.

A developer has built Translatron, an open-source localization tool that treats translations as outputs produced under specific assumptions, regenerating only the strings affected when source text or product rules change and preserving human-edited or unrelated translations. The project, inspired in part by Transformers, is positioned as a "localization compiler" that identifies affected output, regenerates and validates it, and leaves everything else untouched while still emitting ordinary JSON. The developer notes that a changed source string like "Pay now" to "Continue to payment" leaves valid but stale French and German translations, a class of bug invisible to the application itself.

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.