工程師小明拿到多語系上線前的最後測試，一啟動專案，終端機立刻噴出滿版紅字：SyntaxError: Unexpected token。追查下去，才發現是外包翻譯人員把 JSON 配置檔裡的 true 翻成了「正確」，還順便把結尾的逗號給刪了。在軟體本地化過程中，JSON 與 YAML 這類配置檔的翻譯看似只是文字替換，實則暗藏讓系統直接崩潰的風險。
為什麼配置檔翻譯這麼容易「翻車」？
配置檔不是給人看的普通文章，它們是機器讀取的指令。一旦格式跑掉，程式就無法解析。常見的翻車原因包含：
- 語法極度嚴格：JSON 少一個括號、多一個逗號就會報錯；YAML 則對縮排（空格）極度敏感，Tab 和 Space 混用直接導致解析失敗。
- 鍵值對（Key-Value）誤譯：翻譯人員若不了解結構，很容易把作為識別碼的 Key（如
btn_submit）也翻譯掉，導致程式抓不到變數。 - 特殊字元與轉義：配置檔中常見的
\n、\"或 HTML 標籤，若被當作普通文字翻譯或修改，會破壞原有邏輯。
JSON 與 YAML 翻譯的結構保留技巧
要確保翻譯後檔案可用，必須嚴格區分「程式碼」與「待翻譯文字」。以下為兩種主流配置檔的翻譯保留原則對比：
| 特性 | JSON 配置檔 | YAML 配置檔 |
|---|---|---|
| 語法核心 | 大括號 {} 與鍵值對 : |
縮排層級與鍵值對 : |
| 常見崩潰原因 | 逗號遺漏、引號未閉合、Key 被翻譯 | 縮排錯位（如使用 Tab）、Key 被翻譯 |
| 翻譯保留原則 | 僅翻譯 " 內的 Value，保留所有 {}、[]、, |
僅翻譯 : 後的 Value，嚴格維持原有縮排空格 |
| 特殊符號處理 | 保留 \n、\" 等轉義字元 |
保留 ` |
配置檔翻譯的最高原則：機器讀得懂語法，人類讀得懂語意。任何破壞結構的翻譯，都是無效的本地化。
防崩潰實務：從工具到流程的把關
鎖定語法與術語一致性
手動用試算表翻譯配置檔是災難的開始。現代軟體本地化需要依賴專業工具來鎖定不可譯內容。DocTransAI 在處理這類結構化文件時，能自動識別並鎖定 JSON/YAML 的語法符號與 Key，確保翻譯引擎只針對 Value 進行處理，從根源杜絕語法崩潰。
此外，配置檔中常有 UI 字串或系統提示，建立統一的 企業翻譯為什麼必須建立術語庫（Glossary）？ 能讓不同模組的翻譯保持一致，避免同一個 error_404 在不同檔案中被翻成不同意思，降低使用者的認知負擔。
企業級配置檔翻譯的資安與部署
私有化部署保障機密不外洩
配置檔中有時會夾雜測試環境的 API Key、內部資料庫路徑或未公開的專案代號。將這些檔案上傳至公有雲翻譯服務，無形中增加了資安風險。
對於對資安要求極高的科技業或金融軟體團隊，企業私有化部署：讓翻譯數據完全不出本地 是更穩妥的選擇。透過私有化部署，企業可以在內部網路環境中調用 DocTransAI 的翻譯引擎，確保機密配置與程式碼邏輯完全不外洩，同時滿足嚴格的合規要求。
機器翻譯與人工審校的平衡
雖然 AI 模型已經能很好地理解 JSON/YAML 結構，但對於涉及業務邏輯的長句或特定領域的 UI 提示，仍建議採用機器翻譯加上人工審校的流程。實務上可依照以下步驟進行：
- 結構解析與提取：使用工具自動提取可翻譯字串，並保留原始格式與上下文。
- 多模型翻譯：針對不同語系或領域，選擇表現最佳的 AI 模型進行初譯。
- 人工審校微調：由工程師或本地化測試人員針對翻譯後的 Value 進行語意微調，確保符合軟體介面情境。
- 結構還原與驗證：將翻譯後文字寫回原檔，並執行語法檢查（Lint）確保無誤。
透過這套標準流程，開發團隊無需再花時間修復被破壞的語法結構，就能大幅提升軟體出海的迭代速度與產品品質。