So lokalisieren Sie Ihre iOS-App: Leitfaden zur SwiftUI-Internationalisierung

Bereiten Sie Ihre Xcode-App vor, übersetzen Sie .xcstrings mit KI und laden Sie anschließend Screenshots hoch, damit die PTC (Private Translation Cloud) die gerenderte iOS-App in jeder Sprache prüft. Dieser Leitfaden führt Sie durch den gesamten Workflow mit SwiftUI und Xcode 15+ String Catalogs, dem modernen, von Apple empfohlenen Weg. Für eine plattformübergreifende Service-Übersicht, die sowohl iOS als auch Android abdeckt, lesen Sie iOS- und Android-Apps mit KI übersetzen.

Teil 1: Wie die iOS-Lokalisierung funktioniert

Die iOS-Lokalisierung ist der Prozess der Anpassung von Text, Formatierung und Assets Ihrer App, um mehrere Sprachen und Regionen zu unterstützen. Mit den in Xcode 15 eingeführten String Catalogs ist der Workflow wesentlich einfacher als beim alten Ansatz mit .strings / .stringsdict.

Internationalisierung vs. Lokalisierung

Dies sind zwei separate Phasen, und sie müssen in dieser Reihenfolge stattfinden:

• Internationalisierung (i18n) ist die technische Grundlage. Sie strukturieren Ihren Code so, dass Text, Bilder und Formatierungen je nach Locale variieren können, ohne dass Codeänderungen erforderlich sind. Dies geschieht einmalig, idealerweise vor Ihrer ersten Veröffentlichung.
• Lokalisierung (l10n) ist die fortlaufende Arbeit, die danach folgt. Das Schreiben von Übersetzungen, das Anpassen von Layouts und das Bereitstellen Locale-spezifischer Assets für jede neue Sprache.

Der häufigste Fehler besteht darin, die Lokalisierung als Aufgabe nach dem Launch zu behandeln, nur um dann festzustellen, dass die Codebasis nicht bereit ist. Nachträglich hardcodierte Strings, Layouts mit fester Richtung und Formatierer ohne Locale-Unterstützung in einer bestehenden App zu reparieren, dauert viel länger, als die Lokalisierung von Anfang an bei der Entwicklung zu berücksichtigen.

Wie Xcode 15+ Localizable.xcstrings als Single Source of Truth nutzt

Apples Lokalisierungsmodell in Xcode 15+ zentriert sich auf eine einzige Datei pro Target: Localizable.xcstrings. Diese Datei ist ein JSON-formatierter String Catalog, der Ihre Ausgangssprache sowie jede Übersetzung enthält, einschließlich Pluralvarianten, gerätespezifischer Varianten und Ersetzungen.

Xcode extrahiert automatisch lokalisierbare Strings aus Ihrem SwiftUI-Code (jedes Text("..."), Label("...", systemImage:), Button("...") und jede String-Interpolation, die LocalizedStringKey verwendet). Wenn Sie den Build Ihrer App ausführen, wird Localizable.xcstrings mit jedem extrahierten Quellstring gefüllt.

Apple unterstützt mehrere Formate. .strings (klassisches Key-Value-Format), .stringsdict (klassische Pluralformen) und .xcstrings (modern). Neue Projekte sollten mit .xcstrings beginnen. Bestehende .strings-basierte Projekte können über File > New > File > String Catalog und die Importoption von Xcode migriert werden. Apples offizielle Lokalisierungsdokumentation behandelt den gesamten Hintergrund.

Teil 2: Richten Sie Ihr Xcode-Projekt für die Lokalisierung ein

Schritt 1: Lokalisierung aktivieren. Öffnen Sie Ihr Projekt in Xcode und wählen Sie die Projektdatei im Navigator aus. Scrollen Sie unter dem Tab Info zu Localizations. Englisch ist bereits als Basissprache aufgeführt. Klicken Sie auf +, um jede Zielsprache (Spanisch, Französisch, Arabisch usw.) hinzuzufügen.

Schritt 2: Einen String Catalog erstellen. Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie New File from Template. Suchen Sie nach String Catalog und fügen Sie ihn hinzu. Behalten Sie den Standardnamen Localizable.xcstrings bei. Erstellen Sie den Build des Projekts einmal mit Cmd+B. Xcode scannt Ihren Code, findet jeden lokalisierbaren String und füllt den Katalog automatisch.

Schritt 3: Strings für die Lokalisierung markieren. In SwiftUI wird jeder literale String, der an Text(_:), Label, Button-Aktionslabels, Navigationstitel usw. übergeben wird, automatisch als LocalizedStringKey behandelt:

import SwiftUI

struct WelcomeView: View {
    let userName: String
    let unreadCount: Int

    var body: some View {
        VStack {
            Text("Welcome, \(userName)!")
            Text("You have \(unreadCount) unread messages")
            Button("Get Started") {
                // action
            }
        }
    }
}

Es gibt zwei Muster, bei denen Xcode Strings nicht automatisch extrahieren kann. Beide schlagen stillschweigend fehl:

Tipp 1: Vermeiden Sie die Übergabe von Variablen an Text. Wenn Sie eine Variable anstelle eines String-Literals an eine Text-View übergeben, behandelt SwiftUI diese als einfachen String und überspringt die Suche im Katalog vollständig:

// NOT localized - SwiftUI treats the variable as a plain String
let title = "welcome_title"
Text(title)

// Localized correctly
Text(LocalizedStringKey(title))

Tipp 2: Verwenden Sie String(localized:) außerhalb von Views. Für Strings, die Sie in einem View-Model, einer Helper-Funktion oder irgendwo außerhalb einer SwiftUI-View lokalisieren müssen, verwenden Sie String(localized:) anstelle eines einfachen Strings:

let errorMessage = String(localized: "error_generic")

Schritt 4: Plural- und Gerätevarianten hinzufügen. Strings benötigen je nach Kontext oft unterschiedliche Formen.

Für die Pluralisierung beginnen Sie mit dem String in Ihrer SwiftUI-View:

Text("\(bookCount) books on your shelf")

Öffnen Sie den String Catalog, klicken Sie mit der rechten Maustaste auf den Key und wählen Sie Vary by Plural. Xcode generiert die Pluralkategorien automatisch und füllt sie vorab mit dem Quellstring. Für Englisch sehen Sie One und Other. Korrigieren Sie das Feld One zu "%lld book on your shelf". Markieren Sie beide als geprüft.

Wenn Sie den Katalog später an die PTC senden, wird die Pluralstruktur mit der Datei übertragen. Für Arabisch generiert die PTC Übersetzungen für alle sechs Pluralkategorien (zero, one, two, few, many, other), da die arabische Grammatik alle sechs erfordert. Spanisch benötigt zwei, genau wie Englisch.

Für Gerätevarianten (z. B. „Tap to continue“ auf dem iPhone vs. „Click to continue“ auf dem Mac) klicken Sie mit der rechten Maustaste auf den Key und wählen Sie Vary by Device. Fügen Sie die Geräte hinzu, die Sie anpassen möchten, und geben Sie den entsprechenden String für jedes Gerät ein. iOS liefert die Version aus, die zur Laufzeit mit dem aktuellen Gerät übereinstimmt.

Teil 3: Übersetzen Sie Ihre .xcstrings mit der PTC

Bei kleinen Projekten könnten Sie jede Sprachspalte im Katalog öffnen und Übersetzungen direkt eintippen. Wenn Ihre App wächst, wird dies bei Hunderten von Keys und Dutzenden von Sprachen unüberschaubar. Die PTC übernimmt das Hochladen, Übersetzen und Synchronisieren.

Schritt 1: Exportieren Sie Ihren String Catalog aus Xcode. Gehen Sie zu Product > Export Localizations. Xcode verpackt Ihren String Catalog in eine .xcloc-Datei pro Zielsprache. Für die PTC benötigen Sie nur die Datei .xcstrings innerhalb des .xcloc-Pakets. Klicken Sie im Finder mit der rechten Maustaste auf den exportierten .xcloc-Ordner und wählen Sie Show Package Contents, um Localizable.xcstrings zu finden.

Wenn Sie die Benachrichtigung „Unable to build project for localization string extraction“ sehen, verwendet Ihr Projekt reine iOS-APIs, die Xcode während der String-Extraktion nicht mit seinem internen macOS-SDK kompilieren kann. Lösung: Wählen Sie das Projekt-Target unter TARGETS aus, gehen Sie zu Build Settings, suchen Sie nach „Use Compiler to Extract Swift Strings“ und setzen Sie dies auf No. Exportieren Sie dann erneut.

Schritt 2: Melden Sie sich bei der PTC an. Die Testphase deckt 20.000 Wörter in 2 Sprachen ab, was ausreicht, um die meisten Apps zu lokalisieren. Nach der Testphase läuft die PTC über nutzungsbasierte Bezahlung (Pay-As-You-Go). Kein Abonnement, die ersten 500 Wörter jeden Monat sind kostenlos.

Schritt 3: Richten Sie Ihr Projekt ein und übersetzen Sie. Ziehen Sie Localizable.xcstrings in die PTC. Belassen Sie den Ausgabedateinamen bei Localizable.xcstrings. Xcode erwartet genau diesen Namen beim Auflösen lokalisierter Strings. Wählen Sie Ihre Zielsprachen aus.

Die PTC generiert automatisch eine Beschreibung Ihrer App aus der hochgeladenen Datei. Überprüfen Sie diese und bearbeiten Sie sie bei Bedarf. Wenn Sie bereits vorhandene Übersetzungsdateien haben, laden Sie diese hoch, damit die PTC Ihren Stil übernehmen kann. Andernfalls übersetzen Sie von Grund auf. Fügen Sie Glossar-Begriffe hinzu. Die PTC fügt Ihren App-Namen automatisch hinzu. Fügen Sie jegliche markenspezifische Terminologie hinzu, die auf eine bestimmte Weise oder gar nicht übersetzt werden soll. Klicken Sie auf Start Translation.

Schritt 4: Prüfen und herunterladen. Sobald die Übersetzung abgeschlossen ist, zeigt der Tab Translations jeden Quellstring neben seiner Übersetzung. Jeder, den Sie dem Projekt hinzufügen, kann Übersetzungen direkt bearbeiten. Wenn etwas nicht stimmt, melden Sie ein Problem mit einer bestimmten Übersetzung und fordern Sie eine kostenlose KI-Neuübersetzung an. Die PTC lernt aus dem Feedback und wendet es auf zukünftige Strings im selben Projekt an.

Wenn ein übersetzter String seine Längenbegrenzung überschreitet, wird er hervorgehoben. Sie haben drei Optionen. Akzeptieren Sie die längere Übersetzung, wenn Ihre UI sie aufnehmen kann. Fordern Sie eine Neuübersetzung an, die in das aktuelle Limit passt. Passen Sie das Limit unter Einstellungen > Übersetzungslängen an.

Teil 4: Integrieren Sie übersetzte .xcstrings in Ihr Xcode-Projekt

Sie haben drei Optionen.

Option 1: Dateien manuell von der PTC herunterladen. Gehen Sie zum Tab Resource Files und laden Sie die ZIP-Datei herunter. Sie enthält eine einzelne Localizable.xcstrings-Datei mit Ihren englischen Quellstrings und allen Übersetzungen. Schließen Sie Xcode, ersetzen Sie die vorhandene Localizable.xcstrings in Ihrem Projektordner durch die von der PTC und starten Sie Xcode dann neu. Ihre Übersetzungen erscheinen im String Catalog mit einem Häkchen neben jeder vollständig übersetzten Sprache.

Option 2: Mit Git integrieren. Wenn Ihr Projekt auf GitHub, GitLab oder Bitbucket liegt, verbinden Sie die PTC direkt. Die Git-Integration ist eine Pro-Funktion. Aktivieren Sie Pay-As-You-Go, um darauf zuzugreifen. Gehen Sie in Ihrem PTC-Dashboard zu Einstellungen > Merge Requests und klicken Sie auf Add Git Integration. Geben Sie Ihre Repository-URL an, gewähren Sie der PTC Zugriff und wählen Sie Ihren Branch und Ihre Quelldateien aus. Die PTC sendet einen Merge Request mit den Übersetzungen.

Option 3: Die API nutzen. Die API der PTC gibt Ihnen die volle Kontrolle darüber, wann und wie Übersetzungen in Ihre Build-Pipeline gezogen werden. Wenn Pay-As-You-Go aktiviert ist, gehen Sie zu Einstellungen > API-Tokens verwalten, klicken Sie auf Add access token und konsultieren Sie dann die PTC-API-Referenz für die Endpunkte.

Ein In-App-Sprachumschalter (einige Apps benötigen dies) kann das System-Locale pro View über die SwiftUI-Umgebung überschreiben:

import SwiftUI

@MainActor
class LocaleManager: ObservableObject {
    @Published var currentLocale: Locale = .current

    func setLocale(_ identifier: String) {
        currentLocale = Locale(identifier: identifier)
        UserDefaults.standard.set([identifier], forKey: "AppleLanguages")
    }
}

struct LanguageSettingsView: View {
    @EnvironmentObject var localeManager: LocaleManager

    var body: some View {
        List {
            Button("English") { localeManager.setLocale("en") }
            Button("Español") { localeManager.setLocale("es") }
            Button("Français") { localeManager.setLocale("fr") }
        }
        .environment(\.locale, localeManager.currentLocale)
    }
}

Das Ändern von AppleLanguages zur Laufzeit erfordert für einige System-Strings einen Neustart der App. Das Überschreiben der SwiftUI-Umgebung wird für Views innerhalb dieses Scopes sofort wirksam.

Teil 5: Testen Sie Ihre lokalisierte iOS-App

Mit der Scheme-Spracheinstellung testen. Der schnellste Weg, eine bestimmte Sprache zu testen, führt über Ihr Xcode-Scheme. Gehen Sie zu Product > Scheme > Edit Scheme, klicken Sie auf den Tab Options, ändern Sie App Language und App Region auf das gewünschte Locale und führen Sie die App mit Cmd+R aus. Das funktioniert für die meisten Sprachen gut. Sie sollten dasselbe Layout und Design wie im Englischen sehen, wobei der gesamte Text ausgetauscht wurde.

Arabisch und andere Rechts-nach-links-Sprachen testen. Die Scheme-Spracheinstellung kann im Simulator für RTL-Sprachen unzuverlässig sein. Verwenden Sie die eigenen Spracheinstellungen des Simulators:

1. Führen Sie die App mit Cmd+R aus, um den Simulator zu öffnen.
2. Drücken Sie Cmd+Home, um zum Startbildschirm zu gelangen.
3. Öffnen Sie Einstellungen > Allgemein > Sprache & Region.
4. Tippen Sie auf Sprache hinzufügen, wählen Sie Arabisch aus und legen Sie es als primäre Sprache fest.
5. Der Simulator startet neu. Öffnen Sie Ihre App vom Startbildschirm aus.

Überprüfen Sie, ob der Text auf Arabisch erscheint und ob das Layout korrekt gespiegelt wird, wobei Navigationstitel und Inhalt rechtsbündig ausgerichtet sind. Für Vorschautests, ohne sich auf eine Sprache festzulegen, ist Edit Scheme > Options > Application Language > Right-to-Left Pseudolanguage eine schnellere Überprüfung. Für Tests der Textexpansion verwenden Sie Double-Length Pseudolanguage, um zu sehen, wie Layouts mit 30–40 % längeren Strings umgehen, bevor Sie sich auf eine Zielsprache festlegen.

Best Practices für die iOS-Lokalisierung

• Überprüfen Sie Ihre UI auf unterschiedliche Textlängen. Deutsch ist ca. 30 % länger als Englisch. Französisch und Spanisch ca. 20 %. Nutzen Sie das flexible Layoutsystem von SwiftUI, lassen Sie Labels natürlich wachsen und umbrechen, vermeiden Sie Beschränkungen mit fester Breite für Textelemente und testen Sie während der Entwicklung in einigen verschiedenen Sprachen.
• Überspringen Sie keine Pluralvarianten. Russisch hat drei Pluralkategorien, Arabisch sechs, Japanisch keine. String Catalogs übernehmen dies, wenn Sie die Sprache hinzufügen. Stellen Sie sicher, dass alle generierten Felder ausgefüllt sind, bevor Sie veröffentlichen.
• Lokalisieren Sie Bilder und Assets. Bilder mit Text oder kulturspezifischen visuellen Elementen benötigen lokalisierte Varianten. Wählen Sie in Assets.xcassets das Bild aus und klicken Sie im Attributes Inspector auf Localize. Wählen Sie die Sprachen aus, für die Sie Varianten wünschen, und ersetzen Sie jede durch die entsprechende Version. iOS liefert das richtige Bild basierend auf dem Locale des Benutzers aus.
• Halten Sie Ihre Basissprache vollständig. Ihre Basissprache (meistens Englisch) ist der Fallback für jede fehlende Übersetzung. Eine unvollständige Basis kann selbst in ansonsten vollständig übersetzten Sprachen zu unerwarteten Fallbacks führen. Xcode markiert fehlende oder veraltete Basis-Strings während des Builds.
• Lokalisieren Sie Ihren App-Store-Eintrag. Eine lokalisierte App mit einem rein englischen Eintrag verliert Nutzer bei der Entdeckung. In App Store Connect können Sie App-Namen, Untertitel, Beschreibung und Keywords pro Region lokalisieren. Keywords sind besonders wertvoll. Apple indexiert Keywords aus mehreren Locales pro Region, was Ihr Keyword-Zeichenbudget effektiv über die standardmäßigen 100 Zeichen hinaus vervielfacht. Nutzen Sie die PTC-Funktion Paste to Translate für App-Store-Inhalte.
• Verwenden Sie Locale-fähige Formatierer. Date.FormatStyle, Decimal.FormatStyle und Formatierer, die Locale berücksichtigen. Hardcodieren Sie niemals "$" oder "MM/DD/YYYY".
• Verwenden Sie %lld für ganzzahlige Zählungen und String(localized: "You have ^[\(count) message](inflect: true)"), wo Apples automatische grammatikalische Übereinstimmung greift.

Visuelle Übersetzungsprüfung Ihrer übersetzten iOS-App – ohne manuelle QA pro Sprache veröffentlichen

Nachdem die PTC Ihre .xcstrings übersetzt hat, müssen Sie immer noch die laufende App in jeder Sprache verifizieren. Traditionell ein mehrtägiger manueller QA-Durchlauf pro Release. Ein übersetztes Label könnte auf Deutsch das Layout einer Navigationsleiste sprengen. „Send“ könnte im Französischen als Substantiv übersetzt werden, wenn der Button ein Verb benötigte. Ein hardcodierter englischer String außerhalb von Text(_:) wird in der laufenden iOS-App eklatant unübersetzt bleiben.

Die AI Visual QA der PTC ersetzt diesen Durchlauf. Für native iOS-Apps (der Workflow über die Browser-Erweiterung gilt hier nicht) verwenden Sie den Screenshot-Upload. Erfassen Sie die wichtigsten Bildschirme der laufenden App in jeder Zielsprache (Anmeldung, Haupt-Tab, Einstellungen, Edge Cases) und laden Sie diese in die PTC hoch. Die Vision-KI der PTC prüft jeden Bildschirm und:

• Behebt Fehler in der .xcstrings, wenn die PTC diese kontrolliert. Übersetzt eine falsche Wortart neu, wählt ein kürzeres Synonym, das in eine Navigationsleiste passt, und generiert eine Pluralform mit korrekter grammatikalischer Übereinstimmung neu.
• Generiert einen Prompt für Cursor / Claude Code, wenn der Fehler in Ihrem Swift-Code liegt. Ein fehlender LocalizedStringKey, ein hardcodierter String außerhalb des Lokalisierungssystems, ein durch Verkettung statt Ersetzung gebildeter Satz.

Das Ergebnis: eine verifizierte iOS-App pro Release. Nicht eine übersetzte .xcstrings, bei der die manuelle QA noch bevorsteht.

Übersetzen Sie Ihren App-Store-Eintrag, Release Notes und Push-Benachrichtigungen

Ihre App-Store-Beschreibung, What's-New-Release Notes und Texte für Push-Benachrichtigungen befinden sich außerhalb von Localizable.xcstrings. Die Funktion Paste to Translate der PTC verarbeitet diese Texte im selben Projekt. Fügen Sie den Ausgangstext in das PTC-Dashboard ein, wählen Sie Zielsprachen aus und erhalten Sie Übersetzungen zurück, die dasselbe Glossar und dieselbe Markenstimme wie Ihre In-App-Strings verwenden. Apple indexiert Keywords aus mehreren Locales pro Region, sodass lokalisierte Einträge besonders wertvoll für die Entdeckung sind.

Übersetzen Sie In-App-Nutzerinhalte mit der PTC-API

In-App-Chats, Social-Media-Beiträge und Nutzerbewertungen erfordern eine Übersetzung, sobald die Inhalte eintreffen. Die PTC-REST-API übersetzt diese Inhalte bei Bedarf mit Bearer-Token-Authentifizierung und verwendet dabei dasselbe Glossar und dieselbe Markenstimme wie Ihre .xcstrings-Übersetzungen.

Beheben Sie nicht funktionierende iOS-Lokalisierung

Die häufigste Ursache ist, dass die Lokalisierungsdatei nicht im App-Target enthalten ist. Klicken Sie im Navigator auf Localizable.xcstrings, öffnen Sie den File Inspector und überprüfen Sie, ob Ihr App-Target unter Target Membership angehakt ist. Bestätigen Sie außerdem, dass die Sprache im Abschnitt Localizations Ihres Projekts unter dem Tab Info aufgeführt ist. Wenn beides korrekt aussieht, bereinigen Sie den Build-Ordner mit Umschalt+Cmd+K und erstellen Sie den Build neu.

iOS-Lokalisierungsdateiformate: .xcstrings, .strings, .stringsdict, .xliff

.xcstrings (String Catalog) ist seit Xcode 15 der aktuelle Standard. Eine einzelne JSON-basierte Datei, die alle Strings, Pluralregeln und gerätespezifischen Varianten konsolidiert. .strings ist das klassische Key-Value-Format, das in älteren Codebasen immer noch gültig ist, gepaart mit .stringsdict für Pluralformen. .xliff und .xcloc sind Exportformate für die Übergabe an Übersetzer. Es sind keine Speicherformate.

Lokalisieren Sie Ihren App-Namen mit InfoPlist.strings

Erstellen Sie eine InfoPlist.strings-Datei und lokalisieren Sie diese für jede unterstützte Sprache. Fügen Sie in jeder Sprachversion CFBundleDisplayName = "Your Translated App Name"; hinzu. Wählen Sie die Datei im Navigator aus, öffnen Sie den File Inspector und klicken Sie auf Localize, um Sprachvarianten hinzuzufügen. iOS zeigt den korrekten App-Namen basierend auf der Gerätesprache an.

Ändern Sie die iOS-App-Sprache ohne Neustart

iOS bietet hierfür keine native API. Der Standardansatz besteht darin, AppleLanguages in UserDefaults zu setzen und den Benutzer um einen Neustart zu bitten:

UserDefaults.standard.set(["es"], forKey: "AppleLanguages")
UserDefaults.standard.synchronize()

Die Änderung wird beim nächsten Start der App wirksam. Wenn Sie einen Wechsel innerhalb der Sitzung ohne Neustart benötigen, müssen Sie die Lokalisierung manuell verwalten, indem Sie das entsprechende Bundle für die ausgewählte Sprache laden.

Warum iOS bei nicht unterstützten Sprachen auf Englisch zurückfällt

iOS verwendet Ihre Basissprache als Fallback, wenn eine Übersetzung nicht verfügbar ist. Dies ist das erwartete Verhalten. Um Fallbacks zu minimieren, stellen Sie sicher, dass Ihr String Catalog vor jedem Release keine fehlenden oder veralteten Strings aufweist.

Wie genau ist die KI-Lokalisierung für eine gesamte iOS-App?

Die PTC nutzt KI, um .xcstrings-, .strings- und .stringsdict-Dateien in Minuten zu übersetzen, wobei Pluralregeln und Platzhalter automatisch erhalten bleiben. Die Mehrheit der übersetzten Strings geht ohne Bearbeitungen live. Für die besten Ergebnisse sollten Sie der PTC bei der Einrichtung Informationen über Ihre App geben, damit die Übersetzungen die richtige Tonalität und Terminologie widerspiegeln.

In welche iOS-Sprachen Sie zuerst lokalisieren sollten

Spanisch, Französisch, Deutsch, Japanisch und Chinesisch (vereinfacht) sind neben Englisch gängige Ausgangspunkte. Wenn Ihre App bereits Nutzer in einer bestimmten Region hat, priorisieren Sie deren Sprache zuerst. Für die geringsten Anpassungskosten sollten Sie mit Sprachen beginnen, die Ihrem Basismarkt geografisch oder kulturell nahestehen.

Lokalisieren Sie Ihre eigene iOS-App

Starten Sie mit der 30-Tage-Testphase der PTC – 20.000 Wörter auf unsere Kosten, keine Kreditkarte erforderlich. Laden Sie Ihre Localizable.xcstrings hoch, übersetzen Sie sie in Minuten, laden Sie dann Screenshots hoch und lassen Sie die PTC die gerenderte App verifizieren.

Verwandte Themen:

• iOS- und Android-Apps mit KI übersetzen – plattformübergreifende Service-Übersicht.
• So lokalisieren Sie Ihre Android-App – der entsprechende Leitfaden für Android Studio.
• PTC-API-Referenz – REST-Endpunkte für die CI-Integration.