Konfigurációs útmutató¶
A Weblate telepítése¶
A tapasztalattól és a környezettől függően válassza ki az Ön számára megfelelő telepítési módot:
Telepítés Docker használatával, ajánlott éles környezetekhez.
Virtuális környezetbe történő telepítés, szintén ajánlott éles környezetekhez:
Telepítés forráskódból, ajánlott fejlesztési célokra.
Rendszer-architektúra áttekintése¶
- Webszerver
A bejövő HTTP-kérések kezelése, lásd: Statikus fájlok kiszolgálása.
- Celery munkafolyamatok
A Háttérfeladatok Celery használatával feladatok is itt kerülnek végrehajtásra.
A munkaterheléstől függően érdemes lehet testreszabni a munkafolyamatok (workers) számát.
Weblate vízszintes skálázásakor használjon dedikált csomópontot.
- WSGI-szerver
A WSGI-szerver biztosítja a weboldalak kiszolgálását a felhasználók számára.
Weblate vízszintes skálázásakor használjon dedikált csomópontot.
- Adatbázis
PostgreSQL adatbázis-szerver az összes tartalom tárolására szolgál, lásd: Adatbázis beállítása Weblate-hez.
Nagy, több százmillió szót tartalmazó oldalak esetében célszerű dedikált adatbázis-csomópontot használni.
- Datastore
Key/value datastore such as Valkey or Redis server for cache and tasks queue, see Háttérfeladatok Celery használatával.
Weblate vízszintes skálázásakor használjon dedikált csomópontot.
- Fájlrendszer
A VCS (verziókezelő) tárolók és a felhasználók által feltöltött adatok tárolására szolgál. Ezt minden folyamat közösen használja.
A Weblate vízszintes skálázásakor hálózati fájltárolás használata javasolt.
- E-mail szerver
Kimenő e-mailekhez SMTP szerver szükséges, lásd: Kimenő e-mailek beállítása. Ez akár külső szolgáltatásként is biztosítható.
Tipp
Telepítés Docker használatával includes PostgreSQL and Valkey, making the installation easier.
Szoftverkövetelmények¶
Operációs rendszer¶
A Weblate ismerten működik Linux, FreeBSD és macOS rendszereken. Más Unix-szerű rendszereken is valószínűleg problémamentesen használható.
A Weblate Windows rendszeren hivatalosan nem támogatott. Ettől függetlenül működhet, és a javításokat szívesen fogadják.
Lásd még
Az Rendszer-architektúra áttekintése rész ismerteti a Weblate általános architektúráját és az ehhez szükséges szolgáltatásokat.
Python függőségek¶
Weblate is written in Python and supports Python
3.12 or newer. You can install dependencies using pip or from your
distribution packages, full list is available in requirements.txt.
Legfontosabb függőségek:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
Opcionális függőség-megjelölések |
Python csomagok |
Weblate funkció |
|---|---|---|
|
||
|
||
|
||
|
Google Cloud Translation Advanced szójegyzék-támogatással |
|
|
||
|
||
|
PostgreSQL, lásd: Adatbázis beállítása Weblate-hez |
|
|
||
|
||
|
SAML 2 IDP integrálása a Weblate-be |
|
|
Needed for POT-fájl frissítése (Sphinx) |
|
|
Hosted Weblate integráció |
|
|
wsgi server (Weblate-hez) |
|
|
Amennyiben pip segítségével történik a telepítés, a kívánt funkciók közvetlenül is megadhatók:
uv pip install "weblate[Postgres,Amazon,SAML]"
Vagy telepíthető a Weblate az összes opcionális funkcióval:
uv pip install "weblate[all]"
Vagy telepíthető a Weblate opcionális funkciók nélkül is:
uv pip install weblate
Hibaelhárítás pip telepítés esetén¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.The installed
PyGobjectpackage cannot find a matching GObject Introspection library -gobject-introspection-2.0.Older versions are no longer supported by Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Ez az inkompatibilis bináris csomagok miatt történik, amelyeket a PyPI terjeszt. A probléma megoldásához újra kell építeni a csomagot a saját rendszerén:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Ez az xmlsec csomag ismert hibája, részletekért lásd: https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchAz
lxmlésxmlseccsomagokat ugyanahhoz alibxml2verzióhoz kell fordítani. A probléma elkerülése érdekében érdemes őket helyben lefordítani:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Egyéb rendszerkövetelmények¶
A következő függőségeket kell telepíteni a rendszerre:
Git- Pango, Cairo és a kapcsolódó fejlécfájlok, valamint GObject introspection adatok
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, lásd: Pango és Cairo
git-review(opcionális a Gerrit támogatáshoz)git-svn(opcionális a Subversion támogatáshoz)tesseract(csak akkor szükséges, ha a tesserocr bináris csomagok nem érhetők el a rendszerére)
Fordítási (build) időbeli függőségek¶
To build some of the Python függőségek you might need to install their
dependencies. This depends on how you install them, so please consult
individual packages for documentation. You won’t need those if using prebuilt
Wheels while installing using pip or when you use distribution packages.
Pango és Cairo¶
A Weblate a Pango és Cairo könyvtárakat használja bitmap widgetek (grafikus vezérlők) megjelenítésére (lásd: Building the translation community) és ellenőrzések megjelenítésére (lásd: Betűtípusok kezelése). A Python kötéseik helyes telepítéséhez először a rendszerkönyvtárakat kell telepíteni – szükség van a Cairo és a Pango könyvtárakra is, amelyek viszont a GLib könyvtárat igénylik. Minden könyvtárhoz szükség van a fejlesztői fájlok és a GObject introspection adatok telepítésére.
Hardverkövetelmények¶
A Weblate bármilyen korszerű hardveren problémamentesen működik, az alábbi minimális konfiguráció szükséges a Weblate (adatbázis és webszerverrel együtt) egyetlen gépen történő futtatásához:
3 GB RAM
2 CPU mag
1 GB tárhely
Megjegyzés
A Weblate telepítésének tényleges követelményei nagymértékben függnek a kezelt fordítások méretétől.
Memóriahasználat¶
Minél több memória áll rendelkezésre, annál jobb – a memória minden szinten gyorsítótárazásra szolgál (fájlrendszer, adatbázis és Weblate). Több száz fordítási összetevő esetén legalább 4 GB RAM ajánlott.
Tipp
Ha kevesebb memória áll rendelkezésre, mint az ajánlott, a Egyszálú Celery beállítás használata javasolt.
CPU-használat¶
Sok egyidejű felhasználó esetén nő a szükséges CPU magok száma.
Tárhelyhasználat¶
Az adatbázis tipikus tárhelyigénye körülbelül 300 MB 1 millió tárolt szóra vetítve.
A klónozott tárolók tárhelyigénye változó, de a Weblate igyekszik a méretüket minimálisra csökkenteni sekély (shallow ) klónozások alkalmazásával.
Csomópontok¶
Kis és közepes méretű webhelyek esetén (milliós nagyságrendű tárolt szavak) az összes Weblate összetevő (lásd: Rendszer-architektúra áttekintése) egyetlen csomóponton is futtatható.
Amikor a tárolt szavak száma százmilliók fölé nő, ajánlott külön csomópontot biztosítani az adatbázis számára (lásd: Adatbázis beállítása Weblate-hez).
Kiadások aláírásának ellenőrzése¶
A Weblate kiadásait kriptográfiai aláírással látják el Sigstore aláírások segítségével. Az aláírások a GitHub-kiadásokhoz csatoltan érhetők el.
Az ellenőrzés a sigstore csomag segítségével végezhető el. Az alábbi példa az 5.4-es kiadás aláírásának ellenőrzését mutatja be:
sigstore verify github \
--cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
--bundle Weblate-5.4-py3-none-any.whl.sigstore \
Weblate-5.4-py3-none-any.whl
Fájlrendszer jogosultságok¶
A Weblate folyamatnak olvasási és írási jogosultsággal kell rendelkeznie ahhoz a könyvtárhoz, ahol az adatokat tárolja - DATA_DIR. A könyvtárban található összes fájlnak a Weblate folyamatokat futtató felhasználó tulajdonában kell lennie, és számára írhatónak kell lennie (általában WSGI és Celery, lásd: Szerver futtatása és Háttérfeladatok Celery használatával).
Az alapértelmezett konfigurációban, ezek ugyanabban a könyvtárstruktúrában helyezkednek el, mint a Weblate forrásai, azonban célszerű lehet ezeket áthelyezni egy megfelelőbb helyre, például ide: /var/lib/weblate.
A Weblate megpróbálja ezeket a könyvtárakat automatikusan létrehozni, de ha nincs megfelelő jogosultsága, a művelet meghiúsul.
The configured CACHE_DIR also has to be writable by the Weblate
process and has to allow executing generated helper files. Do not mount
CACHE_DIR with the noexec option.
Ügyelni kell a Kezelőparancsok futtatásakor is, mivel ezt ugyanazzal a felhasználóval kell végrehajtani, mint amelyikkel a Weblate fut, különben bizonyos fájlok jogosultságai helytelenek lehetnek.
A Docker-konténerben a /app/data kötetben található összes fájlnak a konténeren belüli weblate felhasználó (UID 1000) tulajdonában kell lennie.
Lásd még
Adatbázis beállítása Weblate-hez¶
Ajánlott a Weblate-et PostgreSQL adatbázis-kiszolgálóval futtatni.
A PostgreSQL 13-as vagy újabb verziói támogatottak. A PostgreSQL 15 vagy újabb verziók használata javasolt.
Adatbázis-kapcsolatok¶
Az alapértelmezett konfiguráció szerint minden Weblate folyamat folyamatos adatbázis-kapcsolatot tart fenn. A folyamatos kapcsolatok javítják a Weblate válaszidejét, de több erőforrást igényelhetnek az adatbázis-kiszolgálótól. További információkért lásd: CONN_MAX_AGE és Persistent connections.
A Weblate-nek legalább a következő számú kapcsolat szükséges:
\((4 \times \mathit{nCPUs}) + 2\) a Celery folyamatokhoz
\(\mathit{nCPUs} + 1\) a WSGI munkafolyamatokhoz (workers)
Ez a Docker-konténerek alapértelmezett beállításaira és a dokumentációban szereplő példakonfigurációkra vonatkozik, de a számok módosulnak, ha testreszabja a WSGI munkafolyamatok számát vagy a Celery párhuzamosítását.
Az adatbázis-kapcsolatok tényleges korlátját magasabbra kell állítani az alábbi helyzetek figyelembevételével:
A Kezelőparancsok futtatása is igényel kapcsolatot.
Ha egy folyamat megszakad (például egy OOM killer miatt), az meglévő kapcsolatot is blokkolhatja a timeout lejártáig.
PostgreSQL¶
A PostgreSQL általában a legjobb választás Django-alapú webhelyekhez. Ez a referencia-adatbázis, amelyet a Django adatbázisrétegének fejlesztéséhez használnak.
Megjegyzés
A Weblate trigram kiterjesztést használ, amelyet bizonyos esetekben külön kell telepíteni. Keresse a postgresql-contrib vagy hasonló nevű csomagot.
Lásd még
Adatbázis létrehozása PostgreSQL-ben¶
Általában jó ötlet a Weblate-et külön adatbázisban és külön felhasználói fiókkal futtatni:
# 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
Tipp
Ha nem szeretné a Weblate felhasználót PostgreSQL superuser (teljes körű) jogokkal ellátni ,ez a lépés kihagyható. Ebben az esetben bizonyos migrációs lépéseket kézzel kell végrehajtani PostgreSQL teljes körű jogosultságokkal azon a sémanéven, amelyet a Weblate használni fog:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Weblate konfigurálása PostgreSQL használatára¶
A settings.py fájlban a PostgreSQL-hez tartozó kódrészlet:
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,
}
}
Az adatbázis-migráció során a ALTER ROLE parancsot hajtja végre a Weblate által használt adatbázis-szerepkörön. A legtöbb esetben a szerepkör neve megegyezik a felhasználónévvel. Összetettebb beállításoknál a szerepkör neve eltérhet a felhasználónévtől, ilyenkor a migráció során hibaüzenetet kap (psycopg2.errors.UndefinedObject: role \"weblate@hostname\" does not exist). Ez ismert probléma például az Azure Database for PostgreSQL környezetben, de nem kizárólag ott fordul elő. Ilyen esetben kérjük, állítsa be az ALTER_ROLE változót a megfelelő szerepkörnév megadásához az adatbázis-migráció során.
Lásd még
Egyéb konfigurációk¶
Kimenő e-mailek beállítása¶
A Weblate különböző események alkalmával küld e-maileket – például fiókaktiváláskor vagy a felhasználók által beállított értesítésekről. Ehhez SMTP szerverhez való hozzáférés szükséges.
A levelezőszerver beállítása az alábbi paraméterekkel történik: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER és EMAIL_PORT. Ezek elnevezése önmagáért beszél, de további információkat a Django dokumentációjában talál.
Tipp
Ha olyan hibaüzenetet kap, amely nem támogatott hitelesítést jelez (például SMTP AUTH extension not supported by server), az valószínűleg nem biztonságos kapcsolaton történő próbálkozás miatt van, és a kiszolgáló elutasítja az ilyen típusú hitelesítést. Ilyen esetben próbálja meg engedélyezni a EMAIL_USE_TLS beállítást.
Fordított (reverse) proxy mögötti futtatás¶
A Weblate több funkciója is attól függ, hogy a megfelelő HTTP-fejlécek helyesen továbbításra kerülnek-e a Weblate felé. Fordított proxy használata esetén ügyeljen arra, hogy ezek az adatok megfelelően átadásra kerüljenek.
To debug this configuration, you can look at HTTP environment in Teljesítményjelentés.
- Kliens IP-cím
This is needed for Sebességkorlátozás or Ellenőrzési napló.
A Weblate a WSGI handler által beállított
REMOTE_ADDRváltozóból olvassa ki az IP-címet. Ez üres lehet (ha socketet használ WSGI-hez) vagy a fordított proxy IP-címét tartalmazhatja, ezért a Weblate-nek szüksége van egy további HTTP fejlécben érkező kliens IP-címre.A
IP_BEHIND_REVERSE_PROXYbeállítás engedélyezése a legtöbb esetben elegendő, de szükség lehet aIP_PROXY_HEADERés aIP_PROXY_OFFSETmódosítására is (Docker-konténerben használja aWEBLATE_IP_PROXY_HEADERésWEBLATE_IP_PROXY_OFFSETváltozókat).Tipp
Ez a beállítás nem engedélyezett alapértelmezetten, mivel lehetővé tenné az IP-címek meghamisítását olyan telepítéseknél, ahol a fordított proxy nincs megfelelően konfigurálva.
- Kiszolgáló gép neve
A Host fejléc értékének egyeznie kell a
SITE_DOMAINbeállítással. További konfiguráció lehet szükséges a fordított proxyban (például használja aProxyPreserveHost Onbeállítást Apache esetén, vagyproxy_set_header Host $host;értéket nginx esetén).Tipp
CSRF verification failed errors are often caused by a mismatch between the Host header and configured
SITE_DOMAIN.- Kliensprotokoll
Ha a megfelelő protokoll nincs továbbítva, a Weblate végtelen átirányítási ciklusba kerülhet, miközben megpróbálja HTTPS-re váltani a kapcsolatot. Győződjön meg róla, hogy a proxy megfelelően továbbítja a X-Forwarded-Proto fejlécet.
This header then needs to be configured in
SECURE_PROXY_SSL_HEADER(settings.py) orWEBLATE_SECURE_PROXY_SSL_HEADER(Docker environment).Fontos
The header value is case-sensitive in the configuration, so
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsandWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSare not interchangeable.Tipp
If you are getting a „Too many redirects” error from the browser, this is most likely caused by mismatch between the actual protocol (HTTPS) and what is observed by Weblate.
A 5.13 verzióban változott: The protocol proxy headers are automatically handled by gunicorn in the default configuration, but other WSGI servers have more secure configuration and require explicit setting of this.
Since Weblate 5.13 the Docker container is using granian and it now requires the explicit configuration of
WEBLATE_SECURE_PROXY_SSL_HEADER.
Lásd még
HTTP proxy¶
A Weblate VCS (verziókezelő rendszer) parancsokat is futtat, amelyek elfogadják a proxybeállításokat a környezeti változókból. Ajánlott a proxybeállításokat a settings.py fájlban definiálni:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Lásd még
Konfiguráció módosítása¶
Lásd még
Másolja a weblate/settings_example.py fájlt weblate/settings.py néven, és igazítsa a rendszere környezetéhez. Valószínűleg az alábbi beállításokat kell majd módosítani:
ADMINS
A webhely adminisztrátorainak listája, akik értesítést kapnak, ha valami hiba történik, például sikertelen egyesítésekről vagy Django hibákról.
A kapcsolatfelvételi űrlap is ezekre az e-mail címekre küld üzenetet, hacsak nincs külön megadvaz
ADMINS_CONTACT.
ALLOWED_HOSTS
Meg kell adnia, hogy a webhely milyen hosztneveket szolgálhat ki. Például:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternatívaként használhat helyettesítő karaktereket is:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Állítsa be, hogy a munkamenetek (sessions) hol legyenek tárolva. Ha az alapértelmezett adatbázis-háttérmotort használja, akkor ütemezze a weblate clearsessions parancsot a régi munkamenet-adatok törlésére az adatbázisból.
If you are using Valkey or Redis as cache (see Configure cache) it is recommended to use it for sessions as well:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
DATABASES
Az adatbázis-kiszolgálóhoz való csatlakozás részleteiért kérjük, olvassa el a Django dokumentációját.
DEBUG
A debug módot tiltsa le bármely éles (production) szerveren. Ha a debug mód engedélyezve van, a Django részletes hibakövetési adatokat jelenít meg a felhasználóknak hiba esetén; ha letiltja, a hibákról e-mail értesítést kapnak az
ADMINScsoport tagjai. (lásd fentebb).A debug mód lelassítja a Weblate működését is, mivel a Django ilyenkor sokkal több információt tárol belsőleg.
DEFAULT_FROM_EMAIL
A kimenő e-mailek (például regisztrációs üzenetek) feladó e-mail címe.
Lásd még
SECRET_KEY
A Django által egyes cookie-k aláírására használt kulcs, további információért lásd: Django titkos kulcs.
Lásd még
SERVER_EMAIL
Az adminisztrátornak küldött e-mailek (például sikertelen egyesítések értesítései) feladó e-mail címe.
Lásd még
Az adatbázis feltöltése¶
Miután elkészült a konfigurációval, futtassa a migrate parancsot az adatbázis-struktúra létrehozásához. Ezt követően az adminisztrációs felületen keresztül létrehozhat fordítási projekteket.
Ha ezzel készen van, érdemes megnézni az adminisztrációs felületen a Teljesítményjelentés oldalt is, amely javaslatokat adhat a nem optimális beállítások javítására.
Lásd még
Éles környezet beállítása¶
Éles környezethez a következő szakaszokban leírt módosításokat kell elvégezni. A legkritikusabb beállítások figyelmeztetést váltanak ki, amelyet egy felkiáltójel jelez a felső sávban, ha rendszergazdaként van bejelentkezve:
Ajánlott továbbá ellenőrizni a Django által jelzett figyelmeztetéseket is (bár nem szükséges mindet kijavítani):
weblate check --deploy
Ugyanezt az ellenőrzőlistát áttekintheti a Teljesítményjelentés résznél a Kezelőfelület felületen.
Lásd még
A hibakeresési (debug) mód kikapcsolása¶
Tiltsa le a Django hibakeresési módját (DEBUG) az alábbi módon:
DEBUG = False
Ha a hibakeresési mód engedélyezve van, a Django eltárolja az összes végrehajtott lekérdezést, és hibák esetén részletes hibakövetést jelenít meg a felhasználóknak, ami éles környezetben nem kívánatos.
Lásd még
Adminisztrátorok helyes beállítása¶
Állítsa be a megfelelő adminisztrátori e-mail címeket az ADMINS beállításban, hogy probléma esetén (például szerverhiba) az értesítések ezekre a címekre érkezzenek, például így:
ADMINS = ("Your Name <your_email@example.com>",)
Lásd még
Webhely domain helyes beállítása¶
Állítsa be a webhely nevét és domainjét az adminisztrációs felületen, különben az RSS-linkek és a regisztrációs e-mailek nem fognak megfelelően működni. Ezt a SITE_DOMAIN beállítással adhatja meg, amely a webhely domain nevét kell, hogy tartalmazza.
A 4.2 verzióban változott: A 4.2-es kiadás előtt a Django sites framework-öt használták erre a célra, részletekért lásd: The “sites” framework.
HTTPS helyes konfigurálása¶
Nyomatékosan ajánlott a Weblate-et titkosított HTTPS protokollon keresztül futtatni. Ennek bekapcsolása után állítsa be az ENABLE_HTTPS értékét a beállításokban:
ENABLE_HTTPS = True
Tipp
Érdemes HSTS-t is beállítani, részletekért lásd: SSL/HTTPS.
SECURE_HSTS_SECONDS helyes beállítása¶
Ha a webhely SSL-en keresztül érhető el, fontolja meg a SECURE_HSTS_SECONDS érték beállítását a settings.py fájlban a HTTP Strict Transport Security (szigorú biztonságos átvitel) engedélyezéséhez. Alapértelmezésben ez 0-ra van állítva, az alábbiak szerint.
SECURE_HSTS_SECONDS = 0
Ha nem nulla értékre állítja, a django.middleware.security.SecurityMiddleware beállítja a HTTP Strict Transport Security HTTP-fejlécet minden olyan válaszra, amelyen ez még nem szerepel.
Figyelem
Ennek helytelen beállítása hosszabb időre visszafordíthatatlanul elérhetetlenné teheti az oldalát. Előtte olvassa el a HTTP Strict Transport Security dokumentációt.
Használjon erős adatbázismotort¶
Kérjük, használjon PostgreSQL-t éles környezetben, részletekért lásd: Adatbázis beállítása Weblate-hez.
Az adatbázis-kiszolgálót lehetőség szerint közeli helyen futtassa, mert a hálózati teljesítmény vagy megbízhatóság problémái rontanák a Weblate használati élményét.
Ellenőrizze az adatbázis-kiszolgáló teljesítményét vagy optimalizálja annak konfigurációját, például a PGTune segítségével.
Configure cache¶
If possible, use Valkey or Redis from Django by adjusting the CACHES
configuration variable, for example:
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",
},
}
}
Tipp
In case you change settings for the cache, you might need to adjust them for Celery as well, see Háttérfeladatok Celery használatával.
Profilképek gyorsítótárazása¶
A Django gyorsítótárazása mellett a Weblate a profilképeket is gyorsítótárazza. Erre a célra ajánlott külön, fájl-alapú gyorsítótár használata:
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,
},
},
}
E-mailek küldésének konfigurálása¶
A Weblate több alkalommal is küld e-maileket, és ezeknek helyes feladócímmel kell rendelkezniük. Állítsa be a SERVER_EMAIL és DEFAULT_FROM_EMAIL értékeket a környezetének megfelelően, például:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Megjegyzés
Ha szeretné letiltani a Weblate általi e-mail küldést, állítsa az EMAIL_BACKEND értékét django.core.mail.backends.dummy.EmailBackend értékre.
Ez minden e-mail küldést letilt, beleértve a regisztrációs és jelszó-visszaállítási e-maileket is.
Engedélyezett hosztok beállítása¶
A Django megköveteli, hogy az ALLOWED_HOSTS listában szerepeljenek azok a domainnevek, amelyeket a webhely kiszolgálhat, ennek üresen hagyása minden kérést blokkolni fog.
Ha ez nincs megfelelően beállítva a HTTP-kiszolgálóval összhangban, ilyen hibát kaphat: Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Tipp
Docker-konténer esetén ez a következő környezeti változóval adható meg: WEBLATE_ALLOWED_HOSTS.
Django titkos kulcs¶
A SECRET_KEY beállítást a Django sütik aláírására használja, ezért mindenképp saját értéket kell generálni, és nem a példa-konfigurációban szereplőt használni.
Új kulcsot a Weblate-hez mellékelt weblate-generate-secret-key programmal generálhat.
Lásd még
Karbantartási feladatok futtatása¶
Az optimális teljesítmény érdekében érdemes néhány karbantartási feladatot háttérben futtatni. Ezt automatikusan a Háttérfeladatok Celery használatával végzi, amely a következő feladatokat fedi le:
Konfigurációs állapotellenőrzés (óránként).
Függőben lévő módosítások véglegesítése (óránként), lásd: Késleltetett véglegesítések (Lazy commits) és
commit_pending.Összetevő riasztások frissítése (naponta).
Távoli ágak frissítése (éjszakánként), lásd:
AUTO_UPDATE.Fordítási memória biztonsági mentése JSON formátumba (naponta), lásd:
dump_memory.Szövegkeresési és adatbázis-karbantartási feladatok (napi és heti feladatok), lásd:
cleanuptrans.
Rendszernyelvi beállítások és karakterkódolás¶
A rendszernyelvi beállításoknak UTF-8 kompatibilisnek kell lenniük. A legtöbb Linux disztribúcióban ez az alapértelmezett beállítás. Ha a rendszerében nem így van, állítson át minden nyelvi beállítást UTF-8 változatra.
Például a /etc/default/locale fájl szerkesztésével és a LANG=\"C.UTF-8\" beállítás megadásával.
Bizonyos esetekben az egyes szolgáltatásoknak külön nyelvi konfigurációjuk lehet. Ez disztribúciótól és webszervertől függ, ezért nézze meg az adott webszerver csomag dokumentációját.
Ubuntu rendszeren az Apache a /etc/apache2/envvars fájlt használja:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
CentOS rendszeren az Apache a /etc/sysconfig/httpd fájlt használja (vagy /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Kliensoldali fájlok tömörítése¶
A Weblate számos JavaScript- és CSS-fájllal érkezik. Teljesítményjavítás céljából érdemes ezeket tömöríteni, mielőtt az ügyfélhez kerülnének. Alapértelmezett konfigurációban ez valós időben történik, minimális teljesítményveszteséggel. Nagyobb telepítések esetén ajánlott az offline tömörítési mód engedélyezése. Ehhez módosítani kell a konfigurációt, és minden Weblate frissítéskor újra kell futtatni a tömörítést.
A konfiguráció egyszerű: engedélyezni kell a django.conf.settings.COMPRESS_OFFLINE beállítást, és meg kell adni a django.conf.settings.COMPRESS_OFFLINE_CONTEXT értékeit is (ez utóbbi már szerepel a példa konfigurációban):
COMPRESS_OFFLINE = True
Minden egyes telepítéskor tömöríteni kell a fájlokat, hogy azok az aktuális verzióhoz illeszkedjenek:
weblate compress
Tipp
A hivatalos Docker-képben ez a funkció már alapértelmezésben engedélyezett.
Szerver futtatása¶
Tipp
Ha nem ismeri a lentebb bemutatott szolgáltatásokat, érdemes lehet kipróbálni a Telepítés Docker használatával megoldást.
A Weblate futtatásához több szolgáltatásra lesz szüksége, az ajánlott összeállítás a következőkből áll:
Adatbázis-kiszolgáló (lásd: Adatbázis beállítása Weblate-hez)
Gyorsítótár-kiszolgáló (lásd: Configure cache)
Frontend webszerver a statikus fájlokhoz és az SSL-kezeléshez (lásd: Statikus fájlok kiszolgálása)
WSGI szerver a dinamikus tartalom kiszolgálásához (lásd: Minta konfiguráció NGINX és uWSGI használatával)
Celery a háttérfeladatok végrehajtásához (lásd: Háttérfeladatok Celery használatával)
Megjegyzés
A szolgáltatások között vannak függőségek is, például a cache és az adatbázis szervereknek működniük kell, mielőtt a Celery vagy a uwsgi folyamatok elindulnak.
A legtöbb esetben minden szolgáltatást egyetlen (virtuális) szerveren futtat, de ha a telepítés nagy terhelésű, szétválaszthatja az egyes szolgáltatásokat. Egyetlen megkötés van: a Celery és a WSGI szervereknek hozzáféréssel kell rendelkezniük a DATA_DIR könyvtárhoz.
Megjegyzés
A WSGI folyamatot ugyanazzal a felhasználóval kell futtatni, mint a Celery folyamatot, különben a DATA_DIR fájljai eltérő tulajdonossal jönnek létre, ami futásidejű problémákat okozhat.
Lásd még: Fájlrendszer jogosultságok és Háttérfeladatok Celery használatával.
Webszerver futtatása¶
A Weblate futtatása nem különbözik más Django-alapú alkalmazások futtatásától. A Django-t általában WSGI-n vagy fcgi-n keresztül futtatják (lásd a különböző webszerverekhez tartozó példákat lentebb).
Megjegyzés
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
Tesztelési célokra használhatja a Django beépített webszerverét is:
weblate runserver
Figyelem
NE HASZNÁLJA EZT A SZERVERKÖRNYEZETET ÉLES ÜZEMBEN! Nem esett át biztonsági auditon vagy teljesítményteszteken. Lásd még a Django dokumentációját: runserver.
Tipp
The Django built-in server serves static files only with DEBUG
enabled as it is intended for development only. For production use, please
see WSGI setups:
Statikus fájlok kiszolgálása¶
A 5.15.2 verzióban változott: /media/ is no longer used for serving screenshots.
A Django-nak egyetlen könyvtárba kell gyűjtenie a statikus fájlokat. Ehhez futtassa a következő parancsot: weblate collectstatic --noinput. Ez átmásolja a statikus fájlokat a STATIC_ROOT által meghatározott könyvtárba (alapértelmezés szerint ez a CACHE_DIR mappán belüli static könyvtár).
Ajánlott a statikus fájlokat közvetlenül a webszerverről kiszolgálni, az alábbi útvonalakon:
/static/A Weblate és az adminisztrációs felület statikus fájljainak kiszolgálása (a
STATIC_ROOTáltal meghatározott helyről)./favicon.icoA
/static/favicon.icokiszolgálása átírási szabállyal (RewriteRule).
Lásd még
Tartalomvédelmi irányelvek¶
A Weblate alapértelmezett konfigurációja engedélyezi a weblate.middleware.SecurityMiddleware köztes réteget, amely biztonsággal kapcsolatos HTTP-fejléceket állít be, például: Content-Security-Policy vagy X-XSS-Protection. Ezek alapértelmezett értékei a Weblate-hez és annak konfigurációjához igazodnak, de előfordulhat, hogy környezetéhez igazítva testreszabásra szorulnak.
Sample configuration for NGINX and Granian¶
The following configuration runs Weblate using Granian the NGINX webserver:
#
# 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;
}
}
Minta konfiguráció NGINX és Gunicorn használatával¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Minta konfiguráció NGINX és uWSGI használatával¶
To run production webserver, use the WSGI wrapper installed with Weblate (when
using a Python environment it is installed as
~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Don’t
forget to set the Python search path to your Python environment as well (for
example using virtualenv = /home/user/weblate-env in uWSGI).
Az alábbi konfiguráció a Weblate-et uWSGI alatt futtatja az NGINX webszerverrel.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# Path to the Python environment
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Lásd még
Minta konfiguráció Apache használatával¶
Ajánlott a prefork MPM használata, ha a Weblate-et WSGI-vel futtatja.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Megjegyzés
A Weblate Python 3-at igényel, ezért győződjön meg róla, hogy a Python 3 változatát használja a mod_wsgi modulnak. Ez általában külön csomagként érhető el, például libapache2-mod-wsgi-py3 néven.
A Weblate telepítéséhez használjon azonos Python-verziót.
Minta konfiguráció Apache és Gunicorn használatával¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Sample configuration to start Granian¶
Weblate has wsgi optional dependency (see Python függőségek) that will install everything you need to run Granian. When installing Weblate you can specify it as:
uv pip install Weblate[all,wsgi]
Once you have Granian installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Minta konfiguráció Gunicorn indításához¶
Gunicorn has to be installed separately:
uv pip install gunicorn
Ha telepítette a Gunicorn-t, akkor futtathatja is. Ez általában rendszerszinten történik. Az alábbi példák a systemd használatával történő indítást mutatják be:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Lásd még
Weblate futtatása útvonal megadásával¶
Ajánlott a prefork MPM használata, ha a Weblate-et WSGI-vel futtatja.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Ezen kívül módosítani kell a weblate/settings.py fájlt is:
URL_PREFIX = "/weblate"
Háttérfeladatok Celery használatával¶
A Weblate a Celery-t használja a rendszeres és háttérfeladatok végrehajtására. Ehhez egy Celery szolgáltatást kell futtatni, amely ezeket a feladatokat végrehajtja. Például az alábbi műveletek kezeléséért felel (a lista nem teljes):
Webhookok fogadása külső szolgáltatásokból (lásd: Értesítési hookok).
Rendszeres karbantartási feladatok futtatása, például biztonsági mentések, tisztítások, napi kiegészítők vagy frissítések (lásd: Weblate biztonsági mentése és áthelyezése,
BACKGROUND_TASKS, Kiegészítők).Automatikus fordítás futtatása.
Összesített értesítések küldése.
Erőforrás-igényes műveletek áthelyezése a WSGI folyamatból.
Függőben lévő módosítások véglegesítése (lásd: Késleltetett véglegesítések (Lazy commits)).
A typical setup using Valkey or Redis as a backend looks like this:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
Megjegyzés
A Celery folyamatot ugyanazzal a felhasználóval kell futtatni, mint a WSGI folyamatot, különben a DATA_DIR könyvtárban lévő fájlok vegyes tulajdonúak lesznek, ami futásidejű hibákhoz vezethet.
További információ: Fájlrendszer jogosultságok és Szerver futtatása.
Celery feladatok végrehajtása a WSGI folyamatban gyors (eager) módban¶
Megjegyzés
Ez komoly teljesítménycsökkenést okoz a webes felületen, és olyan funkciók működését akadályozhatja, amelyek rendszeres indítást igényelnek (például függőben lévő módosítások véglegesítése, összesített értesítések vagy biztonsági mentések).
Fejlesztési célokra ajánlott a gyors (eager) konfiguráció, amely helyben hajtja végre az összes feladatot:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Celery futtatása rendszerszolgáltatásként¶
Most likely you will want to run Celery as a daemon and that is covered by
Daemonization. For the most common Linux setup using
systemd, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
Systemd egységfájl, amelyet a /etc/systemd/system/celery-weblate.service helyre kell elhelyezni:
[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
Környezeti konfigurációs fájl, amelyet a /etc/default/celery-weblate helyre kell elhelyezni:
# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"
# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"
# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"
# Extra command-line arguments to the worker. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
További konfiguráció a Celery naplók forgatásához a logrotate segítségével, amelyet a /etc/logrotate.d/celery helyre kell elhelyezni:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Időzített feladatok a Celery beat használatával¶
A Weblate beépített támogatást nyújt az ütemezett feladatok kezelésére. A feladatütemezés az adatbázisban tárolódik, a végrehajtásért pedig a Celery beat daemon felel.
Tipp
További feladatokat is definiálhat a settings.py fájlban, például lásd: Késleltetett véglegesítések (Lazy commits).
A Celery állapotának figyelése¶
A Celery feladatok várósorainak aktuális hosszát megtekintheti a Kezelőfelület felületen vagy parancssorban a celery_queues parancs segítségével. Ha a sor hossza túlságosan megnő, a rendszergazdai felületen konfigurációs hibajelzést kap.
Figyelem
A Celery hibák alapértelmezetten csak a Celery naplóba kerülnek, a felhasználó számára nem láthatók. Amennyiben szeretné áttekinteni ezeket a hibákat, javasolt a Hibajelentések gyűjtése és teljesítmény monitorozása konfigurálása.
Egyszálú Celery beállítás¶
Ha korlátozott memóriakapacitás áll rendelkezésre, célszerű lehet csökkenteni a Weblate folyamatok számát. Minden Celery feladat egyetlen folyamatban is végrehajtható az alábbi módon:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Docker-alapú telepítés esetén az egyszálú Celery működés beállítható a CELERY_SINGLE_PROCESS környezeti változó megadásával.
Figyelem
Ez érezhető teljesítménycsökkenést eredményez a Weblate működésében.
Weblate monitorozása¶
A Weblate a /healthz/ URL-t biztosítja egyszerű állapotellenőrzésekhez, például Kubernetes környezetben. A Docker-konténer beépített épség ellenőrzést (health check) végez ezen az URL-en keresztül.
A Weblate működési metrikáinak monitorozására használható az GET /api/metrics/ API végpont.
Hibajelentések gyűjtése és teljesítmény monitorozása¶
Mint minden más szoftver, a Weblate is meghibásodhat. A hasznos hibaállapotok összegyűjtése érdekében javasolt külső szolgáltatások használata. Ez különösen hasznos a Celery feladatok meghibásodása esetén, amelyek egyébként csak naplóban jelennének meg, és nem kapna róla értesítést. A Weblate az alábbi szolgáltatásokat támogatja:
E-mail¶
The default Weblate configuration instruments Django to send e-mails upon
server errors via django.utils.log.AdminEmailHandler. This
is the least effort setup, but you should consider other options for privacy
reasons, as the error e-mails might include sensitive data. You can read more on
that in Security implications.
To disable this behavior, remove mail_admins from the
LOGGING in Weblate settings, or disable
WEBLATE_ADMIN_NOTIFY_ERROR in the Docker environment.
Sentry¶
A Weblate beépített támogatást nyújt a Sentry szolgáltatáshoz. Használatához elegendő a SENTRY_DSN beállítása a settings.py fájlban:
SENTRY_DSN = "https://id@your.sentry.example.com/"
A Sentry használható a Weblate teljesítményének monitorozására is, műveletek adott százalékáról származó nyomkövetési adatok és profilok gyűjtésével. Ez a SENTRY_TRACES_SAMPLE_RATE és a SENTRY_PROFILES_SAMPLE_RATE beállításokkal konfigurálható.
Rollbar¶
A Weblate beépített támogatást nyújt a Rollbar szolgáltatáshoz is. Használatához kövesse a Rollbar notifier for Python útmutatását.
Röviden, módosítani kell a settings.py fájlt:
# 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",
}
Minden más automatikusan integrálásra kerül, így a szerver- és kliensoldali hibák gyűjtése is megtörténik.
Megjegyzés
A hibanaplózás magában foglalja azokat a kivételeket is, amelyeket ugyan kezelt a rendszer, de problémára utalhatnak – például egy feltöltött fájl sikertelen feldolgozását.
Graylog-alapú naplókezelés¶
Added in version 5.9.
A Weblate konfigurálható úgy, hogy a naplózást a GELF TCP protokoll használatával végezze. Ezt eredetileg a Graylog integrációhoz fejlesztették, de bármely megfelelően kompatibilis naplózási platformmal használható.
A konfigurációs sablon megtalálható a Mintakonfiguráció részben, Docker használata esetén a WEBLATE_LOG_GELF_HOST változóval állítható be.
Weblate áthelyezése másik szerverre¶
A Weblate átköltöztetése másik szerverre általában egyszerű, azonban több helyen is tárol adatokat, amelyeket körültekintően kell átvinni. A legjobb megközelítés, ha az áthelyezés idejére leállítja a Weblate szolgáltatást.
Adatbázis költöztetése¶
The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. pg_dump). Alternatively you can use replication if your database supports it.
Lásd még
Az adatbázisok közötti migráció részleteit lásd: Más adatbázisról PostgreSQL-re való átállás.
VCS (verziókezelő) tárolók költöztetése¶
A DATA_DIR alatt tárolt VCS tárolókat is át kell vinni. Ezeket egyszerűen átmásolhatja vagy használhatja a hatékonyabb rsync parancsot.
Egyéb megjegyzések¶
Don’t forget to move other services Weblate might have been using like Valkey, Redis, Cron jobs or custom authentication backends.