すべてを再翻訳せずに更新を翻訳する

ローカライゼーションに関する助言の多くは、チームがまったく新しいコンテンツをゼロから翻訳していることを暗黙の前提にしています。ですが、ほとんどのリリース週はそうではありません。大半の週は編集でできています。価格変更、見出しの改善、製品UIの微調整、CTAの更新、既存のランディングページへの段落追加。

小さな変更のたびに完全な翻訳サイクルを回していると、ワークフローは月を追うごとに重くなっていきます。

間違い: すべての更新を新規プロジェクトとして扱うこと

チームは英語で何が変わったかを正確に把握していることが多いのに、ローカライゼーションのワークフローがその精度を維持できていないことがあります。結果はおなじみです。小さな更新がページ全体の翻訳依頼のように引き渡され、レビュアーは過剰な量の素材を確認し、チームは新しいコピーを改善するよりも古いコピーが依然として正しいことを証明するのに時間を費やします。

こうしてリリースへの信頼が崩れ始めます。

より良いモデル: 差分を翻訳する

成熟したワークフローは、更新をリセットではなく差分として扱います。

つまり、次のように問いかけることです。

• 実際に変更されたフィールドはどれか
• すでに承認済みでロックしたままにできるセクションはどれか
• 重点レビューを正当化するだけのリスクがあるページはどれか
• どのロケールで更新を即時反映する必要があるか

これはシンプルに聞こえますが、作業量を劇的に変えます。チームが差分を絞り込めるようになると、翻訳は定期的に積み上がるバックログ対応ではなく、通常のコンテンツ保守のように感じられるようになります。

なぜ絞った更新は速く進むのか

更新規模が小さいほど出荷しやすい実務的な理由は3つあります。

1. レビューが変更量に比例する

変更がCTAとサブヘッド各1つだけなら、レビュアーはローンチ当日のようにページ全体を再読する必要はありません。狭い変更セットは、狭いレビューセットを生みます。

2. これまでの判断を活かせる

用語集の選択、承認済みフレーズ、ブランド上センシティブな言い回しがすでに安定しているなら、システムは毎週それらを再検討するのではなく、その判断を土台にすべきです。

3. リスクを把握しやすい

大規模な再翻訳では、重要な変更が未変更コンテンツの山に埋もれてしまいます。小さな更新ならリスクが可視化されます。チームは重要な行を素早く見つけ、注意不要な部分を無視できます。

更新翻訳をどう構成するか

Contentfulチームにとって有用なパターンは次のとおりです。

1. 変更されたエントリーまたはフィールドだけを特定する
2. 可能な限り、以前に承認されたコピーはロックしたままにする
3. 更新範囲に対してのみ翻訳を実行する
4. 変更されたコピーを文脈の中でレビューする
5. ターゲットロケールのエントリーが意図した更新と一致していることを確認してから公開する

これは単に速いだけではありません。よりクリーンでもあります。ワークフローが、毎回すべてを揺さぶるのではなく、安定したコンテンツを尊重するようになるからです。

隠れた利点: レビュアー疲れの軽減

レビュアー疲れは、ローカライゼーションにおける現実的なコストです。変更のないコピーを過剰にチェックするよう求められると、人は本当に注意すべき点を見落とすようになります。ワークフローは責任を果たしているように見えても、シグナル対ノイズ比が悪いため、レビュー品質は結局低下します。

小さな更新バッチはこの問題を解消します。レビュアーが実際に変更されたコピーにエネルギーを使えるようになり、判断力が必要な箇所に集中できます。

スコープを狭く保つべきでない場合

それでも、バッチを広げるべきタイミングはあります。

• 製品名の変更が複数の接点に影響する
• キャンペーンメッセージが全体で変更された
• 用語集の判断を過去ページ全体に適用する必要がある
• コンプライアンスまたは法務改訂が多数のエントリーに一度に及ぶ

重要なのは、デフォルトで広げるのではなく、意図してスコープを広げることです。

まとめ

すべての更新が完全な再ローンチのように扱われると、ローカライゼーションは高コストになります。リライトと改訂の違いをワークフローが尊重すれば、はるかに容易になります。

ほとんどのチームに必要なのは、すべてをより速く再翻訳する方法ではありません。より少ない範囲を、より安全に触る方法です。