Managed GitHub Checks

Managed Checks compare immutable revisions on GitHub Actions, publish a native result, and keep policy and history visible to the team. They do not upload raw source excerpts and they begin informationally.

1. Install the Checks App

1. Open Dashboard → Automation → Settings.
2. Select Connect GitHub.
3. Choose the organization and only select repositories.
4. Select the intended repository and polyglot.toml config root in Polyglot.

The App reads metadata, contents, pull-request context, and repository merge rules; writes native Checks; and uses Actions access only to dispatch the configured Polyglot workflow. Administration write is used only after an administrator confirms creation of Polyglot's dedicated ruleset. It has no contents-write permission. See the security guide for the exact boundary.

2. Commit the trusted caller

Copy the exact file shown in the dashboard to.github/workflows/polyglot.yml. Commit and push it to the default branch. GitHub cannot expose the manual dispatch endpoint until that file exists on the default branch.

name: Polyglot

on:
  pull_request:
  merge_group:
  push:
    branches: [main]
  workflow_dispatch:
    # Inputs and supported operations are generated by the dashboard.

permissions:
  contents: read
  id-token: write

jobs:
  polyglot:
    # Copy the complete immutable SHA from your dashboard.
    uses: polyglot-i18n/polyglot-action/.github/workflows/managed.yml@FULL_COMMIT_SHA

Do not replace the complete SHA with a branch, tag, shortened SHA, or a value from this guide. Backend trust and the repository caller must pin the same exact workflow contract.

3. Verify and run the first scan

The setup page polls while waiting for GitHub to register the workflow. Leave it open, or choose I've pushed it — verify setup. After detection, the same screen links the active first run, shows its completed result, or offers Run first scan when no run exists.

A run moves through requested, queued, and in-progress states before a final conclusion. The dashboard polls active runs and stops at the final state; manual refresh should not be necessary.

4. Blocking merges (early access)

1. Observe representative pull requests with informational policy.
2. Confirm base/head resolution, configuration roots, and expected existing debt.
3. Adopt no-new to fail only newly introduced findings.
4. After selecting an enforcing policy, finish Merge protection in the dashboard. Polyglot verifies that GitHub requires the stable Polyglot / i18n Check from the Polyglot App, or an administrator can confirm creation of a dedicated ruleset. Until that state is verified, the Check reports failures without blocking merges.

Managed checks begin informationally; Team and Scale customers can select an enforcing policy after establishing a baseline. Polyglot evaluates that policy, while GitHub blocks a merge only after Merge protection is verified. Existing findings remain visible and do not fail a no-new policy.

Event and fork behavior

• pull_request: resolves immutable base/head revisions and uses ordinary read-only permissions for forks.
• merge_group: evaluates the merge-queue revisions GitHub supplies.
• push: evaluates the default-branch update and may trigger post-merge catalog behavior when you've opted in.
• workflow_dispatch: runs only supported operations from the registered default-branch caller.

Missing base history, invalid OIDC claims, stale workflow pins, and incomplete analysis fail closed rather than guessing or reporting a false success.

What the result contains

Run detail records the event, repository, immutable revisions, policy and configuration identity, CLI version, conclusion, duration, finding counts, coverage and validation summaries, and links to the GitHub workflow and Check. Findings contain path, location, classification, category, confidence, remediation, and a keyed fingerprint—not the raw source value.

Continue with Translation PRs or use the recovery guide if setup cannot be verified.