Wie man Drupal .po-Dateien mit KI übersetzt
Die meisten Menschen assoziieren .po-Dateien mit WordPress, aber das gettext-Format existiert bereits Jahrzehnte vor WordPress und ermöglicht die Oberflächenübersetzung in der gesamten Open-Source-Welt. Drupal ist einer seiner größten Nutzer. Wenn Sie eine mehrsprachige Drupal-Website betreiben, fließt jedes Menülabel, jede Feldbeschreibung, Fehlermeldung und Modul-Zeichenkette durch .po-Dateien, genau wie in WordPress, nur mit einem anderen Platzhalter-Dialekt und einem anderen Import-Workflow. Und genau wie bei WordPress, sobald Ihre Website über eine Handvoll Zeichenketten hinauswächst, wird das manuelle Übersetzen dieser Dateien zum Engpass.
Dieser Leitfaden erklärt, wie man Drupal .po-Dateien mit KI übersetzt, ohne die Dinge zu zerstören, die Drupal zu Drupal machen. Wir werden das Übersetzungssystem von Drupal durchgehen, woher die Zeichenketten tatsächlich stammen, die Platzhalter-Syntax, die sich von WordPress unterscheidet und unbedingt erhalten bleiben muss, und den vollständigen Export-, Übersetzungs- und Re-Import-Zyklus einschließlich der drush-Befehle, die ihn wiederholbar machen.
Wie das Übersetzungssystem von Drupal funktioniert
Drupal handhabt die Oberflächenübersetzung über das Kernmodul locale (manchmal in modernem Drupal auch „Interface Translation“ genannt). Einmal aktiviert, verwaltet es eine Datenbanktabelle mit Quellzeichenketten und deren Übersetzungen pro Sprache, und es kann diese Übersetzungen als Standard-gettext-.po-Dateien importieren und exportieren.
Das Admin-Interface befindet sich unter /admin/config/regional/translate. Von dort aus können Sie unübersetzte Zeichenketten suchen, sie direkt bearbeiten und, was entscheidend ist, eine .po-Datei importieren, um Übersetzungen massenhaft zu laden, oder den aktuellen Stand in eine .po-Datei exportieren, um sie offline zu bearbeiten. Dieser Export-/Bearbeitungs-/Importzyklus ist der Workflow, den wir optimieren.
Im Gegensatz zu WordPress, wo jedes Plugin und Theme seine eigenen .po- und .mo-Dateien in einem languages/-Verzeichnis liefert, zentralisiert Drupal die Oberflächenzeichenketten in seiner Datenbank und behandelt .po als Austauschformat. Sie exportieren, bearbeiten die Datei und importieren sie zurück. Der kompilierte .mo-Schritt, den WordPress erfordert, wird intern gehandhabt.
Woher die Zeichenketten kommen
Drupal-Zeichenketten stammen aus drei Quellen, und eine vollständige Übersetzung muss alle abdecken:
- Core liefert Tausende übersetzbarer Zeichenketten für die Admin-Benutzeroberfläche, Formulare und Systemmeldungen.
- Contrib-Module (Views, Webform, Commerce und der Rest) registrieren jeweils eigene Zeichenketten über die
t()-Funktion. - Themes steuern Template-Zeichenketten, Bereichsbezeichnungen und Theme-Einstellungsbeschreibungen bei.
Wenn Sie von /admin/config/regional/translate exportieren, können Sie den Export auf übersetzte, unübersetzte oder alle Zeichenketten eingrenzen. Für einen neuen Übersetzungsdurchlauf erhalten Sie durch den Export nur unübersetzter Zeichenketten eine fokussierte .po-Datei mit genau der noch zu erledigenden Arbeit.
Eine praktische Konsequenz dieser Drei-Quellen-Struktur: Ihre Übersetzungsarbeit ist nie wirklich „erledigt“. Jedes Mal, wenn Sie ein Contrib-Modul hinzufügen, eine neue Funktion aktivieren oder den Drupal-Core aktualisieren, erscheint eine neue Charge unübersetzter msgid-Einträge in den Locale-Tabellen. Aus diesem Grund behandeln Drupal-Teams die Übersetzung als einen wiederkehrenden Prozess statt als einmalige Startaufgabe. Der gleiche Export-, Übersetzungs-, Re-Import-Zyklus läuft bei jeder Bereitstellung, die Module betrifft, und je schneller dieser Zyklus ist, desto weniger Übersetzungsrückstand sammelt sich zwischen den Veröffentlichungen an.
Es ist auch erwähnenswert, dass Drupal gemeinschaftlich beigesteuerte Übersetzungen für Core und populäre Contrib-Module automatisch von localize.drupal.org abrufen kann. Diese decken die gängigen Zeichenketten ab, aber sie decken selten Ihre benutzerdefinierten Module, Ihr Theme oder die projektspezifischen Formulierungen ab, die Ihre Website tatsächlich verwendet. Die Lücke zwischen der Community-Übersetzung und einer vollständig lokalisierten Website ist genau die Arbeit, die ein KI-Durchlauf schnell schließt.
Drupal-Platzhalter sind keine WordPress-Platzhalter
Hier ist die wichtigste Erkenntnis, bevor Sie eine Drupal-.po-Datei an einen KI-Übersetzer senden: Drupal verwendet nicht die printf-ähnlichen %s- und %1$s-Platzhalter, die WordPress dominieren. Die t()-Funktion von Drupal verwendet drei verschiedene Platzhalter-Präfixe, jeder mit unterschiedlichem Escaping-Verhalten:
@variable— der Wert ist HTML-escaped, die sichere Standardeinstellung für benutzerdefinierte Texte.%variable— der Wert ist escaped und in<em>-Hervorhebungs-Markup eingeschlossen.:placeholder— wird für URL-Attribute verwendet, durchläuft eine URL-Bereinigung.
Eine typische Drupal-Quellzeichenkette sieht in der exportierten .po-Datei so aus:
#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""
#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""
Wenn ein Übersetzer @count in @cuenta ändert, @name durch das übersetzte Wort für „Name“ ersetzt oder ein Leerzeichen einfügt, das @count in @ count verwandelt, stimmt der Platzhalter nicht mehr mit dem überein, was der t()-Aufruf übergibt. Drupal gibt dann den literalen Token @count auf der Seite aus, anstatt der tatsächlichen Zahl. Die Übersetzung scheint fertig zu sein, aber die Website ist sichtbar fehlerhaft.
Dies ist die gleiche Art von Fehler, die WordPress-%s-Zeichenketten betrifft, und wir behandeln das allgemeine Prinzip ausführlich in Wie man PO-Dateien übersetzt, ohne Code-Variablen zu beschädigen. Der Drupal-Trick ist einfach, dass es drei Platzhalter-Stile anstelle von einem gibt, und ein Übersetzungstool muss alle erkennen.
Warum generische Übersetzer hier scheitern
Fügen Sie diese node.module-Zeichenkette in ein generisches maschinelles Übersetzungsfeld ein, und Sie werden häufig @count verstümmelt vorfinden, den <em>-gebundenen %date in ein anderes Token lokalisiert oder die Pluralformen zu einer zusammengefasst. Keines dieser Tools wurde mit gettext-Semantik im Hinterkopf entwickelt. Sie übersetzen Text; sie verstehen nicht, dass @count ein Vertrag mit dem Anwendungscode ist.
Eine gettext-sensible Übersetzungspipeline mit Syntax Locking behandelt @variable, %variable und :placeholder als unveränderliche Token. Sie werden vor der Übersetzung gesperrt und danach wiederhergestellt, so dass der umgebende Satz übersetzt wird, während die Platzhalter unberührt bleiben. Die gleiche Sperre deckt WordPress %s und %1$s, i18next {{name}} und Inline-HTML ab, weshalb ein einziges Tool ein Drupal-, Symfony- oder Laravel-Projekt so einfach bedienen kann wie ein WordPress-Projekt. Drupal-Pluralformen über msgid_plural bleiben als Pluralformen erhalten und werden nicht geglättet, was wichtig ist, da Drupal-Sprachen zwischen einer und sechs Pluralvarianten haben können.
Es gibt auch einen subtileren Fehlerfall, der es wert ist, erwähnt zu werden. Drupal-Zeichenketten betten häufig Inline-Markup und Links in den übersetzbaren Text ein, wie Read the <a href=":url">documentation</a>, wobei :url ein Platzhalter ist und die <a>-Tags überleben müssen. Ein Übersetzer, der die Struktur nicht versteht, könnte das href-Attribut übersetzen, den schließenden Tag weglassen oder den Platzhalternamen lokalisieren. Context-Aware AI, die die gesamte Zeichenkette als Einheit liest, kombiniert mit Token-Sperrung, hält sowohl das Markup als auch den :url-Vertrag intakt, während nur der menschenlesbare Text „documentation“ dazwischen übersetzt wird.
Der Export-, Übersetzungs- und Re-Import-Zyklus
Der wiederholbare Workflow hat drei Phasen, und drush macht den Export und Import skriptfähig, so dass Sie nicht jedes Mal durch die Admin-Benutzeroberfläche klicken müssen.
Schritt 1: Die PO-Datei exportieren
Sie können über die Benutzeroberfläche unter /admin/config/regional/translate exportieren, indem Sie eine Sprache und einen Exportbereich auswählen, oder dies über die Kommandozeile tun. Das Locale-Modul macht den Export über die Übersetzungsdienste von Drupal zugänglich, und die meisten Teams skripten es. Ein typischer drush-Aufruf zum Auslösen eines Übersetzungsimports (das Gegenteil, das wir in Schritt drei verwenden) sieht so aus:
# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
--type=customized --override=all
# Rebuild caches so the new strings render immediately
drush cache:rebuild
Für den Export erstellt das Admin-Exportformular die .po-Datei; viele Teams binden den Locale-Exportdienst in einen kleinen benutzerdefinierten Drush-Befehl für die vollständige Automatisierung ein. So oder so erhalten Sie eine Standard-gettext-.po-Datei, die Ihre unübersetzten msgid-Einträge enthält.
Schritt 2: Die Datei übersetzen
Dies ist die Phase, in der KI stundenlange manuelle Bearbeitung ersetzt. Laden Sie die exportierte .po-Datei in einen Cloud-Übersetzer hoch, wählen Sie Ihre Zielsprache und lassen Sie ihn verarbeiten. Da Drupal-.po-Dateien für eine große Website regelmäßig über 10 MB hinausgehen, sobald Core, Contrib-Module und Themes kombiniert sind, ist Smart Batching hier wichtig: Die Datei wird in Chunks zerlegt, übersetzt und wieder zusammengesetzt, ohne dass Sie sie manuell aufteilen oder an Größenbeschränkungen stoßen müssen. Das Ergebnis ist eine vollständige .po-Datei, bei der jeder msgstr gefüllt ist und jeder @count-, %date- und :url-Platzhalter genau dort ist, wo er begonnen hat.
Schritt 3: Zurück nach Drupal importieren
Importieren Sie die übersetzte Datei über /admin/config/regional/translate oder über den oben gezeigten drush locale:import-Befehl zurück und erstellen Sie dann den Cache neu. Drupal führt die Übersetzungen in seine Locale-Tabellen zusammen, und die Zeichenketten erscheinen sofort auf der gesamten Website. Führen Sie den Zyklus erneut aus, wann immer Sie ein Modul hinzufügen oder den Core aktualisieren, da jedes neue unübersetzte Zeichenketten mit sich bringt.
Ein Importdetail, das richtig gemacht werden muss: Das --override-Flag steuert, ob eingehende Übersetzungen bestehende ersetzen. Verwenden Sie --override=all, wenn Sie möchten, dass die KI-übersetzte Datei maßgeblich ist, oder eine konservativere Einstellung, wenn Sie bestimmte Zeichenketten in der Drupal-Benutzeroberfläche manuell angepasst haben, die Sie nicht überschrieben haben möchten. Für die meisten automatisierten Pipelines hält die Behandlung der .po-Datei als Wahrheitsquelle und das Überschreiben von allem das System vorhersehbar: Die Datei in der Versionskontrolle ist das, was die Website anzeigt, Punkt.
Für mehrsprachige Websites mit mehreren Zielsprachen läuft der Zyklus einmal pro Sprache. Exportieren Sie den unübersetzten Satz, übersetzen Sie ihn ins Deutsche, importieren Sie ihn; exportieren Sie erneut, übersetzen Sie ins Spanische, importieren Sie ihn; und so weiter. Da jede Sprache eine unabhängige .po-Datei ist, können Sie sie parallel ausführen, und ein Cloud-Übersetzer, der sie gleichzeitig verarbeitet, verwandelt, was früher eine Woche Auftragnehmerzeit war, in einen Nachmittag.
Drupal PO ist eines von mehreren Formaten
Es ist erwähnenswert, dass gettext-.po nicht die einzige Möglichkeit ist, wie Drupal Übersetzungen handhabt. Konfigurations- und Inhaltsentitäten können auch als XLIFF ausgetauscht werden, was der Standard ist, auf den sich das Translation Management Tool (TMGMT) Modul für professionelle Übersetzungsanbieter-Workflows stützt. Wenn Ihre Drupal-Lokalisierung über XLIFF statt über Interface-.po-Dateien läuft, sind die Prinzipien der Platzhalterbewahrung identisch, aber die Dateistruktur unterscheidet sich, und wir behandeln diesen Weg in Übersetzung von XLIFF-Dateien für Drupal, Symfony und Angular.
Für die Oberflächenübersetzungsschicht bleibt jedoch .po das Arbeitstier. Der Export-, KI-Übersetzungs-, Re-Import-Zyklus verwandelt eine mehrtägige manuelle Aufgabe in wenige Minuten Verarbeitung, und solange das von Ihnen verwendete Tool gettext-Platzhalter wirklich versteht, bleiben Ihre @variable-Verträge intakt und Ihre Drupal-Website in jeder ausgelieferten Sprache intakt.
Bereit, Ihre Drupal-
.po-Dateien zu übersetzen, ohne ein einziges@variablezu beschädigen? Testen Sie SimplePoTranslate kostenlos — keine Kreditkarte erforderlich. Die kostenlose Stufe verarbeitet Standard-gettext-.po- und.pot-Dateien mit vollständiger Syntaxsperrung, damit Ihre Drupal-Platzhalter genau so durchlaufen, wie es der Code erwartet.