Apple 的 Translation 框架：免費、裝置端執行，而且比表面上更有深度

Apple 的 Translation 框架在裝置上翻譯文字，完全免費，不需要 API 金鑰；只要語言已安裝完成，翻譯過程也不會發出任何網路請求¹。它建構在 Core ML 模型之上，隨系統一併提供，讓 App 能使用與「翻譯」App 相同的翻譯引擎。過去要做多語系功能，意謂著一筆雲端翻譯帳單加上一道隱私難題；如今這筆成本再次趨近於零。而且如同 Foundation Models 框架⁶一樣，真正有意思的並不是一路順遂的那條路徑，而是各種示範都略過的邊界：卡住第一次翻譯的語言下載、悄悄拒絕運作的模擬器，以及僅限 SwiftUI 的介面如何左右您的採用方式。

重點摘要

• 兩種介面，兩個 iOS 版本。 translationPresentation 會顯示 Apple 內建的翻譯彈出視窗（iOS 17.4 以上）。TranslationSession 則透過 translationTask 修飾器取得，可在自己的 UI 中進行程式化翻譯（iOS 18 以上）²。
• 程式化翻譯是 async 的。 在 translationTask 閉包內會拿到一個 TranslationSession，呼叫它即可翻譯單一字串或一整批文字³。
• 批次翻譯是一等公民。 一次請求就能翻完整份清單，而且每筆結果都對得回原本的輸入，不必用迴圈逐一等待³。
• 翻譯 UI 僅限 SwiftUI，而且無法在 iOS 模擬器上執行。 這兩點都很容易踩坑才學到；設計與測試時請先納入考量⁴。
• 離線的前提是先下載。 某個語言配對的第一次翻譯會下載語言套件，這是一個必須妥善處理的真實 UX 環節，而非枝微末節⁵。
• 值得記住的組合技：先用 Translation 翻譯使用者輸入，再交給 Foundation Models 推理，如此一來一項單語的裝置端代理功能，就能在裝置可安裝的任何語言中運作。

兩種介面：系統彈出視窗與自訂 UI

這套框架提供兩種截然不同的翻譯方式，而選對其中一種，決策就完成了大半。

輕巧的做法是 translationPresentation，自 iOS 17.4 起可用。把它掛在某個視圖上，綁定一個 isPresented 旗標並傳入文字；旗標轉為 true 時，系統就會在您的內容上方滑出自己的翻譯彈出視窗²：

.translationPresentation(isPresented: $showTranslation, text: selectedText)

您不必撰寫任何翻譯邏輯，也看不到翻譯結果；UI 與互動全由 Apple 掌管。若需求只是「讓使用者翻譯這段文字」，這就是完整的功能了，動用更重的手段純屬多餘。

程式化的介面是 TranslationSession，自 iOS 18 起可用，透過 translationTask 修飾器取得。這個修飾器會執行一個非同步閉包，並交給您一個可自行呼叫的翻譯會話，翻譯後的文字會回到您的程式碼中，再由您決定如何呈現²：

.translationTask(configuration) { session in
    let response = try await session.translate("Good morning")
    await MainActor.run { translated = response.targetText }
}

分工相當清楚。translationPresentation 負責在 Apple 的 UI 中把翻譯呈現給使用者。TranslationSession 則負責把翻譯後的文字送進您的資料與視圖。只要 App 的需求超過一次性的「翻譯這段」，多半都會選擇這個翻譯會話。

批次翻譯：翻整份清單，別用迴圈

決定一項功能流暢或卡頓的關鍵細節，在於批次處理。若需要翻譯一份清單（聊天訊息、目錄項目、一組標籤），別用迴圈逐一 await 每次翻譯。TranslationSession 可以接收一批請求，一次回傳所有回應，每筆都與各自的請求對應³：

.translationTask(configuration) { session in
    let requests = items.map { TranslationSession.Request(sourceText: $0.text, clientIdentifier: $0.id) }
    for try await response in session.translate(batch: requests) {
        store[response.clientIdentifier] = response.targetText
    }
}

關鍵在於 clientIdentifier：它會隨回應一起回來，讓您不必依賴順序就能把每筆翻譯對回所屬的那一列。批次處理也讓框架能有效率地安排工作，不必在迴圈中一再付出單次呼叫的額外開銷。只要不只一個字串，就用批次。

沒人截圖的離線真相

以下這個邊界，正是讓乾淨的示範變成客訴單的地方。翻譯確實在裝置上執行，但語言必須先安裝到裝置上。App 第一次翻譯某個來源到目標的語言配對時，系統會下載語言套件，而這段下載需要時間與網路連線⁵。如果您直接發出翻譯請求並呈現結果，卻完全沒有處理下載環節，那麼每遇到一個新語言，功能在首次使用時看起來就像當掉了。

請刻意處理它。框架允許您檢查語言可用性，並在真正需要之前先行準備（下載）一組配對，這樣就能顯示「正在準備翻譯」的狀態，或挑在比較從容的時機預先下載，而不是在互動途中卡住⁵。心智模型是：把某個語言配對的第一次翻譯，當成一次性的資源下載，因為它本來就是。把 UX 建立在「下載確實存在」的前提上，離線又免費的好處就能真正兌現；忽略它，這份好處就會被一次卡頓給掩蓋。

還有兩件事，太晚知道會白白耗掉一個下午。翻譯的 UI 介面是 SwiftUI 修飾器，因此 UIKit 畫面必須寄宿一個 SwiftUI 視圖（透過 UIHostingController）才能使用；不過若不需要 UI，TranslationSession 也可以直接建構⁴。另外，這套框架無法在 iOS 或 iPadOS 模擬器上執行，翻譯功能只能在實機上測試⁴。這兩點文件都沒有大聲說明，卻都很容易一頭撞上。

讓翻譯與 Foundation Models 搭配

真正值得帶走的整合觀點，把這套框架與裝置端技術堆疊的其餘部分串了起來。多數裝置端的語言處理，都預設輸入語言是您的邏輯與系統模型擅長的那一種。但真實使用者不會這麼配合。Translation 框架補上了這道缺口：先把使用者輸入翻成您功能所推理的語言，對翻譯後的文字執行 Foundation Models 的工作，最後再把結果翻回去。

這個形狀就像一組括號：翻進來、推理、翻回去。

// 1. translate the user's text into English (session configured for their language -> en)
let english = try await inboundSession.translate(userText).targetText
// 2. reason on-device, monolingually, in English
let summary = try await LanguageModelSession()
    .respond(to: "Summarize in one line: \(english)").content
// 3. translate the result back (a session configured for en -> their language)
let localized = try await outboundSession.translate(summary).targetText

客服分流功能、筆記摘要器、意圖擷取器：每一項都只需以單一語言寫一次，再用 Translation 把 Foundation Models 的呼叫包起來，就能在裝置可安裝的任何語言中運作。兩個方向需要兩份會話設定（使用者語言轉英文，再由英文轉回），因為一份會話只對應一組語言配對。兩層都在裝置上執行，兩層都免費，任何資料都不離開手機，所以多語版本相較於單語版本，既不多付隱私成本，也不多付雲端帳單。這種組合方式（翻進來、推理、翻回去），正是讓一項小小的裝置端功能真正走向全球的模式，而它之所以可行，只因為兩個環節都在本地免費執行。

什麼時候不該用它

裝置端翻譯免費又保護隱私，這讓它成為 App 內翻譯的正確預設選項。但在幾種情況下，它確實是錯的工具。

• 您需要最高的翻譯品質或最廣的語言覆蓋。 裝置端模型表現不錯，但稱不上業界最佳，可安裝的語言集合也是有限的。高風險的翻譯（法律、醫療、對外發布的內容）在品質與廣度上，仍是專門的雲端翻譯服務勝出。
• 您無法接受首次使用的下載。 若某項功能必須在首次啟動、沒有網路的情況下立即可用，那麼除非能在導覽流程中預先下載，否則單是下載這項要求就足以讓裝置端翻譯出局。
• 您的 App 是 UIKit 且沒有空間寄宿 SwiftUI，或流程必須在模擬器中執行（例如自動化 UI 測試）。僅限 SwiftUI 與不支援模擬器這兩項限制是硬性的，不是建議事項。

在裝置端工具箱裡，這套框架屬於比較低調的勝利：一個貨真價實免費且保護隱私的翻譯引擎，多數 App 花一個下午就能導入。所需的功力，和這整套技術堆疊獎勵的功力如出一轍。分清楚哪種介面適合（系統彈出視窗或自己的翻譯會話），有清單時就用批次，並且為下載預作設計，而不是假裝它不存在。做到這些，翻譯就不再是一項雲端相依，而成為一項可以與裝置免費提供的其他能力自由組合的本地能力。

常見問題

Apple 的 Translation 框架是免費且在裝置上執行的嗎？

是的。翻譯在裝置上執行且免費，任何資料都不離開手機，因此它是 App 內翻譯的正確預設選項。代價在於翻譯品質與語言覆蓋只能算好，而非頂尖，所以高風險的工作可能仍需要雲端服務。

為什麼第一次翻譯會卡住或需要下載？

翻譯確實在裝置上執行，但語言配對必須先安裝到裝置上。第一次翻譯某個來源到目標的配對時，系統會下載語言套件，這需要時間與網路連線⁵。請先檢查可用性，並在真正需要之前準備（預先下載）該配對，這樣就能顯示「正在準備」的狀態，而不是在互動途中卡住。

為 App 加入翻譯有哪兩種方式？

一是透過 SwiftUI 呈現修飾器叫出系統彈出視窗，二是用直接建構的 TranslationSession 驅動自己的 UI，適合不需要 UI 的情境⁴。由於這些介面都是 SwiftUI 修飾器，UIKit 畫面必須透過 UIHostingController 寄宿一個 SwiftUI 視圖才能使用。

Apple 的 Translation 框架能在模擬器上運作嗎？

不行。這套框架無法在 iOS 或 iPadOS 模擬器上執行，翻譯功能只能在實機上測試⁴。這項限制是硬性的，不是建議事項，也因此自動化的模擬器 UI 測試無法涵蓋翻譯。

我要怎麼讓 Foundation Models 功能支援任何語言？

用括號包起來：先把使用者輸入翻成您的邏輯所推理的語言，對翻譯後的文字執行 Foundation Models 的工作，再把結果翻回去。兩個方向需要兩份 TranslationSession 設定（使用者語言轉英文，再由英文轉回），因為一份會話只對應一組語言配對。兩層都在裝置上執行且免費，所以多語版本既不多付隱私成本，也不多付雲端帳單。

什麼時候不該使用裝置端翻譯？

當您需要最高品質或最廣的語言覆蓋時（法律、醫療、對外發布的內容）；當某項功能必須在首次啟動、沒有網路的情況下立即可用，而您又無法預先下載時；或當流程必須在模擬器中執行，又或者 App 是 UIKit 而沒有空間寄宿 SwiftUI 時。後面這幾項限制是硬性的上限。