# The stringlane CLI

> Check, plan, translate, add keys and locales, and write back through the same checks the desktop app runs, from your terminal, in CI, and inside a coding agent. Free, local, and it writes nothing you did not ask for.

Source: https://stringlane.app/docs/stringlane-cli
Last updated: 2026-09-14

The desktop app tells you what is wrong with your translations while you are looking at them. The CLI tells your **build**.

It is the same engine underneath: the same parsers, the same validation rules, the same completion figures — one implementation, called from both surfaces rather than two copies that drift apart.

```sh
stringlane check .
```

## What you get

Point it at a project folder and it reports which locales are behind, which keys are missing, which translations are structurally broken, and sets an exit code your pipeline can branch on.

```
xcstrings · single-origin · base en
4 locales · 10 keys · 64% complete

  de      9/11       2 missing
  en      11/11      complete
  fr      9/12       3 missing
  uk      1/13       12 missing

8 errors · 3 warnings · 0 info
```

Beyond that report, the CLI is also how a coding agent gets safe access to your localization files. `stringlane mcp` serves the project over the Model Context Protocol, so your agent can find exactly what needs translating and write it back through the same validation gate, instead of hand-editing files whose escaping it will get subtly wrong.

## The commands

| Command | What it does | Writes? |
|---|---|---|
| `stringlane init` | Detects the project and writes `stringlane.yaml` | Yes, asks first |
| `stringlane inspect` | Every locale, how complete it is, and which files were read | No |
| `stringlane check` | The same report plus validation, and an exit code | No |
| `stringlane plan` | The exact list of what needs translating, for an agent to work from | No |
| `stringlane validate` | Checks an agent's translations without touching a file | No |
| `stringlane apply` | Writes them, all or nothing, and only if nothing moved | Yes, asks first |
| `stringlane update` | Translates the missing strings itself using your own provider key | Yes, asks first |
| `stringlane describe` | Writes key descriptions, so translations are made with context | Yes, asks first |
| `stringlane add-locale` | Creates the file for a locale the project does not have yet | Yes, asks first |
| `stringlane add-key` | Adds a key and its source string to the base locale, so every other locale reports it missing | Yes, asks first |
| `stringlane context` | Shows or sets product, branding, locale and terminology context | Yes, asks first |
| `stringlane mcp` | Serves the project to a coding agent over MCP (stdio) | Through its tools |
| `stringlane baseline write` | Records today's issues, so an unclean project can adopt the gate | Yes, asks first |
| `stringlane setup mcp` | Shows, or writes, your agent's MCP configuration | Only with `--apply` |
| `stringlane setup hooks` | Shows, or writes, the write guard in your agent's settings | Only with `--apply` |
| `stringlane telemetry` | Reports or changes whether anonymous usage data is sent | Local state only |

Full flags and behaviour per command are in the [CLI reference](/docs/reference/cli).

## What it will not do

The four read-only commands are read-only with respect to your repository. `inspect`, `check`, `plan` and `validate` write nothing inside your project: not a lock file, not a re-saved locale file, not a byte. The test suite snapshots every file's contents, size and modification time before and after, on Linux, macOS and Windows. What `check` and `scan` keep between runs is a cache of which source files they have already scanned, and it lives in StringLane's own state directory, never in your repository.

The commands that do write ask before they do, and refuse outright when there is no terminal to ask at unless you passed `--yes`. A CI job cannot accidentally commit a decision nobody made.

Nothing follows a symbolic link out of your project root: not the config, not the baseline, not `--output`, and not a path named inside a plan file. A repository that ships a redirect does not get to choose where an agent's translations land.

## Where to go next

- [Getting started](/docs/cli/getting-started) walks from install to your first report.
- [Inspect and check](/docs/cli/inspect-and-check) covers the day-to-day reporting commands and the baseline.
- [Run it in CI](/docs/cli/ci) covers exit codes and the JSON report.
- [The agent workflow](/docs/cli/agent-workflow) covers MCP, [agent setup](/docs/cli/agent-setup) is the one-paste route, and [agent hosts](/docs/cli/agent-hosts) says what each of the eight actually gets.
- [Translate with your own key](/docs/cli/translate-with-your-key) covers `stringlane update`.

## Frequently asked questions

### Is the stringlane CLI free?

Yes. There is no licence key and no activation, and it does not read one: use it on as many machines, projects and CI runners as you like, including at work. It is versioned and licensed separately from the desktop app, and buying the app grants nothing on the CLI in either direction.

### Does the CLI need the desktop app installed?

No. It is a standalone package with no dependency on the app, and the two never talk to each other. They agree because they run the same engine over the same files and the same stringlane.yaml, not because one is driving the other.

### Which file formats does the CLI support?

The same five as the app: iOS .strings with its companion .stringsdict, Xcode .xcstrings String Catalogs, Flutter ARB, Android XML, and i18next JSON.