Instruções de configuração¶
Instalar o Weblate¶
Dependendo da sua configuração e experiência, escolha um método de instalação apropriado para si:
Instalando a usar Docker, recomendado para configurações de produção.
Instalação virtualenv, recomendada para configurações de produção:
Instalando a partir do código-fonte, recomendado para o desenvolvimento.
Visão geral da arquitetura¶
- Servidor Web
Tratamento de solicitações HTTP de entrada, Servir ficheiros estáticos.
- Trabalhadores do Celery
Tarefas de fundo a usar o Celery são executados aqui.
Dependendo da sua carga de trabalho, pode personalizar a quantidade de trabalhadores.
Use um nó dedicado ao escalar o Weblate horizontalmente.
- Servidor WSGI
Um servidor WSGI servindo páginas web para utilizadores.
Use um nó dedicado ao escalar o Weblate horizontalmente.
- Banco de dados
Servidor de banco de dados PostgreSQL para armazenar todo o conteúdo, consulte: Configuração de banco de dados para o Weblate.
Usa um nó de base de dados dedicada para sítios com centenas de milhões de palavras alojadas.
- Redis
Servidor Redis para cache e fila de tarefas, consulte Tarefas de fundo a usar o Celery.
Use um nó dedicado ao escalar o Weblate horizontalmente.
- Sistema de ficheiros
Armazenamento do sistema de ficheiros para armazenar repositórios do VCS e dados de utilizador enviados. Isto é partilhado por todos os processos.
Use armazenamento em rede ao escalar o Weblate horizontalmente.
- Servidor de e-mail
Servidor SMTP para e-mail de saída, consulte Configuração de e-mail de saída. Ele pode ser fornecido externamente.
Dica
Instalando a usar Docker inclui o PostgreSQL e o Redis, facilitando a instalação.
Requisitos de software¶
Sistema operativo¶
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.
Veja também
Visão geral da arquitetura descreve a arquitetura geral do Weblate e os serviços necessários.
Dependências Python¶
Weblate is written in Python and supports Python
3.11 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
Optional dependency specifier |
Python Packages |
Recurso Weblate |
|---|---|---|
|
||
|
||
|
||
|
||
|
||
|
Tradução avançada do Google Cloud with glossary support |
|
|
||
|
||
|
MySQL ou MariaDB, consulte Configuração de banco de dados para o Weblate |
|
|
||
|
PostgreSQL, consulte Configuração de banco de dados para o Weblate |
|
|
||
|
Integrating SAML 2 IDP into Weblate |
|
|
Hosted Weblate integration |
|
|
Hosted Weblate integration |
|
|
wsgi server for Weblate |
|
|
Ao instalar a usar pip, pode especificar diretamente os recursos desejados ao instalar:
uv pip install "weblate[Postgres,Amazon,SAML]"
Ou pode instalar o Weblate com todos os recursos opcionais:
uv pip install "weblate[all]"
Ou pode instalar o Weblate sem quaisquer recursos opcionais:
uv pip install weblate
Outros requisitos do sistema¶
As dependências seguintes devem ser instaladas no sistema:
Git- Pango, Cairo e ficheiros de cabeçalho relacionados e dados de introspecção GObject
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, see Pango e Cairo
git-review(opcional para suporte de Gerrit)git-svn(opcional para suporte de Subversion)tesseract(necessário apenas se o programa tesserocr não estiverem disponíveis para o seu sistema)licensee(opcional para detetar a licença ao criar o componente)
Dependências de tempo de compilação¶
Para compilar alguns das dependências Python, pode precisar instalar as dependências deles. Isso depende de como instala-as, por isso consulte pacotes individuais para obter documentação. Não precisará deles se usar Wheels pré-compilado durante a instalação a usar pip ou quando usar pacotes de distribuição.
Pango e Cairo¶
O Weblate usa Pango e Cairo para renderizar widgets de bitmap (ver Promovendo a tradução) e verificações de renderização (ver Gerir letras). Para instalar as ligações Python corretamente para esses, precisa de instalar bibliotecas de sistemas primeiro - precisa tanto do Cairo quanto do Pango, que por sua vez precisam de GLib. Todos esses devem ser instalados com ficheiros de desenvolvimento e dados de introspecção GObject.
Requisitos de hardware¶
O Weblate deve funcionar em qualquer hardware contemporâneo sem problemas. A seguir está a configuração mínima necessária para executar o Weblate num único host (Weblate, banco de dados e servidor web):
3 GB de 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 geridas nele.
Memória utilizada¶
Quanto mais memória, melhor - ela é usada para armazenamento em cache em todos os níveis (sistema de ficheiros, banco de dados e Weblate). Para centenas de componentes de tradução, recomenda-se pelo menos 4 GB de RAM.
Dica
Para sistemas com menos memória do que o recomendado, Configuração do Celery de processo único é recomendado.
Uso da CPU¶
Muitos utilizadores simultâneos aumentam a quantidade de núcleos de CPU necessários.
Uso de armazenamento¶
O uso típico de armazenamento da base de dados é de cerca de 300 MB por 1 milhão de palavras alojadas.
O espaço de armazenamento necessário para repositórios clonados varia, mas o Weblate tenta manter o seu tamanho mínimo fazendo clones rasos.
Nós¶
Para sítios de pequeno e médio porte (milhões de palavras alojadas), todos os componentes do Weblate (consulte Visão geral da arquitetura) podem ser executados num único nó.
Quando atingir centenas de milhões de palavras alojadas, é recomendável ter um nó dedicado para a base de dados (consulte Configuração de banco de dados para o Weblate).
Verificar assinaturas de lançamento¶
As versões do Weblate são assinadas criptograficamente usando assinaturas Sigstore. As assinaturas estão anexadas à versão do GitHub.
A verificação pode ser realizada usando pacote sigstore. O exemplo a seguir verifica a assinatura da versão 5.4:
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 ficheiros¶
O processo Weblate precisa ser capaz de ler e escrever para o diretório onde mantém os dados – DATA_DIR. Todos os ficheiros dentro deste diretório devem ser de propriedade e graváveis pelo utilizador que executa todos os processos do Weblate (geralmente WSGI e Celery, veja Executar o servidor e Tarefas de fundo a usar o Celery).
A configuração predefinida põe-os na mesma árvore que as fontes do Weblate, no entanto, 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.
Também deve tomar cuidado ao executar Comandos de gerência, pois eles devem ser executados sob o mesmo utilizador que o Weblate em si está a ser executado, caso contrário, permissões em alguns ficheiros podem estar erradas.
No contentor Docker, todos os ficheiros no volume /app/data tem de ter como dono o utilizador weblate dentro do contentor (UID 1000).
Veja também
Configuração de banco de dados para o Weblate¶
Recomenda-se a executar o Weblate com um servidor de banco de dados PostgreSQL.
PostgreSQL 13 and higher is supported. PostgreSQL 15 or newer is recommended.
MySQL e MariaDB é suportado, mas não recomendado para novas instalações.
Nota
Nenhum outro servidor de banco de dados é suportado atualmente, mas deve ser possível implementar o suporte para outros bancos de dados suportados pelo Django.
Veja também
Usar um poderoso mecanismo de banco de dados, Databases, Migrando de outros bancos de dados para o PostgreSQL
Conexões de banco de dados¶
Na configuração padrão, cada processo do Weblate mantém uma conexão persistente com o banco de dados. As conexões persistentes melhoram a capacidade de resposta do Weblate, mas podem exigir mais recursos do servidor do banco de dados. Consulte CONN_MAX_AGE e Persistent connections para obter mais informações.
O Weblate precisa de pelo menos o seguinte número de conexões:
\((4 \times \mathit{nCPUs}) + 2\) para processos Celery
\(\mathit{nCPUs} + 1\) para trabalhadores WSGI
Isto aplica-se aos padrões dos contentores do Docker e às configurações de exemplo fornecidas nesta documentação, mas os números serão alterados quando personalizar a quantidade de workers WSGI ou ajustar o paralelismo do Celery.
O limite atual para o número de conexões do banco de dados precisa ser maior para contemplar as seguintes situações:
Comandos de gerência também precisa da sua conexão.
Se o processo do caso for eliminado (por exemplo, pelo OOM killer) poderá bloquear a conexão existente até o tempo limite.
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 a extensão trigram que deve ser instalada separadamente em alguns casos. Procure por postgresql-contrib ou um pacote com nome similar.
Veja também
Criar um banco de dados no PostgreSQL¶
Geralmente é uma boa ideia executar o Weblate num banco de dados separado e separar a conta do utilizador:
# 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 não quiser fazer do utilizador do Weblate um superutilizador no PostgreSQL, pode omiti-lo. Nesse caso, terá que executar algumas das etapas de migração manualmente como um superutilizador do PostgreSQL no esquema Weblate usará:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Configurar Weblate para usar PostgreSQL¶
O trecho settings.py para PostgreSQL:
DATABASES = {
"default": {
# Database engine
"ENGINE": "django.db.backends.postgresql",
# Database name
"NAME": "weblate",
# Database user
"USER": "weblate",
# Configures name of the PostgreSQL role to alter during the database migration
# "ALTER_ROLE": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "database.example.com",
# Set to empty string for default
"PORT": "",
# Persistent connections
"CONN_MAX_AGE": None,
"CONN_HEALTH_CHECKS": True,
}
}
The database migration performs ALTER ROLE on the database role used
by Weblate. In most cases, the name of the role matches the username. In more
complex setups the role name is different from the username, and you will get an error
about non-existing role during the database migration
(psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist).
This is known to happen with Azure Database for PostgreSQL, but it’s not
limited to this environment. Please set ALTER_ROLE to change the name of the
role Weblate should alter during the database migration.
Veja também
MySQL e MariaDB¶
Aviso
Embora o suporte ao MySQL e MariaDB ainda seja mantido no Weblate, o nosso foco principal é o PostgreSQL. É recomendado usar o PostgreSQL para novas instalações e migrar instalações existentes para o PostgreSQL, consulte: 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.5.
A configuração seguinte é recomendada para Weblate:
Use o conjunto de caracteres
utf8mb4para permitir a representação de planos Unicode mais altos (por exemplo, emojis).Configure o servidor com
innodb_large_prefixpara 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 esteja a planejar ter uma grande quantidade de utilizadores simultâneos a acessar 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 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 estar a receber o erro #1071 - Specified key was too long; max key length is 767 bytes, atualize a sua configuração para incluir as configurações innodb acima e reinicie a sua instalação.
Dica
No caso de estar a receber o erro #2006 - MySQL server has gone away, configurar CONN_MAX_AGE pode ajudar.
Veja 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": {},
}
}
Também deve criar a conta de utilizador 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;
Veja também
Outras configurações¶
Configuração de e-mail de saída¶
O Weblate envia e-mails em várias ocasiões - para a ativação de contas e sobre várias notificações configuradas pelos utilizadores. Para isso, precisa de acesso a um servidor de SMTP.
A configuração do servidor de e-mail é configurada a usar essas configurações: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_SSL, EMAIL_USE_TLS, EMAIL_HOST_USER e EMAIL_PORT. Os nomes deles são bastante autoexplicativos, mas pode encontrar mais informações na documentação do Django.
Dica
Caso 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.
Executar por trás de um proxy reverso¶
Vários recursos no Weblate dependem de ser capaz de obter o endereço IP do cliente. Isso inclui Limitação de taxa, Proteção contra spam ou Registo de auditoria.
Weblate parses IP address from the REMOTE_ADDR which is set by the WSGI
handler. This might be empty (when using socket for WSGI) or contain a reverse
proxy address, so Weblate needs an additional HTTP header with client IP
address.
Enabling IP_BEHIND_REVERSE_PROXY might be enough for the most usual
setups, but you might need to adjust IP_PROXY_HEADER and
IP_PROXY_OFFSET as well (use WEBLATE_IP_PROXY_HEADER and
WEBLATE_IP_PROXY_OFFSET in the Docker container).
Dica
This configuration cannot be turned on by default because it would allow IP address spoofing on installations that don’t have a properly configured reverse proxy.
Outra coisa a tratar é do cabeçalho Host. Deve combinar com o que estiver configurado como SITE_DOMAIN. Uma configuração adicional pode ser necessária no seu proxy reverso (por exemplo, use ProxyPreserveHost On para o Apache ou proxy_set_header Host $host; no nginx).
Veja também
Proteção contra spam,
Limitação de taxa,
Registo de auditoria,
Configuração de amostra para NGINX e uWSGI,
Sample configuration for NGINX and Gunicorn,
Configuração de amostra para Apache,
Configuração de amostra para Apache and Gunicorn,
IP_BEHIND_REVERSE_PROXY,
IP_PROXY_HEADER,
IP_PROXY_OFFSET,
SECURE_PROXY_SSL_HEADER,
WEBLATE_IP_PROXY_HEADER,
WEBLATE_IP_PROXY_OFFSET
Proxy HTTP¶
O Weblate executa comandos VCS e esses 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"
Veja também
Ajustar a configuração¶
Veja também
Copie weblate/settings_example.py para weblate/settings.py e ajuste-o para corresponder à configuração. Provavelmente irá ajustar as opções a seguir:
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.
O formulário de contato também lhes envia e-mail, a menos que a
ADMINS_CONTACTesteja configurada.Veja também
ADMINS,ADMINS_CONTACT, Configurar administradores corretamente
ALLOWED_HOSTS
Precisa definir isso para listar os hosts que o seu site deve servir. Por exemplo:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativamente, pode incluir curinga:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configure como as suas sessões serão armazenadas. Caso mantenha o mecanismo de backend do banco de dados predefinido, deve agendar: weblate clearsessions para remover dados de sessão obsoletos do banco de dados.
Se estiver a usar o Redis como cache (veja Ativar o cache) é recomendado também usá-lo para sessões:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Veja também
DATABASES
Conetividade ao servidor de banco de dados, verifique a documentação do Django para obter mais detalhes.
Veja também
Configuração de banco de dados para o Weblate,
DATABASES, Databases
DEBUG
Desative isto para qualquer servidor de produção. Com o modo de depuração ativado, o Django mostrará backtraces em caso de erro aos utilizadores, quando desativá-lo, erros serão enviados por e-mail para
ADMINS(veja acima).O modo de depuração também desacelera o Weblate, já que o Django armazena muito mais informações internamente neste caso.
Veja também
DEFAULT_FROM_EMAIL
Endereço de remetente de e-mail para e-mail de saída, por exemplo, e-mails de registo.
Veja também
SECRET_KEY
Chave usada por Django para assinar informações em cookies, consulte Chave secreta do Django para obter mais informações.
Veja 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 falhadas.
Veja também
Preencher o banco de dados¶
Depois que a sua configuração estiver pronta, pode executar migrate para criar a estrutura do banco de dados. Agora deve ser capaz de criar projetos de tradução usando a interface administrativa.
Uma vez feito, também deve verificar o Relatório de desempenho na interface administrativa, o que lhe dará dicas de configuração potencial não ideal no seu site.
Veja também
Configuração de produção¶
Para uma configuração de produção, deve realizar ajustes descritos nas secçõ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 esitver conectado como um superutilizador:
Também é recomendado inspecionar verificações desencadeadas por Django (embora possa não precisar corrigir todas):
weblate check --deploy
Também pode revisar a mesma lista de verificação em Relatório de desempenho na Interface de gestão.
Veja também
Desativar o modo de depuração¶
Desative o modo de depuração do Django (DEBUG) com:
DEBUG = False
Com o modo de depuração ativado, o Django armazena todas as consultas executadas e mostra aos utilizadores backtraces de erros, o que não é desejado numa configuração de produção.
Veja também
Configurar administradores corretamente¶
Defina os endereços de administração corretos à configuração ADMINS para definir quem receberá e-mails caso algo dê errado no servidor, por exemplo:
ADMINS = (("Your Name", "your_email@example.com"),)
Veja também
Definir domínio correto do site¶
Ajuste o nome e o domínio do site na interface administrativa, caso contrário, ligações no RSS ou e-mails de registo não funcionarão. Isto é 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 HTTPS corretamente¶
É fortemente recomendado executar Weblate a com o protocolo criptografado HTTPS. Depois de ativá-lo, deve definir ENABLE_HTTPS nas configurações:
ENABLE_HTTPS = True
Dica
Pode também configurar o HSTS, consulte SSL/HTTPS para obter mais detalhes.
Definir SECURE_HSTS_SECONDS corretamente¶
Se o seu site for servido sobre SSL, deve considerar definir um valor para SECURE_HSTS_SECONDS no settings.py para ativar HTTP Strict Transport Security. Por padrão, ele está definido para 0 como mostrado abaixo.
SECURE_HSTS_SECONDS = 0
Se for 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 isto incorretamente pode quebrar irreversivelmente (por algum tempo) o 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 a sua experiência com o Weblate.
Verifique o desempenho do servidor de banco de dados ou ajuste a sua configuração, por exemplo, usando PGTune.
Ativar o cache¶
Se for possível, use Redis do Django e ajuste 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 altere as configurações do Redis para o cache, pode ser necessário ajustá-las também para o Celery, consulte Tarefas de fundo a usar o Celery.
Veja também
Cache de avatares¶
Além do cache de Django, Weblate realiza cache de avatares. Recomenda-se usar um cache separado, baseado em ficheiros 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,
},
},
}
Veja também
ENABLE_AVATARS,
AVATAR_URL_PREFIX,
Avatares,
Ativar o cache,
Django’s cache framework
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 desativar o envio de e-mails pelo Weblate, defina EMAIL_BACKEND a django.core.mail.backends.dummy.EmailBackend.
Isso desativará toda a entrega de e-mail, incluindo e-mails de registo ou redefinição de palavra-passe.
Configuração de hosts permitidos¶
Django requer ALLOWED_HOSTS para manter uma lista de nomes de domínio que o seu site pode servir, deixá-lo vazio bloqueará todas solicitações.
Caso isso não esteja configurado para corresponder ao seu servidor HTTP, terá erros como Invalid HTTP_HOST header: '1.1.1.1'. Pode ter que adicionar '1.1.1.1' ao ALLOWED_HOSTS.
Dica
No contentor 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 o seu próprio valor em vez de usar o da configuração do exemplo.
Pode gerar uma nova chave por weblate-generate-secret-key, que vem com o Weblate.
Veja também
Executar tarefas de manutenção¶
Para um desempenho ideal, é uma boa ideia executar algumas tarefas de manutenção em segundo plano. Isto é feito automaticamente por Tarefas de fundo a usar o Celery e cobre as seguintes tarefas:
Verificação de saúde da configuração (de hora em hora).
Realização de commits de alterações pendentes (de hora em hora), consulte Commits adiados e
commit_pending.Atualização de alertas de componentes (dialy).
Atualização dos ramos remotos (nightly), consulte
AUTO_UPDATE.Backup de memória de tradução para JSON (diariamente), consulte
dump_memory.Tarefas de manutenção de texto completo e banco de dados (tarefas diárias e semanais), consulte
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 predefinida. Se não é o caso no seu sistema, altere as localidades para a variante UTF-8.
Por exemplo, a editar /etc/default/locale e a definir 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'
Comprimir os ativos do cliente¶
O Weblate vem com um monte de ficheiros JavaScript e CSS. Por razões de desempenho, é bom comprimi-los antes de enviar para um cliente. Na configuração predefinida isso é feito rapidamente 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 ativar 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 precisa compactar os ficheiros para corresponder à versão atual:
weblate compress
Dica
A imagem oficial do Docker já tem este recurso ativado.
Veja também
Executar o servidor¶
Dica
No caso de não ter experiência com os serviços descritos abaixo, pode tentar seguir Instalando a usar Docker.
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 Ativar o cache)
Servidor web frontend para ficheiros estáticos e terminação SSL (consulte Servir ficheiros estáticos)
Servidor WSGI para conteúdo dinâmico (consulte Configuração de amostra para NGINX e uWSGI)
Celery para executar tarefas em segundo plano (consulte Tarefas de fundo a usar o 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, executará todos os serviços num único servidor (virtual), mas se a sua instalação estar muito carregada, 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 utilizador que o processo do Celery, caso contrário, os ficheiros em DATA_DIR serão armazenados com propriedade mista, a levar a problemas de tempo de execução.
Veja também Permissões do sistema de ficheiros e Tarefas de fundo a usar o Celery.
Executar um servidor web¶
Running Weblate is not different from running any other Django based program. Django is usually executed as WSGI or fcgi (see examples for different webservers below).
Para fins de teste, pode usar o servidor web incorporado no Django:
weblate runserver
Aviso
NÃO USE ESTE SERVIDOR NUMA CONFIGURAÇÃO DE PRODUÇÃO. Não passou por auditorias de segurança ou testes de desempenho. Veja também a documentação de Django no runserver.
Dica
O servidor embutido do Django serve apenas ficheiros estáticos com DEBUG ativado, pois é destinado apenas ao desenvolvimento. Para uso da produção, consulte as configurações de WSGI em Configuração de amostra para NGINX e uWSGI, Configuração de amostra para Apache, Configuração de amostra para Apache and Gunicorn e Servir ficheiros estáticos.
Servir ficheiros estáticos¶
Django precisa coletar os seus ficheiros estáticos num único diretório. Para isto, execute weblate collectstatic --noinput. Isto copiará os ficheiros estáticos num diretório especificado pela configuração STATIC_ROOT (isto é padrão para um diretório static dentro de CACHE_DIR).
Recomenda-se servir ficheiros estáticos diretamente do seu servidor web. Deve usá-los para os seguintes caminhos:
/static/Serve ficheiros estáticos para Weblate e a interface de administração (definida por
STATIC_ROOT)./media/Usado para o envio de mídia pelo utilizador (por exemplo, capturas de ecrã).
/favicon.icoDeve ser reescrito para reescrever uma regra para servir
/static/favicon.ico.
Política de segurança de conteúdo¶
The default Weblate configuration enables weblate.middleware.SecurityMiddleware
middleware which sets security related HTTP headers like Content-Security-Policy
or X-XSS-Protection. These are by default set up to work with Weblate and its
configuration, but this might need customization for your environment.
Veja também
CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC, CSP_FORM_SRC
Sample configuration for NGINX and Gunicorn¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(also available as weblate/examples/weblate.nginx.gunicorn.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 / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Configuração de amostra para NGINX e uWSGI¶
Para executar o servidor web de produção, use o wrapper WSGI instalado com Weblate (no caso de ambiente virtual é instalado como ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Não se esqueça de definir o caminho de pesquisa Python para o seu virtualenv também (por exemplo, usando virtualenv = /home/user/weblate-env` no uWSGI).
A configuração a seguir executa o Weblate como uWSGI sob o servidor web NGINX.
A 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
Veja também
Configuração de amostra para Apache¶
Recomenda-se o uso de prefork de MPM ao usar WSGI com Weblate.
A configuração a seguir executa o Weblate como WSGI. Precisa ter ativado 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 está a executar a variante do Python 3 do modwsgi. Usualmente, está disponível como um pacote separado, por exemplo libapache2-mod-wsgi-py3.
Use a versão Python correspondente para instalar o Weblate.
Configuração de amostra para Apache and Gunicorn¶
A configuração seguinte executa o Weblate em Gunicorn and 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>
Sample configuration to start Gunicorn¶
Weblate has wsgi optional dependency (see Dependências Python) that will install everything you need to run Gunicorn. When installing Weblate you can specify it as:
uv pip install Weblate[all,wsgi]
Once you have Gunicorn installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Veja também
A executar o 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, a usar 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, irá ter de ajustar o weblate/settings.py:
URL_PREFIX = "/weblate"
Tarefas de fundo a usar o Celery¶
Weblate usa Celery para executar tarefas regulares e em segundo plano. Deve executar o 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 Hooks de notificação).
Executar tarefas de manutenção regulares como backups, limpezas, extensões diárias ou atualizações (veja Fazer backup e mover o Weblate,
BACKGROUND_TASKS, Extensões).Executar Tradução automática.
Enviar notificações de resumo.
A descarregar operações dispendiosas do processo WSGI.
Fazer commits de alterações pendentes (veja Commits adiados).
Uma configuração típica a usar redis como backend se parece com isso:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Veja também
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 utilizador que o Weblate e o processo do WSGI, caso contrário, os ficheiros em DATA_DIR serão armazenados com propriedade mista, a levar a problemas de tempo de execução.
Veja também Permissões do sistema de ficheiros e Executar o servidor.
Execução de tarefas de Celery no WSGI usando o modo eager¶
Nota
Isso terá um impacto severo no desempenho da interface da web e interromperá os recursos a depender do acionamento normal (por exemplo, fazer commit de alterações pendentes, notificações de resumo ou backups).
Para o desenvolvimento, pode 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 vai querer executar o Celery como um daemon e que é coberto por Daemonization. Para as configurações Linux mais comuns a usar systemd, pode usar os ficheiros de exemplo disponibilizados na pasta examples listado abaixo.
Unidade do systemd a ser posta 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 posta 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 a usar logrotate a ser posta 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 a usar a batida do Celery¶
Weblate comes with built-in setup for scheduled tasks. The task schedule is stored in the database and tasks are executed by the Celery beat daemon.
Dica
You can define additional tasks in settings.py, for example see
Commits adiados.
Monitorar o estado do Celery¶
Pode encontrar o comprimento atual das filas de tarefas do Celery na Interface de gestão ou pode usar celery_queues na linha de comando. Caso a fila fique muito longa, também terá erro de configuração na interface administrativa.
Aviso
Os erros do Celery são por padrão apenas conectados ao log do Celery e não são visíveis ao utilizador. Caso queira ter uma visão geral sobre tais falhas, recomenda-se ajustar a configuração para ir A coletar relatórios de erros e monitoramento do desempenho.
Configuração do Celery de processo único¶
Caso a sua memória seja muito limitada, talvez queira reduzir o número de processos do Weblate. Todas as tarefas do Celery podem ser executadas num único processo usando:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Uma instalação que usa o Docker pode ser configurada para usar uma configuração do Celery de processo único, definindo CELERY_SINGLE_PROCESS.
Aviso
Isto terá um impacto perceptível no desempenho do 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 contentor Docker tem verificação de saúde embutida usando esta URL.
Para monitorar as métricas do Weblate, pode usar o ponto final GET /api/metrics/ da API.
A coletar relatórios de erros e monitoramento do desempenho¶
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 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/"
O Sentry também pode ser usado para monitorar o desempenho do Weblate, coletando rastros e perfis para uma percentagem definida de operações. Isto pode ser configurado usando SENTRY_TRACES_SAMPLE_RATE e SENTRY_PROFILES_SAMPLE_RATE.
Veja 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, 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",
"environment": "development" if DEBUG else "production",
"branch": "main",
"root": "/absolute/path/to/code/root",
}
Todo o resto é integrado automaticamente, agora coletará erros do lado do servidor e do cliente.
Nota
O registo de erros também inclui exceções que foram analisadas com cuidado, mas que podem indicar um problema, como a falha na análise de um ficheiro enviado.
Graylog log management¶
Added in version 5.9.
Weblate can be configured to log using the GELF TCP protocol. This was developed for Graylog integration, but can be used with any compliant logging platform.
O segmento chapa de configuração está incluído em Amostra de configuração, Para Docker, pode ser configurado usando WEBLATE_LOG_GELF_HOST.
Migrando Weblate para outro servidor¶
Migrar o Weblate para outro servidor deve ser muito fácil, porém armazena dados em poucos locais que 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, pode ter várias opções para migrar o banco de dados. A abordagem mais direta é usar ferramentas nativas de banco de dados, pois são geralmente as mais eficazes (por exemplo, mysqldump ou pg_dump). Como alternativa, pode usar a replicação caso o seu banco de dados o suporte.
Veja 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. 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.