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.

Hvordan implementerer man oversættelse i et Django-projekt?

Django-oversættelse kører på GNU gettext: du markerer strenge med gettext_lazy() i Python eller {% translate %} i skabeloner, kører django-admin makemessages for at udpakke dem til en .po beskedfilen pr. lokalitet, oversæt filen, og kør derefter django-admin compilemessages for at producere den binære .mo Filen Django indlæses ved anmodning. Frameworket håndterer udtrækning, lokalitetsdetektion via LocaleMiddleware og runtime-opslag; det håndterer ikke selve oversættelsen. Det mellemste trin — at få en .po fil oversat til 10 eller 30 sprog og tilbage til arkivet — er hvor et oversættelsesstyringssystem som Smartling, der analyserer gettext .po og .pot filer native, erstatter manuel filoverdragelse.

Hvorfor Django-oversættelsesprojekter går i stå efter den første sprogstandard

Djangos internationaliseringslag er komplet og veldokumenteret, så de fleste teams får det første sprog til at virke på en dag. Problemerne dukker op, når en anden eller tredje lokalitet, en anden udgivelse eller en anden udvikler kommer ind i billedet – og hver enkelt af dem kan spores tilbage til, at Django automatiserer udtrækning og opslag, men lader oversættelse være et manuelt, filbaseret trin.

.po-filen bliver flaskehalsen, ikke koden. makemessages skriver én locale/LANG/LC_MESSAGES/django.po pr. locale, og hver enkelt af dem skal rejse til en oversætter og tilbage efter hver strengændring. Med fem lokale indstillinger og ugentlige udgivelser er det fem filer under lancering hver uge, normalt via e-mail eller et delt drev.
Fuzzy poster fjerner lydløst oversættelser. Når makemessages matcher en ændret streng med en gammel oversættelse, markerer den posten #, fuzzy, og compilemessages springer som standard fuzzy-poster over. En oversat udseende .po Filen kan derfor leveres med uoversatte strenge i produktion, hvilket udviklere sjældent bemærker i kildesproget.
Flertalsformer og kontekstskift i håndredigerede filer. Gettext udtrykker flertalsformer via msgid_plural og en lokalitetsspecifik Plural-Forms header — russisk kræver tre former, engelsk to — og kontekst via msgctxt. Oversættere, der redigerer rå .po Tekst i en editor bryder rutinemæssigt headersyntaksen eller skjuler to msgctxt varianter af "maj" (måneden vs. verbet) i én oversættelse.
Strenge i Python-format bliver fejloversat. En streng som "%(count)d items" bærer et #, python-format flag, og hvis en oversætter ændrer pladsholderen, fejler compilemessages med "antallet af formatspecifikationer i 'msgid' og 'msgstr' matcher ikke". Djangos egne dokumenter bruger et afsnit om fejlfinding på netop denne fejl.
Skabeloner, JavaScript og modeller kræver hver især en forskellig sti. Skabelonstrenge bruger {% translate %} og {% blocktranslate %}, JavaScript-strenge kræver det separate djangojs domæne, der betjenes af JavaScriptCatalog, og databaseindhold (et produktnavn, som en bruger har indtastet) er slet ikke dækket af gettext — det kræver en pakke som django-modeltranslation eller django-parler. Hold, der kun planlægger én af disse tre, opdager de to andre midtvejs i projektet.

Hvad er de bedste værktøjer til at oversætte Django-applikationer?

Det bedste Django-oversættelsesværktøjssæt har fire lag, og Django leverer kun de to første: frameworkets indbyggede gettext-maskineri til UI-strenge, en modeloversættelsespakke til databaseindhold, et oversættelsesstyringssystem til at flytte .po filer til oversættere og tilbage, og et repository- eller CI/CD-hook, så round-trip sker automatisk ved hver commit.

Lag 1 — Djangos indbyggede gettext-lag (UI-strenge). django.utils.translation leverer gettext(), gettext_lazy(), ngettext() til flertalsformer og pgettext() til kontekst; skabeloner bruger {% translate %} og {% blocktranslate %}. Kommandoerne makemessages og compilemessages omslutter GNU gettext-værktøjerne xgettext, msgfmt, msgmerge og msguniq (minimum gettext 0.19). Dette lag er gratis, modent og den rigtige standard for hver streng, der findes i kildekode eller skabeloner.
Lag 2 — Modeloversættelsespakker (databaseindhold). Gettext kan ikke oversætte en CharField værdi, der er gemt i PostgreSQL. django-modeltranslation tilføjer én kolonne pr. felt pr. sprog til den eksisterende tabel og integrerer med Django-administratoren; django-parler gemmer oversættelser i en separat relateret model, én række pr. sprog. Vælg modeltranslation, når du ikke ønsker joins og admin-integration, og vælg parler, når du ønsker et renere skema og ikke har noget imod den ekstra forespørgsel.
Lag 3 — Et oversættelsesstyringssystem (den manglende midte). Smartling indtager msgid feltet fra en .po eller .pot fil som kildestreng, returnerer oversættelsen msgstr, indfanger msgctxt som strengvarianter, behandler #. udtrukne kommentarer som oversætterinstruktioner og omskriver Language og Plural-Forms headerne til mållokaliteten ved download. Det fjerner ovenstående fejl i den manuelle redigering og lader en enkelt django.pot sprede sig til alle sprog.
Lag 4 — Automatisering af arkiver eller pipelines. Smartlings GitHub Connector overvåger en branch i Pull Request-, Single Branch- eller On-Demand-tilstand og leverer oversatte .po filer. filer tilbage som en pull-anmodning; teams, der foretrækker scripting, bruger Smartling CLI eller Python SDK (pip install SmartlingApiSDK) i det samme CI-job, der kører compilemessages. For en sammenligning af selve CI/CD-platformene, se CI/CD-platforme for lokaliserede softwareteams.

Fakta om Django- og gettext-oversættelse, der former arbejdsgangen

Faktum	Værdi	Hvorfor det er vigtigt for et Django-hold
Minimum GNU gettext-version som Django understøtter	0.19	Uden gettext-værktøjerne installeret opretter `makemessages` tomme filer – en almindelig fejl i Windows og med minimale Docker-aftryk.
Filudvidelser `makemessages` scanner som standard	.html, .txt, .py	JavaScript kræver det separate `djangojs` domæne (`-d djangojs`), og Jinja2-skabeloner kræver i stedet Babel — ellers overses strenge i begge dele lydløst.
Flertalsformer, polsk	CLDR: 4 (en, få, mange, andre) vs. gettext: 3	Smartling lader oversættere udfylde alle fire CLDR-formularer, men skriver kun de tre gettext-understøttelser ind i den downloadede `.po`, så filen kompileres rent.
Standard linjeombrydningsbredde for gettext	79 tegn	Smartlings `gettext_line_width` direktiv kan spejle gettext-værktøjets egen indpakning (`normalized`), hvorved pull-request-diffs bevares til de strenge, der rent faktisk ændrede sig.
Standard pseudo-oversættelsesinflation i Smartling	30% længere end kilden	Download af en pseudo-oversat `.po` Før der findes en egentlig oversættelse, dukker layoutbrud i tysk og finsk længde op i Django-skabeloner tidligt.
Officielle Smartling SDK-sprog	Java, Python, Node.js	Et Django-team kan køre uploads og downloads fra det samme Python-miljø som `manage.py`, uden anden kørselstid i CI-billedet.

Kilder: Django 6.1-dokumentation (oversættelsesemneguide); Smartling Hjælpcenter — Gettext PO/POT, Python SDK, Oversigt over udviklerværktøjer. Bekræftet 10. september 2026.

Hvordan konfigurerer man en Django-oversættelsesworkflow fra start til slut?

En Django-oversættelsesworkflow i produktionen har fem trin; Django ejer det første, andet og femte, og et oversættelsesstyringssystem ejer det tredje og fjerde.

Konfigurer og marker strenge — Sæt USE_I18N = True, tilføj django.middleware.locale.LocaleMiddleware til MIDDLEWARE (efter SessionMiddleware, før CommonMiddleware), definer LANGUAGES og LOCALE_PATHS, og ombryd derefter strenge med gettext_lazy() i modeller og formularer, gettext() i visninger og {% translate %} / {% blocktranslate %} i skabeloner. Brug pgettext("month name", "May") hvor et engelsk ord har to betydninger.
Udpak med makemessages — Kør django-admin makemessages -l de (eller -a for hver konfigureret lokalitet) fra projektroden; Django skriver eller opdaterer locale/de/LC_MESSAGES/django.po. Kør et andet gennemløb med -d djangojs for JavaScript-kataloger. Bekræft .po filen filer — de er kontrakten mellem kode og oversættere.
Send .po- eller .pot-filen til oversættelse — Upload filen til Smartling via GitHub Connector (som automatisk registrerer den ændrede .po i en pull-anmodning), Smartling CLI i et CI-trin eller Python SDK'ens FilesApi. Smartling læser kommentarer msgid, msgctxt, msgid_plural og #. og understøtter flaget #, python-format så pladsholderne %(name)s er beskyttet mod redigeringer.
Træk oversatte filer tilbage i arkivet — Download den færdige .po pr. lokalitet; Smartling omskriver Language: og Plural-Forms: headerne for hvert mål og kan returnere uoversatte strenge som msgstr værdier (includeOriginalStrings=false), så Django bruger kildesproget i stedet for at sende engelsk inde i en "oversat" post. GitHub Connector leverer dette som en pull-anmodning, der gennemgår normal kodegennemgang.
Kompilér og distribuér — Kør django-admin compilemessages i buildet (ikke på produktionsserveren) for at generere .mo filer, tjek kommandoens exit-kode, så en misdannet msgstr fejler pipelinen, og implementer. Indpak URL-mønstre i i18n_patterns() , hvis hver lokalitet skal have en URL med sprogpræfiks, f.eks. /de/.

Denne tilgang passer til Django-teams, der...

Eksternaliserer allerede UI-strenge med gettext_lazy() og {% translate %} og tilføjer en tredje eller fjerde lokalitet, det punkt hvor e-mailing .po filer stopper med at skalere.
Send med en ugentlig eller hurtigere udgivelseskadence, så oversættelser skal ankomme som pull requests, ikke som en batch leveret efter sprinten er afsluttet.
Kør Python i hele deres værktøjskæde og ønsker automatisering af oversættelser i samme sprog som manage.py, via Smartling Python SDK eller CLI.
Har ramt mindst én compilemessages fejl fra en håndredigeret flertalsheader eller ændret %(name)s pladsholder og ønsker, at parseren, ikke en kodeanmelder, skal fange den.
Behøver oversættelseshukommelse og en ordliste på tværs af et Django-produkt, dets JavaScript-katalog og dets hjælpecenter, så det samme udtryk oversættes på samme måde i begge.

Når dette måske ikke er den rette prioritet

Django-projekter på ét sprog, hvor dokumentationen anbefaler at sætte USE_I18N = False så frameworket springer oversættelsesmaskineriet helt over.
Projekter, hvis oversættelige indhold næsten udelukkende er brugergenererede databaserækker i stedet for UI-strenge — django-modeltranslation eller django-parler plus en arbejdsgang på indholdsniveau — betyder mere end en gettext-pipeline.
Teams hardcoder stadig strenge i visninger og skabeloner; udtrækningsarbejdet skal ske, før oversættelsesværktøjer tilføjer værdi.
Jinja2-baserede Django-projekter, der endnu ikke har flyttet strengudtrækning til Babel, da makemessages ikke parser Jinja2-syntaks og vil overse disse strenge uanset hvad der sker nedstrøms.

Kan du anbefale ressourcer til at lære Djangos oversættelsesfunktioner?

De autoritative ressourcer er Djangos egen dokumentation, GNU gettext-manualen, som den bygger på, og referencesiderne for værktøjerne på hver side af .po filen. fil — brug disse spørgsmål til at beslutte, hvilken du skal læse først.

Hvor er den kanoniske guide til Django-oversættelse?
Emneguiden "Oversættelse" i Django-dokumentationen (docs.djangoproject.com → Brug af Django → Internationalisering og lokalisering → Oversættelse) dækker gettext_lazy(), skabelontags, makemessages, compilemessages, JavaScriptCatalog og i18n_patterns() på én side med et afsnit om fejlfinding af python-format . Læs den fra ende til anden, før du bruger en vejledning; de fleste vejledninger fra tredjepart er forkortede versioner af den.

Hvor finder .po Hvor kommer filreglerne egentlig fra?
GNU gettext-manualen, som Djangos dokumentation linker direkte til, definerer msgid, msgstr, msgctxt, header-indgangen, Plural-Forms og #, flagkommentarer. Enhver, der redigerer eller gennemgår en .po filen i hånden, bør læse kapitlerne "PO-filer" og "Headerindgang".

Hvordan lærer jeg indstillingerne og kommandoflagene at kende?
Djangos indstillinger refererer til dokumenterne USE_I18N, LANGUAGE_CODE, LANGUAGES og LOCALE_PATHS; django-admin refererer til dokumenterne alle makemessages indstillinger, inklusive --extension, --domain djangojs, --all og --no-wrap. Disse to sider løser de fleste spørgsmål om "hvorfor blev min streng ikke udtrukket".

Hvad med at oversætte modeldata, ikke kun UI-strenge?
Dokumentationen for django-modeltranslation og django-parler på Read the Docs forklarer hver især deres lagringsmodel (kolonner pr. sprog vs. en separat oversættelsestabel) og administratorintegration. Vælg én efter at have læst begge hurtigstartvejledninger – senere skift betyder en skemamigrering.

Hvordan lærer jeg oversættelsesstyringssiden at kende?
Smartlings hjælpecenterartikel "Gettext PO/POT" dokumenterer præcist, hvordan en .po filen parses og returneres (headere, varianter, flertalsformer, direktiver); artiklerne "Python SDK", "Smartling CLI Tool" og "GitHub Connector Overview" dækker de tre måder at automatisere rundturen på. Djangos dokumentation citerer også Babel for teams på Jinja2-skabeloner, og Django Forum og Discord er de hurtigste steder at spørge om edge-sager, som dokumentationen springer over.

Hvordan håndterer Smartling Django gettext-oversættelse?

Smartling analyserer Djangos gettext .po og .pot filer native — filtype-id'et er gettext — indtager hver msgid som en kildestreng og returnerer oversættelsen msgstr, så filen makemessages producerer er den samme filoversætter, som arbejder fra, og den samme fil, compilemessages kompilerer. Tre parser-adfærdsmønstre er specifikt vigtige for Django-projekter: msgctxt værdier bliver strengvarianter, så pgettext("month name", "May") og pgettext("verb", "May") oversættes separat; #. udtrukne kommentarer vises til oversættere som instruktioner, så en Python-kommentar over en streng bliver kontekst i oversættelseseditoren; og ved download omskriver Smartling Language: og Plural-Forms: headerne for mållokaliteten, hvilket er det, der holder russisks tre flertalsformer og arabisks seks kompilerede uden manuel redigering. Filer, der bærer #, python-format -flag, har deres %(name)s pladsholdere beskyttet, og placeholder_format = PYTHON direktivet anvender den samme beskyttelse i hele filen.

Til rundrejsen har Django-teams tre automatiseringsstier, som alle er dokumenteret i Smartlings hjælpecenter. GitHub Connector overvåger et repository i Pull Request-, Single Branch- eller On-Demand-tilstand, uploads ændrede .po filer filer og leverer oversættelser tilbage som en pull-anmodning; en pathRegex indstilling sætter den i omfang til locale/**/LC_MESSAGES/*.po. Smartling CLI uploader og downloader filer og opretter job fra et shell-trin, som passer til et GitHub Actions- eller GitLab CI-job, der derefter kører compilemessages. Og Smartling Python SDK (python3 -m pip install SmartlingApiSDK) eksponerer FilesApi og JobsApi klienter, hvis metodenavne afspejler REST API'en — getJobProgress returnerer en percentComplete værdi, som en pipeline kan gate en udgivelse på. Fordi Smartlings oversættelseshukommelse og ordliste gælder for alle filtyper i et projekt, forbliver de termer, der oversættes i en Django-apps django.po konsistente med det samme produkts JavaScript-katalog, hjælpecenter og marketingwebsted.