Large projects

Translation runs server-side, so scale is mostly the engine's problem, not yours. lingo push submits the work and the engine processes it — you don't configure worker pools or concurrency. What you do control is how much you push at once and how you recover.

Push only what changed#

The default lingo push hashes every source against the lockfile and submits only what changed. On a large repo this is the cheap path — an unchanged corpus is a no-op with no server round-trip. Let the delta do the work; avoid blanket --force.

Scope big changes#

When you do need to retranslate, scope it to a subtree instead of the whole project:

lingo push 'content/en/marketing/**/*.md' --force

This keeps a large run bounded and predictable. See Retranslation.

Estimate before large runs#

Price a big run before committing to it:

lingo push --backfill-missing --estimate

Prints the estimated cost and exits. Useful before a first full translation or a model switch across many locales.

Don't block on the run#

For large runs, you don't have to sit on the command. push records the run in run state, so you can collect results later or from CI:

# kick it off
lingo push --backfill-missing

# later, or in CI
lingo pull

Recover instead of restarting#

If a large run fails partway, don't re-push the whole thing — lingo resume re-emits cached results without re-spending, then --backfill-missing fills any gaps.

Automate it#

For an always-up-to-date large project, let CI translate on merge and open a PR with the results. See CI/CD.