16 posts tagged with "Keyless i18n"

Backend localization is the i18n problem people forget about. Your frontend speaks five languages, and then your transactional emails go out in English regardless of user locale. Or your push notifications. Or your error messages from the API.

This guide shows how to localize a Node.js backend (Express, Fastify, Hono, or plain Node) with i18n-keyless-node — for emails, push notifications, API responses, scheduled jobs, and anywhere else strings flow from server to user.

React Native i18n traditionally means react-i18next with react-native-localize for locale detection. It works, but it's a lot of moving parts: a localization library, a key naming convention, JSON locale files bundled at build time, and a separate package for native locale detection.

This guide shows the keyless alternative for both Expo and bare React Native projects. You'll go from zero to multilingual in 5–10 minutes, with native locale detection and offline caching via MMKV or AsyncStorage.

Internationalizing a Next.js app in 2026 has more options than it used to. The official Next.js i18n routing was deprecated in favor of "build it yourself" patterns. next-intl is the most popular library purpose-built for the App Router. react-i18next works but adds friction.

This guide shows the keyless alternative — i18n-keyless-node for server components and i18n-keyless-react for client components, with a working setup for both App Router and Pages Router.

If you searched for "how to add i18n to a React app", most results will walk you through react-i18next — install, configure, set up a key naming convention, write locale JSON files, wire up a language switcher, and you're translated. Two days of work for an MVP-stage app.

This guide shows the modern alternative: i18n-keyless. You'll go from zero to multilingual in 5 minutes. We'll cover the setup, the core API, language switching, edge cases, and how to handle interpolation.

If you've ever shipped a multilingual app, you know the pattern: a t("homepage.hero.title") call in your JSX, a JSON file with that key mapped to "Welcome to Acme", a translator who needs to fill in the same key for each locale, and a code review where someone asks "what does homepage.hero.title actually say?".

Keyless i18n flips this. You write the source string directly in your code — <I18nKeyless>Welcome to Acme</I18nKeyless> — and the library handles translation, caching, and locale switching for you. No keys. No JSON files to sync. No translator filling in spreadsheets.

This guide walks through what keyless i18n is, when it makes sense, when it doesn't, and how it compares to traditional key-based libraries.

If you ask why a team migrated away from i18next or react-intl, you'll hear specific stories — not abstract critiques. "We shipped a missing-key bug to French users for three weeks." "Our PM keeps asking what homepage.cta.v2.final actually says." "We tried to add Spanish and it became a six-week project."

This article documents the real friction points, drawn from actual migration conversations. If any of these feel familiar, you're not imagining it — they're systemic costs of the key-based workflow.

Every i18n library you've used — i18next, react-intl, Lingui, FormatJS — is built around the same primitive: the translation key. You name a string, you reference it from code, you map it to translations in JSON files. This pattern has dominated for over a decade.

It made sense at the time. It doesn't anymore.

This is an opinion piece about why the assumption that you need keys is outdated, and why keyless i18n is the natural shape for modern engineering teams.

If you're on Lokalise but you've realized you're not actually using TMS features — no translators, no glossaries, no in-context review — and Lokalise has just become an expensive JSON-file storage with AI auto-translate enabled, this guide walks through migrating to i18n-keyless.

If you do use Lokalise's TMS features (translator team, glossaries, branding workflows), don't migrate. Read the comparison — Lokalise is the right tool for that workflow.

If your app is on react-intl (FormatJS) and you've decided to switch to i18n-keyless, this guide walks through the migration end-to-end: dual-run strategy, message-by-message replacement, handling ICU MessageFormat, and finally removing react-intl.

If you haven't decided yet, read the comparison first — react-intl genuinely wins for ICU-heavy use cases.

If you've decided to move from i18next to i18n-keyless, this is the practical guide. We'll cover the dual-run strategy (so you can ship the migration incrementally), code transformations, gotchas around namespaces / interpolation / pluralization, and how to handle existing translation files.

Read the comparison article first if you haven't decided yet.