Pokyny na konfiguráciu¶

Inštalácia Weblate¶

V závislosti od vášho nastavenia a skúseností si vyberte vhodnú metódu inštalácie:

Inštalácia pomocou Dockeru, odporúčané pre produkčné nastavenia.
Inštalácia Virtualenv, odporúčaná pre produkčné nastavenia:
Inštalácia zo zdrojových kódov, odporúčané pre vývoj.
Inštalácia na OpenShift
Inštalácia na Kubernetes

Prehľad architektúry¶

Webový server

Spracovanie prichádzajúcich HTTP požiadaviek, Obsluha statických súborov.

Pracovníci Celery

Tu sa vykonávajú Úlohy na pozadí pomocou Celery.

V závislosti od vašej záťaže môžete chcieť prispôsobiť počet pracovníkov.

Pri horizontálnom škálovaní Weblate použite vyhradený uzol.

Aplikačný server

Server WSGI alebo ASGI obsluhujúci webové stránky pre používateľov.

Pri horizontálnom škálovaní Weblate použite vyhradený uzol.

Databáza

Databázový server PostgreSQL na ukladanie všetkého obsahu, pozrite Nastavenie databázy pre Weblate.

Použite vyhradený databázový uzol pre stránky so stovkami miliónov hosťovaných slov.

Úložisko dát

Kľúč/hodnota úložisko, ako je server Valkey alebo Redis, pre vyrovnávaciu pamäť a frontu úloh, pozrite Úlohy na pozadí pomocou Celery.

Pri horizontálnom škálovaní Weblate použite vyhradený uzol.

Súborový systém

Úložisko súborového systému na ukladanie repozitárov VCS a nahraných používateľských dát. Toto je zdieľané všetkými procesmi.

Pri horizontálnom škálovaní Weblate použite sieťové úložisko.

E-mailový server

SMTP server pre odchádzajúcu poštu, pozrite Konfigurácia odchádzajúcej pošty. Môže byť poskytovaný externe.

Rada

Inštalácia pomocou Dockeru zahŕňa PostgreSQL a Valkey, čo uľahčuje inštaláciu.

Softvérové požiadavky¶

Operačný systém¶

Je známe, že Weblate funguje na Linuxe, FreeBSD a macOS. Iné systémy podobné Unixu budú s najväčšou pravdepodobnosťou fungovať tiež.

Weblate nie je podporovaný na Windowse. Ale môže stále fungovať a patche sú radi prijímané.

Viď aj

Prehľad architektúry popisuje celkovú architektúru Weblate a požadované služby.

Závislosti Pythonu¶

Weblate je napísaný v Pythone a podporuje Python 3.12 alebo novší. Závislosti môžete nainštalovať pomocou pip alebo z balíčkov vašej distribúcie, úplný zoznam je dostupný v requirements.txt.

Najvýznamnejšie závislosti:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Django REST Framework: https://www.django-rest-framework.org/

Voliteľné závislosti¶
Špecifikátor voliteľnej závislosti	Balíčky Pythonu	Funkcia Weblate
`amazon`	boto3 django-ses	Amazon Translate, AWS SES e-mail backend
`asgi`	granian	ASGI server pre Weblate
`gelf`	logging-gelf	Správa logov Graylog
`gerrit`	git-review	Gerrit recenzné požiadavky
`google`	google-cloud-storage google-cloud-translate	Google Cloud Translation Advanced s podporou slovníka
`google-errors`	google-cloud-error-reporting	Zhromažďovanie hlásení chýb a monitorovanie výkonu
`ldap`	django-auth-ldap	Autentifikácia LDAP
`mercurial`	mercurial	Mercurial
`postgres`	psycopg	PostgreSQL, pozrite Nastavenie databázy pre Weblate
`rollbar`	rollbar	Zhromažďovanie hlásení chýb a monitorovanie výkonu
`saml`	python3-saml xmlsec	Autentifikácia SAML
`saml2idp`	djangosaml2idp2	Integrácia SAML 2 IDP do Weblate
`sphinx`	Sphinx	Potrebné pre Aktualizovať súbor POT (Sphinx)
`wllegal`	wllegal	Integrácia Hosted Weblate
`wsgi`	granian	WSGI server pre Weblate
`zxcvbn`	django-zxcvbn-password-validator	Autentifikácia heslom

Pri inštalácii pomocou pip môžete priamo špecifikovať požadované funkcie pri inštalácii:

uv pip install "weblate[Postgres,Amazon,SAML]"

Alebo môžete nainštalovať Weblate so všetkými voliteľnými funkciami:

uv pip install "weblate[all]"

Alebo môžete nainštalovať Weblate bez akýchkoľvek voliteľných funkcií:

uv pip install weblate

Riešenie problémov s inštaláciou pip¶

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)

Toto je spôsobené nekompatibilitou binárnych balíčkov distribuovaných cez PyPI s distribúciou. Na vyriešenie tohto problému musíte balíček znovu zostaviť vo vašom systéme:

uv pip install --force-reinstall --no-binary :all: cffi

error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?

Toto je známy problém balíčka xmlsec, pozrite si https://github.com/xmlsec/python-xmlsec/issues/314.

lxml & xmlsec libxml2 library version mismatch

Balíčky lxml a xmlsec musia byť zostavené proti jednej libxml2. Mali by ste ich zostaviť lokálne, aby ste sa vyhli tomuto problému:

uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec

Iné systémové požiadavky¶

Nasledujúce závislosti musia byť nainštalované v systéme:

Git: https://git-scm.com/
git-review (voliteľné pre podporu Gerrit): git-review
git-svn (voliteľné pre podporu Subversion): https://git-scm.com/docs/git-svn
tesseract (potrebné iba ak nie sú pre váš systém dostupné binárne wheels tesserocr): https://github.com/tesseract-ocr/tesseract

Závislosti času zostavovania¶

Na zostavenie niektorých Závislosti Pythonu možno budete musieť nainštalovať ich závislosti. Závisí to od toho, ako ich inštalujete, preto sa prosím pozrite do dokumentácie jednotlivých balíčkov. Nebudete ich potrebovať, ak používate predpripravené Wheels pri inštalácii pomocou pip alebo ak používate balíčky distribúcie.

Hardvérové požiadavky¶

Weblate by mal bez problémov bežať na akomkoľvek súčasnom hardvéri, nasledujúca je minimálna konfigurácia potrebná na spustenie Weblate na jednom hostiteľovi (Weblate, databáza a webový server):

3 GB RAM
2 jadrá CPU
1 GB úložného priestoru

Poznámka

Skutočné požiadavky pre vašu inštaláciu Weblate sa výrazne líšia v závislosti od veľkosti prekladov v nej spravovaných.

Využitie pamäte¶

Čím viac pamäte, tým lepšie - používa sa na cacheovanie na všetkých úrovniach (súborový systém, databáza a Weblate). Pre stovky prekladových komponentov sa odporúča aspoň 4 GB RAM.

Rada

Pre systémy s menším množstvom pamäte, než sa odporúča, sa odporúča Nastavenie Celery s jedným procesom.

Využitie CPU¶

Veľa súbežných používateľov zvyšuje počet potrebných jadier CPU.

Využitie úložiska¶

Typické využitie úložiska databázy je okolo 300 MB na 1 milión hosťovaných slov.

Potrebný úložný priestor pre klonované repozitáre sa líši, ale Weblate sa snaží udržiavať ich veľkosť minimálnu pomocou plytkých klonov.

Výkon úložiska¶

Operácie správy verzií vykonávajú množstvo vyhľadávaní metadátových súborov. Podadresár vcs v DATA_DIR preto potrebuje nízku latenciu čítania; úložisko s pomalým prístupom k metadátam môže spôsobiť, že operácie ako git status budú trvať dlho, aj keď je jeho priepustnosť pre hromadné dáta dobrá. Ak je to možné, uchovávajte CACHE_DIR na lokálnom alebo dočasnom úložisku s nízkou latenciou.

Kontroly nasadenia merajú latenciu vyhľadávania metadát pre obe umiestnenia a varujú, ak medián latencie presiahne 10 milisekúnd. Ide o približné meranie v danom časovom bode ovplyvnené záťažou súborového systému a systému. Pred zmenou konfigurácie úložiska znova spustite weblate check --deploy.

Uzly¶

Pre malé a stredne veľké stránky (milióny hosťovaných slov) môžu byť všetky komponenty Weblate (pozrite Prehľad architektúry) spustené na jednom uzle.

Keď narastiete na stovky miliónov hosťovaných slov, odporúča sa mať vyhradený uzol pre databázu (pozrite Nastavenie databázy pre Weblate).

Overovanie artefaktov vydania¶

Archívy vydaní možno overiť pomocou podpisov, atestácií a SBOM zverejnených s assetmi vydania na GitHube. Pozrite Overovanie artefaktov vydania.

Oprávnenia súborového systému¶

Proces Weblate musí mať možnosť čítať a zapisovať do adresára, kde uchováva údaje - DATA_DIR. Všetky súbory v tomto adresári by mali byť vlastnené a zapisovateľné používateľom, ktorý spúšťa všetky procesy Weblate (zvyčajne WSGI a Celery, pozrite Spúšťanie servera a Úlohy na pozadí pomocou Celery).

Predvolená konfigurácia ich umiestňuje do rovnakej stromovej štruktúry ako zdrojové kódy Weblate, avšak môžete uprednostniť ich presun na lepšie umiestnenie, ako je: /var/lib/weblate.

Weblate sa pokúša vytvoriť tieto adresáre automaticky, ale zlyhá, ak nemá oprávnenie na ich vytvorenie.

Nakonfigurovaný CACHE_DIR musí byť tiež zapisovateľný procesom Weblate a musí umožňovať spúšťanie generovaných pomocných súborov. Nepripájajte CACHE_DIR s možnosťou noexec.

Mali by ste byť opatrní aj pri spúšťaní Manažérske príkazy, pretože by sa mali spúšťať pod tým istým používateľom, pod ktorým beží samotný Weblate, inak môžu byť nesprávne oprávnenia na niektoré súbory.

V kontajneri Docker musia byť všetky súbory v zväzku /app/data vlastnené používateľom weblate vo vnútri kontajnera (UID 1000).

Viď aj

Obsluha statických súborov

Nastavenie databázy pre Weblate¶

Odporúča sa spúšťať Weblate s databázovým serverom PostgreSQL.

Podporovaný je PostgreSQL 13 a vyšší. Odporúča sa PostgreSQL 15 alebo novší.

Viď aj

Databázové pripojenia¶

V predvolenej konfigurácii si každý proces Weblate udržiava trvalé pripojenie k databáze. Trvalé pripojenia zlepšujú odozvu Weblate, ale môžu vyžadovať viac zdrojov pre databázový server. Ďalšie informácie nájdete v CONN_MAX_AGE a Persistent connections.

Weblate potrebuje aspoň nasledujúci počet pripojení:

$(4 \times \mathit{nCPUs}) + 2$ pre procesy Celery
$\mathit{nCPUs} + 1$ pre pracovníkov WSGI

Toto platí pre predvolené hodnoty kontajnera Docker a príkladové konfigurácie uvedené v tejto dokumentácii, ale čísla sa zmenia, ak prispôsobíte počet pracovníkov WSGI alebo upravíte paralelizmus Celery.

Skutočný limit pre počet databázových pripojení musí byť vyšší, aby sa zohľadnili nasledujúce situácie:

Manažérske príkazy tiež potrebujú svoje pripojenie.
Ak je proces zabitý (napríklad OOM killerom), môže zablokovať existujúce pripojenie až do vypršania časového limitu.

Viď aj

Úlohy na pozadí pomocou Celery, Ukážková konfigurácia pre NGINX a uWSGI, WEBLATE_WORKERS

PostgreSQL¶

PostgreSQL je zvyčajne najlepšou voľbou pre stránky založené na Django. Je to referenčná databáza používaná na implementáciu databázovej vrstvy Django.

Poznámka

Weblate používa rozšírenie trigramov, ktoré musí byť v niektorých prípadoch inštalované samostatne. Hľadajte postgresql-contrib alebo podobne pomenovaný balíček.

Viď aj

PostgreSQL notes

Vytvorenie databázy v PostgreSQL¶

Zvyčajne je dobrý nápad spúšťať Weblate v samostatnej databáze a samostatnom používateľskom účte:

# 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

Rada

Ak nechcete, aby bol používateľ Weblate super používateľom v PostgreSQL, môžete to vynechať. V takom prípade budete musieť vykonať niektoré kroky migrácie manuálne ako super používateľ PostgreSQL v schéme, ktorú bude Weblate používať:

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS btree_gist;

Konfigurácia Weblate na použitie PostgreSQL¶

Úryvok settings.py pre 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,
    }
}

Migrácia databázy vykonáva ALTER ROLE na databázovej roli používanej Weblate. Vo väčšine prípadov sa názov roly zhoduje s používateľským menom. V zložitejších nastaveniach sa názov roly líši od používateľského mena a počas migrácie databázy dostanete chybu o neexistujúcej roli (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Je známe, že sa to deje s Azure Database for PostgreSQL, ale nie je to obmedzené len na toto prostredie. Prosím, nastavte ALTER_ROLE na zmenu názvu roly, ktorú by mal Weblate počas migrácie databázy upraviť.

Viď aj

Databázové pripojenia

Iné konfigurácie¶

Konfigurácia odchádzajúcej pošty¶

Weblate odosiela e-maily pri rôznych príležitostiach - pre aktiváciu účtu a pri rôznych upozorneniach nakonfigurovaných používateľmi. Na to potrebuje prístup k SMTP serveru.

Nastavenie poštového servera je nakonfigurované pomocou týchto nastavení: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER a EMAIL_PORT. Ich názvy sú celkom samovysvetľujúce, ale ďalšie informácie nájdete v dokumentácii Django.

Rada

Ak dostanete chybu o nepodporovanej autentifikácii (napríklad SMTP AUTH extension not supported by server), je to s najväčšou pravdepodobnosťou spôsobené použitím nezabezpečeného pripojenia a server odmieta týmto spôsobom autentifikovať. V takom prípade skúste povoliť EMAIL_USE_TLS.

Viď aj

Beh za reverzným proxy¶

Niekoré funkcie vo Weblate závisia od správneho odovzdávania HTTP hlavičiek do Weblate. Pri používaní reverzného proxy servera sa uistite, že potrebné informácie sú správne odovzdané.

Na ladenie tejto konfigurácie sa môžete pozrieť na HTTP prostredie v Výkonnostná správa.

IP adresa klienta

Toto je potrebné pre Obmedzovanie rýchlosti alebo Audítorský protokol.

Weblate analyzuje IP adresu z REMOTE_ADDR, ktorú nastavuje obsluha WSGI. Toto môže byť prázdne (pri používaní soketu pre WSGI) alebo obsahovať adresu reverzného proxy servera, takže Weblate potrebuje dodatočnú HTTP hlavičku s IP adresou klienta.

Povolenie IP_BEHIND_REVERSE_PROXY by malo stačiť pre väčšinu bežných nastavení, ale možno budete musieť upraviť aj IP_PROXY_HEADER a IP_PROXY_OFFSET (použite WEBLATE_IP_PROXY_HEADER a WEBLATE_IP_PROXY_OFFSET v kontajneri Docker).

Reverzný proxy server, ktorý sa pripája k Weblate, musí prepísať nakonfigurovanú hlavičku alebo pripojiť overenú adresu partnera na pozícii vybranej pomocou IP_PROXY_OFFSET. Nevyberajte adresu dodanú klientom a nevystavujte aplikačný server cez cestu, ktorá obchádza dôveryhodný proxy server.

Pri používaní X-Forwarded-For s kontajnerom Docker nakonfigurujte WEBLATE_TRUSTED_PROXY_ADDRESSES s reverznými proxy servermi, ktorým je povolené dodávať adresy klientov.

Rada

Túto konfiguráciu nie je možné zapnúť predvolene, pretože by umožňovala falšovanie IP adries na inštaláciách, ktoré nemajú správne nakonfigurovaný reverzný proxy server.

Názov hostiteľa servera

Hlavička Host by mala zodpovedať tomu, čo je nakonfigurované ako SITE_DOMAIN. Vo vašom reverznom proxy serveri môže byť potrebná dodatočná konfigurácia (napríklad použite ProxyPreserveHost On pre Apache alebo proxy_set_header Host $host; pre nginx).

Rada

Chyby overenia CSRF sú často spôsobené nezhodou medzi hlavičkou Host a nakonfigurovaným SITE_DOMAIN.

Protokol klienta

Neposkytnutie správneho protokolu môže spôsobiť, že sa Weblate dostane do slučky presmerovania pri pokuse o upgrade klienta na HTTPS. Uistite sa, že je správne exponovaný reverzným proxy serverom ako X-Forwarded-Proto.

Túto hlavičku je potom potrebné nakonfigurovať v SECURE_PROXY_SSL_HEADER (settings.py) alebo WEBLATE_SECURE_PROXY_SSL_HEADER (prostredie Docker).

Dôležité

Hodnota hlavičky rozlišuje veľké a malé písmená v konfigurácii, takže WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,https a WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPS nie sú vzájomne zameniteľné.

Rada

Ak dostávate chybu „Príliš veľa presmerovaní“ z prehliadača, je to s najväčšou pravdepodobnosťou spôsobené nezhodou medzi skutočným protokolom (HTTPS) a tým, čo pozoruje Weblate.

Zmenené vo verzii 5.13: Hlavičky protokolu proxy sú v predvolenej konfigurácii automaticky spracovávané programom gunicorn, ale iné servery WSGI majú bezpečnejšiu konfiguráciu a vyžadujú si ich explicitné nastavenie.

Od verzie Weblate 5.13 používa kontajner Docker granian a teraz vyžaduje explicitnú konfiguráciu WEBLATE_SECURE_PROXY_SSL_HEADER.

Viď aj

HTTP proxy¶

Weblate podporuje konfiguráciu HTTP proxy pre jednotlivé protokoly pre odchádzajúce HTTP požiadavky a repozitáre Git. Definujte premenné prostredia proxy v settings.py:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["https_proxy"] = "http://proxy.example.com:8080"

Podporované sú iba http_proxy a https_proxy. Všeobecné premenné a premenné na obchádzanie, ako napríklad all_proxy a no_proxy, konfigurácia proxy operačného systému a konfigurácia proxy špecifická pre VCS nie sú podporované.

Viď aj

Premenné prostredia proxy

Úprava konfigurácie¶

Viď aj

Vzorová konfigurácia

Skopírujte weblate/settings_example.py do weblate/settings.py a upravte ho tak, aby zodpovedal vášmu nastaveniu. Pravdepodobne budete chcieť upraviť nasledujúce možnosti:

ADMINS

Zoznam administrátorov stránky, ktorí majú dostávať upozornenia, keď sa niečo pokazí, napríklad upozornenia na neúspešné zlúčenia alebo chyby Django.

Kontaktný formulár posiela e-maily aj na tieto adresy, pokiaľ nie je nakonfigurované ADMINS_CONTACT.

Viď aj

ADMINS

ADMINS_CONTACT

Správne nakonfigurovať administrátorov

ALLOWED_HOSTS

Toto musíte nastaviť na zoznam hostiteľov, ktorých má vaša stránka obsluhovať. Napríklad:
ALLOWED_HOSTS = ["demo.weblate.org"]
Prípadne môžete zahrnúť zástupný znak:
ALLOWED_HOSTS = ["*"]
Viď aj

ALLOWED_HOSTS

WEBLATE_ALLOWED_HOSTS

Nastavenie povolených hostiteľov

SESSION_ENGINE

Nakonfigurujte spôsob ukladania relácií. V prípade, že ponecháte predvolený backend databázy, mali by ste naplánovať: weblate clearsessions na odstránenie zastaraných údajov relácií z databázy.

Ak používate Valkey alebo Redis ako vyrovnávaciu pamäť (pozri Konfigurovať vyrovnávaciu pamäť), odporúča sa použiť ju aj pre relácie:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
Viď aj

Configuring the session engine

SESSION_ENGINE

DATABASES

Pripojenie k databázovému serveru, podrobnosti nájdete v dokumentácii Django.

Viď aj

Nastavenie databázy pre Weblate

DATABASES

Databases

DEBUG

Toto vypnite pre každý produkčný server. So zapnutým režimom ladenia bude Django zobrazovať spätné stopy v prípade chyby používateľom, keď ho vypnete, chyby budú odoslané e-mailom na ADMINS (pozri vyššie).

Režim ladenia tiež spomaľuje Weblate, pretože Django v tomto prípade interne uchováva oveľa viac informácií.

Viď aj

DEBUG

Vypnúť režim ladenia

DEFAULT_FROM_EMAIL

Adresa odosielateľa e-mailu pre odchádzajúce e-maily, napríklad registračné e-maily.

Viď aj

DEFAULT_FROM_EMAIL

SECRET_KEY

Kľúč používaný Django na podpisovanie niektorých informácií v cookies, viac informácií nájdete v Tajný kľúč Django.

Viď aj

SECRET_KEY

SERVER_EMAIL

E-mail použitý ako adresa odosielateľa pre odosielanie e-mailov administrátorovi, napríklad upozornenia na neúspešné zlúčenia.

Viď aj

SERVER_EMAIL

Naplnenie databázy¶

Po dokončení konfigurácie môžete spustiť migrate na vytvorenie štruktúry databázy. Teraz by ste mali byť schopní vytvárať prekladové projekty pomocou administrátorského rozhrania.

Po dokončení by ste mali skontrolovať aj Správu o výkone v administrátorskom rozhraní, ktorá vám poskytne nápovedy týkajúce sa potenciálne neoptimálnej konfigurácie na vašej stránke.

Viď aj

Produkčné nastavenie¶

Pre produkčné nastavenie by ste mali vykonať úpravy opísané v nasledujúcich sekciách. Najkritickejšie nastavenia spustia varovanie, ktoré je indikované výkričníkom v hornom paneli, ak ste prihlásení ako super používateľ:

Odporúča sa tiež skontrolovať kontroly spustené Django (hoci nemusíte opraviť všetky z nich):

weblate check --deploy

Rovnaký kontrolný zoznam si môžete prezrieť aj v Výkonnostná správa v Rozhranie na správu.

Viď aj

Deployment checklist

Vypnúť režim ladenia¶

Vypnite režim ladenia Django (DEBUG) pomocou:

DEBUG = False

Pri zapnutom režime ladenia Django ukladá všetky vykonané dotazy a zobrazuje používateľom spätné stopy chýb, čo nie je žiaduce v produkčnom nastavení.

Viď aj

Úprava konfigurácie

Správne nakonfigurovať administrátorov¶

Nastavte správne adresy administrátorov v nastavení ADMINS, aby ste určili, kto bude dostávať e-maily v prípade, že sa na serveri niečo pokazí, napríklad:

ADMINS = ("Your Name <your_email@example.com>",)

Viď aj

Úprava konfigurácie

Nastaviť správnu doménu stránky¶

Upravte názov a doménu stránky v administrátorskom rozhraní, inak odkazy v RSS alebo registračných e-mailoch nebudú fungovať. Toto sa konfiguruje pomocou SITE_DOMAIN, ktorý by mal obsahovať názov domény stránky.

Zmenené vo verzii 4.2: Pred vydaním 4.2 sa namiesto toho používal framework Django sites, pozrite si The “sites” framework.

Viď aj

Správne nakonfigurovať HTTPS¶

Dôrazne sa odporúča prevádzkovať Weblate pomocou šifrovaného protokolu HTTPS. Po jeho povolení by ste mali nastaviť ENABLE_HTTPS v nastaveniach:

ENABLE_HTTPS = True

Rada

Možno budete chcieť nastaviť aj HSTS, viac podrobností nájdete v SSL/HTTPS.

Viď aj

ENABLE_HTTPS
Nastavenie povolených hostiteľov
Nastaviť správnu doménu stránky

Správne nastaviť SECURE_HSTS_SECONDS¶

Ak je vaša stránka obsluhovaná cez SSL, mali by ste zvážiť nastavenie hodnoty pre SECURE_HSTS_SECONDS v settings.py na povolenie HTTP Strict Transport Security. Predvolene je nastavená na 0, ako je uvedené nižšie.

SECURE_HSTS_SECONDS = 0

Ak je nastavená na nenulovú celočíselnú hodnotu, django.middleware.security.SecurityMiddleware nastaví hlavičku HTTP Strict Transport Security na všetkých odpovediach, ktoré ju ešte nemajú.

Varovanie

Nesprávne nastavenie môže nenávratne (na určitý čas) poškodiť vašu stránku. Najprv si prečítajte dokumentáciu HTTP Strict Transport Security.

Použiť výkonný databázový engine¶

Pre produkčné prostredie použite PostgreSQL, viac informácií nájdete v Nastavenie databázy pre Weblate.
Spúšťajte databázový server na rovnakom mieste, inak môže výkon siete alebo spoľahlivosť pokaziť váš zážitok z Weblate.
Skontrolujte výkon databázového servera alebo vylaďte jeho konfiguráciu, napríklad pomocou PGTune.
Kontroly nasadenia Weblate hlásia neúplné štatistiky relácií PostgreSQL. Spustite ANALYZE na nahlásených reláciách na obnovenie poškodených štatistík.

Viď aj

Konfigurovať vyrovnávaciu pamäť¶

Ak je to možné, používajte Valkey alebo Redis z Django úpravou konfiguračnej premennej CACHES, napríklad:

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",
        },
    }
}

Rada

V prípade, že zmeníte nastavenia pre vyrovnávaciu pamäť, možno budete musieť upraviť aj nastavenia pre Celery, pozri Úlohy na pozadí pomocou Celery.

Viď aj

Ukladanie avatarov do vyrovnávacej pamäte
Django’s cache framework

Ukladanie avatarov do vyrovnávacej pamäte¶

Okrem ukladania do vyrovnávacej pamäte Django vykonáva Weblate aj ukladanie avatarov do vyrovnávacej pamäte. Na tento účel sa odporúča použiť samostatnú vyrovnávaciu pamäť založenú na súboroch:

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,
        },
    },
}

Viď aj

Konfigurovať odosielanie e-mailov¶

Weblate potrebuje odosielať e-maily pri niekoľkých príležitostiach a tieto e-maily by mali mať správnu adresu odosielateľa, prosím nakonfigurujte SERVER_EMAIL a DEFAULT_FROM_EMAIL tak, aby zodpovedali vášmu prostrediu, napríklad:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Poznámka

Na vypnutie odosielania e-mailov Weblate nastavte EMAIL_BACKEND na django.core.mail.backends.dummy.EmailBackend.

Toto vypne všetko doručovanie e-mailov vrátane registračných e-mailov alebo e-mailov na resetovanie hesla.

Viď aj

Nastavenie povolených hostiteľov¶

Django vyžaduje, aby ALLOWED_HOSTS obsahoval zoznam názvov domén, ktoré môže vaša stránka obsluhovať, ponechanie prázdneho zablokuje akékoľvek požiadavky.

V prípade, že toto nie je nakonfigurované tak, aby zodpovedalo vášmu HTTP serveru, dostanete chyby ako Neplatná hlavička HTTP_HOST: '1.1.1.1'. Možno budete musieť pridať '1.1.1.1' do ALLOWED_HOSTS.

Rada

V kontajneri Docker je toto dostupné ako WEBLATE_ALLOWED_HOSTS.

Viď aj

ALLOWED_HOSTS
WEBLATE_ALLOWED_HOSTS
Nastaviť správnu doménu stránky

Tajný kľúč Django¶

Nastavenie SECRET_KEY používa Django na podpisovanie cookies a mali by ste skutočne vygenerovať vlastnú hodnotu, namiesto používania tej z ukážkového nastavenia.

Nový kľúč môžete vygenerovať pomocou weblate-generate-secret-key, ktorý je súčasťou Weblate.

Viď aj

SECRET_KEY

Spúšťanie úloh údržby¶

Pre optimálny výkon je dobré spúšťať niektoré úlohy údržby na pozadí. Toto sa automaticky vykonáva pomocou Úlohy na pozadí pomocou Celery a pokrýva nasledujúce úlohy:

Kontrola stavu konfigurácie (každú hodinu).
Zapisovanie čakajúcich zmien (každú hodinu), pozri Lenivé zápisy a commit_pending.
Aktualizácia upozornení komponentov (denne).
Aktualizácia vzdialených vetiev (nocou), pozri AUTO_UPDATE.
Záloha prekladovej pamäte do JSON (denne), pozri dump_memory.
Úlohy údržby fulltextu a databázy (denné a týždenné úlohy), pozri cleanuptrans.

Systémové lokály a kódovanie¶

Systémové lokály by mali byť nakonfigurované na také, ktoré podporujú UTF-8. Na väčšine distribúcií Linuxu je toto predvolené nastavenie. V prípade, že tomu tak na vašom systéme nie je, prosím, zmeňte lokály na variant UTF-8.

Napríklad úpravou /etc/default/locale a nastavením LANG="C.UTF-8".

V niektorých prípadoch majú jednotlivé služby samostatnú konfiguráciu pre lokály. Tá sa líši medzi distribúciami a webovými servermi, preto si skontrolujte dokumentáciu balíčkov vášho webového servera.

Apache na Ubuntu používa /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Apache na CentOS používa /etc/sysconfig/httpd (alebo /opt/rh/httpd24/root/etc/sysconfig/httpd):

LANG='en_US.UTF-8'

Používanie vlastnej certifikačnej autority¶

Weblate overuje certifikáty SSL počas požiadaviek HTTP. Požiadavky vykonávané pomocou HTTPX2 používajú systémové úložisko certifikátov, preto tam nainštalujte vlastné certifikačné autority.

Podrobnejšie informácie nájdete v dokumentácii vašej distribúcie. Napríklad v systéme Debian to možno urobiť umiestnením certifikátu CA do /usr/local/share/ca-certificates/ a spustením update-ca-certificates.

Rada

Kontajner Weblate ho nezahŕňa do cesty vyhľadávania, musíte zadať celú cestu na jeho spustenie. Napríklad:

docker compose exec -u root weblate /usr/sbin/update-ca-certificates

Po vykonaní tohto kroku budú požiadavky Weblate HTTPX2 a systémové nástroje vrátane Git dôverovať certifikátu.

Niektoré integrácie, vrátane autentifikácie OAuth a OpenID Connect, používajú Requests, ktoré predvolene nepoužívajú systémové úložisko certifikátov. Keď tieto integrácie komunikujú so službami používajúcimi vlastnú certifikačnú autoritu, nakonfigurujte Requests na použitie systémového balíka CA pridaním nasledujúceho do settings.py (cesta je špecifická pre Debian):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

Spúšťanie servera¶

Rada

V prípade, že nemáte skúsenosti s nižšie popísanými službami, môžete vyskúšať Inštalácia pomocou Dockeru.

Na spustenie Weblate budete potrebovať niekoľko služieb, odporúčané nastavenie pozostáva z:

Databázový server (pozri Nastavenie databázy pre Weblate)
Server vyrovnávacej pamäte (pozri Konfigurovať vyrovnávaciu pamäť)
Frontendový webový server pre statické súbory a ukončenie SSL (pozri Obsluha statických súborov)
WSGI server pre dynamický obsah (pozri Ukážková konfigurácia pre NGINX a uWSGI)
Celery na vykonávanie úloh na pozadí (pozri Úlohy na pozadí pomocou Celery)

Poznámka

Medzi službami existujú určité závislosti, napríklad vyrovnávacia pamäť a databáza by mali bežať pri spúšťaní procesov Celery alebo uwsgi.

Vo väčšine prípadov budete spúšťať všetky služby na jednom (virtuálnom) serveri, ale v prípade, že je vaša inštalácia silne zaťažená, môžete služby rozdeliť. Jediným obmedzením je, že servery Celery a Wsgi potrebujú prístup k DATA_DIR.

Poznámka

Proces WSGI sa musí vykonávať pod tým istým používateľom ako proces Celery, inak budú súbory v DATA_DIR ukladané so zmiešaným vlastníctvom, čo povedie k problémom za behu.

Pozrite si aj Oprávnenia súborového systému a Úlohy na pozadí pomocou Celery.

Spúšťanie webového servera¶

Spúšťanie Weblate sa nelíši od spúšťania akéhokoľvek iného programu založeného na Django. Django sa zvyčajne vykonáva ako WSGI alebo fcgi (pozri príklady pre rôzne webové servery nižšie).

Poznámka

Ukážkové konfiguračné súbory uvedené nižšie sú udržiavané v zdrojovom strome Weblate pod weblate/examples/. Sú zahrnuté v zdrojových distribúciách a v tejto dokumentácii, ale Python wheels inštalujú iba súbory behového prostredia. Pri inštalácii Weblate z PyPI si pred kopírovaním týchto príkladov získajte zodpovedajúcu zdrojovú distribúciu alebo zdrojový kód.

Na testovacie účely môžete použiť vstavaný webový server v Django:

weblate runserver

Varovanie

NEPOUŽÍVAJTE TENTO SERVER V PRODUKČNOM PROSTREDÍ. Neprešiel bezpečnostnými auditmi ani testami výkonu. Pozrite si aj dokumentáciu Django o runserver.

Rada

Vstavaný server Django obsluhuje statické súbory iba so zapnutým DEBUG, pretože je určený len na vývoj. Pre produkčné použitie pozrite nastavenia WSGI:

Ukážková konfigurácia pre NGINX a Granian
Ukážková konfigurácia pre NGINX a Gunicorn
Ukážková konfigurácia pre NGINX a uWSGI
Ukážková konfigurácia pre Apache
Ukážková konfigurácia pre Apache a Gunicorn
Obsluha statických súborov

Obsluha statických súborov¶

Zmenené vo verzii 5.15.2: /media/ sa už nepoužíva na obsluhu snímok obrazovky.

Django potrebuje zhromaždiť svoje statické súbory v jednom adresári. Vykonajte to príkazom weblate collectstatic --noinput. Tým sa statické súbory skopírujú do adresára určeného nastavením STATIC_ROOT (predvolene je to adresár static v rámci CACHE_DIR). Produkčné inštalácie používajú v názvoch zhromaždených súborov hash obsahu, aby aktualizované prostriedky nepoužívali zastarané vyrovnávacie pamäte prehliadača alebo proxy.

Odporúča sa obsluhovať statické súbory priamo z vášho webového servera, mali by ste to použiť pre nasledujúce cesty:

/static/: Obsluhuje statické súbory pre Weblate a administrátorské rozhranie (z definície STATIC_ROOT).
/favicon.ico: Malo by byť prepísané tak, aby obsluhovalo /static/favicon.ico.

Viď aj

Ukážková konfigurácia pre NGINX a Granian
Ukážková konfigurácia pre NGINX a Gunicorn
Ukážková konfigurácia pre NGINX a uWSGI
Ukážková konfigurácia pre Apache
Ukážková konfigurácia pre Apache a Gunicorn
How to deploy Django
How to deploy static files

Zásady zabezpečenia obsahu¶

Predvolená konfigurácia Weblate povoľuje middleware weblate.middleware.SecurityMiddleware, ktorý nastavuje bezpečnostné HTTP hlavičky ako Content-Security-Policy alebo X-XSS-Protection. Tieto sú predvolene nastavené tak, aby fungovali s Weblate a jeho konfiguráciou, ale môžu vyžadovať prispôsobenie pre vaše prostredie.

Viď aj

Ukážková konfigurácia pre NGINX a Granian¶

Nasledujúca konfigurácia spúšťa Weblate pomocou Granian s webovým serverom NGINX:

weblate/examples/weblate.nginx.granian.conf¶

#
# 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;
    }
}

Viď aj

Ukážková konfigurácia pre NGINX a Gunicorn¶

Nasledujúca konfigurácia spúšťa Weblate pomocou Gunicorn pod webovým serverom NGINX (weblate/examples/weblate.nginx.gunicorn.conf v zdrojovom strome):

#
# 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;
    }
}

Viď aj

Ukážková konfigurácia na spustenie Gunicorn
How to use Django with Gunicorn

Ukážková konfigurácia pre NGINX a uWSGI¶

Na spustenie produkčného webového servera použite wrapper WSGI nainštalovaný s Weblate (pri používaní prostredia Python je nainštalovaný ako ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Nezabudnite nastaviť aj cestu vyhľadávania Python pre vaše prostredie Python (napríklad pomocou virtualenv = /home/user/weblate-env v uWSGI).

Nasledujúca konfigurácia spúšťa Weblate ako uWSGI pod webovým serverom NGINX.

Konfigurácia pre NGINX (weblate/examples/weblate.nginx.conf v zdrojovom strome):

#
# 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;
    }
}

Konfigurácia pre uWSGI (weblate/examples/weblate.uwsgi.ini v zdrojovom strome):

#
# 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

# Set sys.executable so Python helpers run with the virtual environment's Python
py-executable = /home/weblate/weblate-env/bin/python

# 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

Set py-executable to the absolute path of bin/python inside the environment configured by virtualenv. Weblate uses Python’s sys.executable to launch helper processes, including the SSH connection proxy used for Git repositories. uWSGI can otherwise set this value to its own executable, causing repository operations to fail with an error such as /usr/bin/uwsgi-core: invalid option -- 'I'. Setting virtualenv alone does not ensure that sys.executable points to Python. Restart uWSGI after updating the configuration.

Viď aj

How to use Django with uWSGI

Ukážková konfigurácia pre Apache¶

Odporúča sa používať prefork MPM pri používaní WSGI s Weblate.

Nasledujúca konfigurácia spúšťa Weblate ako WSGI, musíte mať povolený mod_wsgi (weblate/examples/apache.conf v zdrojovom strome):

#
# 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>

Poznámka

Weblate vyžaduje Python 3, preto sa uistite, že používate variant modwsgi pre Python 3. Zvyčajne je dostupný ako samostatný balík, napríklad libapache2-mod-wsgi-py3.

Na inštaláciu Weblate použite zodpovedajúcu verziu Python.

Viď aj

Ukážková konfigurácia pre Apache a Gunicorn¶

Nasledujúca konfigurácia spúšťa Weblate v Gunicorn a Apache 2.4 (weblate/examples/apache.gunicorn.conf v zdrojovom strome):

#
# 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>

Viď aj

Ukážková konfigurácia na spustenie Gunicorn
How to use Django with Gunicorn

Ukážková konfigurácia na spustenie Granian¶

Weblate má voliteľnú závislosť wsgi (pozrite Závislosti Pythonu), ktorá nainštaluje všetko potrebné na spustenie Granian. Pri inštalácii Weblate ju môžete špecifikovať ako:

uv pip install Weblate[all,wsgi]

Po nainštalovaní Granian ho môžete spustiť. Zvyčajne sa to robí na systémovej úrovni. Nasledujúce príklady ukazujú spustenie cez systemd:

/etc/systemd/system/granian.service¶

[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 450 \
    --interface wsgi \
    --workers 2 \
    --blocking-threads 8 \
    --backlog 128 \
    --backpressure 16 \
    --runtime-mode mt \
    --port 8888 \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

Granian používa pracovné procesy na paralelné vykonávanie Pythonu, blokujúce vlákna na súbežné požiadavky WSGI a runtime vlákna na sieťový vstup/výstup. Ukážka používa dvoch pracovníkov s ôsmimi blokujúcimi vláknami každý, obmedzuje každého pracovníka na 16 súbežných pripojení a ponecháva runtime vlákna na predvolenej hodnote Granian. Prispôsobte počet pracovníkov a blokujúcich vlákien dostupnej pamäti, počtu jadier CPU a limitu databázových pripojení. Ponechajte backpressure rovnaký alebo vyšší ako počet blokujúcich vlákien.

Viď aj

Ukážková konfigurácia na spustenie Granian s ASGI¶

Added in version 2026.8.

Nasadenie ASGI je dostupné ako voliteľná alternatíva k WSGI. Nainštalujte voliteľnú závislosť asgi:

uv pip install Weblate[all,asgi]

Nasledujúca jednotka systemd spúšťa aplikáciu Django ASGI:

/etc/systemd/system/granian-asgi.service¶

[Unit]
Description=granian ASGI 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 450 \
    --interface asginl \
    --workers 2 \
    --backlog 128 \
    --backpressure 16 \
    --runtime-mode mt \
    --port 8888 \
    weblate.asgi:application

[Install]
WantedBy=multi-user.target

Ukážka používa ASGI rozhranie Granian bez podpory lifespan alebo WebSocket, pretože Weblate momentálne vystavuje iba HTTP. Middleware Weblate podporuje oba režimy nasadenia a používa vlákno-citlivé adaptéry tam, kde sa stále spolieha na synchrónne Django API. Kontrola zdravia je asynchrónna, ale väčšina pohľadov Weblate zostáva synchrónna a CPU-náročné alebo dlho trvajúce úlohy by mali byť stále spracovávané pomocou Úlohy na pozadí pomocou Celery.

WSGI zostáva predvoleným režimom nasadenia. Docker obrazy sa môžu prihlásiť na ASGI nastavením WEBLATE_ASGI na 1. Prispôsobte počet pracovníkov a backpressure dostupnej pamäti, počtu jadier CPU a limitu databázových pripojení.

Viď aj

Ukážková konfigurácia na spustenie Gunicorn¶

Gunicorn sa musí nainštalovať samostatne:

uv pip install gunicorn

Po nainštalovaní Gunicorn ho môžete spustiť. Toto sa zvyčajne robí na systémovej úrovni. Nasledujúce príklady ukazujú spúšťanie cez systemd:

/etc/systemd/system/gunicorn.socket¶

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

/etc/systemd/system/gunicorn.service¶

[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

Viď aj

How to use Django with Gunicorn

Spúšťanie Weblate pod cestou¶

Odporúča sa používať prefork MPM pri používaní WSGI s Weblate.

Ukážková konfigurácia Apache na poskytovanie Weblate pod /weblate. Opäť s použitím mod_wsgi (weblate/examples/apache-path.conf v zdrojovom strome):

#
# 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>

Dodatočne budete musieť upraviť weblate/settings.py:

URL_PREFIX = "/weblate"

Úlohy na pozadí pomocou Celery¶

Weblate používa Celery na vykonávanie pravidelných úloh a úloh na pozadí. Mali by ste spustiť službu Celery, ktorá ich bude vykonávať. Napríklad je zodpovedná za spracovanie nasledujúcich operácií (tento zoznam nie je úplný):

Prijímanie webhookov z externých služieb (pozri Háky notifikácií).
Spúšťanie pravidelných úloh údržby, ako sú zálohy, čistenia, denné doplnky alebo aktualizácie (pozri Zálohovanie a presun Weblate, BACKGROUND_TASKS, Doplnky).
Spúšťanie Automatický preklad.
Odosielanie súhrnných upozornení.
Vykladanie náročných operácií z procesu WSGI.
Zapisovanie čakajúcich zmien (pozri Lenivé zápisy).

Typické nastavenie používajúce Valkey alebo Redis ako backend vyzerá takto:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

Viď aj

Konfigurácia brokera Redis v Celery

Mali by ste tiež spustiť pracovníka Celery na spracovanie úloh a spustenie naplánovaných úloh. Pre ladenie alebo vývoj to možno urobiť priamo z príkazového riadku:

celery --app=weblate.utils worker --beat \
    --queues=celery,notify,memory,translate,backup \
    --prefetch-multiplier=1

Running all queues in one prefork worker shares the initial application memory between its child processes while retaining parallel task execution. Celery determines the concurrency from the number of available CPUs by default; use --concurrency to adjust it for your workload and available memory.

Na zníženie využitia pamäte pri štarte pracovníci Celery neopakujú systémové kontroly Django. Kontajner Weblate spúšťa komplexnejší príkaz weblate check --deploy automaticky počas štartu kontajnera. Pre iné metódy inštalácie spustite príkaz po inštalácii, aktualizáciách alebo zmenách konfigurácie. Kontroly sú tiež dostupné v rozhraní na správu.

Poznámka

Proces Celery sa musí vykonávať pod tým istým používateľom ako proces WSGI, inak budú súbory v DATA_DIR ukladané so zmiešaným vlastníctvom, čo povedie k problémom za behu.

Pozrite si aj Oprávnenia súborového systému a Spúšťanie servera.

Vykonávanie úloh Celery vo WSGI pomocou eager režimu¶

Poznámka

Toto bude mať vážny vplyv na výkon webového rozhrania a pokazí funkcie závislé od pravidelného spúšťania (napríklad zapisovanie čakajúcich zmien, súhrnné upozornenia alebo zálohy).

Pre vývoj môžete chcieť použiť eager konfiguráciu, ktorá spracováva všetky úlohy na mieste:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

Spúšťanie Celery ako systémovej služby¶

S najväčšou pravdepodobnosťou budete chcieť spustiť Celery ako démona, čo je popísané v Daemonization. Pre najbežnejšie nastavenie Linuxu pomocou systemd upravte nižšie uvedené ukážkové súbory. Tieto príklady sú udržiavané v zdrojovom strome Weblate pod weblate/examples/; Python wheels tieto ukážky nasadenia neinštalujú.

Jednotka systemd umiestnená ako /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

Konfigurácia prostredia umiestnená ako /etc/default/celery-weblate:

# Name of nodes to start
CELERYD_NODES="combined"

# 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. Celery determines concurrency
# from the number of available CPUs by default. You might need to customize it
# depending on the available resources and Weblate usage. Increase concurrency
# if you get weblate.E019 error, decrease it on a low-resource system.
# Command-line values override corresponding Celery settings in settings.py.
CELERYD_OPTS="--beat:combined --queues:combined=celery,notify,memory,translate,backup --prefetch-multiplier:combined=1"

# 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"

Dodatočná konfigurácia na rotáciu logov Celery pomocou logrotate umiestnená ako /etc/logrotate.d/celery:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Periodické úlohy pomocou Celery beat¶

Weblate prichádza s vstavaným nastavením pre naplánované úlohy. Plán úloh je uložený v databáze a úlohy sú vykonávané démonom Celery beat.

Rada

Môžete definovať ďalšie úlohy v settings.py, napríklad pozri Lenivé zápisy.

Monitorovanie stavu Celery¶

Aktuálnu dĺžku frontov úloh Celery nájdete v Rozhranie na správu alebo môžete použiť celery_queues na príkazovom riadku. V prípade, že sa front stane príliš dlhým, dostanete aj chybu konfigurácie v administrátorskom rozhraní.

Varovanie

Chyby Celery sú predvolene logované iba do logu Celery a nie sú viditeľné pre používateľa. V prípade, že chcete mať prehľad o takýchto zlyhaniach, odporúča sa nakonfigurovať Zhromažďovanie hlásení chýb a monitorovanie výkonu.

Viď aj

Nastavenie Celery s jedným procesom¶

V prípade, že máte veľmi obmedzenú pamäť, môžete chcieť znížiť počet procesov Weblate. Všetky úlohy Celery môžu byť vykonávané v jednom procese pomocou:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

An installation using Docker can be configured to use a single-process Celery setup by setting CELERY_WORKER_MODE=single. See CELERY_WORKER_MODE.

Varovanie

Toto bude mať citeľný vplyv na výkon Weblate.

Monitorovanie Weblate¶

Weblate poskytuje URL /healthz/ na použitie v jednoduchých kontrolách stavu, napríklad pomocou Kubernetes. Kontajner Docker má vstavanú kontrolu stavu používajúcu túto URL.

Na monitorovanie metrík Weblate môžete použiť koncový bod API GET /api/metrics/. Monitorovacie nástroje bežiace lokálne môžu získať rovnaké metriky pomocou príkazu metrics.

Viď aj

Zhromažďovanie hlásení chýb a monitorovanie výkonu¶

Weblate, ako akýkoľvek iný softvér, môže zlyhať. Na zhromažďovanie užitočných stavov zlyhania odporúčame používať služby tretích strán na zhromažďovanie takýchto informácií. Toto je obzvlášť užitočné v prípade zlyhávajúcich úloh Celery, ktoré by inak hlásili chyby iba do logov a vy by ste o nich neboli upozornení. Weblate má podporu pre nasledujúce služby:

E-mail¶

Predvolená konfigurácia Weblate inštrumentuje Django na odosielanie e-mailov pri chybách servera cez django.utils.log.AdminEmailHandler. Toto je nastavenie s najmenším úsilím, ale mali by ste zvážiť iné možnosti z dôvodu ochrany súkromia, keďže e-maily s chybami môžu obsahovať citlivé údaje. Viac si o tom môžete prečítať v Security implications.

Na vypnutie tohto správania odstráňte mail_admins z LOGGING v nastaveniach Weblate alebo vypnite WEBLATE_ADMIN_NOTIFY_ERROR v prostredí Docker.

Sentry¶

Weblate má vstavanú podporu pre Sentry. Na jeho použitie stačí nastaviť SENTRY_DSN v settings.py:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Sentry sa dá použiť aj na monitorovanie výkonu Weblate zbieraním stôp a profilov pre definované percento operácií. Toto sa dá nakonfigurovať pomocou SENTRY_TRACES_SAMPLE_RATE a SENTRY_PROFILES_SAMPLE_RATE.

Viď aj

Google Cloud Error Reporting¶

Weblate môže hlásiť spracované chyby servera do Google Cloud Error Reporting. Nainštalujte Weblate s voliteľným balíkom google-errors a nakonfigurujte GOOGLE_CLOUD_ERROR_REPORTING v settings.py:

GOOGLE_CLOUD_ERROR_REPORTING = {
    "project": "your-google-cloud-project",
}

Weblate automaticky hlási chyby pod službou weblate a ako nahlásenú verziu používa aktuálnu verziu Weblate alebo revíziu Git. Tieto hodnoty možno prepísať nastavením service alebo version v GOOGLE_CLOUD_ERROR_REPORTING.

OpenTelemetry¶

Weblate môže exportovať backendové stopy pomocou OpenTelemetry. Používa OTLP cez HTTP a môže odosielať stopy do OpenTelemetry Collectora alebo kompatibilného koncového bodu dodávateľa.

OPENTELEMETRY_ENABLED = True
OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT = "https://collector.example.com/v1/traces"
OPENTELEMETRY_TRACES_SAMPLE_RATE = 0.1

Integrácia sleduje požiadavky Django, úlohy Celery, Redis, odchádzajúce HTTP požiadavky, databázové volania a rozpätia špecifické pre Weblate. Nakonfigurujte ju pomocou OPENTELEMETRY_ENABLED, OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT a OPENTELEMETRY_TRACES_SAMPLE_RATE.

Rollbar¶

Weblate má vstavanú podporu pre Rollbar. Na jeho použitie stačí postupovať podľa inštrukcií pre Rollbar notifier for Python.

Stručne povedané, musíte upraviť 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",
}

Všetko ostatné je integrované automaticky, teraz budete zbierať chyby zo strany servera aj klienta.

Poznámka

Logovanie chýb tiež zahŕňa výnimky, ktoré boli elegantne spracované, ale môžu naznačovať problém – napríklad neúspešné parsovanie nahraného súboru.

Správa logov Graylog¶

Added in version 5.9.

Weblate je možné nakonfigurovať tak, aby zapisoval logy pomocou protokolu GELF cez TCP. Tento spôsob bol pôvodne vyvinutý na integráciu s Graylogom, no dá sa použiť s akoukoľvek kompatibilnou platformou na logovanie.

Vzorová konfigurácia je uvedená v Vzorová konfigurácia. V prípade Dockeru je možné toto nastaviť pomocou WEBLATE_LOG_GELF_HOST.

Migrácia Weblate na iný server¶

Migrácia Weblate na iný server by mala byť pomerne jednoduchá, avšak Weblate ukladá dáta na niekoľkých miestach, ktoré je potrebné preniesť opatrne. Najlepší postup je Weblate pred migráciou zastaviť.

Migrácia databázy¶

Najpriamejší postup je použiť natívne nástroje databázy, keďže tie sú zvyčajne najefektívnejšie (napr. pg_dump). Prípadne môžete použiť replikáciu, ak ju vaša databáza podporuje.

Viď aj

Migrácia medzi databázami je popísaná v Migrácia z iných databáz do PostgreSQL.

Migrácia repozitárov VCS¶

Repozitáre VCS uložené v DATA_DIR je taktiež potrebné zmigrovať. Môžete ich jednoducho skopírovať alebo použiť rsync na efektívnejšiu migráciu.

Ďalšie poznámky¶

Nezabudnite presunúť aj ďalšie služby, ktoré mohol Weblate používať, ako Valkey, Redis, cron úlohy alebo vlastné autentifikačné backendy.