翻訳ステータスは次の問いに答えるべき

翻訳システムは多くの状態を生み出します。ジョブはキューに入り、プロバイダーは応答し、下書きは保存され、Contentful は更新され、エントリーは公開され、リトライは開始されます。

そのすべての動きを見せても、進捗が自動的に明確になるわけではありません。

有用なステータスは、編集者が次に抱く問いに答えるべきです。

1つのリクエストには複数のライフサイクルがある

多言語リクエストは、多くの場合 3 つの主要なフェーズを移動します。

1. 翻訳
2. プッシュ
3. 公開

各フェーズは、待機中、キュー済み、作業中、成功、スキップ、失敗のいずれかになりえます。そうした状態を 1 語に圧縮すると、重要な情報が失われます。

「完了」は、翻訳の下書きがレビュー可能であること、対象ロケールが Contentful に書き込まれたこと、またはエントリーが公開中であることを意味しうるでしょう。これらは実質的に異なる結果です。

インターフェースは、フェーズ名とその状態を組み合わせて示すべきです。

ステータスと操作は一体であるべき

編集者は、次に何ができるかを判断するためにステータスを読みます。

• 準備ができた翻訳はレビューできます。
• 承認済みの翻訳はプッシュできます。
• 成功したプッシュは公開できます。
• 一時的な失敗はリトライできます。
• 進行中の作業はキャンセル可能な場合があります。

利用可能な操作が表示された状態と一致しないと、プロダクトは一貫性を欠いて感じられます。まだプッシュされていないリクエストの横に公開ボタンがあるのは、単に混乱を招くだけではありません。基盤となるワークフローへの信頼を弱めます。

バックエンドは永続的な状態と権限に基づいて可用性を判断し、その後 UI はその判断を一貫して反映すべきです。

進捗数には安定した分母が必要

各フェーズが説明なしに異なる合計数を使うと、バッチ進捗は誤解を招くものになります。

10 件の翻訳リクエストを含むバッチでは、一部のロケールがレビュー専用だったり自動化が無効だったりするため、翻訳は 10 件、プッシュは 8 件、公開は 6 件になることがあります。

進捗は次を区別すべきです。

• 総リクエスト数
• 現在のフェーズの対象となるリクエスト数
• 完了、進行中、失敗、スキップされたリクエスト数

スキップは特に重要です。これは未完了の作業ではなく、終端の判断です。

画面を混雑させずに履歴を保持する

現在の状態は簡潔なままであるべきですが、何か問題が起きたときには運用担当者に履歴も必要です。

展開可能なイベントタイムラインがあれば、リクエストがいつキューに入ったか、どの試行が失敗したか、自動リトライが実行されたか、そして Contentful がいつ更新を受け入れたかを示せます。これにより、すべてのテーブル行をログビューアに変えてしまうことなくデバッグを支援できます。

メインのステータスには人間にわかりやすい言葉を使い、詳細ビューには技術的な識別子とタイムスタンプを保持してください。

終端状態は終端のままであるべき

ポーリングとリアルタイムイベントは順不同で到着することがあります。古い「作業中」イベントによって、完了したリクエストが後戻りしてはいけません。データベースがすでに成功を記録しているのに、ページを再読み込みした際に一時的にキュー済みと表示されるべきでもありません。

状態遷移には順序付けと冪等性が必要です。インターフェースは、ブラウザーに最後に届いたメッセージを単純に受け入れるのではなく、信頼できるタイムスタンプまたはバージョンを使って更新をマージすべきです。

要点

ステータス設計はワークフローの一部であり、その周囲の飾りではありません。

翻訳、プッシュ、公開の各フェーズを分離してください。各状態をそれによって可能になる操作と組み合わせ、スキップされた作業を正直に数え、詳細な履歴をすぐ近くに保ってください。最良のステータスとは、次の意思決定を明確にするものです。