リアルタイム翻訳更新は有用であるべきで、必須であってはならない

翻訳リクエストが queued から working、そして ready へ進む様子を見られることは有用です。チームは更新せずに進捗を確認でき、完了した作業をすぐに開けて、リリースがまだ進行中のうちに失敗したリクエストにも気づけます。

しかし、ライブ更新は表示上の機能です。ワークフローを正しく成立させる仕組みそのものであってはなりません。

永続的な状態が最優先

データベースとジョブシステムが翻訳状態を管理すべきです。各フェーズ遷移は、ブラウザが接続されているかどうかに関係なく記録される必要があります。

• リクエストが queued された
• 翻訳が開始され完了した
• push が開始され完了した
• publish が開始され完了した
• 失敗と再試行のイベント

リアルタイムイベントは、その永続的な変更を通知できます。しかし、それが変更発生の唯一の記録であってはなりません。

この区別は、タブを閉じたユーザー、ネットワークアクセスを失ったユーザー、または websocket 基盤が無効化されている環境で作業するユーザーを守ります。

リアルタイムには運用コストがある

ブロードキャストの導入により、より多くの可動部分が増えます。たとえば websocket サービス、接続認可、チャネル設定、プロキシ対応、そしてブラウザの再接続動作です。

ライブでの連携が必要なチームにとって、そのコストは見合う場合があります。より小規模なデプロイメントでは、通常のポーリングのほうが単純で、しかも十分であることもあります。

リアルタイムをオプトインにしておけば、各環境は中核となる翻訳動作を失うことなく、サポート可能な運用プロファイルを選べます。

優雅なフォールバックを設計する

UI は、リアルタイムイベントでも定期更新でも、同じ最終状態に到達すべきです。

実用的なアプローチは次のとおりです。

1. 現在の永続的な状態を読み込む
2. リアルタイムが有効な場合は関連イベントを購読する
3. リクエスト ID とバージョンで受信更新をマージする
4. アクティブな作業が残っている間は適度な間隔でポーリングする
5. バッチが終端状態に達したら高頻度のポーリングを停止する

リアルタイムは画面の即時性を高めます。ポーリングは再接続後のギャップを埋め、フォールバックも提供します。

この2つの経路が、競合するステータスルールを生み出してはなりません。

更新をノイズに変えない

すべての内部イベントがインターフェースに属するわけではありません。すべてのトークン、ワーカーハートビート、または中間保存をブロードキャストすると、ページが不安定になり、基盤負荷も増える可能性があります。

ユーザーに通常必要なのは、意味のあるフェーズ遷移と更新済みカウントです。急速で低レベルな変化を、より少数の永続的なマイルストーンにまとめることで、落ち着いて見渡しやすい体験を維持できます。

同じ原則は通知にも当てはまります。完了したバッチは注意を引く価値があるかもしれません。しかし、完了したロケールごとに毎回そうとは限りません。

静かな経路をテストする

リアルタイムを有効にした状態でテストし、フォールバックが機能すると想定してしまうのは簡単です。信頼性を得るには、その逆の検証が必要です。

• ブロードキャストを無効にする
• 複数ロケールのバッチを開始する
• ページを離れてから戻る
• 進捗が追いつくことを確認する
• 失敗したリクエストを再試行する
• 最終的なカウントと利用可能なアクションを検証する

この経路が機能するなら、リアルタイムは隠れた依存関係ではなく機能強化です。

要点

ライブ更新は、永続的な状態の上に成り立つときに翻訳オペレーションを改善します。

まずすべての遷移を記録し、ブロードキャストを設定可能にし、節度あるポーリングのフォールバックを維持してください。最も即時性の高い配信チャネルが利用できない場合でも、ワークフローは信頼できるままであるべきです。