Contentful のバージョン競合は安全に再試行すべき

Contentful は楽観的ロックでエントリを保護します。すべての更新には、クライアントが自分が編集していると考えるバージョンが含まれます。別の変更が先に反映された場合、Contentful は古い更新を拒否し、新しい作業を上書きさせません。

その競合は安全機能です。ローカリゼーションにとって行き止まりになってはいけません。

健全なチームで競合が起きる理由

翻訳リクエストには時間がかかることがあります。生成またはレビューのあいだに、編集者がソースエントリを修正したり、別のロケールが更新されたり、自動化がメタデータを変更したりすることがあります。

ローカライズされた値を反映する準備が整うころには、以前に取得したエントリのバージョンは古くなっています。

これは誰かがミスをしたという意味ではありません。公開システムの複数の部分が同時に動いているということです。

同じ古いペイロードを盲目的に再試行しない

最も単純な再試行は、拒否されたリクエストをそのまま繰り返すことです。これは同じ古いバージョンを含んでいるため成功しません。

危険な代替手段は、最新のバージョン番号を取得して、古いエントリのペイロード全体を再送することです。これではバージョンチェックは通るかもしれませんが、翻訳開始後に変更されたフィールドを上書きしてしまう可能性があります。

安全な再試行には、新しい状態と限定的なパッチが必要です。

再読込、マージ、更新

Contentful がバージョン競合を報告したとき、ワークフローは次のようにすべきです。

1. 同じ space と environment から現在のエントリを取得する
2. 最新のフィールドとバージョンを確認する
3. 翻訳リクエストで承認された target-locale の値だけをマージする
4. 関係のないフィールドとロケール値を保持する
5. 新しいバージョンで更新を送信する

これにより、再試行はユーザーの実際の意図に沿ったものになります。翻訳リクエストが変更したかったのは特定のローカライズ済みフィールドであり、エントリ全体の古いスナップショットを復元することではありません。

再試行しないべきタイミングを判断する

自動的な競合回復には制限が必要です。

レビュー開始後にまさにその target-locale のフィールドが変更されていた場合、システムは実際の編集上の衝突を検出したことになります。自動再試行は新しい人手の作業を置き換えてしまう可能性があります。その場合は停止してレビューを求めるべきです。

同様に、競合が繰り返される場合は、忙しい自動化ループや、エントリに継続的に書き込みを行う連携の存在を示している可能性があります。再試行回数に上限を設けることで、ローカリゼーションがそのループに無期限に巻き込まれるのを防げます。

エラーは対応可能なままであるべきです。どのエントリか、影響を受けたロケールとフィールドは何か、そしてどの段階で衝突が起きたのかを特定できるようにします。

ソースとターゲットの責任範囲を明確に保つ

ワークフローに厳格な書き込み境界があると、競合処理は容易になります。翻訳の反映は、承認された target locales だけを変更すべきです。ソースフィールド、コンテンツタイプのメタデータ、タグ、または無関係なロケール値を書き込むべきではありません。

この境界により、マージの複雑さが減り、監査ログの意味も明確になります。再試行が成功したとき、チームはどのローカライズ済みフィールドが、なぜ変更されたのかを正確に確認できます。

要点

バージョン競合は、共同作業型 CMS では正常なことです。あらゆる競合を翻訳失敗として扱うとワークフローは脆弱に感じられますし、競合を無視すると危険になります。

最新のエントリを取得し、承認された最小限の変更をマージし、明確な制限の範囲内で再試行してください。同じフィールドが両側で変更されていた場合は、人によるレビューのために停止します。信頼性は、同時進行の作業を尊重することから生まれるのであって、それが起きていないふりをすることから生まれるのではありません。