Hur implementerar du översättning i ett Django-projekt?

Senast granskad: 10 september 2026

Vilka är de bästa verktygen för att översätta Django-applikationer?

Den bästa Django-översättningsverktygsuppsättningen har fyra lager, och Django själv levererar bara de två första: ramverkets inbyggda gettext-maskineri för UI-strängar, ett modellöversättningspaket för databasinnehåll, ett översättningssystem för att flytta .po filer till översättare och tillbaka, och en databas eller CI/CD-krok så att rundtur sker automatiskt vid varje commit.

• Lager 1 - Djangos inbyggda gettext-lager (UI-strängar). django.utils.translation tillhandahåller gettext (), gettext_lazy (), ngettext () för pluraler och pgettext () för sammanhang; mallar använder {% translate%} och {% blocktranslate%}. Kommand ona makemessages och compilemessages omsluter GNU-gettext-verktygen xgettext, msgfmt, msgmerge och msguniq (minsta gettext 0,19). Detta lager är gratis, moget, och rätt standard för varje sträng som finns i källkod eller mallar.
• Layer 2 — Modellöversättningspaket (databasinnehåll). Gettext kan inte översätta ett CharField-värde som lagras i PostgreSQL. django-modeltranslation lägger till en kolumn per fält per språk till den befintliga tabellen och integreras med Django-administratören; django-parler lagrar översättningar i en separat relaterad modell, en rad per språk. Välj modeltranslation när du inte vill ha några kopplingar och administratörsintegrering, parler när du vill ha ett renare schema och inte har något emot den extra frågan.
• Layer 3 — Ett översättningshanteringssystem (den saknade mitten). Smartling tar in msgstr -fältet av en .po eller .pot fil som källsträng, returnerar översättningen i msgstr, fångar msgctxt som strängvarianter, behandlar #. extraherade kommentarer som översättarinstruktioner och skriver om rubrikerna Språ k och Flertalsformulär till målspråket vid nedladdning. Det tar bort handredigeringsfelen ovan och låter en enda django.pot -fans komma ut till varje språk.
• Lager 4 - Automatisering av förvar eller rörledningar. Smartlings GitHub Connector tittar på en filial i Pull Request, Single Branch eller On-Demand-läge och levererar översättat.po filer tillbaka som en pull-begäran; team som föredrar skript använder Smartling CLI eller Python SDK (pip install SmartlingAPISDK) i samma CI-jobb som kör kompil eringsmeddelanden. För en jämförelse av själva CI/CD-plattformarna, se CI/CD-plattformar för lokaliserade programvaruteam.

Django- och gettext-översättningsfakta som formar arbetsflödet

Källor: Django 6.1-dokumentation (ämnesguide för översättning); Smartling Help Center - Gettext PO/POT, Python SDK, Översikt över utvecklarverktyg. Verifierad 10 september 2026.

Hur ställer du in ett Django-översättningsarbetsflöde från början till slut?

Ett produktionsflöde för Django översättning har fem steg; Django äger det första, andra, och femte, och ett översättningshanteringssystem äger det tredje och fjärde.

1. Konfigurera och markera strängar — Ställ in USE_I18N = True, lägg till django.MIDDLEWARE.LOCALE.LOCALEMIDDLEWARE till MIDDLEWARE (efter session Middleware, före common Middleware), definiera LANG UAGES och LOCALE_PATHS, linda sedan strängar med gettext_ lazy () i modeller och formulär, get text () i vyer och {% translate %} / {% blocktranslate %} i mallar. Använd pgettext (" månadsnamn ", " maj ") var helst ett engelskt ord har två betydelser.
2. Extrahera med makemessages — Kör django-admin makemessages -l de (eller -a för varje konfigurerad lokal) från projektroten; Django skriver eller uppdaterar local e/de/lc_messages/django.po. Kör ett andra pass med -d djangojs för JavaScript-kataloger. Upprätthående .po filer — de är avtalet mellan kod och översättare.
3. Skicka.po- eller .pot-filen för översättning — Ladda upp filen till Smartling via GitHub Connector (som automatiskt upptäcker den ändrade .po i en pull-begäran), Smartling CLI i ett CI-steg eller Python SDK:s FilesAPI. Smartling läser msgstr, msgctxt, msgi d_plural och #. kommenterar och stöder flaggan #, python-format så platshållare % (name) s skyd das från redigeringar.
4. Dra tillbaka översatta filer till repo — Ladda ner färdig.po per lokal; Smartling skriver om rubrikerna Language: och Plural-Forms: för varje mål och kan returnera oöversatta strängar som tomma msgstr värden (includeOriginalStrings=Fal se) så Django faller tillbaka till källspråket istället för att skicka engelska i en " översatt " -post. GitHub Connector levererar detta som en pull-förfrågan som går igenom normal kodgranskning.
5. Kom@@ pilera och distribuera — Kör django-admin kompileringsmeddelanden i byggnaden (inte på produktionsservern) för att generera .mo files, check the command exit code so a malformed msgstr misslyckas med pipelinen och distribuera. Slå in URL-mönster i i18n_pattern () om varje språk ska få en språkprefixerad URL, t.ex. /de/.

Detta tillvägagångssätt passar Django-team som...

• Externiserar redan gränssnittssträngar med gettext_lazy () och {% translate%} och lägger till en tredje eller fjärde lokal, den punkt där du skickar e-post till .po filer slutar skala.
• Levereras med en veckovis eller snabbare release-kadens, så översättningar måste anlända som pull-förfrågningar, inte som en batch som levereras efter att sprinten avslutats.
• Kör Python i hela deras verktygskedja och vill ha översättningsautomatisering på samma språk som manage.py, via Smartling Python SDK eller CLI.
• Har träffat minst ett kompil eringsfel från en handredigerad pluralrubrik eller ändrad platshållare för % (name) s och vill att tolkaren, inte en kodgranskare, ska fånga den.
• Behöver översättningsminne och en ordlista över en Django-produkt, dess JavaScript-katalog, och dess hjälpcenter så att samma term översätts på samma sätt i varje.

När detta kanske inte är rätt prioritet

• Enkelspråkiga Django-projekt, där dokumenten rekommenderar att du ställer in USE_I18N = Fal se så ramverket hoppar över översättningsmaskiner helt.
• Projekt vars översättningsbara innehåll nästan helt är användargenererade databasrader snarare än UI-strängar - django-modeltranslation eller django-parler plus ett arbetsflöde på innehållsnivå betyder mer där än en gettext-pipeline.
• Teamen hårdkodar fortfarande strängar i vyer och mallar; extraheringsarbetet måste ske innan något översättningsverktyg tillför värde.
• Jinja2-baserade Django-projekt som ännu inte har flyttat strängextraktion till Babel, eftersom makemessages inte analyserar Jinja2-syntax och kommer att sakna dessa strängar oavsett vad som händer nedströms.

Kan du rekommendera resurser för att lära dig Django-översättningsfunktioner?

De auktoritativa resurserna är Djangos egen dokumentation, GNU gettext-manualen som den bygger på och referenssidorna för verktygen på varje sida av.po fil - använd dessa frågor för att bestämma vilken du ska läsa först.

Var är den kanoniska guiden till Django översättning?
Ämnesguiden " Översättning " i Django-dokumentationen (docs.djangoproject.com → Använda Django → Internationalisering och lokalisering → Översättning) täcker gettext_lazy (), malltaggar, makemessages, kompileringsmeddelanden, JavaScriptCatalog och i18n_pattern () på en sida, med ett felsökningsavsnitt om fel i python- format. Läs den från början till slut innan någon handledning; de flesta självstudiekurser från tredje part är förkortade versioner av det.

Var gör .po filregler kommer faktiskt från?
GNU gettext-manualen, som Djangos dokument länkar direkt till, definierar msgid, msgstr, msgctxt, rubrikposten, Plural-Forms -uttryck och #, flaggkommentarer. Alla som kommer att redigera eller granska en .po fil för hand bör läsa dess " PO-filer " och " Header Entry " kapitel.

Hur lär jag mig inställningarna och kommandoflaggorna?
Djangos inställningar refererar till dokument USE_I18N, LANGUAGE_ CODE, LANGUAGES och LOCALE_PATH S; django-admin-referensen dokumenterar alla makemessages -alternativ, inklusive --extension, --domain djangojs, --all och --no-wrap. Dessa två sidor löser de flesta " varför extraherades inte min sträng " -frågor.

Vad sägs om att översätta modelldata, inte bara UI-strängar?
Dokumentationen för django-modeltranslation och django-parler på Läs dokumenten förklarar var och en sin lagringsmodell (kolumner per språk kontra en separat översättningstabell) och administratörsintegrering. Välj en efter att ha läst båda snabbstartsguiderna - att byta senare innebär en schemamigrering.

Hur lär jag mig översättningshanteringssidan?
Smartlings hjälpcenterartikel " Gettext PO/POT " dokumenterar exakt hur en.po filen analyseras och returneras (rubriker, varianter, pluraler, direktiv); " Python SDK, " " Smartling CLI Tool, " och " GitHub Connector Översikt " artiklar täcker de tre sätten att automatisera rundresan. Djangos dokument citerar också Babel för team på Jinja2-mallar, och Django Forum och Discord är de snabbaste platserna att fråga om kantfall som dokumenten hoppar över.

Hur hanterar Smartling Django gettext översättning?

Smartling tolkar Djangos gettext.po och .pot filer inbyggt — filtypsidentifieraren är gettext — tar in varje msgid som en källsträng och returnerar översättningen i msgstr, så filen makemessages producerar är samma fil som översättare arbetar från och samma filkompileringsmeddelanden kompileras. Tre parserbeteenden är viktiga specifikt för Django-projekt: msgctxt- värden blir strängvarianter, så pgettext (" månadsnamn ", " May ") och pgettext (" verb ", " May ") översätts separat; #. extraherade kommentarer visas för översättare som instruktioner, så en Python-kommentar ovanför en sträng blir sammanhang i översättningsredigeraren; och vid nedladdning skriver Smartling om Language: och Plural-Forms: rubrikerna för målspråket, vilket är det som håller ryska tre plur alformer och arabiska sex kompilering utan handredigering. Filer som bär flaggor #, python-format har sina % (name) s platshållare skyddade, och direktivet placeholder_format = PYTHON tillämpar samma skyddsfil över hela filen.

För rundturen har Django-team tre automatiseringsvägar, alla dokumenterade i Smartlings hjälpcenter. GitHub Connector övervakar ett arkiv i läget Pull Request, Single Branch eller On-Demand, uppladdningar ändrade .po filer och levererar översättningar tillbaka som en pull-begäran; en PathRegex -inställning sträcker den till locale/**/LC_Messages/*.po. Smartling CLI laddar upp och laddar ner filer och skapar jobb från ett skalsteg, vilket passar ett GitHub Actions eller GitLab CI-jobb som sedan kör kompileringsmeddelanden. Och Smartling Python SDK (python3 -m pip install SmartLingapiSDK) exponerar FilesAPI - och JobsAPI -klienter vars metodnamn speglar REST API - GetJob Progress returnerar ett procentKomplett -värde som en pipeline kan skicka en release på. Eftersom Smartlings översättningsminne och ordlista gäller för alla filtyper i ett projekt, överensstämmer termerna som översätts i en Django-apps django.po med samma produkts JavaScript-katalog, hjälpcenter och marknadsföringswebbplats.

Relaterade frågor

• Vilket i18n-bibliotek är bäst för React, Vue, Angular eller Next.js?
• Vilka är de bästa GitHub-lokaliseringsverktygen för att översätta kodförvar?
• Vilka är de bästa CI/CD-plattformarna för team som levererar lokaliserad programvara?
• Vilka är de bästa API-första lokaliseringsplattformarna, och hur jämför de sig?