hyperlocalise is built for teams that want faster localization cycles without giving up reviewer control.
It combines local draft generation, explicit TMS sync steps, and Git-friendly workflows so engineering and localization teams can collaborate in one delivery path.
Unlike TMS-only or custom-script approaches, Hyperlocalise is designed for teams that keep translation files in-repo and need a repeatable draft-to-curation loop with conflict-aware sync.
Who this is for
Hyperlocalise is a good fit if your team:- keeps translation files in your repository,
- uses AI drafts as a starting point rather than final output,
- may use human curation for some workflows but wants it to be optional,
- wants CI-visible status and quality checks around localization work.
Why teams choose Hyperlocalise
1. Developer velocity with operational guardrails
The CLI is designed around plan-first workflows. You can inspect work with--dry-run, generate drafts locally, and rerun incrementally with lockfile-backed checkpoints.
This reduces repeated translation work while keeping changes reviewable in normal Git diffs.
2. Human curation is supported, not required
Hyperlocalise does not assume machine output is production-ready. The intended loop is straightforward: generate drafts, push to your TMS, curate with human reviewers, then pull curated values back into the repository. This keeps source-of-truth decisions with your localization team. If your team needs speed over review in specific pipelines, you can also run a local-only path and publish without TMS sync.3. Better visibility for release decisions
Teams can usestatus reports to track translated, needs-review, and untranslated content by locale. For quality experiments, you can run eval (experimental) to compare candidate outputs against a baseline in a repeatable format.
4. Provider and platform flexibility
You can run multiple LLM providers and integrate with common TMS adapters (for example Crowdin, Lokalise, POEditor, Phrase, Smartling, and Lilt) without redesigning your entire workflow around one vendor.How it fits your existing workflow
A typical path looks like this:- Initialize config with
init. - Define locales, buckets, and profiles in
i18n config. - Generate drafts with
run. - Optional curation path: use
sync push(experimental), curate in TMS, thensync pull(experimental). - Verify progress with
statusbefore release.
When Hyperlocalise is not the best fit (yet!)
Hyperlocalise may not be the right choice today if you:- need a fully hosted localization platform with no CLI usage,
- cannot run repository-based workflows in developer or CI environments,
- require a workflow where all localization operations are managed only inside a hosted TMS UI.
Quick comparison
| Approach | Setup effort | Review control | CI/Git workflow fit | Vendor lock-in risk |
|---|---|---|---|---|
| Manual scripts | 🟡 Medium to high (build and maintain yourself) | 🟢 High (fully custom) | 🟡 Medium (depends on script quality and standards) | 🟢 Low |
| TMS-only workflow | 🟢 Low to medium | 🟡 Medium to high in TMS, lower in Git-based review | 🟡 Low to medium for in-repo workflows | 🟠 Medium to high |
| Hyperlocalise | 🟢 Low (single CLI with straightforward config) | 🟢 High (AI draft + optional human curation loop) | 🟢 High (explicit dry-run, sync, status flow) | 🟢 Low (multi-provider and multi-adapter support) |
FAQ
Is Hyperlocalise a replacement for my TMS?
No. Hyperlocalise is built to work with your TMS, not replace it. The intended model is local draft generation plus human curation in your existing translation platform.Can I use Hyperlocalise with Crowdin, Lokalise, or POEditor?
Yes. Hyperlocalise supports multiple TMS adapters, including Crowdin, Lokalise, and POEditor (plus Phrase, Smartling, and Lilt).Can this run in CI?
Yes. Teams commonly run planning, generation, and reporting commands in CI to keep localization changes visible in standard release workflows.Does Hyperlocalise publish machine translations directly to production?
Yes, it can. TMS curation is optional, and teams can choose a zero-human-review path when that matches their risk tolerance and release process.Next steps
New user path: Install -> Quickstart -> i18n config Evaluation path: Quickstart ->eval (experimental) -> status
TMS curation path: Storage overview -> sync push (experimental) -> TMS curation loop (experimental) -> sync pull (experimental)