App-Lokalisierungsdateien übersetzen: alle Keys und Platzhalter bleiben intakt

Warum lange String-Dateien allgemeine KI-Assistenten überfordern

Eine Lokalisierungsdatei ist ebenso Code wie Text. Um sie in einem Chat zu übersetzen, muss der Assistent die ganze Datei wieder ausgeben, mit Keys, Klammern, Maskierungen und allem, und eine Datei mit einigen Tausend Strings ist länger als eine einzelne Antwort. Er bricht mittendrin ab oder bittet Sie weiterzumachen, und Sie müssen die Teile selbst zusammensetzen.

Das zweite Problem ist die Syntax. Ein versehentlich übersetzter Key, ein {count}, das zu {cuenta} wurde, ein %1$s ohne Dollarzeichen, ein nicht maskierter Apostroph in strings.xml: Jedes davon ist eine kleine Änderung in einer langen Antwort, und jedes kann einen Build brechen oder Ihren Nutzern einen rohen Platzhalter anzeigen.

Dieses Tool lässt nie ein Modell Ihre Datei neu schreiben. Es liest die Datei in Strings ein und sendet nur den Text, mit dem Key und etwaigen Entwicklerkommentaren als Kontext, in Blöcken von bis zu 60 Strings und verlangt für jeden String genau eine Antwort. Inline-Tags werden zuvor durch kurze Markierungen ersetzt. Jede Antwort wird geprüft: gleiche Platzhalter, gleiche Maskierungen wie \n, gleiche Markierungen, die von Ihnen aufgelisteten Namen und jede Pluralform. Ein String, der durchfällt, wird erneut angefragt; schlägt das zweimal fehl, bleibt der Ausgangstext stehen und der String wird für Sie aufgelistet. Danach wird die Datei aus Ihrem Original neu aufgebaut.

Was Nutzer übersetzen

• React-, Vue-, Angular- und Next.js-Apps: JSON-Dateien für i18next, vue-i18n, react-intl und ngx-translate
• Flutter-Apps: .arb-Dateien, mit @metadata-Beschreibungen als Kontext
• WordPress-Plugins und -Themes, Django und andere gettext-Projekte: .pot-Vorlagen und .po-Dateien
• Android-Apps: res/values/strings.xml mit String-Arrays und Plurals
• iOS- und macOS-Apps: Localizable.strings und String Catalogs (.xcstrings)
• Dateien, die aus einer Übersetzungsplattform oder aus Xcode als XLIFF exportiert wurden

Was das Tool nicht kann

YAML-, .properties-, .resx- und .stringsdict-Dateien liest das Tool noch nicht. Fehlende i18next-Pluralschlüssel (key_one, key_few), die in Ihrer Quelldatei nicht vorkommen, ergänzt es ebenfalls nicht: Es übersetzt die Schlüssel, die Sie haben. In .xcstrings-Dateien bleiben Strings mit Substitutionen oder Gerätevarianten unverändert.

Bereits vorhandene Übersetzungen werden nicht überschrieben: Ausgefüllte PO-Einträge, als übersetzt markierte XLIFF-Targets und String-Catalog-Einträge in Ihrer Sprache bleiben, wie sie sind. Eine Zahlung deckt bis zu 20 Dateien und 5,000 Strings ab; Unlimited deckt bis zu 15,000 Strings pro Auftrag ab.

Es handelt sich um maschinelle Übersetzung mit Strukturprüfungen. Sie eignet sich gut, um schnell eine erste Version einer Sprache auszuliefern und ein Projekt aktuell zu halten. Bei Store-Einträgen, Rechtstexten oder allem mit eigener Markensprache sollte ein Muttersprachler das Ergebnis prüfen.

So gelingt ein gutes Ergebnis

Der Kontext macht den Unterschied zwischen „Speichern“ als Verb und „Sparen“ im Sinne eines Rabatts. Schlüssel wie settings.save_button und Kommentare in Ihrer Datei (#. in PO, @key-Beschreibungen in ARB, /* Kommentare */ in .strings) werden mit jedem String mitgeschickt. Eine Datei mit aussagekräftigen Schlüsseln und ein paar Kommentaren wird daher besser übersetzt.

Tragen Sie Ihre App- und Produktnamen unter „Nie übersetzen“ ein und wählen Sie bei Sprachen mit beiden Formen zwischen Sie- und Du-Ansprache bzw. der jeweiligen formellen und informellen Anrede. Nutzen Sie die kostenlosen Strings als Test und prüfen Sie nach dem Freischalten die Warnliste: Jeder Eintrag zeigt den Schlüssel, das Problem und die Ausgabe des Modells.