Der Befehl run verarbeitet Übersetzungsaufgaben parallel, indem er sie auf einen Worker-Pool verteilt. Jede Sprache-/Datei-Kombination wird als eigenständige Aufgabe behandelt, und die Worker bearbeiten sie gleichzeitig.
Verwendung#
# Default concurrency (10 workers)
npx lingo.dev@latest run
# Custom concurrency
npx lingo.dev@latest run --concurrency 20So funktioniert's#
- Aufgabenerstellung – die CLI analysiert deine
i18n.jsonund erstellt für jede Sprache-/Datei-Kombination eine eigene Aufgabe - Worker-Verteilung – Aufgaben werden per Lastverteilung auf verfügbare Worker verteilt
- Parallele Verarbeitung – Worker übersetzen gleichzeitig, während Dateisystem-Sperren Schreibkonflikte verhindern
- Ergebnisaggregation – abgeschlossene Übersetzungen werden sicher in die Zieldateien geschrieben
Optionen zur Zielauswahl#
Alle Optionen zur Zielauswahl des Befehls run funktionieren auch mit paralleler Verarbeitung:
| Option | Beschreibung |
|---|---|
--target-locale es | Bestimmte Zielsprachen verarbeiten |
--source-locale en | Quell-Sprache überschreiben |
--bucket json | Bestimmte Bucket-Typen verarbeiten |
--file components/header | Bestimmte Dateien verarbeiten (unterstützt Glob-Muster) |
--key welcome.title | Bestimmte Schlüssel verarbeiten (unterstützt Glob-Muster) |
--force | Lockfile umgehen und alles neu übersetzen |
--frozen | Fehlschlagen, wenn Inhalte eine Übersetzung erfordern |
--concurrency 20 | Anzahl paralleler Worker festlegen |
Automatisches Caching#
Bei der Verwendung der Lingo.dev API werden große Sprachdateien in Chunks aufgeteilt. Die Zieldateien werden schrittweise befüllt, sobald jeder Chunk von der API zurückkommt. Wird der Prozess unterbrochen, setzt der nächste Durchlauf genau dort fort, wo er aufgehört hat.
Für eine Neuübersetzung verwende zuerst purge, dann run ohne --force. So nutzt du den integrierten Caching-Mechanismus für eine effizientere Verarbeitung als mit run --force.
Sicherheit#
Der Worker-Pool schützt vor Dateibeschädigungen durch:
- I/O-Synchronisierung – Dateisystem-Operationen werden pro Datei serialisiert
- Lockfile-Schutz – atomare Operationen verhindern, dass
i18n.lockbei gleichzeitigen Zugriffen beschädigt wird - Transaktionale Verarbeitung – jede Aufgabe wird entweder vollständig abgeschlossen oder schlägt sauber fehl
