Skip to main content

i18n-keyless vs Inlang (Paraglide): keyless SDK vs compiled i18n

· 9 min read
Arnaud Ambroselli
Founder of i18n-keyless

Inlang is a newer developer-centric i18n ecosystem built around one insight: translations should be compiled, not loaded at runtime. Its compiler, Paraglide, turns message files into tree-shakeable JavaScript functions with full TypeScript autocompletion. No runtime lookup, no unused translations in the bundle, no typo'd key strings.

i18n-keyless takes a different bet: what if you had no keys, no message files, and no compilation step at all? Write the string in your code, the AI translates it, you override the ones that matter. The source string is the key.

Both are modern reactions to the i18next-era status quo. They agree on the problem (key management is overhead) but disagree on the fix.

TL;DR​

i18n-keylessInlang / Paraglide
Product typeDeveloper SDK with AI translationCompiler + editor ecosystem
Source of truthSource string in your codeMessage files (.inlang/)
Translation keysNone — source string is the keyCompiled to typed functions (m.confirm_payment())
Tree-shakingN/A (translations fetched on demand)Yes — only used messages in the bundle
Type safetyNone on keys (no keys to type)Full — autocompletion on every message function
AI translationBuilt inNot included — bring your own
Build stepNoneRequired — Paraglide compiler
Best forMVPs, indie SaaS, engineer-driven teamsType-safety-focused teams, static sites, bundle-conscious apps

Pick i18n-keyless if you want multilingual without managing keys, files, or a build step. Pick Paraglide if you want compile-time type safety, tree-shaking, and you're okay managing message files.

The fundamental difference: no keys vs typed keys​

Paraglide doesn't eliminate keys — it upgrades them. You still write message files:

// messages/en.json
{ "confirm_payment": "Confirm payment" }

// messages/fr.json
{ "confirm_payment": "Confirmer le paiement" }

Paraglide compiles them into typed functions:

import * as m from "./paraglide/messages";
<button>{m.confirm_payment()}</button>

Type-safe, tree-shakeable, autocompletable. A typo in m.confrim_payment() is a build error, not a missing string at runtime. This is genuinely great DX for teams who value static analysis.

i18n-keyless removes the step before that:

import { I18nKeylessText } from "i18n-keyless-react";
<button><I18nKeylessText>Confirm payment</I18nKeylessText></button>

No message files to write. No compiler to run. No functions to import. The source string is the identity, and AI translation is the default.

Where Inlang / Paraglide genuinely wins​

Tree-shaking​

Paraglide's compiled output means only the messages your page actually imports end up in the bundle. For a large app with 2,000 strings where any given page uses 50, that's a significant difference — especially on mobile or in static-site contexts where bundle size matters.

i18n-keyless fetches translations at runtime from a backend cache. The bundle contains the SDK (~8KB gzip) but no translation data. The tradeoff: a network request on first load vs a larger initial bundle.

Full type safety​

Every message is a function with typed parameters:

m.greeting({ name: "Alice" })  // TS error if `name` is missing or misspelled

i18n-keyless uses string-based replace maps — { "{name}": user.name }. The keys are strings, not types. You won't get a build error for a missing placeholder; you'll see {name} rendered in production. For teams that lean heavily on the type system to catch bugs, Paraglide is safer.

VS Code integration (Sherlock)​

Inlang's Sherlock extension shows translation previews inline in your editor — hover over a message function to see every language. It also highlights missing translations and links to the message file. Tight editor integration is an underrated productivity boost.

i18n-keyless has no editor extension. You see the source string in the code and check translations in the dashboard.

No runtime dependency​

Paraglide's output is plain JavaScript functions. No SDK, no backend, no network call. The translations are in the bundle — your app works offline, in a test runner, in a Storybook, without any service running. For static sites or Electron apps, this is a real advantage.

i18n-keyless requires its backend to be reachable (at least for the first load; then local cache takes over).

Framework-agnostic compiler output​

Paraglide's compiled functions are plain JavaScript. They work in React, Svelte, Vue, Astro, SolidJS — anywhere you can call a function. No framework-specific SDK to install.

i18n-keyless has dedicated SDKs for React, Vue, Angular, Node, Laravel, Rails, Flutter, Python, Go, Swift, and Kotlin. Broader runtime coverage, but each is a distinct package.

Where i18n-keyless wins​

No keys to manage​

Paraglide made keys better. i18n-keyless made keys unnecessary. You still write confirm_payment in a message file, still keep en.json and fr.json in sync, still decide on a naming convention. The compiler catches typos, but the management overhead is still there.

With i18n-keyless, new engineers read the source string in the JSX. No naming convention to learn, no message file to find, no "which namespace is this in?" questions.

No message files​

Paraglide needs .inlang/ with message files per language. You write the source messages, then either translate them yourself or use a separate tool. Adding a new language means creating a new message file and filling it in.

i18n-keyless has no files. Adding Italian is one config line — every existing string auto-translates in the background.

No compilation step​

Paraglide requires a build step that compiles messages into functions. Your dev server needs the compiler plugin. Your CI needs it. Your test runner needs it. It's one more thing in the pipeline.

i18n-keyless is a runtime SDK. Install, init, use. No build plugin, no compiler configuration.

AI translation built in​

Paraglide has no translation service. You write the translations yourself, use an external tool, or integrate with a TMS. The compiler is agnostic about where translations come from — which is elegant, but it means you still need to solve "who translates?"

i18n-keyless answers that question: AI does, and you override. For a 500-string SaaS launching in 4 languages, that's the difference between "done in an afternoon" and "done in a week."

13 SDKs across platforms​

Paraglide is primarily a web compiler. i18n-keyless has SDKs for React, React Native, Vue, Angular, Node, Laravel, Rails, Flutter, Python, Go, Swift, Kotlin, and a plain browser SDK. One protocol, one dashboard, one API key across all of them.

A practical decision rubric​

  1. Is bundle size critical?

    • Yes (static site, mobile web, offline-first) → Paraglide.
    • No (SaaS, dashboard, app with a backend anyway) → either works.

  2. Do you want compile-time type safety on translation keys?

    • Yes → Paraglide.
    • No (you'd rather have no keys at all) → i18n-keyless.

  3. Who translates?

    • You or your team, manually → Paraglide (you control the files).
    • AI does, you override → i18n-keyless.

  4. Do you want a build step?

    • Fine with it → Paraglide.
    • Want to avoid it → i18n-keyless.

  5. What platforms do you target?

    • Web only → Paraglide works well.
    • Web + mobile + backend → i18n-keyless has SDKs for all of them.

FAQ​

What's the difference between Inlang and Paraglide?​

Inlang is the ecosystem — an open-source project that includes the Sherlock VS Code extension, the Fink translation editor, and a CLI. Paraglide is the compiler inside that ecosystem: it takes message files and compiles them into tree-shakeable JavaScript functions. When developers say "Inlang" they usually mean Paraglide.

Is Paraglide's tree-shaking worth it?​

For static sites, marketing pages, and mobile web where every KB matters — yes. For a SaaS dashboard or an admin panel where the user is already loading a React app, charting library, and an API client, the difference between 0KB (Paraglide, messages in bundle) and an 8KB SDK + one API call (i18n-keyless) is negligible.

Does i18n-keyless support type-safe keys?​

No, because there are no keys. The source string is the identity. You get no build-time check that a translation exists — but you also can't have a missing-key bug, because the source string renders as the fallback. The tradeoff is different: Paraglide catches typos at build time; i18n-keyless eliminates the class of bugs that typos belong to.

Which is better for a new project?​

If you're starting a SaaS or an app and want multilingual fast: i18n-keyless. Install, init, wrap strings, ship. If you're building a static site or a library where bundle size and type safety are priorities: Paraglide. Neither is universally better — the right choice depends on what you optimize for.

Next steps​