What happens to your translations if you stop using Polyglot

Vendor lock-in is a legitimate concern when evaluating any developer tool. With a traditional TMS like Crowdin or Lokalise, the platform is the system of record — if you stop paying, you'll want to export translations and memory before you lose access. With Polyglot, the architecture is different, and the answer to "what if I leave?" is deliberately boring.

Your translations live in your repo

Polyglot writes standard translation files directly to your repository — JSON by default, or your framework's own format, like ARB for Flutter. These files are committed to git alongside your source code. They're version-controlled, reviewable in PRs, and deployed through your existing pipeline.

messages/
  en.json
  fr.json
  de.json
  ja.json

These are plain JSON files. They don't use a proprietary format, they don't reference a Polyglot-specific schema, and they don't require a Polyglot runtime to read. They work with next-intl, react-i18next, react-intl, i18next, svelte-i18n, and any other library that reads JSON translation files.

Need a different format? polyglot export --format yaml (or arb, strings, or xml) converts your catalogs locally. It doesn't touch our backend.

If you stop using Polyglot, nothing happens to the translations in your repo. They stay there. They keep working. Your app doesn't notice.

One thing to check first: generated translations wait for review in the Polyglot dashboard. If reviewers approved or edited translations there, run polyglot pull --approved-only to write that reviewed work into your catalogs before you go.

What you lose if you leave

Let's be specific about what changes:

You lose automation. You don't lose data.

Translation memory lives in your Polyglot account and is kept while your account uses the service. The translations it produced are already in your repo once you've pulled them. If you want your account data exported or deleted, you can ask from the dashboard or by contacting us — see our privacy policy for retention details. The glossary file (polyglot-glossary.yaml) is a YAML file in your repo that you own. The cache file (.polyglot-cache.json) is also in your repo.

What about the Polyglot-specific files?

A few Polyglot files may exist in your repo:

polyglot.toml — Your project configuration. If you stop using Polyglot, you can delete it. It's not read by anything else.

polyglot-glossary.yaml — Your glossary terms. This is a simple YAML file listing your product terminology and preferred translations. Even without Polyglot, this file is useful documentation for anyone doing manual translation. Keep it or delete it — your choice.

.polyglot-cache.json — Content hashes from your last translation run, so polyglot translate only sends new or changed strings. You can safely delete this.

polyglot-i18n-report.md / .json — The report polyglot wrap writes about what it changed and what it left for you. Delete them whenever you like.

None of these files affect your application at runtime. They're all development-time files.

How to migrate away

If you decide to switch to another tool:

1. Pull reviewed work. Run polyglot pull --approved-only so approved dashboard edits land in your catalogs.
2. Your translations are already portable. JSON translation files work with every major i18n library and TMS. Upload them to Crowdin, Lokalise, Phrase, or any other platform.
3. Delete Polyglot files. Remove polyglot.toml, .polyglot-cache.json, any wrap reports, and optionally polyglot-glossary.yaml.
4. Remove the GitHub Action. Delete the Polyglot step from your CI workflow. If you installed the Polyglot GitHub Apps for Automation, uninstall them in GitHub too.
5. Uninstall the CLI. If you installed with Homebrew, run brew uninstall polyglot. If you used the install script, delete ~/.local/bin/polyglot (or remove polyglot from the custom directory you set with POLYGLOT_INSTALL).

That's it. There's no bulk export step because your translations were never locked in a platform — they were always in your repo.

Why we built it this way

We designed Polyglot around files in your repo — not data in our platform — because it's the right architecture for a developer tool. Translations are code artifacts. They should live with your code, version with your code, and deploy with your code.

This design also means you can evaluate Polyglot without any risk. Run polyglot scan on your project right now — it's free, read-only, and produces no side effects. If the results are useful, translate a few strings. If it's not for you, delete the config file and move on. There's nothing to unwind.

The free tier (50 strings with no account, 500 lifetime source strings once you sign up) exists for exactly this reason. We'd rather you try Polyglot risk-free and decide it's not right for you than never try it because you're worried about getting locked in.