Seth Keddy

Sep 09, 2025 • 4 min read

Taking Language All the Way Through Your App

The Origins of the Language Selector and my Implementation

Taking Language All the Way Through Your App

The humble language selector is one of those design patterns we all take for granted. Scroll to the footer of almost any global site and you’ll find a dropdown with flags or a list of languages. But somebody had to invent it.

The earliest versions appeared in the mid-1990s as the web started to go international. A few forward-thinking developers realized that defaulting to English limited adoption, so they added simple links: “English | Français | Español.” It wasn’t pretty, but it worked.

By the late 1990s, the W3C Internationalization (i18n) Working Group began formalizing standards. They didn’t just say “translate the text”—they created guidelines for encoding (UTF-8 replacing ASCII), locale handling, bidirectional text support (Arabic/Hebrew), and eventually best practices for language negotiation in HTTP headers. The point was clear: if the web was truly global, software had to respect users’ languages, not force them into one.

Fast forward to today: libraries like i18next, FormatJS, and frameworks like Next.js have native i18n support baked in. Language selectors are no longer afterthoughts—they’re essential to accessibility, compliance, and user trust.


My Experiment: From InventorsBook.ai to Paperbot.info

With that history in mind, I wanted to see how far a language selector could go when paired with AI-driven apps.

I started experimenting on InventorsBook.ai, where I prototyped a basic selector tied into i18n. It let users choose their preferred language, and the UI updated instantly. That was nice, but I wondered: What if the language preference didn’t just stop at the UI? What if it flowed into the AI context itself?

That led me to push the idea further in Paperbot.info. Paperbot is a small tool I built to generate “newspaper-style” outputs for marketers. On the surface, it’s a content tool. But under the hood, I designed it so that when a user picks a language, that choice doesn’t just update the visible interface—it gets carried all the way into the ChatGPT context.


How It Works: Carrying the Variable End-to-End

Here’s the simple but powerful logic:

  1. Language selection → A user chooses a language through the i18n-powered selector.

  2. Variable propagation → Instead of just updating UI text, I store that language choice as a context variable.

  3. Pipeline injection → When a user sends a request, the selected language variable is inserted into the ChatGPT context (chat.ts / openai.ts).

  4. AI response alignment → The model now receives not only the prompt but also the explicit instruction to respond in the selected language.

  5. Consistency across sessions → Because the variable is carried through the pipeline, the entire experience stays in the user’s chosen tongue—even when prompts are complex.

In practice, it looks like this in code:

// Example: injecting language into context
const userLanguage = getSelectedLanguage(); // from i18n
const messages = [
 { role: "system", content: `Respond in ${userLanguage}.` },
 { role: "user", content: userInput }
];

const response = await openai.chat.completions.create({
 model: "gpt-4",
 messages,
});

This ensures the AI “knows” the user’s language preference before it processes any content.


The Impact on Development

At first, I thought this was just a neat trick. But it turned out to reshape my development process:

  • Natural global reach: Instead of thinking “I’ll launch in English and add languages later,” I could think globally from day one.

  • User trust: When the AI reliably responds in the chosen language, users feel like the app was built for them, not translated for them.

  • Prompt design: Carrying the language variable into the system message forced me to think carefully about how prompts are structured. It made me realize that language isn’t just decoration—it’s context.

Of course, it’s not flawless. Sometimes the model drifts into English or misinterprets multilingual input. But the fix is straightforward: reinforce the system prompt or carry the variable deeper into the request pipeline.


Why This Matters

We’ve come full circle from those early “English | Français” links. The difference is that today, language selection doesn’t just mean swapping text—it can shape how AI systems respond and how users experience entire workflows.

For me, carrying a simple variable all the way through the stack was a small technical step, but it opened up a much bigger realization: the future of app design is about respecting context at every level—UI, pipeline, and AI.

If you’re building AI-powered products, I encourage you to try it. Add a language selector, propagate it through your stack, and see how it changes not only your app, but your thought process as a developer.

Join Seth on Peerlist!

Join amazing folks like Seth and thousands of other builders on Peerlist.

peerlist.io/

It’s available... this username is available! 😃

Claim your username before it's too late!

This username is already taken, you’re a little late.😐

0

5

0