OpenL logo

So übersetzen Sie PO-Dateien, ohne Ihre App zu beschädigen

OpenL Team 7/3/2026
So übersetzen Sie PO-Dateien, ohne Ihre App zu beschädigen

TABLE OF CONTENTS

PO-Dateien sehen wie einfache Textdateien aus – bis ein übersetztes %s, eine fehlende Pluralform oder ein bearbeitetes msgid Ihre App zum Absturz bringt. Verwenden Sie diesen Workflow, um die für Nutzer sichtbaren Zeichenketten zu übersetzen und dabei die gettext-Struktur unverändert zu lassen.

Kopieren Sie niemals die gesamte Datei in einen normalen Textübersetzer. Eine PO-Datei ist Quellcode-nah: Die Wörter sind übersetzbar, aber die Dateistruktur, Platzhalter, Kommentare und Pluralindizes müssen unverändert bleiben.

Methode 1: Verwenden Sie einen PO-Datei-Übersetzer

Wählen Sie diese Methode, wenn Sie einen schnellen, sicheren Erstentwurf möchten und die msgid- / msgstr-Paare nicht von Hand bearbeiten wollen.

  1. Sichern Sie die originale .po-Datei. Legen Sie vor dem Versand an einen Übersetzer eine saubere Kopie in Ihrem Repository ab. Falls die übersetzte Datei Fehler aufweist, benötigen Sie eine funktionierende Version zum Vergleich.

  2. Öffnen Sie einen PO-fähigen Übersetzer. Nutzen Sie ein Tool, das für gettext-Dateien entwickelt wurde, wie zum Beispiel OpenL PO Translator, ein Dokumentenübersetzer mit nutzungsbasierter Abrechnung. Ein PO-fähiges Tool sollte die Zieltexte übersetzen und dabei Quelltexte, Kommentare, Platzhalter und die Dateistruktur erhalten. Wenn Sie noch ein Tool auswählen, vergleichen Sie die Optionen in unserem Leitfaden zum besten PO-Übersetzer.

  3. Laden Sie die .po-Datei hoch. Verwenden Sie die Sprachdatei, die msgid- und msgstr-Einträge enthält. Falls Sie nur eine .pot-Vorlage haben, erstellen Sie daraus zunächst eine .po-Datei in der Zielsprache und laden Sie dann diese hoch.

  4. Wählen Sie Quell- und Zielsprache aus. Stimmen Sie die Quellsprache auf den Text im msgid ab, nicht auf die Sprache Ihrer Administrationsoberfläche. Enthält die Datei beispielsweise englische msgid-Strings und Sie benötigen eine spanische Übersetzung, wählen Sie Englisch zu Spanisch.

  5. Laden Sie die übersetzte Datei herunter. Speichern Sie sie nach dem Namensschema, das Ihr Framework erwartet. WordPress-Plugins verwenden oft ein Textdomain-plus-Locale-Muster, während Django Dateien meist unter locale/<language>/LC_MESSAGES/ ablegt.

  6. Überprüfen Sie zuerst die riskanten Zeichenfolgen. Suchen Sie in der übersetzten Datei nach %, {, }, <, >, msgid_plural, msgctxt und #, fuzzy. Diese Einträge beeinflussen am ehesten das Laufzeitverhalten.

  7. Testen Sie die übersetzte Datei in Ihrer App. Laden Sie die Sprache lokal und klicken Sie sich durch die Bildschirme, auf denen die übersetzten Zeichenfolgen verwendet werden. Eine PO-Datei ist nicht fertig, wenn sie übersetzt ist, sondern erst, wenn die App weiterhin korrekt dargestellt wird.

Methode 2: PO-Dateien mit Poedit übersetzen

Wählen Sie diese Methode, wenn Sie eine menschliche Überprüfung, WordPress-Kompatibilität oder einen sorgfältigen, eintragweisen Arbeitsablauf benötigen.

  1. Öffnen Sie die Datei in Poedit. Poedit ist ein spezieller Übersetzungseditor für PO- und andere Lokalisierungsformate; der Basis-Editor ist kostenlos, für umfangreichere Arbeitsabläufe gibt es kostenpflichtige Pro-Funktionen. Für WordPress erklärt das offizielle Polyglots-Handbuch, dass Poedit .po- und .mo-Dateien aus einer POT-Datei erstellen kann und Pluralformen sowie UTF-8 unterstützt.

  2. Aktualisieren Sie anhand der POT-Vorlage, falls sich der Quelltext geändert hat. Wenn Entwickler den App-Text geändert haben, aktualisieren Sie die .po-Datei vor der Übersetzung anhand der neuesten .pot. So bleiben neue, entfernte und unscharfe Zeichenfolgen sichtbar, anstatt veraltete UI-Texte unbemerkt auszuliefern.

  3. Übersetzen Sie nur das Feld msgstr. Das msgid ist die Quellzeichenfolge, mit der Ihre App die Übersetzung abruft. Im normalen gettext-Workflow sollten Übersetzer nur msgstr bearbeiten, nicht msgid.

  4. Platzhalter exakt beibehalten. Übersetzen oder verändern Sie keine Variablen wie %s, %d, %1$s, {name}, %(count)s, :name oder HTML-Tags. Falls sich die Wortstellung ändern muss, verschieben Sie den Platzhalter als Einheit.

  5. Behandeln Sie Pluralformen als separate Übersetzungen. Ein Plural-Eintrag kann msgid, msgid_plural und mehrere msgstr[n]-Werte enthalten. Füllen Sie jedes für die Zielsprache erforderliche Pluralfeld aus, anstatt überall denselben Satz zu kopieren.

  6. Speichern und kompilieren Sie die .mo-Datei, falls Ihre App sie benötigt. Manche Stacks lesen .po-Dateien direkt während der Entwicklung, aber WordPress und viele gettext-Setups verwenden zur Laufzeit kompilierte .mo-Dateien. Poedit kann .mo-Dateien beim Speichern kompilieren; in Django können Sie Nachrichten mit django-admin compilemessages kompilieren.

  7. Beheben Sie Warnungen vor dem Hochladen. In Poedit weisen Warnsymbole oft auf fehlerhafte Platzhalter, fehlende Variablen oder Unstimmigkeiten bei Pluralformen hin. Beheben Sie diese Probleme, bevor Sie die Übersetzung in WordPress, Django, Drupal oder Ihren Release-Branch importieren.

Methode 3: Eine Lokalisierungsplattform verwenden

Wählen Sie diese Methode, wenn mehrere Übersetzer, Prüfer oder Release-Manager an denselben PO-Dateien arbeiten müssen.

  1. Importieren Sie die PO-Datei in eine Plattform, die gettext unterstützt. Weblate und ähnliche Lokalisierungsplattformen unterstützen PO-Workflows. Team-Lokalisierungsplattformen sind oft kostenpflichtig, allerdings bietet Weblate auch eine quelloffene, selbst gehostete Option. Die Behandlung von Kommentaren, Headern, unscharfen Strings und Platzhaltern unterscheidet sich je nach Plattform, daher sollten Sie die Format-Einstellungen prüfen, bevor Sie Produktionsdateien hochladen.

  2. Stellen Sie Prüfungen für Platzhalter und Tags ein. Aktivieren Sie QA-Regeln für printf-ähnliche Platzhalter, benannte Variablen, HTML/XML-Tags und Pluralformen. Diese Prüfungen erkennen Fehler, die normale Rechtschreibprüfungen nicht finden.

  3. Halten Sie Entwicklerkommentare sichtbar. PO-Kommentare können Kontext wie Quellverweise, extrahierte Entwicklernotizen, Flags und vorherige Quelltexte enthalten. Übersetzer benötigen diese Hinweise, wenn ein kurzes UI-Label wie „Öffnen“ ein Verb, Adjektiv oder Menü-Befehl sein könnte.

  4. Verwenden Sie Translation Memory mit Überprüfung. Translation Memory ist nützlich für wiederkehrende UI-Strings, kann aber eine alte Übersetzung in einen neuen Kontext kopieren. Überprüfen Sie wiederverwendete Strings, wenn sich msgctxt, Quellverweise oder das umgebende UI geändert haben.

  5. Exportieren Sie PO-Dateien und führen Sie lokale Prüfungen durch. Verlassen Sie sich nicht blind auf den Export. Fügen Sie die übersetzte Datei wieder in die App ein, kompilieren Sie sie falls nötig und testen Sie die Ansichten, bevor Sie zusammenführen.

PO-Datei-Regeln, die Sie niemals brechen sollten

PO-ElementÜbersetzen?Sicheres BeispielWarum ist es wichtig?
msgidNeinmsgid "Save changes"Die App verwendet diesen Quellstring als Suchschlüssel in vielen gettext-Workflows.
msgstrJamsgstr "Guardar cambios"Dies ist der Zielsprach-Text, den die Nutzer sehen.
msgctxtNeinmsgctxt "button"Kontext hilft, identische Quellstrings zu unterscheiden.
%s, %d, %1$sNeinHello, %s -> Hola, %sDiese Platzhalter werden zur Laufzeit durch aktuelle Werte ersetzt.
{name}, %(count)s, :nameNeinWelcome, {name}Benannte Variablen müssen weiterhin mit dem App-Code übereinstimmen.
HTML-TagsMeistens nein<strong>Warning</strong>Übersetze den Text, nicht die Tag-Syntax.
msgid_pluralNeinmsgid_plural "%d files"Die Quell-Pluralform gehört zum ursprünglichen Codepfad.
msgstr[0], msgstr[1]Ja, mit Sorgfaltmsgstr[0] "%d file"Jede Zielsprache hat eigene Pluralregeln.
#, fuzzyErst prüfen#, fuzzyFuzzy bedeutet, die Übersetzung ist möglicherweise veraltet oder unbestätigt.
#. EntwicklerkommentareMeistens nein#. Button labelDiese Hinweise helfen Übersetzern, den Kontext zu verstehen.

Kurzes Beispiel: Sichere vs. fehlerhafte PO-Übersetzung

Hier ein normaler gettext-Eintrag:

#. %s is the user's display name.
#, c-format
msgid "Welcome back, %s"
msgstr ""

Eine sichere spanische Übersetzung lässt %s unverändert:

#. %s is the user's display name.
#, c-format
msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, %s"

Eine fehlerhafte Übersetzung verändert den Platzhalter:

msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, % s"

Dieses kleine Leerzeichen kann entscheidend sein. GNU msgfmt --check-format ist dafür gemacht, Formatstring-Fehler wie falsche %-Platzhalter zu erkennen, und auch Poedit warnt vor häufigen Platzhalter-Problemen. Für eine umfassendere Liste von Strings, die unverändert bleiben sollten, nutze unseren Leitfaden zu was nicht übersetzt werden darf.

Wie man eine übersetzte PO-Datei überprüft

  1. Führen Sie eine Gettext-Validierung durch, wenn Sie Gettext installiert haben.
msgfmt --check --check-format -o /tmp/messages.mo path/to/messages.po

Dies prüft Syntax, Header und Format-Strings und schreibt dann einen temporären kompilierten Katalog, falls die Datei gültig ist.

  1. Kompilieren Sie die Datei so, wie es Ihr Framework erwartet.
django-admin compilemessages

Für Django-Projekte kompiliert compilemessages die von makemessages erstellten .po-Dateien in .mo-Dateien für die Gettext-Unterstützung.

  1. Suchen Sie nach leeren Übersetzungen.
grep -n 'msgstr ""' path/to/messages.po

Leere msgstr-Felder können für nicht übersetzte Einträge beabsichtigt sein, sollten Sie aber beim Release nicht überraschen.

  1. Suchen Sie nach unsicheren („fuzzy“) Strings.
grep -n '#, fuzzy' path/to/messages.po

Unsichere („fuzzy“) Strings sollten vor dem Release von einer Person überprüft werden. Standardmäßig verwendet msgfmt keine unsicheren Übersetzungen, es sei denn, Sie kompilieren mit --use-fuzzy. Daher kann ein unsicherer Eintrag im endgültigen Katalog wie ein nicht übersetzter String behandelt werden.

  1. Testen Sie die echte Benutzeroberfläche. Öffnen Sie die Ansichten, die Formulare, Pluralformen, Fehlermeldungen, Kontomenüs und Zahlungsabläufe enthalten. Die PO-Validierung erkennt Dateiprobleme; nur das Testen der Benutzeroberfläche deckt ungeschickte Formulierungen, Überläufe und fehlenden Kontext auf.

Welche Methode sollten Sie verwenden?

SituationBeste MethodeWarum
Sie benötigen einen schnellen ersten Entwurf für eine PO-DateiPO-Datei-ÜbersetzerSchnellster Weg mit Erhalt der Struktur
Sie pflegen ein WordPress-Plugin oder ThemePoeditVertrauter WordPress-Workflow mit .mo-Kompilierung
Sie pflegen eine Django-AppPO-Übersetzer oder Poedit, dann compilemessagesÜbersetzung kann schnell erfolgen, aber Framework-Kompilierung ist weiterhin erforderlich
Sie haben viele Sprachen und PrüferLokalisierungsplattformBessere Zuweisung, Historie, QA und Kontrollmöglichkeiten für Reviews
Sie übersetzen Entwickler-nahe StringsMenschliche Prüfung nach maschineller ÜbersetzungCodebegriffe, Platzhalter und Kontext sind wichtiger
Sie lokalisieren auch JSON- oder Frontend-i18n-DateienFormat-spezifischer Workflow verwendenPO-Regeln gelten nicht immer für JSON, YAML oder ICU-Nachrichten

Wenn Ihr Projekt gettext-PO-Dateien mit JSON-Locale-Dateien mischt, übersetzen Sie jedes Format mit einem Tool, das dessen Struktur versteht. PO-Dateien basieren auf msgid und msgstr; JSON-Lokalisierung basiert auf Schlüsseln und Werten. Für diesen Workflow siehe unseren Leitfaden zu den besten JSON-Übersetzern im Jahr 2026.

FAQ

Kann ich PO-Dateien mit Google Translate übersetzen?

Sie können einzelne msgstr-Werte in einen allgemeinen Übersetzer kopieren, aber das Hochladen oder Einfügen der gesamten PO-Datei in einen reinen Textübersetzer ist riskant. Allgemeine Übersetzer können msgid, Kommentare, Anführungszeichen, Plural-Indizes oder Platzhalter verändern. Verwenden Sie stattdessen einen PO-spezifischen Übersetzer, Poedit oder eine Lokalisierungsplattform.

Was ist der Unterschied zwischen .po, .pot und .mo?

.pot ist die Vorlage, die aus dem Quellcode extrahiert wird. Sie enthält normalerweise Originalstrings, aber keine fertigen Übersetzungen. .po ist die bearbeitbare Übersetzungsdatei für eine Zielsprache. .mo ist der kompilierte Binärkatalog, den viele auf gettext basierende Apps zur Laufzeit laden.

Sollte ich msgid übersetzen?

Nein, nicht im normalen Arbeitsablauf. Übersetze msgstr. Das GNU gettext-Handbuch beschreibt msgid als den ursprünglichen, nicht übersetzten String und msgstr als die Übersetzung; msgid-Strings werden von gettext-Tools erzeugt und verwaltet.

Wie prüfe ich, ob eine PO-Datei gültig ist?

Führe msgfmt --check --check-format aus, wenn gettext verfügbar ist, öffne die Datei in Poedit oder nutze die QA-Prüfungen deiner Lokalisierungsplattform. Anschließend die Datei kompilieren und in der App testen. Die Validierung ist notwendig, ersetzt aber kein UI-Testing.

Was passiert, wenn ich einen Platzhalter beschädige?

Im besten Fall zeigt die App einen seltsamen String an. Im schlimmsten Fall wirft der Runtime-Formatter einen Fehler, weil der übersetzte String nicht mehr zu den vom Code übergebenen Variablen passt. Platzhalter dürfen nur als vollständige Tokens verschoben, niemals übersetzt oder teilweise bearbeitet werden.

Kann OpenL PO-Dateien übersetzen?

Ja. OpenL PO Translator ist speziell für gettext-.po-Dateien entwickelt und gibt an, Platzhalter und Variablen beim Übersetzen in über 100 Sprachen unverändert zu lassen. Es nutzt einen Pay-per-Use-Workflow für Dokumentübersetzungen – ideal für einen schnellen ersten Entwurf, wenn der Erhalt der PO-Struktur wichtiger ist als eine vollständige manuelle Bearbeitung. Wenn du nur eine .pot-Vorlage hast, erstelle vor der Nutzung von OpenL eine .po-Datei in der Zielsprache.

Quellen

Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp