Sprachdateien einer App, dreizehn Dateiendungen, dieselbe Aufgabe. Du hast eine JSON-Datei, eine strings.xml, eine PO-Datei oder einen String Catalog vor dir und möchtest dieselben Texte in fünf weitere Sprachen übertragen, ohne den Build zu beschädigen.
Das Format ändert sich. Die Aufgabe bleibt gleich: Schlüssel beibehalten, Platzhalter schützen, Werte übersetzen und das bei jedem Release wiederholen.
Welche Option solltest du wählen?
| Geeignet für | Grenzen | |
|---|---|---|
| AI Glot | Alle unten aufgeführten Formate, mehrere Sprachen in einem Auftrag, ein verbindliches Glossar und jedes Release | Für zehn Texte nicht nötig |
| Eine Übersetzungsmanagement-Plattform (Crowdin, Lokalise, Phrase) | Teams mit kontinuierlichem Workflow, Prüfern und Anbindung an ein Repository | Vor der ersten Übersetzung musst du ein Projekt einrichten und dein Repository verbinden |
| DeepL | XLIFF-Dateien bis zu 10 MB | Verarbeitet XLIFF, aber nicht die anderen hier aufgeführten Formate. Außerdem ersetzt das Glossar Begriffe, ohne zu berücksichtigen, warum sie festgelegt sind |
| ChatGPT, Claude oder ein anderer Assistent | Eine Handvoll Texte | Du musst den Prompt selbst schreiben und das Glossar in jeden Chat übertragen. Bei langen Dateien wird der Text langsam Token für Token ausgegeben und dein Nutzungslimit aufgebraucht. Bei jedem Durchlauf besteht das Risiko, dass ein Schlüssel geändert oder ein Platzhalter beschädigt wird |
| Ein freiberuflicher Übersetzer oder eine Agentur | Die App-Store-Seite und dein Onboarding | Langsam, Abrechnung pro Wort, und die Dateien musst du trotzdem selbst vorbereiten |
Beauftrage einen Menschen mit den fünf Texten, die deine App verkaufen: dem Store-Eintrag und dem ersten Bildschirm. Die Tausenden von Texten im Hintergrund kannst du durch ein Übersetzungssystem laufen lassen.
Wähle dein Dateiformat
Für jedes Format gibt es eine eigene Seite mit einem kostenlosen Tool und allen Details. Hier findest du das Wichtigste zu jedem Format.
| Datei | Speicherort | Wissenswertes |
|---|---|---|
| JSON | locales/en.json |
Die Schlüssel bleiben in derselben Reihenfolge. Platzhalter wie {count} werden durch deine Anweisungen geschützt |
| ARB (Flutter) | lib/l10n/app_en.arb |
Die Metadateneinträge mit @ werden übernommen. Setze @@locale auf die Zielsprache |
| YAML | config/locales/en.yml |
Platzhalter im Rails-Format wie %{name} werden erkannt. Kommentare werden beim Zurückschreiben der Datei entfernt |
| TOML | i18n/en.toml (Hugo) |
Nur Textwerte werden geändert. Kommentare bleiben normalerweise erhalten |
| XLIFF | Exporte aus deinen Tools | Versionen 1.2 und 2.0. Inline-Tags werden anhand der Quelldatei wiederhergestellt |
| PO und POT | locale/fr/LC_MESSAGES/app.po |
Für Pluralformen werden die Regeln der Zielsprache verwendet und der Plural-Forms-Header wird angepasst |
| Qt Linguist | app_fr.ts |
Pluralformen (numerus) werden noch nicht übersetzt. Führe anschließend lrelease aus |
| String Catalog | Localizable.xcstrings |
Alle Sprachen befinden sich in einer Datei. Ersetzungen und gerätespezifische Varianten bleiben unverändert |
| iOS .strings | fr.lproj/Localizable.strings |
Die Datei wird als UTF-8 zurückgegeben, Kommentarblöcke bleiben erhalten. Pluralformen in .stringsdict werden ebenfalls verarbeitet |
| Android XML | res/values-fr/strings.xml |
Pluralformen und String-Arrays werden verarbeitet. translatable="false" wird berücksichtigt |
| RESX und RESW | Resources.fr.resx |
Du erhältst eine Datei pro Sprache. Entwicklerkommentare bleiben auf Englisch |
| Java .properties | messages_fr.properties |
Nur UTF-8. Fasse Werte, die über eine zweite Zeile fortgesetzt werden, vorher in einer Zeile zusammen |
Nicht jedes Format speichert Sprachen auf dieselbe Weise. Ein String Catalog enthält alle Sprachen in einer Datei. Die meisten anderen Formate, darunter JSON, Android und iOS, enthalten eine Sprache pro Datei. Für jede Zielsprache brauchst du also eine eigene Datei.
So sieht eine übersetzte Datei aus
Nur die Werte ändern sich.
{ "cart.title": "Your cart", "cart.title": "Votre panier", "cart.items": "{count} items", "cart.items": "{count} articles", "cart.checkout": "Go to checkout" "cart.checkout": "Passer à la caisse"}Der Weg einer einzelnen Datei
- 1HochladenDie Datei in ihrer aktuellen FormOder eine ZIP-Datei mit mehreren Dateien
- 2Sagen Sie, was Sie brauchenSprachen und UmfangKostenlos
- 3Plan lesenStrings, Wörter, KostenKostenlos
- 4GenehmigenDer einzige kostenpflichtige SchrittVerbraucht Credits
- 5DownloadEine Datei pro SpracheEinfach einfügen
Bis zum vierten Schritt entstehen keine Kosten. Und einen falschen Plan kannst du kostenlos korrigieren.
So geht’s Schritt für Schritt
1. Teste kostenlos eine Datei. Auf jeder Formatseite findest du ein kostenloses Tool, für das du kein Konto brauchst.
2. Lade die Datei in der App hoch oder sende sie über die Kommandozeile. Wie das geht, erfährst du weiter unten.
3. Sag in einem Satz, was du brauchst.
Translate this file into French.
Skip every key that starts with "internal.".Der Satz legt fest, was in der gesamten Datei übersetzt wird. Regeln zur Formulierung selbst, zum Beispiel „jeden {placeholder} exakt so beibehalten“ oder „die informelle Anrede verwenden“, gehören bei der Freigabe ins zweite Feld. Sie werden auf jeden String so angewendet, wie er geschrieben ist.
4. Füge ein Glossar mit dem Produktnamen, den Funktionsnamen und den Begriffen hinzu, die deine App immer gleich verwendet. So erstellst du eins.
5. Wähle eine Qualitätsstufe.
Lite bietet etwa dreimal mehr Wörter pro Credit und ist schneller. Ideal für die vielen Einstellungen und Hilfetexte. Standard eignet sich für Strings, die Nutzer zuerst lesen. Ein Credit entspricht einem Wort in Standard.
6. Gib die Übersetzung frei und lade sie herunter.
Eine Datei, viele Sprachen
Die Dateinamen dienen als Beispiel. Für einen ganzen Ordner mit Sprachdateien packst du sie in eine ZIP-Datei: Bis zu 200 Dateien und 20 MB werden in einem einzigen Auftrag verarbeitet.
Drei Möglichkeiten, es auszuführen
Die Kommandozeile ist die Variante, die Entwickler immer wieder verwenden. Es sind dieselben vier Schritte, in einem Skript:
# 1. Create the job. Free. Returns a plan and an id.
id=$(aiglot batches create locales/en.json \
--instruction "Translate into French. Skip every key that starts with internal." \
--json | jq -r '.data.id')
# 2. Read the plan for free, then commit.
aiglot batches get "$id" --json | jq '.data.plan'
aiglot batches approve "$id" --quality lite \
--instructions "Keep every {placeholder} exactly as written."
# 3. When the status is completed, bring the file back.
aiglot batches download "$id" --output locales/fr.jsonMit deinem KI-Agenten: Binde AI Glot als MCP-Server ein. Der Agent kann dein Repository lesen, darin gefundene Glossarbegriffe vorschlagen, sie in deinen Arbeitsbereich übernehmen, den Auftrag ausführen und die Dateien wieder an ihren Platz legen.
In der App: hochladen, klicken, herunterladen. Gut für einen einmaligen Auftrag.
Eine API-Integration wird in der API-Dokumentation beschrieben.
Ergebnis prüfen
Erstelle die App in einer übersetzten Sprache und öffne die drei Bildschirme mit den längsten Texten. Lass anschließend wie gewohnt den Linter oder eine Prüfung auf fehlende Schlüssel laufen, denn ein geänderter Schlüssel wird als fehlender String angezeigt. Übersetzte Texte sind oft länger als das englische Original. Achte daher darauf, dass Schaltflächen und Beschriftungen nicht überlaufen.
Unter Preise siehst du, was ein größeres Volumen kostet. Ein kostenloses Konto enthält Guthaben, mit dem du eine echte Datei verarbeiten kannst.
Die hier genannten Limits galten zum Zeitpunkt der Erstellung: 200 Dateien und 20 MB pro ZIP-Datei. Das Limit von DeepL stammt aus der eigenen Dokumentation. Dateinamen und String-Anzahlen in den Diagrammen dienen nur als Beispiele. Die tatsächlichen Werte für deine Dateien findest du in deinem Tarif. Das Nachsehen ist kostenlos.