{"id":17475,"date":"2026-07-09T11:19:06","date_gmt":"2026-07-09T09:19:06","guid":{"rendered":"https:\/\/modilingua.com\/?p=17475"},"modified":"2026-07-09T11:19:06","modified_gmt":"2026-07-09T09:19:06","slug":"python-localization","status":"publish","type":"post","link":"https:\/\/modilingua.com\/de\/l10n-und-t9n\/anwendungen\/python-lokalisierung\/","title":{"rendered":"Eine Gettext-Checkliste f\u00fcr die Python-Lokalisierung"},"content":{"rendered":"

Ist die jeweilige Python-Anwendung \u00fcberhaupt bereit f\u00fcr eine \u00dcbersetzung?<\/p>\n\n\n\n

Bei der Lokalisierung kann das gettext<\/code>-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 \u00dcbersetzung gesendet werden, muss die App einer grundlegenden Pr\u00fcfung hinsichtlich Software-Internationalisierung<\/a> und -Lokalisierung unterzogen werden. Andernfalls besteht die Gefahr, ein mehrsprachiges Produkt zu erstellen, das technisch zwar funktioniert, sich aber ungeschickt, uneinheitlich oder unvollst\u00e4ndig anf\u00fchlt.<\/p>\n\n\n\n

Wof\u00fcr das gettext-Modul in Python zust\u00e4ndig ist<\/span><\/h2>\n\n\n\n

In der Python-3-Dokumentation<\/a> wird gettext<\/code> als Modul beschrieben, das Internationalisierungsfunktionen f\u00fcr Python-Module und -Anwendungen bereitstellt. In der Praxis erm\u00f6glicht das gettext<\/code> -Modul einer Python-Anwendung, Meldungskataloge anstelle von fest codierten, f\u00fcr den Benutzer sichtbaren Zeichenfolgen zu verwenden.<\/p>\n\n\n\n

Ein typischer GNU-gettext-Workflow sieht so aus: Entwickler markieren die entsprechenden Strings im Quellcode, extrahieren sie in eine .pot<\/code> -Datei, legen f\u00fcr jedes Locale eine eigene .po<\/code>-Datei an und kompilieren die fertigen \u00dcbersetzungen anschlie\u00dfend in bin\u00e4re .mo<\/code>-Dateien. Zur Laufzeit verwendet die Anwendung dann das aktuelle Locale oder einen ausgew\u00e4hlten Sprachcode, um die passende \u00dcbersetzung anzuzeigen.<\/p>\n\n\n\n

Python unterst\u00fctzt dieses GNU-gettext-Modell \u00fcber die Standardbibliothek. Es ist nach wie vor ein g\u00e4ngiger Ansatz f\u00fcr Python i18n und l10n, besonders wenn man einen verl\u00e4sslichen Lokalisierungsprozess f\u00fcr Anwendungen<\/a>, Kommandozeilentools oder Python-Module braucht.<\/p>\n\n\n\n

Gettext ist allerdings nur der technische Mechanismus. Der eigentliche Lokalisierungsablauf geht deutlich dar\u00fcber hinaus.<\/p>\n\n\n\n

Weshalb \u00dcbersetzungsprobleme meist im Code entstehen<\/span><\/h2>\n\n\n\n

Ein \u00dcbersetzungsprojekt beginnt also mit der Frage, ob die Originaltexte im Code \u00fcberhaupt f\u00fcr eine andere Sprache taugen.<\/p>\n\n\n\n

Nehmen wir eine Buchungsplattform als Beispiel. Eine Fehlermeldung wie \u201eAktion fehlgeschlagen\" erscheint im Code oft an zehn verschiedenen Stellen \u2013 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 \u00dcbersetzer sieht aber nur die isolierte Zeile in der .po<\/code>-Datei und muss raten.<\/p>\n\n\n\n

\u00c4hnlich kritisch ist die Art, wie Werte in S\u00e4tze eingebaut werden. Ein Datum, das im Code als reiner Zahlenstring zusammengesetzt wird \u2013 etwa \u201e15\/03\/2026\" \u2013 funktioniert zwar in Sprachen mit Tag-Monat-Reihenfolge, kollidiert aber in einer Sprache, die zuerst das Jahr nennt. Solche Formatierungsentscheidungen geh\u00f6ren in die Locale-Logik, nicht in einen manuell gebauten String.<\/p>\n\n\n\n

Zahlw\u00f6rter sind ein eigenes Kapitel. \u201e2 Zimmer verf\u00fcgbar\" und \u201e1 Zimmer verf\u00fcgbar\" brauchen in vielen Sprachen nicht zwei, sondern drei oder vier grammatische Formen \u2013 ein Umstand, den ein einzelner, hart codierter Satz niemals abbildet.<\/p>\n\n\n\n

Wird das erst nach dem Export bemerkt, betrifft die Korrektur nicht mehr nur den Quellcode, sondern auch die bereits verteilten po-Dateien und jede \u00dcbersetzung, die auf Basis des alten, unklaren Strings schon entstanden ist. Der Katalog selbst zeigt diese M\u00e4ngel nicht an. Das l\u00e4sst sich nur vorher im Code pr\u00fcfen.<\/p>\n\n\n\n

F\u00fcnf typische Probleme bei der Lokalisierung von Python-Anwendungen<\/span><\/h2>\n\n\n\n

Ein Klassiker ist das Zusammenkleben von Satzteilen im Code, etwa nach dem Muster \u201eIhre\" + anzahl + \u201eArtikel wurden versendet\". Solche Konstruktionen sind im Original meist unauff\u00e4llig, brechen aber in Sprachen mit anderer Wortstellung oder mit grammatischem Geschlecht regelrecht auseinander. Ein vollst\u00e4ndiger, in sich stehender Satz l\u00e4sst sich dagegen als Ganzes \u00fcbersetzen, ohne dass die \u00dcbersetzung von der Position eines eingef\u00fcgten Werts abh\u00e4ngt.<\/p>\n\n\n\n

Ein zweites, oft \u00fcbersehenes Problem sind Texte au\u00dferhalb der sichtbaren Benutzeroberfl\u00e4che: automatische Best\u00e4tigungsmails, 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\u00fcckfallen.<\/p>\n\n\n\n

Vage Platzhalter sind das dritte typische Problem. Ein Platzhalter wie %s<\/code> sagt dem \u00dcbersetzer nichts. Benannte Platzhalter wie {user_name}<\/code>, {event_name}<\/code> or {amount}<\/code> geben mehr Kontext und senken das Risiko fehlerhafter \u00dcbersetzungsdateien. Eine Python-Anwendung k\u00f6nnte zum Beispiel so eine nutzerseitige Meldung erzeugen:<\/p>\n\n\n\n

import gettext\n\n_ = gettext.gettext<\/code><\/pre>\n\n\n\n
Diese Variante ist schwieriger zu \u00fcbersetzen, weil der Platzhalter anonym ist:<\/p>\n\n\n\n
message = _(\"%s wurde hinzugef\u00fcgt\") % item_name<\/code><\/pre>\n\n\n\n
Der \u00dcbersetzer sieht nur\u00a0%s wurde hinzugef\u00fcgt<\/code>. Er wei\u00df nicht, worauf sich\u00a0%s<\/code>\u00a0bezieht, was genau hinzugef\u00fcgt wurde oder wo die Meldung \u00fcberhaupt erscheint.<\/p>\n\n\n\n
Diese Variante ist klarer, weil der Platzhalter benannt und der Satz vollst\u00e4ndig ist:<\/p>\n\n\n\n
message = _(\"Produkt {product_name} wurde dem Warenkorb hinzugef\u00fcgt\").format(\n    product_name=product_name\n)<\/code><\/pre>\n\n\n\n
Der Unterschied ist keine Stilfrage. Bei benannten Platzhaltern kann eine \u00dcbersetzung die Reihenfolge frei anpassen, ohne dass die Werte an der falschen Stelle landen oder das Programm crasht, wenn ein Formatargument fehlt.<\/p>\n\n\n\n
Viertens: nicht jeder String vertr\u00e4gt denselben Freigabeprozess. Ein Tooltip l\u00e4sst sich frei und sinngem\u00e4\u00df \u00fcbersetzen; eine Widerrufsbelehrung oder ein Preis\u00e4nderungshinweis eher nicht. L\u00e4uft beides durch dieselbe Pr\u00fcfschleife, f\u00fchrt das entweder zu unn\u00f6tiger Verz\u00f6gerung bei harmlosen Texten oder zu einer zu knappen Pr\u00fcfung bei rechtlich heiklen.<\/p>\n\n\n\n
F\u00fcnftens landen in vielen .pot<\/code>-Dateien Zeilen, die dort nichts verloren haben: Platzhaltertexte aus der Entwicklung, auskommentierte alte Versionen einer Meldung, interne Debug-Ausgaben. Jede dieser Zeilen kostet das \u00dcbersetzungsteam Zeit und verw\u00e4ssert den \u00dcbersetzungsspeicher mit Eintr\u00e4gen, die nie im Produkt erscheinen.<\/p>\n\n\n\n
So unterschiedlich diese f\u00fcnf Probleme auch klingen m\u00f6gen, im Kern sind sie gleich: Sie werden im gettext-Workflow sichtbar, entstehen aber schon vorher, beim Schreiben des Codes.<\/p>\n\n\n\n
Ein Vier-Punkte-Check vor dem ersten Export<\/span><\/h2>\n\n\n\n
\"python<\/figure>\n\n\n\n
Es empfiehlt sich, vor der \u00dcbersetzung des Python-Quellcodes eine kurze \u00dcberpr\u00fcfung der Voraussetzungen durchzuf\u00fchren.<\/p>\n\n\n\n