String Catalog 多語言測試：2026 遠端 Mac 怎麼自動化？

String Catalog 自動化的第一個目標，不是「所有翻譯都變綠」，而是確認四件事：字串是否被提取、翻譯狀態是否符合發布要求、執行時介面是否可用，以及最終建置是否包含資源。Apple 也將文字準備、測試與本地化資源匯入匯出分成不同流程，應分別保留證據，而不是混成一個成功或失敗標記。

先從登入、購買、訂閱恢復或核心創作流程選取少量路徑。這些頁面通常同時包含標題、按鈕、錯誤訊息、複數和插值，能較早暴露真正影響發布的問題。若一開始把所有設定頁和低使用率畫面都納入，測試維護成本會快速上升，失敗原因也難以定位。

SwiftUI 專案：由提取結果進入執行驗證

SwiftUI 的文字若使用正確的可本地化 API，便能在建置流程中進入 String Catalog；相關提取規則可參考 Apple 對 SwiftUI 與程式碼文字提取的說明。因此，測試首先要找出「看起來是文字、但實際沒有進入目錄」的寫法，例如自訂封裝忽略本地化處理、動態組合字串，或只在某個條件分支中出現的訊息。

建立最小樣本時，至少放入以下內容：

• 一般標題與按鈕文字；
• 含插值參數的句子；
• 單複數不同的訊息；
• 長文字與短文字的裝置變體；
• 翻譯缺失時應出現的回退語言。

Preview 可以快速查看文字替換和版面變化，但不能取代實際 UI 測試。通過條件應包括：文字在目標語言中出現、參數順序正確、按鈕沒有被截斷、文字不會推動主要操作離開可視範圍。若只看到 Preview 正常，卻沒有在代表性語言執行最小流程，便不能把這個結果當成通過。

UIKit 與混合專案：分清資源來源和 Target 邊界

UIKit 或混合專案最常見的風險，是遷移後同一段文字同時存在於 String Catalog、strings 或 stringsdict，或者 Storyboard、XIB 與 Info.plist 的本地化資源沒有被同一個 Target 使用。這類問題不一定會在編輯器中顯示為錯誤，卻可能在擴充功能、框架或不同 Scheme 建置時才暴露。

存量專案應採取可回退的分模組遷移：

1. 先列出 App、Extension 和 Framework 各自擁有的本地化資源。
2. 為一條核心流程指定唯一的資源來源。
3. 建置後檢查每個 Target 的 Bundle，而非只查看主 App。
4. 用實際執行畫面確認 Storyboard、XIB 和程式碼文字均能替換。
5. 確認穩定後才遷移下一個模組，保留原資源作為回退依據。

通過標準不是「格式全部統一」，而是沒有重複鍵、沒有遺漏鍵，且不同 Target 的實際畫面都能使用正確翻譯。對仍依賴 stringsdict 的模組，不必為了追求單一格式而一次性重寫整個專案。

「語言」和「地區」不是同一個測試條件。Apple 的本地化測試文件說明了如何在執行 App 時測試本地化結果；Test Plan 則可用來組織測試條件，並設定應用程式語言與地區。可參考 Apple 的本地化執行測試文件 與 Test Plan 組織說明。

語言地區矩陣應根據實際市場建立，不要把所有語言與所有模擬器組合都當成同等優先。核心矩陣可按以下維度整理：

Test Plan 中應將 Application Language 與 Application Region 分開設定。這能避免測試只換了顯示語言，卻沒有驗證貨幣或日期格式。對 RTL 語言，還要特別觀察圖示方向、返回按鈕、列表排列與固定寬度元件；單純確認字串已替換，不能代表版面可用。

本地化截圖也應被視為測試證據。Apple 提供了 為本地化人員建立 App 截圖的官方流程，但測試截圖不應直接等同於 App Store 行銷素材。每張圖應保留語言、地區、Scheme 或測試案例等環境識別，方便翻譯複核與之後的 UI 回歸。

在持續整合中，建議將流程拆成四類可單獨重跑的任務：字串匯出或提取檢查、指定語言與地區的測試、UI 測試及截圖、建置結果與 xcresult 歸檔。Apple 的 本地化匯出文件 和 匯入文件 可作為資源交換流程的依據。

遠端 Mac 的落地步驟如下：

1. 固定建置入口。 指定 Workspace 或 Project、Scheme、測試計畫和簽名方式，避免本機與遠端使用不同設定。
2. 先執行提取與資源檢查。 將新增字串、缺少翻譯或格式異常分開記錄，不要等到 UI 測試失敗才回頭尋找原因。
3. 按矩陣執行測試。 為高風險語言、地區和裝置尺寸建立獨立測試任務，失敗時只重跑受影響的組合。
4. 保存截圖和 xcresult。 截圖要附上環境識別，測試結果則保存測試案例、失敗畫面和日誌，讓沒有圖形介面的 SSH 工作階段也能追查。
5. 驗證重啟與斷線恢復。 檢查 SSH 中斷、遠端主機重啟、模擬器重新啟動後，任務是否能從明確階段重跑，而不是留下半份結果。
6. 最後執行真實 Archive。 從產物中確認預期語言資源存在，再於代表性語言中完成核心流程驗收。

需要圖形登入工作階段的模擬器和 UI 測試，不應被當成純 SSH 命令處理。SSH 適合觸發 xcodebuild、讀取日誌和取回結果；遇到模擬器卡住、視窗狀態異常或登入工作階段失效時，則需要透過 VNC 或網頁控制台觀察遠端畫面。對獨立開發者而言，這也是選擇遠端 Mac 時必須先驗證的環境條件。

若希望先處理主機、模擬器和測試結果保存方式，可參考 遠端 Mac 的自動化測試環境說明。完成矩陣後，再依租期與使用時段評估 NUKCLOUD 的遠端 Mac 方案，不應在尚未定義測試證據前直接購買長期環境。

String Catalog 怎樣檢查遺漏的本地化字串？

不要只看編輯器中的翻譯完成率。先檢查 SwiftUI 與程式碼中的可本地化字串是否被提取，再用複數、插值與裝置變體建立最小測試樣本，最後在代表性語言中執行介面測試，並從建置後 Bundle 驗證資源是否真的被打包。

如何批量測試 iOS App 的不同語言和地區？

把支援語言、地區、書寫方向和核心裝置整理成矩陣，再以 Test Plan 分開設定 Application Language 與 Application Region。不要機械地測試所有組合，應先覆蓋購買、登入或創作等核心流程，並額外檢查日期、貨幣、數字及複數格式。

String Catalog 可以放進持續整合流程自動檢查嗎？

可以，但持續整合不應只執行一次建置。可將字串匯出、指定語言測試、UI 測試和 xcresult 保存拆成獨立任務，再使用 xcodebuild 執行與歸檔。這樣才能區分字串遺漏、介面失敗、資源未打包和測試主機故障。

遠端 Mac 如何執行多語言 UI 測試與截圖？

先確認遠端 Mac 能正常啟動模擬器及圖形登入工作階段，再以 Test Plan 指定語言和地區執行 UI 測試，將本地化截圖與 xcresult 一起保存。SSH 適合觸發命令與取回結果；若需要觀察介面，則應保留 VNC 或網頁控制台作為故障排查入口。

多語言 App 發布前需要檢查哪些本地化問題？

至少要分開檢查遺漏翻譯、文字截斷、錯誤地區格式、RTL 版面、複數與插值，以及 Archive 是否包含預期語言資源。翻譯狀態呈現完成不代表發布成功，最終決策應以實際建置產物和代表性語言的核心流程驗收為準。

以下條件列表可用於發版前判斷：

• 若測試只需要偶爾檢查少量語言，且本機已有可用的 Xcode、模擬器和儲存空間，則先在本機完成矩陣驗證。
• 若需要在提交或定時任務中重複執行，且本機無法長時間保留 Xcode 和測試結果，則選擇可持續連線的遠端 Mac。
• 若UI 測試依賴圖形登入，但遠端主機只能執行無頭 SSH 任務，則先回退到可提供圖形工作階段的環境，不要把失敗歸因於 String Catalog。
• 若舊版 strings、stringsdict 和新 Catalog 同時存在，則先分模組遷移並保存回退路徑，不要在發布前一次性替換所有資源。
• 若翻譯狀態正常但文字截斷、地區格式錯誤或 Archive 缺少資源，則停止發布，將本地化缺陷與測試基礎設施故障分開修復。
• 若代表性語言的核心流程、截圖、xcresult 和 Archive 資源均可追溯，則才把結果提升為發版門禁。

本流程的重點，是讓每個失敗都能回答「哪一類證據不成立」。字串提取失敗應回到程式碼或資源來源；UI 失敗應檢查語言、地區與裝置條件；Archive 失敗則應檢查 Target、Bundle 和建置設定。三者不能用同一個翻譯百分比代替。

如果目前方案只是開發者個人電腦，常見缺點是 Xcode、模擬器與測試結果無法長時間保留，主機重啟後也容易失去原有測試狀態；若改用不具 macOS 圖形環境的通用 CI，則可能無法穩定執行依賴模擬器和登入工作階段的 UI 測試。對需要持續驗收多語言 App 的團隊而言，NUKCLOUD 的遠端 Mac 能把 Xcode、模擬器與測試資料放在可重複連線的 macOS 環境中，較適合作為臨時測試主機或持續回歸節點；但若團隊需要長期高負載編譯、實體裝置介面或本地硬體連接，仍應先評估自購 Mac 是否更合適。

因此，完成語言地區矩陣後，若本地設備無法常駐 Xcode 和測試結果，可先從 NUKCLOUD 的遠端 Mac 使用說明確認連線與工作階段條件，再按測試週期選擇短期或較長租期。