要用 AI 建立本地化術語表，先確定產品、版本、來源 locale 及目標 locale。只從已獲批的材料抽取候選概念，再記錄定義、容許的譯法、禁用或棄用的變體、語境、負責人及狀態。AI 可以找出候選項及不一致之處；每個 locale 的具體術語都由合資格的語言負責人及領域負責人批准。

通用 AI 工作流程提供來源控制及覆核模式，本文把它應用到術語上。術語表可以支援 AI 輔助翻譯，但它不是完整的翻譯質素體系，也不能令未經覆核的譯文變得權威。

關鍵要點

管治的是概念及含義，而不只是反覆出現的詞對。

每個 locale 及地區變體的來源術語與目標術語分開記錄。

明確記錄容許、禁用、棄用及視乎語境而定的形式。

要求 AI 引用獲批證據，缺乏權威依據時放棄判斷。

發佈前在受控樣本上評估覆蓋率及誤報。

為術語表定版本，相關內容改變後重新進行漂移檢查。

如何安全地用 AI 建立本地化術語表？

本地化術語表是一種受管治的術語資源。每個條目把一個概念與特定語境中獲批的語言表達連結起來。它應協助譯者、審校、作者、設計師及自動檢查作出一致的選擇，同時不抹去合理的 locale 差異。

一個實用的條目可包括：

欄位	用途
`concept_id`	不依賴措辭的穩定概念識別碼
`definition`	獲批的含義及邊界
`domain`	產品範疇或主題語境
`source_locale`、`source_term`	獲授權的來源語言形式
`target_locale`、`target_term`	獲批的 locale 特定形式
`part_of_speech`	協助處理詞形變化及語法用法
`allowed_variants`	語境形式或縮寫形式
`prohibited_variants`	不應使用的形式
`deprecated_variants`	為方便偵測而保留的歷史形式
`example`、`counterexample`	展示正確及錯誤的語境
`source`	政策、介面、規格或負責人證據
`owner`、`status`、`version`	審批及生命週期控制

W3C 國際化詞彙表說明了為何國際化工作中的術語需要清楚界定的概念及語境。［1］簡單的兩欄詞表無法表示同形異義詞、語法特性、地區變體，或在一個介面正確、在另一個介面卻被禁用的術語。

怎樣建立有證據支持的術語資源？

第 1 步：凍結範圍及權威次序

建立範圍表頭，寫明產品或服務、發佈版本、內容類型、來源 locale、確切的目標 locale、受眾、司法管轄區、獲批來源語料、排除的草稿、術語負責人、覆核角色及預計發佈日期。

使用精確的 locale 識別碼。es-MX 及 es-ES 需要不同慣例時，es 可能過於籠統。zh-Hans 及 zh-Hant 描述的是書寫系統，但仍可能需要地區政策。不要因為語言相近，便推斷一個 locale 批准的術語可直接用於另一個。

抽取之前先界定權威次序。產品規格、獲批的介面字串、法律要求、品牌標準、領域專家及既有翻譯記憶可能互相衝突。記錄每個欄位以哪個來源為準，以及由誰裁決含糊之處。語料中的出現頻率是用法證據，不是權威證明。

第 2 步：準備已審批來源語料

只收集最終版或經明確批准的內容。為每項內容指派穩定的來源 ID、版本、locale、內容類型、負責人、審批狀態及擷取日期。除非政策授權，否則排除草稿、過時截圖、機器翻譯、客戶提交的內容及第三方文字。

統一檔案格式，但不改寫內容。保留解讀術語所需的標點、大小寫、佔位符、標記及句子語境。進行任何 AI 處理之前先刪除個人或機密資料，並遵守獲批的工具政策。

如果內容命名與資料命名混雜，要把術語管治與資料字典分開。資料字典界定欄位、類型及系統含義；本地化術語表管治的是語言概念及可接受的表達。有需要時可把兩者連結，但不要合併兩者的權威。

第 3 步：抽取術語前先界定概念紀錄

就必填欄位、狀態值及驗證規則達成共識。典型狀態包括 candidate、under_review、approved、deprecated、prohibited 及 rejected。訂明同一 locale 中一個概念可否有多個獲批術語，以及如何以語境區分。

由 ISO 30042:2019 標準化的 TBX 提供表示及交換術語資料的框架。［2］你不必採用 TBX 的所有功能，但它以概念為本的思路、語言分區、術語、定義及管理元數據是有用的模型。如需與翻譯管理系統交換資料，應核實對方支援的 TBX 方言及欄位，而不是假定相容。

加入確定性檢查：概念 ID 獨一無二、locale 代碼合法、負責人必填、狀態有效、定義不為空、來源參照明確，以及日期或版本格式正確。這些檢查能在語言覆核前找出結構錯誤。

第 4 步：讓 AI 帶引用抽取候選

提供獲批語料、來源 ID、欄位 schema 及排除規則。要求它提出候選項，而不是獲批條目：

只從所提供的獲批來源抽取重複出現或領域特定的候選概念。
為每一項引用所有來源 ID 及精確語境。把 UI 標籤、品牌名稱、
一般術語及 locale 慣例區分開。不要編造定義或目標譯法。
把含糊、同形異義及衝突標記出來供覆核。
按所提供的 schema 回傳候選紀錄。

核實每段引用的語境確實存在、每個來源 ID 真實、每個候選項都出現在語料中。只有在覆核人確定相同拼寫代表相同含義後，才按概念去除重複。「account」可以指用戶身份、財務紀錄或客戶機構；一個表面形式可能需要對應多個概念。

AI 亦可提出在各獲批來源中看似不一致的術語，但不得按頻率決定哪個變體正確。最常見的術語可能是新版產品已明確取代的舊文字。

第 5 步：區分術語與相鄰規則

批准之前先為每個候選項分類：

**術語：**需要受控措辭的領域概念。
**UI 字串：**精確的介面文字，其翻譯可能受空間或互動限制。
**品牌或產品名稱：**受命名及商標政策規管。
**locale 慣例：**日期、數字、地址、引號、大小寫或複數規則。
**風格偏好：**語氣、口吻、標點或一般寫作指引。
**不翻譯元素：**程式碼、佔位符、協議名稱或受保護的識別碼。

Unicode CLDR 提供用於顯示名稱、日期、數字、單位及複數規則等方面的 locale 資料。［3］它不是產品術語的權威來源。應連結適用的 locale 慣例，而不是把 CLDR 資料複製到每個術語條目。

同樣，內容風格指南規管較廣泛的編輯選擇。術語條目應保持精簡；當大小寫或語氣規則適用於多個概念時，連結到相應的風格規則。

術語應如何審批、發佈及監察？

第 6 步：覆核定義及來源術語

領域負責人應先確認每個概念真實存在、在範圍之內且定義準確。好的定義能把該概念與容易混淆的相鄰概念區分，並避免只用術語本身解釋自己。

覆核來源語言術語、詞性、大小寫、容許的縮寫、禁用的舊措辭、示例及介面限制。如果來源內容自相矛盾，不要借標準化把衝突掩蓋；應與產品或政策負責人解決，並記錄決定。

各 locale 共用一個概念 ID，但不要求語法結構完全相同。來源語言中的一個名詞，在另一種語言可能需要一個短語；英語複合詞可能需要不同的詞序、詞形變化、語法性別或語體。概念是共享的，語言上的實現則因 locale 而異。

第 7 步：逐 locale 批准目標術語

就每個目標 locale，應由合資格的語言覆核人及領域覆核人共同考慮含義、受眾、地區用法、語法、介面語境、無障礙、法律限制及現有產品用語。記錄分歧及負責人的最終決定。

歐盟委員會的翻譯資源說明了術語庫、風格指引及人工語言管治在專業翻譯工作中的角色。［4］應使用適合你的機構及語言組合的資源；公開術語庫可為研究提供參考，但不會自動凌駕產品或特定司法管轄區的要求。

不要把已批准的術語從 fr-FR 機械地複製到 fr-CA、由簡體中文複製到繁體中文，或由一個西班牙語市場複製到另一個。不要叫 AI 一次過「本地化整個術語表」，然後把所有結果標為已批准。每個 locale 都要保持獨立的狀態及證據。

第 8 步：測試覆蓋、誤報及例外

建立一個受控的評估樣本，包含一般文字、UI 字串、標題、支援內容、詞形變化、同形異義詞、禁用變體、舊文字、佔位符及合理的例外。保留一部分 holdout 資料，不在改良抽取或檢查規則時使用。

最少量度：

指標	問題
獲批術語覆蓋率	必需的概念是否以容許的術語表達？
禁用術語召回率	不容許的變體有否被偵測？
誤報率	正確的語境用法有否被錯誤標記？
未解決率	有多常仍需人工判斷？
locale 覆蓋	哪些目標 locale 及內容類型欠缺證據？
覆核推翻率	AI 建議有多常被修改？

確定性配對可能漏掉詞形變化，並因同形異義詞產生誤報；AI 能辨識語境，卻可能編造權威依據。視乎情況兩者並用，保留引用證據，把不確定項交給人。資料驗證清單可涵蓋結構欄位，含義則由語言覆核人判斷。

第 9 步：發佈有版本的術語表

每次發佈術語表都應包括版本、範圍、概念紀錄、各 locale 狀態、來源快照、變更紀錄、負責人、驗證結果、已知例外、生效日期及匯出格式。鎖定已批准的紀錄或清楚標示，以免之後的抽取暗中覆寫。

修改已批准術語前先做影響分析：找出受影響的 UI 字串、文件、客戶支援範本、翻譯記憶、搜尋元數據、截圖、培訓材料及網站資訊架構標籤。決定每處出現是即時修改、於下個版本修改，還是作為有紀錄的例外保留。

用戶仍在搜尋某個棄用標籤時，保留重新導向或搜尋同義詞，但不要把該變體呈現為首選。記錄禁用的原因屬法律、品牌、誤導、過時、冒犯，還是純屬風格選擇；覆核人需要知道原因，才能正確處理例外。

第 10 步：偵測術語漂移

凍結已發佈的術語表，只掃描獲批、有版本的內容快照。讓 AI 或確定性工具報告可能缺失的概念、棄用形式、未獲批的變體、定義衝突及新語境。每項發現都應引用內容 ID、確切出現位置、locale、配對的概念及規則。

把發現分為內容缺陷、術語表缺口、合理例外、誤報或來源版本不符。不要自動取代文字：簡短的 UI 標籤、引文、法定名稱、SEO 同義詞或歷史引用都可能需要例外。

在產品命名改變、功能推出、收購、監管更新、市場擴展、來源 locale 修訂、翻譯系統變更，以及覆核人一再出現分歧之後重新檢查。把模型輔助檢查視為受管治的生命週期，而不是一次性的生成任務。

常見錯誤有哪些？

**只做雙語詞表：**管治概念、定義、語境及生命週期元數據。
**把頻率當成權威：**引用獲批來源及具名負責人。
**把一個 locale 的術語複製到另一個：**獨立覆核每個目標 locale。
**混淆術語及風格規則：**為規則分類並連結正確的負責人。
**批量批准 AI 輸出：**所有抽取及翻譯出來的條目都保持候選狀態。
**每個表面配對都發出警告：**測試同形異義詞、詞形變化、引文及例外。
**自動取代文字：**審視影響，保留合理的語境差異。

總結

凍結產品、版本、來源 locale、目標 locale、語料及權威次序。
使用以概念為本的紀錄，包含定義、證據、負責人及狀態。
讓 AI 抽取及比較候選項，但絕不讓它批准術語。
區分術語、UI 字串、品牌名稱、locale 慣例及風格規則。
在受控、具代表性的樣本上評估覆蓋率及誤報。
發佈有版本的術語表，並以可追溯的人工決定審視術語漂移。

常見問題

AI 可從我們現有的全部譯文產生術語表嗎？

它可以抽取候選項，但現有譯文可能包含舊的、不一致或未獲批的措辭。應限定語料、保留來源引用，並由領域及語言負責人批准每個 locale。

術語表只是來源詞與目標詞的清單嗎？

不是。有用的術語表以概念為本，包含定義、語境、語法資訊、變體、禁用形式、來源、狀態及負責人。一個詞可能代表多個概念。

每個反覆出現的詞都應成為術語條目嗎？

不應該。優先處理領域特定、影響大、含糊、涉及品牌、受規管或經常不一致的概念。一般用語可繼續按一般編輯及語言判斷處理。

一個目標術語可獲批用於所有地區 locale 嗎？

只有在分別覆核、證明合適之後才可以。即使共用一種語言，各地區在含義、語法、慣例、法律及產品用法上也可能不同。

禁用詞和棄用詞應如何區分？

禁用詞在指定語境中不應使用。棄用詞曾獲接受，但正逐步淘汰，為了遷移可能仍保留可供搜尋。記錄原因及生效版本。

術語表可取代風格指南或翻譯 QA 嗎？

不可以。它只管治術語。風格、流暢度、含義、格式、功能、無障礙、佔位符及 locale 慣例都需要額外的控制及人工覆核。

如何偵測術語漂移而不產生過多誤報？

使用顧及 locale 的規則、語境、例外及具代表性的評估樣本。要求每項發現引用確切內容及概念 ID，然後量度誤報及覆核推翻情況。

術語條目何時需要重新批准？

當概念、產品版本、來源權威、目標 locale、法律要求、獲批措辭或相關語境改變時重新批准。記錄影響決定，而不是暗中取代之前的版本。

**免責聲明：**本文提供一般資訊，不構成認證翻譯、語言、無障礙、商標、監管或法律建議。請就每個領域及 locale 使用合資格的覆核人。

來源

World Wide Web Consortium, Internationalization Glossary: https://www.w3.org/TR/i18n-glossary/
International Organization for Standardization, ISO 30042:2019, Management of terminology resources — TermBase eXchange (TBX): https://www.iso.org/standard/62510.html
Unicode Consortium, Common Locale Data Repository: https://cldr.unicode.org/
European Commission, Guidelines for translating EU documents into English: https://knowledge-centre-translation-interpretation.ec.europa.eu/en/resources-translating-eu-documents/guidelines-translating-eu-documents-english

Sources checked 2026 年 9 月 6 日。

如何用 AI 建立本地化術語表：locale 審批及漂移偵測