A localization API, CLI, GitHub Action, and MCP server for your CI/CD pipeline

Localization as a step in your pipeline

The developer platform exposes the whole localization loop over /api/v1 — project info, pull, push, translate, batches, translation CRUD, QA, and glossary — so every step is scriptable. A zero-runtime-dependency CLI, a first-party GitHub Action, and an MCP server all sit on top of that same API and the same project tokens.

Bearer authentication uses project access tokens with a tgl_ prefix. A token is shown once at creation and stored only as a SHA-256 hash, scoped to abilities — push, pull, manage — with an optional expiry.

Register a webhook per project across 10 events — batch.completed, batch.failed, key.created, key.updated, key.deleted, translation.updated, translation.reviewed, language.added, glossary.updated, and qa.completed. Every delivery is signed with HMAC-SHA256, high-frequency events are coalesced rather than firing per row, the last 50 deliveries are logged with status and attempt count, and any past delivery can be manually redelivered with its original, frozen payload.

Twenty native file formats round-trip through the API — JSON (flat and nested), Android XML, iOS .strings, .stringsdict and .xcstrings, Flutter ARB, Laravel PHP and JSON, XLIFF 1.2 and 2.0, gettext .po, YAML, Java .properties, .NET .resx, CSV and XLSX spreadsheets, Markdown/MDX documents, the Unity Localization CSV, and the Unreal Engine PO. Handling is format-aware: simple formats skip plural forms and report exactly what was skipped in an X-Skipped-Keys header.

When a fix has to reach users now, publish your reviewed strings to the OTA/CDN endpoint — public, edge-cacheable, versioned, with ETag/304 — and pull them at runtime with the zero-dependency @transglot/runtime SDK (or its Vue, React, Svelte, Next.js, SvelteKit, Angular, and Solid adapters). A production typo becomes a publish, not a redeploy.

If localization is a manual step outside your pipeline, it is the step that gets forgotten. The developer platform exists so it never has to be manual.

What the developer platform gives you

• Pull & push — pull exports your project’s translations in any of the 20 supported formats; push imports a file back in, either merging new keys or syncing removals to match the file exactly.
• Translate & batches — translate triggers an AI translation batch for a locale and a set of keys over the API; batches lets you check status or retry a batch that failed.
• The transglot CLI — a zero-runtime-dependency npm package with init, pull, push, and status. Run it with npx transglot or npm i -g transglot, authenticate with a tgl_ project token, and drive localization from any terminal or CI job.
• First-party GitHub Action — a composite Action (name: transglot) that pushes source files, optionally waits for the AI batch, pulls translations back, and commits them to a branch or uploads them as an artifact. Inputs: token (a tgl_ repo secret), url, and wait.
• An MCP server for AI agents — @transglot/mcp exposes 15 tools mapped 1:1 onto the public REST API, so Claude (or any MCP client) can read translations, trigger batches, run QA, and manage the glossary. Read tools are annotated read-only; every mutating tool states exactly what it changes and what it spends, and the three that burn AI word quota say so up front.
• Scoped project access tokens — bearer authentication via tgl_ tokens, stored as a SHA-256 hash and shown only once on creation. Each token is scoped to abilities (push, pull, manage) with an optional expiry. The CLI, the Action, and the MCP server all authenticate the same way.
• HMAC-signed webhooks, 10 events — register a webhook per project for batch.completed, batch.failed, key.created, key.updated, key.deleted, translation.updated, translation.reviewed, language.added, glossary.updated, and qa.completed. Every delivery is signed with HMAC-SHA256, and high-frequency events are coalesced rather than firing once per row.
• Delivery log & redelivery — the last 50 webhook deliveries are logged with status and attempt count, and any past delivery can be manually redelivered with its original, frozen payload.
• OTA / CDN runtime delivery — publish reviewed strings to a public, edge-cacheable endpoint (versioned immutable URLs plus a cheaply-revalidated “latest”, ETag/304) and read them at runtime with the zero-dependency @transglot/runtime SDK or its Vue, React, Svelte, Next.js, SvelteKit, Angular, and Solid adapters — so a production fix ships without a redeploy. Available on every paid plan.
• 20 native file formats — JSON (flat and nested), Android XML, iOS .strings, .stringsdict and .xcstrings, Flutter ARB, Laravel PHP and JSON, XLIFF 1.2 and 2.0, gettext .po, YAML, Java .properties, .NET .resx, and CSV and XLSX spreadsheets, Markdown/MDX documents, Unity Localization CSV, and Unreal Engine PO. Format-aware: simple formats skip plural forms and flag anything skipped in an X-Skipped-Keys header.

Wire it into your pipeline

• Mint a scoped token — create a tgl_ project access token scoped to the abilities the job needs (push, pull, or manage) with an optional expiry. It is shown once and stored only as a SHA-256 hash.
• Push your source strings — from the CLI, the Action, the MCP server, or a direct API call, push your source file in any of the 20 native formats, merging new keys or syncing removals to match the file exactly.
• Trigger and wait for the batch — call translate to start an AI batch. The CLI and Action can wait for it in-job, or a batch.completed webhook can signal your pipeline when it finishes.
• Pull translations back — pull the finished translations into your repo and commit them to a branch, or let the GitHub Action commit or upload them for you as an artifact.

Localization in CI/CD, before and after

• Moving files — export by hand, email it around, paste the result back, and hope nothing drifted; or pull and push over the REST API, the CLI, the GitHub Action, or the MCP server.
• Triggering translation — remember to kick off translation manually every time source strings change; or let translate fire an AI batch from the API or CLI, with the Action waiting for it inside the job.
• Knowing it finished — poll a dashboard, or just guess; or take an HMAC-signed webhook across 10 events, with coalescing, a delivery log, and redelivery.
• Authentication — share a password or a long-lived key with more access than the job needs; or use scoped tgl_ project tokens, hashed, shown once, limited to push / pull / manage, with optional expiry.
• Format handling — a lossy CSV round-trip flattens plurals and drops platform-specific structure; format-aware codecs cover 20 native formats and flag anything a simple format can’t hold in X-Skipped-Keys.
• Letting an agent help — paste strings into a chat window and copy the answers back by hand; or point an MCP client at @transglot/mcp and let it call the same 15 policy-checked tools your CI does.

The details that make it safe to automate

Automating localization means trusting it in CI. These are the guarantees that make that trust reasonable — grounded in what actually ships.

• Hashed, single-shown tokens — a tgl_ token is shown once at creation and only ever stored as a SHA-256 hash, so a leaked database never leaks a usable key.
• Ability scoping — each token is limited to push, pull, or manage abilities, so a CI job only ever gets the access it actually needs.
• Frozen redelivery — any of the last 50 webhook deliveries can be manually redelivered with its original, frozen payload, so a missed event is recoverable.
• Format-aware skips — simple formats that cannot represent plurals skip them cleanly and report exactly what was skipped in an X-Skipped-Keys response header.
• Spend-annotated agent tools — the MCP server’s 15 tools carry the same ability scoping as the REST API, and the three that burn AI word quota (translate_missing, retry_failed_batch, run_qa) declare it in their description, so an agent knows the cost before it calls.