リッチテキストこそが翻訳ワークフローの真のテスト

見出しと短い説明があれば、ほとんどどんな翻訳ワークフローでも有能に見せることができます。本当のテストは、ソースエントリーにネストされたリスト、インラインリンク、埋め込みエントリー、そして意味を持つ書式が含まれているときに始まります。

そこで翻訳は単なるテキストの問題ではなくなり、コンテンツ構造の問題になります。

リッチテキストは文字列ではなくドキュメント

Contentfulのリッチテキストはツリーとして保存されます。段落にはテキストノードが含まれます。リストにはリスト項目が含まれます。リンクと埋め込みエントリーは他のコンテンツを参照します。マークは太字、斜体、コード、その他の書式を担います。

そのツリーをプレーンテキストに平坦化すると、単語は残るかもしれませんが、エントリーは残りません。

信頼できるワークフローは、ドキュメントを保持したまま言語を翻訳しなければなりません。

• 見出しは見出しのまま
• リスト項目は正しい順序を保つ
• リンクはリンク先を維持する
• インラインエントリーは編集者が置いた文中に残る
• 埋め込みブロックは周囲のコピーとの関係を保つ

翻訳モデルに対して、ワークフローが明示的に保護できたはずの構造を再構築させるべきではありません。

危険な失敗ほどもっともらしく見える

リッチテキストの損傷は、翻訳レビューで常に明白とは限りません。埋め込みが欠けていても、段落自体は自然に読めることがあります。分割されたリストは、いくつかの妥当な段落のように見えることがあります。インラインエントリーは消えても、文はその空白を埋めるように閉じてしまうことがあります。

そのため、構造的なエラーは目に見える例外よりも危険です。ローカライズされたエントリーがもはやソースを表していなくても、リクエストは成功として扱われてしまう可能性があります。

優れたレビュー用ツールは、保護された構造を見える形にします。編集者は、生のJSONを読んだり、すべてのトークンが無事だったと信じたりしなくても、埋め込み、リンク、書式がどこにあるかを確認できるべきです。

まず保護し、その後で翻訳する

強力なリッチテキストパイプラインは、翻訳可能なコンテンツと構造的なコンテンツを分離します。

モデルがドキュメントを受け取る前に、ワークフローは保護対象ノードを安定したプレースホルダーに置き換えることができます。モデルは周囲の言語を翻訳します。その後ワークフローが元のノードを復元し、すべてのプレースホルダーがそれぞれちょうど一度だけ返ってきたことを検証します。

これにより、責務が明確になります。

• モデルは言語を扱う
• アプリケーションは構造を扱う
• 検証は欠落または重複した保護対象コンテンツを検出する

この境界は、慣例に従ってCMSドキュメント全体を保持することを1つの確率的な応答に任せるより、はるかに信頼できます。

レビューするのは文章だけでなく階層も

人によるレビューでは、文だけでなくそれ以上を比較すべきです。次の点にも答えるべきです。

1. すべてのソースセクションが反映されているか。
2. リストのネストは保たれているか。
3. リンクと埋め込みエントリーは、正しい文脈に結び付いたままか。
4. 空のソースブロックは翻訳結果に入り込んでいないか。
5. レンダリングされたプレビューは、ソースページのコンテンツ階層と一致しているか。

最後の質問は重要です。構造的には有効なドキュメントでも、ぎこちないページを生み出すことがあるからです。プレビューを見れば、翻訳された見出しの折り返しが不自然ではないか、CTAがレイアウトを崩していないか、埋め込みが予期しない視覚的位置に置かれていないかが分かります。

要点

リッチテキストは、翻訳ワークフローが信頼を獲得する場所です。単語を保持することは最初の要件にすぎません。システムは、その単語の周囲に編集者が構築したドキュメントも保持しなければなりません。

構造を保護対象データとして扱い、保存前に検証し、CMSプレビューで結果を確認してください。リッチテキストがその一連の流れを無事に通過できれば、より単純なフィールドは本来そうあるべき簡単なケースになります。