🌍 Localship

Translate your app with the AI you already use.

Free and open source · No account, no server · Any AI model · Every translation checked

Highlights · See it in action · How it works · What you can ask · Formats · Install · Questions · Roadmap · Reference

Ask your coding agent to translate your app. Localship gives it the context it needs, checks every translation before it's written, and remembers what's done, so updates only redo what changed. Think of it as a localization platform that runs inside your coding agent: no account, no server, no monthly bill.

✨ Highlights

• 🆓 Free and open source. MIT-licensed. You pay only for your own AI usage, or nothing with a local model.

• 🤖 Your AI, your model. Your coding agent's own model, or Claude, GPT, Gemini, OpenRouter or Ollama.

• 🛡️ Catches broken translations. Placeholders, plural forms, escaping and markup are checked in code before anything is written. Failures go back to the AI with the reason.

• 🧠 More context for the AI. Each string comes with the code that uses it, its comment, your glossary and voice notes, and earlier translations of the same text.

• 🔒 Your files, your workflow. No Localship server or account. Translation files stay in your repo, formatted the way your tools write them. You choose the AI that receives their content.

• 👀 Review in your browser. localship review opens a page on your computer with source and translation side by side, where you edit, approve or reject them, one at a time or all at once.

• ✅ Check before release. Require current, approved translations in CI with localship validate --require-approved. No model call or API key needed for the check.

• 💻 Runs anywhere. Claude Code, Cursor, VS Code, Codex, Gemini CLI, Claude Desktop or the terminal, on macOS, Linux and Windows.

🤔 Why use Localship?

Related MCP server: i1n

🎬 See it in action

You:    Translate this app into Hindi and Arabic.
Agent:  Translating 18 strings into Hindi and Arabic…
        36 translations written as drafts, 0 errors. Arabic has all six plural forms.
        Hindi addresses the user as आप, and "Jotter Pro" is kept as written.

You:    Review the Arabic, then approve them.
Agent:  Two small fixes made. All approved.

You:    I'd like to check the Hindi myself.
Agent:  Review page is open in your browser: edit, approve or reject each string.

You:    I reworded two buttons. Update the translations.
Agent:  Updated the 2 changed strings. Your hand edit in Hindi was kept.

🔍 How it works

flowchart LR
    A[📁 Your repo] --> B[🔎 Find strings]
    B --> C[🧠 Batch + context<br/><sub>code usage · comments<br/>glossary · voice · memory</sub>]
    C --> D[🤖 AI translates<br/><sub>your agent or any model</sub>]
    D --> E{🛡️ Checks<br/><sub>placeholders · plurals<br/>escaping · markup</sub>}
    E -- fails --> D
    E -- passes --> F[📝 Drafts in your files]
    F --> G[👀 Review] --> H[✅ Approved]

Setup adds one folder to your repo. Commit it: the brief, glossary and voice notes are yours to edit, and the lockfile is how Localship knows what's new, what changed and what someone edited by hand.

.localship/
├── config.yaml     where your strings live, and which languages
├── brief.md        what the app is and who it's for
├── glossary.yaml   terms to keep as they are or translate one way
├── voice/          tone and formality per language
└── lock.json       what was translated from which text

💬 What you can ask

Wherever your app is today, one sentence gets it started.

🖥️ Review translations in your browser

• ✏️ Edit in place. Every save goes through the same checks as the agent's translations, so a broken placeholder is refused with the reason.

• ✅ Approve one, or all at once. Filter by language, state or text, then Approve all approves just what's shown.

• 🧭 Context on every string. The comment, glossary terms, placeholders to keep, and the code that uses it. Right-to-left languages show right-to-left, and plurals show every form with sample counts.

• 🔒 Stays on your computer. It runs on 127.0.0.1 with a private link, with no account and no upload.

localship review --locale ar     # opens in your browser; --no-open just prints the link

📦 Formats

Setup finds these on its own. To write the config by hand, a Flutter app and a web app look like this:

targets:
  - format: arb
    path: lib/l10n/app_{locale}.arb            # the source language's file is the template
  - format: json
    path: public/locales/{locale}/common.json  # i18next; add `placeholders: icu` for react-intl or next-intl

Android string arrays and plurals, String Catalog plural variations, gettext plural forms, ICU plurals in ARB and JSON, and i18next _one/_other keys are all supported.

Apple device/nested variations and substitutions, and Android strings in configuration-specific folders such as values-ar-night, are preserved but not translated or validated. Localship reports these coverage gaps; validate --strict and --require-approved fail rather than claim completeness. See platform verification for native build, language setup and device checks.

🚀 Install

Claude Code plugin

/plugin marketplace add jigarfumakiya/localship
/plugin install localship@localship

Claude Code, Codex, Gemini CLI and other CLIs: add the server, then the skills.

claude mcp add localship -- npx -y localship mcp   # Claude Code
codex mcp add localship -- npx -y localship mcp    # Codex
gemini mcp add localship npx -y localship mcp      # Gemini CLI
npx skills add jigarfumakiya/localship             # the skills, for any agent

Cursor and VS Code

Add the skills too: npx skills add jigarfumakiya/localship.

Now ask your agent: "Translate this app into Hindi and Arabic." Needs Node.js 22 or newer.

🔌 Other tools

Add this MCP server to your tool's config:

{ "mcpServers": { "localship": { "command": "npx", "args": ["-y", "localship", "mcp"] } } }

Your agent picks these itself; you just ask. 👀 marks tools that only read and never change a file.

🔒 Security and privacy

• Stays in your project. Localship reads and writes only your translation files and the .localship/ folder. Changes to your code are made by your agent, where you can see them.

• No Localship server. No account, no telemetry. Localship's model calls go to the provider you configure. When you use a cloud coding agent, that agent may send strings and context to its model provider. Validation runs locally without model calls; translation can also stay local when you use a locally hosted model.

• Nothing is final until you say so. Translations are written as drafts, and hand edits and approved translations are never replaced unless you ask.

⌨️ From the command line

No agent needed: run Localship straight from your terminal with any model.

npm install -g localship

localship plan hindi arabic                                 # what it takes, before changing anything
localship start hi,ar --model anthropic:claude-sonnet-5-5   # set up and translate in one go
localship status                                            # progress per language
localship validate                                          # exits 1 on errors
localship review --locale ar                                # review page in your browser
localship approve --locale hi                               # after review
localship validate --require-approved                       # release / CI check

Every command, option and config key is in the reference.

❓ Questions

• Node.js 22 or newer: run node --version.

• The first start takes a minute while it installs; try again after that.

• Reconnect the server: /mcp in Claude Code, or restart your editor.

• Open your app's folder in your tool, so Localship starts in the right project.

Yes. Two examples come with their translations:

• examples/android-notes: a small Android app in Hindi and Arabic.

• examples/flutter-app: a small Flutter app in Arabic, French, Hindi and Japanese, translated by a coding agent, with Flutter tests that check every language.

Open one with Localship installed and ask your agent to add another language.

No. Inside a coding agent, Localship uses the agent's own model. An API key is only needed to translate from the terminal or CI, and a local model through Ollama needs none at all.

Only to the AI you choose. There's no Localship server.

No. Hand edits and anything approved are never replaced unless you explicitly ask.

Yes. One config can list all of them, and they share the same brief, glossary and voice notes. When the same text appears in more than one app, the earlier translation is offered to the AI, so "Sign in" reads the same everywhere.

Yes. Flutter's .arb files and JSON files for i18next, react-intl, next-intl and similar libraries are supported. ICU plurals ({count, plural, one{…} other{…}}) and i18next plural keys (items_one, items_other) get every form each language needs, so Arabic gets six. Translators also see where each key is used, from AppLocalizations.of(context)!.save in Dart or t("nav.home") in JavaScript.

Any. Plural rules come from Unicode's CLDR data, so Arabic gets six plural forms, Russian three and Japanese one, automatically.

As good as the model and the context you give it. The brief, voice and glossary make the biggest difference. The checks catch mechanical errors, not wrong meaning, so review the drafts, ideally with a native speaker.

Not yet. Localship checks the translation files, not how your app draws them. Charts that don't mirror, signs on the wrong side of amounts, or text stored in a database won't show up in the files, so test right-to-left languages on a device before you ship. The agent skills list what to look for.

🛣️ Roadmap

Want something sooner? Open an issue or 👍 an existing one.

🤝 Contributing

Found a bug or have an idea? Open an issue.