ソース変更検出で翻訳レビューの信頼性を保つ

翻訳は正しくても、最新ではないことがあります。

これは、翻訳開始後に編集者がソースエントリを変更したときに起こります。ローカライズされた下書きは依然として元のスナップショットを反映していますが、レビュー画面には最新のソースが表示される場合があります。ワークフローがその差分を示さなければ、レビュアーは実際には比較されていない2つのコンテンツを承認してしまう可能性があります。

ソース変更検出は、その静かな不一致がリリースに紛れ込むのを防ぎます。

翻訳はスナップショットから始まる

すべての翻訳リクエストにはソース境界があります。つまり、ある時点におけるフィールド、値、リッチテキスト構造の集合です。

そのスナップショットはリクエストとともに保存されるべきです。これにより、モデルが何を受け取ったのか、レビュアーが何を評価しているのか、そしてターゲット下書きがその内容になっている理由が説明できます。

表示用にソースを再取得することは有用ですが、それによって過去のスナップショットを置き換えてはいけません。ワークフローには両方が必要です。

• 下書きの生成に使われたソース
• CMS内の現在のソース

前者がなければ、下書きには信頼できる来歴がありません。後者がなければ、チームはページがすでに先へ進んでいることを把握できません。

すべての変更がすべてを無効にするわけではない

タイムスタンプだけでもエントリが変更されたことは分かりますが、翻訳が古くなったかどうかまでは分かりません。

編集者は内部メモを更新したり、ローカライズ対象外のフィールドにアセットを追加したり、リクエストに含まれていないフィールドを修正したりするかもしれません。そうした変更が、ローカライズされた下書きを必ずしもブロックする必要はありません。

代わりに、翻訳対象フィールド単位で比較します。ソースタイトルが変わったなら、タイトル下書きを古いものとしてマークします。本文だけが変わったなら、レビュー済みのタイトルはそのまま維持し、本文だけを再確認対象に戻します。

限定的な無効化により、完了した作業を保持しつつ、残っているリスクを明示できます。

レビュアーに実際の差分を見せる

「ソースが変更されました」は警告であって、判断ではありません。

レビュアーは、元のスナップショットと現在の値の間で何が変わったのかを確認する必要があります。プレーンテキストでは単語レベルの差分で十分な場合があります。リッチテキストでは、削除されたリンク、新しいリスト項目、異なる埋め込みエントリといった構造上の変化も比較結果として示すべきです。

重要なのは、単に文字列が異なるかどうかではありません。承認済みのターゲットが、現在のソースを依然として正確に表しているかどうかです。

チームに意図的な選択肢を与える

翻訳対象のソースフィールドが変更されたとき、ワークフローは少数の明確な選択肢を提示できます。

1. 変更が意味に影響しない場合は現在の翻訳を維持する
2. ローカライズされた下書きを手動で編集する
3. 影響を受けたフィールドだけを再生成する
4. 変更範囲が広い場合はリクエストを翻訳に戻す

その選択とレビュアーは記録されるべきです。監査証跡なしに解除できる古い状態の警告は、リリースのプレッシャーの下で簡単に無視されてしまいます。

プッシュ前に再確認する

レビューはソース内容が一致した状態で始まっても、その後に別の編集が入った状態で終わることがあります。

CMSへプッシュする直前に、ソース比較をもう一度実行してください。この最後のチェックにより、承認と反映の間のギャップを閉じられます。レビュー画面と同じフィールド単位のルールを使い、影響を受けた書き込みだけを止めるべきです。

自動公開では、このチェックはさらに重要です。自動化によって人間が立ち止まる余地がなくなるため、システムはどの承認済みスナップショットなら公開してよいのかを正確に判断しなければなりません。

要点

翻訳レビューが信頼できるのは、レビュー対象のソースが下書きを生み出したソースそのものである場合に限られます。

元のスナップショットを保存し、それを現在のCMSの値と比較し、フィールド単位で変更を特定し、意味のある差分をレビュアーが意図的に解決できるようにしてください。ソース変更検出はローカライゼーションを遅らせるものではありません。今日のコンテンツに対して昨日の答えを、チームが自信満々に公開してしまうのを防ぐのです。