How to auto-translate new i18n keys on every push

Tools like Phrase Strings or Lokalise watch your repository and sync keys both ways. This is the mature path: review queues, translation memory, glossaries, roles for translators. It is also built and priced for teams — Phrase’s self-serve developer plan runs around $525 a month, and Lokalise starts around $144 with no free plan. If you are one person shipping one product, you are paying for a workflow (approvals, vendor management) you will never use.

Open-source Actions like i18n-ai-translate or i18n Autopilot run in your workflow and call an AI model directly. The catch is in the name: your model account. You create an OpenAI (or other provider) account, generate an API key, put it in your repo secrets, and watch a second bill that scales with how fast you ship. You also own what happens when the model changes, the key leaks into a fork, or the Action overwrites a translation you fixed by hand.

The DIY version of option 2: a script that diffs your locale files, calls a model API, and writes the results back. It is genuinely fine for a weekend project, and you learn a lot. What it doesn’t give you is the boring parts — diffing YAML, PO and ARB files correctly, protecting keys you corrected by hand, and opening a reviewable pull request instead of committing straight to main. Every hour maintaining the script is an hour not building the product.

The newest option collapses the setup to two artifacts: a workflow file and one token from a service that runs the model on its side. Verba works this way — you paste a workflow into .github/workflows, add your Verba token as a repo secret, and on every push the workflow sends your locale files over, the new and changed keys come back translated through Verba’s own model gateway, and the pull request opens itself:

# .github/workflows/verba.yml
- uses: actions/checkout@v4
- run: |
    curl -s --data-binary @locales/en.json \
      -H "Authorization: Bearer $VERBA_TOKEN" \
      https://verba.nanocorp.app/translate

The honest limits at launch: it is one repository per plan, it handles JSON, YAML, PO and ARB files (not every exotic format), and there is no glossary or per-project tone yet. If you need translator roles or translation memory, a platform is still the right answer.

Whichever route you take, two properties matter more than the price. First, translations a human corrected must never be overwritten by the next run — an automation that silently reverts your work will cost you more trust than it saves time. Second, the tool should work off your repository’s own workflow, so you can revoke it with one secret deletion rather than untangling a GitHub App installation with broad permissions.