Localization in CI/CD: translate on every commit

Add translation to your CI/CD pipeline with PTC: a token, one workflow file, and translated files return as a pull request on GitHub, GitLab or Bitbucket.

In short: four steps

1. Create a PTC project and choose API integration. You describe the product, choose the languages and get a project API token.
2. Add the token to your repository as the secret PTC_API_TOKEN.
3. Add the ready-made workflow for your CI. See the examples for GitHub Actions and GitLab CI.
4. Push. PTC translates only the new and changed strings, and the translated files come back as a pull request.

The full setup is below. You set this up once; after that every commit is translated without anyone starting it.

Source files change, PTC translates automatically, translated files land back in your repo as a merge request, and AI Visual QA verifies the rendered app before the release ships. No file shuttling between teams, no agency hand-offs between releases.

The localization workflow that is slowing your team down

Most engineering teams adopt localization the same way. They hit the same three problems:

• Translations break the UI. German words are roughly 30% longer than English. You only find out that your buttons overflow in production.
• Localization is always the last step. You manually export .json, .po, or .strings files. Translations come back late and delay your release.
• Translations do not reflect your brand. Generic software translation tools do not know your feature names, your technical terminology, or whether your tone is formal or playful.

PTC replaces all three with a CI-native flow.

What sets PTC apart for software localization

Each item below links to the detailed section further down the page.

• PTC learns your product's vocabulary and brand voice - tailored translations per project, with context-aware accuracy across every resource file.
• Visual translation review of your running software - PTC reviews your rendered app so you ship without manual QA per language.
• Native CI/CD integration with GitHub, GitLab, and Bitbucket - a push that adds or changes source strings comes back as a merge request.
• Glossary and translation memory per project - terminology stays consistent across every resource file in the project and across every release.
• Every common resource format handled out of the box - JSON, YAML, PO, .strings, .xcstrings, .properties, XLIFF, CSV, and more.

PTC learns your product's vocabulary and brand voice

PTC is not a translation tool that helps your team translate. PTC is the translator. It learns your product's vocabulary, tone, and rules from the strings you upload, and applies them consistently across every release.

Built for development teams, not bolted on after

A software translation tool earns its place when it fits the existing workflow, understands technical file formats, and preserves placeholders and variables. PTC is built for exactly this: it parses your resource files automatically, learns your product's terminology, and delivers translations that respect your UI constraints, so your engineers keep their workflow instead of adapting to a generic translation app.

• Brand voice per project. Define your product's purpose and audience once. PTC uses this context for every string, so your translations sound like they were written by your team. This holds whether your product is formal or casual, technical or consumer-facing.
• Glossary that compounds. Add brand-specific terms, feature names, and “do-not-translate” rules once. “Cart = Carrito” for Spanish. PTC enforces them across every file, every language, every future update.
• Translations that fit your UI. PTC uses smart length defaults for each target language and flags overflows while you translate, not after you build.
• Placeholders, handled correctly. PTC recognizes placeholders like %s, {{name}}, {0}, %1$s in every supported resource format. Variables are preserved so you never release a broken string.
• Translation memory across updates. When you change one word in a paragraph, PTC re-translates only what changed and preserves the rest.
• No guessing. If a string is ambiguous (is “Submit” a button or a noun?), PTC stops and asks instead of picking a wrong meaning.

Visual translation review of your running software - ship without manual QA per language

Translation is necessary but not sufficient for shipping multilingual software. A translated string can ship a broken product. A German label that overflows a button. A French word with the wrong part of speech. An English string someone forgot to wrap in the i18n helper. Catching these traditionally means a multi-day manual QA pass per language per release. That is the most expensive and slowest stage of localization, and the reason many teams limit themselves to two or three languages.

PTC's AI Visual QA replaces that pass with CI-native automation. Two flavors cover every kind of software:

• Browser extension (for browser-based software like SaaS, web admin UIs, web-based desktop apps). Install the PTC browser extension and record a walkthrough of your app's critical user flows once. From then on, PTC replays the recording after every release, captures each screen in each language, and inspects the rendered result.
• Screenshot upload (for native desktop apps, server CLI tools, or any non-browser software). Upload one screenshot per language per screen. PTC's vision AI inspects the rendered result the same way.

Issues PTC can fix in the resource files (verb/noun ambiguity, layout overflow, plural mismatches) get fixed automatically. Issues that live in your source code (missing wrappers, hardcoded strings, sentence concatenation) come back as ready-to-paste prompts for Cursor or Claude Code.

The deliverable shifts from “translated resource files” to “release-ready multilingual software”. No other localization platform offers this today.

Native CI/CD integration with GitHub, GitLab, and Bitbucket

Commit a .ptc-config.yml naming the files that carry your source strings and where the translations belong:

# .ptc-config.yml
source_locale: en
files:
  - file: src/locales/en.json
    output: src/locales/{{lang}}.json
  - file: app/src/main/res/values/strings.xml
    output: app/src/main/res/values-{{lang}}/strings.xml

Then add the PTC Translate action to your workflow. It carries a pinned version of the PTC CLI inside itself, so your build downloads nothing at run time:

# .github/workflows/translate.yml
name: Translate
on:
  push:
    branches: [main]
    paths:
      - 'src/locales/en.json'
      - 'app/src/main/res/values/strings.xml'
  workflow_dispatch: {}

jobs:
  translate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: OnTheGoSystems/ptc-action@v1
        with:
          api-token: ${{ secrets.PTC_API_TOKEN }}
          create-pr: true

PTC syncs the new source strings, translates them into your target languages, and opens a pull request with the updated es.json, de.json, values-es/strings.xml, and so on. Your team reviews it like any other code change. A push that leaves your source strings unchanged translates nothing and opens nothing.

For GitLab CI, Bitbucket Pipelines, CircleCI, or any other CI system, the same flow works via REST. See the PTC API reference for the full webhook and sync API.

For teams shipping multiple releases per week, PTC scales without per-release overhead. PTC only re-translates strings that actually changed. A 10-string update does not re-translate the other 10,000. PTC runs 24/7. You never wait on an agency's next-week delivery estimate.

Localization runs alongside your code, not after it

Continuous localization means translation lives inside your development lifecycle instead of becoming a separate stage at the end. PTC delivers this by connecting to your Git repository or CI/CD pipeline. When you push new code, PTC detects the new strings, applies your product context and glossary, translates them, and returns them as a merge request, so localization keeps pace with every commit rather than blocking the next release.

How the CI/CD Integration Works

Before you set up PTC with your CI system, here are the three principles behind the PTC API and CLI:

1. Resource files are tied to a branch

Every file you send to PTC is linked to a branch name (e.g. main, feature/new-checkout). This keeps translations separate, so translations from different features don’t overwrite each other. When you use the ready-made CI/CD configurations, this mapping is already handled automatically.

2. Translations are processed asynchronously

PTC does not return translations immediately. Instead, it:

• Uploads the updated files
• Identifies only the new or modified strings
• Translates the strings
• Prepares translated files for download

3. One CLI script works everywhere

Instead of calling the API yourself, use the PTC CLI:

One script handles the entire flow (upload → poll → download). The CLI runs on Linux and macOS, and works with GitHub Actions, GitLab, Bitbucket, or any other CI/CD platform.

High-Level Flow: Set Up the PTC API in Your CI/CD Pipeline

1Sign up for a trial.

Get full access to all features and translate up to 20,000 words into any two languages you choose.

2Create a new project.

When choosing how to use PTC, select API integration. During setup, you’ll provide a bit of context about your project (what it does, who it’s for) and select the languages you want to translate into.

3Get your API token.

At the end of the setup, you’ll receive a project-specific API token. Copy it and store it safely — you’ll need it to authenticate all requests. You can always find the same token again in your project dashboard under Settings → PTC API tokens.

4Add the PTC API token to your repository in the right location.

5Copy the ready-made CI/CD configuration.

On GitHub Actions, add the PTC Translate action to your workflow. Your API token is the only input you have to pass. The action carries a fixed version of the CLI inside itself, so your build never downloads a script at run time, and when a run produces new translations it opens the pull request for you.

On GitLab CI, Bitbucket Pipelines, or any other platform, copy the job for your platform from the PTC CLI CI/CD templates. Each template pins the CLI to a specific release and publishes the checksum to verify it against, so a later CLI release cannot change what your build runs.

6Run the workflow.

You can trigger the workflow manually, on commits that update resource files, or on a schedule. See triggers for GitHub, GitLab, and Bitbucket. A pull request needs a branch to open against, so on GitHub Actions the PTC Translate action opens one on a push, on a schedule, and on a manual run from a branch. On a pull_request, pull_request_target or merge_group event, or on a tag or a release, it stops with an explanation instead - translate on a push to your source branch, or set create-pr: false for that run.

When it runs, the CLI uploads your files, waits for translations to finish, and writes the updated translations back into your repository. If you’re using the ready-made configs and the run produced new translations, the workflow will also create a merge request with the changes, so you can review and merge them like any other code update. A run that finds nothing to translate writes nothing and opens no merge request. From here on, your translations stay in sync automatically.

CI/CD Examples

WordPress

• GitHub Actions
• GitLab CI

Ruby on Rails

• GitHub Actions

JSON Files (React Apps)

• GitHub Actions
• GitLab CI

Glossary and translation memory per project

Add a glossary entry once. For example: “Cart = Carrito” for Spanish. PTC applies the entry across every file in the same project, now and on every future update. You never re-upload TMX files between runs.

You can manage glossary entries in two ways. The PTC dashboard provides an editor for ad-hoc entries. The PTC REST API supports glossary import and export for teams that maintain terminology in a separate system.

Edit or retranslate any string after it is generated

PTC never locks a translation. You can review, edit, or ask PTC to retranslate any string from the Translations tab at any time, so your team keeps the final say on every word that ships.

PTC handles every common resource format out of the box

PTC handles the formats your stack actually uses. The named formats below link to their dedicated translation pages:

• Web: JSON (i18next, react-intl, vue-i18n, next-intl), YAML (Rails), PO/POT (Django, WordPress).
• iOS: .strings, .stringsdict, .xcstrings (String Catalogs).
• Android: strings.xml, plurals, string arrays.
• Desktop / cross-platform: .properties (Java), .po (gettext).
• Data / catalogs: CSV, XLIFF.

Software localization does not start and stop at the user interface. PTC also translates release notes, email notifications, help documentation, marketing materials, user feedback, and bug reports. All in the same project, so terminology stays consistent across everything your users touch.

See the full format and language support matrix for the complete list.

Ship in 40+ languages, from Arabic to Japanese

PTC translates into 40+ languages, including Arabic, Chinese, French, German, Japanese, Korean, Portuguese, Spanish, and more, so you can reach new markets without adding a new tool for each one. See the full list of supported languages to confirm your targets are covered.

Translate cross-platform release notes, customer emails, and support docs

Cross-platform release notes, customer-facing emails, support documentation, and marketing site copy all live outside your resource files. PTC's Paste to Translate handles that copy in the same project. Paste the source text, choose target languages, get back translations that use the same glossary and brand voice as your in-app strings.

Translate user-generated content, support tickets, and dynamic data with the PTC API

User-generated content, support tickets, and the dynamic data your software handles at runtime need translation as it arrives. The PTC REST API translates this content on demand with Bearer-token authentication, using the same glossary and brand voice as your resource-file translations.

Pricing: 30-day trial, then Pay-As-You-Go

The trial covers 20,000 words into 2 languages with no credit card. When the trial ends, PTC offers Pay-As-You-Go. No subscription. No minimum commitment. The first 500 words every month are free. You only pay for the rest. The pricing page has a cost calculator. Sign up with a company email for an extended business trial.

PTC is ISO 27001 certified for enterprise use

PTC is ISO 27001 certified, which means your data and your users' data are handled to internationally recognized security standards. PTC supports continuous localization for engineering teams of every size, from a 3-developer startup to an enterprise releasing weekly across 12 languages.

Follow a proven path from first string to shipped release

Getting started is straightforward when you have a map. Our software localization guide walks you through everything from preparing your strings for translation to managing updates as your product grows, so you adopt PTC with a clear plan instead of trial and error. Read the software localization guide to set up your first project.

Ready to ship verified multilingual software?

Connect your GitHub or GitLab repo. PTC translates your resource files into 40+ languages and reviews the running app in every one on every release. You ship with confidence.

Start your 30-day trial - 20,000 words on us, no credit card required.

For developers ready to dig in:

• Read the PTC API reference - REST endpoints, webhooks, CI integration.
• See the file format and language support.
• Talk to us about enterprise - custom SLAs, on-prem options, dedicated support.

Last updated: November 11, 2026