既存の翻訳を取り込む

多くのチームは、手ぶらで始めるわけではありません。リリース済みのアプリのドイツ語やフランス語の文字列、昨年翻訳したマニュアル、すでに4言語に対応したゲームなどです。これをすべて翻訳し直すとクレジットがかかるうえ、何より、承認済みの表現が失われてしまいます。そこでTranseptでは、既存の翻訳を取り込めるようにしています。既存の訳文は作り直さず、そのまま受け取ります。

この仕組みは、APIでTranseptを自動化するで説明している文字列テーブルのインポート（.tstrings.json）に組み込まれています。各文字列は固定のキーを持つ単位で、すでにある訳文を一緒に持たせられます。言語ごとに1エントリずつのtargetsマップを使います（ファイルが1つのロケールに固定されている場合は単一のtarget）。インポートすると、それらの訳文はすべて、それぞれの言語の現在の訳文としてそのまま書き込まれます。モデルは呼び出されず、クレジットも請求されません。作業はすでに済んでいて、Transeptは受け取るだけだからです。

既存の翻訳を取り込むメリットは、再翻訳のコストを抑えることだけではありません。シードした対訳ペアは、新しく生成したものと同じように翻訳メモリに登録されるので、メモリは初日から充実しています。次に似たテキストが出てきたとき、Transeptは当て推量ではなく、自分たちで選んだ言い回しを再利用します。翻訳が必要な部分にはこれまでどおり用語集やスタイルガイドが適用されるため、新しい文字列や変更した文字列も、シードした訳文と一貫した仕上がりになります。

データセットを取り込んだ後は、変更が発生するたびに現在のファイル全体を再送信することで同期を維持できます。Transeptはキーごとに差分を検出します。変更のない文字列は既存の訳文（および完了済みのレビュー）を保持し、実際に追加または変更された単位のみが翻訳されます。これはエディターの変更された箇所だけを実行すると同じ動作をAPI側で行うものです。数百件あるファイルのうち1件の文字列を修正した場合、請求されるのは数百件分ではなく、その1件分だけです。

シードする訳文は、エクスポート時にエラーを引き起こすような無関係な値ではなく、原文に対応した適切な翻訳である必要があります。そのため、各シードデータは原文のプレースホルダー（そのまま維持されるべき{name}形式のスロット）と照合されます。訳文のプレースホルダーが原文と一致しない場合、その単位は気付かれないまま反映されるのではなく、スキップされてレポートに記録されます。問題のないほかの単位は通常どおりシードされます。インポート結果には、シードされた訳文の件数とスキップされた件数が理由のサンプルとともに表示されるため、形式の崩れたエクスポートファイルを見落とさずに把握できます。（このチェックは、中括弧がプレースホルダーとして機能するICU形式の文字列テーブルで実行されます。プレーンなテーブルでは中括弧はリテラルテキストとして扱われ、そのまま残されます。）