Help › Keys, CLI and automation

Run translations from CI

Partly builtLast updated

On this page

You can let your build system keep translations up to date. Each time your strings file changes on your main branch, the job sends the new text, translates it and publishes. On a pull request, it only counts what would change.

These integrations are in the repository. They are not on any marketplace or registry, and examples use placeholder addresses. Publishing them needs the owner's approval: OPEN.

What happens#

GitHub Actions#

Use the action from a checkout of the repository. Give it your control-plane address, your site and a secret key stored as a repository secret. Use a read-only key for pull requests and a key with write scopes for the main branch. The workflow needs pull-requests: write only to post the comment. A read-only token, such as on a fork, turns the comment into a warning.

GitLab CI#

Include the provided file and set the CI/CD variables for the key, address and site. Mark the key Masked and Protected. Protected variables are not given to unprotected branches or forks, so those pipelines fall back to the offline count. The merge request note needs an optional project token. Details of how GitLab merge request pipelines select files are verify.

Bitbucket Pipelines#

Paste the provided pipeline file and add the key as a secured variable. The preview goes to the log and a file. It does not post a comment on Bitbucket. Forked pull requests get no secured variables.

Keys and scopes#

Never put a secret key in the workflow file. Store it as a secret. A sync needs strings:write, translations:write and bundles:publish. A preview needs sites:read and translations:read. See API keys.

Plan limits#

If the plan or allowance stops a run, it fails with a 402 explanation. See CI run failed.