01
String changes hide in large pull requests without clear localisation impact.
GitHub release localisation
Localisation checks that run with every pull request
Detect string changes, gather PR context, draft translations, and gate releases — so engineering teams catch localisation issues before merge, not after launch.
Join the waitlistThe shift
Localisation is still a manual step outside the release pipeline
02
Engineering and localisation coordinate over Slack instead of inside CI/CD.
03
Translation files drift from source strings between releases.
Overview
Developers merge string changes daily. Localisation quality depends on someone remembering to check before ship.
01
GitHub Action for localisation checks
Run drift detection, coverage checks, and regression evals on every pull request.
02
Detect string changes from PR diffs
Surface added, modified, and removed keys with context from the pull request description and linked issues.
03
Draft translations with your preferred LLM
Generate locale drafts automatically when strings change, using glossary and TM context.
04
Comment on pull requests with localisation status
Give reviewers a clear view of locale coverage, quality flags, and unresolved items before merge.
How it works
From pull request to release gate
Hyperlocalise fits into the developer workflow your team already runs — with GitHub Actions and TMS sync built in.
01
Pull request
Detect added, changed, and removed strings
02
Change analysis
Map diffs to locales and glossary impact
03
Translation draft
Generate locale drafts with your LLM
04
Review routing
Open review tasks in your TMS
05
CI check
Run localisation gates in GitHub Actions
06
Release gate
Block merge when locales are unresolved
Key capabilities
Built for developer-led release workflows
05
Sync approved strings to your TMS
Push translations to Crowdin, Lokalise, Phrase, or Smartling without leaving the release flow.
06
Block releases when quality gates fail
Configure checks that prevent merge when critical locales are missing or regression thresholds are exceeded.
Why this is different
Localisation intelligence inside your CI/CD pipeline
Hyperlocalise is not a replacement for your TMS or i18n library. It adds an AI-native layer that connects GitHub change signals, translation drafting, and release gates.
01TMS agnostic
02LLM agnostic
03Human-in-the-loop when review is required
04Context-aware from pull requests and issues
05Built for engineering and localisation operations
06Works across GitHub, TMS, and release tooling
Example workflow
A pricing page refactor opens a pull request on Tuesday
A developer opens a pull request that renames fourteen UI strings and adds six new ones. Hyperlocalise comments on the PR with affected locales, generates translation drafts using glossary context from the linked launch brief, opens review tasks in Lokalise, runs the GitHub Action to verify all target locales are covered, and blocks merge until German and Japanese reviewers approve the updated pricing terminology.
Build your AI-native localisation workflow
Join the Hyperlocalise waitlist and bring localisation checks into your release pipeline.