Eine Gettext-Checkliste für die Python-Lokalisierung

Ist die jeweilige Python-Anwendung überhaupt bereit für eine Übersetzung?

Bei der Lokalisierung kann das gettext-Modul helfen, aber es ist nicht in der Lage, unklaren Quellcode, vage Platzhalter, uneinheitliche Terminologie oder Produkttexte, die nur auf Englisch funktionieren, zu beheben. Bevor Zeichenfolgen also zur Übersetzung gesendet werden, muss die App einer grundlegenden Prüfung hinsichtlich Software-Internationalisierung und -Lokalisierung unterzogen werden. Andernfalls besteht die Gefahr, ein mehrsprachiges Produkt zu erstellen, das technisch zwar funktioniert, sich aber ungeschickt, uneinheitlich oder unvollständig anfühlt.

Wofür das gettext-Modul in Python zuständig ist

In der Python-3-Dokumentation wird gettext als Modul beschrieben, das Internationalisierungsfunktionen für Python-Module und -Anwendungen bereitstellt. In der Praxis ermöglicht das gettext -Modul einer Python-Anwendung, Meldungskataloge anstelle von fest codierten, für den Benutzer sichtbaren Zeichenfolgen zu verwenden.

Ein typischer GNU-gettext-Workflow sieht so aus: Entwickler markieren die entsprechenden Strings im Quellcode, extrahieren sie in eine .pot -Datei, legen für jedes Locale eine eigene .po-Datei an und kompilieren die fertigen Übersetzungen anschließend in binäre .mo-Dateien. Zur Laufzeit verwendet die Anwendung dann das aktuelle Locale oder einen ausgewählten Sprachcode, um die passende Übersetzung anzuzeigen.

Python unterstützt dieses GNU-gettext-Modell über die Standardbibliothek. Es ist nach wie vor ein gängiger Ansatz für Python i18n und l10n, besonders wenn man einen verlässlichen Lokalisierungsprozess für Anwendungen, Kommandozeilentools oder Python-Module braucht.

Gettext ist allerdings nur der technische Mechanismus. Der eigentliche Lokalisierungsablauf geht deutlich darüber hinaus.

Weshalb Übersetzungsprobleme meist im Code entstehen

Ein Übersetzungsprojekt beginnt also mit der Frage, ob die Originaltexte im Code überhaupt für eine andere Sprache taugen.

Nehmen wir eine Buchungsplattform als Beispiel. Eine Fehlermeldung wie „Aktion fehlgeschlagen" erscheint im Code oft an zehn verschiedenen Stellen – bei einer abgelehnten Zahlung, einer abgelaufenen Sitzung, einem doppelten Buchungsversuch usw. Im Code selbst ist das kein Problem, weil der umgebende Kontext klar macht, welche der zehn Situationen gemeint ist. Ein Übersetzer sieht aber nur die isolierte Zeile in der .po-Datei und muss raten.

Ähnlich kritisch ist die Art, wie Werte in Sätze eingebaut werden. Ein Datum, das im Code als reiner Zahlenstring zusammengesetzt wird – etwa „15/03/2026" – funktioniert zwar in Sprachen mit Tag-Monat-Reihenfolge, kollidiert aber in einer Sprache, die zuerst das Jahr nennt. Solche Formatierungsentscheidungen gehören in die Locale-Logik, nicht in einen manuell gebauten String.

Zahlwörter sind ein eigenes Kapitel. „2 Zimmer verfügbar" und „1 Zimmer verfügbar" brauchen in vielen Sprachen nicht zwei, sondern drei oder vier grammatische Formen – ein Umstand, den ein einzelner, hart codierter Satz niemals abbildet.

Wird das erst nach dem Export bemerkt, betrifft die Korrektur nicht mehr nur den Quellcode, sondern auch die bereits verteilten po-Dateien und jede Übersetzung, die auf Basis des alten, unklaren Strings schon entstanden ist. Der Katalog selbst zeigt diese Mängel nicht an. Das lässt sich nur vorher im Code prüfen.

Fünf typische Probleme bei der Lokalisierung von Python-Anwendungen

Ein Klassiker ist das Zusammenkleben von Satzteilen im Code, etwa nach dem Muster „Ihre" + anzahl + „Artikel wurden versendet". Solche Konstruktionen sind im Original meist unauffällig, brechen aber in Sprachen mit anderer Wortstellung oder mit grammatischem Geschlecht regelrecht auseinander. Ein vollständiger, in sich stehender Satz lässt sich dagegen als Ganzes übersetzen, ohne dass die Übersetzung von der Position eines eingefügten Werts abhängt.

Ein zweites, oft übersehenes Problem sind Texte außerhalb der sichtbaren Benutzeroberfläche: automatische Bestätigungsmails, Push-Benachrichtigungen, Texte in PDF-Exporten oder Meldungen in Log-Dateien, die dem Nutzer versehentlich angezeigt werden. Ein Produkt kann in der Haupt-App makellos lokalisiert sein und trotzdem an jeder dieser Randstellen in die Ausgangssprache zurückfallen.

Vage Platzhalter sind das dritte typische Problem. Ein Platzhalter wie %s sagt dem Übersetzer nichts. Benannte Platzhalter wie {user_name}, {event_name} or {amount} geben mehr Kontext und senken das Risiko fehlerhafter Übersetzungsdateien. Eine Python-Anwendung könnte zum Beispiel so eine nutzerseitige Meldung erzeugen:

import gettext

_ = gettext.gettext

Diese Variante ist schwieriger zu übersetzen, weil der Platzhalter anonym ist:

message = _("%s wurde hinzugefügt") % item_name

Der Übersetzer sieht nur %s wurde hinzugefügt. Er weiß nicht, worauf sich %s bezieht, was genau hinzugefügt wurde oder wo die Meldung überhaupt erscheint.

Diese Variante ist klarer, weil der Platzhalter benannt und der Satz vollständig ist:

message = _("Produkt {product_name} wurde dem Warenkorb hinzugefügt").format(
    product_name=product_name
)

Der Unterschied ist keine Stilfrage. Bei benannten Platzhaltern kann eine Übersetzung die Reihenfolge frei anpassen, ohne dass die Werte an der falschen Stelle landen oder das Programm crasht, wenn ein Formatargument fehlt.

Viertens: nicht jeder String verträgt denselben Freigabeprozess. Ein Tooltip lässt sich frei und sinngemäß übersetzen; eine Widerrufsbelehrung oder ein Preisänderungshinweis eher nicht. Läuft beides durch dieselbe Prüfschleife, führt das entweder zu unnötiger Verzögerung bei harmlosen Texten oder zu einer zu knappen Prüfung bei rechtlich heiklen.

Fünftens landen in vielen .pot-Dateien Zeilen, die dort nichts verloren haben: Platzhaltertexte aus der Entwicklung, auskommentierte alte Versionen einer Meldung, interne Debug-Ausgaben. Jede dieser Zeilen kostet das Übersetzungsteam Zeit und verwässert den Übersetzungsspeicher mit Einträgen, die nie im Produkt erscheinen.

So unterschiedlich diese fünf Probleme auch klingen mögen, im Kern sind sie gleich: Sie werden im gettext-Workflow sichtbar, entstehen aber schon vorher, beim Schreiben des Codes.

Ein Vier-Punkte-Check vor dem ersten Export

Es empfiehlt sich, vor der Übersetzung des Python-Quellcodes eine kurze Überprüfung der Voraussetzungen durchzuführen.

• Textqualität im Code: Steht jeder übersetzbare String für sich allein verständlich da, ohne dass man den umgebenden Code kennen muss? Sind Sätze vollständig statt zusammengeklebt, Platzhalter benannt statt anonym, und ist für jede Zahlenangabe eine Pluralregel vorgesehen?
• Locale- und Formatlogik: Woher weiß die Anwendung, welche Sprache gilt, und was passiert, wenn diese Sprache fehlt? Werden Datum, Uhrzeit, Zahlenformat und Währung über die Locale-Bibliothek erzeugt statt im Code manuell zusammengebaut?
• Sauberkeit des Katalogs: Enthält die pot-Datei ausschließlich Texte, die tatsächlich im Produkt erscheinen? Bekommt jeder Eintrag genug Kontext, damit ein Übersetzer nicht raten muss, und wird die fertige mo-Datei im echten Programmablauf getestet statt nur einzeln überprüft?
• Definition von „fertig": Zählt eine Übersetzung schon als abgeschlossen, wenn alle Strings einen Eintrag im Katalog haben – oder erst, wenn Fehlermeldungen, Bestätigungen und kritische Entscheidungspunkte in der Zielsprache genauso klar funktionieren wie im Original?

Ein Programm, das gettext korrekt einbindet, ist noch kein lokalisiertes Produkt. Das eine ist Technik, das andere ist Sorgfalt an vielen kleinen Stellen im Code. Wer diesen Unterschied vor dem ersten Export klärt, entscheidet damit auch, wie viele Rückfragen später vom Übersetzungsteam kommen.