概要

このリリースでは、導出可能なコンテキスト値のサポートが追加されました。コンテンツ向けの derive システムと同様に、context プロパティに derive 呼び出しを追加できるようになりました。これにより、異なるコンテキストごとに個別の翻訳エントリが生成されます。

動機

コンテキストシステムの初期設計には、私たちのミスがありました。導出システムでは、ソースエントリのコンテンツと訳文を 1 対 1 で対応付けています。つまり、1 つのソースから 1 つの訳文が生成されます。これは既存の翻訳システムとはうまく整合しています。そのシステムは、1 つのソースを入力として受け取り、単一の訳文を出力することを前提としています。つまり、n 個のソースエントリを作成すると、n 個の翻訳エントリができることになります。しかし、私たちは単純な事実を考慮できていませんでした。ソースエントリのコンテンツだけでは、必要な訳文が複数ある場合があるのです。

問題を理解する

ソースエントリの集合があるとします。この集合は、翻訳処理から抽出されたすべてのソースエントリを表します。次に、理想的な翻訳エントリの集合を考えます。この集合は、すべてのソースエントリを翻訳するのに必要な、すべての翻訳エントリの理想的な集合を表します。

これは、one-to-one、many-to-one、one-to-many の 3 つのケースに分けられます。重要なのは、ソースの集合と翻訳の集合の間に、必ずしも 1 対 1 のマッピングがあるとは限らないということです。

ケース1: 一対一の対応

各ソースエントリは、それぞれ1つの翻訳エントリにマッピングされます。

ケース2: 多対一マッピング

各ソースエントリを1つの翻訳エントリにマッピングでき、ソースセットの数は翻訳セットの数より多くなります。たとえば、英語には複数形処理の規則がありますが、中国語 (標準中国語) にはありません。そのため、中国語 (標準中国語) では、複数のソースエントリを1つの翻訳エントリで表せます。

ケース 3: 1対多のマッピング

各ソースエントリは、1つ以上の翻訳エントリに対応付けられます。たとえば、スペイン語では英語にはない男性形・女性形の一致があるため、同じソースエントリに対して2つの翻訳エントリが生じることがあります。

これは、初期実装では考慮していなかったケースです。ソースエントリと翻訳エントリは常に1対1で対応すると想定していました。

解決策

この問題は、コンテキストシステムと derive システムを組み合わせることで解決できます。ユーザーは、2 つ以上の翻訳エントリの曖昧さを解消するために、runtime でコンテキスト値を選択できます。

condition
  ? gt("I am tired", { $context: "inflect as masculine" })
  : gt("I am tired", { $context: "inflect as feminine" })

これを derive の呼び出しと組み合わせることで、正しい翻訳エントリを runtime で解決するロジックを埋め込めます。

gt("I am tired", { $context: derive(
  condition ? "inflect as masculine" : "inflect as feminine"
)})

これで、2つの翻訳エントリが生成されます：

"I am tired" -> "Estoy cansado"
"I am tired" -> "Estoy cansada"

これにより、(1) 必要な翻訳ケースをすべて満たし、(2) ユーザーが runtime で 2 つの翻訳エントリを区別できるようになります。

要約

コンテキストの導出は、原文エントリと翻訳エントリの間にある one-to-many のマッピング関係を表現できないという、翻訳モデルの根本的な欠落を補うものです。