Shipeasy Translations treats translations like configuration. You discover keys from source, store them on the project, generate translations (manually or via AI), review, and publish. New copy goes live worldwide in seconds — no redeploy.

The 5-minute path

What Shipeasy Translations does

How copy gets to the user

Quick install

shipeasy login

shipeasy i18n install-loader --profile en  # injects the script tag
shipeasy i18n scan ./src --rewrite               # discovers & rewrites t("…") calls
shipeasy i18n push --profile en
shipeasy i18n profiles create --name fr --locale fr
# AI draft + review happen in the dashboard or via the i18n_translate_draft
# MCP tool — the CLI subcommand for this is on the roadmap.
shipeasy i18n publish --profile fr

Detailed walkthrough at Quickstart.

Configure

Translation settings live on the profile (one per locale, e.g. en:prod, fr:prod). Configure source language, targets, tone, glossary terms, and AI provider in the dashboard under Translations → Profiles → Settings. The same values can be edited via the Admin API.

A declarative shipeasy.config.ts is on the roadmap — until then, the profile is the authoritative configuration surface.

Settings reference

Use it in your app

Shipeasy Translations ships through the same client SDK as flags and experiments. Call i18n.t(key, fallback) anywhere — the active locale is picked from your loader script (or the cookie / URL param you configure), and translations come from the chunked bundle the loader fetches.

// app/(marketing)/page.tsx (Server Component or "use client" — both work)
import { i18n } from "@shipeasy/sdk/client";

export default function Page() {
  return (
    <section>
      <h1>{i18n.t("landing.hero.title", "Localize, as easy as asking Claude.")}</h1>
      <p>{i18n.t("landing.hero.sub", "Ship in 12 languages without ever leaving your editor.")}</p>
    </section>
  );
}

The English fallback string is the SOURCE OF TRUTH — shipeasy i18n scan picks it up and pushes it to the en profile, and the AI draft uses it as the prompt to translate from. The key (landing.hero.title) is what the runtime looks up in the published chunk. Pre-launch you can ship without ever opening the dashboard — fallbacks render until the chunk is up.

Why a separate product

You could store labels as a dynamic JSON config — and for tiny apps, you should. Shipeasy Translations exists because real-world i18n hits problems configs aren't built for:

• Volume: tens of thousands of keys. One JSON blob is unworkable.
• Workflow: translators are not engineers and shouldn't need access to flag tooling.
• Discovery: keys come and go with code; manual sync drifts immediately.
• Performance: chunking + lazy loading by route is critical at the upper end.
• Stats: you want to know which keys are unused, which translations are stale, which locales lag behind.

Shipeasy Translations handles all of that and exposes a dead-simple SDK for the runtime side.