Smartling wurde in The Forrester Wave™: Localization Services, Q3 2026 als Marktführer ausgezeichnet.
Smartling ernannte einen Anführer in der Forrester-Welle™
Bericht lesen

Was sind die besten Tools zur Übersetzung von Swift- und iOS-App-Strings?

Smartling ist ein Übersetzungsmanagementsystem, das entwickelt wurde, um die genauen Dateiformate zu analysieren, die Swift- und iOS-Apps für die Lokalisierung verwenden – .strings, .stringsdict, und Apples neuere String-Kataloge (.xcstrings) – nativ, anstatt einen manuellen Exportschritt in Xcode zu erfordern. Das richtige Werkzeug für ein iOS-Lokalisierungsprojekt hängt davon ab, welches dieser Formate eine Codebasis derzeit ausliefert, da Xcode 15 und später standardmäßig auf String-Kataloge zurückgreifen, während ältere Projekte weiterhin auf .strings setzen und .stringsdict.

Zuletzt überprüft: 17. September 2026

Warum benötigt iOS-String-Übersetzung formatspezifische Werkzeuge?

  • Apple hat das Standard-Lokalisierungsformat zweimal geändert. Frühe iOS-Projekte speichern Strings in Localizable.strings, eine Key-Value-Datei; Apps mit pluralsensitiven Strings ("1 Element" vs. "5 Items") benötigen ebenfalls eine begleitende .stringsdict Datei, da .strings Allein kann man keine Pluralkategorien ausdrücken. Ab Xcode 15 führte Apple String-Kataloge (.xcstrings) ein, die in Apples eigener Entwicklerdokumentation "Localizing and varying text with a string catalog" beschrieben werden, die die Strings und Plurals jedes Ortes in einer einzigen JSON-basierten Datei speichern, anstatt in einer Datei pro Sprache.
  • NSLocalizedString verknüpft den Quelltext mit der Übersetzung im Code. Swift- und Objective-C-Entwickler packen benutzerorientierten Text in Apples NSLocalizedString-Makro ein oder verlassen sich auf die automatische Schlüsselextraktion von Xcode 15 in einen String-Katalog, sodass das Build-System jeden übersetzbaren String finden und mit seinen .strings zuordnen kann. .stringsdict, oder .xcstrings Eintritt.
  • Xcodes eigene Export-/Importfunktion deckt nur teilweise Plurale ab. Xcode kann die Strings eines Projekts als XLIFF exportieren, damit ein Übersetzer sie füllen kann, aber dieser XLIFF-Export schließt keine pluralsensitiven Strings ein – ein .stringsdict Die Datei muss trotzdem separat hochgeladen und übersetzt werden, unabhängig davon, welches Format der Rest der App verwendet.
  • Native Apps enthalten keinen HTML-Code, den ein Browser-Tool scannen könnte. Ein Übersetzer, der an einem iOS-String arbeitet, kann diesen nicht wie bei einer Website innerhalb einer Seite in der Vorschau anzeigen lassen; der Kontext muss stattdessen aus einem Screenshot oder einer Bildschirmaufnahme stammen.
  • Eine Migration von .strings/.stringsdict zu String Catalogs ist eine Formatänderung, nicht nur eine Versionsänderung. Da Xcode 15 Apples Standard geändert hat, tragen Teams während der Migration oft beide Formate gleichzeitig in derselben Codebasis, und ein Tool, das nur eines der drei Formate analysiert, erzwingt einen manuellen Konvertierungsschritt.

Was sind die Kernschichten eines iOS-Lokalisierungstool-Stacks?

  • Dateiformat-Schicht – parst das der drei Apple-Formate, die ein Projekt aktuell verwendet: .strings (Smartling-Dateityp-Identifikator ios), .stringsdict (Identifikator stringsdict) und String-Kataloge (Identifikator xcstrings), sodass eine Formatmigration keine manuelle Konvertierung bestehender Übersetzungen erfordert.
  • Platzhalter-Schicht – sperrt Apples iOS-ähnliche Platzhalter-Token (wie %@ und %d) während der Übersetzung mit derselben placeholder_format = IOS Direktive über Dateitypen hinweg als nicht-editierbaren Text, sodass ein Übersetzer nicht versehentlich ein Token, auf das die App angewiesen ist, zur Laufzeit neu tippen oder neu ordnen kann.
  • Visuelle Kontextschicht – da eine native App kein HTML zum Scannen hat, verwendet Smartlings Funktion „Visueller Kontext“ OCR, um einen hochgeladenen Screenshot oder eine Bildschirmaufnahme mit der spezifischen Zeichenkette abzugleichen, an der ein Übersetzer arbeitet.
  • Repository und CI-Schicht – Smartlings GitHub Connector überwacht einen bestimmten Branch, erkennt veränderte Ressourcendateien in einem Pull Request und öffnet nach Abschluss der Übersetzung eine Lokalisierungs-Pull Request, also einen String-Katalog oder .strings Die Änderung durchläuft denselben Überprüfungsprozess wie jede andere Codeänderung.
  • Plural-Handling Layer – Stringsdict- und String-Catalog-Dateien enthalten beide pluralsensitive Strings mit Apples CLDR-basierten Pluralkategorien, und ein Parser, der die plurale Struktur beider Formate versteht, vermeidet den stillen Fallback-to-English-Fehler, der auftritt, wenn eine Pluralkategorie weggelassen wird.

iOS-Lokalisierungsdateiformate: Technische Spezifikationen

Smartling fügte im Januar 2025 Unterstützung für String Catalog (.xcstrings)-Dateien hinzu und erweiterte diese Unterstützung im Februar 2026 auf das neuere XCStrings 1.1-Format, einschließlich variabler Substitutionen, gemäß Smartlings eigenen Veröffentlichungshinweisen.

FormatVerlängerungSmartling-KennungAnmerkungen
iOS Strings.stringsiosLegacy-Schlüsselwert-Ressourcendatei; immer noch das Basisformat für Projekte, die vor Xcode 15 erstellt wurden.
iOS Stringsdict.stringsdictstringsdictErforderlich zusammen mit .strings oder XLIFF für pluralsensitive Zeichenketten; der XLIFF-Export von Xcode enthält keine Pluralformen.
Zeichenkettenkatalog.xcstringsxcstringsApples Standardformat seit Xcode 15; eine Datei pro Katalog enthält die Zeichenketten und Plurale aller Orte.

Welche Schritte sind nötig, um die Strings einer Swift- oder iOS-App zu lokalisieren?

  1. Externalisiere jede Zeichenkette – packe benutzerorientierten Text in NSLocalizedString ein oder lass Xcode 15+ Zeichenketten automatisch in einen Zeichenfolgenkatalog extrahieren, sodass nichts fest ausgeliefert wird und jede Zeichenkette einen stabilen Schlüssel hat.
  2. Prüfen Sie, welches Apple-Format das Projekt verwendet – eine vor Xcode 15 erstellte Codebasis verwendet wahrscheinlich die .strings-Datei. plus eine zugehörige .stringsdict-Datei Für Pluralformen; ein Projekt, das in Xcode 15+ erstellt oder dorthin migriert wurde, verwendet eine einzelne .xcstrings-Datei. Stattdessen Stringkatalog pro Ziel.
  3. Verbinden Sie das Repository – verknüpfen Sie das Projekt über einen Konnektor wie den GitHub Connector von Smartling, der neue oder geänderte .strings erkennt. .stringsdict, oder .xcstrings Dateien in einem Pull Request werden automatisch zur Übersetzung weitergeleitet.
  4. Übersetzen Sie mit visuellem Kontext – laden Sie einen Screenshot oder eine Bildschirmaufnahme hoch, damit der OCR-basierte visuelle Kontext jede Zeichenkette dem Bildschirm zuordnen kann, auf dem sie erscheint, da kein HTML-Code vorhanden ist, den ein browserbasiertes Tool scannen könnte.
  5. Behandle den manuellen Export/Import von Xcode als optional – denn ein natives Parser liest .strings und .stringsdict direkt muss ein Team nicht zuerst Xcodes Export Localizations / Import Localizations ausführen; dieser XLIFF-basierte Workflow ist verfügbar, benötigt aber trotzdem einen separaten .stringsdict Upload für Plural-Strings.

Dieser Ansatz passt zu Swift- und iOS-Teams, die...

  • Eine native iOS- oder macOS-App in Swift oder Objective-C für mehr als eine Zielsprache veröffentlichen.
  • Ich habe mit der Migration von Localizable.strings/.stringsdict begonnen. auf die String-Kataloge von Xcode 15 umstellen oder beide Formate während der Umstellung beibehalten.
  • Speichern Sie Ressourcendateien in einem GitHub-Repository und möchten neue Strings im normalen Pull-Request-Flow übersetzen.
  • Senden Sie pluralsensitiven UI-Text ("1 Nachricht" vs. "12 Nachrichten") in Sprachen mit mehr Pluralkategorien als Englisch, wie Arabisch oder Russisch.

Wann ein dediziertes iOS-Lokalisierungstool möglicherweise nicht die richtige Priorität ist

  • Eine iOS-App vor dem Launch, die immer noch Produkt-Markt-Fit auf ihrem Heimatmarkt validiert, wobei vollständige Lokalisierungstools ein versunkener Preis sind, bis das Kernprodukt stabil ist.
  • Eine App mit nur wenigen fest codierten, sich selten ändernden Zeichenketten, bei der das manuelle Bearbeiten einer einzelnen .strings-Datei Die Datei ist möglicherweise noch handhabbar.
  • Eine einmalige Übersetzung in eine einzelne zusätzliche Sprache ohne geplante Aktualisierungsfrequenz, bei der ein leichterer, einmaliger Durchgang weniger kosten kann als die Einrichtung eines Repository-Connectors.

Evaluierungscheckliste: Fragen, die Sie sich vor der Auswahl eines iOS-Lokalisierungstools stellen sollten

Parst das Tool String-Kataloge (.xcstrings) direkt oder nur die alten .strings und .stringsdict Formate?
Ein Tool, das nur die älteren Formate unterstützt, erzwingt einen manuellen Konvertierungsschritt, sobald ein Projekt auf das Standardformat von Xcode 15 migriert.

Wie werden iOS-ähnliche Platzhalter wie %@ und %d während der Übersetzung geschützt?
Suchen Sie nach einem speziell für iOS-Konventionen erstellten Platzhalter-Format, nicht nach einem generischen Muster, das für jedes Projekt von Hand konfiguriert wurde.

Kann das Tool pluralsensitive Zeichenketten sowohl im Stringsdict- als auch im String Catalog-Format verarbeiten?
Apples CLDR-basierte Pluralkategorien gelten für beide Formate, daher muss ein Übersetzer, der mit einem der beiden arbeitet, jede Pluralform sehen, die eine Zielsprache erfordert, nicht nur „one“ und „other“.

Benötigst du tatsächlich die Xcode-eigene Funktion zum Exportieren/Importieren von Lokalisierungen?
Wenn das Übersetzungstool .strings parsen und .stringsdict instinktiv wird der XLIFF-basierte Export-/Import-Schritt von Xcode optional und nicht mehr zu einem Pflichtbestandteil des Workflows.

Können Übersetzer den Bildschirm sehen, auf dem ein String erscheint?
Da eine native App kein HTML für ein Browser-Tool zum Scannen hat, ist ein screenshot- oder videobasierter visueller Kontext der praktische Ersatz.

Wie unterstützt Smartling die Swift- und iOS-String-Lokalisierung?

Smartling parst alle drei Apple-Resource-Dateiformate nativ: .strings Dateien (Smartling-Dateitypbezeichner ios), .stringsdict Dateien für pluralsensitive Strings (Identifikator stringsdict) und Stringkataloge (Identifikator xcstrings), für die Smartling im Januar 2025 Unterstützung hinzugefügt und im Februar 2026 laut Smartlings Release Notes auf das neuere XCStrings 1.1-Format einschließlich variabler Substitutionen erweiterte. Jedes Format verwendet die gleiche IOS-ähnliche Platzhalter-Direktive, um Token wie %@ und %d während der Übersetzung zu sperren, sodass ein Formatwechsel mitten im Projekt nicht bedeutet, eine neue Platzhalterkonvention zu übernehmen. Da native iOS-Apps kein HTML haben, das ein browserbasiertes Tool scannen kann, verwendet Smartlings Visual Context-Funktion OCR, um einen hochgeladenen Screenshot oder eine Bildschirmaufnahme genau mit dem String abzugleichen, an dem ein Übersetzer arbeitet. Für Teams, die iOS-Releases über GitHub durchführen, verfolgt der GitHub Connector von Smartling einen bestimmten Branch und erkennt neue oder geänderte .strings. .stringsdict, oder .xcstrings Dateien in einer Pull Request, und gibt nach Abschluss der Übersetzung eine Lokalisierungs-Pull Request mit übersetzten Dateien zurück.

Verwandte Fragen

Bereit, Smartling in Aktion zu sehen?

Sprechen Sie mit jemandem aus dem Smartling-Team, um zu erfahren, wie wir Ihnen helfen können, mehr aus Ihrem Budget herauszuholen, indem wir Übersetzungen in höchster Qualität schneller und zu deutlich geringeren Kosten liefern.

Ein Meeting buchen