Contentful翻訳信頼性チェックリスト

翻訳は言語的に優れていても、リリースに失敗することがあります。

誤ったソーススナップショットが使われた可能性があります。リッチテキスト構造が変更されているかもしれません。レビュー済みの値がContentfulに到達していない場合もあります。更新は存在していても未公開かもしれません。信頼性は、1つのモデル応答を最適化することではなく、経路全体を保護することから生まれます。

翻訳前

明確なソース境界から始めます。

• 正確なContentfulエントリと環境を特定する
• ソースロケールとターゲットロケールを記録する
• 翻訳対象となるフィールドのみを読み込む
• リンク、埋め込み、マーク、および翻訳不要の構造を保持する
• モデル、プロンプト、用語ルールを記録する
• 空のソースフィールドを含めるかどうかを表示する

生成前の時点でリクエスト範囲が曖昧であれば、その後のすべての段階はその曖昧さを引き継ぎます。

生成中

プロバイダー呼び出しは、レビューを支えられる程度に可観測で再現可能であるべきです。

応答に、期待されるすべてのフィールドと保護対象のプレースホルダーが含まれていることを検証します。もっともらしく見える部分だけを保存しようとするのではなく、不正な構造化出力は拒否してください。

再試行では同じリクエスト範囲を再利用する必要があります。別のモデルやプロンプトが選択された場合、レビュー担当者がドラフト変更の理由を理解できるよう、その結果は新しい試行として扱ってください。

レビュー中

レビューでは、次の3つの状態を並べて表示する必要があります。

1. 翻訳に使用されたソース値
2. Contentful内の現在のターゲット値
3. 提案されたローカライズドラフト

これにより、古いソースデータが明らかになり、既存のローカライズ作業を保護できます。

リッチテキストでは、言語だけでなく階層もレビューしてください。レイアウト、リンク、埋め込みコンテンツがページに影響する場合は、承認前にCMSプレビューを開きます。

レビュー担当者が行った編集は、最終反映時に消えてしまうのではなく、保存されたドラフト履歴の一部になるべきです。

反映中

可能な限り最小の変更を書き込みます。

承認済みのターゲットロケールのフィールドだけを反映してください。現在のContentfulエントリを再取得し、無関係な値を保持し、最新のエントリバージョンを使用します。同じターゲットフィールドがレビュー開始後に変更されていた場合は、自動的に上書きするのではなく、判断のために停止してください。

Contentfulがどのフィールドを受け入れたか、そしていつ受け入れたかを記録します。APIレスポンスが成功していても、UIが完了を通知する前に、永続的なリクエスト状態へ対応付けられている必要があります。

公開中

反映と公開は別々の結果です。

エントリが設定された公開モードの対象であること、およびユーザーに公開権限があることを確認してください。公開が自動の場合、その失敗は翻訳や反映の成功とは独立させる必要があります。

リクエストには、ワークフロー全体を一般的な失敗にまとめるのではなく、"反映済み、公開失敗" と明確に表示されるべきです。

復旧中

信頼できるシステムは、プロバイダーがタイムアウトし、ネットワークが中断し、CMSバージョンが競合することを前提とします。

• 一時的なエラーは制限付きで再試行する
• 失敗した段階から再開する
• 成功した翻訳と反映はそのまま保持する
• 最新の対応可能なエラーを表示する
• 進行中の作業を安全に停止できる箇所ではキャンセルを可能にする
• リアルタイムイベントがなくても、ポーリングによって最終状態を復旧可能にする

復旧は作業を保持するべきであり、反射的に最初からやり直すべきではありません。

要点

Contentful翻訳に単一の信頼性機能はありません。

信頼は、あらゆる境界における限定的な保護策から生まれます。明示的な範囲、保護された構造、比較可能なレビュー状態、最小限の書き込み、分離された公開状態、そして段階を意識した復旧です。これらの制御が連携して機能するとき、チームはあらゆる多言語リリースを賭けのように扱うことなく、迅速に進めることができます。