分割翻訳パイプライン

v1.5.0 で導入された、翻訳実行を段階的に行うパイプラインです。

3 段階の実行フロー

ブラウザ側の JavaScript がこれら 3 段階を順番に HTTP リクエストとして送ります。

1 段階目: prepare

ai_translator_prepare エンドポイントを呼び出します。

• 翻訳元コンテンツから翻訳プラン（翻訳すべきフィールドのリスト）を生成
• 翻訳先のドラフトコンテンツを下書き状態（HOLD）で作成
• 翻訳プランとドラフト ID をフロントに返却
• 新規ドラフトの場合は rollback トークンを発行（失敗時の自動破棄用）

2 段階目: translate_field

ai_translator_translate_field エンドポイントをプラン内のフィールド数だけ呼び出します。

• 1 リクエストで 1 つのフィールドを翻訳
• 翻訳結果を翻訳先ドラフトに書き込み
• フロントエンドは「翻訳中 X/Y: フィールド名」と進捗を表示

1 リクエストあたりの所要時間が短くなるため、インフラ側のタイムアウト（Apache ProxyTimeout / Nginx proxy_read_timeout 等）に引っかかりにくくなります。

3 段階目: finalize

ai_translator_finalize エンドポイントを呼び出します。

• Placement （カテゴリ関連付け）の作成 / 更新
• convert_breaks （リッチテキスト形式）の同期
• リダイレクト先 URL を返却
• rollback トークンを破棄（もう失敗による rollback は不要）

完了後、フロントが翻訳先コンテンツの編集画面へリダイレクトします。

進捗表示

翻訳ウィジェットに次の形式で進捗が表示されます。

翻訳中 2/5: 本文

全言語一括翻訳では 2 段階の進捗が表示されます。

言語 1/4 (日本語→英語（同じサイト）): 翻訳中 2/5: 本文

中断時の挙動

翻訳実行中にブラウザを閉じる / ネットワークが切れる / フィールド翻訳が失敗するといったケースでは、それまでに翻訳されたフィールドを含む「下書き状態」の翻訳先コンテンツが残ります。

公開状態は常に HOLD で作成されるため、半翻訳の状態でサイトに表示されることはありません。

再開

途中で止まった翻訳を再開したい場合、同じ翻訳ボタンをもう一度押すだけです。

• 既存の下書きを「上書き対象」として検出
• 上書き確認モーダルが表示される
• OK を押すと残りのフィールドも含めて翻訳が再実行される

自動 rollback

新規翻訳の途中で すべてのフィールドが失敗または skip された 場合、AITranslator はフロントエンドから rollback リクエストを送って 新規ドラフトを自動破棄 します。

• 新規ドラフトのみが対象(既存翻訳の上書き時は対象外)
• 自動破棄により「全フィールド失敗なのに半翻訳のドラフトだけ残る」状況を回避
• rollback トークン(MT::Session, 1 時間有効, 単回使用)で安全性を担保

上書きモードでは既に存在する翻訳先の値が変更されてしまうため、自動 rollback は行いません。

旧エンドポイントとの互換性

分割翻訳パイプラインは新しいエンドポイント群で実装されています。

旧エンドポイント ai_translator_translate と ai_translator_translate_json も後方互換のため維持されています。外部スクリプトから旧エンドポイントを呼んでいた場合も影響はありません。

ただし、翻訳ウィジェットは新しいパイプラインを使うように切り替わっています。

アクセスログへの影響

リクエスト数が増えるため、Web サーバーのアクセスログのサイズがやや増えます。1 回の翻訳実行で 1 + N + 1 (= prepare + translate_field × N + finalize) のリクエストが発生します。

通常運用では問題ありませんが、ログを集計してコスト計算しているような場合は、計算式の調整が必要かもしれません。

旧エンドポイントを使い続けるには

外部スクリプトから AITranslator を呼ぶ場合、旧エンドポイントを直接叩く形でも引き続き利用できます。旧エンドポイントは 1 リクエストで全フィールド翻訳を完了させる従来の方式で動作します。

ただし、長文や多言語の場合はタイムアウトに引っかかる可能性が残るので、可能なら新しいエンドポイント群への移行を推奨します。