Dashboards are great for translators. They're terrible for developers. Here's why a CLI-first approach to i18n is faster, more reliable, and fits your actual workflow.
The localization industry has spent 15 years building dashboards. Crowdin has a dashboard. Lokalise has a dashboard. Phrase has a dashboard. Transifex has a dashboard. Every TMS on the market assumes that the primary interface for managing translations is a web browser.
This makes sense for translators. Professional translators work in dashboards all day — they need visual context, collaboration features, and approval workflows. But the person who's actually responsible for i18n at most startups and small teams isn't a translator. It's a developer. And developers don't work in dashboards.
Here's what i18n actually looks like for a developer:
Steps 3-9 are overhead. They interrupt your flow, require context switching, and involve waiting for syncs and uploads that shouldn't be necessary. The actual work — identifying strings, translating them, and verifying the result — takes minutes. The dashboard overhead takes longer.
Here's the same workflow with a CLI tool:
polyglot scan in your terminalpolyglot wrap --dry-run, then polyglot wrap if the new strings are hardcodedpolyglot translate in your terminalpolyglot preview to check the result in your running appGenerated translations still get a human look: they wait for review in the Polyglot dashboard, and reviewer seats are free. That's the one place a browser earns its keep.
No file uploads. No sync delays. The mechanical work happens in the same terminal where you're already writing code.
A CLI tool that reads and writes files in your repo means translations are version-controlled from the start. You can:
git revertgit blameWith a dashboard TMS, translations live in a separate system. Getting them into your repo requires sync plugins, webhooks, or manual downloads. Every sync is a potential point of failure.
A CLI tool runs natively in GitHub Actions, GitLab CI, or any CI system. No special plugins, no API tokens for a third-party platform, no webhook configuration. The open Polyglot Action works this way — the workflow lives in your repo, and it flags new untranslated strings on every PR without an API key. Under the hood, it's one command comparing your PR against its base:
# Needs a full-history checkout (fetch-depth: 0) and a committed polyglot.toml
- run: polyglot check --base ${{ github.event.pull_request.base.sha }}
Integrating a dashboard TMS into CI typically requires installing a platform-specific CLI, configuring API credentials, and writing custom scripts to pull/push translations. It works, but it's more setup and more things that can break.
A CLI tool works offline, on a plane, in a coffee shop with bad WiFi. Your translations are files on your filesystem. polyglot scan, wrap, preview, and validate run locally without an internet connection. polyglot preview runs your own dev server. Translation and review are the parts that need our service.
A dashboard TMS requires internet access for everything — you can't even see your translations without loading a web page.
polyglot scan is a local command. It parses files in parallel across your CPU cores and prints results where you're already working. Checking the same thing in a dashboard means loading a page, finding the right project, and filtering to the right strings.
Those small context switches add up across a week of feature work.
CLIs aren't always the right answer. You need a dashboard when:
The key question is: who is responsible for i18n at your organization? If it's developers (common on smaller teams), a CLI tool fits your workflow. If it's a dedicated localization team working with external translators, a dashboard fits theirs.
You don't have to choose one or the other. You can use Polyglot for detection and initial translation (the developer workflow), then export to a dashboard TMS for professional review of marketing and brand-sensitive content. And on Team and Scale plans, Polyglot Automation (early access) covers the CI side — after someone reviews the generated translations, it opens a separate catalog-only PR for your team to merge.
# Developer workflow: detect, wrap, and translate
polyglot scan
polyglot wrap --dry-run
polyglot wrap
polyglot translate --languages fr,de,ja
# Export for professional review (if needed)
polyglot export --format yaml --output export # or json, arb, strings, xml
# Upload the files to Crowdin/Lokalise for human review
This gives you the speed and developer experience of a CLI for most UI strings (labels, buttons, error messages) and the visual context of a dashboard for the copy that needs closer human review (marketing copy, brand messaging).
curl -fsSL https://getpolyglot.ai/install.sh | bash
polyglot init
polyglot scan
polyglot wrap
polyglot translate
polyglot preview
One install line and five workflow commands, no account required for scanning, wrapping, or previewing. That's what a developer i18n workflow should feel like.
Start in your terminal
Install the CLI, run a scan, and see exactly what you're missing. Free, no account required.