如何透過查詢日誌管理譯者問題

譯者查詢日誌是用於記錄無法從來源套件中安全解決的問題之共用決策記錄。每一列會識別確切的來源位置、解釋語意不明之處及其後果、盡可能提出建議操作、指定負責人與期限，並記錄最終答案以及所有受影響的位置。

它的目的不是為了收集訊息。它可以防止四種代價高昂的失敗：猜測、重複詢問相同問題、在電子郵件中遺失答案，以及修復了一處卻在其他地方留下相同問題。

美國翻譯協會（American Translators Association）關於翻譯專案期間問題的指引建議使用共用的查詢檔案、檢查是否已問過某個問題，並在交付前解決未決的問題。XLIFF 標準在結構化翻譯工作流程中提供了相同的底層資料模型：來源和目標單位可以攜帶上下文資訊與備註，包含指示和譯者評語。請參閱XLIFF 1.2 規格.

只有在答案會改變翻譯時才提出問題

當合理的譯者無法從核准的來源中解決問題，且答案會改變意義、術語、範圍、版面配置或驗收條件時，該問題就應該列入日誌中。

好的查詢觸發條件包括：

• 具有兩個合理解析對象的句子；
• 修正後會改變意義的表面來源錯誤；
• 未定義的縮寫或專案特定術語；
• 兩個來源位置中名稱或數字衝突；
• 遺失圖表、表格、備註或引用的附件；
• 程式碼、產品名稱、引文或引言的可翻譯性不明；
• 使要求的目標變得不可能實現的版面配置限制；以及
• 必須套用於重複出現之處的決策。

請勿將日誌用於譯者應透過一般研究、提供的詞彙表、樣式指南、鄰近上下文或既定目標語言慣例來回答的問題。充滿「請確認」要求的日誌會將正常的翻譯工作轉嫁給客戶，並掩蓋了重要的問題。

使用最低完整綱要

關鍵在於區分 已回答, 已執行、以及 已驗證。客戶的回答並不代表所有受影響的段落都已修改，而單次的編輯也不代表最終匯出的檔案中已包含該項變更。

撰寫一個能一次性回答的問題

使用此結構：

位置： 第 4 章，第 18 段，第 2 句

原文： 「Mara 告訴 Elena 她將帶領代表團。」

問題： 請問 she 應指Mara還是Elena？目標語言要求明確指出指代對象。

已檢查證據： 前兩段提到了兩位女性，但未指定委派角色。

擬議操作： 除非作者確認為Elena，否則使用Mara。

影響： 第6章和第9章引用了相同的委派領導者。 需求期限： 在第4章審核之前。

這比「她指的是誰？」更好，因為它為負責人提供了來源、後果、已完成的調查、擬議的預設值以及下游影響。

一行應詢問一項決定。如果某段包含含糊不清的代名詞、錯誤的日期和未定義的縮寫，請建立獨立的查詢，以便每個查詢可以有不同的負責人和狀態。

根據後果分類，而非出於好奇

使用三個實用的層級。

阻礙

受影響的翻譯無法安全進行，或者繼續進行會產生高昂的返工成本。範例包括遺失的來源內容、未解決的安全性語言、相互矛盾的數量，或章節核心的未識別實體。

重大

可以帶著有記錄的臨時假設繼續工作，但在交付前必須得到解答。範例包括重複出現的術語、角色關係或出版物範圍的格式規則。

次要

該決定會影響局部偏好或低影響力的段落，並且可以批次處理。範例包括當兩個選項都保持易懂時，對一次性標籤的大小寫處理。

嚴重性不等於緊急性。三小時內需要的重大術語決定，可能值得在下週才翻譯的附錄中的阻礙之前採取行動。同時記錄影響與需求期限。

將決定指派給正確的負責人

不要將所有問題都丟給作者。領域專家可以解釋概念，目標語言編輯可以決定用詞，而製作負責人則可以決定是否更換圖片。

維持單一事實來源

選擇一個權威記錄檔。即時通訊和電子郵件可用於通知相關人員，但其回覆必須連同來源和日期一併複製到權威記錄的對應列中。

針對每一項新查詢：

1. 在記錄檔中搜尋該術語、實體、原文摘錄及類別。
2. 連結相關問題，而非默默建立重複項。
3. 使用穩定的來源位置與版本。
4. 指派一名決策負責人。
5. 完整記錄答案。
6. 尋找每一個受影響的目標出現位置。
7. 僅在完成這些編輯後，才將該列標記為已實作。
8. 驗證最終交付成果並關閉該列。

XLIFF 的 <note> 元素可以攜帶指示或譯者註解，其上下文結構可以將資訊附加到翻譯單元。無論您的專案使用的是 XLIFF、試算表還是問題追蹤系統，請保留該單元層級的可追蹤性。

將答案轉化為可重複使用的專案控制項

當決策可重複使用時，一個答案應該更新多個列。

• 將核準的名稱或術語新增至 術語表.
• 將作者語氣的決策新增至樣式指南。
• 將不翻譯規則新增至來源套件。
• 將已知的來源錯誤新增至變更日誌。
• 將拒絕的變體新增至 QA 搜尋清單。
• 將缺少上下文的指引新增至下一個翻譯批次。

這就是資訊增益循環：每一個解決的問題都會讓後續的翻譯與審閱更加可靠。只關閉單據卻不更新工作資源的查詢系統，保證會產生重複的問題。

處理來源錯誤而不默默重寫它們

當來源看起來有誤時，請區分觀察與決策。

不良的列：

將日期從 2019 年修正為 2020 年。

較佳的列：

來源此處寫 2019 年，但在時間軸與引用的報告中寫 2020 年。哪一年具權威性？擬議行動：保留 2019 年，直到來源負責人批准修正。影響：正文段落、時間軸、圖說與索引條目。

譯者可以識別證據並建議修正，但不應默默更改事實性來源。如果擁有者批准了變更，請記錄是否將修正來源本身以及哪些目標版本會繼承該變更。

刻意使用臨時假設

當工作必須在答案到達之前繼續時：

• 標記該選擇provisional;
• 記錄為什麼這是風險最低的選項；
• 新增確切的搜尋詞元或片段清單；
• 識別更改它的最後安全日期；
• 在阻礙因素仍然存在時阻止發布；以及
• 用最終答案替換臨時備註，而不是將兩者都留作互相衝突的指示。

切勿將沉默視為批准。只有在專案簡報事先給出該規則的情況下，期限才能觸發升級或宣告的預設值。

將查詢紀錄視為專案資料

在里程碑結束時，計算流程訊號而非虛榮指標：

• 開放的阻礙和重大問題；
• 未回答查詢的年齡；
• 缺少擁有者或需求日期的問題；
• 重複的問題；
• 已回答但尚未實作的列；
• 已實作但尚未驗證的列；
• 重複出現的類別和來源位置；以及
• 由答案建立的來源、詞彙表或簡報改進。

大量的查詢數量並不自動意味著翻譯品質差。它可能表示來源困難，或是譯者拒絕盲目猜測。有用的問題是查詢是否具體、重要、解決過一次，並且已正確傳播。

查詢紀錄發布檢查清單

在交付之前，請確認：

• 每一列都識別出確切的來源版本和位置；
• 阻擋與重大查詢有具體權威的解答；
• 臨時假設會獲得核准或遭到移除；
• 最終答案會明確指出決策內容，而不僅僅是「是」或「已核准」；
• 重複出現的術語和實體已在所有受影響的位置中更新；
• 可重複使用的決策已納入詞彙表、樣式指南與 QA 規則中；
• 已解答、已實作與已驗證是不同的狀態；
• 最終匯出的檔案已在實作後進行檢查；以及
• 已撤回或未解決的項目仍保留說明。

請透過以下方式開始專案：書籍來源預先檢查工作流程，以便在問題增加之前釐清來源版本、詞彙表、資產與驗收標準。BookTranslator 可以從支援的書籍和文件檔案產生完整的翻譯草稿；利用查詢記錄來捕捉來源上下文與自動化無法安全解決的決策，然後在人工審查期間一致地套用這些答案。