Auf der WWDC23 hat Apple ein neues Feature für Xcode vorgestellt, das große Teile meiner RemafoX-App gesherlocked hat. Natürlich habe ich das neue Feature ausführlich getestet und all meine Fragen an das Team gestellt, das es gebaut hat – in der zugehörigen Slack-Aktivität. Sie haben mit String Catalogs wirklich gute Arbeit geleistet, so gut sogar, dass ich meine App komplett neu denken werde, da sie den Großteil der Low-Level-Arbeit übernommen haben, die ich bisher in meiner App erledigt habe.
Aber die meisten Leute, mit denen ich seit der Dub Dub gesprochen habe, sind sich der Auswirkungen von String Catalogs auf ihre Projekte noch gar nicht bewusst. Also dachte ich, ich sollte die häufigsten Fragen beantworten, um klarer zu machen, wie großartig String Catalogs wirklich sind.
Was sind String Catalogs? Was ist mit Strings(dict)-Dateien?
String Catalogs sind Dateien mit der Endung .xcstrings, die ihren Inhalt in einem eigenen JSON-Format speichern. Das genaue Format ist nicht dokumentiert (Feedback eingereicht, um das zu ändern: FB12264877), und als Entwickler wirst du nie mit JSON-Code herumhantieren müssen, denn Xcode 15 liefert einen visuellen Editor mit:
String Catalogs ersetzen sowohl .strings- als auch .stringsdict-Dateien und unterstützen daher Pluralisierung von Haus aus. Anders als .strings(dict)-Dateien, die in sprachspezifischen Ordnern wie en.lproj abgelegt werden, kapseln String Catalogs die Übersetzungen aller unterstützten Sprachen in einer einzigen Datei. Das ermöglicht Sicherheitsprüfungen wie die Anzeige des Übersetzungsfortschritts direkt in Xcode, damit du über fehlende Übersetzungen informiert bist (ersetzt den RemafoX-Linter). Ebenso werden neue Keys automatisch für alle Sprachen hinzugefügt, was dir viel Zeit spart (ersetzt den RemafoX-Normalizer). Und in zukünftigen Updates könnten weitere Features folgen, wie eine Prüfung, ob deine Lokalisierungen die gleichen Parameter (z. B. %@) wie die Ausgangssprache haben (ein Feature, das ich für RemafoX geplant hatte, Feedback eingereicht: FB12264614).
Ich habe ein Projekt mit Strings(dict)-Dateien. Ist die Migration einfach?
Ja, absolut! Die Migration zu String Catalogs ist kinderleicht: Klicke einfach mit der rechten Maustaste auf eine deiner .strings(dict)-Dateien und wähle “Migrate to String Catalog…”. Das öffnet ein Modal mit einer Liste all deiner .strings(dict)-Dateien im Projekt, aus denen du auswählen kannst, welche zu einem String Catalog zusammengefasst werden sollen. Wenn du separate Strings-Dateien für verschiedene Teile deines Projekts hast, kannst du auch separate String Catalogs behalten – es ist nicht nötig, alles in einen String Catalog zu packen.
Aber mein Projekt unterstützt ältere OS-Versionen. Kann ich trotzdem migrieren?
Ja, absolut! Die Apple-Ingenieure haben hier etwas sehr Cleveres gemacht: Während wir als Entwickler alle Features von String Catalogs voll nutzen können, bekommt unsere App kein neues Dateiformat wie .xcstrings zu sehen. Stattdessen konvertiert Xcode den String Catalog während des Build-Prozesses zurück in die guten alten .strings- und .stringsdict-Dateien, was die Unterstützung aller OS-Versionen sicherstellt, die du potenziell anvisieren kannst. Das bedeutet: Sobald du für dein Projekt auf Xcode 15 wechseln kannst, kannst du String Catalogs uneingeschränkt nutzen, ohne jemals zurückblicken zu müssen!
💁♂️ Wenn du dir schon mal eine App wie SF Symbols gewünscht hast, aber für lokalisierte Strings im Code mit offiziellen Übersetzungen für alle Sprachen, in denen iOS verfügbar ist: Genau das habe ich gebaut, und das Feature ist komplett kostenlos! Lade einfach TranslateKit herunter und schau in deine Menüleiste. 🌐 👍
Ich nutze SwiftGen/RemafoX für sichere Lokalisierungs-Key-Referenzen mit Compiler-Checks. Verliere ich diese Sicherheit?
Nein, überhaupt nicht. Xcode führt nicht nur ein neues Dateiformat für deine Lokalisierungen ein, sondern bringt auch Tools mit, die automatisch neue Lokalisierungs-Keys aus deinem Projekt extrahieren. Wenn du eine von SwiftUIs Lokalisierungs-APIs mit LocalizedStringKey oder LocalizedStringResource verwendest, werden sie automatisch erkannt und deinem String Catalog hinzugefügt. Aber das beschränkt sich nicht auf SwiftUI – es funktioniert auch mit reinen Swift-String-APIs wie String(localized:), klassischen Obj-C-Style-APIs wie NSLocalizedString() (sogar mit eigenen Namen) und sogar mit Interface-Builder-Dateien wie .storyboard und .xib. Für Info.plist-Dateien musst du einen eigenen String Catalog namens InfoPlist.xcstrings erstellen, und die Extraktion funktioniert auch dort automatisch.
Beachte, dass du keine Auto-Completion für deine Keys im Code bekommst, wie du sie jetzt für Bilder und Farben in deinen Asset Catalogs mit Xcode 15 erhältst. Das liegt daran, dass bei Asset Catalogs die Source of Truth im Catalog selbst liegt, wo deine Assets platziert werden. Weil Xcode aber automatisch alle hinzugefügten Lokalisierungen aus deinem Quellcode extrahiert, ist die Source of Truth für deine Lokalisierungen umgekehrt und liegt in deinem Code. Daher ist es unmöglich, einen Text in deinem Code hinzuzufügen, für den es kein Gegenstück in einer Strings-Datei gibt (wie es vorher möglich war und zu defekten Übersetzungen führte). Stattdessen erstellt Xcode jedes Mal, wenn du einen lokalisierten String in deinem Projekt hinzufügst, automatisch einen neuen Übersetzungs-Key für alle unterstützten Sprachen, und du siehst im String Catalog, dass deine Übersetzungen unvollständig sind.
Das Fehlen eines grünen Häkchens bei der deutschen Sprache zeigt an, dass die Übersetzung unvollständig ist.
Was ist mit Tippfehlern? Kann ich den Key während der Entwicklung ändern?
Xcode extrahiert nicht nur neue Keys und fügt sie automatisch deinem String Catalog hinzu, sondern stellt auch sicher, dass Keys in deinem Catalog, die nicht mehr in deinem Projekt referenziert werden, gelöscht werden. Das geschieht auf sichere Weise: Wenn du einen Key hast, für den du noch keine Übersetzungen in irgendeiner Sprache bereitgestellt hast, wird er automatisch gelöscht, sobald er nicht mehr in deinem Projekt gefunden wird. Das passiert typischerweise, wenn du einen Tippfehler in deinem Key hast oder den Key während der Entwicklung einfach verbessern und ändern möchtest. Aber wenn du bereits einige Übersetzungen hast, markiert Xcode den Key im String Catalog stattdessen als “stale” mit einem gelben Warnsymbol. So lassen sich Keys, die nicht mehr referenziert werden, leicht erkennen, ihre Übersetzungen bei Bedarf zum neuen Key kopieren und danach löschen.
Was, wenn ich einen bestimmten Text in Code/IB-Dateien nicht lokalisieren möchte?
Derzeit scheint es keinen direkten Weg zu geben, die Extraktion aus der Source of Truth zu steuern. Ich habe ein Feedback speziell für IB-Dateien eingereicht (FB12264777), weil meine Tools RemafoX (und sein Vorgänger BartyCrouch) dort das Ausschließen unterstützen – der Wechsel zu String Catalogs wäre daher für Nutzer dieser Tools nur möglich, wenn Apple eine Lösung anbieten würde. Einen expliziten Weg, einen String im Code als “nicht übersetzbar” zu markieren, konnte ich auch nicht finden, aber in den meisten SwiftUI-Views findest du eine Überladung der gleichen API, die statt eines Strings ein Text-View entgegennimmt. Für Views, bei denen das zutrifft, kannst du Text(verbatim: "Your Text") verwenden, um ein Text-View zu erstellen, dessen Text nicht extrahiert wird, weil das Schlüsselwort verbatim ihn als nicht übersetzbar kennzeichnet. Da aber nicht immer eine Überladung mit Text existiert, habe ich ein Feedback für einen direkteren Weg zur Steuerung der Extraktion eingereicht (FB12469163). Vorläufig habe ich einen Workaround gefunden, indem ich einfach einen String-Initializer in SwiftUI-APIs verwende, die die LocalizedStringKey-Überladung bevorzugen – übergib einfach etwas wie String("Your Text").
Fazit
Die Einführung von String Catalogs in Xcode 15 bringt erhebliche Verbesserungen für den Lokalisierungs-Workflow, indem sie die Verwaltung von Übersetzungsdateien vereinfacht. Entwickler können ihre Projekte einfach zu String Catalogs migrieren und die Sicherheit von Lokalisierungs-Key-Referenzen beibehalten, während sie weiterhin ältere OS-Versionen unterstützen und Kontrolle über Key-Änderungen und Tippfehler haben. Obwohl es einige Einschränkungen und Verbesserungsmöglichkeiten gibt, sind String Catalogs ein riesiger Schritt nach vorne und haben gegenüber dem alten Strings-Dateisystem keine echten Nachteile. Jetzt migrieren!