Installera med Docker¶

Med dockeriserad Weblate-distribution kan du få din personliga Weblate-instans igång på några sekunder. Alla Weblates beroenden ingår redan. PostgreSQL är inställt som standarddatabas och Valkey som caching-backend.

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).

Installation¶

Råd

Följande exempel förutsätter att du har en fungerande Docker-miljö med docker-compose-plugin installerat. Se Docker-dokumentationen för instruktioner.

Detta skapar en Weblate-distributionsserver via HTTP, så du bör placera den bakom en HTTPS-termineringsproxy. Du kan också distribuera med en HTTPS-proxy, se Automatiska SSL-certifikat med Let’s Encrypt. För större installationer, se Horisontell skalning.

Klonera weblate-docker-repo:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

Skapa en docker-compose.override.yml-fil med dina inställningar. Se Docker-miljövariabler för en fullständig lista över miljövariabler.

services:
  weblate:
    image: weblate/weblate:latest
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SERVER_EMAIL: weblate@example.com
      WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for the admin user
      WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
    ports:
    - 80:8080

Observera

Om WEBLATE_ADMIN_PASSWORD inte är inställt skapas administratörsanvändaren med ett slumpmässigt lösenord som visas vid första start.

I det angivna exemplet lyssnar Weblate på port 80. Ändra portmappningen i filen docker-compose.override.yml för att ändra den.

Starta Weblate-containrar:
```
docker compose up
```

Njut av din Weblate-distribution, den är tillgänglig på port 80 i weblate-containern.

Se även

Använda administrationskommandon

Välja Docker-bildregister¶

Weblate-containrar publiceras i följande register:

Docker Hub, se https://hub.docker.com/r/weblate/weblate
GitHub Packages-registret, se https://github.com/WeblateOrg/docker/pkgs/container/weblate

Observera

Alla exempel hämtar för närvarande bilder från Docker Hub. Justera konfigurationen efter behov för att använda ett annat register.

Välja Docker-bildtagg¶

Välj en tagg som passar din miljö och dina förväntningar:

Taggnamn	Beskrivning	Användningsfall
`latest`	Weblate stabil version, motsvarar senaste taggade versionen	Rullande uppdateringar i en produktionsmiljö
`<MAJOR>`	Weblate stabil utgåva	Rullande uppdateringar inom en huvudversion i en produktionsmiljö
`<MAJOR>.<MINOR>`	Weblate stabil utgåva	Rullande uppdateringar inom en mindre version i en produktionsmiljö
`<VERSION>.<PATCH>`	Weblate stabil utgåva	Väl definierad distribution i en produktionsmiljö
`edge`	Weblate stabil release med utvecklingsändringar i Docker-containern (till exempel uppdaterade beroenden)	Rullande uppdateringar i en stagingmiljö
`edge-<DATE>-<SHA>`	Weblate stabil release med utvecklingsändringar i Docker-containern (till exempel uppdaterade beroenden)	Väl definierad distribution i en stagingmiljö
`bleeding`	Utvecklingsversion Weblate från Git	Rullande uppdateringar för att testa kommande Weblate-funktioner
`bleeding-<DATE>-<SHA>`	Utvecklingsversion Weblate från Git	Väl definierad distribution för att testa kommande Weblate-funktioner

Varje bild testas av vår CI innan den publiceras, så även den ”blödande” versionen bör vara ganska säker att använda.

En fullständig lista över publicerade taggar finns på GitHub Packages

Docker-container med HTTPS-stöd¶

Se Installation för generella installationsinstruktioner. Detta avsnitt beskriver endast skillnaderna jämfört med dessa.

SSL-terminerande proxy¶

SSL kan avslutas utanför Weblate-containern. För att detta ska fungera väl måste flera rubriker skickas till containern så att den känner till sin faktiska miljö. Dessa rubriker beskrivs mer detaljerat i Körning bakom omvänd proxy.

Exempel på nginx-konfiguration för omvänd proxy för en Docker-container.¶

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600s;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}

Docker-containermiljö för extern SSL-terminering.¶

WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

Använda egna SSL-certifikat¶

Om du har ett eget SSL-certifikat som du vill använda, placera helt enkelt filerna i Weblate-datavolymen (se Docker-containervolymer):

ssl/fullchain.pem som innehåller certifikatet inklusive alla nödvändiga CA-certifikat
ssl/privkey.pem som innehåller den privata nyckeln

Båda dessa filer måste ägas av samma användare som den som startar docker-containern och ha filmasken inställd på 600 (läsbar och skrivbar endast av den ägande användaren).

Dessutom accepterar Weblate-containern nu SSL-anslutningar på port 4443. Du bör inkludera portvidarebefordran för HTTPS i docker compose override:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

Om du redan är värd för andra webbplatser på samma server är det troligt att portarna 80 och 443 används av en omvänd proxy, till exempel NGINX. För att vidarebefordra HTTPS-anslutningen från NGINX till docker-containern kan du använda följande konfiguration:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

Ersätt <SITE_URL>, <SITE> och <EXPOSED_DOCKER_PORT> med faktiska värden från din miljö.

Automatiska SSL-certifikat med Let’s Encrypt¶

Om du vill använda Let’s Encrypt automatiskt genererade SSL-certifikat på en offentlig installation måste du lägga till en omvänd HTTPS-proxy och en extra Docker-container, https-portal kommer att användas för det. Detta används i filen docker-compose-https.yml. Skapa sedan en docker-compose-https.override.yml-fil med dina inställningar:

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

När du anropar docker compose måste du skicka båda filerna till det och sedan göra följande:

docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Uppgradering av Docker-containern¶

Vanligtvis är det en bra idé att endast uppdatera Weblate-containern och behålla PostgreSQL-containern i den version du har, eftersom det är ganska besvärligt att uppgradera PostgreSQL och i de flesta fall inte ger några större fördelar.

Förändrat i version 4.17-1: Sedan Weblate 4.17-1 använder Docker-containern Django 4.2, vilket kräver PostgreSQL 12 eller nyare. Uppgradera detta innan du uppgraderar Weblate. Se Uppgradering av PostgreSQL-container.

Du kan göra detta genom att behålla den befintliga docker-compose och bara hämta de senaste bilderna och sedan starta om:

# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f

Weblate-databasen bör migreras automatiskt vid första start, och det bör inte behövas några ytterligare manuella åtgärder.

Observera

Uppgraderingar mellan större versioner stöds inte av Weblate. Om du till exempel använder version 3.x och vill uppgradera till 4.x måste du först uppgradera till den senaste 4.0.x-y-bilden (vid skrivande stund är det 4.0.4-5), som kommer att utföra migreringen, och sedan fortsätta uppgraderingen till nyare versioner.

Du kanske också vill uppdatera docker-compose-arkivet, även om det i de flesta fall inte behövs. Se Uppgradering av PostgreSQL-container för uppgradering av PostgreSQL-servern.

Uppgradering av PostgreSQL-container¶

PostgreSQL-containrar stöder inte automatisk uppgradering mellan versioner, du måste utföra uppgraderingen manuellt. Följande steg visar ett av alternativen för uppgradering.

Se även

https://github.com/docker-library/postgres/issues/37

Stoppa Weblate-containern:
```
docker compose stop weblate cache
```

Säkerhetskopiera databasen:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

Stoppa databasbehållaren:
```
docker compose stop database
```
Ta bort PostgreSQL-volymen:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Råd

Volymnamnet innehåller namnet på Docker Compose-projektet, som standard är det katalognamnet, vilket i denna dokumentation är weblate-docker.
Justera docker-compose.yml för att använda den nya versionen av PostgreSQL.
Starta databascontainern:
```
docker compose up -d database
```
Återställ databasen från säkerhetskopian:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
Råd

Kontrollera att databasnamnet stämmer överens med POSTGRES_DB.
(Valfritt) Uppdatera lösenordet för Weblate-användaren. Detta kan behövas vid migrering till PostgreSQL 14 eller 15, eftersom sättet att lagra lösenord har ändrats:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
Råd

Kontrollera att databasnamnet stämmer överens med POSTGRES_DB.
Starta alla återstående behållare:
```
docker compose up -d
```

Administratörsinloggning¶

Efter att containern har konfigurerats kan du logga in som administratör med lösenordet som anges i WEBLATE_ADMIN_PASSWORD, eller ett slumpmässigt lösenord som genereras vid första start om det inte har angetts.

För att återställa admin-lösenordet, starta om behållaren med WEBLATE_ADMIN_PASSWORD inställt på det nya lösenordet.

Se även

WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Antal processer och minnesförbrukning¶

Antalet arbetsprocesser för både WSGI och Celery bestäms automatiskt utifrån antalet processorer. Detta fungerar bra för de flesta virtuella molnmaskiner, eftersom dessa vanligtvis har få processorer och mycket minne.

Om du har många CPU-kärnor och stöter på minnesproblem kan du prova att minska antalet arbetare:

environment:
  WEBLATE_WORKERS: 2

Du kan också finjustera enskilda arbetstagarkategorier:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Minnesanvändningen kan minskas ytterligare genom att endast köra en enda Celery-process:

environment:
  CELERY_SINGLE_PROCESS: 1

Se även

WEBLATE_WORKERS
CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS
CELERY_SINGLE_PROCESS
WEB_WORKERS

Horisontell skalning¶

Added in version 4.6.

Du kan köra flera Weblate-containrar för att skala tjänsten horisontellt. Volymen /app/data måste delas av alla containrar, och det rekommenderas att använda ett klusterfilsystem som GlusterFS för detta. Volymen /app/cache bör vara separat för varje container.

Varje Weblate-container har en definierad roll med hjälp av miljövariabeln WEBLATE_SERVICE. Följ dokumentationen noggrant, eftersom vissa tjänster endast ska köras en gång i klustret och ordningen på tjänsterna också är viktig.

Du hittar exempel på inställningar i docker-compose-repositoriet som docker-compose-split.yml.

Docker-miljövariabler¶

Många av Weblates Konfiguration kan ställas in i Docker-containern med hjälp av de miljövariabler som beskrivs nedan.

Om du behöver definiera en inställning som inte exponeras via Docker-miljövariabler, se Konfiguration utöver miljövariabler.

Att vidarebefordra hemligheter¶

Added in version 5.0.

Weblate-containern stöder överföring av hemlig information som filer. För att utnyttja detta, lägg till suffixet _FILE till miljövariabeln och överför den hemliga filen via Docker.

Relaterat docker-compose.yml kan se ut så här:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

Se även

Hur man använder hemligheter i Docker Compose

Generella inställningar¶

WEBLATE_DEBUG¶

Konfigurerar Djangos felsökningsläge med hjälp av DEBUG.

Exempel:

environment:
  WEBLATE_DEBUG: 1

Se även

Inaktivera felsökningsläge

WEBLATE_LOGLEVEL¶

Konfigurerar loggningsdetaljnivån. Ställ in detta på DEBUG för att få mer detaljerade loggar.

Standardvärdet är INFO när WEBLATE_DEBUG är avstängt, DEBUG används när felsökningsläget är aktiverat.

För mer tyst loggning, använd ERROR eller WARNING.

WEBLATE_LOGLEVEL_DATABASE¶: Konfigurerar loggningen av databasfrågornas detaljeringsgrad.

WEBLATE_LOG_GELF_HOST¶: Added in version 5.9.

Konfigurerar fjärrloggning med hjälp av GELF TCP-anslutning. Kan användas för integration med Graylog.

WEBLATE_LOG_GELF_PORT¶: Added in version 5.9.

Använd anpassad port för WEBLATE_LOG_GELF_HOST, standardvärdet är 12201.

WEBLATE_SITE_TITLE¶: Ändrar webbplatsens titel som visas i rubriken på alla sidor.

WEBLATE_SITE_DOMAIN¶

Konfigurerar webbplatsdomänen. Denna parameter är obligatorisk.

Ange port om du använder en icke-standardport.

Exempel:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Se även

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

Konfigurerar webbplatsadministratörens namn och e-postadress. Används både för inställningen ADMINS och för att skapa användaren admin (se WEBLATE_ADMIN_PASSWORD för mer information om detta).

Exempel:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

Se även

WEBLATE_ADMIN_PASSWORD¶

Ställer in lösenordet för användaren admin.

Om det inte är inställt och användaren admin inte finns, skapas den med ett slumpmässigt lösenord som visas när den första behållaren startas.
Om det inte är inställt och användaren admin finns, utförs ingen åtgärd.
Om inställningen är aktiverad justeras användaren admin vid varje containerstart så att den matchar WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME och WEBLATE_ADMIN_EMAIL.

Varning

Det kan vara en säkerhetsrisk att lagra lösenordet i konfigurationsfilen. Överväg att endast använda denna variabel för den initiala konfigurationen (eller låt Weblate generera ett slumpmässigt lösenord vid den första starten) eller för återställning av lösenord.

Se även

Administratörsinloggning
Att vidarebefordra hemligheter
WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_NOTIFY_ERROR¶

Om e-post ska skickas till administratörer vid serverfel. Aktiverat som standard.

Du kanske vill använda andra felinsamlingsverktyg som Sentry eller Rollbar och stänga av den här funktionen.

Se även

WEBLATE_SERVER_EMAIL¶

Den e-postadress som felmeddelanden skickas från.

Se även

WEBLATE_DEFAULT_FROM_EMAIL¶

Konfigurerar adressen för utgående e-postmeddelanden.

Se även

WEBLATE_ADMINS_CONTACT¶: Konfigurerar ADMINS_CONTACT.

WEBLATE_CONTACT_FORM¶: Konfigurerar kontaktformulärets beteende, se CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS¶

Konfigurerar tillåtna HTTP-värdnamn med hjälp av ALLOWED_HOSTS.

Standardinställningen är *, vilket tillåter alla värdnamn.

Exempel:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

Se även

WEBLATE_REGISTRATION_OPEN¶

Konfigurerar om registreringar är öppna genom att växla REGISTRATION_OPEN.

Exempel:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_CAPTCHA¶

Added in version 5.10.

Konfigurerar om captcha används för registrering och andra oautentiserade åtgärder, se REGISTRATION_CAPTCHA.

Exempel:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

Konfigurera vilka autentiseringsmetoder som kan användas för att skapa nya konton via REGISTRATION_ALLOW_BACKENDS.

Exempel:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

Konfigurerar REGISTRATION_REBIND.

WEBLATE_TIME_ZONE¶

Konfigurerar den tidszon som används i Weblate, se TIME_ZONE.

Observera

För att ändra tidszonen för själva Docker-containern använder du miljövariabeln TZ.

Exempel:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Får Weblate att anta att det drivs bakom en omvänd HTTPS-proxy, vilket gör att Weblate använder HTTPS i e-post och API-länkar eller sätter säkra flaggor på cookies.

Råd

Se dokumentationen för ENABLE_HTTPS för eventuella varningar.

Observera

Detta gör inte att Weblate-containern accepterar HTTPS-anslutningar, du måste också konfigurera det, se Docker-container med HTTPS-stöd för exempel.

Exempel:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Se även

WEBLATE_IP_PROXY_HEADER¶

Låt Weblate hämta IP-adressen från valfri HTTP-header. Använd detta när du använder en omvänd proxy framför Weblate-containern.

Aktiverar IP_BEHIND_REVERSE_PROXY och ställer in IP_PROXY_HEADER.

Observera

Formatet måste överensstämma med Djangos förväntningar. Django transformerar råa HTTP-rubriknamn enligt följande:

konverterar alla tecken till versaler
ersätter alla bindestreck med understreck
lägger till prefixet HTTP_ före

Således skulle X-Forwarded-For mappas till HTTP_X_FORWARDED_FOR.

Exempel:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

Konfigurerar IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

En boolesk variabel som anger om X-Forwarded-Port-rubriken ska användas i stället för SERVER_PORT META-variabeln. Detta bör endast aktiveras om en proxy som ställer in denna rubrik används.

Se även

USE_X_FORWARDED_PORT

Observera

Detta är en boolesk inställning (använd "true" eller "false").

WEBLATE_SECURE_PROXY_SSL_HEADER¶

En tupel som representerar en kombination av HTTP-rubrik och värde som anger att en begäran är säker. Detta behövs när Weblate körs bakom en omvänd proxy som utför SSL-terminering och som inte vidarebefordrar standard-HTTPS-rubriker.

Exempel:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Se även

WEBLATE_REQUIRE_LOGIN¶

Aktiverar REQUIRE_LOGIN för att kräva autentisering på hela Weblate.

Exempel:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_GOOGLE_ANALYTICS_ID¶: Konfigurerar ID för Google Analytics genom att ändra GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE¶: Konfigurerar standardrubrik och meddelande för pull-förfrågningar via API genom att ändra DEFAULT_PULL_MESSAGE.

Se även

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: Konfigurerar policyn för språklig förenkling, se SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL¶: Konfigurerar standardinställningen Åtkomstkontroll för nya projekt, se DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: Konfigurerar standardvärdet för Begränsad åtkomst för nya komponenter, se DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: Konfigurerar standardvärdet för Tillåt spridning av översättning för nya komponenter, se DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL¶: Konfigurerar DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME¶: Konfigurerar DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM¶: Konfigurerar DEFAULT_SHARED_TM.

WEBLATE_DEFAULT_AUTOCLEAN_TM¶: Konfigurerar DEFAULT_AUTOCLEAN_TM.

WEBLATE_GPG_IDENTITY¶: Konfigurerar GPG-signering av commit, se WEBLATE_GPG_IDENTITY.

Se även

Signera Git-commits med GnuPG

WEBLATE_URL_PREFIX¶: Konfigurerar URL-prefix där Weblate körs, se URL_PREFIX.

WEBLATE_STATIC_URL¶: Konfigurerar URL-prefix för server för statiska filer från CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: Konfigurerar kontroller som du inte vill ska visas, se SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶

WEBLATE_CSP_FORM_SRC¶

Gör det möjligt att anpassa HTTP-rubriken Content-Security-Policy.

Se även

WEBLATE_LICENSE_FILTER¶: Konfigurerar LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED¶: Konfigurerar LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED¶: Konfigurerar WEBSITE_REQUIRED.

WEBLATE_HIDE_VERSION¶: Konfigurerar HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES¶: Konfigurerar BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH¶: Konfigurerar DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶

Added in version 4.6.

Konfigurerar hastighetsbegränsaren.

Råd

Du kan ställa in konfigurationen för alla hastighetsbegränsare. För att göra det lägger du till prefixet WEBLATE_ till någon av inställningarna som beskrivs i Hastighetsbegränsande.

Se även

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

Konfigurerar API-hastighetsbegränsning. Standardvärdet är 100/dag för anonyma användare och 5000/timme för autentiserade användare.

Se även

API-hastighetsbegränsning

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

Konfigurerar ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

Konfigurerar ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

Konfigurerar AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

Konfigurerar LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

Konfigurerar SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

Konfigurerar BORG_EXTRA_ARGS som en kommaseparerad lista med argument.

Exempel:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

Konfigurerar ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

Konfigurerar SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

Konfigurerar EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

Konfigurerar PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

Konfigurerar PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

Konfigurerar UNUSED_ALERT_DAYS.

WEBLATE_UPDATE_LANGUAGES¶: Added in version 4.3.2.

Konfigurerar UPDATE_LANGUAGES.

WEBLATE_VCS_ALLOW_HOSTS¶: Added in version 5.15.

Konfigurerar VCS_ALLOW_HOSTS.

WEBLATE_VCS_ALLOW_SCHEMES¶: Added in version 5.15.

Konfigurerar VCS_ALLOW_SCHEMES.

WEBLATE_VCS_CLONE_DEPTH¶: Added in version 5.4.

Konfigurerar VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY¶: Added in version 5.4.

Konfigurerar VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT¶: Added in version 5.15.

Konfigurerar VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

Tillåt CORS-förfrågningar till API från angivna ursprung.

Exempel:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

WEBLATE_CORS_ALLOW_ALL_ORIGINS¶: Added in version 5.6.1: Tillåter CORS-förfrågningar till API från alla ursprung.

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

Konfigurerar maximal kroppsstorlek som accepteras av den inbyggda webbservern.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Råd

Denna variabel saknar avsiktligt prefixet WEBLATE_ eftersom den delas med en tredjepartscontainer som används i Automatiska SSL-certifikat med Let’s Encrypt.

Inloggningsuppgifter för kodhostingsajter¶

I Docker-containern kan kodens autentiseringsuppgifter konfigureras antingen i separata variabler eller med hjälp av en Python-ordlista för att ställa in dem på en gång. Följande exempel gäller för GitHub-pullförfrågningar, men gäller alla Integration av versionskontroll med lämpligt ändrade variabelnamn.

Viktigt

Alla miljövariabelnamn måste innehålla prefixet WEBLATE_. Om du till exempel vill konfigurera GitHub-inloggningsuppgifter använder du WEBLATE_GITHUB_USERNAME, inte GITHUB_USERNAME. Detta gäller oavsett om du konfigurerar för pull-förfrågningar eller någon annan VCS-integration.

En exempelkonfiguration för GitHub-pull-förfrågningar kan se ut så här:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

Kommer att användas som:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

Alternativt kan Python-ordlistan anges som en sträng:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

Eller sökvägen till en fil som innehåller Python-ordlistan:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

WEBLATE_GITHUB_USERNAME¶

WEBLATE_GITHUB_TOKEN¶

WEBLATE_GITHUB_HOST¶

WEBLATE_GITHUB_CREDENTIALS¶: Konfigurerar GitHub-pullförfrågningar genom att ändra GITHUB_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Konfigurerar GitLab-sammanslagningsförfrågningar genom att ändra GITLAB_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Konfigurerar Gitea-pullförfrågningar genom att ändra GITEA_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Konfigurerar Pagure-sammanslagningsförfrågningar genom att ändra PAGURE_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Konfigurerar Bitbucket Data Center-pullförfrågningar genom att ändra BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME¶

WEBLATE_BITBUCKETCLOUD_WORKSPACE¶

WEBLATE_BITBUCKETCLOUD_TOKEN¶

WEBLATE_BITBUCKETCLOUD_HOST¶

WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶: Konfigurerar Bitbucket Cloud-pullförfrågningar genom att ändra BITBUCKETCLOUD_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Konfigurerar Azure DevOps pull-förfrågningar genom att ändra AZURE_DEVOPS_CREDENTIALS.

Se även

Konfigurera inloggningsuppgifter för kodhosting i Docker

Inställningar för automatiska förslag¶

Förändrat i version 4.13: Automatiska förslagstjänster konfigureras nu i användargränssnittet, se Automatiska förslag.

De befintliga miljövariablerna importeras under migreringen till Weblate 4.13, men att ändra dem kommer inte att ha någon ytterligare effekt.

Autentiseringsinställningar¶

Råd

E-postbaserad autentisering är aktiverad om den inte inaktiveras av WEBLATE_NO_EMAIL_AUTH.

LDAP¶

WEBLATE_AUTH_LDAP_SERVER_URI¶

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶

WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶

WEBLATE_AUTH_LDAP_BIND_DN¶

WEBLATE_AUTH_LDAP_BIND_PASSWORD¶

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶

WEBLATE_AUTH_LDAP_USER_SEARCH¶

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶

LDAP-autentiseringskonfiguration.

Exempel på direktbindning:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

Exempel på sökning och bindning:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

Exempel på unionssökning och bindning:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Exempel med sökning och bindning mot Active Directory:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

Se även

GitHub¶

WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID¶: Aktiverar GitHub-autentisering.

GitHub Enterprise Edition¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶: Aktiverar GitHub EE-autentisering.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶: Aktiverar Bitbucket-autentisering.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Aktiverar Facebook OAuth 2.

Google¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶: Aktiverar Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Aktiverar GitLab OAuth 2.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Aktiverar Gitea-autentisering.

Azure Active Directory¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Aktiverar Azure Active Directory-autentisering, se Microsoft Azure Active Directory.

Azure Active Directory med stöd för hyresgäster¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Aktiverar Azure Active Directory-autentisering med stöd för Tenant, se Microsoft Azure Active Directory.

Keycloak¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶

Aktiverar Keycloak-autentisering, se Keycloak - Open Source Red Hat SSO.

Råd

När Keycloak är konfigurerat för att abstrahera tredjeparts-IDP måste du konfigurera WEBLATE_CSP_FORM_SRC för tredjeparts-IDP-domänen.

Exempel när Keycloak vidarebefordrar autentisering till Microsoft.¶

environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

Linux-leverantörer¶

Du kan aktivera autentisering med hjälp av Linux-leverantörers autentiseringstjänster genom att ställa in följande variabler till valfritt värde.

WEBLATE_SOCIAL_AUTH_FEDORA¶

WEBLATE_SOCIAL_AUTH_OPENSUSE¶

WEBLATE_SOCIAL_AUTH_OPENINFRA¶

WEBLATE_SOCIAL_AUTH_UBUNTU¶

Slack¶

WEBLATE_SOCIAL_AUTH_SLACK_KEY¶

SOCIAL_AUTH_SLACK_SECRET¶: Aktiverar Slack-autentisering, se Slack.

OpenID Connect¶

Added in version 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶

WEBLATE_SOCIAL_AUTH_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶

WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_TITLE¶

WEBLATE_SOCIAL_AUTH_OIDC_IMAGE¶: Konfigurerar generisk OpenID Connect-integration.

Se även

OIDC (OpenID Connect)

Fedora OpenID Connect¶

Added in version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET¶: Konfigurerar Fedora OpenID Connect-integration.

Se även

Fedora

SAML¶

Självsignerade SAML-nycklar genereras automatiskt vid första start av containern. Om du vill använda egna nycklar placerar du certifikatet och den privata nyckeln i /app/data/ssl/saml.crt och /app/data/ssl/saml.key.

WEBLATE_SAML_IDP_ENTITY_ID¶

WEBLATE_SAML_IDP_URL¶

WEBLATE_SAML_IDP_X509CERT¶

WEBLATE_SAML_IDP_IMAGE¶

WEBLATE_SAML_IDP_TITLE¶: Inställningar för SAML-identitetsleverantör, se SAML-autentisering.

WEBLATE_SAML_ID_ATTR_FULL_NAME¶

WEBLATE_SAML_ID_ATTR_FIRST_NAME¶

WEBLATE_SAML_ID_ATTR_LAST_NAME¶

WEBLATE_SAML_ID_ATTR_USERNAME¶

WEBLATE_SAML_ID_ATTR_EMAIL¶

WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶: Added in version 4.18.

SAML-attributmappning.

Övriga autentiseringsinställningar¶

WEBLATE_NO_EMAIL_AUTH¶: Inaktiverar e-postautentisering när den är inställd på något värde. Se Inaktivera lösenordsautentisering.

WEBLATE_MIN_PASSWORD_SCORE¶

Minsta lösenordspoäng enligt bedömningen av lösenordsstyrkan med zxcvbn. Standardvärdet är 3. Ställ in på 0 för att inaktivera styrkekontrollen.

Se även

Inställning av PostgreSQL-databas¶

Databasen skapas av docker-compose.yml, så dessa inställningar påverkar både Weblate- och PostgreSQL-containrar.

Se även

Databasinställningar för Weblate

POSTGRES_PASSWORD¶: PostgreSQL-lösenord.

Se även

Att vidarebefordra hemligheter

POSTGRES_USER¶: PostgreSQL-användarnamn.

POSTGRES_DB¶: PostgreSQL-databasnamn.

POSTGRES_HOST¶: PostgreSQL-serverns värdnamn eller IP-adress. Standardvärdet är database.

POSTGRES_PORT¶: PostgreSQL-serverport. Standardinställningen är ingen (använder standardvärdet).

POSTGRES_SSL_MODE¶: Konfigurera hur PostgreSQL hanterar SSL vid anslutning till servern. För möjliga alternativ, se SSL Mode Descriptions.

POSTGRES_ALTER_ROLE¶

Konfigurerar namnet på PostgreSQL-rollen som ska ändras under databasmigreringen, se Konfigurera Weblate för att använda PostgreSQL.

Standardvärdet är POSTGRES_USER.

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

Livslängden för en databasanslutning, uttryckt som ett heltal i sekunder. Använd 0 för att stänga databasanslutningar i slutet av varje begäran.

Förändrat i version 5.1: Standardinställningen är att ha obegränsade permanenta databasanslutningar.

Om du aktiverar anslutningspersistens kommer det vanligtvis att leda till fler öppna anslutningar till databasen. Justera din databaskonfiguration innan du aktiverar funktionen.

Exempel på konfiguration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Se även

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

Inaktivera server-sidans markörer i databasen. Detta är nödvändigt i vissa pgbouncer-konfigurationer.

Exempel på konfiguration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Se även

WEBLATE_DATABASES¶: Added in version 5.1.

Ställ in på false för att inaktivera miljöbaserad konfiguration av databasanslutningen. Använd Åsidosätta inställningar från datavolymen för att konfigurera databasanslutningen manuellt.

MySQL- eller MariaDB-server¶

Varken MySQL eller MariaDB kan konfigureras via miljövariabler. Se MySQL och MariaDB för information om hur du använder dessa med Weblate. Använd WEBLATE_DATABASES för att konfigurera databasanslutningen manuellt.

Inställningar för databasbackup¶

Se även

Dumpade data för säkerhetskopior

WEBLATE_DATABASE_BACKUP¶: Konfigurerar den dagliga databasdumpen med hjälp av DATABASE_BACKUP. Standardinställningen är plain.

Datastore-serverkonfiguration¶

Weblate-containern kräver att Valkey eller Redis används, och du måste ange anslutningsparametrar när du kör Weblate i Docker.

Se även

Konfigurera cache

REDIS_HOST¶: Datastore-serverns värdnamn eller IP-adress. Standardvärdet är cache.

REDIS_PORT¶: Datastore-serverns port. Standardvärdet är 6379.

REDIS_DB¶: Datastore-databasnumret, standardvärdet är 1.

REDIS_USER¶: Added in version 5.13: Datastore-databasens användare, används inte som standard.

REDIS_PASSWORD¶: Datastore-serverns lösenord, används inte som standard.

Se även

Att vidarebefordra hemligheter

REDIS_TLS¶: Aktiverar användning av SSL för datalagringsanslutningen.

REDIS_VERIFY_SSL¶: Kan användas för att inaktivera SSL-certifikatverifiering för datalagringsanslutningen.

Konfigurera e-postserver¶

För att utgående e-post ska fungera måste du ange en e-postserver.

Exempel på TLS-konfiguration:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

Exempel på SSL-konfiguration:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1

Se även

Konfigurera utgående e-post

WEBLATE_EMAIL_HOST¶

E-postserverns värdnamn eller IP-adress.

Se även

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
WEBLATE_EMAIL_USE_TLS
EMAIL_HOST

WEBLATE_EMAIL_PORT¶: E-postserverns port, standardinställningen är 25.

Se även

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: E-postautentiseringsanvändare.

Se även

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶

E-postautentiseringslösenord.

Se även

WEBLATE_EMAIL_USE_SSL¶

Om en implicit TLS-anslutning (säker) ska användas vid kommunikation med SMTP-servern. I de flesta e-postdokumentationer kallas denna typ av TLS-anslutning för SSL. Den används vanligtvis på port 465. Om du har problem, se den explicita TLS-inställningen WEBLATE_EMAIL_USE_TLS.

Förändrat i version 4.11: SSL/TLS-stödet aktiveras automatiskt baserat på WEBLATE_EMAIL_PORT.

Se även

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_TLS
EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶

Om en TLS-anslutning (säker) ska användas vid kommunikation med SMTP-servern. Detta används för explicita TLS-anslutningar, vanligtvis på port 587 eller 25. Om du upplever att anslutningarna hänger sig, se den implicita TLS-inställningen WEBLATE_EMAIL_USE_SSL.

Förändrat i version 4.11: SSL/TLS-stödet aktiveras automatiskt baserat på WEBLATE_EMAIL_PORT.

Se även

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶

Konfigurerar Django-backend för att skicka e-post.

Se även

WEBLATE_AUTO_UPDATE¶: Konfigurerar om och hur Weblate ska uppdatera arkiv.

Se även

AUTO_UPDATE

Observera

Detta är en boolesk inställning (använd "true" eller "false").

Webbplatsintegration¶

WEBLATE_GET_HELP_URL¶: Konfigurerar GET_HELP_URL.

WEBLATE_STATUS_URL¶: Konfigurerar STATUS_URL.

WEBLATE_LEGAL_URL¶: Konfigurerar LEGAL_URL.

WEBLATE_PRIVACY_URL¶: Konfigurerar PRIVACY_URL.

Insamling av felrapporter och övervakning av prestanda¶

Det rekommenderas att systematiskt samla in fel från installationen, se Insamling av felrapporter och övervakning av prestanda.

För att aktivera stöd för Rollbar, ställ in följande:

ROLLBAR_KEY¶: Din Rollbar-postserveråtkomsttoken.

ROLLBAR_ENVIRONMENT¶: Din Rollbar-miljö är som standard inställd på produktion.

För att aktivera stöd för Sentry, ställ in följande:

SENTRY_DSN¶: Din Sentry DSN, se SENTRY_DSN.

SENTRY_ENVIRONMENT¶: Din Sentry-miljö (valfritt), standardinställning är WEBLATE_SITE_DOMAIN.

SENTRY_MONITOR_BEAT_TASKS¶: Om Celery Beat-uppgifter ska övervakas med Sentry, standardinställningen är True.

SENTRY_TRACES_SAMPLE_RATE¶

Konfigurerar SENTRY_TRACES_SAMPLE_RATE.

Exempel:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

SENTRY_PROFILES_SAMPLE_RATE¶

Konfigurerar SENTRY_PROFILES_SAMPLE_RATE.

Exempel:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

SENTRY_SEND_PII¶: Konfigurerar SENTRY_SEND_PII.

Lokalisering CDN¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Konfiguration för JavaScript-lokalisering CDN.

WEBLATE_LOCALIZE_CDN_PATH är en sökväg inom containern. Den bör lagras på den permanenta volymen och inte i det tillfälliga lagringsutrymmet.

En möjlighet är att lagra det i Weblate-datakatalogen:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

Observera

Du ansvarar för att konfigurera serveringen av de filer som genereras av Weblate, som endast lagrar filerna på den konfigurerade platsen.

Se även

Ändra aktiverade appar, kontroller, tillägg, maskinöversättning eller automatiska korrigeringar¶

Den inbyggda konfigurationen av aktiverade kontroller, tillägg eller automatiska korrigeringar kan justeras med följande variabler:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

WEBLATE_ADD_MACHINERY¶: Added in version 5.6.1.

WEBLATE_REMOVE_MACHINERY¶: Added in version 5.6.1.

Exempel:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Se även

Containerinställningar¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

Basantalet arbetareprocesser som körs i behållaren. Om det inte är inställt bestäms det automatiskt vid behållarens start baserat på antalet tillgängliga CPU-kärnor.

Den används för att bestämma CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS och WEB_WORKERS. Du kan använda dessa inställningar för att finjustera.

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

Med dessa variabler kan du justera Celery-arbetaralternativen. Det kan vara användbart att justera samtidigheten (--concurrency 16) eller använda en annan poolimplementering (--pool=gevent).

Som standard baseras antalet samtidiga arbetare på WEBLATE_WORKERS.

Exempel:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Se även

CELERY_SINGLE_PROCESS¶

Added in version 5.7.1: Denna variabel kan ställas in på 1 för att endast köra en celery-process. Detta minskar minnesanvändningen men kan påverka Weblates prestanda.

environment:
  CELERY_SINGLE_PROCESS: 1

Se även

Enkelprocess-konfiguration av Celery

WEB_WORKERS¶

Konfigurera hur många WSGI-arbetare som ska köras.

Standardvärdet är hälften av WEBLATE_WORKERS, men är alltid minst 2.

Exempel:
environment:
  WEB_WORKERS: 4

Förändrat i version 5.13: WEB_WORKERS konfigurerar hur många arbetsprocesser som ska användas av granian.

WEBLATE_SERVICE¶

Definierar vilka tjänster som ska köras inuti containern. Använd detta för Horisontell skalning.

Följande tjänster definieras:

celery-beat: Celery-uppgiftsschemaläggare, endast en instans ska köras. Denna behållare ansvarar också för migreringar av databasstrukturen och ska startas före andra.
celery-backup: Celery-arbetare för säkerhetskopior, endast en instans ska köras.
celery-celery: Generisk selleriarbetare.
celery-memory: Översättningsminne Celery-arbetare.
celery-notify: Meddelanden Celery-arbetare.
celery-translate: Automatisk översättning Selleriarbetare.
web: Webbserver.

Se även

Bakgrundsuppgifter internt

WEBLATE_ANUBIS_URL¶

Added in version 5.11.4.

URL för Anubis -servern för att hantera autentisering av underförfrågningar. Detta kan vara användbart för att filtrera inkommande HTTP-förfrågningar med hjälp av proof-of-work för att stoppa AI-crawlers. Du måste konfigurera Anubis för autentisering av underförfrågningar för att det ska fungera.

Se även

Anubis Docker-containerintegration
Anubis

Docker-containervolymer¶

Det finns två volymer (data och cache) som exporteras av Weblate-containern.

Observera

De andra servicecontainrarna (som PostgreSQL eller Valkey) har också sina datavolymer och krävs för att upprätthålla Weblates persistens.

PostgreSQL-containern lagrar databasen i volymen /var/lib/postgresql och Valkey i volymen /data. Valkey-containern sparar inte data som standard och kräver ytterligare konfiguration för att aktivera persistens.

Basera din konfiguration på exempel från Weblate eller läs deras dokumentation för mer information.

Volymen data är monterad som /app/data och används för att lagra Weblate-data som klonade arkiv eller för att anpassa Weblate-installationen. DATA_DIR beskriver mer detaljerat vad som lagras här.

Volymen data används också för att lagra Weblate-anpassningar såsom Åsidosätta inställningar från datavolymen, Ersätta logotyp och andra statiska filer eller Anpassa kod.

Placeringen av Docker-volymen på värdsystemet beror på din Docker-konfiguration, men vanligtvis lagras den i /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (sökvägen består av namnet på din docker-compose-katalog, container och volymnamn).

cache-volymen är monterad som /app/cache och används för att lagra statiska filer och CACHE_DIR. Dess innehåll återskapas när containern startas och volymen kan monteras med hjälp av ett tillfälligt filsystem som tmpfs.

När volymerna skapas manuellt ska katalogerna ägas av UID 1000, eftersom det är den användare som används inuti containern.

Weblate-containern kan också köras med ett skrivskyddat rotfilsystem. I detta fall bör två ytterligare tmpfs-volymer monteras: /tmp och /run.

Se även

Skrivskyddat rotfilsystem¶

Added in version 4.18.

När containern körs med ett skrivskyddat rotsystem krävs två ytterligare tmpfs-volymer: /tmp och /run.

Konfiguration utöver miljövariabler¶

Docker-miljövariabler är avsedda att exponera de flesta konfigurationsinställningar som är relevanta för Weblate-installationer.

Om du hittar en inställning som inte visas som en miljövariabel och du anser att den borde göra det, kan du gärna be om att den ska visas i en framtida version av Weblate.

Om du behöver ändra en inställning som inte visas som en Docker-miljövariabel kan du fortfarande göra det, antingen från datavolym eller genom att utöka Docker-bilden.

Se även

Anpassa Weblate

Åsidosätta inställningar från datavolymen¶

Du kan skapa en fil i /app/data/settings-override.py, dvs. i roten av datavolymen, för att utöka eller åsidosätta inställningar som definierats genom miljövariabler.

Åsidosätta inställningar genom att utöka Docker-bilden¶

För att åsidosätta inställningar på Docker-bildnivå istället för från datavolymen:

Skapa ett anpassat Python-paket.
Lägg till en modul till ditt paket som importerar alla inställningar från weblate.settings_docker.

Till exempel, inom den exempelpaketstruktur som definieras i Skapa en Python-modul, kan du skapa en fil i weblate_customization/weblate_customization/settings.py med följande initiala kod:
```
from weblate.settings_docker import *
```

Skapa en anpassad Dockerfile som ärver från den officiella Weblate Docker-bilden, installerar sedan ditt paket och pekar miljövariabeln DJANGO_SETTINGS_MODULE till din inställningsmodul:

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN source /app/venv/bin/activate && uv pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

Istället för att använda den officiella Weblate Docker-bilden kan du skapa en anpassad bild från denna Dockerfile-fil.

Det finns inget rent sätt <https://github.com/docker/compose/issues/7231> att göra detta med docker-compose.override.yml. Du kan lägga till build: . till weblate-noden i den filen, men då kommer din anpassade bild att märkas som weblate/weblate i ditt system, vilket kan vara problematiskt.

Så istället för att använda docker-compose.yml direkt från det officiella arkivet, utan modifieringar, och utöka den genom docker-compose.override.yml, kanske du vill göra en kopia av den officiella filen docker-compose.yml och redigera din kopia för att ersätta image: weblate/weblate med build: ..

Se Compose file build reference för mer information om hur man bygger bilder från källkoden när man använder docker-compose.
Utöka din modul för anpassade inställningar för att definiera eller omdefiniera inställningar.

Du kan definiera inställningar före eller efter import-satsen ovan för att avgöra vilka inställningar som har företräde. Inställningar som definieras före import-satsen kan åsidosättas av miljövariabler och inställningsåsidosättningar som definieras i datavolymen. Inställningar som definieras efter import-satsen kan inte åsidosättas.

Du kan också gå längre. Du kan till exempel reproducera vissa av de saker som weblate.docker_settings gör, såsom att exponera inställningar som miljövariabler eller tillåta att inställningar från Python-filer i datavolymen åsidosätts.

Ersätta logotyp och andra statiska filer¶

De statiska filerna som medföljer Weblate kan åsidosättas genom att placera dem i /app/data/python/customize/static (se Docker-containervolymer). Om du till exempel skapar /app/data/python/customize/static/favicon.ico kommer faviconen att ersättas.

Råd

Filerna kopieras till motsvarande plats när containern startas, så det krävs en omstart av Weblate efter att innehållet i volymen har ändrats.

Denna metod kan också användas för att åsidosätta Weblate-mallar. Till exempel kan Juridisk modul-dokument placeras i /app/data/python/customize/templates/legal/documents.

Alternativt kan du också inkludera en egen modul (se Anpassa Weblate) och lägga till den som en separat volym i Docker-containern, till exempel:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

Anpassa kod¶

Observera

Det interna Weblate-API:et kan variera avsevärt mellan olika versioner och är inte avsett att vara stabilt. Kontrollera din anpassade kod som interagerar med Weblate-interna funktioner vid varje uppgradering.

Du kan placera ytterligare Python-kod i /app/data/python/customize (se Docker-containervolymer). Den är redan installerad som en Django-applikation inuti Weblate (den används för att anpassa mallar och statiska filer enligt beskrivningen ovan).

Detta kan användas för att placera valfri kod (till exempel Skriva egna checkar) eller för att lägga till anpassade underhållsuppgifter till Celery-uppgiftsschemaläggaren.

Ett exempel på anpassade schemalagda uppgifter i /app/data/python/customize/tasks.py.¶

"""Custom scheduled task."""

import subprocess

from celery.schedules import crontab

from weblate.utils.celery import app


@app.task
def custom_task() -> None:
    """Execute custom task code."""
    subprocess.run(["sleep", "1"], check=True)


@app.on_after_finalize.connect
def setup_periodic_tasks(sender, **kwargs) -> None:
    """Configure when periodic task is triggered."""
    sender.add_periodic_task(
        crontab(hour=1, minute=0), custom_task.s(), name="custom-task"
    )

Integrering av tredjepartscontainrar¶

Weblate Docker-installationen kan utökas med ytterligare containrar för att tillhandahålla kompletterande tjänster såsom maskinöversättning, stavningskontroll eller andra verktyg som förbättrar översättningsflödet. Dessa tjänster kan integreras i din Docker Compose-konfiguration och fungera tillsammans med Weblate.

När du lägger till behållare från tredje part bör du tänka på följande:

Nätverksanslutning: Se till att containrarna kan kommunicera med varandra genom att placera dem i samma Docker-nätverk
Datapersistens: Använd volymer för tjänster som behöver lagra data
Säkerhet: Konfigurera lämpliga åtkomstkontroller och undvik att exponera onödiga portar

LibreTranslate Docker-containerintegration¶

LibreTranslate är en gratis och öppen källkodstjänst för maskinöversättning som kan hostas själv. Genom att integrera den med Weblate får man tillgång till maskinöversättning offline utan att behöva förlita sig på externa tjänster.

Du kan integrera LibreTranslate-tjänsten i din Weblate-distribution genom att inkludera den i en docker-compose.override.yml-fil. Eftersom den körs inom Docker-nätverket är den endast tillgänglig för Weblate och exponeras inte för det offentliga internet.

Grundläggande inställningar med hjälp av docker-compose.override.yml:

services:
  libretranslate:
    image: libretranslate/libretranslate:latest
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s

volumes:
  libretranslate_models:

För GPU-accelererad översättning (om du har NVIDIA GPU tillgängligt):

services:
  libretranslate:
    image: libretranslate/libretranslate:latest-cuda
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
      PUID: root
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  libretranslate_models:

Efter att ha startat tjänsterna med docker compose down && docker compose up -d, konfigurera LibreTranslate i Weblate:

Öppna Weblate-administratörsgränssnittet
Navigera till Maskinöversättning → Automatiska förslag
Lägg till en ny LibreTranslate-tjänst med:

Tjänst:

LibreTranslate

URL för API:

http://libretranslate:5000

API-nyckel:

Lämna tomt

LibreTranslate är nu konfigurerat och tillgängligt för maskinöversättning i Weblate.

Observera

LibreTranslate-tjänsten körs utan webbgränssnittet (--disable-web-ui) och är endast tillgänglig via API:et inom Docker-nätverket.
Modellerna uppdateras automatiskt när containern startar. (LT_UPDATE_MODELS: true)
Data lagras med hjälp av Docker-volymer för optimal prestanda och datasäkerhet.
Hälsokontroller säkerställer att Docker-motorn korrekt observerar tjänstens status.
För GPU-acceleration, använd CUDA-bildvarianten och se till att ditt system har stöd för NVIDIA Docker. Denna container körs som en privilegierad användare för att kunna använda GPU:n.
Inga externa portar är exponerade, vilket gör installationen säker som standard.

Se även

Anubis Docker-containerintegration¶

Anubis är ett webbaserat AI-brandväggsverktyg som blockerar AI-skrapare och annan störande trafik på servern. Det behövs vanligtvis för offentligt tillgängliga Weblate-installationer för att undvika överbelastning orsakad av skrapning.

Anubis kan distribueras med hjälp av Docker Compose:

anubis:
   image: ghcr.io/techarohq/anubis:latest
   environment:
      BIND: ":8923"
      DIFFICULTY: "4"
      METRICS_BIND: ":9090"
      SERVE_ROBOTS_TXT: "false"
      OG_PASSTHROUGH: "false"
      # The single space in TARGET enables subrequest authentication
      TARGET: " "
      # The redirect domain has to match WEBLATE_SITE_DOMAIN
      REDIRECT_DOMAINS: weblate.example.com
      # Generate a random private key using: openssl rand -hex 32
      ED25519_PRIVATE_KEY_HEX: "..."
      # Customize your Anubis policy
      POLICY_FNAME: /data/botPolicies.yaml
   healthcheck:
      test: ["CMD", "anubis", "--healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5
      start_period: 500ms
   volumes:
      - anubis-data:/data

volumes:
   anubis-data:

Observera

Volymen anubis-data i ovanstående konfiguration förväntas innehålla botPolicies.yaml med en botpolicy konfigurerad efter dina behov.

Du måste åtminstone justera statuskoderna enligt beskrivningen i https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth.

Det rekommenderas också att konfigurera permanent lagringsbackend enligt beskrivningen i https://anubis.techaro.lol/docs/admin/policies/#storage-backends.

Du kan sedan aktivera Anubis-användningen i Weblate med hjälp av:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Se även

WEBLATE_ANUBIS_URL

Konfigurera PostgreSQL-server¶

PostgreSQL-containern använder standardkonfigurationen för PostgreSQL och utnyttjar inte dina CPU-kärnor eller ditt minne på ett effektivt sätt. Vi rekommenderar att du anpassar konfigurationen för att förbättra prestandan.

Konfigurationen kan justeras enligt beskrivningen i Databaskonfiguration på https://hub.docker.com/_/postgres. Konfigurationen som passar din miljö kan genereras med hjälp av https://pgtune.leopard.in.ua/.

Container-interna¶

Containern använder supervisor för att starta enskilda tjänster. I fallet med Horisontell skalning startar den endast en enda tjänst i en container.

För att kontrollera tjänsternas status, använd:

docker compose exec --user weblate weblate supervisorctl status

Det finns individuella tjänster för varje Celery-kö (se Bakgrundsuppgifter med Celery för mer information). Du kan stoppa bearbetningen av vissa uppgifter genom att stoppa lämplig arbetare:

docker compose exec --user weblate weblate supervisorctl stop celery-translate