AI翻訳におけるプレースホルダー、リンク、識別子の保護

翻訳において最も重要な要素の一部は、そもそも翻訳されるべきではありません。

変数、URL、エントリーID、アセット参照、コードサンプル、書式マーカーは、文章ではなく機能を担っています。モデルは自然な文章を生成できても、それらの要素の1つを密かに変更し、周辺の体験を壊してしまうことがあります。

信頼できるAI翻訳は、言語と構造を切り分けることから始まります。

プロンプトの前に保護対象コンテンツを特定する

「プレースホルダーを保持する」といった一般的な指示に頼ってはいけません。まず、保持されなければならない正確なトークンとノードを特定してください。

保護対象コンテンツには、一般的に次のものが含まれます。

• {first_name} や {{ total }} のような補間変数
• ICUメッセージ構文と複数形セレクター
• URL、メールアドレス、ルートフラグメント
• HTML属性とmarkdownリンク先
• Contentfulのエントリー参照とアセット参照
• コードスパン、フェンス付きコードブロック、API値
• 非翻訳対象としてマークされた製品名

コンテンツモデルとフィールドタイプは、保護ルールの判断に役立つべきです。リッチテキスト文書には、プレーンテキストのタイトルとは異なる構造的な取り扱いが必要です。

リスクのある値を安定したトークンに置き換える

プレーンな文字列については、堅牢な方法の1つとして、翻訳前に保護対象の値を抽出し、それらを明確な一時トークンに置き換える方法があります。

モデルは周辺の言語を参照できますが、リンク先URLや識別子を誤って書き換えることはできません。生成後、ワークフローはサーバー側のマップから元の値を復元します。

トークンは一意で、自然言語と混同しにくく、復元前に検証されるべきです。マップ自体をモデルが再現することを決して信用してはいけません。

リッチテキストを構造として翻訳する

リッチテキストツリーをmarkdownやHTMLにフラット化すると、重要な違いが失われることがあります。

テキストノードは翻訳対象です。リンク、埋め込みエントリー、ノードタイプ、マークは構造です。ドキュメントツリーをたどって翻訳可能なテキスト葉ノードを翻訳し、参照には手を触れずに元の階層構造を再構築してください。

これによりレビューも改善されます。編集者は、ノードの欠落や並び替えを隠してしまう可能性のあるシリアライズされた近似表現をレビューするのではなく、両ロケールで同じ構造を比較できます。

保存前に出力を検証する

保護にはクローズドループが必要です。

翻訳後、期待されるすべてのトークンがフォーマット上許可された場所に正確に現れていること、そして未知のトークンが新たに導入されていないことを確認してください。構造化フォーマットは、緩い文字列比較ではなくパースして検証するべきです。

有用な失敗は具体的です。

• プレースホルダー {total} の欠落
• フィールド ctaBody におけるリンク先の変更
• ロケール de における無効なICU構文
• 想定外のリッチテキストノード数

この境界で不正な出力を拒否するほうが、レンダリング中、あるいはさらに悪いことに公開後に問題が表面化するのを待つより安全です。

レビューで保護要素を表示する

レビュアーは、機能的なコンテンツをそれに気を取られすぎることなく認識できるべきです。

プレースホルダーや保護対象語には控えめなスタイルを使ってください。リンクテキストは編集可能にしつつ、リンク先は見える状態で別個に管理してください。埋め込みコンテンツについては、不変のIDと並べて人が読めるラベルを表示してください。

レビュアーがターゲット市場向けのURLを意図的に変更する必要がある場合、それは文章翻訳の偶発的な副作用ではなく、ローカライズされたフィールドに関する別個の判断として扱うべきです。

敵対的な例でテストする

順調なケースだけでは不十分です。繰り返し変数、隣接する句読点、ネストしたmarkdown、複数形、右から左へのテキスト、そして普通の単語に見えるプレースホルダーを含む文字列を用意してください。

保護ロジックは、本番コンテンツに任せられる前に、それらのケースを損失なく往復できることを証明するべきです。

まとめ

翻訳品質には機能的完全性も含まれます。

保護対象コンテンツを抽出し、翻訳可能な言語だけを翻訳し、リッチテキスト構造を保持し、結果を検証し、レビュー中に機能要素を明確にしてください。流暢な文は、公開後もページが正しく機能して初めて価値を持ちます。