翻訳はサーバー側で実行されるため、スケール対応の大半はあなたではなくエンジンが引き受けます。lingo push がジョブを送信し、エンジンが処理するので、ワーカープールや並行処理を設定する必要はありません。あなたがコントロールするのは、一度にどこまでプッシュするか と どう復旧するか です。
変更分だけをプッシュする#
デフォルトでは、lingo push が各ソースを lockfile と照らし合わせてハッシュを取り、変更があったものだけを送信します。大規模なリポジトリでは、これがもっとも低コストなルートです。変更のないコーパスはサーバーとの往復も発生しない no-op になります。差分に任せて、全面的な --force は避けましょう。
大きな変更は範囲を絞る#
再翻訳が必要な場合でも、プロジェクト全体ではなくサブツリー単位に絞って実行しましょう。
lingo push 'content/en/marketing/**/*.md' --forceこうすることで、大規模な実行でも範囲を限定でき、見通しよく進められます。詳しくは 再翻訳 を参照してください。
大規模な実行前に見積もる#
大きな実行は、始める前にコストを見積もっておきましょう。
lingo push --backfill-missing --estimate見積もりコストを表示して終了します。初回のフル翻訳や、多数のロケールにまたがるモデル切り替えの前に便利です。
実行に張り付く必要はない#
大規模な実行では、コマンドの完了をその場で待ち続ける必要はありません。push は実行内容を run state に記録するため、結果はあとから、あるいは CI からでも取得できます。
# kick it off
lingo push --backfill-missing
# later, or in CI
lingo pull最初からやり直さずに復旧する#
大規模な実行が途中で失敗しても、全体を再プッシュする必要はありません。lingo resume は追加コストをかけずにキャッシュ済みの結果を再出力し、そのうえで --backfill-missing が不足分を埋めます。
自動化する#
常に最新の状態を保ちたい大規模プロジェクトでは、CI でマージ時に翻訳を実行し、結果を PR として開く運用がおすすめです。詳しくは CI/CD を参照してください。
旧CLIを使っていた方へ
旧CLIではローカルマシン上で翻訳していたため、クライアント側の並行処理設定（ワーカープールや parallel フラグ）を公開していました。現在の CLI はサーバー側で翻訳するため、そうした調整項目はなくなっています。スケール対応は自動で処理されます。いま重視すべきなのは、スコープ、バックフィル、resume です。
