Konfigurationsinstruktioner¶
Installera Weblate¶
Välj en lämplig installationsmetod utifrån din konfiguration och erfarenhet:
Installera med Docker, rekommenderas för produktionsmiljöer.
Virtualenv-installation, rekommenderas för produktionsmiljöer:
Installera från källor, rekommenderas för utveckling.
Arkitekturöversikt¶
- Webbserver
Hantera inkommande HTTP-förfrågningar, Servering av statiska filer.
- Selleriarbetare
Bakgrundsuppgifter med Celery exekveras här.
Beroende på din arbetsbelastning kan du behöva anpassa antalet arbetare.
Använd dedikerad nod vid horisontell skalning av Weblate.
- WSGI-server
En WSGI-server som levererar webbsidor till användare.
Använd dedikerad nod vid horisontell skalning av Weblate.
- Databas
PostgreSQL-databasserver för lagring av allt innehåll, se Databasinställningar för Weblate.
Använd dedikerad databasnod för webbplatser med hundratals miljoner värdord.
- Datastore
Nyckel/värde-databas såsom Valkey eller Redis-server för cache och uppgiftskö, se Bakgrundsuppgifter med Celery.
Använd dedikerad nod vid horisontell skalning av Weblate.
- Filsystem
Filsystemlagring för lagring av VCS-arkiv och uppladdade användardata. Detta delas av alla processer.
Använd nätverkslagring när du skalar Weblate horisontellt.
- E-postserver
SMTP-server för utgående e-post, se Konfigurera utgående e-post. Den kan tillhandahållas externt.
Råd
Installera med Docker innehåller PostgreSQL och Valkey, vilket underlättar installationen.
Programvarukrav¶
Operativsystem¶
Weblate fungerar på Linux, FreeBSD och macOS. Andra Unix-liknande system kommer troligen också att fungera.
Weblate stöds inte på Windows. Men det kan fortfarande fungera och patchar tas gärna emot.
Se även
Arkitekturöversikt beskriver Weblates övergripande arkitektur och nödvändiga tjänster.
Python-beroenden¶
Weblate är skrivet i Python och stöder Python 3.12 eller nyare. Du kan installera beroenden med pip eller från dina distributionspaket. En fullständig lista finns i requirements.txt.
De mest anmärkningsvärda beroendena:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
Valfri beroendespecifikator |
Python-paket |
Weblate-funktion |
|---|---|---|
|
||
|
||
|
||
|
Google Cloud Translation Advanced med stöd för ordlista |
|
|
||
|
||
|
||
|
PostgreSQL, se Databasinställningar för Weblate |
|
|
||
|
||
|
Integrera SAML 2 IDP i Weblate |
|
|
Needed for Uppdatera POT-fil (Sphinx) |
|
|
Hostad Weblate-integration |
|
|
wsgi-server för Weblate |
|
|
När du installerar med pip kan du direkt ange önskade funktioner vid installationen:
uv pip install "weblate[Postgres,Amazon,SAML]"
Eller så kan du installera Weblate med alla valfria funktioner:
uv pip install "weblate[all]"
Eller så kan du installera Weblate utan några valfria funktioner:
uv pip install weblate
Felsökning av pip-installation¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.Det installerade paketet
PyGobjectkan inte hitta ett matchande GObject Introspection-bibliotek -gobject-introspection-2.0.Äldre versioner stöds inte längre av Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Detta beror på att binärpaket som distribueras via PyPI är inkompatibla med distributionen. För att lösa detta måste du bygga om paketet på ditt system:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Detta är ett känt problem med xmlsec-paketet, se https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchPaketen
lxmlochxmlsecmåste byggas mot enlibxml2. Du bör bygga dem lokalt för att undvika detta problem:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Övriga systemkrav¶
Följande beroenden måste installeras på systemet:
Git- Pango, Cairo och relaterade huvudfiler samt GObject-introspektionsdata
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, se Pango och Kairo
git-review(valfritt för Gerrit-stöd)git-svn(valfritt för Subversion-stöd)tesseract(krävs endast om tesserocr binära hjul inte är tillgängliga för ditt system)
Beroenden vid byggtiden¶
För att bygga vissa av Python-beroenden kan du behöva installera deras beroenden. Detta beror på hur du installerar dem, så se dokumentationen för de enskilda paketen. Du behöver inte dessa om du använder förkompilerade Wheels när du installerar med pip eller när du använder distributionspaket.
Pango och Kairo¶
Weblate använder Pango och Cairo för att rendera bitmap-widgets (se Bygga upp översättningsgemenskapen) och rendera kontroller (se Hantera teckensnitt). För att korrekt installera Python-bindningar för dessa måste du först installera systembibliotek – du behöver både Cairo och Pango, som i sin tur behöver GLib. Alla dessa bör installeras med utvecklingsfiler och GObject-introspektionsdata.
Hårdvarukrav¶
Weblate bör fungera utan problem på all modern hårdvara. Nedan anges den minimikonfiguration som krävs för att köra Weblate på en enda värd (Weblate, databas och webbserver):
3 GB RAM-minne
2 CPU-kärnor
1 GB lagringsutrymme
Observera
De faktiska kraven för din installation av Weblate varierar kraftigt beroende på storleken på de översättningar som hanteras i den.
Använt minne¶
Ju mer minne desto bättre – det används för caching på alla nivåer (filsystem, databas och Weblate). För hundratals översättningskomponenter rekommenderas minst 4 GB RAM-minne.
Råd
För system med mindre minne än rekommenderat rekommenderas Enkelprocess-konfiguration av Celery.
CPU-användning¶
Många samtidiga användare ökar behovet av CPU-kärnor.
Lagringsutnyttjande¶
Den typiska databaslagringsanvändningen är cirka 300 MB per 1 miljon lagrade ord.
Lagringsutrymmet som behövs för klonade arkiv varierar, men Weblate försöker hålla storleken minimal genom att göra ytliga kloner.
Noder¶
För små och medelstora webbplatser (miljoner värdord) kan alla Weblate-komponenter (se Arkitekturöversikt) köras på en enda nod.
När du växer till hundratals miljoner lagrade ord rekommenderas det att ha en dedikerad nod för databasen (se Databasinställningar för Weblate).
Verifying release artifacts¶
Release archives can be verified using the signatures, attestations, and SBOMs published with GitHub release assets. See Verifying release artifacts.
Filssystemets behörigheter¶
Weblate-processen måste kunna läsa och skriva till den katalog där den lagrar data - DATA_DIR. Alla filer i denna katalog ska ägas av och vara skrivbara för den användare som kör alla Weblate-processer (vanligtvis WSGI och Celery, se Körande server och Bakgrundsuppgifter med Celery).
Standardkonfigurationen placerar dem i samma träd som Weblate-källorna, men du kanske föredrar att flytta dem till en bättre plats, till exempel: /var/lib/weblate.
Weblate försöker skapa dessa kataloger automatiskt, men det misslyckas om det inte har behörighet att göra det.
The configured CACHE_DIR also has to be writable by the Weblate
process and has to allow executing generated helper files. Do not mount
CACHE_DIR with the noexec option.
Du bör också vara försiktig när du kör Ledningskommandon, eftersom det bör köras under samma användare som Weblate själv körs under, annars kan behörigheterna för vissa filer bli felaktiga.
I Docker-containern måste alla filer i volymen /app/data ägas av användaren weblate i containern (UID 1000).
Se även
Databasinställningar för Weblate¶
Det rekommenderas att köra Weblate med en PostgreSQL-databasserver.
PostgreSQL 13 och högre stöds. PostgreSQL 15 eller nyare rekommenderas.
Databasanslutningar¶
I standardkonfigurationen upprätthåller varje Weblate-process en permanent anslutning till databasen. Permanenta anslutningar förbättrar Weblates responsivitet, men kan kräva mer resurser för databasservern. Se CONN_MAX_AGE och Persistent connections för mer information.
Weblate behöver minst följande antal anslutningar:
\((4 \times \mathit{nCPUs}) + 2\) för Celery-processer
\(\mathit{nCPUs} + 1\) för WSGI-arbetare
Detta gäller standardinställningarna för Docker-containrar och exempelkonfigurationerna i denna dokumentation, men siffrorna kommer att ändras när du anpassar antalet WSGI-arbetare eller justerar parallelliteten i Celery.
Den faktiska gränsen för antalet databasanslutningar måste vara högre för att ta hänsyn till följande situationer:
Ledningskommandon behöver också deras anslutning.
Om processprocessen avbryts (till exempel av OOM-killer) kan den blockera den befintliga anslutningen tills tidsgränsen löper ut.
PostgreSQL¶
PostgreSQL är vanligtvis det bästa valet för Django-baserade webbplatser. Det är referensdatabasen som används för att implementera Djangos databaslager.
Observera
Weblate använder trigram-tillägg som i vissa fall måste installeras separat. Leta efter postgresql-contrib eller ett paket med liknande namn.
Se även
Skapa en databas i PostgreSQL¶
Det är vanligtvis en bra idé att köra Weblate i en separat databas och med ett separat användarkonto:
# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"
# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate
# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate
Råd
Om du inte vill göra Weblate-användaren till superanvändare i PostgreSQL kan du utelämna det. I så fall måste du utföra vissa migreringssteg manuellt som superanvändare i PostgreSQL i det schema som Weblate kommer att använda:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Konfigurera Weblate för att använda PostgreSQL¶
settings.py-snippet för PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Configures name of the PostgreSQL role to alter during the database migration
# "ALTER_ROLE": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "database.example.com",
# Set to empty string for default
"PORT": "",
# Persistent connections
"CONN_MAX_AGE": None,
"CONN_HEALTH_CHECKS": True,
}
}
Databasmigreringen utför ALTER ROLE på den databasroll som används av Weblate. I de flesta fall matchar rollens namn användarnamnet. I mer komplexa installationer skiljer sig rollnamnet från användarnamnet, och du kommer att få ett felmeddelande om en icke-existerande roll under databasmigreringen (psycopg2.errors.UndefinedObject: rollen "weblate@hostname" finns inte). Detta är känt för att inträffa med Azure Database for PostgreSQL, men det är inte begränsat till denna miljö. Ställ in ALTER_ROLE för att ändra namnet på den roll som Weblate ska ändra under databasmigreringen.
Se även
Andra konfigurationer¶
Konfigurera utgående e-post¶
Weblate skickar ut e-postmeddelanden vid olika tillfällen – för aktivering av konton och olika meddelanden som konfigurerats av användarna. För detta behöver det tillgång till en SMTP-server.
E-postservern konfigureras med hjälp av följande inställningar: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER och EMAIL_PORT. Deras namn är ganska självförklarande, men du kan hitta mer information i Djangos dokumentation.
Råd
Om du får ett felmeddelande om att autentiseringen inte stöds (till exempel SMTP AUTH-tillägg stöds inte av servern), beror det troligen på att du använder en osäker anslutning och servern vägrar att autentisera på detta sätt. Försök att aktivera EMAIL_USE_TLS i sådana fall.
Körning bakom omvänd proxy¶
Flera funktioner i Weblate är beroende av att korrekta HTTP-rubriker skickas till Weblate. När du använder omvänd proxy, se till att nödvändig information skickas korrekt.
För att felsöka denna konfiguration kan du titta på HTTP-miljö i Prestandarapport.
- Klientens IP-adress
Detta behövs för Hastighetsbegränsande eller Granskningslogg.
Weblate analyserar IP-adressen från
REMOTE_ADDR, som ställs in av WSGI-hanteraren. Denna kan vara tom (vid användning av socket för WSGI) eller innehålla en omvänd proxyadress, så Weblate behöver en extra HTTP-header med en klient-IP-adress.Att aktivera
IP_BEHIND_REVERSE_PROXYbör vara tillräckligt för de vanligaste inställningarna, men du kan behöva justeraIP_PROXY_HEADERochIP_PROXY_OFFSETockså (användWEBLATE_IP_PROXY_HEADERochWEBLATE_IP_PROXY_OFFSETi Docker-containern).Råd
Denna konfiguration kan inte aktiveras som standard, eftersom det skulle möjliggöra IP-adressförfalskning på installationer som inte har en korrekt konfigurerad omvänd proxy.
- Serverns värdnamn
Host-rubriken ska matcha det som är konfigurerat som
SITE_DOMAIN. Ytterligare konfiguration kan behövas i din omvända proxy (använd till exempelProxyPreserveHost Onför Apache ellerproxy_set_header Host $host;med nginx).Råd
Fel vid CSRF-verifiering orsakas ofta av en diskrepans mellan Host-rubriken och konfigurerade
SITE_DOMAIN.- Klientprotokoll
Om rätt protokoll inte godkänns kan Weblate hamna i en omdirigeringsloop när det försöker uppgradera klienten till HTTPS. Se till att det exponeras korrekt av den omvända proxyn som X-Forwarded-Proto.
Denna rubrik måste sedan konfigureras i
SECURE_PROXY_SSL_HEADER(settings.py) ellerWEBLATE_SECURE_PROXY_SSL_HEADER(Docker-miljö).Viktigt
The header value is case-sensitive in the configuration, so
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsandWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSare not interchangeable.Råd
Om du får felmeddelandet ”För många omdirigeringar” från webbläsaren beror det troligen på att det faktiska protokollet (HTTPS) inte stämmer överens med det som Weblate observerar.
Förändrat i version 5.13: Protokollproxyhuvudena hanteras automatiskt av gunicorn i standardkonfigurationen, men andra WSGI-servrar har en säkrare konfiguration och kräver en explicit inställning av detta.
Sedan Weblate 5.13 använder Docker-containern granian och kräver nu en explicit konfiguration av
WEBLATE_SECURE_PROXY_SSL_HEADER.
Se även
HTTP-proxy¶
Weblate utför VCS-kommandon och dessa accepterar proxykonfiguration från miljön. Det rekommenderade tillvägagångssättet är att definiera proxyinställningar i settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Se även
Justera konfigurationen¶
Se även
Kopiera weblate/settings_example.py till weblate/settings.py och anpassa den efter din konfiguration. Du kommer troligen att vilja justera följande alternativ:
ADMINS
Lista över webbplatsadministratörer som ska få meddelanden när något går fel, till exempel meddelanden om misslyckade sammanslagningar eller Django-fel.
Kontaktformuläret skickar även e-post om dessa, såvida inte
ADMINS_CONTACTär konfigurerat.
ALLOWED_HOSTS
Du måste ställa in detta för att lista de värdar som din webbplats ska betjäna. Till exempel:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativt kan du inkludera jokertecken:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Konfigurera hur dina sessioner ska lagras. Om du behåller standarddatabasmotorn bör du schemalägga weblate clearsessions för att ta bort gamla sessionsdata från databasen.
Om du använder Valkey eller Redis som cache (se Konfigurera cache) rekommenderas det att du använder det även för sessioner:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
DATABASES
Anslutning till databasserver, se Djangos dokumentation för mer information.
DEBUG
Inaktivera detta för alla produktionsservrar. När felsökningsläget är aktiverat visar Django backtraces för användarna vid fel. När du inaktiverar det skickas felmeddelanden via e-post till
ADMINS(se ovan).Felsökningsläget gör också Weblate långsammare, eftersom Django lagrar mycket mer information internt i detta fall.
Se även
DEFAULT_FROM_EMAIL
E-postadress för utgående e-post, till exempel registreringsmeddelanden.
Se även
SECRET_KEY
Nyckel som används av Django för att signera viss information i cookies. Se Djangos hemliga nyckel för mer information.
Se även
SERVER_EMAIL
E-postadress som används som avsändaradress för att skicka e-postmeddelanden till administratören, till exempel meddelanden om misslyckade sammanslagningar.
Se även
Fylla databasen¶
När konfigurationen är klar kan du köra migrate för att skapa databasstrukturen. Nu bör du kunna skapa översättningsprojekt med hjälp av administratörsgränssnittet.
När du är klar bör du också kontrollera Prestandarapporten i administratörsgränssnittet, som ger dig tips om potentiella icke-optimala konfigurationer på din webbplats.
Produktionsuppsättning¶
För en produktionsmiljö bör du göra de justeringar som beskrivs i följande avsnitt. De mest kritiska inställningarna utlöser en varning, som indikeras med ett utropstecken i den övre fältet om du är inloggad som superanvändare:
Det rekommenderas också att kontrollera de kontroller som utlöses av Django (även om du kanske inte behöver åtgärda alla):
weblate check --deploy
Du kan också granska samma checklista på Prestandarapport i Hanteringsgränssnitt.
Se även
Inaktivera felsökningsläge¶
Inaktivera Djangos felsökningsläge (DEBUG) genom att:
DEBUG = False
När felsökningsläget är aktiverat lagrar Django alla utförda frågor och visar användarna backtraces av fel, vilket inte är önskvärt i en produktionsmiljö.
Se även
Konfigurera administratörer korrekt¶
Ange rätt administratörsadresser i inställningen ADMINS för att definiera vem som ska ta emot e-postmeddelanden om något går fel på servern, till exempel:
ADMINS = ("Your Name <your_email@example.com>",)
Se även
Ställ in rätt webbplatsdomän¶
Justera webbplatsens namn och domän i administratörsgränssnittet, annars kommer länkar i RSS eller registreringsmejl inte att fungera. Detta konfigureras med hjälp av SITE_DOMAIN som ska innehålla webbplatsens domännamn.
Förändrat i version 4.2: Före version 4.2 användes istället Djangos webbplatsramverk, se The “sites” framework.
Konfigurera HTTPS korrekt¶
Det rekommenderas starkt att köra Weblate med det krypterade HTTPS-protokollet. Efter att ha aktiverat det bör du ställa in ENABLE_HTTPS i inställningarna:
ENABLE_HTTPS = True
Råd
Du kanske också vill konfigurera HSTS. Se SSL/HTTPS för mer information.
Ställ in SECURE_HSTS_SECONDS korrekt¶
Om din webbplats används via SSL måste du överväga att ange ett värde för SECURE_HSTS_SECONDS i settings.py för att aktivera HTTP Strict Transport Security. Som standard är det inställt på 0, som visas nedan.
SECURE_HSTS_SECONDS = 0
Om den är inställd på ett heltal som inte är noll, ställer django.middleware.security.SecurityMiddleware in HTTP Strict Transport Security-rubriken på alla svar som inte redan har den.
Varning
Om du ställer in detta felaktigt kan det orsaka irreversibla skador (under en viss tid) på din webbplats. Läs först dokumentationen HTTP Strict Transport Security.
Använd en kraftfull databasmotor¶
Använd PostgreSQL för en produktionsmiljö, se Databasinställningar för Weblate för mer information.
Använd en närliggande plats för att köra databasservern, annars kan nätverksprestandan eller tillförlitligheten förstöra din upplevelse av Weblate.
Kontrollera databasserverns prestanda eller justera dess konfiguration, till exempel med hjälp av PGTune.
Konfigurera cache¶
Om möjligt, använd Valkey eller Redis från Django genom att justera konfigurationsvariabeln CACHES, till exempel:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://127.0.0.1:6379/0",
# If redis is running on same host as Weblate, you might
# want to use unix sockets instead:
# 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
}
}
Råd
Om du ändrar inställningarna för cachen kan du behöva justera dem även för Celery, se Bakgrundsuppgifter med Celery.
Avatar-cachning¶
Förutom caching av Django utför Weblate även caching av avatarer. Det rekommenderas att använda en separat, filbaserad cache för detta ändamål:
CACHES = {
"default": {
# Default caching backend setup, see above
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "unix:///var/run/redis/redis.sock?db=0",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
},
"avatar": {
"BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
"LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
"TIMEOUT": 604800,
"OPTIONS": {
"MAX_ENTRIES": 1000,
},
},
}
Konfigurera e-postutskick¶
Weblate behöver skicka e-postmeddelanden vid flera tillfällen, och dessa e-postmeddelanden ska ha en korrekt avsändaradress. Konfigurera SERVER_EMAIL och DEFAULT_FROM_EMAIL så att de passar din miljö, till exempel:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Observera
För att inaktivera e-postutskick via Weblate, ställ in EMAIL_BACKEND till django.core.mail.backends.dummy.EmailBackend.
Detta kommer att inaktivera alla e-postleveranser, inklusive registrerings- eller lösenordsåterställningsmeddelanden.
Tillåtna värdar inställning¶
Django kräver att ALLOWED_HOSTS innehåller en lista över domännamn som din webbplats får betjäna. Om du lämnar den tom kommer alla förfrågningar att blockeras.
Om detta inte är konfigurerat för att matcha din HTTP-server kommer du att få felmeddelanden som Ogiltig HTTP_HOST-rubrik: '1.1.1.1'. Du kan behöva lägga till '1.1.1.1' till ALLOWED_HOSTS.
Råd
På Docker-containern är detta tillgängligt som WEBLATE_ALLOWED_HOSTS.
Djangos hemliga nyckel¶
Inställningen SECRET_KEY används av Django för att signera cookies, och du bör verkligen generera ditt eget värde istället för att använda det från exempelkonfigurationen.
Du kan generera en ny nyckel med hjälp av weblate-generate-secret-key som medföljer Weblate.
Se även
Kör underhållsuppgifter¶
För optimal prestanda är det en bra idé att köra vissa underhållsuppgifter i bakgrunden. Detta görs automatiskt av Bakgrundsuppgifter med Celery och omfattar följande uppgifter:
Konfigurationshälsokontroll (varje timme).
Bekräfta väntande ändringar (varje timme), se Lata åtaganden och
commit_pending.Uppdatering av komponentvarningar (dagligen).
Uppdatera fjärrgrenar (varje natt), se
AUTO_UPDATE.Säkerhetskopiering av översättningsminne till JSON (dagligen), se
dump_memory.Fulltext- och databasunderhållsuppgifter (dagliga och veckovisa uppgifter), se
cleanuptrans.
Systemets lokaliseringar och kodning¶
Systemets lokaliseringar bör konfigureras till UTF-8-kompatibla. På de flesta Linux-distributioner är detta standardinställningen. Om så inte är fallet på ditt system, ändra lokaliseringarna till UTF-8-varianten.
Till exempel genom att redigera /etc/default/locale och ställa in LANG="C.UTF-8" där.
I vissa fall har enskilda tjänster separata inställningar för lokalisering. Detta varierar mellan distributioner och webbservrar, så kontrollera dokumentationen för dina webbserverpaket för mer information.
Apache på Ubuntu använder /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache på CentOS använder /etc/sysconfig/httpd (eller /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Komprimering av klientresurser¶
Weblate levereras med en rad JavaScript- och CSS-filer. Av prestandaskäl är det bra att komprimera dem innan de skickas till en klient. I standardkonfigurationen görs detta direkt med en liten extra kostnad. Vid stora installationer rekommenderas det att aktivera offlinekomprimeringsläget. Detta måste göras i konfigurationen och komprimeringen måste aktiveras vid varje uppgradering av Weblate.
Konfigurationsomkopplaren är enkel genom att aktivera django.conf.settings.COMPRESS_OFFLINE och konfigurera django.conf.settings.COMPRESS_OFFLINE_CONTEXT (det senare ingår redan i exempelkonfigurationen):
COMPRESS_OFFLINE = True
Vid varje distribution måste du komprimera filerna så att de matchar den aktuella versionen:
weblate compress
Råd
Den officiella Docker-bilden har redan denna funktion aktiverad.
Körande server¶
Råd
Om du inte har erfarenhet av tjänsterna som beskrivs nedan kan du prova Installera med Docker.
Du behöver flera tjänster för att köra Weblate. Den rekommenderade konfigurationen består av:
Databasserver (se Databasinställningar för Weblate)
Cache-server (se Konfigurera cache)
Frontend-webbserver för statiska filer och SSL-avslutning (se Servering av statiska filer)
WSGI-server för dynamiskt innehåll (se Exempelkonfiguration för NGINX och uWSGI)
Celery för att utföra bakgrundsuppgifter (se Bakgrundsuppgifter med Celery)
Observera
Det finns vissa beroenden mellan tjänsterna, till exempel bör cache och databas vara igång när Celery- eller uwsgi-processer startas.
I de flesta fall kommer du att köra alla tjänster på en enda (virtuell) server, men om din installation är tungt belastad kan du dela upp tjänsterna. Den enda begränsningen för detta är att Celery- och Wsgi-servrarna behöver åtkomst till DATA_DIR.
Observera
WSGI-processen måste köras under samma användare som Celery-processen, annars kommer filer i DATA_DIR att lagras med blandad äganderätt, vilket leder till problem vid körning.
Se även Filssystemets behörigheter och Bakgrundsuppgifter med Celery.
Körande webbserver¶
Att köra Weblate skiljer sig inte från att köra något annat Django-baserat program. Django körs vanligtvis som WSGI eller fcgi (se exempel för olika webbservrar nedan).
Observera
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
För teständamål kan du använda den inbyggda webbservern i Django:
weblate runserver
Varning
ANVÄND INTE DENNA SERVER I EN PRODUKTIONSMILJÖ. Den har inte genomgått säkerhetsgranskningar eller prestandatester. Se även Django-dokumentationen om runserver.
Råd
Djangos inbyggda server hanterar endast statiska filer med DEBUG aktiverat, eftersom den endast är avsedd för utveckling. För produktionsanvändning, se WSGI-inställningar:
Servering av statiska filer¶
Förändrat i version 5.15.2: /media/ används inte längre för att visa skärmdumpar.
Django måste samla sina statiska filer i en enda katalog. För att göra detta, kör weblate collectstatic --noinput. Detta kopierar de statiska filerna till en katalog som anges av inställningen STATIC_ROOT (standard är en katalog med namnet static i CACHE_DIR).
Det rekommenderas att servera statiska filer direkt från din webbserver. Du bör använda detta för följande sökvägar:
/static/Serverar statiska filer för Weblate och administratörsgränssnittet (från definierat av
STATIC_ROOT)./favicon.icoBör skrivas om för att skriva om en regel för att betjäna
/static/favicon.ico.
Se även
Innehållssäkerhetspolicy¶
Standardkonfigurationen för Weblate aktiverar mellanprogrammet weblate.middleware.SecurityMiddleware, som ställer in säkerhetsrelaterade HTTP-rubriker som Content-Security-Policy eller X-XSS-Protection. Dessa är som standard inställda för att fungera med Weblate och dess konfiguration, men kan behöva anpassas för din miljö.
Exempel på konfiguration för NGINX och Granian¶
Följande konfiguration kör Weblate med Granian NGINX-webbserver:
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:8888;
proxy_read_timeout 3600;
}
}
Exempel på konfiguration för NGINX och Gunicorn¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Exempelkonfiguration för NGINX och uWSGI¶
To run production webserver, use the WSGI wrapper installed with Weblate (when
using a Python environment it is installed as
~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Don’t
forget to set the Python search path to your Python environment as well (for
example using virtualenv = /home/user/weblate-env in uWSGI).
Följande konfiguration kör Weblate som uWSGI under NGINX-webbservern.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# Path to the Python environment
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Se även
Exempel på konfiguration för Apache¶
Det rekommenderas att använda prefork MPM när du använder WSGI med Weblate.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Observera
Weblate kräver Python 3, så se till att du kör Python 3-varianten av modwsgi. Vanligtvis finns den tillgänglig som ett separat paket, till exempel libapache2-mod-wsgi-py3.
Använd motsvarande Python-version för att installera Weblate.
Exempelkonfiguration för Apache och Gunicorn¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Exempel på konfiguration för att starta Granian¶
Weblate har wsgi som valfri beroende (se Python-beroenden) som installerar allt du behöver för att köra Granian. När du installerar Weblate kan du ange det som:
uv pip install Weblate[all,wsgi]
När du har installerat Granian kan du köra det. Detta görs vanligtvis på systemnivå. Följande exempel visar hur man startar via systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Exempelkonfiguration för att starta Gunicorn¶
Gunicorn måste installeras separat:
uv pip install gunicorn
När du har installerat Gunicorn kan du köra det. Detta görs vanligtvis på systemnivå. Följande exempel visar hur man startar via systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Se även
Kör Weblate under sökvägen¶
Det rekommenderas att använda prefork MPM när du använder WSGI med Weblate.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Dessutom måste du justera weblate/settings.py:
URL_PREFIX = "/weblate"
Bakgrundsuppgifter med Celery¶
Weblate använder Celery för att utföra regelbundna uppgifter och bakgrundsuppgifter. Du ska köra en Celery-tjänst som utför dessa uppgifter. Den ansvarar till exempel för följande operationer (listan är inte fullständig):
Ta emot webhooks från externa tjänster (se Aviseringskopplingar).
Utföra regelbundna underhållsuppgifter såsom säkerhetskopiering, rensning, dagliga tillägg eller uppdateringar (se Säkerhetskopiera och flytta Weblate,
BACKGROUND_TASKS, Tillägg).Skicka sammanfattande meddelanden.
Avlasta dyra operationer från WSGI-processen.
Bekräfta väntande ändringar (se Lata åtaganden).
En typisk konfiguration med Valkey eller Redis som backend ser ut så här:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
Observera
Celery-processen måste köras under samma användare som WSGI-processen, annars kommer filer i DATA_DIR att lagras med blandad ägarskap, vilket leder till problem vid körning.
Se även Filssystemets behörigheter och Körande server.
Utföra Celery-uppgifter i WSGI med eager-läge¶
Observera
Detta kommer att ha en allvarlig inverkan på webbgränssnittets prestanda och kommer att störa funktioner som är beroende av regelbundna utlösare (till exempel att bekräfta väntande ändringar, sammanfattande aviseringar eller säkerhetskopieringar).
För utveckling kan du använda ivrig konfiguration, som bearbetar alla uppgifter på plats:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Kör Celery som systemtjänst¶
Most likely you will want to run Celery as a daemon and that is covered by
Daemonization. For the most common Linux setup using
systemd, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
Systemd-enhet som ska placeras som /etc/systemd/system/celery-weblate.service:
[Unit]
Description=Celery Service (Weblate)
After=network.target
[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
--pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
-A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
--logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
[Install]
WantedBy=multi-user.target
Miljökonfiguration som ska placeras som /etc/default/celery-weblate:
# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"
# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"
# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"
# Extra command-line arguments to the worker. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
Ytterligare konfiguration för att rotera Celery-loggar med logrotate som ska placeras som /etc/logrotate.d/celery:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Periodiska uppgifter med Celery beat¶
Weblate har en inbyggd funktion för schemalagda uppgifter. Uppgiftsschemat lagras i databasen och uppgifterna utförs av Celery beat-daemon.
Råd
Du kan definiera ytterligare uppgifter i settings.py, se till exempel Lata åtaganden.
Övervakning av Celery-status¶
Du kan se den aktuella längden på Celery-uppgiftsköerna i Hanteringsgränssnitt eller använda celery_queues på kommandoraden. Om kön blir för lång får du också ett konfigurationsfel i admin-gränssnittet.
Varning
Celery-fel loggas som standard endast i Celery-loggen och är inte synliga för användaren. Om du vill ha en översikt över sådana fel rekommenderas det att konfigurera Insamling av felrapporter och övervakning av prestanda.
Enkelprocess-konfiguration av Celery¶
Om du har mycket begränsat minne kan du minska antalet Weblate-processer. Alla Celery-uppgifter kan utföras i en enda process med hjälp av:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
En installation som använder Docker kan konfigureras för att använda en enkelprocess-Celery-konfiguration genom att ställa in CELERY_SINGLE_PROCESS.
Varning
Detta kommer att ha en märkbar inverkan på Weblates prestanda.
Övervakning av Weblate¶
Weblate tillhandahåller URL:en /healthz/ som kan användas för enkla hälsokontroller, till exempel med Kubernetes. Docker-containern har en inbyggd hälsokontroll som använder denna URL.
För att övervaka mätvärden för Weblate kan du använda API-ändpunkten GET /api/metrics/.
Insamling av felrapporter och övervakning av prestanda¶
Weblate kan, precis som all annan programvara, drabbas av fel. För att samla in användbar information om fel rekommenderar vi att du använder tjänster från tredje part för att samla in sådan information. Detta är särskilt användbart vid fel i Celery-uppgifter, som annars endast skulle rapportera felet till loggarna utan att du får någon avisering om det. Weblate har stöd för följande tjänster:
E-post¶
The default Weblate configuration instruments Django to send e-mails upon
server errors via django.utils.log.AdminEmailHandler. This
is the least effort setup, but you should consider other options for privacy
reasons, as the error e-mails might include sensitive data. You can read more on
that in Security implications.
To disable this behavior, remove mail_admins from the
LOGGING in Weblate settings, or disable
WEBLATE_ADMIN_NOTIFY_ERROR in the Docker environment.
Sentry¶
Weblate har inbyggt stöd för Sentry. För att använda det räcker det att ställa in SENTRY_DSN i settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry kan också användas för att övervaka Weblates prestanda genom att samla in spår och profiler för en definierad procentandel av operationerna. Detta kan konfigureras med hjälp av SENTRY_TRACES_SAMPLE_RATE och SENTRY_PROFILES_SAMPLE_RATE.
Google Cloud Error Reporting¶
Weblate can report handled server errors to Google Cloud Error Reporting.
Install Weblate with the google-errors extra and configure
GOOGLE_CLOUD_ERROR_REPORTING in settings.py:
GOOGLE_CLOUD_ERROR_REPORTING = {
"project": "your-google-cloud-project",
}
Weblate automatically reports errors under the weblate service and uses the
current Weblate version or Git revision as the reported version. These values
can be overridden by setting service or version in
GOOGLE_CLOUD_ERROR_REPORTING.
OpenTelemetry¶
Weblate can export backend traces using OpenTelemetry. It uses OTLP over HTTP and can send traces to an OpenTelemetry Collector or a compatible vendor endpoint.
OPENTELEMETRY_ENABLED = True
OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT = "https://collector.example.com/v1/traces"
OPENTELEMETRY_TRACES_SAMPLE_RATE = 0.1
The integration traces Django requests, Celery tasks, Redis, outgoing HTTP
requests, database calls, and Weblate-specific spans. Configure it using
OPENTELEMETRY_ENABLED,
OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT, and
OPENTELEMETRY_TRACES_SAMPLE_RATE.
Rollbar¶
Weblate har inbyggt stöd för Rollbar. För att använda det räcker det att följa instruktionerna för Rollbar notifier för Python.
Kort sagt måste du justera settings.py:
# Add rollbar as last middleware:
MIDDLEWARE = [
# … other middleware classes …
"rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]
# Configure client access
ROLLBAR = {
"access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Allt annat integreras automatiskt, och du kommer nu att samla in både server- och klientsidefel.
Observera
Felregistrering omfattar även undantag som hanterats på ett korrekt sätt, men som kan tyda på ett problem – till exempel misslyckad analys av en uppladdad fil.
Graylog logghantering¶
Added in version 5.9.
Weblate kan konfigureras för att logga med hjälp av GELF TCP-protokollet. Detta utvecklades för Graylog-integration, men kan användas med alla kompatibla loggningsplattformar.
Konfigurationsmallarna finns i Exempel på konfiguration. För Docker kan detta konfigureras med WEBLATE_LOG_GELF_HOST.
Migrera Weblate till en annan server¶
Att migrera Weblate till en annan server bör vara ganska enkelt, men det lagrar data på flera platser som du bör migrera noggrant. Det bästa sättet är att stoppa Weblate under migreringen.
Migrering av databas¶
The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. pg_dump). Alternatively you can use replication if your database supports it.
Se även
Migrering mellan databaser beskrivs i Migrera från andra databaser till PostgreSQL.
Migrera VCS-arkiv¶
VCS-arkiven som lagras under DATA_DIR måste också migreras. Du kan helt enkelt kopiera dem eller använda rsync för att göra migreringen mer effektivt.
Övriga anmärkningar¶
Glöm inte att flytta andra tjänster som Weblate kan ha använt, såsom Valkey, Redis, Cron-jobb eller anpassade autentiseringsbackends.