Review workflow

The review workflow gives your team control over what ships when it matters that a human has read every string. Team members view and adjust translations in the Localhero.ai dashboard, without touching code or git or filing a ticket, and their edits go back to the original pull request as a commit.

You can also choose which languages get translated automatically, and use the same interface to fill in the ones you opted out of by hand.

The whole loop in 45 seconds: a pull request adds new copy, the check waits, a reviewer approves, the check turns green.

Reviewing AI translations

From the reviewer's side, the loop runs on the pull request:

1. A developer opens a pull request that adds or changes translation keys in the locale files. The GitHub Action translates the keys that are new or missing and commits the result to that PR, then posts a comment on the pull request linking to Localhero.ai.
2. Anyone with access to the project can add one or more reviewers. Each reviewer gets an email with a link to view the translations and adjust them as needed. With Slack connected you can also ask a channel; whoever opens the link from Slack becomes a reviewer. An organization admin connects Slack under Integrations in the organization settings, then each project picks its channels in its own settings, where you can also have every new pull request with translations posted to a channel.
3. The reviewer views the translations, rather than a code diff, and edits whatever needs fixing. Edits are saved on Localhero.ai. Each correction also goes into the project's translation memory, which later translations follow.
4. When done, the reviewer marks the PR approved, with a comment if they have one. The PR page on Localhero.ai shows how many of the assigned reviewers have approved, and shows "Ready to merge" when everyone has. Once every reviewer has approved, a comment saying so is posted on the pull request in GitHub.
5. If there were any edits to the translations, the PR page in Localhero.ai shows how many are not in the pull request yet. You or the reviewer click Sync to GitHub there. The edits go back to the pull request as a commit, so everything is included when it merges.

Screenshots on the pull request

A string is easier to review when you can see where it shows up. Add screenshots to the pull request description on GitHub as you normally would, or drop them on the PR page in Localhero.ai. Localhero.ai reads the text in each screenshot and matches it to the strings in the pull request. On the PR page, each string links to the screenshot it appears in, with the text outlined. Screenshots from the description need the GitHub App installed.

Screenshots are stored in Frankfurt (EU). Localhero.ai reads their text on its own servers there and does not send screenshots to AI models. They are deleted when someone removes them, on the PR page or from the description, or 90 days after the pull request is merged or closed.

The flow in just over a minute: a pull request with screenshots in its description, the GitHub Action commits the translations, a reviewer gets a ping in Slack, sees each string outlined in its screenshot and approves, the localhero/translations check turns green.

The translation check on the pull request

Translations can gate the merge button on the PR, the same way a test that does not pass can stop a PR from being merged. Once a reviewer approves, Localhero.ai reports a commit status called localhero/translations on the pull request, next to your own CI checks, reading Translations approved on Localhero. It links back to the PR page so anyone reading the pull request can jump to the translations.

If you make it a required status check, it becomes a condition for merging pull requests: Settings → Branches → Branch protection rules, edit the rule for your default branch, tick Require status checks to pass before merging, and search for localhero/translations. The check must have run on the repository at least once before GitHub offers it in that list, so approve translations on a pull request first.

A pull request with reviewers assigned then cannot merge until its translations have been approved. No process to remember, no release-day scramble to work out whether the Norwegian copy was ever read. Leave the check out of branch protection and it stays informational, a green tick showing the translations were reviewed.

The sync check on the pull request

An edit on Localhero.ai only ships once it is in the branch. A second commit status, localhero/sync, shows whether it is. Localhero.ai reports it on every pull request in a connected repository:

• Pending while edits on Localhero.ai are not in the pull request yet, and while a sync is on its way.
• Failing when the last sync didn't finish. The PR page says why and offers Try again.
• Passing when every edit is in the branch, or when there are none.

The check is optional. Make it required and a pull request can't merge while edits are still waiting on Localhero.ai. Add it the same way as localhero/translations: sync one edit to a pull request first, so GitHub has seen the check, then add localhero/sync under required status checks.

GitHub App installations from before the check need one more permission, Commit statuses: Read and write, before Localhero.ai can report localhero/sync. GitHub asks the account or organization owner by email to accept it. While it's missing, the project's general settings on Localhero.ai show a notice with a link to the right page on GitHub.

If a pull request is stuck on the check, open it on Localhero.ai and press Leave out of this PR. The check passes and the edits stay on Localhero.ai. Sync anyway sends them after all, and any new edit makes the check pending again.

Three limits:

• If Localhero.ai is down, new commits get no localhero/sync status until it is back. A required check then waits. Once Localhero.ai is back, it catches up within about 10 minutes.
• Remove the required check before you uninstall the GitHub App. Without the App nothing reports localhero/sync, and a required check that never reports blocks every pull request.
• Merge queues are not supported. Localhero.ai reports on pull request heads, not on merge queue commits, so don't require localhero/sync or localhero/translations on a branch that uses a merge queue.

Approvals are tied to the exact translations they were given for. Change a string after someone approved and Localhero.ai marks their approval stale on the PR page and offers Re-approve. An approval means someone read this text, not text that has since moved on.

You can also edit translations straight from the translations page, without a PR in context. Select the keys you changed, click Export to GitHub in the top right, and Localhero.ai opens a pull request with them.

Both features need the GitHub App installed. The App is what has permission to write to your repository. Without it, you can still review and edit in the dashboard, but nothing gets pushed back from there. Pull the translations down locally with the CLI instead.

Adding reviewers

Access to the project on Localhero.ai is all a reviewer needs. Invite them through the Members tab in your organization settings. They need neither git installed nor a code editor.

Developers keep the flow they already have. The locale files stay the source of truth in the repository, keys are added there, and translations arrive as commits on the pull request. Nobody has to switch tools to accommodate the other side.

Translating some languages yourself

Each target language in your project settings can have Auto-translate turned off. Turn it off for a language and Localhero.ai writes nothing for it: the GitHub Action and the CLI skip generating translations for it. The keys and the language stay in the dashboard for your own translator to fill in.

Useful when copy is written directly in the target language rather than translated, when you have specific needs in different markets, for legally sensitive wording, or for a variant with special requirements.

Further reading: GitHub App for what the App can write to your repository, and translation quality at scale for how consistency holds up across many keys.