技術翻譯：精準文件的實用工作流程

技術翻譯將專業資訊轉換為另一種語言，以便讀者能夠理解概念、比較規格或正確執行任務。它涵蓋設備手冊、工程規範、軟體文件和研究報告等文件。了解詞彙是必要的；維護指令、數值、圖表和版本之間的關係也同樣重要。

對於技術作家或專案負責人而言，第一個決策應該是 翻譯錯誤可能會改變什麼，而不是哪種工具能產生最快的草稿。翻譯錯誤的概述段落與相反的操作條件不應以相同的優先順序進入同一個審查佇列。

本指南提供跨文件的工作流程。如需詳細的格式專屬工作，請使用 使用者手冊翻譯指南 或 研究論文翻譯指南。下載 技術翻譯控制矩陣 ，將以下的決策轉化為指定的檢查項目。

依據用途而非僅依主旨來對文件進行分類

技術文件可以有多種用途。工程師可能會閱讀翻譯的研究報告作為背景資訊、將規格複製到採購決策中，或在實際設備上遵循操作程序。主旨可能完全相同，但出錯的後果卻大相逕庭。

在定義專案時請使用此風險圖。這是一個規劃框架，而非認證方案。

切勿從檔案短小推斷低風險。一頁規格書所承載的重大資訊，往往勝過冗長的描述性報告。

針對受法規管轄或攸關安全的內容，應由負責的專家決定是否允許進行機器翻譯。外觀良好的草稿，並不代表獲得法規接受或具備營運安全性。

在要求翻譯前撰寫驗收簡要說明

定義目標地區、受眾、用途、來源修訂版、輸出格式與核准負責人。「翻譯成西班牙文」並未釐清讀者是墨西哥的工程師、西班牙的消費者，還是使用內部工作複本的研究人員。

美國 美國翻譯協會（American Translators Association）的技術專案指引 建議準備可編輯的來源素材、受眾與用途資訊、參考文件，以及預留審閱時間。該指引亦建議核實譯者的相關專業領域，而非假設具備一般雙語能力即已足夠。

您的簡要說明應解答以下營運問題：

• 哪一個來源檔案與修訂版具備權威性？
• 包含哪些附錄、嵌入式圖表、試算表或連結檔案？
• 輸出成果是供閱讀的複本、可編輯的工作文件，還是發布成品？
• 有哪些數字、識別碼、產品標籤與術語需要進行受控處理？
• 誰能解決技術上的模糊之處，誰又能核准目標語言的用詞？
• 何種證據可用以證明工作已完成：經過審閱的檔案、問題記錄、已解決的參照項目，或是經簽署的發布記錄？

在與任何服務分享來源檔案之前，請先設定機密性與上傳權限。 文件翻譯隱私檢查清單 有助於區分有用的供應商問題與缺乏依據的安全假設。

準備一個可保留上下文的來源套件

儘可能取得原始創作檔案以及顯示預期呈現方式的 PDF 參考資料。將可編輯的圖表標籤和連結資產保留在其中。如果 PDF 是唯一的來源，請記錄該限制，而不是假裝隨時可以復原遺失的創作結構。

翻譯前，請區分可選取文字的 PDF 與純圖片掃描檔。OCR 會增加辨識步驟：錯誤的字元可能會變成錯誤來源的合理翻譯。針對該分支，請使用以下項目檢查辨識品質： 掃描 PDF 工作流程.

使語意含糊的來源用詞明確。請考慮以下自創的規格句子：

控制模組會監控驅動單元。請在檢查前將其斷開。

代名詞使得第二句的受詞變得不夠明確。譯者可以詢問指的是哪個元件；流暢的自動化輸出則可能會掩蓋這個未解的問題。文件擁有者應在任何人核准翻譯之前，於來源中指明該元件。切勿讓譯者憑空捏造操作說明。

微軟的 全球通訊寫作指引 支援清晰的句子結構、一致的術語，並避免難以翻譯的表達方式。請應用這些原則來消除歧義，而不是剝奪必要的技術細節。

將概念與字面字串分開控制

圍繞影響理解的概念建立簡短的術語暫存器。對於每個項目，請包含定義、來源上下文、核准的目標術語、拒絕的替代方案以及決策擁有者。單純的兩欄字詞清單會讓譯者難以猜測「bearing」、「terminal」或「range」適用於哪種含義。

保留一份獨立的字面字串清單：必須與實際產品相符的零件編號、指令名稱、網址、檔案路徑和介面標籤。有些標籤應進行在地化；有些則必須保持顯示原貌。請記錄選擇，而非套用單一全域的「全部翻譯」規則。

例如，名為 reset_cache 的指令與解釋性片語「reset the cache」並非同一類項目。該指令需要進行精確相配檢查；該片語則需要準確、自然的翻譯。

將未解決的問題記錄在一個地方，包含來源位置以及能改變文件的解答。 譯者查詢工作流程 當有多個審查者或語言共用相同的疑慮時，這會非常有用。

圍繞交付成果選擇工作流程

下列分支可防止一般技術翻譯流程變成純手動的檢查清單。

當核准的翻譯在不同版本間重複出現時，基於 CAT 的工作流程可能會很有用；檔案層級的翻譯草稿則可能適合一次性的閱讀或審查任務。這兩種選擇都無法免除檢查最終文件的必要性。 CAT 工具與機器翻譯比較 解釋了如何在人工主導、自動化與混合式工作流程之間進行選擇。

在處理整個包裹之前，請使用具代表性的區段來檢查所選的工作流程是否能交付所需的格式。請包含困難的素材，而不僅僅是簡單的導言頁面。如果表格、圖表或方程式無法在通往審查的路徑中存留，請在擴大規模之前解決該問題。

審查六個層面，每個層面均需指定負責人

將下方的矩陣視為發布檢查清單。勾選並不代表有人瀏覽過文件就告完成；它需要來源位置、目標位置以及結果。

在審閱期間將數字與單位保持在一起。作為一項具體的慣例， NIST 的 SI 指南 在數值與單位符號之間保留一個空格，包括攝氏度。來源值如 25 °C 需要的不仅是拼写检查：它描述的数字、符号和条件都很重要。单位转换是单独的编辑决策；翻译时不要悄悄转换或对数值进行四舍五入。

有关 PDF 特定的交付检查，请继续阅读 PDF 翻译 QA 检查清单。更广泛的 翻译质量控制中心 涵盖了相关的术语和译后编辑任务。

一个实际审查示例：正确的词汇，错误的规格

假设虚构的产品说明书包含以下两行：

如果目标表格交换了型号标签但保留了每个数字，数字存在性检查就会通过，而文档传达的却是错误的限制。这些虚构的值仅用于说明文档关系，并非真实产品的操作建议。

在可下载的矩阵中，这变成了检查 NUM-02：将每个型号标识符、值、单位和条件作为一个组进行比较。领域审校员记录修正内容；生产审校员重新打开导出的文件，以验证修复没有再次移动单元格。

这一教训不仅适用于表格：应检查关系，而不仅仅是检查单个字符串是否仍然存在。

分离审批角色并控制后续修订

领域专家可以确认规格的含义，但不一定具备判断每个目标语言细微差别的资格。语言审校员可以识别出翻译错误，却不知道哪个来源规格具权威性。为两者提供通往文档所有者的清晰途径；不要让“经工程部门审阅”替代所有其他检查。

使用四个明确的职责，即使某个人合理地承担了多个角色：

1. 文档所有者： 負責解決來源疑問並批准範圍或需求的變更。
2. 語言審閱者： 比對來源與目標含義，並針對目標讀者進行潤飾編輯。
3. 領域審閱者： 驗證技術概念、條件以及具決策參考價值的資訊。
4. 生產負責人： 驗證匯出的成品並打包正確的版本。

發布阻礙包括未解決的技術語意不明、缺少必要內容、數值或條件錯誤，以及將讀者引導至錯誤項目的圖表或參照。外觀上的喜好不應掩蓋這些缺失。

來源變更後，請識別受影響的章節以及相關的表格、圖表和參照。重新開啟其檢查項目。切勿假設先前已批准的段落在其運作情境變更後仍維持批准狀態。請將來源版本、目標版本、術語決策與已關閉的問題記錄妥善保存。

BookTranslator 的適用之處

BookTranslator 支援完整的 PDF 與 DOCX 檔案翻譯。針對適合上傳並作為草稿的文件，請從 PDF 翻譯工具 或 DOCX 翻譯工具開始，然後將結果與您的驗收簡報和控制矩陣進行比對。

切勿將檔案支援或自動詞彙表視為所有技術區分、圖表標籤或排版皆完整保留的證明。OCR 工作流程會重建識別出的內容，而非保證完美重現頁面。安全關鍵、受法規監管或具其他重大影響的文件，需要一開始就建立專業的工作流程，而非在未經審查的翻譯完成後才做出最後關頭的免責聲明。

有用的交接成果是一個翻譯後的檔案 加上檢查項目紀錄、檢查人員以及比對的來源。這正是讓下一次修訂變得易於管理的關鍵。