Mission

Better Translate is intentionally focused, it starts where type-safe translations matter the most today:

• TypeScript
• Node.js and Bun
• React and the modern React ecosystem

That includes frameworks like:

• Next.js (App Router)
• TanStack Start
• React Router
• React Native

This is not accidental, it’s about building one solid system that works across the stack most teams are already using.

Where we are today

Better Translate is designed to feel native inside a modern TypeScript stack.

One core.
One translation model.
Everywhere.

Whether you're building:

• a backend with Node.js or Bun
• a web app with React
• a mobile app with React Native
• or a fullstack app with Next.js or TanStack Start

The experience should feel the same, no different tools per framework, no different patterns to learn. The focus right now is simple, make this experience solid, predictable, and fast to use.

The end goal

Translation today still depends heavily on key-based systems, that creates problems at scale. Imagine an app with thousands of messages:

• thousands of keys to maintain
• thousands of mappings to keep in sync
• thousands of translations to generate and review

Even with modern tooling, this becomes expensive in time, effort, and cost. And even when automated, translations don’t always capture intent. Tone shifts, meaning drifts, and the result is not always right.

Better Translate aims to move away from that model, reducing reliance on predefined translation files and rigid key systems, and moving toward a more direct, runtime-driven approach.

A system where:

• translations stay closer to the source of truth
• intent is preserved, not just converted
• and the developer experience stays simple and predictable

This should work across every layer, client, server and APIs

Where we’re going

The scope will grow, but carefully. More frameworks will be supported over time, especially within the React ecosystem and beyond.

Expansion is not the goal, consistency is. Better Translate should scale across:

• more frameworks
• more runtimes
• eventually, more languages beyond TypeScript
• and without relying on large, ever-growing key files

Without breaking the core idea: one system, everywhere

Why this matters

Translations are not isolated, they live across your entire product: frontend, backend, mobile, and everything in between. The tooling should reflect that.

The mission is to start with a strong foundation in TypeScript-first apps, then evolve without losing what makes it valuable:

• type safety by default
• consistency across the stack
• no reliance on rigid key-mapping systems
• and a system you don’t have to relearn every time