ページを再構築せずに1つのフィールドだけを翻訳する

すべてのローカライズ作業がページ公開とは限りません。レビュー後に見出しが変更されることもあります。法務文の修正が必要になることもあります。プロダクトマーケターが1つのCTAを書き直し、次のキャンペーン公開前までにローカライズ版を用意したい場合もあります。

エントリー全体を再度翻訳にかけることは可能ですが、その変更規模には見合わない対応です。

ワークフローを変更の規模に合わせる

大きな翻訳アクションは、ソースの変更が大きいときには理にかなっています。新しいページ、連携したリリース、大規模なコンテンツ移行には有効です。

1フィールドの編集には、異なる要件があります。

• 編集者は、どのソース値が変更されたかをすでに正確に把握している
• 他のローカライズ済みフィールドはすでに承認されている可能性がある
• レビューは1つの判断に集中すべきである
• 反映時に無関係なコンテンツへ触れないようにすべきである

ワークフローがその範囲を無視すると、小さな編集がエントリー全体の翻訳と同じコストとリスクを引き継いでしまいます。

エントリー全体の再試行が疑念を生む理由

ページ全体を再翻訳すると、対応が不要だったフィールドにも妥当ではあるものの異なる言い回しが生成されることがあります。そうした変更が文面を改善するとしても、レビュー対象の範囲を広げてしまいます。

するとレビュアーは、既存の翻訳が意図的に修正されたのか、用語が変更されたのか、そして新しい出力で承認済みの値を置き換えるべきなのかを確認しなければならなくなります。

それは不要な手戻りです。限定的なソース編集は、限定的なターゲット差分を生むべきです。

フィールド単位の進め方

有用なフィールドアクションは、編集者がすでに確認しているフィールドのすぐそばから始められるべきです。翻訳リクエストには、エントリー、ソースロケール、ターゲットロケール、フィールドの識別情報、現在のソース値が引き継がれる必要があります。

結果は同じ文脈に戻るべきです。編集者が比較する必要があるのは次の4点です。

1. ソースフィールド
2. 現在のターゲット値
3. 提案された翻訳
4. 反映される最終値

これにより、判断が明確になります。エントリーの他の部分が変更されていないことを確認するために、残り全体を見渡す必要はありません。

同じ安全策を維持する

短いワークフローだからといって、弱いワークフローになってはいけません。フィールド単位の翻訳でも、完全なリクエストと同じ制御を尊重すべきです。

• 承認済みモデルへのアクセス
• プロジェクトのプロンプトと用語集
• ロケール権限
• 下書き履歴
• 反映および公開の認可
• Contentful のバージョンチェック

変わるのは範囲であり、ガバナンスではありません。

また、AI 出力の生成後も編集者のコントロールを維持することが重要です。提案されたフィールドは編集可能なままであるべきであり、そうすることでレビュアーは別のリクエストを開始せずにニュアンスを修正できます。

フィールド単位の翻訳が適さない場合

フィールドは常に単独で成立するとは限りません。タイトルがその下の要約に依存することもあります。CTA が周囲の段落で確立された表現を使うこともあります。リッチテキストのセクションには、文書全体の中でしか意味をなさない参照が含まれる場合もあります。

値だけで安全に翻訳できるだけの文脈がある場合は、フィールドアクションを使ってください。内容にトーン、用語、構造の調整が必要な場合は、エントリー全体を使ってください。

プロダクトは、この2つの進め方を同等のものだと見せかけることなく、どちらも利用できるようにすべきです。

要点

ローカライズのワークフローは、元の変更の規模を保つと、より速くなります。

1つのフィールドは、より大きな作業と同じレビュー履歴と公開制御を備えたまま、1つのフィールドとして翻訳できるべきです。そうすることで承認済みコンテンツの安定性が保たれ、レビュアーは焦点を絞った判断ができ、小さな文言更新を再び小さな作業に戻せます。