How to Automate i18n in Your GitHub Repo

The problem with manual i18n

If you've shipped a multilingual product, you know the cycle. A developer adds a feature in English. It goes to code review, gets merged, ships to production. At some point — maybe two weeks later, maybe two months — someone notices the Spanish UI has a raw English key sitting in the middle of a sentence.

This isn't a discipline problem. It's an architecture problem. Manual i18n workflows require developers to remember to extract strings, upload them to a translation platform, wait for translators, download the results, and merge them back. Every step is a handoff. Every handoff is a place where things go stale.

The average team spends 4–8 hours per release cycle on localization busywork. For a weekly release cadence, that's a full engineering day per month that produces nothing except keeping up. And the output still drifts.

Why existing tools don't fully solve it

The localization platform market is mature. Crowdin, Phrase, and Lokalise have been around for years. They're genuinely good at what they do — but what they do is provide infrastructure for human translators. They don't automate the workflow. They automate the storage.

The core pricing assumption of traditional TMS platforms is translator seats. The pricing scales with how many human translators are using the platform. If you're trying to run a lean team where AI does the translation, you're paying for infrastructure you don't use and missing automation you need.

What a fully automated i18n pipeline looks like

A properly automated i18n workflow has three stages that run without developer intervention:

1. Detection — the system notices when new translatable strings appear in your source files.
2. Translation — the strings are translated with context preserved (variables, plurals, tone, product terminology).
3. Delivery — the translated files land in your repository as a reviewable pull request.

That last step matters more than it sounds. Delivering translations as a pull request (rather than committing directly to main) keeps humans in the loop without making them do the translation work. You review a diff, not a spreadsheet. You merge when you're satisfied. The review takes two minutes instead of two hours.

How to set this up with GitHub Actions (manual approach)

If you want to build the automation yourself, here's the general shape of it. The GitHub Actions approach is good for teams who want full control over every step.

Create a workflow that triggers on push to main whenever i18n source files change:

name: Translate new strings
on:
  push:
    branches: [main]
    paths:
      - 'src/locales/en.json'

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Detect new strings
        run: |
          # diff en.json against last commit
          git diff HEAD~1 -- src/locales/en.json > diff.txt
      - name: Translate via AI
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: node scripts/translate.js
      - name: Open PR
        uses: peter-evans/create-pull-request@v6
        with:
          title: "chore(i18n): auto-translate new strings"
          branch: "lokali/translations"

This works, but it leaves the hardest part to you: the translate.js script. Writing a script that correctly handles nested JSON keys, preserves template variables like {{name}} or {count, plural, ...}, avoids retranslating strings that already exist, and produces consistent output across languages — that's a couple of weeks of work to do right.

Common failure modes when rolling this yourself:

• Variable corruption — LLMs will translate {{name}} to {{nombre}} unless explicitly instructed not to.
• Key drift — if your translation script doesn't detect existing keys correctly, you'll overwrite human-corrected translations on every run.
• Plural forms — most languages have plural rules that differ from English. Arabic has six plural forms. Your script needs to handle this or produce broken output.
• Context loss — "Save" means something different in a file editor vs. a payment flow. Without context, translations default to generic.

The faster path: a repo-connected translation agent

The alternative is connecting your repo to a system that handles the full pipeline — diff detection, context-aware translation, variable preservation, and PR submission — as a managed service.

This is exactly what Lokali does. You connect a GitHub repo, pick your target languages, and the agent monitors pushes. When new strings appear in your source locale file, Lokali:

• Detects the diff between the source file and what's already translated
• Translates only the new strings, preserving existing translations
• Handles variables, nested keys, and plurals correctly
• Opens a pull request in your repo with a clean diff

The whole cycle — new string merged to main, translated PR opened — runs in under 60 seconds.

// New string added to en.json
"checkout_confirm": "Review your order, {{name}}"

// Lokali opened PR with de.json updated:
"checkout_confirm": "Bestellung überprüfen, {{name}}"

// Variable preserved. Key matched. PR ready to merge.

What to look for in any i18n automation tool

Whether you build it yourself or use a service, a production-ready i18n automation setup needs to handle:

1. Incremental translation — only translate new strings, never overwrite existing ones. Full-file retranslation is slow, expensive, and destroys human edits.
2. Variable safety — {{name}}, %s, {0}, %(key)s must survive translation unchanged.
3. Plural form awareness — the CLDR plural rules differ by language. German has two forms, Arabic has six, Japanese has one.
4. Context injection — "free" in English could mean "free of charge" or "free to use." Passing product context to the translation model prevents these ambiguities.
5. PR-based delivery — translations should be reviewable before they hit main. Direct commits to main bypass the review process.
6. Multiple file formats — JSON is common but YAML, PO, XLIFF, and ARB files all show up in real codebases.

The compounding value of i18n automation

The real ROI of automating i18n isn't the hours saved on any single release. It's that localization stops being a release gate.

When translations are handled manually, teams batch them. You don't run a translation cycle for every PR — you collect strings, translate in bulk before a milestone, and ship. This means your non-English users are always 1–4 weeks behind English users.

With a fully automated pipeline, every merged PR that touches a source locale file triggers a translation PR. There's no batch cycle. There's no backlog. Your product launches globally on day one, and every feature ships in every language at the same time.

Getting started

The path to fully automated i18n in your GitHub repo:

1. Audit your current translation workflow — how many steps involve a human that could be automated?
2. Pick a delivery mechanism — GitHub Actions workflow you own, or a managed service that handles the pipeline.
3. Set up incremental translation — never retranslate the whole file, only the diff.
4. Test variable handling before shipping to production — this is where most DIY scripts break.
5. Ship translations as PRs, not direct commits — keep humans in the approval loop.

If you want to skip straight to step 5 and have the rest handled for you, Lokali connects to your GitHub repo and runs the full pipeline autonomously. No CLI, no config files, no dashboards to manage.