Framework Translation od Apple: darmowy, działający na urządzeniu i lepszy, niż się wydaje

Framework Translation od Apple tłumaczy tekst na urządzeniu, za darmo, bez klucza API i bez żadnego wywołania sieciowego, gdy język jest już zainstalowany¹. Opiera się na modelach Core ML, jest dostarczany razem z systemem i daje aplikacji ten sam silnik tłumaczeń, z którego korzysta aplikacja Tłumacz. W przypadku funkcji wielojęzycznych, które kiedyś oznaczały rachunek za tłumaczenie w chmurze oraz pytanie o prywatność, koszt znów zaokrągla się do zera. I tak jak w przypadku frameworku Foundation Models, interesująca nie jest droga, na której wszystko idzie gładko — interesujące są niuanse, które dema pomijają: pobranie języka blokujące pierwsze tłumaczenie, symulator, który po cichu odmawia działania, oraz powierzchnia dostępna wyłącznie w SwiftUI, kształtująca sposób, w jaki framework się wdraża.

W skrócie

• Dwie powierzchnie, dwie wersje iOS. translationPresentation pokazuje wbudowany w Apple popover tłumaczenia (iOS 17.4+). TranslationSession, dostępny przez modyfikator translationTask, wykonuje tłumaczenie programistyczne we własnym interfejsie aplikacji (iOS 18+)².
• Tłumaczenie programistyczne jest async. Wewnątrz domknięcia translationTask otrzymuje się TranslationSession; wystarczy go wywołać, aby przetłumaczyć jeden ciąg znaków lub całą partię³.
• Tłumaczenie wsadowe jest pełnoprawnym mechanizmem. Można przetłumaczyć listę w jednym żądaniu i utrzymać dopasowanie każdego wyniku do jego danych wejściowych, zamiast iterować i czekać na każde tłumaczenie po kolei³.
• Interfejs tłumaczenia działa wyłącznie w SwiftUI i nie uruchamia się w symulatorze iOS. Obie te rzeczy łatwo odkryć dopiero w trudny sposób; warto projektować i testować z tą wiedzą⁴.
• Offline oznacza najpierw pobranie. Pierwsze tłumaczenie dla danej pary językowej pobiera pakiety, co jest realnym momentem w UX, który należy obsłużyć, a nie szczegółem⁵.
• Warte poznania połączenie: przetłumaczyć tekst użytkownika za pomocą Translation, następnie wnioskować nad nim za pomocą Foundation Models — i jednojęzyczna, działająca na urządzeniu funkcja agentowa zadziała w każdym języku, który urządzenie potrafi zainstalować.

Dwie powierzchnie: systemowy popover i własny interfejs

Framework daje dwa odrębne sposoby tłumaczenia, a wybór właściwego z nich to większość całej decyzji.

Lżejszym podejściem jest translationPresentation, dostępne od iOS 17.4. Dołącza się je do widoku, wiąże flagę isPresented i przekazuje tekst; gdy flaga przyjmie wartość prawda, system wysuwa nad zawartością swój własny popover tłumaczenia²:

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

Nie pisze się żadnej logiki tłumaczenia i nie widzi się wyniku; Apple jest właścicielem interfejsu oraz interakcji. Dla scenariusza „pozwól użytkownikowi przetłumaczyć ten fragment” to cała funkcja, a sięganie po cokolwiek cięższego jest zmarnowaną pracą.

Powierzchnią programistyczną jest TranslationSession, dostępna od iOS 18, do której dociera się przez modyfikator translationTask. Modyfikator uruchamia asynchroniczne domknięcie i przekazuje sesję, którą wywołuje się samodzielnie, dzięki czemu przetłumaczony tekst wraca do kodu i można go wyrenderować po swojemu²:

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

Podział jest klarowny. translationPresentation służy do pokazania użytkownikowi tłumaczenia w interfejsie Apple. TranslationSession służy do wprowadzenia przetłumaczonego tekstu do własnych danych i własnych widoków. Większość aplikacji, które robią coś więcej niż jednorazowe „przetłumacz to”, sięga po sesję.

Tłumaczenie wsadowe: tłumacz listę, nie pętlę

Szczegółem, który odróżnia płynną funkcję od nieporadnej, jest przetwarzanie wsadowe. Jeśli trzeba przetłumaczyć listę (wiadomości czatu, wpisy katalogu, zestaw etykiet), nie należy iterować i wywoływać await przy każdym tłumaczeniu po kolei. TranslationSession przyjmuje partię żądań i zwraca odpowiedzi, każdą dopasowaną do swojego żądania, w jednym przebiegu³:

.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
    }
}

Najważniejszą częścią jest clientIdentifier: wraca on w odpowiedzi, dzięki czemu można dopasować każde tłumaczenie do wiersza, do którego należy, bez polegania na kolejności. Przetwarzanie wsadowe pozwala też frameworkowi efektywnie zaplanować pracę, zamiast ponosić narzut wywołań przy każdym przejściu pętli. Przy czymkolwiek poza pojedynczym ciągiem znaków — należy tłumaczyć wsadowo.

Rzeczywistość offline, której nikt nie pokazuje na zrzutach ekranu

Oto niuans, który zamienia czyste demo w zgłoszenie do pomocy technicznej. Tłumaczenie działa na urządzeniu, ale język musi najpierw na tym urządzeniu się znaleźć. Za pierwszym razem, gdy aplikacja tłumaczy daną parę źródło-cel, system pobiera pakiety językowe, a to pobieranie wymaga czasu i połączenia z siecią⁵. Jeśli uruchomi się tłumaczenie i wyrenderuje wynik bez żadnej obsługi pobierania, funkcja przy pierwszym użyciu sprawia wrażenie zawieszonej dla każdego nowego języka.

Należy obsłużyć to świadomie. Framework pozwala sprawdzić dostępność języka i przygotować (pobrać) parę z wyprzedzeniem, zanim będzie potrzebna, dzięki czemu można pokazać stan „przygotowywanie tłumaczenia” albo pobrać dane w spokojniejszym momencie, zamiast utykać w środku interakcji⁵. Model myślowy: traktować pierwsze tłumaczenie pary językowej jak jednorazowe pobranie zasobu, bo właśnie tym ono jest. Jeśli zaprojektuje się UX wokół istnienia tego pobierania, korzyść z trybu offline i z darmowości się ujawnia; jeśli się je zignoruje, korzyść kryje się za zawieszeniem.

Jeszcze dwa fakty, które kosztują pół dnia, jeśli pozna się je za późno. Powierzchnie interfejsu tłumaczenia są modyfikatorami SwiftUI, więc ekran w UIKit hostuje widok SwiftUI (poprzez UIHostingController), aby do nich dotrzeć — choć TranslationSession można też skonstruować bezpośrednio do pracy bez interfejsu⁴. Ponadto framework nie uruchamia się w symulatorze iOS ani iPadOS; tłumaczenie testuje się na fizycznym urządzeniu⁴. Żaden z tych faktów nie jest głośno udokumentowany, a na oba łatwo wpaść głową naprzód.

Łączenie tłumaczenia z Foundation Models

Synteza warta zapamiętania wiąże ten framework z resztą stosu działającego na urządzeniu. Większość pracy językowej na urządzeniu zakłada, że dane wejściowe są w języku, który logika aplikacji oraz model systemowy dobrze obsługują. Prawdziwi użytkownicy nie współpracują. Framework Translation domyka tę lukę: tłumaczy dane wejściowe użytkownika na język, w którym funkcja wnioskuje, uruchamia pracę Foundation Models na przetłumaczonym tekście, a następnie tłumaczy wynik z powrotem.

Kształt tego rozwiązania to klamra: przetłumacz na wejściu, wnioskuj, przetłumacz na wyjściu.

// 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

Funkcja segregująca zgłoszenia do pomocy technicznej, narzędzie streszczające notatki, ekstraktor intencji: każde z nich można napisać raz, jednojęzycznie, i sprawić, że zadziała w każdym języku, który urządzenie potrafi zainstalować — obejmując wywołanie Foundation Models klamrą Translation. Oba kierunki korzystają z dwóch konfiguracji sesji (z języka użytkownika na angielski, a potem z angielskiego z powrotem), ponieważ sesja jest skonfigurowana dla jednej pary językowej. Obie warstwy działają na urządzeniu, obie są darmowe, a nic nie opuszcza telefonu, więc wersja wielojęzyczna nie kosztuje ani prywatności, ani rachunku za chmurę ponad to, co kosztowała wersja jednojęzyczna. To właśnie ta kompozycja (przetłumacz na wejściu, wnioskuj, przetłumacz na wyjściu) jest wzorcem, który czyni małą funkcję działającą na urządzeniu naprawdę globalną — i jest możliwa wyłącznie dlatego, że obie połowy działają lokalnie i za darmo.

Kiedy go nie używać

Tłumaczenie na urządzeniu jest darmowe i prywatne, co czyni je właściwym domyślnym wyborem do tłumaczenia w obrębie aplikacji. Jest jednak niewłaściwym narzędziem w kilku uczciwie przyznanych przypadkach.

• Potrzebna jest najwyższa możliwa jakość tłumaczenia lub najszersze pokrycie językowe. Modele na urządzeniu są dobre, lecz nie najlepsze z dostępnych, a zbiór języków możliwych do zainstalowania jest skończony. Do tłumaczeń wysokiej stawki (prawnych, medycznych, publikowanych treści) dedykowana usługa tłumaczenia w chmurze wciąż wygrywa pod względem jakości i zakresu.
• Nie da się tolerować pobierania przy pierwszym użyciu. W przypadku funkcji, która musi działać natychmiast po pierwszym uruchomieniu bez sieci, wymóg pobrania może sam w sobie zdyskwalifikować tłumaczenie na urządzeniu — chyba że dane pobierze się wcześniej, podczas onboardingu.
• Aplikacja jest w UIKit bez miejsca na host SwiftUI albo przepływ musi działać w symulatorze (na przykład zautomatyzowany test UI). Ograniczenia „wyłącznie SwiftUI” i „brak symulatora” są twarde, a nie orientacyjne.

Framework jest jednym z cichszych zwycięstw w zestawie narzędzi działających na urządzeniu: naprawdę darmowym, prywatnym silnikiem tłumaczeń, który większość aplikacji mogłaby wdrożyć w jedno popołudnie. Wymagana umiejętność jest tą samą, którą nagradza reszta tego stosu. Trzeba wiedzieć, która powierzchnia pasuje (systemowy popover czy własna sesja), tłumaczyć wsadowo, gdy ma się listę, i projektować z myślą o pobieraniu, zamiast udawać, że go nie ma. Jeśli się to zrobi, tłumaczenie przestaje być zależnością od chmury, a staje się lokalną zdolnością, którą komponuje się z wszystkim innym, co urządzenie robi za darmo.

FAQ

Czy framework Translation od Apple jest darmowy i działa na urządzeniu?

Tak. Translation działa na urządzeniu i jest darmowy, a nic nie opuszcza telefonu, co czyni go właściwym domyślnym wyborem do tłumaczenia w obrębie aplikacji. Kompromis polega na tym, że jakość tłumaczenia i pokrycie językowe są dobre, a nie najlepsze w swojej klasie, więc praca wysokiej stawki może wciąż wymagać usługi w chmurze.

Dlaczego pierwsze tłumaczenie zawiesza się lub wymaga pobrania?

Tłumaczenie działa na urządzeniu, ale para językowa musi najpierw na tym urządzeniu się znaleźć. Za pierwszym razem, gdy tłumaczy się daną parę źródło-cel, system pobiera pakiety językowe, co wymaga czasu i połączenia z siecią⁵. Należy sprawdzić dostępność i przygotować (pobrać z wyprzedzeniem) parę przed momentem, w którym jest potrzebna, aby móc pokazać stan „przygotowywanie” zamiast utykać w środku interakcji.

Jakie są dwa sposoby dodania tłumaczenia do aplikacji?

Systemowy popover przez modyfikator prezentacji SwiftUI albo własny interfejs napędzany przez TranslationSession skonstruowany bezpośrednio do pracy bez interfejsu⁴. Ponieważ te powierzchnie są modyfikatorami SwiftUI, ekran w UIKit dociera do nich, hostując widok SwiftUI poprzez UIHostingController.

Czy framework Translation od Apple działa w symulatorze?

Nie. Framework nie uruchamia się w symulatorze iOS ani iPadOS, więc tłumaczenie testuje się na fizycznym urządzeniu⁴. To ograniczenie jest twarde, a nie orientacyjne, i wyklucza ono również tłumaczenie wewnątrz zautomatyzowanych testów UI w symulatorze.

Jak sprawić, by funkcja oparta na Foundation Models działała w każdym języku?

Należy ująć ją w klamrę: przetłumaczyć dane wejściowe użytkownika na język, w którym wnioskuje logika, uruchomić pracę Foundation Models na przetłumaczonym tekście, a następnie przetłumaczyć wynik z powrotem. Oba kierunki korzystają z dwóch konfiguracji TranslationSession (z języka użytkownika na angielski, a potem z angielskiego z powrotem), ponieważ sesja jest skonfigurowana dla jednej pary językowej. Obie warstwy działają na urządzeniu i są darmowe, więc wersja wielojęzyczna nie kosztuje ani prywatności, ani rachunku za chmurę.

Kiedy nie należy używać tłumaczenia na urządzeniu?

Gdy potrzebna jest najwyższa możliwa jakość lub najszersze pokrycie językowe (treści prawne, medyczne, publikowane), gdy funkcja musi działać natychmiast po pierwszym uruchomieniu bez sieci, a nie można pobrać danych z wyprzedzeniem, albo gdy przepływ musi działać w symulatorze lub jest w UIKit bez miejsca na host SwiftUI. Te ostatnie ograniczenia są twardymi limitami.