Die Apple-Dokumentation beschreibt String Catalog als Xcode-Werkzeug für lokalisierbare App-Texte; die Release Notes führen außerdem Xcode 27.2 als eigene Beta-Version auf. String Catalog in Xcode und Xcode-27.2-Release-Notes sind daher die Quellen, an denen Sie die aktuelle Verfügbarkeit prüfen sollten. Für Ihr SwiftUI-Kursprojekt gilt: Verwalten Sie sichtbare Texte bevorzugt im String Catalog, statt chinesische und englische Satzteile im Code zusammenzusetzen. Prüfen Sie danach beide Sprachen in der laufenden App, besonders längere Texte und dynamische Inhalte.

Für wen dieser Leitfaden gedacht ist:
Sie schreiben gerade Ihr erstes SwiftUI-Kursprojekt und möchten eine chinesische und englische Oberfläche ergänzen.
Sie haben bereits Texte im Code verteilt und möchten wissen, welche davon übersetzbar sein sollten.
Sie arbeiten im Team oder bereiten eine mehrsprachige Abgabe vor und brauchen eine verlässliche Prüfung.

Den Umfang Ihres ersten zweisprachigen Bildschirms begrenzen

Beginnen Sie mit einer einzelnen Ansicht, zum Beispiel einer Kursübersicht mit Seitentitel, einer Schaltfläche und einem kurzen Hinweis. Übersetzen Sie zunächst nur die Texte, die Ihre Nutzer tatsächlich sehen. Sie müssen weder das ganze Projekt umorganisieren noch jede Ressource lokalisieren, bevor Sie die erste Ansicht testen können.

„Lokalisierung“ bedeutet hier: Die App stellt Texte passend zur gewählten Sprache bereit. Das betrifft nicht nur einzelne Wörter. Auch Satzbau, Länge und Darstellung können sich unterscheiden. Eine Schaltfläche, die auf Chinesisch kurz wirkt, kann auf Englisch deutlich mehr Platz beanspruchen. Umgekehrt lässt sich nicht jeder englische Ausdruck Wort für Wort in eine andere Sprache übertragen.

Ein sinnvoller erster Projektumfang umfasst:

  • Titel und Navigationsbeschriftungen der gewählten Ansicht
  • Schaltflächen und Hinweise, die zur Bedienung gehören
  • verständliche Fehlermeldungen, die Nutzende tatsächlich sehen
  • dynamische Texte, falls die Ansicht zum Beispiel einen Punktestand anzeigt

Lassen Sie interne Variablennamen, Debug-Ausgaben und beliebige Daten nicht automatisch zu Übersetzungstexten werden. Eine Variable wie score ist kein sichtbarer App-Text. Ein Produktname oder ein aus einer Datenquelle geladener Benutzername sollte ebenfalls nicht ohne Grund verändert werden. Apple erläutert, wie Sie App-Texte für die Übersetzung vorbereiten; nutzen Sie diese Unterscheidung, bevor Sie Einträge im Katalog bearbeiten. Apples Hinweise zur Übersetzungsvorbereitung

Für eine Kursabgabe ist das eine praktische Grenze: Wenn nur die Oberfläche Ihrer Projektübersicht zweisprachig sein soll, übersetzen Sie diese Ansicht und die direkt dazugehörigen Meldungen. Versuchen Sie nicht, Bezeichnungen in Testdaten, Konsolenausgaben oder Kommentaren „mitzulokalisieren“. Das macht den Katalog unübersichtlich, ohne die Bedienung der App zu verbessern.

SwiftUI-Texte im String Catalog sammeln

Ein String Catalog ist die zentrale Xcode-Datei, in der lokalisierbare Texte und ihre Sprachfassungen verwaltet werden. Die Xcode-Dokumentation erklärt, wie Sie einen Katalog verwenden, Sprachen ergänzen und lokalisierbare Texte bearbeiten. Apple: Texte mit einem String Catalog lokalisieren

Prüfen Sie zuerst, ob Ihr Projekt bereits einen String Catalog enthält. Öffnen Sie das Projekt in einer für Ihre Umgebung verfügbaren Xcode-Version und sehen Sie im Projektnavigator nach, ob eine entsprechende Katalogdatei vorhanden ist. Die genaue Darstellung und einzelne Menübezeichnungen können sich zwischen Xcode-Versionen unterscheiden. Verlassen Sie sich deshalb nicht auf eine ungeprüfte Schrittfolge aus einem alten Tutorial: Orientieren Sie sich für die verwendete Version an der aktuellen Apple-Dokumentation.

In SwiftUI ist ein sichtbarer, als lokalisierbar erkennbarer Text häufig direkt in der Ansicht notiert. Zum Beispiel:

Text("Course overview")
Button("Continue") {
    // Aktion
}

Xcode kann unterstützte Textstellen bei der Arbeit mit dem Katalog erfassen. Das bedeutet aber nicht, dass jede Zeichenfolge, die irgendwann zur Laufzeit in einer Ansicht landet, automatisch eine passende Übersetzungszeile erhält. Wenn eine Beschriftung aus Variablen, zusammengesetzten Teilen oder externen Inhalten entsteht, prüfen Sie den Eintrag gezielt. Apple beschreibt sowohl die Verwendung des Katalogs als auch die Grenzen der Lokalisierung in seiner Dokumentation zur Unterstützung mehrerer Sprachen. Mehrsprachige Apps in Xcode unterstützen

Gehen Sie für Ihre erste Ansicht so vor:

  1. Sammeln Sie sichtbare Texte. Notieren Sie die Beschriftungen, Hinweise und Fehlermeldungen, die in der gewählten Ansicht tatsächlich angezeigt werden.
  2. Ordnen Sie sie nach Funktion. Ein Seitentitel, eine Schaltfläche und eine Erklärung haben unterschiedliche Aufgaben. Kontext erleichtert später die Übersetzung.
  3. Prüfen Sie den Katalog. Kontrollieren Sie, ob Xcode die erwarteten Texte aufgenommen hat. Fehlt ein Eintrag, prüfen Sie zuerst, wie der Text im SwiftUI-Code erzeugt wird.
  4. Ergänzen Sie die Sprachfassungen. Tragen Sie für jede lokalisierte Zeichenfolge eine vollständige Formulierung ein, statt Satzteile im Code zusammenzusetzen.
  5. Bauen und starten Sie die App. Entscheidend ist die sichtbare Oberfläche, nicht allein die Vollständigkeit der Katalogdatei.

Wenn Xcode einen Text nicht automatisch aufnimmt, behandeln Sie das zunächst als Prüfhinweis und nicht als Beweis, dass Lokalisierung grundsätzlich unmöglich ist. Ermitteln Sie, ob es sich um statischen UI-Text, zusammengesetzten Text oder Daten zur Laufzeit handelt. Danach können Sie die Zeichenfolge in eine unterstützte Form bringen oder eine passende Lokalisierungsressource gezielt ergänzen.

Bestehenden Code und dynamische Inhalte übersetzbar machen

Bei einem vorhandenen Projekt liegt die Schwierigkeit häufig nicht in der Übersetzung selbst, sondern darin, die Grenzen zwischen Oberfläche und Programmlogik zu erkennen. Suchen Sie nach Texten, die Nutzende lesen: etwa in Text-Elementen, Schaltflächen, Formularhinweisen und sichtbaren Warnungen. Lassen Sie technische Protokolle und interne Fehlersuche zunächst außen vor.

Vermeiden Sie Konstruktionen, bei denen mehrere übersetzte Bruchstücke zu einem Satz verbunden werden. Ein Beispiel wäre, einen festen Textteil, einen Namen und eine weitere feste Wendung separat einzusetzen. Die Grammatik und Reihenfolge können sich zwischen Sprachen unterscheiden. Eine Übersetzung, die im Deutschen oder Englischen funktioniert, muss deshalb nicht zu einem chinesischen Satz passen.

Planen Sie stattdessen einen vollständigen Ausdruck mit dem nötigen Platz für veränderliche Werte. Für Zähler, Mengen oder Statusangaben ist wichtig, dass die sprachabhängige Form nicht bloß aus einem festen Wort plus Zahl besteht. Prüfen Sie die von Xcode unterstützten Möglichkeiten für Pluralformen und Formatwerte im String Catalog. Apple dokumentiert, wie lokalisierbare Texte und sprachabhängige Varianten in der App verwaltet werden. Dokumentation zu String Catalogs

Prüfen Sie bei dynamischen Texten außerdem den Inhalt der eingesetzten Werte. Eine Zahl, ein Nutzername oder ein Datenbankfeld ist nicht automatisch ein Übersetzungstext. Die umgebende Nachricht kann lokalisierbar sein, während der Datenwert unverändert bleibt. Trennen Sie also die sprachabhängige Formulierung von den variablen Inhalten, statt beides als einen beliebigen Textblock zu behandeln.

Achtung: Ein Eintrag im String Catalog beweist nicht, dass jede Laufzeitvariante korrekt dargestellt wird. Prüfen Sie auch Werte, die erst während der Nutzung eingesetzt werden, direkt in der gestarteten App.

Für Studierende, die bereits Code geschrieben haben, hilft eine kleine Inventarliste. Erfassen Sie pro UI-Text seine Fundstelle, den Zweck und mögliche dynamische Werte. Markieren Sie danach, ob es sich um eine Bedienbeschriftung, einen Satz mit variablem Inhalt oder um interne Information handelt. So vermeiden Sie sowohl fehlende sichtbare Texte als auch unnötig übersetzte Entwicklungsdetails.

Übersetzungen im Team vorbereiten und übergeben

Wenn ein Team die Übersetzung aufteilt, braucht die übersetzende Person mehr als eine Liste isolierter Wörter. Ergänzen Sie für jeden Eintrag eine kurze Erklärung: Wo erscheint der Text? Ist er eine Schaltfläche, ein Titel oder eine Fehlermeldung? Welcher dynamische Wert kann darin vorkommen? Ohne diesen Kontext kann eine sprachlich plausible Übersetzung trotzdem an der falschen Stelle oder mit der falschen Bedeutung landen.

Xcode bietet einen dokumentierten Weg, Lokalisierungen zu exportieren und wieder zu importieren. Verwenden Sie den offiziellen Ablauf, statt Inhalte per Hand aus verschiedenen Projektdateien herauszukopieren. Apple: Lokalisierungen exportieren beschreibt die Exportfunktion. Stimmen Sie bei einer Gruppenarbeit außerdem ab, wer die Katalogdatei ändert und wie übersetzte Dateien wieder ins Projekt gelangen. Das verhindert, dass eine Person eine ältere Fassung versehentlich über eine neuere schreibt.

Maschinelle Übersetzung kann beim Entwurf einzelner Formulierungen helfen, ersetzt aber keine fachliche Prüfung. Besonders Schaltflächen, Warnungen und Texte mit Variablen müssen in ihrem tatsächlichen Zusammenhang gelesen werden. Bitten Sie Ihre Teammitglieder deshalb nicht nur um eine Übersetzung, sondern auch um eine Prüfung auf Bedeutung, Ton und Platzbedarf.

Vor der Übergabe sollten Sie kontrollieren:

  • Sind die Zielsprachen im Projekt angegeben?
  • Sind die sichtbaren Texte im Katalog auffindbar?
  • Haben die Einträge genug Kontext für die Übersetzung?
  • Sind dynamische Werte als solche erkennbar?
  • Wurde die zurückgegebene Lokalisierung im Projekt geöffnet und geprüft?

Den Lernweg ohne eigenen Mac auswählen

Sie können die Grundidee der Lokalisierung auch ohne eigenes Apple-Gerät lernen: Texte in der Oberfläche identifizieren, Übersetzungen formulieren und Unterschiede im Satzbau nachvollziehen. Für die eigentliche Xcode-Projektarbeit brauchen Sie jedoch eine nutzbare Mac-Umgebung. Apple veröffentlicht Systemanforderungen für Xcode; prüfen Sie vor Beginn, ob die verfügbare Mac- und Betriebssystemversion mit der von Ihrer Lehrveranstaltung geforderten Entwicklungsumgebung zusammenpasst. Aktuelle Xcode-Systemanforderungen

Ein Windows-Schulcomputer kann für allgemeine Programmierübungen oder die Vorbereitung von Übersetzungen reichen. Er ersetzt aber nicht die Möglichkeit, das SwiftUI-Projekt in Xcode zu öffnen, zu bauen und die laufende Oberfläche zu kontrollieren. Auch ein gesperrtes Schulgerät kann ein Hindernis sein, wenn Sie keine Software installieren oder Projekte nicht an den benötigten Speicherort legen dürfen. Klären Sie Berechtigungen und Speicherregeln, bevor Sie Ihre Abgabe darauf aufbauen.

Für einen Mac vor Ort sprechen die direkte Bedienung und der unmittelbare Zugriff auf die Projektdateien. Ein Remote-Mac kann eine Alternative sein, wenn Sie nur zeitweise eine Xcode-Umgebung brauchen. Dabei sollten Sie prüfen, ob Ihre Internetverbindung stabil genug für die Arbeit am entfernten Bildschirm ist, wie Dateien übertragen werden und ob die Kursregeln die Nutzung erlauben. Bei einer kurzen Sitzung kann eine Unterbrechung außerdem bedeuten, dass Sie den Arbeitsstand erneut öffnen oder die Verbindung neu herstellen müssen. Speichern Sie Änderungen deshalb regelmäßig im Projekt und halten Sie wichtige Abgabedateien zusätzlich an einem von der Schule erlaubten Ort bereit.

Wenn Sie diese Möglichkeit prüfen möchten, finden Sie auf der deutschsprachigen MACCOME-Seite Informationen zum Angebot. Entscheiden Sie nicht allein nach dem Fernzugriff: Für Ihre Aufgabe zählt, ob die benötigte Xcode-Umgebung, der erlaubte Umgang mit Kursdateien und die geplante Nutzungsdauer zusammenpassen.

Entscheidungszweige für Ihren nächsten Schritt:

  • Wenn Sie nur Übersetzungen und Begriffe vorbereiten möchten, dann sammeln Sie Texte und Kontext zunächst auf dem vorhandenen Rechner.
  • Wenn Ihr Kurs den Build und die tatsächliche Anzeige in Xcode verlangt und ein kompatibler Schul-Mac verfügbar ist, dann nutzen Sie diesen zuerst.
  • Wenn Sie Xcode nur für eine begrenzte Projektphase benötigen und kein lokaler Mac verfügbar ist, dann prüfen Sie einen Remote-Mac und klären Sie vorher Dateiablage, Verbindung und Kursregeln.
  • Wenn das Projekt regelmäßig lange Sitzungen oder direkten Zugriff auf lokale Geräte und Anschlüsse verlangt, dann passt ein eigener Mac oder ein dauerhaft verfügbarer Rechner möglicherweise besser als eine zeitweise Remote-Umgebung.

Die zweisprachige Abgabe im laufenden Betrieb prüfen

Führen Sie Ihre Abschlusskontrolle in der App aus, nicht nur im Xcode-Editor. Apple beschreibt Tests für Lokalisierungen beim Ausführen der App. Verwenden Sie den dokumentierten Testweg Ihrer Xcode-Version und unterscheiden Sie klar zwischen Beta- und stabilen Funktionen. Die Release Notes für Xcode 27.2 sind ein Hinweis auf eine Beta-Veröffentlichung, kein Beleg dafür, dass jede dort aufgeführte Funktion in allen stabilen Versionen verfügbar ist. Lokalisierungen beim Ausführen testen

Kontrollieren Sie in jeder Sprache mindestens diese Punkte:

  • Wird die Standardsprache der App wie erwartet angezeigt?
  • Erscheinen die Texte der anderen Sprache, wenn Sie die Spracheinstellung ändern?
  • Bleiben längere Titel und Schaltflächen vollständig lesbar?
  • Sind dynamische Werte in den übersetzten Satz sinnvoll eingebettet?
  • Werden Layout, Abstände und Zeilenumbrüche in der laufenden Ansicht korrekt dargestellt?
  • Haben Sie die tatsächlich verwendete Projekt- und Xcode-Version geprüft, statt sich auf einen Beta-Menüpfad zu verlassen?

Prüfen Sie auch den Wechsel zwischen den Spracheinstellungen, den Ihre Lehrkraft oder Aufgabenstellung verlangt. Ein vorhandener zweisprachiger Katalog ist kein Ersatz für einen Laufzeittest. Wenn eine Schaltfläche abgeschnitten wird oder ein dynamischer Satz falsch klingt, ist die Lokalisierung noch nicht fertig, selbst wenn beide Texte im Katalog stehen.

Die folgende Entscheidungshilfe fasst zusammen, was Sie für den Einstieg benötigen:

Ihre Ausgangslage Sinnvoller erster Schritt Grenze, die Sie prüfen sollten
Neues SwiftUI-Kursprojekt Eine Ansicht auswählen und sichtbare Texte erfassen Nicht das gesamte Projekt vorab übersetzen
Bestehender Code mit Texten an vielen Stellen UI-Texte von Variablen, Daten und Debug-Ausgaben trennen Automatische Erkennung nicht als vollständig voraussetzen
Teamübersetzung Kontext ergänzen und Xcode-Export beziehungsweise -Import verwenden Zurückgegebene Texte in der App kontrollieren
Kein lokaler Mac Konzepte und Übersetzungen vorab vorbereiten; Mac-Zugang für Build und Laufzeittest klären Schulregeln, Xcode-Kompatibilität und Verbindung berücksichtigen
Prüfbereich Was Sie konkret ansehen Freigabekriterium
Sprachressourcen Einträge für die benötigten Sprachen Sichtbare Texte sind auffindbar und zugeordnet
Statische Oberfläche Titel, Hinweise und Schaltflächen Beide Fassungen sind verständlich und vollständig
Dynamische Inhalte Zahlen, Namen oder Statuswerte in Sätzen Satzbau bleibt mit eingesetzten Werten plausibel
Laufende App Beide Sprachumgebungen und längere Texte Kein abgeschnittener Text und kein ungeprüftes Layout
Projektumgebung Xcode-Version und Kursanforderungen Build und Test laufen in einer zulässigen Umgebung

Wenn Sie aktuell nur auf Windows oder einem eingeschränkten Schulrechner arbeiten, hat dieser Weg klare Nachteile: Xcode lässt sich dort nicht als lokale Mac-Entwicklungsumgebung nutzen, der tatsächliche iOS-Build bleibt ungetestet und die sichtbare Oberfläche lässt sich nicht zuverlässig nur anhand der Katalogdatei abnehmen. Für eine einzelne Kursphase kann ein Remote-Mac von MACCOME die Lücke zwischen Vorbereitung und echtem Xcode-Test schließen, ohne dass Sie sofort einen Mac kaufen müssen. Wenn Sie diese Option vergleichen möchten, prüfen Sie die Informationen zur Mac-Miete und gleichen Sie Nutzungszeit, Kursregeln und benötigte Projektaufgaben ab. Für lange, regelmäßig anfallende Entwicklungsarbeit oder Aufgaben mit notwendigem physischem Gerätezugriff kann ein eigener Mac die passendere Wahl sein.