The Translation Was Still There. That Was the Bug.

Shanthosh — Sun, 27 Sep 2026 16:22:29 +0000

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.

That changed what I wanted Translatron to solve

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.

And yes, the name has a Transformers connection

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.

💊 The Dashboard Simulation is Lying to You: Why I Built Redpillx

Shanthosh — Sun, 08 Mar 2026 15:02:39 +0000

You take the Blue Pill, the story ends. You go back to writing
400‑line if/else blocks to handle every single JSON schema from
Stripe, Shopify, and GitHub. You keep paying OpenAI $0.50 every
time a user wants to see a bar chart of their own data. You stay in
the "Context Window" prison.

You take the Red Pill, you stay in Wonderland, and I show you how
Deep the data profiling goes.

The Problem: The "Generic Function" Trap

Every service---Stripe, GitHub, Jira, or your own internal
database---exposes data differently. As a developer, you usually face
two painful choices:

Choice A: Write a custom parser for every single API provider. (Goodbye, weekend.)
Choice B: Dump a 5MB JSON payload into an LLM and watch your API bill explode while the model hallucinates math that doesn't exist.

What I wanted was Choice C:

A plug‑and‑play SDK where the LLM acts as the Architect, but a
high‑performance engine (like Polars) acts as the Contractor.

The Redpill Philosophy: Profile, Don't Dump

Most AI tools fail because they try to be too smart. They scan
everything, which is slow and expensive.

Redpillx takes a different approach.

A local Data Profiler inspects a small sample (default: 100
rows) of your data first.

Benefits

Context Window Freedom
We only send the shape (schema) of your data to the LLM.
Whether you have 10 rows or 1 million rows, the token cost stays
the same.
Deterministic Math
The LLM generates a ChartSpec (the instructions).
The actual calculation happens locally using Polars (Python)
or our optimized JavaScript execution engine.

🛠️ Tutorial: Building Your First Dynamic Chart

Let's see how easy it is to exit the simulation.

1. Installation

# For the JS/TS fans
npm install redpillx

# For the Python / Data Science crew
pip install redpillx

2. The "Bring Your Own LLM" Setup

Redpillx doesn't lock you into any specific provider.

You bring the brain (LLM).
Redpillx provides the muscle (execution engine).


import { Redpill } from "redpillx";
import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const rp = new Redpill()
  .setLlm(async (messages) => {
    const res = await openai.chat.completions.create({
      model: "gpt-4o-mini",
      messages,
    });

    return {
      content: res.choices[0].message.content
    };
  })
  .build();

3. Generate & Execute

Point Redpillx at any JSON data and ask a question in plain
English.

const myData = {
  tickets: [
    { status: "open", priority: "high" },
    // ...
  ]
};

// 1. The Architect creates the plan (Chart Spec)
const { spec } = await rp.generateSpec(
  myData,
  "Show me ticket count by status"
);

// 2. The Executor performs the calculation locally
const result = rp.execute(spec, myData);

console.log(result.data);

/*
Output:
[
  { x: "open", y: 42, labelX: "Status", labelY: "Count" }
]
*/

🧬 Why This Works

Because the Spec is separate from the Data, it becomes reusable.

If your data updates every minute, you don't need to call the LLM
again.

Just run:

rp.execute(spec, newData)

And you're done.

⚡ Sub‑millisecond execution
🧠 LLM used only once
💰 Zero extra tokens

🤝 Credits & Inspiration

This project stands on the shoulders of giants:

PyGWalker
A massive inspiration for how interactive data exploration should be
feel.
OpenCode
For supporting the spirit of open‑source collaboration.
OpenRouter
For making it easy to test the SDK against dozens of models (Llama,
Claude (GPT) with a single API.

📦 Get Started

The project is fully open‑source and ready for contributions.

JavaScript SDK
GitHub -- red-pill-js | NPM
Python SDK
GitHub -- red-pill-py | PyPI

Final Question

Which pill will you take?

Let me know in the comments how you're dealing with the " Dashboard
Tax" in your apps 👇

DEV Community: Shanthosh