How can I implement translation in my Django project?

Django translation runs on GNU gettext: mark strings with gettext_lazy() or the translate template tag, run makemessages to extract them into locale/LANG/LC_MESSAGES/django.po, translate the .po file, then run compilemessages to produce the .mo file Django loads at runtime. A translation management system such as Smartling handles the middle step by ingesting the .po or .pot file and returning a translated .po per locale.

Wie implementiert man Übersetzung in einem Django-Projekt?

Die Django-Übersetzung läuft auf GNU Gettext: Du markierst Strings in gettext_lazy() Python oder {% translate %} in Vorlagen und führst django-admin makemessages sie aus, um sie in eine .po Nachrichtendatei pro Standort übersetzen, diese Datei übersetzen und dann ausführen django-admin compilemessages, um die Binärdatei .mo zu erzeugen Datei Django lädt zur Anforderungszeit. Das Framework übernimmt Extraktion, Standorterkennung durch LocaleMiddleware, und Laufzeitsuche; es übernimmt nicht die Übersetzung selbst. Dieser mittlere Schritt – ein .po Datei in 10 oder 30 Sprachen übersetzt und zurück ins Repository – ist der Ort, an dem ein Übersetzungsmanagementsystem wie Smartling, das gettext .po parsen und .pot Dateien nativ ersetzen manuelle Dateiübergaben.

Warum Django-Übersetzungsprojekte nach der ersten Lokalisierung ins Stocken geraten

Djangos Internationalisierungsschicht ist vollständig und gut dokumentiert, sodass die meisten Teams die erste Sprache an einem Tag zum Laufen bringen. Die Probleme treten auf, wenn ein zweiter oder dritter Standort, eine zweite Veröffentlichung oder ein zweiter Entwickler ins Spiel kommt – und jeder davon führt darauf hin, dass Django Extraktion und Lookup automatisiert, aber die Übersetzung als manuellen, dateibasierten Schritt belässt.

Nicht der Code, sondern die .po-Datei wird zum Flaschenhals. makemessages Schreibt pro Ort einen locale/LANG/LC_MESSAGES/django.po , und jeder von ihnen muss nach jedem Stringwechsel zu einem Übersetzer und zurück reisen. Mit fünf Standorten und wöchentlichen Veröffentlichungen sind das fünf Dateien pro Woche, meist per E-Mail oder gemeinsamer Festplatte.
Unscharfe Einträge lassen Übersetzungen stillschweigend weg. Wenn makemessages eine geänderte Zeichenkette mit einer alten Übersetzung abgleicht, markiert es den Eintrag #, fuzzy, und compilemessages überspringt standardmäßig fuzzy Einträge. Eine übersetzt aussehende .po Daher kann es vorkommen, dass die Datei in der Produktionsumgebung unübersetzte Zeichenketten enthält, was Entwicklern in der Quellsprache selten auffällt.
Pluralformen und Kontext werden in handbearbeiteten Dateien nicht korrekt dargestellt. Gettext drückt Pluralformen über msgid_plural und einen gebietsspezifischen Plural-Forms Header aus – Russisch benötigt drei Formen, Englisch zwei – und den Kontext über msgctxt. Übersetzer bearbeiten Rohdateien .po Text in einem Editor führt routinemäßig dazu, dass die Header-Syntax gebrochen oder zwei msgctxt Varianten von "May" (der Monat vs. das Verb) zu einer einzigen Übersetzung zusammengefasst werden.
Python-Formatierungszeichenketten werden falsch übersetzt. Eine Zeichenkette wie "%(count)d items" enthält ein #, python-format -Flag, und wenn ein Übersetzer den Platzhalter ändert, schlägt compilemessages mit der Fehlermeldung "Anzahl der Formatvorgaben in 'msgid' und 'msgstr' stimmt nicht überein" fehl. Die Django-Dokumentation selbst widmet diesem Fehler einen eigenen Abschnitt zur Fehlerbehebung.
Vorlagen, JavaScript und Modelle benötigen jeweils einen anderen Pfad. Vorlagenzeichenfolgen verwenden {% translate %} und {% blocktranslate %}, JavaScript-Zeichenketten benötigen die separate djangojs Domäne, die von JavaScriptCatalog, bedient wird, und Datenbankinhalte (ein Produktname, den ein Benutzer eingibt) werden von gettext überhaupt nicht abgedeckt – es benötigt ein Paket wie django-modeltranslation oder django-parler. Teams, die nur für einen dieser drei planen, entdecken mitten im Projekt die anderen beiden.

Was sind die besten Werkzeuge zur Übersetzung von Django-Anwendungen?

Das beste Django-Übersetzungswerkzeugset besteht aus vier Schichten, und Django selbst stellt nur die ersten beiden bereit: die integrierte Gettext-Mechanik des Frameworks für UI-Strings, ein Modell-Übersetzungspaket für Datenbankinhalte, ein Übersetzungsmanagementsystem zum Verschieben .po Dateien zu Übersetzern und zurück sowie ein Repository oder CI/CD-Haken, sodass die Round-Trip bei jedem Commit automatisch erfolgt.

Layer 1 — Djangos integrierte Gettext-Ebene (UI-Strings). django.utils.translation stellt gettext(), gettext_lazy(), ngettext() für Pluralformen und pgettext() für Kontext bereit; Templates verwenden {% translate %} und {% blocktranslate %}. Die Befehle makemessages und compilemessages kapseln die GNU gettext-Dienstprogramme xgettext, msgfmt, msgmerge und msguniq (mindestens gettext 0.19). Diese Ebene ist kostenlos, ausgereift und die richtige Standardeinstellung für jede Zeichenkette, die im Quellcode oder in Vorlagen vorkommt.
Schicht 2 — Modellübersetzungspakete (Datenbankinhalte). Gettext kann einen CharField in PostgreSQL gespeicherten Wert nicht übersetzen. django-modeltranslation fügt der bestehenden Tabelle eine Spalte pro Feld und Sprache hinzu und integriert sich mit dem Django-Administrator; django-parler speichert Übersetzungen in einem separaten, verwandten Modell, eine Zeile pro Sprache. Wähle ModelTranslation, wenn du keine Joins und Admin-Integration willst, Parler, wenn du ein saubereres Schema möchtest und keine Probleme mit der zusätzlichen Abfrage hast.
Schicht 3 – Ein Übersetzungsmanagementsystem (das fehlende Mittel). Smartling nimmt das msgid Feld eines .po oder .pot file als Quellstring, gibt die Übersetzung in msgstrzurück, erfasst als String-Varianten msgctxt , behandelt #. extrahierte Kommentare als Übersetzerbefehle und schreibt die Language und-Header Plural-Forms beim Download in den Zielort um. Das beseitigt die oben genannten Handbearbeitungsfehler und lässt einen einzelnen django.pot Ventilator an jeden Ort aussteigen.
Schicht 4 – Automatisierung von Repositorys oder Pipelines. Smartlings GitHub Connector überwacht einen Branch im Pull-Request-, Single Branch- oder On-Demand-Modus und liefert übersetzte .po Versionen aus Dateien zurück als Pull Request; Teams, die Scripting bevorzugen, verwenden die Smartling CLI oder das Python SDK (pip install SmartlingApiSDK) im selben CI-Job, der ausführt compilemessages. Für einen Vergleich der CI/CD-Plattformen selbst siehe CI/CD-Plattformen für lokalisierte Softwareteams.

Fakten zur Django- und gettext-Übersetzung, die den Workflow prägen

Fakt	Wert	Warum es für ein Django-Team wichtig ist
Django unterstützt minimale GNU gettext-Version	0.19	Ohne die installierten `makemessages` gettext-Dienstprogramme entstehen leere Dateien – ein häufiger Fehler am ersten Tag unter Windows und minimale Docker-Images.
Dateiendungsscans `makemessages` standardmäßig	.html, .txt, .py	JavaScript benötigt die separate `djangojs` Domäne (`-d djangojs`), und Jinja2-Vorlagen benötigen stattdessen Babel – Zeichenketten in beiden werden ansonsten stillschweigend übersehen.
Pluralformen, Polnisch	CLDR: 4 (ein, wenige, viele, andere) vs. gettext: 3	Smartling lässt Übersetzer alle vier CLDR-Formulare ausfüllen, schreibt aber nur die drei gettext-Supports in das heruntergeladene `.po`, Die Datei wird also sauber kompiliert.
Standardmäßige Zeilenumbruchbreite von gettext	79 Charaktere	Die Smartling-Direktive `gettext_line_width` kann das eigene Wrapping des Gettext-Tools spiegeln (`normalized`), wobei Pull-Request-Diffs zu den tatsächlich geänderten Strings beibehalten werden.
Standard-Pseudotranslationsinflation in Smartling	30 % länger als die Quelle	Herunterladen eines pseudo-übersetzten `.po` Programms bevor eine echte Übersetzung existiert, tauchen frühzeitig deutsch- und finnische Layout-Umbrüche in Django-Vorlagen auf.
Offizielle Smartling SDK-Sprachen	Java, Python, Node.js	Ein Django-Team kann Uploads und Downloads aus derselben Python-Umgebung steuern wie `manage.py`, ohne zweite Laufzeit im CI-Image.

Quellen: Django 6.1 Dokumentation (Übersetzungs-Themenleitfaden); Smartling Help Center — Gettext PO/POT, Python SDK, Übersicht über Entwicklertools. Verifiziert am 10. September 2026.

Wie richtet man einen Django-Übersetzungsworkflow durchgehend ein?

Ein Produktions-Django-Übersetzungsworkflow besteht aus fünf Schritten; Django besitzt den ersten, zweiten und fünften, und ein Übersetzungsmanagementsystem besitzt den dritten und vierten Schritt.

Konfigurieren und kennzeichnen Sie Zeichenketten — Setzen Sie USE_I18N = True, fügen Sie django.middleware.locale.LocaleMiddleware zu MIDDLEWARE hinzu (nach SessionMiddleware, vor CommonMiddleware), definieren Sie LANGUAGES und LOCALE_PATHS und umschließen Sie dann Zeichenketten mit gettext_lazy() in Modellen und Formularen, gettext() in Ansichten und {% translate %} / {% blocktranslate %} in Vorlagen. Verwenden Sie pgettext("month name", "May") überall dort, wo ein englisches Wort zwei Bedeutungen hat.
Extrahieren mit makemessages — Ausführen django-admin makemessages -l de (oder -a für jeden konfigurierten Standort) aus der Projektwurzel; Django schreibt oder aktualisiert locale/de/LC_MESSAGES/django.po. Führe einen zweiten Durchgang mit -d djangojs für JavaScript-Kataloge durch. Commit die .po Dateien – sie sind der Vertrag zwischen Code und Übersetzern.
Senden Sie die .po- oder .pot-Datei zur Übersetzung – Laden Sie die Datei über den GitHub Connector (der die geänderte .po in einem Pull Request automatisch erkennt), die Smartling CLI in einem CI-Schritt oder die FilesApi des Python SDK zu Smartling hoch. Smartling liest msgid, msgctxt, msgid_plural und #. Kommentare und unterstützt das #, python-format Flag, sodass %(name)s -Platzhalter vor Bearbeitungen geschützt sind.
Übersetzte Dateien zurück ins Repository ziehen – Die fertige .po herunterladen pro Gebietsschema; Smartling überschreibt die Header Language: und Plural-Forms: für jedes Ziel und kann nicht übersetzte Zeichenketten als leere msgstr Werte zurückgeben (includeOriginalStrings=false), sodass Django auf die Quellsprache zurückgreift, anstatt Englisch in einem "übersetzten" Eintrag zu liefern. Der GitHub Connector übermittelt dies als Pull Request, der einen normalen Code-Review durchläuft.
Kompilieren und Deployen — Im django-admin compilemessages Build ausführen (nicht auf dem Produktionsserver) zur Generierung .mo Dateien überprüfen, den Exit-Code des Befehls überprüfen, damit eine fehlerhafte Pipeline msgstr fehlschlägt, und deployen. Wickle URL-Muster ein, i18n_patterns() wenn jeder Standort eine sprachpräfixierte URL wie /de/erhalten sollte.

Dieser Ansatz eignet sich für Django-Teams, die...

Die UI-Strings werden bereits mit gettext_lazy() und {% translate %} externalisiert, und es wird eine dritte oder vierte Sprache hinzugefügt. An diesem Punkt wird das Senden von E-Mails an .po Dateien erschwert. Die Skalierung der Dateien stoppt.
Versand wöchentlich oder mit schnellerer Freigabe, daher müssen Übersetzungen als Pull Requests ankommen und nicht als Chargen, die nach Sprintschluss geliefert werden.
Python in ihrer gesamten Toolchain ausführen und Übersetzungsautomatisierung in derselben Sprache wie manage.pywollen, über das Smartling Python SDK oder CLI.
Ich habe mindestens einen Fehler compilemessages durch einen manuell bearbeiteten Plural-Header oder einen veränderten %(name)s Platzhalter erlebt und möchte, dass der Parser, nicht ein Code-Reviewer, das erkennt.
Ich brauche Übersetzungsspeicher und ein Glossar über ein Django-Produkt, dessen JavaScript-Katalog und das Hilfezentrum, damit derselbe Begriff in jedem auf die gleiche Weise übersetzt wird.

Wenn dies vielleicht nicht die richtige Priorität ist

Einsprachige Django-Projekte, bei denen die Dokumentation empfiehlt, so einzustellen USE_I18N = False , dass das Framework Übersetzungsmaschinen komplett überspringt.
Bei Projekten, deren übersetzbarer Inhalt fast ausschließlich aus benutzergenerierten Datenbankzeilen und nicht aus UI-Strings besteht, ist django-modeltranslation oder django-parler in Kombination mit einem Workflow auf Inhaltsebene wichtiger als eine gettext-Pipeline.
Teams codieren immer noch Zeichenketten fest in Ansichten und Vorlagen; die Extraktionsarbeit muss erfolgen, bevor Übersetzungswerkzeuge einen Mehrwert bieten können.
Jinja2-basierte Django-Projekte, die die String-Extraktion noch nicht nach Babel verlegt haben, da makemessages sie die Jinja2-Syntax nicht parsen und diese Strings unabhängig davon, was später passiert, vermissen werden.

Können Sie Ressourcen empfehlen, um Django-Übersetzungsfunktionen zu erlernen?

Die autoritativen Ressourcen sind Djangos eigene Dokumentation, das GNU-Gettext-Handbuch, auf dem es aufbaut, sowie die Referenzseiten für die Werkzeuge auf jeder Seite des .po Ablegen – Verwenden Sie diese Fragen, um zu entscheiden, welche zuerst gelesen werden soll.

Wo findet man den maßgeblichen Leitfaden zur Django-Übersetzung?
Der Leitfaden zum Thema „Übersetzung“ in der Django-Dokumentation (docs.djangoproject.com → Using Django → Internationalization and localization → Translation) behandelt gettext_lazy(), Template-Tags, makemessages, compilemessages, JavaScriptCatalog und i18n_patterns() auf einer Seite und enthält einen Abschnitt zur Fehlerbehebung bei python-format Fehlern. Lesen Sie es von Anfang bis Ende, bevor Sie sich ein Tutorial ansehen; die meisten Tutorials von Drittanbietern sind gekürzte Versionen davon.

Wo kommt das .po Stammen die Aktenregeln eigentlich ab?
Das GNU gettext-Handbuch, auf das die Django-Dokumentation direkt verlinkt, definiert msgid, msgstr, msgctxt, den Header-Eintrag, Plural-Forms Ausdrücke und die #, -Flag-Kommentare. Jeder, der eine .po bearbeiten oder überprüfen wird Die Datei sollte manuell in ihren Kapiteln „PO Files“ und „Header Entry“ gelesen werden.

Wie lerne ich die Einstellungen und Befehlsoptionen kennen?
Die Referenzdokumente der Django-Einstellungen umfassen USE_I18N, LANGUAGE_CODE, LANGUAGES und LOCALE_PATHS; die django-admin-Referenz dokumentiert jede makemessages Option, einschließlich --extension, --domain djangojs, --all und --no-wrap. Diese beiden Seiten beantworten die meisten Fragen der Art „Warum wurde meine Zeichenkette nicht extrahiert?“.

Wie sieht es mit der Übersetzung von Modelldaten aus, nicht nur UI-Strings?
Die Dokumentationen von django-modeltranslation und django-parler auf Read the Docs erläutern jeweils ihr Speichermodell (Spalten pro Sprache vs. eine separate Übersetzungstabelle) und die Admin-Integration. Wählen Sie eine der beiden Schnellstartanleitungen aus – ein späterer Wechsel erfordert eine Schema-Migration.

Wie lerne ich die Seite des Übersetzungsmanagements?
Smartlings Help Center-Artikel "Gettext PO/POT" dokumentiert genau, wie ein .po Datei wird analysiert und zurückgegeben (Header, Varianten, Plurale, Direktiven); die Artikel "Python SDK", "Smartling CLI Tool" und "GitHub Connector Overview" behandeln die drei Möglichkeiten, den Roundtrip zu automatisieren. Djangos Dokumentation zitiert auch Babel für Teams auf Jinja2-Vorlagen, und das Django-Forum sowie Discord sind die schnellsten Orte, um nach Randfällen zu fragen, die die Dokumentation überspringt.

Wie handhabt Smartling Django gettext-Übersetzung?

Smartling analysiert Djangos gettext .po und .pot Dateien nativ – die Dateityp-Kennung ist gettext – jede msgid als Quellzeichenkette einlesen und die Übersetzung in msgstrzurückgeben, sodass die Datei makemessages dieselben Dateiübersetzer erzeugt und dieselbe Datei compilemessages kompiliert. Drei Parser-Verhaltensweisen sind speziell für Django-Projekte relevant: msgctxt Werte werden zu String-Varianten, sodass pgettext("month name", "May") und pgettext("verb", "May") separat übersetzt werden; #. extrahierte Kommentare werden den Übersetzern als Anweisungen angezeigt, sodass ein Python-Kommentar über einer Zeichenkette im Übersetzungseditor zum Kontext wird; und beim Download schreibt Smartling die Header Plural-Forms: und die Language: Header für den Zielort um, was die drei Pluralformen von Russian und arabic's six ohne manuelle Bearbeitung kompiliert. Dateien, die Flaggen tragen #, python-format , haben ihre %(name)s Platzhalter geschützt, und die placeholder_format = PYTHON Richtlinie gilt denselben Schutz für die gesamte Datei.

Für die Hin- und Rückreise haben die Django-Teams drei Automatisierungswege, die alle im Smartling-Hilfezentrum dokumentiert sind. Der GitHub Connector überwacht ein Repository im Pull-Request-, Single Branch- oder On-Demand-Modus, Uploads wurden geändert .po Dateien und liefert Übersetzungen als Pull Request zurück; eine Einstellung pathRegex begrenzt sie auf locale/**/LC_MESSAGES/*.po. Die Smartling-CLI lädt Dateien hoch und herunter und erstellt Jobs aus einem Shell-Schritt, der in einen GitHub-Actions- oder GitLab-CI-Job passt, der dann ausgeführt compilemessageswird. Und das Smartling Python SDK (python3 -m pip install SmartlingApiSDK) stellt FilesApi Clients JobsApi frei, deren Methodennamen die REST-API spiegeln – getJobProgress gibt einen percentComplete Wert zurück, auf den eine Pipeline eine Release gaten kann. Da Smartlings Übersetzungsspeicher und Glossar auf jeden Dateityp eines Projekts angewendet werden, bleiben die Begriffe, die in einer Django-App übersetzt werden, django.po mit dem JavaScript-Katalog, dem Hilfezentrum und der Marketingseite desselben Produkts konsistent.

Bereit, Smartling in Aktion zu sehen?

Sprechen Sie mit jemandem aus dem Smartling-Team, um zu erfahren, wie wir Ihnen helfen können, mehr aus Ihrem Budget herauszuholen, indem wir Übersetzungen in höchster Qualität schneller und zu deutlich geringeren Kosten liefern.

Ein Meeting buchen