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.
Visão geral da arquitetura¶
- Servidor Web
Tratamento de solicitações HTTP de entrada, Servindo arquivos estáticos.
- Trabalhadores do Celery
Tarefas de fundo usando Celery são executados aqui.
Dependendo da sua carga de trabalho, você pode querer personalizar o número de trabalhadores.
Use um nó dedicado ao escalar o Weblate horizontalmente.
- Servidor WSGI
Um servidor WSGI servindo páginas web para usuários.
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.
Use um nó de banco de dados dedicado para sites com centenas de milhões de palavras hospedadas.
- Datastore
Key/value datastore such as Valkey or Redis server for cache and tasks queue, see Tarefas de fundo usando Celery.
Use um nó dedicado ao escalar o Weblate horizontalmente.
- Sistema de arquivos
Armazenamento do sistema de arquivos para armazenar repositórios do VCS e dados de usuário enviados. Isso é compartilhado 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 usando Docker includes PostgreSQL and Valkey, 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
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.12 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
Especificador da dependência opcional |
Pacotes Python |
Recurso Weblate |
|---|---|---|
|
||
|
||
|
||
|
Tradução avançada do Google Cloud com suporte a glossário |
|
|
||
|
||
|
PostgreSQL, consulte Configuração de banco de dados para o Weblate |
|
|
||
|
||
|
Integrando SAML 2 IDP no Weblate |
|
|
Needed for Atualizar arquivo POT (Sphinx) |
|
|
Integração ao Hosted Weblate |
|
|
Servidor wsgi para o Weblate |
|
|
Ao instalar usando pip, você pode especificar diretamente os recursos desejados ao instalar:
uv pip install "weblate[Postgres,Amazon,SAML]"
Ou você pode instalar o Weblate com todos os recursos opcionais:
uv pip install "weblate[all]"
Ou você pode instalar o Weblate sem quaisquer recursos opcionais:
uv pip install weblate
Solução de problemas via instalação pip¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.The installed
PyGobjectpackage cannot find a matching GObject Introspection library -gobject-introspection-2.0.Older versions are no longer supported by Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Isso é causado pela incompatibilidade de pacotes binários distribuídos via PyPI com a distribuição. Para resolver isso, você precisa reconstruir o pacote em seu sistema:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Este é um problema conhecido do pacote xmlsec. Veja https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchOs pacotes
lxmlexmlsecprecisam ser compilados com base em umalibxml2. Você deve compilá-los localmente para evitar este problema:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
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://www.gtk.org/docs/architecture/pango, consulte Pango e Cairo
git-review(opcional para suporte a Gerrit)git-svn(opcional para suporte a Subversion)tesseract(necessário apenas se o programa tesserocr não estiverem disponíveis para o seu sistema)
Dependências de tempo de compilação¶
To build some of the Dependências Python you might need to install their
dependencies. This depends on how you install them, so please consult
individual packages for documentation. You won’t need those if using prebuilt
Wheels while installing using pip or when you use distribution packages.
Pango e Cairo¶
O Weblate usa Pango e Cairo para renderizar widgets bitmap (ver Building the translation community) 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¶
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 em um ú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 gerenciadas nele.
Memória utilizada¶
Quanto mais memória, melhor - ela é usada para armazenamento em cache em todos os níveis (sistema de arquivos, 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 usuários simultâneos aumentam a quantidade de núcleos de CPU necessários.
Uso de armazenamento¶
O uso típico de armazenamento de banco de dados é de cerca de 300 MB por 1 milhão de palavras hospedadas.
O espaço de armazenamento necessário para repositórios clonados varia, mas o Weblate tenta manter seu tamanho mínimo fazendo clones rasos.
Nodes¶
Para sites de pequeno e médio porte (milhões de palavras hospedadas), todos os componentes do Weblate (consulte Visão geral da arquitetura) podem ser executados em um único nó.
Quando você atingir centenas de milhões de palavras hospedadas, é recomendável ter um nó dedicado para o banco de dados (consulte Configuração de banco de dados para o Weblate).
Verificando 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 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, consulte 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.
The configured CACHE_DIR also has to be writable by the Weblate
process and has to allow executing generated helper files. Do not mount
CACHE_DIR with the noexec option.
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.
O PostgreSQL 13 e versões superiores são suportados. O PostgreSQL 15 ou mais recente é recomendado.
Ver também
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 Conexões persistentes 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
Isso se aplica aos padrões dos contêineres do Docker e às configurações de exemplo fornecidas nesta documentação, mas os números serão alterados quando você 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 de sua conexão.
Se o processo do caso for eliminado (por exemplo, pelo OOM killer), ele 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 um complemento de trigrama que deve ser instalado 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",
# 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,
}
}
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
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ê receba um erro sobre autenticação não suportada (por exemplo, SMTP AUTH extension not supported by server), isso provavelmente é causado pelo uso de uma conexão insegura e o servidor se recusa a autenticar dessa forma. Tente ativar a EMAIL_USE_TLS nesse caso.
Executando por trás de um proxy reverso¶
Várias funcionalidades do Weblate dependem da transmissão correta de cabeçalhos HTTP. Ao usar proxy reverso, certifique-se de que as informações necessárias sejam transmitidas corretamente.
To debug this configuration, you can look at HTTP environment in Relatório de desempenho.
- Endereço IP do cliente
This is needed for Limitação de taxa or Registro de auditoria.
O Weblate analisa o endereço IP do
REMOTE_ADDR, que é definido pelo manipulador WSGI. Ele pode estar vazio (ao usar socket para WSGI) ou conter um endereço de proxy reverso, então o Weblate precisa de um cabeçalho HTTP adicional com um endereço IP do cliente.Habilitar
IP_BEHIND_REVERSE_PROXYdeve ser suficiente para as configurações mais comuns, mas talvez você precise ajustarIP_PROXY_HEADEReIP_PROXY_OFFSETtambém (useWEBLATE_IP_PROXY_HEADEReWEBLATE_IP_PROXY_OFFSETno contêiner do Docker).Dica
Esta configuração não pode ser ativada por padrão, pois isso permitiria a falsificação de endereço IP em instalações que não têm um proxy reverso configurado corretamente.
- Nome do host do servidor
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, useProxyPreserveHost Onpara Apache ouproxy_set_header Host $host;com nginx).Dica
CSRF verification failed errors are often caused by a mismatch between the Host header and configured
SITE_DOMAIN.- Protocolo do cliente
Não passar o protocolo correto pode fazer com que o Weblate acabe em um loop de redirecionamento ao tentar atualizar o cliente para HTTPS. Certifique-se de que ele seja exposto corretamente pelo proxy reverso como X-Forwarded-Proto.
This header then needs to be configured in
SECURE_PROXY_SSL_HEADER(settings.py) orWEBLATE_SECURE_PROXY_SSL_HEADER(Docker environment).Importante
The header value is case-sensitive in the configuration, so
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsandWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSare not interchangeable.Dica
If you are getting a “Too many redirects” error from the browser, this is most likely caused by mismatch between the actual protocol (HTTPS) and what is observed by Weblate.
Alterado na versão 5.13: The protocol proxy headers are automatically handled by gunicorn in the default configuration, but other WSGI servers have more secure configuration and require explicit setting of this.
Since Weblate 5.13 the Docker container is using granian and it now requires the explicit configuration of
WEBLATE_SECURE_PROXY_SSL_HEADER.
Ver também
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.
O formulário de contato também envia e-mail para eles, a menos que a
ADMINS_CONTACTesteja configurada.
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.
If you are using Valkey or Redis as cache (see Configure cache) it is recommended to use it for sessions as well:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"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¶
Depois que sua configuração estiver pronta, você pode executar migrate para criar a estrutura do banco de dados. Agora você deve ser capaz de criar projetos de tradução usando a interface administrativa.
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
Você também pode revisar a mesma lista de verificação em Relatório de desempenho na 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.
Configure cache¶
If possible, use Valkey or Redis from Django by adjusting the CACHES
configuration variable, for example:
CACHES = {
"default": {
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "redis://127.0.0.1:6379/0",
# If redis is running on same host as Weblate, you might
# want to use unix sockets instead:
# 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
}
}
Dica
In case you change settings for the cache, you might need to adjust them for Celery as well, see Tarefas de fundo usando Celery.
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-generate-secret-key, que vem com o Weblate.
Ver também
Executando tarefas de manutenção¶
Para um desempenho ideal, é uma boa ideia executar algumas tarefas de manutenção em segundo plano. Isso é feito automaticamente por Tarefas de fundo usando 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 (diariamente).
Update remote branches (nightly), see
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 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 Configure 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.
Consulte 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 WSGI ou fcgi (consulte exemplos para diferentes servidores web abaixo).
Nota
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
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. Consulte também a documentação de Django no runserver.
Dica
O servidor integrado do Django serve arquivos estáticos apenas com DEBUG habilitado, pois se destina apenas ao desenvolvimento. Para uso em produção, consulte as configurações WSGI:
Servindo arquivos estáticos¶
Alterado na versão 5.15.2: /media/ is no longer used for serving screenshots.
Django precisa coletar seus arquivos estáticos em um único diretório. Para isso, execute weblate collectstatic --noinput. Isso copiará os arquivos estáticos em um diretório especificado pela configuração STATIC_ROOT (isso é padrão para um diretório static dentro de CACHE_DIR).
Recomenda-se servir arquivos estáticos diretamente do seu servidor web. Você deve usá-los para os seguintes caminhos:
/static/Serve arquivos estáticos para Weblate e a interface de administração (definida por
STATIC_ROOT)./favicon.icoDeve ser reescrito para reescrever uma regra para servir
/static/favicon.ico.
Ver também
Política da 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.
Sample configuration for NGINX and Granian¶
A seguinte configuração executa o Weblate usando o Granian, o servidor web NGINX:
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:8888;
proxy_read_timeout 3600;
}
}
Amostra de configuração para NGINX e Gunicorn¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Amostra de configuração para NGINX e uWSGI¶
To run production webserver, use the WSGI wrapper installed with Weblate (when
using a Python environment it is installed as
~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Don’t
forget to set the Python search path to your Python environment as well (for
example using virtualenv = /home/user/weblate-env in uWSGI).
A configuração a seguir executa o Weblate como uWSGI sob o servidor web NGINX.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# Path to the Python environment
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Ver também
Amostra de configuração para o Apache¶
Recomenda-se o uso de prefork de MPM ao usar WSGI com Weblate.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
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 a versão Python correspondente para instalar o Weblate.
Amostra de configuração para Apache e Gunicorn¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Sample configuration to start Granian¶
Weblate has wsgi optional dependency (see Dependências Python) that will install everything you need to run Granian. When installing Weblate you can specify it as:
uv pip install Weblate[all,wsgi]
Once you have Granian installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Amostra de configuração para iniciar Gunicorn¶
Gunicorn has to be installed separately:
uv pip install gunicorn
Depois que você tiver o Gunicorn instalado, você pode executá-lo. Isso geralmente é feito no nível do sistema. Os exemplos a seguir mostram a inicialização 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
Ver também
Rodando Weblate sob o caminho¶
Recomenda-se o uso de prefork de MPM ao usar WSGI com Weblate.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
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 (consulte Ganchos de notificação).
Executar tarefas de manutenção regulares como backups, limpezas, complementos diários ou atualizações (consulte Fazendo backup e movendo o Weblate,
BACKGROUND_TASKS, Complementos).Executar Tradução automática.
Enviar notificações de resumo.
Descarregando operações dispendiosas do processo WSGI.
Fazer commits de alterações pendentes (consulte Commits adiados).
A typical setup using Valkey or Redis as a backend looks like this:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Ver também
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
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.
Consulte também Permissões do sistema de arquivos e Executando 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 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¶
Most likely you will want to run Celery as a daemon and that is covered by
Daemonization. For the most common Linux setup using
systemd, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
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. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
Configuração adicional para alternar os logs do Celery usando logrotate a ser colocada como /etc/logrotate.d/celery:
/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 agendadas. O agendamento de tarefas é armazenado no banco de dados e as tarefas são executadas pelo daemon beat do Celery.
Dica
Você pode definir tarefas adicionais em settings.py, por exemplo, consulte Commits adiados.
Monitorando status do Celery¶
Você pode encontrar o comprimento atual das filas de tarefas do Celery na Interface de gerenciamento ou você pode usar celery_queues na linha de comando. Caso a fila fique muito longa, você 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 usuário. Caso você queira ter uma visão geral sobre tais falhas, recomenda-se ajustar a configuração para ir Coletando relatórios de erros e monitoramento do desempenho.
Configuração do Celery de processo único¶
Caso sua memória seja muito limitada, talvez você queira reduzir o número de processos do Weblate. Todas as tarefas do Celery podem ser executadas em um ú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
Isso 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 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.
Coletando relatórios de erros e monitoramento do desempenho¶
Weblate, como qualquer outro software, pode falhar. Para coletar status 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:
E-mail¶
The default Weblate configuration instruments Django to send e-mails upon
server errors via django.utils.log.AdminEmailHandler. This
is the least effort setup, but you should consider other options for privacy
reasons, as the error e-mails might include sensitive data. You can read more on
that in Security implications.
To disable this behavior, remove mail_admins from the
LOGGING in Weblate settings, or disable
WEBLATE_ADMIN_NOTIFY_ERROR in the Docker environment.
Sentry¶
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 porcentagem definida de operações. Isso pode ser configurado usando SENTRY_TRACES_SAMPLE_RATE e SENTRY_PROFILES_SAMPLE_RATE.
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",
"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
O registro 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 arquivo enviado.
Gerenciamento de logs Graylog¶
Adicionado na versão 5.9.
O Weblate pode ser configurado para registrar usando o protocolo GELF TCP. Ele foi desenvolvido para integração com Graylog, mas pode ser usado com qualquer plataforma de registro compatível.
O modelo de configuração está incluído em Amostra de configuração, para o Docker isso 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 você deve migrar cuidadosamente. A melhor abordagem é parar o Weblate para a migração.
Migrando banco de dados¶
The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. pg_dump). Alternatively you can use replication if your database supports it.
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¶
Don’t forget to move other services Weblate might have been using like Valkey, Redis, Cron jobs or custom authentication backends.