How to Automate Your Localization Workflow with Lara CLI

You are managing localization across multiple clients or products. The developer ships a new build. Someone exports the updated string files. They land in your inbox. You open a ticket, assign a linguist, wait for the files back, check the terminology, and send them to engineering for re-import. Three days later, the source has already changed. You start again. This is not a workflow problem you can solve by hiring faster. It is a structural problem: localization sits outside the build process, so it always runs behind it. Lara CLI puts it back inside. Translation runs automatically on every push, with your glossaries and translation memories enforced, and the translated files committed back to the repository without anyone touching them. Here is how it works and what you can configure to maintain quality at scale.

TL;DR What: Lara CLI is a command-line tool that automates localization as part of a build pipeline, replacing manual file exports and handoffs. Who it is for: Localization managers and LSPs who need consistent, repeatable output across projects without manual intervention at every release. How it works: A lara.yaml config file, version-controlled in the repository, defines which files to translate, which languages to target, and which glossaries and translation memories to apply. Running lara-cli translate triggers the job. Quality controls: Project-level instructions set tone and register globally. File-level and key-level instructions override them for specific content. Glossaries enforce terminology. Translation memories reuse previously approved output. CI/CD: GitHub Actions integration automates the full cycle: translate on push, commit results back to the repo automatically. Get started: Lara CLI product page and full documentation.

What Lara CLI is and what it does

Lara CLI is a command-line interface for Lara Translate, distributed as an npm package. It runs from your terminal or from a CI/CD runner and connects directly to the Lara Translate API to translate localization files programmatically. The tool auto-detects file format by extension and supports JSON, PO, TypeScript, Vue i18n single-file components, Markdown/MDX, and Android XML. The entire project configuration lives in a single file: lara.yaml. That file is committed to the repository alongside the source code, which means every configuration change is tracked, every team member works with the same settings, and there is no separate localization dashboard to manage or log into. From a localization manager’s perspective, this is the key shift: your terminology rules, your tone instructions, your file scope, all of it is defined once and applied automatically on every run.

The lara.yaml configuration: what you control

The lara.yaml file has a clear hierarchical structure. Understanding it is where localization managers get their leverage. Settings cascade from project level down to individual keys, and more specific settings always override broader ones. The three sections that matter most for quality control are project.instruction, memories, and glossaries. project.instruction is where you define the global context for every translation job in this project: audience, domain, tone, register, do-not-translate rules. It applies across all files unless overridden. Think of it as the brief you would give a translator at the start of an engagement, written once and applied automatically to every run. memories connects one or more Translation Memory IDs from your Lara account. Approved translations are reused automatically. This is where consistency compounds: the more jobs you run, the more your TM covers, and the less new translation is needed per release. glossaries connects one or more Glossary IDs. Product names, feature labels, brand terms, and domain-specific vocabulary are enforced on every job without manual review. You define the terms once in Lara Translate, reference the glossary ID in lara.yaml, and they apply to every file in every run.

Instruction inheritance: project, file, and key level

This is the feature localization managers and LSPs handling multiple content types will find most useful. The lara.yaml configuration supports three levels of instruction, and each level overrides the one above it. Project-level instructions apply globally. File-level instructions apply to a specific file path and override the project setting for that file. Key-level instructions apply to specific keys within a file and override both. A real configuration using all three looks like this: In this example, the medical app runs with formal tone globally. The onboarding file overrides that with a friendlier tone because the audience and context are different. Button keys within the onboarding file get a character limit constraint on top of that. Error message keys across all files revert to formal regardless of their parent file setting. For LSPs managing multiple clients in one repository or across multiple configurations, this inheritance model means you do not need separate pipelines for different content types. One lara.yaml can express the full complexity of your quality requirements.

Protecting keys that should not be translated

Two settings in the files section give you explicit control over which keys the CLI touches. lockedKeys protects keys from being modified. If a key already has a translation, the CLI will not overwrite it. This is useful for strings that have been manually reviewed and approved, or for keys that contain non-translatable values such as IDs, URLs, or configuration strings. ignoredKeys excludes keys from the translation job entirely. The CLI skips them, leaves the files untouched for those keys, and does not count them against your character usage. Use this for internal keys, development-only strings, or any content that should never go through automated translation.

Running a translation job

Once lara.yaml is in place, the translate command is a single line: The CLI reads lara.yaml, calls the Lara Translate API, and writes translated files according to the configured include patterns. Original file structure is preserved. You can also run ad-hoc translations from the command line for individual files or text strings using flags: The --memory and --glossary flags in the ad-hoc command accept the same IDs you use in lara.yaml, so your terminology assets are available whether you are running automated jobs or one-off translations from the terminal.

Managing translation memories from the CLI

Lara CLI includes a full set of memory management commands. You can list, create, update, and delete translation memories directly from the terminal, and you can import TMX files into an existing memory: For LSPs migrating existing TM assets into Lara Translate, the TMX import command covers the most common handoff format. Once imported, the memory ID can be referenced in any lara.yaml configuration across your client projects.

Automating with GitHub Actions

The GitHub Actions integration closes the loop. Instead of running lara-cli translate manually after each developer push, the workflow runs it automatically and commits the translated files back to the repository. The setup requires three things: your Lara API credentials stored as GitHub Secrets (LARA_ACCESS_KEY_ID and LARA_ACCESS_KEY_SECRET), write permissions enabled for the workflow, and a lara.yaml already present in the repository (generated locally with lara-cli init and pushed). Then you create a workflow file at .github/workflows/translate.yml: Once this is in place, every push to main triggers a translation run. Updated files are committed automatically. No one needs to export, email, re-import, or review file delivery. The localization manager’s role shifts from managing handoffs to managing the configuration: defining instructions, maintaining glossaries, reviewing TM quality, and deciding which keys to lock or ignore. That is where localization expertise actually matters.

How to get started

You need Node.js 16 or higher and pnpm. Install Lara CLI globally: Create a .env file in your project directory with your Lara API credentials: Then run the interactive initialization to generate your lara.yaml: The init command detects your localization directories and guides you through configuration. You can also run it with --non-interactive and pass glossaries and memories directly as flags if you already know your asset IDs. Commit the generated lara.yaml to your repository. From there, run lara-cli translate locally or set up the GitHub Actions workflow to automate every subsequent run. API key setup, full command reference, and configuration details are in the Lara CLI documentation.

---

FAQs

Do I need to be a developer to use Lara CLI?

You need Node.js and pnpm installed, and basic comfort running commands in a terminal. The setup is straightforward: install the package, add credentials to a .env file, and run lara-cli init to generate the configuration. Most of the configuration work, which is defining instructions, connecting glossaries and translation memories, and scoping which files to include, is editorial and linguistic rather than technical. For localization managers working alongside a development team, the typical pattern is for engineering to handle the CI/CD integration and for the localization manager to own the lara.yaml configuration content.

What file formats does Lara CLI support?

Lara CLI supports JSON, PO (gettext), TypeScript, Vue i18n single-file components, Markdown/MDX, and Android XML. The format is detected automatically based on the file extension, so you do not need to specify it manually. You can include multiple formats in a single lara.yaml by adding different format sections under the files key. The full format documentation with format-specific guides is in the Lara CLI docs.

Can I use multiple glossaries and translation memories in one project?

Yes. The glossaries and memories sections of lara.yaml accept lists, so you can reference multiple IDs for each. All connected glossaries are applied during the translation job. For LSPs managing multiple clients with separate terminology assets, this means you can maintain per-client glossaries in Lara Translate and reference the relevant ones in each project’s configuration. You can also pass glossary and memory IDs directly as flags when running ad-hoc translations from the command line, without touching the lara.yaml.

What is the difference between lockedKeys and ignoredKeys?

lockedKeys protects keys that already have a translation from being overwritten. The CLI skips them on subsequent runs, which is useful for strings that have been manually reviewed and approved. ignoredKeys excludes keys from the job entirely, meaning they are never sent to the API and never appear in the output. Use lockedKeys for approved translations you want to preserve. Use ignoredKeys for internal strings, placeholder keys, or anything that should never be translated at all.

Is the CLI free?

The CLI tool itself is free to install and use. Translations processed through it draw from your standard Lara Translate API subscription or pay-as-you-go quota. There are no extra fees for using the CLI. You need a Lara account with API credentials to authenticate. You can generate credentials from the API section of your Lara account dashboard.

---

This article covers

• What Lara CLI is and why it is relevant for localization managers and LSPs specifically, not just developers
• The lara.yaml configuration and the three-level instruction inheritance system (project, file, key) that gives quality control without per-job manual review
• Glossaries, translation memories, lockedKeys, and ignoredKeys as the primary levers for controlling output quality at scale
• Translation memory management commands including TMX import for migrating existing assets
• GitHub Actions integration with the full workflow configuration for automated translate-and-commit on every push
• Getting started steps: install, credentials, init, and first run

Useful articles

• Introduction to Lara CLI: full documentation
• Lara CLI configuration overview
• GitHub Actions integration guide
• How glossaries work in Lara Translate

---