Translation Automation: Streamlining Localization with CI/CD and Webhooks

Translation Automation: Streamlining Localization with CI/CD and Webhooks

Key Takeaways

• Translation automation eliminates manual file handoffs between developers and translators, reducing localization cycle times
• CI/CD integration enables continuous localization where new strings are automatically extracted, translated, and merged back
• Webhooks allow TMS platforms to trigger actions (builds, notifications, deployments) when translations are completed
• Automation reduces the risk of shipping untranslated content or outdated translations
• A well-automated workflow can cut localization turnaround from weeks to hours

What Is Auto Translation?

At its core, auto translation is the practice of removing manual steps from the translation workflow so that content moves from source language to target languages with minimal human intervention. The term covers a spectrum — from a simple API call to Google Translate, to a fully orchestrated pipeline that detects new strings in your codebase, translates them with context-aware AI, routes them through human review, and merges the approved translations back into your repository as a pull request.

Automatic translation matters because modern software teams ship continuously. If your translation process requires manual file exports, email coordination, and manual imports, it becomes the bottleneck that delays every international release. Auto translation eliminates that bottleneck.

There are three levels of automatic translation maturity:

1. Basic auto translation: A developer triggers an MT API (DeepL, Google Translate, Azure Translator) to translate a file, then manually integrates the output. Fast for one-off tasks, but does not scale.
2. Semi-automated translation: A TMS watches your repository or CMS for changes, applies translation memory and machine translation automatically, then notifies human reviewers. Most of the pipeline runs without intervention, but humans approve before publishing.
3. Fully automated translation pipelines: CI/CD-integrated workflows where string changes are detected on merge, translated via AI, validated by quality gates (placeholder checks, length validation, completeness thresholds), and merged back automatically if all checks pass. Human review is reserved for content types that require it (marketing copy, legal text).

The rest of this guide focuses on levels 2 and 3 — the CI/CD and webhook-driven approaches that make automatic translation a sustainable part of your development workflow, not a one-time shortcut.

Why Automate Translation?

In a manual localization workflow, developers extract translation files, email them to translators or upload them to a TMS, wait for translations, download completed files, and merge them back into the codebase. Each handoff introduces delays and opportunities for error.

Translation automation removes these handoffs by connecting your source code repository directly to your translation management system. When developers commit changes, new or modified strings are automatically detected and sent for translation. When translators complete their work, translations are automatically synced back.

The Automated Localization Pipeline

A typical automated pipeline follows this flow:

Developer commits code
        ↓
CI/CD detects changed translation files
        ↓
TMS CLI pushes new/changed strings to TMS
        ↓
TMS applies translation memory (instant matches)
        ↓
Unmatched strings → MT pre-translation or human assignment
        ↓
Translator completes translations in TMS
        ↓
Webhook triggers: "translations completed"
        ↓
CI/CD pulls completed translations back to repo
        ↓
PR created with new translations
        ↓
Review, merge, deploy

CI/CD Integration Patterns

GitHub Actions Example

Most TMS platforms provide CLI tools that can be used in CI/CD pipelines:

# .github/workflows/sync-translations.yml
name: Sync Translations

on:
  push:
    branches: [main]
    paths:
      - 'src/locales/en/**'

jobs:
  push-sources:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Push source strings to TMS
        run: |
          npx @better-i18n/cli push \
            --project your-org/your-project \
            --source src/locales/en
        env:
          BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}

Pull Translations on Schedule

# .github/workflows/pull-translations.yml
name: Pull Translations

on:
  schedule:
    - cron: '0 */6 * * *'  # Every 6 hours
  workflow_dispatch:       # Manual trigger

jobs:
  pull-translations:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pull completed translations
        run: |
          npx @better-i18n/cli pull \
            --project your-org/your-project \
            --target src/locales
        env:
          BETTER_I18N_TOKEN: ${{ secrets.BETTER_I18N_TOKEN }}
      - name: Create PR if translations changed
        uses: peter-evans/create-pull-request@v6
        with:
          title: 'chore(i18n): update translations'
          commit-message: 'chore(i18n): pull latest translations from TMS'
          branch: i18n/update-translations

GitLab CI/CD

# .gitlab-ci.yml
push-sources:
  stage: sync
  only:
    changes:
      - src/locales/en/**
  script:
    - npx @better-i18n/cli push --project $PROJECT_ID --source src/locales/en

Webhook-Driven Workflows

Webhooks allow your TMS to notify your systems when events occur — translations completed, reviews approved, or new strings detected.

Common Webhook Events

Webhook Handler Example

// Express.js webhook handler
app.post('/webhooks/translations', (req, res) => {
  const { event, language, project } = req.body;

  if (event === 'translation.completed') {
    // Trigger GitHub Actions workflow via API
    triggerWorkflow('pull-translations', {
      language,
      project,
    });
  }

  res.status(200).json({ received: true });
});

File Format Considerations

Different file formats affect how automation works:

Your automation pipeline needs to handle the specific format your codebase uses. Most TMS CLI tools support all common formats.

String Extraction Automation

For projects that don't use separate translation files, automated string extraction identifies translatable strings in source code:

Static Analysis

Tools scan source code for translation function calls:

// These patterns are detected by extraction tools:
t('home.title')
useTranslations('common')
formatMessage({ id: 'greeting' })

Extraction Configuration

{
  "extract": {
    "patterns": ["src/**/*.{tsx,ts}"],
    "functions": ["t", "useTranslations", "formatMessage"],
    "output": "src/locales/en/messages.json"
  }
}

Running the extraction command as a pre-commit hook or CI step ensures that new translatable strings are always captured.

Quality Gates in Automated Pipelines

Automation should include quality checks to prevent broken translations from reaching production:

1. Placeholder validation: Verify that all placeholders ({name}, {count}) from source strings exist in translations
2. Length validation: Flag translations that significantly exceed source string length (may cause UI overflow)
3. Completeness check: Ensure all required languages meet a minimum translation percentage before deployment
4. Format validation: Verify that translation files are valid JSON/XLIFF/PO (no syntax errors)

# Quality gate in CI
- name: Validate translations
  run: |
    npx @better-i18n/cli validate \
      --source src/locales/en \
      --target src/locales \
      --min-coverage 95

Common Pitfalls

1. Over-syncing: Pulling translations on every commit creates noisy PRs. Use scheduled pulls or webhook-triggered pulls instead.
2. Missing context: Automated extraction captures strings but not screenshots or descriptions. Provide context through comments or TMS features.
3. Branch conflicts: Translation PRs can conflict with feature branches. Merge translation updates frequently to minimize conflicts.
4. Secret management: TMS API tokens must be stored securely in CI/CD secrets, not committed to the repository.
5. Rate limiting: API calls to TMS platforms may be rate-limited. Implement backoff and retry logic in automation scripts.

FAQ

How often should I sync translations?

Push source strings on every merge to main (or your primary branch). Pull translations either on a schedule (every 4-6 hours) or via webhook when translations are completed. Avoid syncing on every commit to feature branches — it creates unnecessary noise.

Should I auto-merge translation PRs?

For well-established workflows with quality gates (placeholder validation, format checking), auto-merging translation PRs can be safe. For new setups, require manual review until you're confident in the quality checks. Many teams auto-merge for non-critical languages and require review for primary markets.

What if translations break the build?

Add a CI check that validates translation files before merging. If a translation file has invalid syntax, missing placeholders, or other issues, the PR should fail CI and not be merged. This prevents broken translations from reaching production.

Is auto translation good enough for production?

Auto translation — meaning fully automated machine translation without human review — is suitable for internal tools, developer documentation, and low-stakes content where speed matters more than polish. For user-facing product UI, marketing copy, and legal content, auto translation should serve as the first draft in a pipeline that includes human review. The goal of automatic translation in a CI/CD context is not to eliminate humans, but to eliminate the manual coordination that slows them down.