翻訳者クエリログを使用して翻訳者の疑問を管理する方法

翻訳者クエリログとは、ソースパッケージから安全に解決できない疑問に対する共有の決定記録です。各行は正確なソースの場所を特定し、曖昧さとその影響を説明し、可能な場合は対応策を提案し、担当者と期限を指定し、最終的な回答と影響を受けるすべての場所を記録します。

その目的は、メッセージを収集することではありません。推測する、同じ質問を何度も繰り返す、メールの中で回答を見失う、1箇所を修正して同じ問題を他の場所に残してしまうという、4つのコストのかかる失敗を防ぎます。

米国翻訳者協会（American Translators Association）のガイドライン（翻訳プロジェクト中の疑問について）では、共有クエリファイルの活用、質問がすでに尋ねられたかどうかの確認、および納品前の未解決の質問の解決が推奨されています。XLIFF標準は、構造化された翻訳ワークフローにおいて同じ基礎データモデルを提供します。つまり、ソース単位とターゲット単位に、指示や翻訳者のコメントを含むコンテキスト情報やメモを持たせることができます。次を参照してください：XLIFF 1.2仕様.

回答によって翻訳が変わる場合にのみ質問する

合理的な翻訳者が承認されたソースから解決できず、かつその回答が意味、用語、スコープ、レイアウト、または受入基準を変更する場合、クエリはログに登録されるべきです。

適切なクエリのトリガーには以下が含まれます：

• 2つの妥当な指示対象を持つ文、
• 修正すると意味が変わる、見かけ上のソースのエラー、
• 定義されていない頭字語またはプロジェクト固有の用語、
• 2つのソースの場所における矛盾する名前や数値、
• 欠落している図、表、メモ、または参照された添付ファイル、
• コード、製品名、引用、または引用符の翻訳可能性の不明瞭さ、
• 要求されたターゲットを不可能にするレイアウトの制約、および
• 繰り返される発生に適用されなければならない決定。

通常の調査、提供された用語集、スタイルガイド、近傍のコンテキスト、または確立されたターゲット言語の慣習を通じて翻訳者が答えるべき質問にはログを使用しないでください。「確認してください」という依頼でいっぱいのログは、通常の翻訳作業をクライアントに押し戻し、重大な質問を隠してしまうことになります。

最小限の完全なスキーマを使用する

The crucial separation is between answered, implemented, and verified. A client response does not prove every affected passage changed, and an edit does not prove the final export contains it.

Write a query that can be answered in one pass

Use this structure:

Location: Chapter 4, paragraph 18, sentence 2

Source: “Mara told Elena that she would lead the delegation.”

Question: Does she MaraかElenaのどちらを指していますか？ターゲット言語では指示対象を明確にする必要があります。

確認された証拠: 直前の2つのパラグラフでは両方の女性が特定されていますが、委任の役割は割り当てられていません。

提案されたアクション: 著者がElenaを確認しない限り、Maraを使用してください。

影響: 同じ委任リーダーが第6章および第9章で言及されています。 必要な期限: 第4章の承認前。

これは「彼女は誰を指していますか？」とするよりも優れています。なぜなら、所有者にソース、結果、すでに実施された調査、提案されたデフォルト、そして下流への影響を伝えることができるからです。

1行につき1つの判断を求めるようにします。1つのパラグラフに曖昧な代名詞、誤った日付、未定義の頭字語が含まれている場合は、それぞれに異なる所有者とステータスを設定できるように、別々のクエリを作成してください。

好奇心ではなく、影響度でトリアージする

3つの実用的なレベルを使用します。

ブロック（進行不可）

影響を受ける翻訳を安全に進めることができないか、継続すると高額な手戻りが発生する状態です。例としては、ソースコンテンツの欠落、未解決の安全に関する文言、矛盾する数量、または章の中心となる未特定のエンティティなどが挙げられます。

メジャー（重大）

文書化された暫定的な仮定の下で作業を継続できますが、納品前には回答が必要です。例としては、繰り返し使用される用語、キャラクターの関係性、または出版物全体のフォーマット規則などが挙げられます。

マイナー（軽微）

ローカルな好みや影響度の低いパッセージに影響を与えるもので、一括処理が可能です。例としては、どちらのオプションでも意味が通じる場合の、一度限りのラベルの大文字化などが挙げられます。

重要度は緊急度と同じではありません。3時間以内に必要な主要な用語の決定は、来週まで翻訳されない付録のブロックよりも先に対応すべき場合があります。影響度と必要な期限の両方を記録してください。

適切な所有者に決定を割り当てる

すべての質問を著者に送らないようにしましょう。概念については専門家が解決し、表現については訳文エディターが責任を持ち、画像の差し替えが可能かどうかについてはプロダクションオーナーが判断する場合があるからです。

「信頼できる唯一の情報源」を維持する

正本となるログを1つ選びます。チャットやメールは通知手段として使えますが、回答は必ず情報源と日付を添えて、正本のログの該当行にコピーする必要があります。

新しいクエリ（質問）ごとに：

1. 用語、エンティティ、原文の抜粋、カテゴリーをログから検索します。
2. 重複を黙って増やすのではなく、関連する質問へのリンクを貼ります。
3. 安定したソースの場所とバージョンを使用する。
4. 決定権者を1人割り当てる。
5. 回答を完全に記録する。
6. 影響を受けるすべてのターゲットの出現箇所を見つける。
7. それらの編集が行われた後にのみ、行を実装済みにマークする。
8. 最終的な成果物を検証し、行をクローズする。

XLIFFの<note>要素は指示や翻訳者のコメントを保持でき、そのコンテキスト構造によって翻訳単位に情報を付加できる。プロジェクトでXLIFF、スプレッドシート、課題追跡システムのいずれを使用する場合でも、その単位レベルのトレーサビリティを維持する。

回答を再利用可能なプロジェクト管理コントロールに変える

決定が再利用可能である場合、1つの回答で複数の行を更新する必要がある。

• 承認された名前や用語を用語集.
• に追加する。
• 著者の声に関する決定事項をスタイルガイドに追加する。
• 翻訳対象外のルールをソースパッケージに追加する。
• 既知のソースエラーをチェンジログに追加する。
• 拒否されたバリエーションをQA検索リストに追加する。

コンテキストが不足している場合のガイダンスを次の翻訳バッチに追加する。

これが情報ゲインのループである。解決された質問ごとに、その後の翻訳とレビューの信頼性が高まる。作業リソースを更新せずにチケットをクローズするクエリシステムは、同じ質問の再発を保証してしまう。

ソースエラーを黙って書き換えることなく処理する

ソースが間違っているように思われる場合は、観察と決定を区別する。

悪い例：

日付を2019年から2020年に修正しました。

良い例：

翻訳者は証拠を特定して修正を提案できますが、事実に関するソーステキストを勝手に変更してはなりません。所有者が変更を承認した場合は、ソース自体が修正されるかどうか、およびどのターゲット版がそれを継承するのかを記録します。

暫定的な仮定を意図的に使用する

回答が届く前に作業を継続しなければならない場合：

• 選択肢にラベルを付ける provisional;
• それが最もリスクの低い選択肢である理由を記録する；
• 正確な検索トークンまたはセグメントリストを追加する；
• 変更期限となる最終的な安全日を特定する；
• ブロッカーが未解決のままリリースされるのを防ぐ；および
• 両方を競合する指示として残すのではなく、暫定的な注記を最終的な回答に置き換える。

沈黙を承認と捉えてはならない。プロジェクトの概要にそのルールが事前に記載されていた場合にのみ、締め切りをエスカレーションや宣言されたデフォルトのトリガーにすることができます。

クエリログをプロジェクトデータとしてレビューする

マイルストーンの終わりに、見せかけの数値ではなくプロセスのシグナルを計算する：

• 未解決のブロッカーと重大な問題；
• 未回答のクエリの経過日数；
• 担当者や期限が設定されていない質問；
• 重複した質問；
• 回答済みであるがまだ実装されていない行；
• 実装済みであるがまだ検証されていない行；
• 繰り返し発生するカテゴリとソースの場所；および
• 回答から作成されたソース、用語集、または概要の改善。

クエリの数が多いからといって、必ずしも翻訳の質が低いとは限りません。それは、ソースが難解であるか、翻訳者が憶測での翻訳を拒否していることを示している可能性があります。有益な疑問は、クエリが具体的で、重要であり、一度で解決され、正しく反映されているかどうかです。

クエリログのリリースチェックリスト

納品前に以下を確認する：

• すべての行が正確なソースバージョンと場所を特定していること；
• ブロッカーおよび重大なクエリには権限のある回答が示され、
• 暫定的な前提は承認されるか削除され、
• 最終的な回答には「はい」や「承認済み」だけでなく決定内容が記載され、
• 繰り返される用語やエンティティは影響を受けるすべての箇所で更新され、
• 再利用可能な決定事項が用語集、スタイルガイド、QAルールに反映され、
• 「回答済み」「実装済み」「検証済み」はそれぞれ異なる状態であり、
• 最終的なエクスポートファイルは実装後に確認され、
• 取り下げられた行や未解決の行には説明が保持されます。

プロジェクトを開始するには、書籍のソース事前確認ワークフローを利用し、質問が増える前にソースのバージョン、用語集、アセット、受け入れ基準を明確にしてください。BookTranslatorは対応する書籍やドキュメントファイルから完全な翻訳ドラフトを生成できます。ソースの文脈や自動化だけでは安全に解決できない決定事項を記録するためにクエリログを使用し、その回答を人間のレビュー時に一貫して適用してください。