Introducing Polyglot: CLI-first i18n for developers

We built Polyglot because internationalizing a web app shouldn't require a separate platform. Here's how four terminal commands cover the core of your localization workflow.

4 min read← All articles

Update (July 22, 2026): Polyglot now runs in CI too. The open Action flags new untranslated strings on every PR, and Polyglot Automation — early access for Team and Scale — opens a separate catalog-only PR after a human reviews the translations. Your team merges it.

Internationalizing a web application has always been one of those tasks that developers dread. Not because it's conceptually hard — wrapping strings in translation functions is straightforward enough — but because the tooling around it has historically been painful. You either end up with a bloated enterprise platform that requires a dedicated localization team, or you cobble together regex scripts that miss half your strings and flag the other half as false positives.

Today we're launching Polyglot, and it takes a fundamentally different approach. Polyglot is a CLI tool that lives in your terminal, understands your code at the AST level, translates with LLMs instead of lookup tables, and lets you preview everything locally before you ship.

The four-command workflow

Every Polyglot project follows the same workflow. You scan your codebase to detect untranslated strings, wrap them with translation functions, translate them into your target languages, and preview the result in your browser. Four commands, no context switching.

# Initialize a project (picks up your framework automatically)
polyglot init

# Find hardcoded UI strings (candidates for you to review)
polyglot scan

# Wrap detected strings with translation functions
polyglot wrap

# Translate into your target languages
polyglot translate

# Preview translations in your browser
polyglot preview

That's it. No browser tabs to manage, no spreadsheets to maintain, no copy-pasting between platforms. The CLI handles detection, wrapping, translation, and preview — all from the same terminal where you write your code. Generated translations wait for your review in the Polyglot dashboard before they count as approved.

Why CLI-first?

We built Polyglot as a CLI because i18n is fundamentally a developer workflow. It touches your source code, your build pipeline, and your deployment process. Forcing developers to switch to a web UI to manage translations creates friction at every step — you lose the ability to review changes in git, you can't run translations in CI, and you end up with a disconnect between your code and your translations.

With Polyglot, translations live in your repo as JSON files. They're version-controlled, reviewable in PRs, and deployable through your existing pipeline. The CLI integrates with GitHub Actions so you can run translation checks on every pull request, catch new untranslated strings before they merge, and track coverage over time.

Tree-sitter detection

Most i18n tools use regex to find translatable strings. This approach is fundamentally broken — regex can't distinguish between a user-facing label and an import path, a heading and a CSS class name, a button label and a configuration constant. Polyglot uses tree-sitter to parse your code into an abstract syntax tree, then walks that tree to find strings that are actually rendered to users.

This means Polyglot understands context. It knows that <h1>Welcome</h1> contains a translatable string, but import "./utils" does not. It detects strings in JSX text, attributes like placeholder and aria-label, template literals rendered in JSX, and framework-specific patterns like Astro templates and SvelteKit template blocks. What it reports are candidates for you to review, not a guarantee that every UI string was found.

LLM-powered translation

Traditional machine translation treats every string identically — a button label gets the same treatment as a marketing headline. Polyglot sends context alongside each string: where it lives in your code, any meaning notes you add, and the glossary terms your team has defined. The goal is translations that sound natural, respect your product terminology, and stay consistent across your app. You still review them before they ship.

Polyglot also maintains a translation memory that grows over time. When you translate a string that's similar to one you've translated before, the system reuses the existing translation — saving API calls and ensuring consistency. Combined with your glossary, this keeps your translations more consistent the more you use the tool.

What's next

Polyglot is available today. You can install it with a single command and start scanning your codebase right away. Detection covers Next.js, Astro, SvelteKit, React Native, Vue, Angular, and Flutter. Runtime support varies by setup, and Next.js App Router with next-intl is the best-tested path.

curl -fsSL https://getpolyglot.ai/install.sh | bash

We're also launching a generous free tier — 50 strings with no account (500 lifetime source strings once you sign up), no API key required, so you can try it without signing up. Scanning, wrapping, and preview run locally and don't need an account at all. For teams that need more volume — more strings, more languages, and more developer seats — paid tiers start at $49/month.

We'd love to hear what you think. Try it out, and let us know what frameworks and features you want to see next.

Start in your terminal

Stop hunting for untranslated strings.

Install the CLI, run a scan, and see exactly what you're missing. Free, no account required.

$curl -fsSL https://getpolyglot.ai/install.sh | bash
Introducing Polyglot: CLI-first i18n for developers - Polyglot Blog | Polyglot