Instruções de configuração¶
Instalando o Weblate¶
Dependendo da sua configuração e experiência, escolha um método de instalação apropriado para você:
Instalando usando Docker, recomendado para configurações de produção.
Instalação com virtualenv, recomendada para configurações de produção:
Instalando a partir do código-fonte, recomendado para o desenvolvimento.
Architecture overview¶
- Servidor web
Handling incoming HTTP requests, Servindo arquivos estáticos.
- Celery workers
Tarefas de fundo usando 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.
- Banco de dados
PostgreSQL database server for storing all the content, see Configuração de banco de dados para o Weblate.
Use dedicated database node for sites with hundreds of millions of hosted words.
- Redis
Servidor Redis para cache e fila de tarefas, consulte Tarefas de fundo usando 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 Configuração de e-mail de saída. It can be provided externally.
Dica
Instalando usando Docker includes PostgreSQL and Redis, making the installation easier.
Requisitos de software¶
Sistema operacional¶
Weblate é conhecido por funcionar no Linux, FreeBSD e macOS. Outros sistemas como o Unix provavelmente funcionarão também.
O Weblate não é suportado no Windows. Mas ainda pode funcionar e patches são aceitos alegremente.
Ver também
Architecture overview describes overall Weblate architecture and required services.
Dependências 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
.
As dependências mais notáveis:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
pip extra |
Python Package |
Weblate feature |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
MySQL or MariaDB, see Configuração de banco de dados para o Weblate |
|
|
||
|
PostgreSQL, see Configuração de banco de dados para o Weblate |
|
|
||
|
Ao instalar usando pip, você pode especificar diretamente os recursos desejados ao instalar:
pip install "Weblate[Postgres,Amazon,SAML]"
Ou você pode instalar o Weblate com todos os recursos opcionais:
pip install "Weblate[all]"
Ou você pode instalar o Weblate sem quaisquer recursos opcionais:
pip install Weblate
Outros requisitos do sistema¶
As seguintes dependências devem ser instaladas no sistema:
Git
- Pango, Cairo e arquivos de cabeçalho relacionados e dados de introspecção GObject
https://cairographics.org/, https://pango.gnome.org/, veja Pango e Cairo
git-review
(opcional para suporte a Gerrit)git-svn
(opcional para suporte a Subversion)tesseract
(needed only if tesserocr binary wheels are not available for your system)licensee
(opcional para detectar a licença ao criar o componente)
Dependências de tempo de compilação¶
Para compilar alguns das dependências Python, você pode precisar instalar suas dependências. Isso depende de como você instalá-las, por isso consulte pacotes individuais para obter documentação. Você não precisará deles se usar Wheels
pré-compilado durante a instalação usando pip
ou quando você usar pacotes de distribuição.
Pango e Cairo¶
O Weblate usa Pango e Cairo para renderizar widgets bitmap (ver Promovendo a tradução) e verificações de renderização (ver Gerenciando fontes). Para instalar corretamente as ligações Python para aqueles que você precisa instalar bibliotecas de sistemas primeiro - você precisa tanto do Cairo quanto do Pango, que por sua vez precisam de GLib. Todos esses devem ser instalados com arquivos de desenvolvimento e dados de introspecção GObject.
Requisitos de 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 núcleos de CPU
1 GB de espaço de armazenamento
Nota
Os requisitos reais para a sua instalação do Weblate variam fortemente com base no tamanho das traduções gerenciadas nele.
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.
Dica
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 Configuração de banco de dados para o Weblate).
Verificando assinaturas de lançamento¶
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
Permissões do sistema de arquivos¶
O processo Weblate precisa ser capaz de ler e escrever para o diretório onde mantém os dados – DATA_DIR
. Todos os arquivos dentro deste diretório devem ser de propriedade e graváveis pelo usuário que executa todos os processos do Weblate (geralmente WSGI e Celery, veja Executando servidor e Tarefas de fundo usando Celery).
A configuração padrão coloca-os na mesma árvore que os fontes do Weblate, no entanto, você pode preferir movê-los para um local melhor, como /var/lib/weblate
.
O Weblate tenta criar esses diretórios automaticamente, mas ele falhará quando não tiver permissões para fazê-lo.
Você também deve tomar cuidado ao executar Comandos de gerência, pois eles devem ser executados sob o mesmo usuário que o Weblate em si está sendo executado, caso contrário, permissões em alguns arquivos podem estar erradas.
No contêiner Docker, todos os arquivos no volume /app/data
tem de ter como dono o usuário weblate
dentro do contêiner (UID 1000).
Ver também
Configuração de banco de dados para o Weblate¶
Recomenda-se executar o Weblate com um servidor de banco de dados PostgreSQL.
PostgreSQL 12 and higher is supported. PostgreSQL 15 or newer is recommended.
MySQL e MariaDB is supported, but not recommended for new installs.
Nota
No other database servers are currently supported, but support for other Django supported databases should be possible to implement.
Ver também
Usar um poderoso mecanismo de banco de dados, Databases, Migrando de outros bancos de dados para o 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:
Comandos de gerência 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 é geralmente a melhor escolha para sites baseados em Django. É o banco de dados de referência usado para implementar a camada de banco de dados Django.
Nota
O Weblate usa uma extensão de trigrama que deve ser instalada separadamente em alguns casos. Procure por postgresql-contrib
ou um pacote com nome similar.
Ver também
Criando um banco de dados no PostgreSQL¶
Geralmente é uma boa ideia executar o Weblate em um banco de dados separado e separar a conta do usuário:
# 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
Dica
Se você não quiser fazer do usuário do Weblate um superusuário no PostgreSQL, você pode omitir isso. Nesse caso, você terá que executar algumas das etapas de migração manualmente como um superusuário PostgreSQL no esquema Weblate usará:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Configurando Weblate para usar PostgreSQL¶
O trecho de settings.py
para 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,
}
}
A migração do banco de dados executa ALTER ROLE na função de banco de dados usada pelo Weblate. Na maioria dos casos, o nome da função corresponde ao nome de usuário. Em configurações mais complexas, o nome da função é diferente do nome de usuário e você obterá um erro sobre a função não existente durante a migração do banco de dados (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist
). Isso é conhecido por acontecer com o Azure Database para PostgreSQL, mas não está limitado a este ambiente. Defina ALTER_ROLE
para alterar o nome da função que o Weblate deve alterar durante a migração do banco de dados.
Ver também
MySQL e MariaDB¶
Aviso
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 Migrando de outros bancos de dados para o PostgreSQL.
Alguns recursos do Weblate terão melhor desempenho com PostgreSQL. Isso inclui a memória de pesquisa e tradução, que ambos utilizam recursos de texto completo no banco de dados e a implementação do PostgreSQL é superior.
Weblate também pode ser usado com MySQL ou MariaDB, consulte MySQL notes e MariaDB notes para ressalvas ao uso do Django com elas. or causa das limitações, é recomendado usar PostgreSQL para novas instalações.
Weblate requires MySQL at least 8 or MariaDB at least 10.4.
A seguinte configuração é recomendada para Weblate:
Use o conjunto de caracteres
utf8mb4
para permitir a representação de planos Unicode mais altos (por exemplo, emojis).Configure o servidor com
innodb_large_prefix
para permitir índices mais longos em campos de texto.Defina o nível de isolamento para
READ COMMITTED
.O modo SQL deve ser definido como
STRICT_TRANS_TABLES
.
MySQL 8.x, MariaDB 10.5.x ou mais recente têm uma configuração padrão razoável, de modo que nenhum ajuste de servidor deve ser necessário e tudo o que é necessário pode ser configurado no lado do cliente.
Abaixo está um exemplo /etc/my.cnf.d/server.cnf
para um servidor com 8 GB de RAM. Essas configurações devem ser suficientes para a maioria das instalações. MySQL e MariaDB têm ajustáveis que irão aumentar o desempenho do seu servidor que são considerados desnecessários, a menos que você esteja planejando ter um grande número de usuários simultâneos acessando o sistema. Consulte a documentação de vários fornecedores sobre esses detalhes.
É absolutamente crítico para reduzir problemas durante a instalação que a configuração innodb_file_per_table
esteja configurada corretamente e o MySQL/MariaDB reiniciado antes de você iniciar a instalação do 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
Dica
No caso de você estar recebendo o erro #1071 - Specified key was too long; max key length is 767 bytes
, atualize sua configuração para incluir as configurações innodb
acima e reinicie sua instalação.
Dica
No caso de você estar recebendo o erro #2006 - MySQL server has gone away
, configurar CONN_MAX_AGE
pode ajudar.
Ver também
Configurando Weblate para usar MySQL/MariaDB¶
O trecho de settings.py
para MySQL e 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": {},
}
}
Você também deve criar a conta de usuário weblate
no MySQL ou MariaDB antes de iniciar a instalação. Use os comandos abaixo para fazer isso:
GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Ver também
Outras configurações¶
Configuração de e-mail de saída¶
O Weblate envia e-mails em várias ocasiões - para ativação de conta e sobre várias notificações configuradas pelos usuários. Para isso, ele precisa de acesso a um servidor SMTP.
A configuração do servidor de e-mail é configurada usando essas configurações: EMAIL_HOST
, EMAIL_HOST_PASSWORD
, EMAIL_USE_SSL
, EMAIL_USE_TLS
, EMAIL_HOST_USER
e EMAIL_PORT
. Seus nomes são bastante autoexplicativos, mas você pode encontrar mais informações na documentação do Django.
Dica
Caso você tenha erro sobre autenticação não suportada (por exemplo, SMTP AUTH extension not supported by server
), é provavelmente causada pelo uso de conexão insegura e o servidor se recusa a autenticar dessa forma. Tente ativar EMAIL_USE_TLS
nesse caso.
Executando por trás de um proxy reverso¶
Vários recursos no Weblate dependem de ser capaz de obter endereço IP do cliente. Isso inclui Limitação de taxa, Proteção contra spam ou Registro de auditoria.
Na configuração padrão, o Weblate analisa o endereço IP de REMOTE_ADDR
que é definido pelo manipulador WSGI.
No caso de você estiver usando um proxy reverso, este campo provavelmente conterá seu endereço. Você precisa configurar o Weblate para confiar em cabeçalhos HTTP adicionais e analisar o endereço IP destes. Isso não pode ser ativado por padrão, pois permitiria falsificação de endereço IP para instalações que não usam um proxy reverso. Habilitar IP_BEHIND_REVERSE_PROXY
pode ser suficiente para as configurações mais usuais, mas você pode precisar ajustar IP_PROXY_HEADER
e IP_PROXY_OFFSET
também.
Outra coisa a ajustar é o cabeçalho Host. Deve corresponder ao que está configurado como SITE_DOMAIN
. Configuração adicional pode ser necessária em seu proxy reverso (por exemplo, use ProxyPreserveHost On
para Apache ou proxy_set_header Host $host;
com nginx).
Proxy HTTP¶
O Weblate executa comandos VCS e aqueles que aceitam a configuração proxy do ambiente. A abordagem recomendada é definir configurações de proxy em settings.py
:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Ver também
Ajustando a configuração¶
Ver também
Copie weblate/settings_example.py
para weblate/settings.py
e ajuste-o para corresponder à configuração. Você provavelmente vai querer ajustar as seguintes opções:
ADMINS
Lista de administradores de sites para receber notificações quando algo dá errado, por exemplo, notificações em mesclagens fracassadas ou erros de Django.
Contact form sends e-mail on these as well unless
ADMINS_CONTACT
is configured.Ver também
ADMINS
,ADMINS_CONTACT
, Configurar corretamente administradores
ALLOWED_HOSTS
Você precisa definir isso para listar os hosts que seu site deve servir. Por exemplo:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativamente, você pode incluir curinga:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configure como suas sessões serão armazenadas. Caso você mantenha o mecanismo de backend do banco de dados padrão, você deve agendar: weblate clearsessions para remover dados de sessão obsoletos do banco de dados.
Se você estiver usando o Redis como cache (veja Habilitar o cache) é recomendado usá-lo para sessões também:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Ver também
DATABASES
Conectividade ao servidor de banco de dados, verifique a documentação do Django para obter mais detalhes.
DEBUG
Desabilite isso para qualquer servidor de produção. Com o modo depuração ativado, o Django mostrará backtraces em caso de erro aos usuários, quando você desabilitá-lo, erros serão enviados por e-mail para
ADMINS
(veja acima).O modo depuração também diminui o Weblate, já que o Django armazena muito mais informações internamente neste caso.
Ver também
DEFAULT_FROM_EMAIL
Endereço de remetente de e-mail para e-mail de saída, por exemplo, e-mails de registro.
Ver também
SECRET_KEY
Chave usada por Django para assinar algumas informações em cookies, consulte Chave secreta do Django para obter mais informações.
Ver também
SERVER_EMAIL
E-mail usado como endereço de remetente para envio de e-mails ao administrador, por exemplo, notificações em mesclagens fracassadas.
Ver também
Preenchendo o banco de dados¶
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.
Uma vez feito, você também deve verificar o Relatório de desempenho na interface administrativa, o que lhe dará dicas de configuração potencial não ideal em seu site.
Ver também
Configuração de produção¶
Para uma configuração de produção, você deve realizar ajustes descritos nas seções a seguir. As configurações mais críticas acionarão um aviso, que é indicado por um ponto de exclamação na barra superior se conectado como um superusuário:
Também é recomendado inspecionar verificações desencadeadas por Django (embora você possa não precisar corrigir todas elas):
weblate check --deploy
You can also review the very same checklist at Relatório de desempenho in the Interface de gerenciamento.
Ver também
Desabilitar o modo de depuração¶
Desabilite o modo de depuração do Django (DEBUG
) com:
DEBUG = False
Com o modo depuração ativado, o Django armazena todas as consultas executadas e mostra aos usuários atrasos de erros, o que não é desejado em uma configuração de produção.
Ver também
Configurar corretamente administradores¶
Defina os endereços de administração corretos para a configuração ADMINS
para definir quem receberá e-mails caso algo dê errado no servidor, por exemplo:
ADMINS = (("Your Name", "your_email@example.com"),)
Ver também
Definir domínio correto do site¶
Ajuste o nome e o domínio do site na interface administrativa, caso contrário, links no RSS ou e-mails de registro não funcionarão. Isso é configurado usando SITE_DOMAIN
que deve conter o nome de domínio do site.
Alterado na versão 4.2: Antes da versão 4.2, a estrutura de sites do Django era usada em vez disso, consulte The “sites” framework.
Configurar corretamente HTTPS¶
É fortemente recomendado executar Weblate usando o protocolo HTTPS criptografado. Depois de habilitá-lo, você deve definir ENABLE_HTTPS
nas configurações:
ENABLE_HTTPS = True
Dica
Você pode querer configurar o HSTS também, consulte SSL/HTTPS para obter mais detalhes.
Definir corretamente SECURE_HSTS_SECONDS¶
Se o seu site for servido sobre SSL, você deve considerar definir um valor para SECURE_HSTS_SECONDS
no settings.py
para habilitar HTTP Strict Transport Security. Por padrão, ele está definido para 0 como mostrado abaixo.
SECURE_HSTS_SECONDS = 0
Se definido como um valor inteiro não-zero, o cabeçalho django.middleware.security.SecurityMiddleware
define o cabeçalho HTTP Strict Transport Security em todas as respostas que ainda não o possuem.
Aviso
Definir isso incorretamente pode quebrar irreversivelmente (por algum tempo) seu site. Leia primeiro a documentação HTTP Strict Transport Security.
Usar um poderoso mecanismo de banco de dados¶
Por favor, use PostgreSQL para um ambiente de produção, consulte Configuração de banco de dados para o Weblate para obter mais informações.
Use um local adjacente para executar o servidor de banco de dados, caso contrário, o desempenho ou confiabilidade da rede podem arruinar sua experiência com o Weblate.
Verifique o desempenho do servidor de banco de dados ou ajuste sua configuração, por exemplo, usando PGTune.
Habilitar o cache¶
Se possível, use Redis do Django ajustando a variável de configuração CACHES
, por exemplo:
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",
},
}
}
Dica
Caso você altere as configurações do Redis para o cache, pode ser necessário ajustá-las também para o Celery, consulte Tarefas de fundo usando Celery.
Ver também
Cache de avatares¶
Além do cache de Django, Weblate realiza cache de avatares. Recomenda-se usar um cache separado, baseado em arquivos para este fim:
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,
},
},
}
Configurar envio de e-mail¶
O Weblate precisa enviar e-mails em várias ocasiões, e esses e-mails devem ter um endereço de remetente correto, por favor, configure SERVER_EMAIL
e DEFAULT_FROM_EMAIL
para combinar com o seu ambiente, por exemplo:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Nota
Para desabilitar o envio de e-mails pelo Weblate, defina EMAIL_BACKEND
para django.core.mail.backends.dummy.EmailBackend
.
Isso desabilitará toda entrega de e-mail, incluindo e-mails de registro ou redefinição de senha.
Configuração de hosts permitidos¶
Django requer ALLOWED_HOSTS
para manter uma lista de nomes de domínio que seu site pode servir, deixando-o vazio bloqueará quaisquer solicitações.
Caso isso não esteja configurado para corresponder ao seu servidor HTTP, você terá erros como Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Dica
No contêiner Docker, isso está disponível como WEBLATE_ALLOWED_HOSTS
.
Chave secreta do Django¶
A configuração SECRET_KEY
é usada pelo Django para assinar cookies, e você deve realmente gerar seu próprio valor em vez de usar o da configuração do exemplo.
Você pode gerar uma nova chave usando weblate/examples/generate-secret-key
, que vem com o Weblate.
Ver também
Executando tarefas de manutenção¶
For optimal performance, it is good idea to run some maintenance tasks in the background. This is automatically done by Tarefas de fundo usando Celery and covers following tasks:
Verificação de saúde da configuração (de hora em hora).
Committing pending changes (hourly), see Commits adiados and
commit_pending
.Atualização de alertas de componentes (diariamente).
Atualização dos ramos remotos (nightly), consulte
AUTO_UPDATE
.Translation memory backup to JSON (daily), see
dump_memory
.Fulltext and database maintenance tasks (daily and weekly tasks), see
cleanuptrans
.
Codificação e localidades do sistema¶
As localidades do sistema devem ser configuradas para UTF-8. Na maioria das distribuições Linux, esta é a configuração padrão. Caso não seja o caso em seu sistema, altere as localidades para a variante UTF-8.
Por exemplo, editando /etc/default/locale
e definindo lá LANG="C.UTF-8"
.
Em alguns casos, os serviços individuais têm configuração separada para locais. Isso varia entre a distribuição e os servidores da web, portanto, verifique a documentação dos pacotes do servidor da web para isso.
Apache no Ubuntu usa /etc/apache2/envvars
:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache no CentOS usa /etc/sysconfig/httpd
(ou /opt/rh/httpd24/root/etc/sysconfig/httpd
):
LANG='en_US.UTF-8'
Comprimindo os ativos do cliente¶
Weblate vem com um monte de arquivos JavaScript e CSS. Por razões de desempenho, é bom comprimi-los antes de enviar para um cliente. Na configuração padrão isso é feito na mosca ao custo de pouca sobrecarga. Em grandes instalações, recomenda-se ativar o modo de compressão offline. Isso precisa ser feito na configuração e a compressão tem que ser acionada em cada atualização do Weblate.
A mudança da configuração é simples ao habilitar django.conf.settings.COMPRESS_OFFLINE
e configuração django.conf.settings.COMPRESS_OFFLINE_CONTEXT
(este último já está incluído na configuração do exemplo):
COMPRESS_OFFLINE = True
Em cada implantação você precisa compactar os arquivos para corresponder à versão atual:
weblate compress
Dica
A imagem oficial do Docker já tem este recurso habilitado.
Executando servidor¶
Dica
No caso de você não ter experiência com os serviços descritos abaixo, você pode tentar seguir Instalando usando Docker.
Você precisará de vários serviços para executar o Weblate, a configuração recomendada consiste em:
Servidor de banco de dados (consulte Configuração de banco de dados para o Weblate)
Servidor de cache (consulte Habilitar o cache)
Servidor web frontend para arquivos estáticos e terminação SSL (consulte Servindo arquivos estáticos)
Servidor WSGI para conteúdo dinâmico (consulte Amostra de configuração para NGINX e uWSGI)
Celery para executar tarefas em segundo plano (consulte Tarefas de fundo usando Celery)
Nota
Existem algumas dependências entre os serviços, por exemplo, o cache e o banco de dados devem estar em execução ao iniciar os processos de Celery ou uwsgi.
Na maioria dos casos, você executará todos os serviços em um único servidor (virtual), mas no caso de sua instalação estar muito carregada, você pode dividir os serviços. A única limitação disso é que os servidores Celery e Wsgi precisam acessar DATA_DIR
.
Nota
O processo de WSGI deve ser executado sob o mesmo usuário que o processo do Celery, caso contrário, os arquivos em DATA_DIR
serão armazenados com propriedade mista, levando a problemas de tempo de execução.
Veja também Permissões do sistema de arquivos e Tarefas de fundo usando Celery.
Executando servidor web¶
Executar o Weblate não é diferente de executar qualquer outro programa baseado em Django. Django é geralmente executado como uWSGI ou fcgi (consulte exemplos para diferentes servidores web abaixo).
Para fins de teste, você pode usar o servidor web embutido no Django:
weblate runserver
Aviso
NÃO USE ESTE SERVIDOR EM UMA CONFIGURAÇÃO DE PRODUÇÃO. Ele não passou por auditorias de segurança ou testes de desempenho. Veja também a documentação de Django no runserver
.
Dica
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 Amostra de configuração para NGINX e uWSGI, Amostra de configuração para o Apache, Amostra de configuração para Apache e Gunicorn, and
Servindo arquivos estáticos.
Servindo arquivos estáticos¶
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
).
Recomenda-se servir arquivos estáticos diretamente do seu servidor web. Você deve usá-los para os seguintes caminhos:
/static/
Serves static files for Weblate and the admin interface (from defined by
STATIC_ROOT
)./media/
Usado para envio de mídia pelo usuário (por exemplo, capturas de tela).
/favicon.ico
Deve ser reescrito para reescrever uma regra para servir
/static/favicon.ico
.
Política de segurança de conteúdo¶
A configuração padrão do Weblate habilita o middleware weblate.middleware.SecurityMiddleware
que define cabeçalhos HTTP relacionados à segurança como Content-Security-Policy
ou X-XSS-Protection
. Eles são configurados por padrão para funcionar com o Weblate e sua configuração, mas isso pode precisar de personalização para o seu ambiente.
Ver também
CSP_SCRIPT_SRC
,
CSP_IMG_SRC
,
CSP_CONNECT_SRC
,
CSP_STYLE_SRC
,
CSP_FONT_SRC
Amostra de configuração para NGINX e 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).
A configuração a seguir executa o Weblate como uWSGI sob o servidor web NGINX.
Configuração para NGINX (também disponível como 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ção para uWSGI (também disponível como 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
Ver também
Amostra de configuração para o Apache¶
Recomenda-se o uso de prefork de MPM ao usar WSGI com Weblate.
A configuração a seguir executa o Weblate como WSGI. Você precisa ter habilitado mod_wsgi
(disponível como 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>
Nota
Weblate precisa do Python 3, então, por favor se certifique que você está executando a variante do Python 3 do modwsgi. Usualmente, está disponível como um pacote separado, por exemplo libapache2-mod-wsgi-py3
.
Use matching Python version to install Weblate.
Amostra de configuração para Apache e Gunicorn¶
A configuração a seguir executa o Weblate em Gunicorn e Apache 2.4 (disponível como 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>
Ver também
django:tutorial/deployment/wsgi/gunicorn
Rodando Weblate sob o caminho¶
Recomenda-se o uso de prefork de MPM ao usar WSGI com Weblate.
Uma configuração do Apache de amostra para servir o Weblate sob /weblate
. Novamente, usando mod_wsgi
(também disponível como 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>
Adicionalmente, você irá ter de ajustar o weblate/settings.py
:
URL_PREFIX = "/weblate"
Tarefas de fundo usando Celery¶
Weblate usa Celery para executar tarefas regulares e em segundo plano. Você deve executar um serviço Celery que irá executá-los. Por exemplo, é responsável por lidar com as seguintes operações (esta lista não está completa):
Receber webhooks de serviços externos (veja Ganchos de notificação).
Executar tarefas de manutenção regulares como backups, limpezas, extensões diárias ou atualizações (veja Fazendo backup e movendo o Weblate,
BACKGROUND_TASKS
, Extensões).Executar Tradução automática.
Enviar notificações de resumo.
Offloading expensive operations from the WSGI process.
Fazer commits de alterações pendentes (veja Commits adiados).
Uma configuração típica usando redis como backend se parece com isso:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Ver também
Você também deve iniciar o worker do Celery para processar as tarefas e iniciar tarefas programadas, isso pode ser feito diretamente na linha de comando (o que é mais útil ao depurar ou desenvolver):
./weblate/examples/celery start
./weblate/examples/celery stop
Nota
O processo de Celery deve ser executado sob o mesmo usuário que o Weblate e o processo do WSGI, caso contrário, os arquivos em DATA_DIR
serão armazenados com propriedade mista, levando a problemas de tempo de execução.
Veja também Permissões do sistema de arquivos e Executando servidor.
Executing Celery tasks in the WSGI using eager mode¶
Nota
Isso terá um impacto severo no desempenho da interface da web e interromperá os recursos dependendo do acionamento normal (por exemplo, fazer commit de alterações pendentes, notificações de resumo ou backups).
Para o desenvolvimento, você pode querer usar uma configuração ansiosa, que processa todas as tarefas no local:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Executando Celery como serviço do sistema¶
Provavelmente você vai querer executar o Celery como um daemon e que é coberto por Daemonization. Para as configurações Linux mais comuns usando systemd, você pode usar os arquivos de exemplo disponibilizados na pasta examples
listado abaixo.
Unidade do systemd a ser colocada como /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ção do ambiente a ser colocada como /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ção adicional para alternar os logs do Celery usando logrotate a ser colocada como /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
}
Tarefas periódicas usando a batida do Celery¶
O Weblate vem com configuração embutida para tarefas programadas. No entanto, você pode definir tarefas adicionais em settings.py
. Por exemplo, veja Commits adiados.
As tarefas deveriam ser executadas por daemons de batidas do Celery. Caso não esteja funcionando corretamente, pode não estar funcionando ou seu banco de dados foi corrompido. Verifique os registros de inicialização do Celery nesse caso para descobrir a causa raiz.
Monitorando status do Celery¶
You can find current length of the Celery task queues in the
Interface de gerenciamento 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.
Aviso
Os erros do Celery são por padrão apenas conectados ao log do Celery e não são visíveis ao usuário. Caso você queira ter uma visão geral sobre tais falhas, recomenda-se ajustar a configuração para ir 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
Aviso
This will have a noticeable performance impact on Weblate.
Monitorando o Weblate¶
O Weblate fornece a URL /healthz/
a ser usada em verificações de saúde simples, por exemplo, usando Kubernetes. O contêiner Docker tem verificação de saúde embutida usando esta URL.
Para monitorar as métricas do Weblate, você pode usar o ponto final GET /api/metrics/
da API.
Collecting error reports and monitoring performance¶
Weblate, como qualquer outro software, pode falhar. Para coletar estados de falha úteis, recomendamos usar serviços de terceiros para coletar tais informações. Isso é especialmente útil no caso de falhas nas tarefas do Celery, que de outra forma só relatariam erro nos logs e você não será notificado sobre eles. O Weblate tem suporte para os seguintes serviços:
Sentry¶
O Weblate possui suporte embutido para Sentry. Para usá-lo, é suficiente definir SENTRY_DSN
no 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
.
Ver também
Rollbar¶
O Weblate tem suporte embutido para Rollbar. Para usá-lo, basta seguir instruções para o notificador de Rollbar para Python.
Em suma, você precisa ajustar 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",
}
Todo o resto é integrado automaticamente, agora você coletará erros do lado do servidor e do cliente.
Nota
Error logging also includes exceptions that were gracefully handled, but might indicate a problem - such as failed parsing of an uploaded file.
Migrando Weblate para outro servidor¶
Migrar o Weblate para outro servidor deve ser muito fácil, porém armazena dados em poucos locais que você deve migrar cuidadosamente. A melhor abordagem é parar o Weblate para a migração.
Migrando banco de dados¶
Dependendo do back-end do seu banco de dados, você pode ter várias opções para migrar o banco de dados. A abordagem mais direta é usar ferramentas nativas de banco de dados, pois elas são geralmente as mais eficazes (por exemplo, mysqldump ou pg_dump). Como alternativa, você pode usar a replicação caso seu banco de dados suporte isso.
Ver também
Migração entre bancos de dados descritos em Migrando de outros bancos de dados para o PostgreSQL.
Migrando repositórios VCS¶
Os repositórios VCS armazenados em DATA_DIR
também precisam ser migrados. Você pode simplesmente copiá-los ou usar rsync para fazer a migração de forma mais eficaz.
Outras notas¶
Não se esqueça de mover outros serviços que o Weblate pode ter usado como Redis, tarefas do cron ou backends de autenticação personalizada.