Instrucțiuni de configurare¶
Instalarea Weblate¶
În funcție de configurația și experiența dumneavoastră, alegeți o metodă de instalare adecvată pentru dumneavoastră:
Instalarea folosind Docker, recomandat pentru configurațiile de producție.
Instalarea Virtualenv, recomandată pentru configurațiile de producție:
Instalarea din surse, recomandat pentru dezvoltare.
Architecture overview¶
- Server web
Handling incoming HTTP requests, Servirea fișierelor statice.
- Celery workers
Sarcini de fundal folosind Celery are executed here.
Depending on your workload, you might want to customize the number of workers.
Use dedicated node when scaling Weblate horizontally.
- WSGI server
A WSGI server serving web pages to users.
Use dedicated node when scaling Weblate horizontally.
- Baza de date
PostgreSQL database server for storing all the content, see Configurarea bazei de date pentru Weblate.
Use dedicated database node for sites with hundreds of millions of hosted words.
- Redis
Server Redis pentru cache și coada de sarcini, vezi Sarcini de fundal folosind Celery.
Use dedicated node when scaling Weblate horizontally.
- File system
File system storage for storing VCS repositories and uploaded user data. This is shared by all the processes.
Use networked storage when scaling Weblate horizontally.
- E-mail server
SMTP server for outgoing e-mail, see Configurarea e-mailului de ieșire. It can be provided externally.
Sugestie
Instalarea folosind Docker includes PostgreSQL and Redis, making the installation easier.
Cerințe software¶
Sistem de operare¶
Se știe că Weblate funcționează pe Linux, FreeBSD și macOS. Cel mai probabil vor funcționa și alte sisteme de tip Unix.
Weblate nu este acceptat pe Windows. Dar este posibil să funcționeze în continuare, iar patch-urile sunt acceptate cu plăcere.
Vezi și
Architecture overview describes overall Weblate architecture and required services.
Dependențe Python¶
Weblate is written in Python and supports Python
3.10 or newer. You can install dependencies using pip or from your
distribution packages, full list is available in requirements.txt.
Cele mai notabile dependențe:
- Django
- Celery
- Traducere Toolkit
- traducător-detector
- Python Social Auth
- Cadrul Django REST
pip extra |
Python Package |
Weblate feature |
|---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
MySQL or MariaDB, see Configurarea bazei de date pentru Weblate |
|
|
||
|
PostgreSQL, see Configurarea bazei de date pentru Weblate |
|
|
||
|
Atunci când instalați folosind pip, puteți specifica direct caracteristicile dorite la instalare:
pip install "Weblate[Postgres,Amazon,SAML]"
Sau puteți instala Weblate cu toate funcțiile opționale:
pip install "Weblate[all]"
Sau puteți instala Weblate fără nicio funcție opțională:
pip install Weblate
Alte cerințe de sistem¶
Următoarele dependențe trebuie să fie instalate pe sistem:
Git- Pango, Cairo și fișierele antet aferente și datele de introspecție GObject
https://cairographics.org/, https://pango.gnome.org/, vezi Pango și Cairo
git-review(opțional pentru suport Gerrit)git-svn(opțional pentru suport pentru Subversion)tesseract(needed only if tesserocr binary wheels are not available for your system)licensee(opțional pentru detectarea licenței la crearea componentei)
Dependențe în timp de construcție¶
Pentru a construi unele dintre Dependențe Python, ar putea fi necesar să instalați dependențele acestora. Acest lucru depinde de modul în care le instalați, așa că vă rugăm să consultați pachetele individuale pentru documentație. Nu veți avea nevoie de acestea dacă folosiți Wheels preinstalate în timp ce instalați folosind pip sau când folosiți pachete de distribuție.
Pango și Cairo¶
Weblate folosește Pango și Cairo pentru redarea widget-urilor bitmap (vezi Promovarea traducerii) și pentru redarea verificărilor (vezi Gestionarea fonturilor). Pentru a instala corect legăturile Python pentru acestea, trebuie să instalați mai întâi bibliotecile de sistem - aveți nevoie atât de Cairo, cât și de Pango, care la rândul lor au nevoie de GLib. Toate acestea ar trebui să fie instalate împreună cu fișierele de dezvoltare și datele de introspecție GObject.
Cerințe hardware¶
Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):
3 GB of RAM
2 nuclee CPU
1 GB de spațiu de stocare
Notă
Cerințele reale pentru instalarea Weblate variază foarte mult în funcție de dimensiunea traducerilor gestionate în cadrul acesteia.
Memory usage¶
The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.
Sugestie
For systems with less memory than recommended, Single-process Celery setup is recommended.
CPU usage¶
Many concurrent users increase the amount of needed CPU cores.
Storage usage¶
The typical database storage usage is around 300 MB per 1 million hosted words.
Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.
Nodes¶
For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) can be run on a single node.
When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Configurarea bazei de date pentru Weblate).
Verificarea semnăturilor de eliberare¶
Weblate release are cryptographically signed using Sigstore signatures. The signatures are attached to the GitHub release.
The verification can be performed using sigstore package. The following example verifies signature of the 5.4 release:
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
Permisiunile sistemului de fișiere¶
Procesul Weblate trebuie să fie capabil să citească și să scrie în directorul în care păstrează datele - DATA_DIR. Toate fișierele din acest director trebuie să fie deținute și scriere de către utilizatorul care rulează toate procesele Weblate (de obicei WSGI și Celery, a se vedea Rularea serverului și Sarcini de fundal folosind Celery).
Configurația implicită le plasează în același arbore ca și sursele Weblate, însă ați putea prefera să le mutați într-o locație mai bună, cum ar fi: /var/lib/weblate.
Weblate încearcă să creeze aceste directoare în mod automat, dar nu va reuși dacă nu are permisiuni pentru a face acest lucru.
De asemenea, trebuie să aveți grijă când rulați Comenzi de gestionare, deoarece acestea ar trebui să fie rulate sub același utilizator cu cel care rulează Weblate însuși, altfel permisiunile pentru unele fișiere ar putea fi greșite.
În containerul Docker, toate fișierele din volumul /app/data trebuie să fie deținute de utilizatorul weblate din container (UID 1000).
Vezi și
Configurarea bazei de date pentru Weblate¶
Se recomandă ca Weblate să ruleze cu un server de baze de date PostgreSQL.
PostgreSQL 12 and higher is supported. PostgreSQL 15 or newer is recommended.
MySQL și MariaDB is supported, but not recommended for new installs.
Notă
No other database servers are currently supported, but support for other Django supported databases should be possible to implement.
Vezi și
Utilizați un motor de baze de date puternic, Databases, Migrarea de la alte baze de date la PostgreSQL
Database connections¶
In the default configuration, each Weblate process keeps a persistent
connection to the database. Persistent connections improve Weblate
responsiveness, but might require more resources for the database server.
Please consult CONN_MAX_AGE and
Persistent connections for more info.
Weblate needs at least the following number of connections:
\((4 \times \mathit{nCPUs}) + 2\) for Celery processes
\(\mathit{nCPUs} + 1\) for WSGI workers
This applies to Docker container defaults and example configurations provided in this documentation, but the numbers will change once you customize the amount of WSGI workers or adjust parallelism of Celery.
The actual limit for the number of database connections needs to be higher to account following situations:
Comenzi de gestionare need their connection as well.
If case process is killed (for example by OOM killer), it might block the existing connection until timeout.
PostgreSQL¶
PostgreSQL este, de obicei, cea mai bună alegere pentru site-urile bazate pe Django. Este baza de date de referință utilizată pentru implementarea stratului de baze de date Django.
Notă
Weblate utilizează extensia Trigram, care trebuie instalată separat în unele cazuri. Căutați postgresql-contrib sau un pachet cu nume similar.
Vezi și
Crearea unei baze de date în PostgreSQL¶
De obicei, este o idee bună să executați Weblate într-o bază de date separată și într-un cont de utilizator separat:
# 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
Sugestie
Dacă nu doriți să faceți din utilizatorul Weblate un superutilizator în PostgreSQL, puteți omite acest lucru. În acest caz, va trebui să efectuați manual unele dintre etapele de migrare ca superutilizator PostgreSQL în schema pe care o va folosi Weblate:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Configurarea Weblate pentru a utiliza PostgreSQL¶
Fragmentul settings.py pentru PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Name of role to alter to set parameters in PostgreSQL,
# use in case role name is different than user used for authentication.
# "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,
}
}
Migrarea bazei de date efectuează ALTER ROLE pe rolul bazei de date utilizat de Weblate. În cele mai multe cazuri, numele rolului se potrivește cu numele de utilizator. În configurațiile mai complexe, numele rolului este diferit de numele de utilizator și veți primi o eroare privind inexistența rolului în timpul migrării bazei de date (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Se știe că acest lucru se întâmplă cu Azure Database pentru PostgreSQL, dar nu se limitează la acest mediu. Vă rugăm să setați ALTER_ROLE pentru a schimba numele rolului pe care Weblate ar trebui să îl modifice în timpul migrării bazei de date.
Vezi și
MySQL și MariaDB¶
Atenționare
While MySQL and MariaDB support is still maintained in Weblate, our primary focus is PostgreSQL. It is recommended to use PostgreSQL for new installs, and to migrate existing installs to PostgreSQL, see Migrarea de la alte baze de date la PostgreSQL.
Unele caracteristici Weblate vor funcționa mai bine cu PostgreSQL. Aceasta include căutarea și memoria de traducere, care utilizează ambele caracteristici full-text în baza de date, iar implementarea PostgreSQL este superioară.
Weblate poate fi folosit și cu MySQL sau MariaDB, vă rugăm să consultați MySQL notes și MariaDB notes pentru avertismente legate de utilizarea Django cu acestea. Din cauza limitărilor, se recomandă să folosiți PostgreSQL pentru noile instalări.
Weblate requires MySQL at least 8 or MariaDB at least 10.4.
Următoarea configurație este recomandată pentru Weblate:
Utilizați setul de caractere
utf8mb4pentru a permite reprezentarea planurilor Unicode superioare (de exemplu, emojis).Configurați serverul cu
innodb_large_prefixpentru a permite indici mai lungi pentru câmpurile text.Setați nivelul de izolare la
READ COMMITTED.Modul SQL trebuie să fie setat la
STRICT_TRANS_TABLES.
MySQL 8.x, MariaDB 10.5.x sau mai nou au o configurație implicită rezonabilă, astfel încât nu ar trebui să fie necesară nicio modificare a serverului și tot ceea ce este necesar poate fi configurat pe partea de client.
Mai jos este un exemplu de /etc/my.cnf.d/server.cnf pentru un server cu 8 GB de RAM. Aceste setări ar trebui să fie suficiente pentru majoritatea instalațiilor. MySQL și MariaDB au reglaje care vor crește performanțele serverului, care sunt considerate a nu fi necesare decât dacă plănuiți să aveți un număr mare de utilizatori simultani care să acceseze sistemul. Consultați documentația diferiților furnizori pentru aceste detalii.
Este absolut esențial, pentru a reduce problemele la instalare, ca setarea innodb_file_per_table să fie setată corect și MySQL/MariaDB să fie repornit înainte de a începe instalarea Weblate.
[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci
datadir=/var/lib/mysql
log-error=/var/log/mariadb/mariadb.log
innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES
Sugestie
În cazul în care primiți eroarea #1071 - Cheia specificată a fost prea lungă; lungimea maximă a cheii este de 767 octeți, vă rugăm să vă actualizați configurația pentru a include setările innodb de mai sus și să reporniți instalarea.
Sugestie
În cazul în care primiți eroarea #2006 - MySQL server has gone away, configurarea CONN_MAX_AGE v-ar putea ajuta.
Vezi și
Configurarea Weblate pentru a utiliza MySQL/MariaDB¶
Fragmentul settings.py pentru MySQL și MariaDB:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.mysql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "127.0.0.1",
# Set to empty string for default
"PORT": "3306",
# In case you wish to use additional
# connection options
"OPTIONS": {},
}
}
De asemenea, trebuie să creați contul de utilizator weblate în MySQL sau MariaDB înainte de a începe instalarea. Utilizați comenzile de mai jos pentru a realiza acest lucru:
GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Vezi și
Alte configurații¶
Configurarea e-mailului de ieșire¶
Weblate trimite e-mailuri cu diferite ocazii - pentru activarea contului și la diferite notificări configurate de utilizatori. Pentru aceasta are nevoie de acces la un server SMTP.
Configurarea serverului de poștă electronică este configurată cu ajutorul acestor setări: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER și EMAIL_PORT. Numele lor sunt destul de explicite, dar puteți găsi mai multe informații în documentația Django.
Sugestie
În cazul în care primiți o eroare de autentificare neacceptată (de exemplu SMTP AUTH extension not supported by server), cel mai probabil aceasta este cauzată de utilizarea unei conexiuni nesigure și serverul refuză să se autentifice în acest mod. Încercați să activați EMAIL_USE_TLS în acest caz.
Rularea în spatele unui proxy invers¶
Mai multe funcții din Weblate se bazează pe posibilitatea de a obține adresa IP a clientului. Printre acestea se numără Limitarea ratei, Protecția împotriva spam-ului sau Jurnal de audit.
În configurația implicită, Weblate analizează adresa IP din REMOTE_ADDR care este setată de gestionarul WSGI.
În cazul în care utilizați un proxy invers, acest câmp va conține, cel mai probabil, adresa acestuia. Trebuie să configurați Weblate pentru a avea încredere în antetele HTTP suplimentare și să analizați adresa IP din acestea. Acest lucru nu poate fi activat în mod implicit, deoarece ar permite falsificarea adresei IP pentru instalațiile care nu utilizează un proxy invers. Activarea IP_BEHIND_REVERSE_PROXY ar putea fi suficientă pentru cele mai obișnuite configurații, dar poate fi necesar să ajustați IP_PROXY_HEADER și IP_PROXY_OFFSET.
Un alt lucru de care trebuie să aveți grijă este antetul Host. Acesta ar trebui să corespundă cu ceea ce este configurat ca SITE_DOMAIN. Ar putea fi necesară o configurare suplimentară în proxy-ul invers (de exemplu, utilizați ProxyPreserveHost On pentru Apache sau proxy_set_header Host $host; cu nginx).
HTTP proxy¶
Weblate execută comenzi VCS și acceptă configurația proxy din mediul înconjurător. Abordarea recomandată este de a defini setările proxy în settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Vezi și
Ajustarea configurației¶
Vezi și
Copiați weblate/settings_example.py în weblate/settings.py și ajustați-l pentru a se potrivi cu configurația dumneavoastră. Probabil că veți dori să ajustați următoarele opțiuni:
ADMINS
Lista de administratori de site care trebuie să primească notificări atunci când ceva nu merge bine, de exemplu, notificări privind fuziunile eșuate sau erorile Django.
Contact form sends e-mail on these as well unless
ADMINS_CONTACTis configured.
ALLOWED_HOSTS
Trebuie să setați acest lucru pentru a lista gazdele pe care site-ul tău trebuie să le deservească. De exemplu:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativ, puteți include caractere wildcard:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configurați modul în care vor fi stocate sesiunile dvs. În cazul în care păstrați motorul implicit al bazei de date backend, ar trebui să programați: weblate clearsessions pentru a elimina din baza de date datele vechi ale sesiunilor.
Dacă utilizați Redis ca memorie cache (a se vedea Activați memoria cache), este recomandat să o utilizați și pentru sesiuni:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
DATABASES
Conectivitatea la serverul de baze de date, vă rugăm să consultați documentația Django pentru mai multe detalii.
DEBUG
Dezactivați acest lucru pentru orice server de producție. Cu modul de depanare activat, Django va arăta utilizatorilor backtraces în caz de eroare, când îl dezactivați, erorile vor fi trimise prin e-mail către
ADMINS(vezi mai sus).Modul de depanare încetinește, de asemenea, Weblate, deoarece Django stochează mult mai multe informații pe plan intern în acest caz.
Vezi și
DEFAULT_FROM_EMAIL
Adresa de e-mail a expeditorului pentru e-mailurile de ieșire, de exemplu e-mailurile de înregistrare.
Vezi și
SECRET_KEY
Cheia folosită de Django pentru a semna unele informații în cookie-uri, vezi Cheia secretă Django pentru mai multe informații.
Vezi și
SERVER_EMAIL
E-mail utilizat ca adresă de expeditor pentru trimiterea de e-mailuri către administrator, de exemplu notificări privind fuziunile eșuate.
Vezi și
Completarea bazei de date¶
After your configuration is ready, you can run
migrate to create the database structure. Now you should be
able to create translation projects using the admin interface.
După ce ați terminat, ar trebui, de asemenea, să verificați Raportul de performanță din interfața de administrare, care vă va oferi indicii cu privire la o potențială configurație neoptimă a site-ului dumneavoastră.
Vezi și
Configurarea producției¶
Pentru o configurație de producție, trebuie să efectuați ajustările descrise în secțiunile următoare. Cele mai critice setări vor declanșa un avertisment, care este indicat printr-un semn de exclamare în bara de sus dacă sunteți conectat ca superutilizator:
De asemenea, se recomandă să inspectați verificările declanșate de Django (deși s-ar putea să nu fie nevoie să le reparați pe toate):
weblate check --deploy
You can also review the very same checklist at Raport de performanță in the Interfața de gestionare.
Vezi și
Dezactivați modul de depanare¶
Dezactivați modul de depanare al lui Django (DEBUG) prin:
DEBUG = False
Cu modul de depanare activat, Django stochează toate interogările executate și arată utilizatorilor traseele erorilor, ceea ce nu este de dorit într-o configurație de producție.
Vezi și
Configurați în mod corespunzător administratorii¶
Setați adresele de administrator corecte în setarea ADMINS pentru a defini cine va primi e-mailuri în cazul în care ceva nu merge bine pe server, de exemplu:
ADMINS = (("Your Name", "your_email@example.com"),)
Vezi și
Setați domeniul corect al site-ului¶
Ajustați numele site-ului și domeniul în interfața de administrare, altfel linkurile din RSS sau din e-mailurile de înregistrare nu vor funcționa. Acest lucru este configurat cu ajutorul SITE_DOMAIN care trebuie să conțină numele domeniului site-ului.
Schimbat în versiunea 4.2: Înainte de versiunea 4.2, a fost folosit în schimb cadrul Django sites, consultați The “sites” framework.
Configurați corect HTTPS¶
Se recomandă cu tărie să executați Weblate utilizând protocolul HTTPS criptat. După ce îl activați, trebuie să setați ENABLE_HTTPS în setări:
ENABLE_HTTPS = True
Sugestie
Este posibil să doriți să configurați și HSTS, consultați SSL/HTTPS pentru mai multe detalii.
Setați corect SECURE_HSTS_SECONDS¶
Dacă site-ul tău este servit prin SSL, trebuie să ai în vedere setarea unei valori pentru SECURE_HSTS_SECONDS în settings.py pentru a activa HTTP Strict Transport Security. În mod implicit, este setată la 0, așa cum se arată mai jos.
SECURE_HSTS_SECONDS = 0
Dacă este setat la o valoare întreagă diferită de zero, django.middleware.security.SecurityMiddleware setează antetul HTTP Strict Transport Security pe toate răspunsurile care nu îl au deja.
Atenționare
Setarea incorectă a acestui parametru vă poate distruge ireversibil (pentru o perioadă de timp) site-ul. Citiți mai întâi documentația HTTP Strict Transport Security.
Utilizați un motor de baze de date puternic¶
Vă rugăm să folosiți PostgreSQL pentru un mediu de producție, consultați Configurarea bazei de date pentru Weblate pentru mai multe informații.
Folosiți o locație adiacentă pentru a rula serverul de baze de date, în caz contrar performanța sau fiabilitatea rețelei ar putea să vă distrugă experiența Weblate.
Verificați performanța serverului de baze de date sau modificați configurația acestuia, de exemplu folosind PGTune.
Activați memoria cache¶
Dacă este posibil, utilizați Redis din Django prin ajustarea variabilei de configurare CACHES, de exemplu:
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",
},
}
}
Sugestie
În cazul în care modificați setările Redis pentru memoria cache, este posibil să trebuiască să le ajustați și pentru Celery, consultați Sarcini de fundal folosind Celery.
Avatar în memoria cache¶
În plus față de memoria cache a lui Django, Weblate realizează și memoria cache a avatarelor. În acest scop, se recomandă utilizarea unui cache separat, susținut de fișiere:
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,
},
},
}
Configurați trimiterea de e-mailuri¶
Weblate trebuie să trimită e-mailuri în mai multe ocazii, iar aceste e-mailuri trebuie să aibă o adresă de expeditor corectă, vă rugăm să configurați SERVER_EMAIL și DEFAULT_FROM_EMAIL pentru a se potrivi cu mediul dumneavoastră, de exemplu:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Notă
Pentru a dezactiva trimiterea de e-mailuri prin Weblate, setați EMAIL_BACKEND la django.core.mail.backends.dummy.EmailBackend.
Acest lucru va dezactiva toată livrarea de e-mailuri, inclusiv e-mailurile de înregistrare sau de resetare a parolei.
Configurarea gazdelor permise¶
Django are nevoie ca ALLOWED_HOSTS să conțină o listă de nume de domenii pe care site-ul tău are voie să le servească, dacă o lași goală va bloca orice cerere.
În cazul în care acesta nu este configurat pentru a se potrivi cu serverul dumneavoastră HTTP, veți primi erori de tipul Invalid HTTP_HOST header: '1.1.1.1.1'. Este posibil să fie necesar să adăugați '1.1.1.1.1' la ALLOWED_HOSTS.
Sugestie
Pe containerul Docker, acest lucru este disponibil ca WEBLATE_ALLOWED_HOSTS.
Cheia secretă Django¶
Setarea SECRET_KEY este folosită de Django pentru a semna cookie-urile și ar trebui să vă generați propria valoare, mai degrabă decât să o folosiți pe cea din exemplul de configurare.
Puteți genera o cheie nouă utilizând weblate-generate-secret-key livrat cu Weblate.
Vezi și
Executarea sarcinilor de întreținere¶
For optimal performance, it is good idea to run some maintenance tasks in the background. This is automatically done by Sarcini de fundal folosind Celery and covers following tasks:
Verificarea stării de sănătate a configurației (din oră în oră).
Committing pending changes (hourly), see Angajări leneșe and
commit_pending.Actualizarea alertelor privind componentele (zilnic).
Actualizarea ramurilor la distanță (noaptea), vezi
AUTO_UPDATE.Translation memory backup to JSON (daily), see
dump_memory.Fulltext and database maintenance tasks (daily and weekly tasks), see
cleanuptrans.
Locațiile și codificarea sistemului¶
Locațiile de sistem trebuie configurate cu cele care acceptă UTF-8. Pe majoritatea distribuțiilor Linux, aceasta este setarea implicită. În cazul în care nu este cazul în sistemul dumneavoastră, vă rugăm să schimbați localele în varianta UTF-8.
De exemplu, prin editarea /etc/default/locale și setarea acolo LANG="C.UTF-8".
În unele cazuri, serviciile individuale au o configurație separată pentru localități. Acest lucru variază în funcție de distribuție și de serverele web, așa că verifică documentația pachetelor serverului tău web.
Apache pe Ubuntu utilizează /etc/apache2/envvvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache pe CentOS utilizează /etc/sysconfig/httpd (sau /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Comprimarea activelor clienților¶
Weblate vine cu o mulțime de fișiere JavaScript și CSS. Din motive de performanță, este bine să le comprimați înainte de a le trimite către un client. În configurația implicită, acest lucru se face din mers, cu un mic cost suplimentar. În cazul instalațiilor mari, se recomandă activarea modului de compresie offline. Acest lucru trebuie făcut în configurație, iar compresia trebuie să fie declanșată la fiecare actualizare Weblate.
Comutarea configurației este simplă prin activarea django.conf.settings.COMPRESS_OFFLINE și prin configurarea django.conf.settings.COMPRESS_OFFLINE_CONTEXT (aceasta din urmă este deja inclusă în configurația de exemplu):
COMPRESS_OFFLINE = True
La fiecare implementare trebuie să comprimați fișierele pentru a se potrivi cu versiunea curentă:
weblate compress
Sugestie
Imaginea oficială Docker are această funcție deja activată.
Rularea serverului¶
Sugestie
În cazul în care nu aveți experiență cu serviciile descrise mai jos, ați putea încerca Instalarea folosind Docker.
Veți avea nevoie de mai multe servicii pentru a rula Weblate, configurația recomandată constă în:
Server de baze de date (vezi Configurarea bazei de date pentru Weblate)
Server cache (vezi Activați memoria cache)
Server web frontend pentru fișiere statice și terminarea SSL (vezi Servirea fișierelor statice)
Server WSGI pentru conținut dinamic (vezi Exemplu de configurare pentru NGINX și uWSGI)
Celery pentru executarea de sarcini de fundal (vezi Sarcini de fundal folosind Celery)
Notă
Există unele dependențe între servicii, de exemplu, memoria cache și baza de date trebuie să ruleze la pornirea proceselor Celery sau uwsgi.
În cele mai multe cazuri, veți rula toate serviciile pe un singur server (virtual), dar în cazul în care instalația dvs. este foarte încărcată, puteți împărți serviciile. Singura limitare în acest sens este că serverele Celery și Wsgi au nevoie de acces la DATA_DIR.
Notă
Procesul WSGI trebuie să fie executat sub același utilizator ca și procesul Celery, în caz contrar fișierele din DATA_DIR vor fi stocate cu proprietate mixtă, ceea ce duce la probleme în timpul execuției.
A se vedea Permisiunile sistemului de fișiere și Sarcini de fundal folosind Celery.
Rularea serverului web¶
Rularea Weblate nu este diferită de rularea oricărui alt program bazat pe Django. Acesta este de obicei executat ca uWSGI sau fcgi (a se vedea mai jos exemple pentru diferite servere web).
În scopuri de testare, puteți utiliza serverul web încorporat în Django:
weblate runserver
Atenționare
NU FOLOSIȚI ACEST SERVER ÎNTR-UN MEDIU DE PRODUCȚIE. Acesta nu a fost supus unor audituri de securitate sau teste de performanță. Consultați, de asemenea, documentația Django privind runserver.
Sugestie
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 in Exemplu de configurare pentru NGINX și uWSGI, Exemplu de configurare pentru Apache, Exemplu de configurare pentru Apache și Gunicorn, and
Servirea fișierelor statice.
Servirea fișierelor statice¶
Django needs to collect its static files in a single directory. To do so,
execute weblate collectstatic --noinput. This will copy the static
files into a directory specified by the STATIC_ROOT setting (this defaults to
a static directory inside CACHE_DIR).
Se recomandă să serviți fișiere statice direct de pe serverul dvs. web, ar trebui să folosiți acest lucru pentru următoarele căi:
- :fișier:`/static/`
Serves static files for Weblate and the admin interface (from defined by
STATIC_ROOT).- :fișier:`/media/`
Utilizat pentru încărcarea de conținut media de către utilizator (de exemplu, capturi de ecran).
- :fișier:`/favicon.ico`
Ar trebui să fie rescrisă pentru a rescrie o regulă pentru a servi
/static/favicon.ico.
Politica de securitate a conținutului¶
Configurația implicită Weblate activează middleware-ul weblate.middleware.SecurityMiddleware care stabilește antetele HTTP legate de securitate, cum ar fi Content-Security-Policy sau X-XSS-Protection. Acestea sunt setate în mod implicit pentru a funcționa cu Weblate și cu configurația sa, dar s-ar putea să fie nevoie de o personalizare pentru mediul dumneavoastră.
Exemplu de configurare pentru NGINX și uWSGI¶
To run production webserver, use the WSGI wrapper installed with Weblate (in
virtual env case it is installed as
~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Don’t
forget to set the Python search path to your virtualenv as well (for example
using virtualenv = /home/user/weblate-env in uWSGI).
Următoarea configurație rulează Weblate ca uWSGI sub serverul web NGINX.
Configurație pentru NGINX (disponibilă și sub forma weblate/examples/weblate.nginx.conf):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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 /media/ {
# DATA_DIR/media/
alias /home/weblate/data/media/;
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;
}
}
Configurație pentru uWSGI (disponibilă și sub forma weblate/examples/weblate.uwsgi.ini):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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
# In case you're using virtualenv uncomment this:
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
Vezi și
Exemplu de configurare pentru Apache¶
Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.
Următoarea configurație rulează Weblate ca WSGI, trebuie să aveți activat mod_wsgi (disponibil ca weblate/examples/apache.conf):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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>
# DATA_DIR/media/
Alias /media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
# Path to your Weblate virtualenv
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>
Notă
Weblate necesită Python 3, așa că asigurați-vă că rulați varianta Python 3 a modwsgi. De obicei, acesta este disponibil ca un pachet separat, de exemplu libapache2-mod-wsgi-py3.
Use matching Python version to install Weblate.
Exemplu de configurare pentru Apache și Gunicorn¶
Următoarea configurație rulează Weblate în Gunicorn și Apache 2.4 (disponibilă ca weblate/examples/apache.gunicorn.conf):
#
# 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 virtualenv 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>
# DATA_DIR/media/
Alias /media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
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 /media/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Vezi și
Rularea Weblate sub calea de acces¶
Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.
Un exemplu de configurare Apache pentru a servi Weblate sub /weblate. Din nou, folosind mod_wsgi (disponibil și ca weblate/examples/apache-path.conf):
# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv 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>
# DATA_DIR/media/
Alias /weblate/media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
# Path to your Weblate virtualenv
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>
În plus, va trebui să ajustați weblate/settings.py:
URL_PREFIX = "/weblate"
Sarcini de fundal folosind Celery¶
Weblate utilizează Celery pentru a executa sarcini regulate și de fundal. Se presupune că trebuie să rulați un serviciu Celery care să le execute. De exemplu, acesta este responsabil pentru gestionarea următoarelor operațiuni (această listă nu este completă):
Primirea de webhooks de la servicii externe (a se vedea Cârlige notificare).
Executarea sarcinilor de întreținere regulate, cum ar fi copii de rezervă, curățări, adăugări zilnice sau actualizări (a se vedea Copierea de rezervă și mutarea Weblate,
BACKGROUND_TASKS, Suplimente).Rulează Traducere automată.
Trimiterea de notificări de sinteză.
Offloading expensive operations from the WSGI process.
Angajarea modificărilor în așteptare (a se vedea Angajări leneșe).
O configurație tipică care utilizează Redis ca backend arată astfel:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Vezi și
Configurarea brokerului Redis în Celery <celery:broker-redis-configuration>`
De asemenea, ar trebui să porniți lucrătorul Celery pentru a procesa sarcinile și pentru a porni sarcinile programate; acest lucru poate fi făcut direct din linia de comandă (ceea ce este util mai ales atunci când depanați sau dezvoltați):
./weblate/examples/celery start
./weblate/examples/celery stop
Notă
Procesul Celery trebuie să fie executat sub același utilizator ca și procesul WSGI, în caz contrar fișierele din DATA_DIR vor fi stocate cu proprietate mixtă, ceea ce duce la probleme în timpul execuției.
A se vedea Permisiunile sistemului de fișiere și Rularea serverului.
Executing Celery tasks in the WSGI using eager mode¶
Notă
Acest lucru va avea un impact sever asupra performanțelor interfeței web și va întrerupe caracteristicile care depind de declanșarea regulată (de exemplu, comiterea modificărilor în așteptare, notificările Digest sau copiile de rezervă).
Pentru dezvoltare, este posibil să doriți să utilizați configurația eager, care procesează toate sarcinile pe loc:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Rularea Celery ca serviciu de sistem¶
Cel mai probabil, veți dori să rulați Celery ca demon, iar acest lucru este acoperit de Daemonization. Pentru cea mai obișnuită configurație Linux care utilizează systemd, puteți utiliza fișierele de exemplu livrate în dosarul examples listat mai jos.
Unitatea Systemd va fi plasată ca /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
Configurația de mediu care urmează să fie plasată ca /etc/default/celery-weblate:
# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"
# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"
# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"
# Extra command-line arguments to the worker,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
--queues:notify=notify --prefetch-multiplier:notify=10 \
--queues:memory=memory --prefetch-multiplier:memory=10 \
--queues:translate=translate --prefetch-multiplier:translate=4 \
--concurrency:backup=1 --queues:backup=backup --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"
Configurație suplimentară pentru a roti jurnalele Celery folosind logrotate pentru a fi plasată ca /etc/logrotate.d/celery:
# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Sarcini periodice folosind Celery beat¶
Weblate vine cu o configurare integrată pentru sarcini programate. Cu toate acestea, puteți defini sarcini suplimentare în settings.py, de exemplu, consultați Angajări leneșe.
Sarcinile ar trebui să fie executate de demonul Celery beats. În cazul în care acesta nu funcționează corect, este posibil să nu fie în funcțiune sau baza sa de date a fost coruptă. În acest caz, verificați jurnalele de pornire Celery pentru a afla cauza principală.
Monitorizarea stării Celery¶
You can find current length of the Celery task queues in the
Interfața de gestionare or you can use celery_queues on the
command-line. In case the queue will get too long, you will also get
configuration error in the admin interface.
Atenționare
În mod implicit, erorile Celery sunt înregistrate doar în jurnalul Celery și nu sunt vizibile pentru utilizator. În cazul în care doriți să aveți o imagine de ansamblu asupra acestor eșecuri, se recomandă să configurați Collecting error reports and monitoring performance.
Single-process Celery setup¶
In case you have very limited memory, you might want to reduce number of Weblate processes. All Celery tasks can be executed in a single process using:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Atenționare
This will have a noticeable performance impact on Weblate.
Monitorizarea Weblate¶
Weblate oferă URL-ul /healthz/ pentru a fi utilizat în verificări simple ale stării de sănătate, de exemplu, folosind Kubernetes. Containerul Docker are încorporată o verificare a stării de sănătate folosind acest URL.
Pentru monitorizarea metricilor Weblate puteți utiliza punctul final API GET /api/metrics/.
Collecting error reports and monitoring performance¶
Weblate, ca orice alt software, poate da greș. Pentru a colecta stări de eșec utile, vă recomandăm să utilizați servicii terțe pentru a colecta astfel de informații. Acest lucru este util mai ales în cazul sarcinilor Celery care eșuează, care altfel ar raporta erori doar în jurnale și nu veți fi notificat cu privire la acestea. Weblate are suport pentru următoarele servicii:
Sentry¶
Weblate are suport încorporat pentru Sentry. Pentru a-l utiliza, este suficient să setați SENTRY_DSN în settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry can be also used to monitor performance of Weblate by collecting traces
and profiles for defined percentage of operations. This can be configured using
SENTRY_TRACES_SAMPLE_RATE and SENTRY_PROFILES_SAMPLE_RATE.
Rollbar¶
Weblate are suport încorporat pentru Rollbar. Pentru a-l utiliza, este suficient să urmați instrucțiunile pentru Rollbar notifier for Python.
Pe scurt, trebuie să ajustați 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",
"client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Restul este integrat automat, iar acum veți colecta atât erorile de pe server, cât și cele de pe partea clientului.
Notă
Error logging also includes exceptions that were gracefully handled, but might indicate a problem - such as failed parsing of an uploaded file.
Migrarea Weblate pe un alt server¶
Migrarea Weblate pe un alt server ar trebui să fie destul de ușoară, însă acesta stochează date în câteva locații pe care trebuie să le migrați cu atenție. Cea mai bună abordare este să opriți Weblate pentru migrare.
Migrarea bazei de date¶
Depending on your database backend, you might have several options to migrate the database. The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. mysqldump or pg_dump). Alternatively you can use replication in case your database supports it.
Vezi și
Migrating between databases described in Migrarea de la alte baze de date la PostgreSQL.
Migrarea depozitelor VCS¶
Depozitele VCS stocate în DATA_DIR trebuie, de asemenea, să fie migrate. Puteți să le copiați pur și simplu sau să folosiți rsync pentru a face migrarea mai eficient.
Alte note¶
Nu uitați să mutați și alte servicii pe care Weblate le-ar fi putut folosi, cum ar fi Redis, Cron jobs sau backend-uri de autentificare personalizate.