Automate Localization in CI/CD: A Developer’s Guide to Lara CLI

Most engineering teams automate builds, tests, and deployments without thinking twice. Then localization hits: strings get exported manually, sent to translators over email, reviewed in a spreadsheet, and re-imported days later. By the time translated files are back, the source has changed again.

This is not a people problem. It is a pipeline problem. And it has a straightforward fix: bring translation into the same automated workflow you already use for everything else.

Lara CLI is the command-line interface for Lara Translate. It connects directly to the Lara Translate API from your terminal or CI runner, so you can trigger translation jobs programmatically, version your localization config alongside your code, and ship to international markets without breaking your release cadence.

Why manual localization breaks CI/CD

The manual localization cycle typically looks like this: a developer finishes a feature, exports the updated string files, emails or uploads them to a localization team, waits for translated files to come back, and then re-imports and re-deploys. In a team shipping multiple times per week, this cycle introduces 2–5 days of delay per release. (Translation jobs across target languages can run in parallel, but the pipeline still blocks until the cycle completes.)

The compounding effects are worse than the initial delay. Terminology drifts when different translators handle different batches. Strings get duplicated because there is no shared translation memory. And when you add a third or fourth target language, the overhead does not scale linearly. It multiplies.

Automating localization in your CI/CD pipeline eliminates all of this. Translation runs on every push, reuses previously approved translations automatically, and enforces terminology through glossaries, with zero manual intervention.

What is Lara CLI and what does it do?

Lara CLI is a command-line interface that exposes Lara Translate‘s translation capabilities as terminal commands. You can use it locally during development or as a step in any CI/CD runner.

The core capabilities relevant to pipeline integration are:

• Translate localization files from the command line and in CI/CD
• Use --context and --instructions to guide output (tone, register, do-not-translate rules, UI constraints)
• Attach a glossary to enforce consistent terminology across every job
• Use translation memories to reuse previously approved output automatically
• Support multiple i18n file formats and auto-detect the parser by file extension

Everything is driven by a single configuration file (lara.yaml) that lives in your repository. No dashboards to log into, no files to upload by hand.

Install Lara CLI in under a minute

Lara CLI is distributed as an npm package. You can use npm, pnpm, or yarn — whichever your project already uses. For a global install (recommended for most use cases):

# npm
npm install -g @translated/lara-cli

# pnpm
pnpm install -g @translated/lara-cli

# yarn
yarn global add @translated/lara-cli

For a project-local install:

# npm
npm install --save-dev @translated/lara-cli
npx lara --version

# pnpm
pnpm install --save-dev @translated/lara-cli
npx lara --version

The full setup guide is available in the Lara CLI Setup and Installation docs.

Configuration as code: the lara.yaml file

Lara CLI is driven by a lara.yaml file that lives in the root of your repository. This is where you define language settings, file paths, translation memory, glossary, and project-wide instructions. Your entire localization setup is version-controlled alongside your code.

A complete example configuration looks like this:

# Schema version for backward compatibility
version: "1.0.0"

# Project-wide translation guidance
project:
  instruction: "B2B SaaS product. Technical UI strings for a developer audience. Keep placeholders and product names unchanged."

# Language configuration
locales:
  source: en
  target:
    - de
    - fr
    - es
    - ja

# Translation memory configuration
memories:
  - mem_your_tm_id

# Glossary configuration
glossaries:
  - gls_your_glossary_id

# File path and processing rules (format auto-detected by section)
files:
  json:
    include:
      - "src/locales/[locale].json"
  po:
    include:
      - "src/locales/[locale].po"

A few things worth noting about this config:

• project.instruction — your highest-leverage control. Use it to define audience, tone, UI constraints, and non-translatable terms. It applies across all files by default.
• memories — reuses previously approved translations automatically, reducing both cost and turnaround time. See translation memory docs.
• glossaries — connects pre-built term pairs so product names, feature labels, and brand terms stay consistent across every job. Learn how glossaries work in Lara Translate.
• files — you can include multiple formats in one project. Lara CLI selects the right parser based on file extension and the format section you configure.

Because this file is committed to git, every team member works with the same settings, configuration changes are trackable in pull requests, and onboarding a new project is a matter of cloning a repo.

How to set credentials safely (local and CI)

Locally, Lara CLI can read credentials from a .env file in your project directory:

LARA_ACCESS_KEY_ID=<YOUR_ACCESS_KEY_ID>
LARA_ACCESS_KEY_SECRET=<YOUR_ACCESS_KEY_SECRET>

In CI, you should pass these as secrets or protected variables, never hardcode them in lara.yaml or commit them to git.

See: Lara CLI Setup and Installation and API key setup.

How to run a translation job

Once your lara.yaml is in place, running a project translation job is a single command:

lara-cli translate

Lara CLI reads lara.yaml, calls the Lara Translate API, and writes translated files according to your configured include patterns. The original structure is preserved. No manual file handling required.

If you want an ad-hoc translation from the command line (text or a single file) you can also use the translate command with flags:

lara translate --text "Hello, world!" --source en-US --target fr-FR

See all available commands in the Lara CLI commands reference.

How to integrate Lara CLI into GitHub Actions

The real payoff of Lara CLI comes from pipeline integration. Here is a complete GitHub Actions workflow that runs translation automatically every time changes to source locale files are pushed:

name: Localization

on:
  push:
    paths:
      - 'src/locales/en.json'
      - 'src/locales/en.po'

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Lara CLI
        run: npm install -g @translated/lara-cli

      - name: Run translation
        run: lara-cli translate
        env:
          LARA_ACCESS_KEY_ID: ${{ secrets.LARA_ACCESS_KEY_ID }}
          LARA_ACCESS_KEY_SECRET: ${{ secrets.LARA_ACCESS_KEY_SECRET }}

      - name: Commit translated files
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add src/locales/
          git commit -m "chore: auto-translate strings [skip ci]" || echo "No changes"
          git push

A few notes on this workflow:

• The paths filter ensures the translation job only runs when source strings actually change, not on every push.
• Store credentials as GitHub Actions secrets (for example LARA_ACCESS_KEY_ID and LARA_ACCESS_KEY_SECRET) under Settings > Secrets and variables > Actions.
• The commit step uses || echo "No changes" so the workflow does not fail when translation memory already covers all strings and there is nothing new to commit.
• The [skip ci] tag prevents the auto-commit from triggering another workflow run.
• Alternative: open a pull request instead of committing directly. Some teams prefer translated files to land in a separate PR so they can review and approve what gets merged before it hits the main branch. To do this, replace the commit step with a gh pr create call (using the GitHub CLI) or use a community action like peter-evans/create-pull-request. The translation command stays identical — only the delivery step changes.

For GitLab CI, the same logic applies: install the CLI, authenticate via environment variables, and call lara-cli translate in a job that runs on changes to your locale files.

GitLab CI equivalent

translate:
  stage: localize
  image: node:20
  only:
    changes:
      - src/locales/en.json
      - src/locales/en.po
  script:
    - npm install -g @translated/lara-cli
    - lara-cli translate
  variables:
    LARA_ACCESS_KEY_ID: $LARA_ACCESS_KEY_ID
    LARA_ACCESS_KEY_SECRET: $LARA_ACCESS_KEY_SECRET
  artifacts:
    paths:
      - src/locales/

The example above uses npm. You can substitute pnpm (pnpm install -g @translated/lara-cli) or yarn (yarn global add @translated/lara-cli) if that is what your project uses.

Supported file formats for localization pipelines

Lara CLI supports multiple internationalization file formats and automatically selects the right parser based on file extension. The table below covers the formats explicitly documented for Lara CLI:

For the authoritative CLI list and how format detection works, see Introduction to Lara CLI.

How translation memory and glossaries reduce manual work

Two features make automated localization reliable at scale, not just fast.

Translation memory stores every approved translation segment. When Lara CLI processes a project, it can reuse previously approved translations automatically. If you have ever been charged to translate the same error message or UI label across multiple releases, translation memory eliminates that completely. You pay to translate a string once, and every future job reuses the approved result. It also guarantees that approved phrasing is never changed without human intent. See how translation memories work in the API.

Glossaries enforce mandatory term pairs across every translation job. Without one, the same technical term can end up translated three different ways across three different releases, and that inconsistency is exactly the kind of thing customers notice. You define each term once in the glossary, attach it to your project configuration, and every job respects it regardless of how many languages you ship. Learn how to set up and manage glossaries.

Together, these two features mean that as your pipeline matures, the proportion of strings that require human review steadily shrinks. The model handles new strings. The memory handles everything already approved.

Security and data privacy in automated pipelines

Automated translation pipelines often handle source content that is not yet public: unreleased feature names, internal tooling strings, draft documentation, proprietary copy. One of the most common concerns when adopting AI translation is whether that content ends up in a public training dataset. Lara Translate is built to prevent exactly that.

• All processing and storage happen within the EU. Lara Translate is fully GDPR-compliant.
• Incognito Mode disables learning from your content, so nothing processed in your pipeline is used to improve the model.
• Credentials should always be passed as secrets or protected variables, never hardcoded in config files committed to version control.
• For enterprise teams, data processing locations and subprocessors are fully documented.

Why automated localization matters for engineering teams

Localization is the last manual bottleneck in otherwise automated release pipelines, and every day it stays manual is a day international users wait longer for updates. Lara CLI turns translation into a repeatable, version-controlled pipeline step that runs on every push, the same way linting or testing does. For teams shipping to multiple markets, this is not a convenience feature. It is a prerequisite for sustainable release velocity.

The secondary benefit is quality consistency. Human-in-the-loop translation is still valuable for high-stakes content, but for UI strings, error messages, and documentation, automated translation backed by glossaries and translation memory can outperform ad-hoc manual workflows. You get fewer terminology errors, not more. Human review on top of AI translation is available when you need that extra layer.

Ready to remove the localization bottleneck from your pipeline? Install Lara CLI, add your lara.yaml to your repo, and your next push ships with translations already done. The quickstart guide walks you through installation and your first job.

FAQ

Does Lara CLI work with any CI/CD platform?
Yes. Lara CLI runs in any environment with Node.js installed. It works with GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines, Jenkins, and any other runner. The examples in this article use GitHub Actions and GitLab CI, but the commands are the same regardless of platform.

Which file formats does Lara CLI support?
Lara CLI supports multiple internationalization formats and auto-detects the parser by file extension. The Lara CLI docs explicitly list JSON, PO, TS, Vue i18n single-file components, Markdown/MDX, and Android XML. See Introduction to Lara CLI for the current list and format behavior.

How do I keep my credentials secure in a CI pipeline?
Pass your credentials as environment secrets, never hardcode them in lara.yaml. In GitHub Actions, store LARA_ACCESS_KEY_ID and LARA_ACCESS_KEY_SECRET under Settings > Secrets and variables > Actions. In GitLab CI, use protected CI/CD variables.

Will my source content be used to train the model?
Not if you enable Incognito Mode. With Incognito Mode active, Lara Translate does not learn from your content. This is the recommended setting for pipelines that process unreleased or proprietary strings.

Can I still request human review for high-stakes content?
Yes. Lara Translate supports human review on top of AI translation. You can automate the first pass and route specific files or languages to a human reviewer when the content requires it.

Does the CLI support multiple target languages in one job?
Yes. Define multiple target locales in lara.yaml under locales.target and they can be processed in a single CLI run. This is part of Lara Translate’s multilingual translation support.

How do I control tone and translation behavior from the CLI?
Use project-level instructions in lara.yaml (project.instruction) and, when needed, add file- and key-level instructions. For ad-hoc translations, use the --context and --instructions flags. See Configuration overview and Commands.

This article is about

How to automate localization in a CI/CD pipeline using Lara CLI, the command-line interface for Lara Translate. It covers installation, the lara.yaml configuration file, credentials and CI secrets, a complete GitHub Actions workflow, a GitLab CI equivalent, CLI-supported file formats, translation memory and glossary integration, data security settings, and answers to common developer questions about CI/CD i18n automation.

Related resources from Lara Translate:

• Lara CLI: Introduction and quickstart
• Lara CLI: Setup and installation
• Configuration overview
• CLI commands reference
• How glossaries work in Lara Translate
• Translation memories in the API
• Learning vs. Incognito Mode
• API key setup
• Human review on top of AI translation
• GDPR compliance