Metlivi 部落格

如何校對技術術語、大小寫與翻譯標籤

審閱技術文件時，請依據明確的術語表逐一核對各個術語，而非單憑記憶或單一的大小寫規則。記錄核准的形式、讀者應看到的拼寫與大小寫、可接受的變體、逐字精確的程式碼或 API 識別碼，以及任何仍待決定的翻譯。接著，將正文、介面標籤與識別碼視為不同的項目分別進行校對。這種方法既能揪出不一致的術語，又能保留必須維持精準無誤的名稱與程式碼。

2026年9月30日4 分鐘閱讀生活美學與自我表達作者：Metlivi Editorial Team

開啟產品返回文章庫

第 1 節

為什麼單一的大小寫規則無法解決所有術語問題？

風格指南（Style guides）提供了實用的預設標準，但某個產品或領域可能已經有確立的專有名稱，需要採用不同的處理方式。Google 的開發者指南建議在標題、清單與表格中使用標準美式英文大小寫與句首大寫（sentence case），同時保留官方產品名稱與程式碼形式。微軟的指南同樣傾向使用句首大寫風格，但明確將大寫保留給專有名詞，例如其品牌、產品與服務。它們共同的預設值只是一個起點，並不能證明某個特定的技術術語就是普通名詞。[Google 的大小寫指引](https://developers.google.com/style/capitalization) [微軟的大小寫指引](https://learn.microsoft.com/en-us/style-guide/capitalization)

字詞清單（word list）可以回答與一般大小寫頁面不同的問題：特定編輯指南在具體術語上偏好哪種拼寫或用法。舉例來說，Google 的字詞清單會引導讀者查閱其偏好的字典以獲取未涵蓋的詞條，並將風格指引與在權威文件中查詢技術定義區分開來。這種區隔非常實用：編輯的一致性與技術的正確性，各自需要來自適合該問題的來源證據。[Google 的字詞清單](https://developers.google.com/style/word-list)

第 2 節

校對術語表中應該包含哪些內容？

為每個可能被不一致修改或誤譯的術語建立一列。以下這個假設範例展示了欄位與決策邏輯；其中的「Sync token」及其翻譯僅為說明之用，並非針對真實產品或已核准術語的主張。

此表格的作用是保留決策及其適用邊界。允許的小寫形式不應在無意間演變成第二個產品名稱；識別碼不應被「修正」成與內文一致；尚未確定的翻譯也應保持清晰可見的待定狀態。當官方來源與本機詞彙表衝突時，應記錄該衝突以及最終決策的依據來源，而不是將各個形式合併成未加解釋的清單。

術語與適用範圍 — 概念、產品領域與目標受眾 — Sync token；設定指南

官方形式與證據 — 精確的核准形式、來源，以及核對的版本或日期 — Sync token；產品詞彙表，第 3 版

顯示形式 — 用於說明性正文與標籤的拼寫與大小寫 — Sync token

允許的變體 — 在特定情境下允許使用的形式及其原因 — 若詞彙表允許，在一般正文中使用「sync token」

字面識別碼 — 絕對不能被改寫的精確程式碼、API、指令或 UI 字串 — API 回應中的 `syncToken`

翻譯狀態 — 核准的本地化標籤、證據、負責人或工作流程，或待定狀態 — 未解決；需要進行翻譯審閱

第 3 節

如何決定顯示的拼寫與大小寫？

首先識別該術語指的是什麼：是普通概念、品牌或產品名稱、UI 標籤，還是字面識別碼。查閱相關的產品文件或詞彙表以確認官方形式。接著將目標出版物的風格規則套用至一般正文、標題與標籤，同時為名稱與識別碼保留有文檔記錄的例外情況。Google 建議避免不必要的大寫，並警告不要僅憑大小寫來區分語義；微軟同樣在其句首大寫方法中表示，除了句首與專有名詞外，其餘一律使用小寫。[Google 大小寫指引](https://developers.google.com/style/capitalization) [微軟大小寫指引](https://learn.microsoft.com/en-us/style-guide/capitalization)

接著，在適當的情況下，將該形式與目標組織的字詞清單及字典進行比對。記錄來源及其版本或查核日期，以便另一位編輯能夠追溯該選擇的依據。切勿僅憑看起來順眼的大寫拼寫、搜尋結果或與英文術語相似的翻譯，就推斷其具有官方地位。如果各來源之間存在分歧或未明確規定形式，請將該列標記為待決策，切勿將猜測當作已確定的術語呈現。

第 4 節

應該如何檢查翻譯與介面標籤？

應將翻譯視為涉及語義與語境的決策，而非機械式的大小寫轉換。標籤可能會受到介面空間、既有的本地化產品術語，或目標語言中不同語法形式的限制。將候選詞與核准的本地化資料以及讀者接觸到它的實際情境進行比對。如果沒有權威的本地化形式可用，請將該翻譯標記為未解決並請求相應的術語決策；切勿自行捏造一個所謂的官方對應詞。

完成術語決策後，請在實際位置校對該標籤。檢查大小寫是否符合所選語言的規則以及適用的產品或內部風格。在術語記錄中保留原始標籤、其來源與狀態，以確保未來的編輯不會將臨時翻譯誤認為已核准的翻譯。如果說明文件中也引用了該標籤，請確認內文提及的名稱與螢幕上顯示的文字完全一致。

第 5 節

如何保護程式碼與 API 識別碼？

在更改大小寫之前，務必先將字面字串（literal strings）與編輯文本分開。將識別碼與相關的 API 參考資料、結構綱要（schema）、程式碼或介面逐字進行比對。在來源有定義的地方，請完整保留底線、大小寫、空格與標點符號；風格標準化應留在周圍的說明文字中，而非套用在字面值上。Google 的指南明確允許在官方名稱中或引用包含它們的程式碼時，使用全大寫（all-caps）或駝峰式命名法（camel-case）。[Google 大小寫指引](https://developers.google.com/style/capitalization)

實務上的審閱方式是在術語表中標註受保護的識別碼，然後依據該參考標準檢查每一次出現的情況。如果正文句子將程式碼形式的術語當作普通名詞使用，請決定是否要改用對讀者友善的措辭加以解釋，同時在程式碼格式中保留完整的字面識別碼。當權威定義本身不甚明確時，請記錄該不確定性；風格指南無法用來判定 API 的行為或標準欄位名稱。

第 6 節

什麼是可靠的校對流程？

這個流程是一項校對輔助工具，而非自動翻譯或通用的大小寫規則。它的價值在於讓每項編輯決策都可被檢驗：選擇了什麼形式、出自何處、適用於何處，以及還有哪些項目需要決策。對於簡短的文件，一份精簡的表格可能就足夠了；對於龐大的術語集，請在團隊既有的詞彙表工作流程中保留相同的欄位。

**收集：** 在受審閱的資料中，找出重複出現的技術術語、產品名稱、標籤、翻譯術語與識別碼。

**查證：** 查閱適用的官方文件、詞彙表、字詞清單與風格指南。若有來源版本或日期，請一併記錄。

**決策：** 在表格中填入核准的顯示形式、允許的變體以及受保護的識別碼。將有爭議與缺漏的翻譯標記為未解決。

**套用：** 一致地編輯一般正文與標題，同時保留官方名稱、引用的措辭與字面識別碼。

**複查：** 在文件中搜尋每個記錄的變體與每個受保護的識別碼。確認每一次出現都符合其規定的語境，並在宣布術語校對工作完成之前，解決或呈報未決的項目列。