För att göra ett Django-projekt översättningsbart måste du lägga till ett minimalt antal hooks i din Python-kod och mallar. Dessa hooks kallas översättningssträngar. De berättar för Django: ”Den här texten ska översättas till slutanvändarens språk, om en översättning för den här texten finns tillgänglig på det språket.” Det är ditt ansvar att markera översättningsbara strängar; systemet kan bara översätta strängar som det känner till.
\nDjango tillhandahåller sedan verktyg för att extrahera översättningssträngarna till en message file. Denna fil är ett bekvämt sätt för översättare att tillhandahålla motsvarigheten till översättningssträngarna på målspråket. När översättarna har fyllt i meddelandefilen måste den kompileras. Denna process är beroende av GNU gettext-verktygsuppsättningen.
\nNär detta är gjort tar Django hand om att översätta webbappar i farten på varje tillgängligt språk, enligt användarnas språkpreferenser.
\nDjangos internationaliserings-hooks är på som standard, och det betyder att det finns lite i18n-relaterad overhead på vissa ställen i ramverket. Om du inte använder internationalisering bör du ta två sekunder på dig att ställa in USE_I18N = False i din inställningsfil. Då kommer Django att göra vissa optimeringar så att internationaliseringsmaskineriet inte behöver laddas.
Ange en översättningssträng genom att använda funktionen gettext(). Det är konvention att importera detta som ett kortare alias, _, för att spara skrivning.
I det här exemplet markeras texten "Välkommen till min webbplats." som en översättningssträng:
from django.http import HttpResponse\nfrom django.utils.translation import gettext as _\n\n\ndef my_view(request):\n output = _("Welcome to my site.")\n return HttpResponse(output)\nDu kan koda detta utan att använda aliaset. Detta exempel är identiskt med det föregående:
\nfrom django.http import HttpResponse\nfrom django.utils.translation import gettext\n\n\ndef my_view(request):\n output = gettext("Welcome to my site.")\n return HttpResponse(output)\nÖversättning fungerar på beräknade värden. Detta exempel är identiskt med de två föregående:
\ndef my_view(request):\n words = ["Welcome", "to", "my", "site."]\n output = _(" ".join(words))\n return HttpResponse(output)\nÖversättning fungerar på variabler. Återigen, här är ett identiskt exempel:
\ndef my_view(request):\n sentence = "Welcome to my site."\n output = _(sentence)\n return HttpResponse(output)\n(Varningen med att använda variabler eller beräknade värden, som i de två föregående exemplen, är att Djangos verktyg för att upptäcka översättningssträngar, django-admin makemessages, inte kommer att kunna hitta dessa strängar. Mer om makemessages senare)
Strängarna som du skickar till _() eller gettext() kan innehålla platshållare som anges med Pythons standardiserade syntax för interpolering av namngivna strängar. Exempel:
def my_view(request, m, d):\n output = _("Today is %(month)s %(day)s.") % {"month": m, "day": d}\n return HttpResponse(output)\nMed den här tekniken kan språkspecifika översättningar ändra ordningen på platshållartexten. Till exempel kan en engelsk översättning vara ”Today is November 26.”, medan en spansk översättning kan vara ”Hoy es 26 de noviembre.” - med platshållarna för månad och dag ombytta.
\nAv denna anledning bör du använda namngiven stränginterpolering (t.ex. %(day)s) i stället för positionsinterpolering (t.ex. %s eller %d) när du har mer än en enda parameter. Om du använde positionell interpolering skulle översättningarna inte kunna ändra ordningen på platshållartexten.
Since string extraction is done by the xgettext command, only syntaxes\nsupported by gettext are supported by Django. Python f-strings cannot be used directly with gettext functions because\nf-string expressions are evaluated before they reach gettext. This means\n_(f"Welcome {name}") will not work as expected, as the variable is\nsubstituted before translation occurs. Instead, use named-string\ninterpolation:
# Good\n_("Welcome %(name)s") % {"name": name}\n\n# Good\n_("Welcome {name}").format(name=name)\n\n# Bad\n_(f"Welcome {name}") # f-string evaluated before translation.\nJavaScript-mallsträngar kräver gettext 0.21+.
Om du vill ge översättarna tips om en översättningsbar sträng kan du lägga till en kommentar med nyckelordet Translators som prefix på raden före strängen, t.ex.:
def my_view(request):\n # Translators: This message appears on the home page only\n output = gettext("Welcome to my site.")\nKommentaren kommer sedan att visas i den resulterande filen .po som är associerad med den översättningsbara konstruktionen som finns under den och bör också visas av de flesta översättningsverktyg.
Detta fungerar även i mallar. Se Kommentarer för översättare i mallar för mer information.
\nUse the function django.utils.translation.gettext_noop() to mark a\nstring as a translation string without translating it. The string is later\ntranslated from a variable.
Använd detta om du har konstanta strängar som bör lagras på källspråket eftersom de utbyts mellan system eller användare - t.ex. strängar i en databas - men som bör översättas vid sista möjliga tidpunkt, t.ex. när strängen presenteras för användaren.
\nUse the function django.utils.translation.ngettext() to specify\npluralized messages.
ngettext() tar tre argument: översättningssträngen i singular, översättningssträngen i plural och antalet objekt.
Den här funktionen är användbar när du vill att din Django-applikation ska kunna lokaliseras till språk där antalet och komplexiteten i pluralformerna <https://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms>`_ är större än de två former som används på engelska (”object” för singular och ”objects” för alla fall där ”count” skiljer sig från ett, oavsett dess värde)
\nTill exempel:
\nfrom django.http import HttpResponse\nfrom django.utils.translation import ngettext\n\n\ndef hello_world(request, count):\n page = ngettext(\n "there is %(count)d object",\n "there are %(count)d objects",\n count,\n ) % {\n "count": count,\n }\n return HttpResponse(page)\nI det här exemplet skickas antalet objekt till översättningsspråken som variabeln ”count”.
\nObservera att pluralisering är komplicerat och fungerar olika på olika språk. Att jämföra count med 1 är inte alltid den korrekta regeln. Den här koden ser sofistikerad ut, men kommer att ge felaktiga resultat för vissa språk:
from django.utils.translation import ngettext\nfrom myapp.models import Report\n\ncount = Report.objects.count()\nif count == 1:\n name = Report._meta.verbose_name\nelse:\n name = Report._meta.verbose_name_plural\n\ntext = ngettext(\n "There is %(count)d %(name)s available.",\n "There are %(count)d %(name)s available.",\n count,\n) % {"count": count, "name": name}\nFörsök inte att implementera din egen singular-eller-plural-logik; den kommer inte att vara korrekt. I ett fall som detta kan man tänka sig något i stil med följande:
\ntext = ngettext(\n "There is %(count)d %(name)s object available.",\n "There are %(count)d %(name)s objects available.",\n count,\n) % {\n "count": count,\n "name": Report._meta.verbose_name,\n}\nSometimes words have several meanings, such as "May" in English, which\nrefers to a month name and to a verb. To enable translators to translate\nthese words correctly in different contexts, you can use the\ndjango.utils.translation.pgettext() function, or the\ndjango.utils.translation.npgettext() function if the string needs\npluralization. Both take a context string as the first variable.
I den resulterande .po-filen kommer strängen sedan att visas så ofta som det finns olika kontextuella markörer för samma sträng (kontexten visas på msgctxt-raden), vilket gör det möjligt för översättaren att ge en annan översättning för var och en av dem.
Till exempel:
\nfrom django.utils.translation import pgettext\n\nmonth = pgettext("month name", "May")\neller:
\nfrom django.db import models\nfrom django.utils.translation import pgettext_lazy\n\n\nclass MyThing(models.Model):\n name = models.CharField(\n help_text=pgettext_lazy("help text for MyThing model", "This is the help text")\n )\nkommer att visas i filen .po som:
msgctxt "month name"\nmsgid "May"\nmsgstr ""\nKontextuella markörer stöds också av malltaggarna translate och blocktranslate.
Använd de lata versionerna av översättningsfunktioner i django.utils.translation (lätt igenkännliga genom suffixet lazy i deras namn) för att översätta strängar lata – när värdet nås snarare än när de anropas.
Dessa funktioner lagrar en latent referens till strängen - inte den faktiska översättningen. Själva översättningen görs när strängen används i en strängkontext, t.ex. i mallrendering.
\nDetta är viktigt när anrop till dessa funktioner finns i kodvägar som exekveras vid modulens laddningstid.
\nDetta är något som lätt kan hända när man definierar modeller, formulär och modellformulär, eftersom Django implementerar dessa så att deras fält faktiskt är attribut på klassnivå. Se därför till att använda lazy translations i följande fall:
\nverbose_name och help_text alternativvärdenLink to this heading#Om du t.ex. vill översätta hjälptexten för fältet name i följande modell gör du så här:
\nfrom django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass MyThing(models.Model):\n name = models.CharField(help_text=_("This is the help text"))\nDu kan markera namn på ForeignKey, ManyToManyField eller OneToOneField relationer som översättningsbara genom att använda deras verbose_name alternativ:
class MyThing(models.Model):\n kind = models.ForeignKey(\n ThingKind,\n on_delete=models.CASCADE,\n related_name="kinds",\n verbose_name=_("kind"),\n )\nPrecis som du skulle göra i verbose_name bör du ange en text med små bokstäver för verbose-namnet för relationen eftersom Django automatiskt kommer att skriva det med små bokstäver när det krävs.
Det rekommenderas att alltid tillhandahålla explicita verbose_name och verbose_name_plural alternativ snarare än att förlita sig på den engelska-centrerade och något naiva bestämningen av verbose-namn som Django utför genom att titta på modellens klassnamn:
from django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass MyThing(models.Model):\n name = models.CharField(_("name"), help_text=_("This is the help text"))\n\n class Meta:\n verbose_name = _("my thing")\n verbose_name_plural = _("my things")\ndescription argument till @display dekoratornLink to this heading#För modellmetoder kan du tillhandahålla översättningar till Django och admin-webbplatsen med argumentet description till display() decorator:
from django.contrib import admin\nfrom django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass MyThing(models.Model):\n kind = models.ForeignKey(\n ThingKind,\n on_delete=models.CASCADE,\n related_name="kinds",\n verbose_name=_("kind"),\n )\n\n @admin.display(description=_("Is it a mouse?"))\n def is_mouse(self):\n return self.kind.type == MOUSE_TYPE\nResultatet av ett gettext_lazy()-anrop kan användas där du skulle använda en sträng (ett str-objekt) i annan Django-kod, men det kanske inte fungerar med godtycklig Python-kod. Till exempel kommer följande inte att fungera eftersom biblioteket requests inte hanterar gettext_lazy-objekt:
body = gettext_lazy("I \\u2764 Django") # (Unicode :heart:)\nrequests.post("https://example.com/send", data={"body": body})\nDu kan undvika sådana problem genom att kasta gettext_lazy()-objekt till textsträngar innan du skickar dem till icke-Django-kod:
requests.post("https://example.com/send", data={"body": str(body)})\nOm du inte gillar det långa namnet gettext_lazy kan du använda aliaset _ (understreck), så här:
from django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass MyThing(models.Model):\n name = models.CharField(help_text=_("This is the help text"))\nAtt använda gettext_lazy() och ngettext_lazy() för att markera strängar i modeller och verktygsfunktioner är en vanlig operation. När du arbetar med dessa objekt på andra ställen i din kod bör du se till att du inte av misstag konverterar dem till strängar, eftersom de bör konverteras så sent som möjligt (så att rätt lokal används). Detta gör det nödvändigt att använda den hjälpfunktion som beskrivs härnäst.
När du använder latent översättning för en pluralsträng (n[p]gettext_lazy) känner du i allmänhet inte till argumentet number vid tidpunkten för strängdefinitionen. Därför är du behörig att skicka ett nyckelnamn istället för ett heltal som argumentet number. Då kommer number att slås upp i ordlistan under den nyckeln vid stränginterpolering. Här är ett exempel:
from django import forms\nfrom django.core.exceptions import ValidationError\nfrom django.utils.translation import ngettext_lazy\n\n\nclass MyForm(forms.Form):\n error_message = ngettext_lazy(\n "You only provided %(num)d argument",\n "You only provided %(num)d arguments",\n "num",\n )\n\n def clean(self):\n # ...\n if error:\n raise ValidationError(self.error_message % {"num": number})\nOm strängen innehåller exakt en icke namngiven platshållare kan du interpolerar direkt med argumentet number:
class MyForm(forms.Form):\n error_message = ngettext_lazy(\n "You provided %d argument",\n "You provided %d arguments",\n )\n\n def clean(self):\n # ...\n if error:\n raise ValidationError(self.error_message % number)\nformat_lazy()Link to this heading#Python’s str.format() method will not work when either the\nformat_string or any of the arguments to str.format()\ncontains lazy translation objects. Instead, you can use\ndjango.utils.text.format_lazy(), which creates a lazy object\nthat runs the str.format() method only when the result is included\nin a string. For example:
from django.utils.text import format_lazy\nfrom django.utils.translation import gettext_lazy\n\n...\nname = gettext_lazy("John Lennon")\ninstrument = gettext_lazy("guitar")\nresult = format_lazy("{name}: {instrument}", name=name, instrument=instrument)\nI det här fallet kommer de lata översättningarna i result endast att konverteras till strängar när result själv används i en sträng (vanligtvis vid mallens renderingstid).
För alla andra fall där du vill fördröja översättningen, men måste skicka den översättningsbara strängen som argument till en annan funktion, kan du själv packa in den här funktionen i ett lazy call. Till exempel:
\nfrom django.utils.functional import lazy\nfrom django.utils.translation import gettext_lazy as _\n\n\ndef to_lower(string):\n return string.lower()\n\n\nto_lower_lazy = lazy(to_lower, str)\nOch sedan senare:
\nlazy_string = to_lower_lazy(_("My STRING!"))\nFunktionen get_language_info() ger detaljerad information om språk:
>>> from django.utils.translation import activate, get_language_info\n>>> activate("fr")\n>>> li = get_language_info("de")\n>>> print(li["name"], li["name_local"], li["name_translated"], li["bidi"])\nGerman Deutsch Allemand False\nThe name, name_local, and name_translated attributes of the\ndictionary contain the name of the language in English, in the language\nitself, and in your current active language respectively. The bidi\nattribute is True only for bi-directional languages.
Källan till språkinformationen är modulen django.conf.locale. Liknande tillgång till denna information är tillgänglig för mallkod. Se nedan.
Översättningar i Django templates använder två malltaggar och en något annorlunda syntax än i Python-kod. För att ge din mall tillgång till dessa taggar, lägg {% load i18n %} längst upp i din mall. Som med alla malltaggar måste denna tagg laddas i alla mallar som använder översättningar, även de mallar som bygger på andra mallar som redan har laddat i18n-taggen.
translate mall taggLink to this heading#Malltaggen {% translate %} översätter antingen en konstant sträng (omgiven av enkla eller dubbla citattecken) eller variabelt innehåll:
<title>{% translate "This is the title." %}</title>\n<title>{% translate myvar %}</title>\nOm alternativet noop finns kvar sker fortfarande variabeluppslagning, men översättningen hoppas över. Detta är användbart när man ”stubbar ut” innehåll som kommer att behöva översättas i framtiden:
<title>{% translate "myvar" noop %}</title>\nInternt använder inline-översättningar ett gettext()-anrop.
Om en mallvariabel (myvar ovan) skickas till taggen kommer taggen först att omvandla variabeln till en sträng under körningen och sedan leta upp strängen i meddelandekatalogen.
Det är inte möjligt att blanda en mallvariabel i en sträng inom {% translate %}. Om dina översättningar kräver strängar med variabler (platshållare), använd {% blocktranslate %} istället.
Om du vill hämta en översatt sträng utan att visa den kan du använda följande syntax:
\n{% translate "This is the title" as the_title %}\n\n<title>{{ the_title }}</title>\n<meta name="description" content="{{ the_title }}">\nI praktiken använder du detta för att få en sträng som du kan använda på flera ställen i en mall eller så att du kan använda utdata som ett argument för andra malltaggar eller filter:
\n{% translate "starting point" as start %}\n{% translate "end point" as end %}\n{% translate "La Grande Boucle" as race %}\n\n<h1>\n <a href="/" title="{% blocktranslate %}Back to '{{ race }}' homepage{% endblocktranslate %}">{{ race }}</a>\n</h1>\n<p>\n{% for stage in tour_stages %}\n {% cycle start end %}: {{ stage }}{% if forloop.counter|divisibleby:2 %}<br>{% else %}, {% endif %}\n{% endfor %}\n</p>\n{% translate %} stöder även kontextuella markörer med hjälp av nyckelordet context:
{% translate "May" context "month name" %}\nblocktranslate mall taggLink to this heading#I motsats till taggen translate kan du med taggen blocktranslate markera komplexa meningar som består av bokstavstecken och variabelt innehåll för översättning genom att använda platshållare:
{% blocktranslate %}This string will have {{ value }} inside.{% endblocktranslate %}\nFör att översätta ett malluttryck - t.ex. åtkomst till objektattribut eller användning av mallfilter - måste du binda uttrycket till en lokal variabel som kan användas i översättningsblocket. Exempel på detta:
\n{% blocktranslate with amount=article.price %}\nThat will cost $ {{ amount }}.\n{% endblocktranslate %}\n\n{% blocktranslate with myvar=value|filter %}\nThis will have {{ myvar }} inside.\n{% endblocktranslate %}\nDu kan använda flera uttryck i en enda blocktranslate-tagg:
{% blocktranslate with book_t=book|title author_t=author|title %}\nThis is {{ book_t }} by {{ author_t }}\n{% endblocktranslate %}\nAndra blocktaggar (till exempel {% for %} eller {% if %}) är inte tillåtna inuti en blocktranslate-tagg.
Om lösningen av ett av blockargumenten misslyckas kommer blocktranslate att falla tillbaka till standardspråket genom att avaktivera det aktuella aktiva språket tillfälligt med funktionen deactivate_all().
Den här taggen möjliggör även pluralisering. För att använda den:
\nUtse och bind ett räknevärde med namnet count. Detta värde kommer att vara det som används för att välja rätt pluralform.
Ange både singular- och pluralformerna och separera dem med taggen {% plural %} i taggarna {% blocktranslate %} och {% endblocktranslate %}.
Ett exempel:
\n{% blocktranslate count counter=list|length %}\nThere is {{ counter }} {{ name }} object.\n{% plural %}\nThere are {{ counter }} {{ name }} objects.\n{% endblocktranslate %}\nEtt mer komplext exempel:
\n{% blocktranslate with amount=article.price count years=i.length %}\nThat will cost $ {{ amount }} per year.\n{% plural %}\nThat will cost $ {{ amount }} per {{ years }} years.\n{% endblocktranslate %}\nNär du använder både pluraliseringsfunktionen och binder värden till lokala variabler utöver räknevärdet, kom ihåg att blocktranslate-konstruktionen internt konverteras till ett ngettext-anrop. Detta innebär att samma noteringar om ngettext-variabler gäller.
Omvända URL-uppslagningar kan inte utföras inom blocktranslate och bör hämtas (och lagras) i förväg:
{% url 'path.to.view' arg arg2 as the_url %}\n{% blocktranslate %}\nThis is a URL: {{ the_url }}\n{% endblocktranslate %}\nOm du vill hämta en översatt sträng utan att visa den kan du använda följande syntax:
\n{% blocktranslate asvar the_title %}The title is {{ title }}.{% endblocktranslate %}\n<title>{{ the_title }}</title>\n<meta name="description" content="{{ the_title }}">\nI praktiken använder du detta för att få en sträng som du kan använda på flera ställen i en mall eller så att du kan använda utdata som ett argument för andra malltaggar eller filter.
\n{% blocktranslate %} stöder även kontextuella markörer med hjälp av nyckelordet context:
{% blocktranslate with name=user.username context "greeting" %}Hi {{ name }}{% endblocktranslate %}\nEn annan funktion som stöds av {% blocktranslate %} är alternativet trimmed. Detta alternativ tar bort ny rad-tecken från början och slutet av innehållet i taggen {% blocktranslate %}, ersätter alla blanksteg i början och slutet av en rad och sammanfogar alla rader till en med ett mellanslagstecken för att separera dem. Detta är mycket användbart för att indentera innehållet i en {% blocktranslate %}-tagg utan att indentationstecknen hamnar i motsvarande post i filen .po, vilket gör översättningsprocessen enklare.
Till exempel följande tagg {% blocktranslate %}:
{% blocktranslate trimmed %}\n First sentence.\n Second paragraph.\n{% endblocktranslate %}\nkommer att resultera i posten "Första meningen. Second paragraph." i filen .po, jämfört med "\\n First sentence.\\n Second paragraph.\\n", om alternativet trimmed inte hade angetts.
Precis som med Python-kod kan dessa anteckningar för översättare anges med hjälp av kommentarer, antingen med taggen comment:
{% comment %}Translators: View verb{% endcomment %}\n{% translate "View" %}\n\n{% comment %}Translators: Short intro blurb{% endcomment %}\n<p>{% blocktranslate %}A multiline translatable\nliteral.{% endblocktranslate %}</p>\neller med {# … #} enradskommentarer konstrueras:
{# Translators: Label of a button that triggers search #}\n<button type="submit">{% translate "Go" %}</button>\n\n{# Translators: This is a text of the base template #}\n{% blocktranslate %}Ambiguous translatable block of text{% endblocktranslate %}\nOm du vill välja ett språk i en mall kan du använda malltaggen language:
{% load i18n %}\n\n{% get_current_language as LANGUAGE_CODE %}\n<!-- Current language: {{ LANGUAGE_CODE }} -->\n<p>{% translate "Welcome to our page" %}</p>\n\n{% language 'en' %}\n {% get_current_language as LANGUAGE_CODE %}\n <!-- Current language: {{ LANGUAGE_CODE }} -->\n <p>{% translate "Welcome to our page" %}</p>\n{% endlanguage %}\nMedan den första förekomsten av ”Välkommen till vår sida” använder det aktuella språket, kommer den andra alltid att vara på engelska.
\nAtt lägga till översättningar i JavaScript innebär vissa problem:
\nJavaScript-kod har inte tillgång till en gettext-implementering.
JavaScript-kod har inte tillgång till filerna .po eller .mo, utan de måste levereras av servern.
Översättningskatalogerna för JavaScript bör hållas så små som möjligt.
Django erbjuder en integrerad lösning för dessa problem: Översättningarna skickas till JavaScript, så att du kan anropa gettext etc. från JavaScript.
Den huvudsakliga lösningen på dessa problem är följande vy JavaScriptCatalog, som genererar ett JavaScript-kodbibliotek med funktioner som efterliknar gränssnittet gettext, plus en matris med översättningssträngar.
JavaScriptCatalog (JavaScript-katalog)Link to this heading#En vy som producerar ett JavaScript-kodbibliotek med funktioner som efterliknar gränssnittet gettext, plus en matris med översättningssträngar.
Attribut
\nÖversättningsdomän som innehåller strängar som ska läggas till i vyns utdata. Standardvärdet är 'djangojs.
A list of application names (AppConfig.name) among the\ninstalled applications. Those apps should contain a locale\ndirectory. All those catalogs plus all catalogs found in\nLOCALE_PATHS (which are always included) are merged into one\ncatalog. Defaults to None, which means that all available\ntranslations from all INSTALLED_APPS are provided in the\nJavaScript output.
Exempel med standardvärden:
\nfrom django.views.i18n import JavaScriptCatalog\n\nurlpatterns = [\n path("jsi18n/", JavaScriptCatalog.as_view(), name="javascript-catalog"),\n]\nExempel med anpassade paket:
\nurlpatterns = [\n path(\n "jsi18n/myapp/",\n JavaScriptCatalog.as_view(packages=["your.app.label"]),\n name="javascript-catalog",\n ),\n]\nOm din root URLconf använder i18n_patterns(), måste JavaScriptCatalog också omslutas av i18n_patterns() för att katalogen ska genereras korrekt.
Exempel med i18n_patterns():
from django.conf.urls.i18n import i18n_patterns\n\nurlpatterns = i18n_patterns(\n path("jsi18n/", JavaScriptCatalog.as_view(), name="javascript-catalog"),\n)\nÖversättningarnas prioritet är sådan att de paket som förekommer senare i argumentet packages har högre prioritet än de som förekommer i början. Detta är viktigt när det gäller krockande översättningar för samma bokstav.
Om du använder mer än en JavaScriptCatalog-vy på en webbplats och några av dem definierar samma strängar, har strängarna i den katalog som laddades senast företräde.
För att använda katalogen drar du in det dynamiskt genererade skriptet så här:
\n<script src="{% url 'javascript-catalog' %}"></script>\nDetta använder omvänd URL-uppslagning för att hitta URL:en för JavaScript-katalogvyn. När katalogen är laddad kan din JavaScript-kod använda följande metoder:
\ngettext
ngettext
interpolera
get_format
gettext_noop
pgettext
npgettext
pluralidx
gettextLink to this heading#Funktionen gettext beter sig på samma sätt som standardgränssnittet gettext i din Python-kod:
document.write(gettext("this is to be translated"))\nngettextLink to this heading#Funktionen ngettext tillhandahåller ett gränssnitt för att pluralisera ord och fraser:
const objectCount = 1 // or 0, or 2, or 3, ...\nconst string = ngettext(\n 'literal for the singular case',\n 'literal for the plural case',\n objectCount\n);\ninterpoleraLink to this heading#Funktionen interpolate har stöd för att dynamiskt fylla i en formatsträng. Interpolationssyntaxen är lånad från Python, så funktionen interpolate stöder både positions- och namninterpolation:
Positionell interpolering: obj innehåller ett JavaScript Array-objekt vars elementvärden sedan interpoleras sekventiellt i motsvarande fmt-platshållare i samma ordning som de visas. Till exempel:
const formats = ngettext(\n 'There is %s object. Remaining: %s',\n 'There are %s objects. Remaining: %s',\n 11\n);\nconst string = interpolate(formats, [11, 20]);\n// string is 'There are 11 objects. Remaining: 20'\nNamngiven interpolation: Detta läge väljs genom att skicka den valfria booleska parametern named som true. obj innehåller ett JavaScript-objekt eller en associativ matris. Exempelvis:
const data = {\n count: 10,\n total: 50\n};\n\nconst formats = ngettext(\n 'Total: %(total)s, there is %(count)s object',\n 'there are %(count)s of a total of %(total)s objects',\n data.count\n);\nconst string = interpolate(formats, data, true);\nDu bör dock inte överdriva med stränginterpolering: det här är fortfarande JavaScript, så koden måste göra upprepade substitutioner med reguljära uttryck. Detta är inte lika snabbt som stränginterpolering i Python, så håll det till de fall där du verkligen behöver det (till exempel i samband med ngettext för att producera korrekta pluraliseringar).
get_formatLink to this heading#Funktionen get_format har tillgång till de konfigurerade i18n-formateringsinställningarna och kan hämta formatsträngen för ett givet inställningsnamn:
document.write(get_format('DATE_FORMAT'));\n// 'N j, Y'\nDen har tillgång till följande inställningar:
\nFÖRSTA_DAGEN_I_VECKAN
Detta är användbart för att upprätthålla formateringskonsistens med de Python-renderade värdena.
\ngettext_noopLink to this heading#Detta efterliknar funktionen gettext men gör ingenting, utan returnerar det som skickas till den:
document.write(gettext_noop("this will not be translated"))\nDet här är användbart för att stubba ut delar av koden som kommer att behöva översättas i framtiden.
\npgettextLink to this heading#The pgettext function behaves like the Python variant\n(pgettext()), providing a contextually\ntranslated word:
document.write(pgettext("month name", "May"))\nnpgettextLink to this heading#The npgettext function also behaves like the Python variant\n(npgettext()), providing a pluralized\ncontextually translated word:
document.write(npgettext('group', 'party', 1));\n// party\ndocument.write(npgettext('group', 'party', 2));\n// parties\npluralidxLink to this heading#Funktionen pluralidx fungerar på samma sätt som mallfiltret pluralize och avgör om ett givet count ska använda pluralformen av ett ord eller inte:
document.write(pluralidx(0));\n// true\ndocument.write(pluralidx(1));\n// false\ndocument.write(pluralidx(2));\n// true\nI det enklaste fallet, om ingen anpassad pluralisering behövs, returnerar detta false för heltalet 1 och true för alla andra tal.
Pluralisering är dock inte lika enkelt på alla språk. Om språket inte stöder pluralisering anges ett tomt värde.
\nOm det dessutom finns komplexa regler kring pluralisering, kommer katalogvyn att återge ett villkorligt uttryck. Detta utvärderas till antingen ett true (bör pluraliseras) eller false (bör inte pluraliseras) värde.
För att använda ett annat bibliotek på klientsidan för att hantera översättningar kanske du vill dra nytta av vyn JSONCatalog. Den liknar JavaScriptCatalog men returnerar ett JSON-svar.
Se dokumentationen för JavaScriptCatalog för att lära dig mer om möjliga värden och användning av attributen domain och packages.
Svarsformatet är som följer:
\n{\n "catalog": {\n # Translations catalog\n },\n "formats": {\n # Language formats for date, time, etc.\n },\n "plural": "..." # Expression for plural forms, or null.\n}\nDe olika JavaScript/JSON i18n-vyerna genererar katalogen från .mo-filer vid varje förfrågan. Eftersom dess utdata är konstant, åtminstone för en viss version av en webbplats, är det en bra kandidat för cachelagring.
Cachelagring på serversidan minskar CPU-belastningen. Det är enkelt att implementera med cache_page() decorator. För att utlösa cache-invalidering när dina översättningar ändras, ange ett versionsberoende nyckelprefix, som visas i exemplet nedan, eller mappa vyn på en versionsberoende URL:
from django.views.decorators.cache import cache_page\nfrom django.views.i18n import JavaScriptCatalog\n\n# The value returned by get_version() must change when translations change.\nurlpatterns = [\n path(\n "jsi18n/",\n cache_page(86400, key_prefix="jsi18n-%s" % get_version())(\n JavaScriptCatalog.as_view()\n ),\n name="javascript-catalog",\n ),\n]\nCachelagring på klientsidan sparar bandbredd och gör att din webbplats laddas snabbare. Om du använder ETags (ConditionalGetMiddleware) är du redan täckt. Annars kan du tillämpa villkorliga dekoratorer. I följande exempel ogiltigförklaras cachen när du startar om din applikationsserver:
from django.utils import timezone\nfrom django.views.decorators.http import last_modified\nfrom django.views.i18n import JavaScriptCatalog\n\nlast_modified_date = timezone.now()\n\nurlpatterns = [\n path(\n "jsi18n/",\n last_modified(lambda req, **kw: last_modified_date)(\n JavaScriptCatalog.as_view()\n ),\n name="javascript-catalog",\n ),\n]\nDu kan till och med förgenerera JavaScript-katalogen som en del av din distributionsprocedur och servera den som en statisk fil. Denna radikala teknik implementeras i django-statici18n.
\nDjango tillhandahåller två mekanismer för att internationalisera URL-mönster:
\nLägger till språkprefixet i roten av URL-mönstren för att göra det möjligt för LocaleMiddleware att upptäcka vilket språk som ska aktiveras från den begärda URL:en.
Making URL patterns themselves translatable via the\ndjango.utils.translation.gettext_lazy() function.
Denna funktion kan användas i en rot-URLconf och Django kommer automatiskt att preppa den aktuella aktiva språkkoden till alla URL-mönster som definieras inom i18n_patterns().
Om du anger prefix_default_language till False tas prefixet bort från standardspråket (LANGUAGE_CODE). Detta kan vara användbart när du lägger till översättningar på en befintlig webbplats så att de aktuella webbadresserna inte ändras.
Exempel på URL-mönster:
\nfrom django.conf.urls.i18n import i18n_patterns\nfrom django.urls import include, path\n\nfrom about import views as about_views\nfrom news import views as news_views\nfrom sitemap.views import sitemap\n\nurlpatterns = [\n path("sitemap.xml", sitemap, name="sitemap-xml"),\n]\n\nnews_patterns = (\n [\n path("", news_views.index, name="index"),\n path("category/<slug:slug>/", news_views.category, name="category"),\n path("<slug:slug>/", news_views.details, name="detail"),\n ],\n "news",\n)\n\nurlpatterns += i18n_patterns(\n path("about/", about_views.main, name="about"),\n path("news/", include(news_patterns, namespace="news")),\n)\nEfter att ha definierat dessa URL-mönster kommer Django automatiskt att lägga till språkprefixet till de URL-mönster som lades till av funktionen i18n_patterns. Exempel på detta:
>>> from django.urls import reverse\n>>> from django.utils.translation import activate\n\n>>> activate("en")\n>>> reverse("sitemap-xml")\n'/sitemap.xml'\n>>> reverse("news:index")\n'/en/news/'\n\n>>> activate("nl")\n>>> reverse("news:detail", kwargs={"slug": "news-slug"})\n'/nl/news/news-slug/'\nMed prefix_default_language=False och LANGUAGE_CODE='en' blir webbadresserna följande:
>>> activate("en")\n>>> reverse("news:index")\n'/news/'\n\n>>> activate("nl")\n>>> reverse("news:index")\n'/nl/news/'\nURL-mönster kan också markeras som översättningsbara med hjälp av funktionen gettext_lazy(). Exempel:
from django.conf.urls.i18n import i18n_patterns\nfrom django.urls import include, path\nfrom django.utils.translation import gettext_lazy as _\n\nfrom about import views as about_views\nfrom news import views as news_views\nfrom sitemaps.views import sitemap\n\nurlpatterns = [\n path("sitemap.xml", sitemap, name="sitemap-xml"),\n]\n\nnews_patterns = (\n [\n path("", news_views.index, name="index"),\n path(_("category/<slug:slug>/"), news_views.category, name="category"),\n path("<slug:slug>/", news_views.details, name="detail"),\n ],\n "news",\n)\n\nurlpatterns += i18n_patterns(\n path(_("about/"), about_views.main, name="about"),\n path(_("news/"), include(news_patterns, namespace="news")),\n)\nNär du har skapat översättningarna kommer funktionen reverse() att returnera webbadressen på det aktiva språket. Exempel på detta:
>>> from django.urls import reverse\n>>> from django.utils.translation import activate\n\n>>> activate("en")\n>>> reverse("news:category", kwargs={"slug": "recent"})\n'/en/news/category/recent/'\n\n>>> activate("nl")\n>>> reverse("news:category", kwargs={"slug": "recent"})\n'/nl/nieuws/categorie/recent/'\nOm lokaliserade webbadresser blir omvända i mallar använder de alltid det aktuella språket. Om du vill länka till en URL på ett annat språk använder du malltaggen language. Den aktiverar det angivna språket i det bifogade mallavsnittet:
{% load i18n %}\n\n{% get_available_languages as languages %}\n\n{% translate "View this category in:" %}\n{% for lang_code, lang_name in languages %}\n {% language lang_code %}\n <a href="{% url 'category' slug=category.slug %}">{{ lang_name }}</a>\n {% endlanguage %}\n{% endfor %}\nTaggen language förväntar sig språkkoden som det enda argumentet.
När stränglitteralerna i en applikation har taggats för senare översättning, måste själva översättningen skrivas (eller erhållas). Så här fungerar det.
\nDet första steget är att skapa en message file för ett nytt språk. En meddelandefil är en fil i klartext som representerar ett enda språk och som innehåller alla tillgängliga översättningssträngar och hur de ska representeras på det aktuella språket. Meddelandefiler har filändelsen .po.
Django levereras med ett verktyg, django-admin makemessages, som automatiserar skapandet och underhållet av dessa filer.
Kör det här kommandot för att skapa eller uppdatera en meddelandefil:
\ndjango-admin makemessages -l de\n…där de är lokalnamn för den meddelandefil du vill skapa. Till exempel pt_BR för brasiliansk portugisiska, de_AT för österrikisk tyska eller id för indonesiska.
Skriptet bör köras från en av två platser:
\nRotkatalogen för ditt Django-projekt (den som innehåller manage.py).
Rotkatalogen för en av dina Django-appar.
Skriptet körs över projektets källträd eller applikationens källträd och drar ut alla strängar som är markerade för översättning (se Hur Django upptäcker översättningar och se till att LOCALE_PATHS är korrekt konfigurerad). Det skapar (eller uppdaterar) en meddelandefil i katalogen locale/LANG/LC_MESSAGES. I exemplet de kommer filen att vara locale/de/LC_MESSAGES/django.po.
När du kör makemessages från rotkatalogen i ditt projekt, kommer de extraherade strängarna automatiskt att distribueras till rätt meddelandefiler. Det vill säga, en sträng som extraheras från en fil i en app som innehåller en locale-katalog kommer att hamna i en meddelandefil under den katalogen. En sträng som extraheras från en fil i en app utan någon locale-katalog kommer antingen att läggas i en meddelandefil under den katalog som listas först i LOCALE_PATHS eller generera ett fel om LOCALE_PATHS är tom.
Som standard undersöker django-admin makemessages alla filer som har filtillägget .html, .txt eller .py. Om du vill åsidosätta denna standard använder du alternativet --extension eller -e för att ange vilka filtillägg som ska undersökas:
django-admin makemessages -l de -e txt\nSeparera flera tillägg med kommatecken och/eller använd -e eller --extension flera gånger:
django-admin makemessages -l de -e html,txt -e xml\nVarje .po-fil innehåller en liten del metadata, till exempel kontaktuppgifter till den som ansvarar för översättningen, men huvuddelen av filen är en lista med messages - mappningar mellan översättningssträngar och den faktiska översatta texten för det aktuella språket.
Till exempel, om din Django-app innehåller en översättningssträng för texten "Välkommen till min webbplats.", så här:
_("Welcome to my site.")\n…då kommer django-admin makemessages att ha skapat en .po-fil som innehåller följande utdrag – ett meddelande:
#: path/to/python/module.py:23\nmsgid "Welcome to my site."\nmsgstr ""\nEn snabb förklaring:
\nmsgid är översättningssträngen, som visas i källan. Ändra inte den.
msgstr är där du lägger in den språkspecifika översättningen. Den är tom från början, så det är ditt ansvar att ändra den. Se till att du behåller citattecknen runt din översättning.
För enkelhetens skull innehåller varje meddelande, i form av en kommentarrad med # som prefix och ovanför msgid-raden, filnamnet och radnumret från vilket översättningssträngen hämtades.
Långa meddelanden är ett specialfall. Där är den första strängen direkt efter msgstr (eller msgid) en tom sträng. Sedan skrivs själva innehållet över de närmaste raderna som en sträng per rad. Dessa strängar konkateneras direkt. Glöm inte efterföljande mellanslag i strängarna; annars kommer de att häftas ihop utan blanksteg!
Om du vill granska all källkod och alla mallar för nya översättningssträngar och uppdatera alla meddelandefiler för alla språk kör du detta:
\ndjango-admin makemessages -a\nNär du har skapat din meddelandefil - och varje gång du gör ändringar i den - måste du sammanställa den till en mer effektiv form som kan användas av gettext. Detta gör du med django-admin compilemessages.
Detta verktyg går igenom alla tillgängliga .po-filer och skapar .mo-filer, som är binära filer optimerade för att användas av gettext. I samma katalog som du körde django-admin makemessages, kör django-admin compilemessages så här:
django-admin compilemessages\nNu är det klart. Dina översättningar är klara att användas.
\n\n\ngettext() upptäcker felaktigt python-format i strängar med procentteckenLink to this heading#I vissa fall, till exempel strängar med ett procenttecken följt av ett mellanslag och en strängkonverteringstyp (t.ex. _("10% interest")), gettext() flaggar felaktigt strängar med python-format.
Om du försöker kompilera meddelandefiler med felaktigt markerade strängar får du ett felmeddelande som antalet formatspecifikationer i 'msgid' och 'msgstr' matchar inte eller 'msgstr' är inte en giltig Python-formatsträng, till skillnad från 'msgid'.
För att kringgå detta kan du undkomma procenttecken genom att lägga till ett andra procenttecken:
\nfrom django.utils.translation import gettext as _\n\noutput = _("10%% interest")\nEller så kan du använda no-python-format så att alla procenttecken behandlas som bokstavstecken:
# xgettext:no-python-format\noutput = _("10% interest")\nDu skapar och uppdaterar meddelandefilerna på samma sätt som de andra Django-meddelandefilerna - med verktyget django-admin makemessages. Den enda skillnaden är att du uttryckligen måste ange vad som på gettextspråk kallas en domän, i det här fallet djangojs-domänen, genom att tillhandahålla en -d djangojs-parameter, så här:
django-admin makemessages -d djangojs -l de\nDetta skulle skapa eller uppdatera meddelandefilen för JavaScript för tyska. Efter uppdatering av meddelandefiler kör du django-admin compilemessages på samma sätt som du gör med vanliga Django-meddelandefiler.
gettext på WindowsLink to this heading#Detta behövs endast för personer som antingen vill extrahera meddelande-ID:n eller sammanställa meddelandefiler (.po). Själva översättningsarbetet innebär att redigera befintliga filer av den här typen, men om du vill skapa dina egna meddelandefiler, eller vill testa eller kompilera en ändrad meddelandefil, ladda ner en förkompilerad binär installerare.
Du kan också använda gettext binära filer som du har fått på annat håll, så länge kommandot xgettext --version fungerar korrekt. Försök inte att använda Djangos översättningsverktyg med ett gettext-paket om kommandot xgettext --version som anges i en Windows-kommandotolk orsakar ett popup-fönster som säger ”xgettext.exe har genererat fel och kommer att stängas av Windows”.
Om du vill skicka ytterligare parametrar till xgettext måste du skapa ett anpassat makemessages-kommando och åsidosätta dess xgettext_options-attribut:
from django.core.management.commands import makemessages\n\n\nclass Command(makemessages.Command):\n xgettext_options = makemessages.Command.xgettext_options + ["--keyword=mytrans"]\nOm du behöver mer flexibilitet kan du också lägga till ett nytt argument till ditt anpassade makemessages-kommando:
from django.core.management.commands import makemessages\n\n\nclass Command(makemessages.Command):\n def add_arguments(self, parser):\n super().add_arguments(parser)\n parser.add_argument(\n "--extra-keyword",\n dest="xgettext_keywords",\n action="append",\n )\n\n def handle(self, *args, **options):\n xgettext_keywords = options.pop("xgettext_keywords")\n if xgettext_keywords:\n self.xgettext_options = makemessages.Command.xgettext_options[:] + [\n "--keyword=%s" % kwd for kwd in xgettext_keywords\n ]\n super().handle(*args, **options)\nSom en bekvämlighet kommer Django med en vy, django.views.i18n.set_language(), som ställer in en användares språkpreferens och omdirigerar till en given URL eller, som standard, tillbaka till föregående sida.
Aktivera denna vy genom att lägga till följande rad i din URLconf:
\npath("i18n/", include("django.conf.urls.i18n")),\n(Observera att detta exempel gör vyn tillgänglig på /i18n/setlang/.)
Vyn förväntas anropas via metoden POST, med en parameter language inställd i begäran. Vyn sparar språkvalet i en cookie som standard heter django_language. (Namnet kan ändras genom inställningen LANGUAGE_COOKIE_NAME.)
Efter att ha ställt in språkvalet letar Django efter en next parameter i POST eller GET data. Om den hittas och Django anser att det är en säker URL (dvs. den pekar inte till en annan värd och använder ett säkert schema), kommer en omdirigering till den URL:en att utföras. Annars kan Django falla tillbaka till att omdirigera användaren till webbadressen från Referer-huvudet eller, om det inte är inställt, till /, beroende på typen av begäran:
Om begäran accepterar HTML-innehåll (baserat på HTTP-rubriken Accept) utförs alltid fallbacken.
Om begäran inte accepterar HTML, kommer fallbacken endast att utföras om parametern next har angetts. I annat fall returneras en statuskod 204 (Inget innehåll).
Här är ett exempel på HTML-mallkod:
\n{% load i18n %}\n\n<form action="{% url 'set_language' %}" method="post">{% csrf_token %}\n <input name="next" type="hidden" value="{{ redirect_to }}">\n <select name="language">\n {% get_current_language as LANGUAGE_CODE %}\n {% get_available_languages as LANGUAGES %}\n {% get_language_info_list for LANGUAGES as languages %}\n {% for language in languages %}\n <option value="{{ language.code }}"{% if language.code == LANGUAGE_CODE %} selected{% endif %}>\n {{ language.name_local }} ({{ language.code }})\n </option>\n {% endfor %}\n </select>\n <input type="submit" value="Go">\n</form>\nI det här exemplet letar Django upp webbadressen till den sida som användaren kommer att omdirigeras till i kontextvariabeln redirect_to.
You may want to set the active language for the current session explicitly.\nPerhaps a user’s language preference is retrieved from another system, for\nexample. You’ve already been introduced to\ndjango.utils.translation.activate(). That applies to the current thread\nonly. To persist the language for the entire session in a cookie, set the\nLANGUAGE_COOKIE_NAME cookie on the response:
from django.conf import settings\nfrom django.http import HttpResponse\nfrom django.utils import translation\n\nuser_language = "fr"\ntranslation.activate(user_language)\nresponse = HttpResponse(...)\nresponse.set_cookie(settings.LANGUAGE_COOKIE_NAME, user_language)\nYou would typically want to use both: django.utils.translation.activate()\nchanges the language for this thread, and setting the cookie makes this\npreference persist in future requests.
Även om Django tillhandahåller en rik uppsättning i18n-verktyg för användning i vyer och mallar, begränsar det inte användningen till Django-specifik kod. Djangos översättningsmekanismer kan användas för att översätta godtyckliga texter till alla språk som stöds av Django (så länge som en lämplig översättningskatalog finns, naturligtvis). Du kan ladda en översättningskatalog, aktivera den och översätta text till valfritt språk, men kom ihåg att växla tillbaka till originalspråket, eftersom aktivering av en översättningskatalog görs per tråd och en sådan ändring kommer att påverka kod som körs i samma tråd.
\nTill exempel:
\nfrom django.utils import translation\n\n\ndef welcome_translated(language):\n cur_language = translation.get_language()\n try:\n translation.activate(language)\n text = translation.gettext("welcome")\n finally:\n translation.activate(cur_language)\n return text\nAnrop av denna funktion med värdet 'de' ger dig "Willkommen", oavsett LANGUAGE_CODE och språk som anges av mellanprogramvaran.
Functions of particular interest are\ndjango.utils.translation.get_language() which returns the language used\nin the current thread, django.utils.translation.activate() which\nactivates a translation catalog for the current thread, and\ndjango.utils.translation.check_for_language()\nwhich checks if the given language is supported by Django.
To help write more concise code, there is also a context manager\ndjango.utils.translation.override() that stores the current language on\nenter and restores it on exit. With it, the above example becomes:
from django.utils import translation\n\n\ndef welcome_translated(language):\n with translation.override(language):\n return translation.gettext("welcome")\nDjangos översättningsmaskineri använder standardmodulen gettext som medföljer Python. Om du känner till gettext kanske du noterar dessa specialiteter i hur Django gör översättning:
Strängdomänen är django eller djangojs. Denna strängdomän används för att skilja mellan olika program som lagrar sina data i ett gemensamt meddelandefilsbibliotek (vanligtvis /usr/share/locale/). Domänen django används för översättningssträngar för Python och mallar och laddas in i de globala översättningskatalogerna. Domänen djangojs används endast för JavaScript-översättningskataloger för att se till att de är så små som möjligt.
Django använder inte enbart xgettext. Det använder Pythonomslag runt xgettext och msgfmt. Detta är mest för bekvämlighetens skull.
När du har förberett dina översättningar - eller om du vill använda de översättningar som följer med Django - måste du aktivera översättning för din app.
\nBakom kulisserna har Django en mycket flexibel modell för att bestämma vilket språk som ska användas - installationsövergripande, för en viss användare eller båda.
\nFör att ställa in en installationsomfattande språkpreferens, ställ in LANGUAGE_CODE. Django använder detta språk som standardöversättning - det sista försöket om ingen bättre matchande översättning hittas genom någon av de metoder som används av locale middleware (se nedan).
Om allt du vill är att köra Django med ditt modersmål behöver du bara ställa in LANGUAGE_CODE och se till att motsvarande message files och deras kompilerade versioner (.mo) finns.
Om du vill låta varje enskild användare ange vilket språk de föredrar måste du också använda LocaleMiddleware. LocaleMiddleware möjliggör språkval baserat på data från begäran. Det anpassar innehållet för varje användare.
För att använda LocaleMiddleware, lägg till 'django.middleware.locale.LocaleMiddleware' till din MIDDLEWARE inställning. Eftersom ordningen på middleware spelar roll, följ dessa riktlinjer:
Se till att det är en av de första middleware som installeras.
Det bör komma efter SessionMiddleware, eftersom LocaleMiddleware använder sessionsdata. Och det bör komma före CommonMiddleware eftersom CommonMiddleware behöver ett aktiverat språk för att kunna lösa den begärda URL:en.
Om du använder CacheMiddleware, lägg till LocaleMiddleware efter det.
Till exempel kan din MIDDLEWARE se ut så här:
MIDDLEWARE = [\n "django.contrib.sessions.middleware.SessionMiddleware",\n "django.middleware.locale.LocaleMiddleware",\n "django.middleware.common.CommonMiddleware",\n]\n(Mer information om middleware finns i middleware documentation.)
\nLocaleMiddleware försöker bestämma användarens språkpreferens genom att följa denna algoritm:
First, it looks for the language prefix in the requested URL. This is\nonly performed when you are using the i18n_patterns function in your\nroot URLconf. See Internationalisering: i URL-mönster for more information\nabout the language prefix and how to internationalize URL patterns.
Om det inte lyckas letar den efter en kaka.
\nNamnet på den cookie som används bestäms av inställningen LANGUAGE_COOKIE_NAME. (Standardnamnet är django_language.)
Om så inte är fallet tittar den på HTTP-huvudet ”Accept-Language”. Denna header skickas av din webbläsare och talar om för servern vilket eller vilka språk du föredrar, i prioritetsordning. Django provar varje språk i rubriken tills den hittar ett med tillgängliga översättningar.
Om så inte är fallet används den globala inställningen LANGUAGE_CODE.
Anteckningar:
\nPå var och en av dessa platser förväntas språkpreferensen vara i standard language format, som en sträng. Till exempel är brasiliansk portugisiska pt-br.
Om ett basspråk är tillgängligt men det angivna underspråket inte är det, använder Django basspråket. Till exempel, om en användare anger de-at (österrikisk tyska) men Django bara har de tillgängligt, använder Django de.
Endast de språk som anges i inställningen LANGUAGES kan väljas. Om du vill begränsa språkvalet till en delmängd av de språk som tillhandahålls (eftersom ditt program inte tillhandahåller alla dessa språk) anger du LANGUAGES till en lista med språk. Till exempel:
LANGUAGES = [\n ("de", _("German")),\n ("en", _("English")),\n]\nI det här exemplet begränsas de språk som är tillgängliga för automatiskt val till tyska och engelska (och alla underspråk, som de-ch eller en-us).
Om du definierar en anpassad LANGUAGES-inställning, som förklaras i föregående punkt, kan du markera språknamnen som översättningssträngar - men använd gettext_lazy() istället för gettext() för att undvika en cirkulär import.
Här är ett exempel på en inställningsfil:
\nfrom django.utils.translation import gettext_lazy as _\n\nLANGUAGES = [\n ("de", _("German")),\n ("en", _("English")),\n]\nNär LocaleMiddleware har bestämt användarens preferens gör den denna preferens tillgänglig som request.LANGUAGE_CODE för varje HttpRequest. Läs gärna detta värde i din view-kod. Här är ett exempel:
from django.http import HttpResponse\n\n\ndef hello_world(request, count):\n if request.LANGUAGE_CODE == "de-at":\n return HttpResponse("You prefer to read Austrian German.")\n else:\n return HttpResponse("You prefer to read another language.")\nObservera att med statisk översättning (utan middleware) finns språket i settings.LANGUAGE_CODE, medan det med dynamisk översättning (middleware) finns i request.LANGUAGE_CODE.
Vid körning bygger Django en enhetlig katalog av bokstavs-översättningar i minnet. För att uppnå detta letar den efter översättningar genom att följa denna algoritm angående ordningen i vilken den undersöker de olika filsökvägarna för att ladda de kompilerade meddelandefilerna (.mo) och företräde för flera översättningar för samma bokstav:
De kataloger som anges i LOCALE_PATHS har högst prioritet, där de som visas först har högre prioritet än de som visas senare.
Then, it looks for and uses if it exists a locale directory in each\nof the installed apps listed in INSTALLED_APPS. The ones\nappearing first have higher precedence than the ones appearing later.
Slutligen används den Django-tillhandahållna basöversättningen i django/conf/locale som en fallback.
I samtliga fall förväntas namnet på den katalog som innehåller översättningen vara namngivet med locale name-notation. T.ex. de, pt_BR, es_AR, etc. Oöversatta strängar för territoriella språkvarianter använder översättningarna av det generiska språket. Till exempel, oöversatta pt_BR strängar använder pt översättningar.
På så sätt kan du skriva program som innehåller sina egna översättningar och du kan åsidosätta basöversättningar i ditt projekt. Eller så kan du bygga ett stort projekt av flera appar och lägga alla översättningar i en stor gemensam meddelandefil som är specifik för det projekt du skapar. Valet är ditt.
\nAlla arkiv för meddelandefiler är uppbyggda på samma sätt. De är följande:
\nAlla sökvägar som anges i LOCALE_PATHS i din inställningsfil söks efter <language>/LC_MESSAGES/django.(po|mo)
$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)
$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)
För att skapa meddelandefiler använder du verktyget django-admin makemessages. Och du använder django-admin compilemessages för att producera de binära .mo-filerna som används av gettext.
Du kan också köra django-admin compilemessages --settings=path.to.settings för att få kompilatorn att bearbeta alla kataloger i din LOCALE_PATHS-inställning.
Django gör det allmänna antagandet att originalsträngarna i ett översättningsbart projekt är skrivna på engelska. Du kan välja ett annat språk, men du måste vara medveten om vissa begränsningar:
\ngettext ger bara två pluralformer för de ursprungliga meddelandena, så du måste också tillhandahålla en översättning för basspråket för att inkludera alla pluralformer om pluralreglerna för basspråket skiljer sig från engelska.
När en engelsk variant är aktiverad och engelska strängar saknas, kommer reservspråket inte att vara projektets LANGUAGE_CODE, utan originalsträngarna. Till exempel kommer en engelsk användare som besöker en webbplats med LANGUAGE_CODE inställt på spanska och originalsträngar skrivna på ryska att se rysk text i stället för spansk.