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ê:
Installing using Docker, recomendado para configurações de produção.
Instalação virtualenv, recomendada para configurações de produção:
Installing from sources, recomendado para o desenvolvimento.
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.
Outros serviços¶
Weblate está usando outros serviços para sua operação. Você precisará pelo menos seguir os serviços em execução:
Servidor de banco de dados PostgreSQL, consulte Configuração de banco de dados para o Weblate.
Servidor Redis para cache e fila de tarefas, consulte Background tasks using Celery.
Servidor SMTP para e-mail de saída, consulte Configuração de e-mail de saída.
Dependências Python¶
Weblate é escrito em Python e tem suporte a Python 3.6 ou mais novo. Você pode instalar dependências usando pip ou de seus pacotes de distribuição, a lista completa está disponível em requirements.txt
.
As dependências mais notáveis:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Django REST Framework
Dependências opcionais¶
Os seguintes módulos são necessários para alguns recursos do Weblate. Você pode encontrar todos eles em requirements-optional.txt
.
Mercurial
(opcional para suporte a repositórios Mercurial)phply
(opcional para suporte a PHP)tesserocr
(opcional para OCR de capturas de tela)akismet
(opcional para a sugestão de proteção de spam)ruamel.yaml
(opcional para YAML files)Zeep
(opcional para Microsoft Terminology Service)aeidon
(opcional para Subtitle files)
Dependências de backend de banco de dados¶
O Weblate tem suporte a PostgreSQL, MySQL e MariaDB, consulte Configuração de banco de dados para o Weblate e a documentação dos backends para mais detalhes.
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 gir
https://cairographics.org/, https://pango.gnome.org/, veja Pango e Cairo
git-review
(opcional para suporte a Gerrit)git-svn
(opcional para suporte a Subversion)tesseract
e seus dados (opcional para OCR de capturas de tela)licensee
(opcional para detectar a licença ao criar o componente)
Dependências de tempo de compilação¶
Para compilar alguns das dependências Python, você pode precisar instalar suas dependências. Isso depende de como você instalá-las, por isso consulte pacotes individuais para obter documentação. Você não precisará deles se usar Wheels
précompilado durante a instalação usando pip
ou quando você usar pacotes de distribuição.
Pango e Cairo¶
Alterado na versão 3.7.
O Weblate usa Pango e Cairo para renderizar widgets bitmap (ver Promoting the translation) 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.
Verificando assinaturas de lançamento¶
Os lançamentos do Weblate é criptograficamente assinados pelo desenvolvedor que o lançou. Atualmente este é Michal Čihař. A impressão digital da chave PGP é:
63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D
e você pode obter mais informações de identificação de <https://keybase.io/nijel>.
Você deve verificar se a assinatura corresponde ao arquivo que você baixou. Desta forma, você pode ter certeza de que está usando o mesmo código que foi lançado. Você também deve verificar a data da assinatura para ter certeza de que você baixou a versão mais recente.
Cada arquivo é acompanhado com arquivos .asc
, os quais contêm a assinatura PGP para ele. Uma vez que você tenha ambos na mesma pasta, você pode verificar a assinatura:
$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg: using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found
Como você pode ver, o GPG reclama que não conhece a chave pública. Neste ponto você deve fazer um dos seguintes passos:
Use wkd para baixar a chave:
$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub rsa4096 2009-06-17 [SC]
63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid [ultimate] Michal Čihař <michal@cihar.com>
uid [ultimate] Michal Čihař <nijel@debian.org>
uid [ultimate] [jpeg image of size 8848]
uid [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub rsa4096 2009-06-17 [E]
sub rsa4096 2015-09-09 [S]
Baixe o chaveiro do servidor do Michal e importe-o com:
$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
Baixe e importe a chave de um dos principais servidores:
$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg: unchanged: 1
Isso vai melhorar um pouco a situação - neste momento, você pode verificar que a assinatura da chave dada está correta, mas você ainda não pode confiar no nome usado na chave:
$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg: using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg: aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg: aka "[jpeg image of size 8848]" [ultimate]
gpg: aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D
O problema aqui é que qualquer um poderia emitir a chave com este nome. Você precisa garantir que a chave é realmente propriedade da pessoa mencionada. O Manual de Privacidade do GNU aborda este tópico no capítulo Validating other keys on your public keyring. O método mais confiável é conhecer o desenvolvedor pessoalmente e trocar impressões digitais importantes, no entanto você também pode confiar na rede de confiança. Dessa forma, você pode confiar na chave transitivamente através de assinaturas de outros, que conheceram o desenvolvedor pessoalmente.
Uma vez que a chave seja confiável, o aviso não ocorrerá:
$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar 3 16:43:15 2019 CET
gpg: using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg: aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg: aka "[jpeg image of size 8848]" [ultimate]
gpg: aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
Se a assinatura for inválida (o arquivo foi alterado), você obteria um erro claro, independentemente do fato de que a chave é confiável ou não:
$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar 3 16:43:15 2019 CET
gpg: using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]
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 o Weblate.
A configuração padrão coloca-os na mesma árvore que os fontes do Weblate, no entanto, você pode preferir movê-los para um local melhor, como /var/lib/weblate
.
O Weblate tenta criar esses diretórios automaticamente, mas ele falhará quando não tiver permissões para fazê-lo.
Você também deve tomar cuidado ao executar Management commands, 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.
In the Docker container, all files in the /app/data
volume have to be
owned by weblate user inside the container (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.
Ver também
Usar um poderoso mecanismo de banco de dados, Databases, Migrating from other databases to PostgreSQL
PostgreSQL¶
PostgreSQL é geralmente a melhor escolha para sites baseados em Django. É o banco de dados de referência usado para implementar a camada de banco de dados Django.
Nota
O Weblate usa uma extensão de trigrama que deve ser instalada separadamente em alguns casos. Procure por postgresql-contrib
ou um pacote com nome similar.
Ver também
Criando um banco de dados no PostgreSQL¶
Geralmente é uma boa ideia executar o Weblate em um banco de dados separado e separar a conta do usuário:
# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"
# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate
# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -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 WITH SCHEMA weblate;
Configurando 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',
# Database password
'PASSWORD': 'password',
# Set to empty string for localhost
'HOST': 'database.example.com',
# Set to empty string for default
'PORT': '',
}
}
MySQL e MariaDB¶
Weblate também pode ser usado com MySQL ou MariaDB, consulte MySQL notes e MariaDB notes para ressalvas ao uso do Django com elas.
Dica
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.
Por causa disso, recomenda-se usar PostgreSQL para novas instalações.
A seguinte configuração é recomendada para Weblate:
Use o conjunto de caracteres
utf8mb4
para permitir a representação de planos Unicode mais altos (por exemplo, emojis).Configure o servidor com
Innodb_large_prefix
para permitir índices mais longos em campos de texto.Defina o nível de isolamento para
READ COMMITTED
.O modo SQL deve ser definido como
STRICT_TRANS_TABLES
.
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_HOST_USER
e EMAIL_PORT
. Seus nomes são bastante autoexplicativos, mas você pode encontrar mais informações na documentação do Django.
Nota
Você pode verificar se o e-mail de saída está funcionando corretamente usando o comando de gerenciamento sendtestemail
(veja Invoking management commands para instruções sobre como invocá-lo em diferentes ambientes).
Executando por trás de um proxy reverso¶
Vários recursos no Weblate dependem de ser capaz de obter endereço IP do cliente. Isso inclui Limitação de taxa, Spam protection ou Registro de auditoria.
Na configuração padrão, o Weblate analisa o endereço IP de REMOTE_ADDR
que é definido pelo manipulador WSGI.
No caso de você estiver usando um proxy reverso, este campo provavelmente conterá seu endereço. Você precisa configurar o Weblate para confiar em cabeçalhos HTTP adicionais e analisar o endereço IP destes. Isso não pode ser ativado por padrão, pois permitiria falsificação de endereço IP para instalações que não usam um proxy reverso. Habilitar IP_BEHIND_REVERSE_PROXY
pode ser suficiente para as configurações mais usuais, mas você pode precisar ajustar IP_PROXY_HEADER
e IP_PROXY_OFFSET
também.
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.
Ver também
ALLOWED_HOSTS
Você precisa definir isso para listar os hosts que seu site deve servir. Por exemplo:
ALLOWED_HOSTS = ['demo.weblate.org']Alternativamente, você pode incluir curinga:
ALLOWED_HOSTS = ['*']
SESSION_ENGINE
Configure como suas sessões serão armazenadas. Caso você mantenha o mecanismo de backend do banco de dados padrão, você deve agendar: weblate clearsessions para remover dados de sessão obsoletos do banco de dados.
Se você estiver usando o Redis como cache (veja Habilitar o cache) é recomendado usá-lo para sessões também:
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'Ver também
DATABASES
Conectividade ao servidor de banco de dados, verifique a documentação do Django para obter mais detalhes.
DEBUG
Desabilite isso para qualquer servidor de produção. Com o modo depuração ativado, o Django mostrará backtraces em caso de erro aos usuários, quando você desabilitá-lo, erros serão enviados por e-mail para
ADMINS
(veja acima).O modo depuração também diminui o Weblate, já que o Django armazena muito mais informações internamente neste caso.
Ver também
DEFAULT_FROM_EMAIL
Endereço de remetente de e-mail para e-mail de saída, por exemplo, e-mails de registro.
Ver também
SECRET_KEY
Chave usada por Django para assinar algumas informações em cookies, consulte Chave secreta do Django para obter mais informações.
Ver também
SERVER_EMAIL
E-mail usado como endereço de remetente para envio de e-mails ao administrador, por exemplo, notificações em mesclagens fracassadas.
Ver também
Preenchendo o banco de dados¶
Depois que sua configuração estiver pronta, você pode executar weblate migrate
para criar a estrutura do banco de dados. Agora você deve ser capaz de criar projetos de tradução usando a interface administrativa.
Caso você queira executar uma instalação não interativamente, você pode usar weblate migrate --noinput
e, em seguida, criar um usuário administrativo usando createadmin
comando.
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
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.
Habilitar o cache¶
Se possível, use Redis do Django ajustando a variável de configuração CACHES
, por exemplo:
CACHES = {
'default': {
'BACKEND': 'django_redis.cache.RedisCache',
'LOCATION': 'redis://127.0.0.1:6379/0',
# If redis is running on same host as Weblate, you might
# want to use unix sockets instead:
# 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
'OPTIONS': {
'CLIENT_CLASS': 'django_redis.client.DefaultClient',
'PARSER_CLASS': 'redis.connection.HiredisParser',
}
}
}
Ver também
Cache de avatares¶
Além do cache de Django, Weblate realiza cache de avatares. Recomenda-se usar um cache separado, baseado em arquivos para este fim:
CACHES = {
'default': {
# Default caching backend setup, see above
'BACKEND': 'django_redis.cache.RedisCache',
'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
'OPTIONS': {
'CLIENT_CLASS': 'django_redis.client.DefaultClient',
'PARSER_CLASS': 'redis.connection.HiredisParser',
}
},
'avatar': {
'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
'LOCATION': os.path.join(DATA_DIR, 'avatar-cache'),
'TIMEOUT': 604800,
'OPTIONS': {
'MAX_ENTRIES': 1000,
},
}
Configurar envio de e-mail¶
O Weblate precisa enviar e-mails em várias ocasiões, e esses e-mails devem ter um endereço de remetente correto, por favor, configure :configuração:`SERVER_EMAIL` e DEFAULT_FROM_EMAIL
para combinar com o seu ambiente, por exemplo:
SERVER_EMAIL = 'admin@example.org'
DEFAULT_FROM_EMAIL = 'weblate@example.org'
Nota
Para desabilitar o envio de e-mails pelo Weblate, defina EMAIL_BACKEND
para django.core.mail.backends.dummy.EmailBackend
.
Isso desabilitará toda entrega de e-mail, incluindo e-mails de registro ou redefinição de senha.
Configuração de hosts permitidos¶
Django requer ALLOWED_HOSTS
para manter uma lista de nomes de domínio que seu site pode servir, deixando-o vazio bloqueará quaisquer solicitações.
Caso isso não esteja configurado para corresponder ao seu servidor HTTP, você terá erros como Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Dica
No contêiner Docker, isso está disponível como WEBLATE_ALLOWED_HOSTS
.
Chave secreta do Django¶
A configuração SECRET_KEY
é usada pelo Django para assinar cookies, e você deve realmente gerar seu próprio valor em vez de usar o da configuração do exemplo.
Você pode gerar uma nova chave usando weblate/examples/generate-secret-key
, que vem com o Weblate.
Ver também
Diretório inicial¶
Alterado na versão 2.1: Isso não é mais necessário, o Weblate agora armazena todos os seus dados em DATA_DIR
.
O diretório home do usuário que executa o Weblate deve existir e ser escrito por este usuário. Isso é especialmente necessário se você quiser usar o SSH para acessar repositórios privados, mas o Git pode precisar acessar este diretório também (dependendo da versão git que você usa).
Você pode alterar o diretório usado pelo Weblate em settings.py
, por exemplo, para defini-lo como diretório configuration
na árvore do Weblate:
os.environ['HOME'] = os.path.join(BASE_DIR, 'configuration')
Nota
No Linux e em outros sistemas como UNIX, o caminho para o diretório home do usuário é definido em /etc/passwd
. Muitas distribuições usam como padrão um diretório sem permissão de escrita para usuários usados para servir conteúdo web (como apache
, www-data
ou wwwrun
), então você tem que executar o Weblate sob um usuário diferente ou alterar essa configuração.
Ver também
Carregamento de modelos¶
Recomenda-se usar um carregador de modelo em cache para Django. Ele armazena modelos analisados e evita a necessidade de fazer análise a cada solicitação. Você pode configurá-lo usando o trecho a seguir (a configuração loaders
é importante aqui):
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [
os.path.join(BASE_DIR, 'templates'),
],
'OPTIONS': {
'context_processors': [
'django.contrib.auth.context_processors.auth',
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.request',
'django.template.context_processors.csrf',
'django.contrib.messages.context_processors.messages',
'weblate.trans.context_processors.weblate_context',
],
'loaders': [
('django.template.loaders.cached.Loader', [
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
]),
],
},
},
]
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 agora é feito automaticamente por Background tasks using 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).
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
.
Alterado na versão 3.2: Desde a versão 3.2, a maneira padrão de executar essas tarefas é usar o Celery e o Weblate já vem com a configuração adequada, consulte Background tasks using Celery.
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. Por exemplo, ao usar o Apache, você pode querer defini-lo em /etc/apache2/envvars
:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Usando autoridade certificadora personalizada¶
O Weblate verifica os certificados SSL durante as solicitações HTTP. Caso você esteja usando uma autoridade de certificação personalizada que não seja confiável em pacotes padrão, você terá que adicionar seu certificado como confiável.
A abordagem preferida é fazer isso no nível do sistema. Consulte a documentação da sua distro para mais detalhes (por exemplo, no Debian isso pode ser feito colocando o certificado de AC em /usr/local/share/ca-certificates/
e executando update-ca-certificates).
Uma vez feito isso, as ferramentas do sistema confiarão no certificado e isso inclui o Git.
Para código Python, você precisará configurar solicitações para usar o pacote de AC do sistema em vez do enviado com ele. Isso pode ser conseguido colocando seguintes trechos para settings.py
(o caminho é específico do Debian):
import os
os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"
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¶
Você precisará de vários serviços para executar o Weblate, a configuração recomendada consiste em:
Servidor de banco de dados (consulte Configuração de banco de dados para o Weblate)
Servidor de cache (consulte Habilitar o cache)
Servidor web frontend para arquivos estáticos e terminação SSL (consulte Servindo arquivos estáticos)
Servidor Wsgi para conteúdo dinâmico (consulte Configuração de amostra para NGINX e uWSGI)
Celery para executar tarefas em segundo plano (consulte Background tasks using 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
.
Executando servidor web¶
Executar o Weblate não é diferente de executar qualquer outro programa baseado em Django. Django é geralmente executado como uWSGI ou fcgi (consulte exemplos para diferentes servidores web abaixo).
Para fins de teste, você pode usar o servidor web incorporado no Django:
weblate runserver
Aviso
NÃO USE ESTE SERVIDOR EM UMA CONFIGURAÇÃO DE PRODUÇÃO. Ele não passou por auditorias de segurança ou testes de desempenho. Veja também a documentação de Django no runserver
.
Dica
O servidor embutido do Django serve apenas arquivos 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, Sample configuration for Apache, Sample configuration for Apache and Gunicorn e Servindo arquivos estáticos.
Servindo arquivos estáticos¶
Alterado na versão 2.4: Antes da versão 2.4, o Weblate não usava corretamente a estrutura de arquivos estáticos do Django e a configuração era mais complexa.
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 DATA_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
)./media/
Usado para envio de mídia pelo usuário (por exemplo, capturas de tela).
/favicon.ico
Deve ser reescrito para reescrever uma regra para servir
/static/favicon.ico
.
Política de segurança de conteúdo¶
A configuração padrão do Weblate habilita o middleware weblate.middleware.SecurityMiddleware
que define cabeçalhos HTTP relacionados à segurança como Content-Security-Policy
ou X-XSS-Protection
. Eles são configurados por padrão para funcionar com o Weblate e sua configuração, mas isso pode precisar de personalização para o seu ambiente.
Ver também
CSP_SCRIPT_SRC
,
CSP_IMG_SRC
,
CSP_CONNECT_SRC
,
CSP_STYLE_SRC
,
CSP_FONT_SRC
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.7/site-packages/weblate/wsgi.py
). Não se esqueça de definir o caminho de pesquisa Python para 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.
Configuração para NGINX (também disponível como weblate/examples/weblate.nginx.conf
):
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# DATA_DIR/static/favicon.ico
alias /home/weblate/data/static/favicon.ico;
expires 30d;
}
location /static/ {
# DATA_DIR/static/
alias /home/weblate/data/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
):
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Ver também
Sample configuration for Apache¶
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (available as weblate/examples/apache.conf
):
#
# VirtualHost for Weblate
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# DATA_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/static/favicon.ico
# DATA_DIR/static/
Alias /static/ /home/weblate/data/static/
<Directory /home/weblate/data/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
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Nota
Weblate requires Python 3, so please make sure you are running Python 3
variant of the modwsgi. Usually it is available as a separate package, for
example libapache2-mod-wsgi-py3
.
Sample configuration for Apache and Gunicorn¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(available as weblate/examples/apache.gunicorn.conf
):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# DATA_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/static/favicon.ico
# DATA_DIR/static/
Alias /static/ /home/weblate/data/static/
<Directory /home/weblate/data/static/>
Require all granted
</Directory>
# DATA_DIR/media/
Alias /media/ /home/weblate/data/media/
<Directory /home/weblate/data/media/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass /media/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Ver também
Running Weblate under path¶
Alterado na versão 1.3: This is supported since Weblate 1.3.
A sample Apache configuration to serve Weblate under /weblate
. Again using
mod_wsgi (also available as weblate/examples/apache-path.conf
):
#
# VirtualHost for Weblate, running under /weblate path
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# DATA_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico
# DATA_DIR/static/
Alias /weblate/static/ /home/weblate/data/static/
<Directory /home/weblate/data/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
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Additionally, you will have to adjust weblate/settings.py
:
URL_PREFIX = '/weblate'
Background tasks using Celery¶
Novo na versão 3.2.
Weblate uses Celery to process background tasks. The example settings come with eager configuration, which does process all tasks in place, but you want to change this to something more reasonable for a production setup.
A typical setup using Redis as a backend looks like this:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = 'redis://localhost:6379'
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
You should also start the Celery worker to process the tasks and start scheduled tasks, this can be done directly on the command line (which is mostly useful when debugging or developing):
./weblate/examples/celery start
./weblate/examples/celery stop
Running Celery as system service¶
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, you can use the example files shipped in the examples
folder
listed below.
Systemd unit to be placed as /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
Environment configuration to be placed as /etc/default/celery-weblate
:
# Name of nodes to start
CELERYD_NODES="celery notify 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 concurency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
--queues:notify=notify --prefetch-multiplier:notify=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="/var/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
# Internal Weblate variable to indicate we're running inside Celery
CELERY_WORKER_RUNNING="1"
Logrotate configuration to be placed as /etc/logrotate.d/celery
:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Nota
The Celery process has to be executed under the same user as Weblate and the WSGI
process, otherwise files in the DATA_DIR
will be stored with
mixed ownership, leading to runtime issues.
Periodic tasks using Celery beat¶
Weblate comes with built-in setup for scheduled tasks. You can however define
additional tasks in settings.py
, for example see Commits adiados.
The tasks are supposed to be executed by Celery beats daemon. In case it is not working properly, it might not be running or its database was corrupted. Check the Celery startup logs in such case to figure out root cause.
Monitoring Celery status¶
You can use celery_queues
to see current length of Celery task
queues. In case the queue will get too long, you will also get configuration
error in the admin interface.
Aviso
The Celery errors are by default only logged into Celery log and are not visible to user. In case you want to have overview on such failures, it is recommended to configure Collecting error reports.
Monitoring Weblate¶
Weblate provides the /healthz/
URL to be used in simple health checks, for example
using Kubernetes.
Collecting error reports¶
Weblate, as any other software, can fail. In order to collect useful failure states we recommend to use third party services to collect such information. This is especially useful in case of failing Celery tasks, which would otherwise only report error to the logs and you won’t get notified on them. Weblate has support for the following services:
Sentry¶
Weblate has built-in support for Sentry. To use
it, it’s enough to set SENTRY_DSN
in the settings.py
:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Rollbar¶
Weblate has built-in support for Rollbar. To use it, it’s enough to follow instructions for Rollbar notifier for Python.
In short, you need to adjust settings.py
:
# Add rollbar as last middleware:
MIDDLEWARE = [
# … other middleware classes …
'rollbar.contrib.django.middleware.RollbarNotifierMiddleware',
]
# Configure client access
ROLLBAR = {
'access_token': 'POST_SERVER_ITEM_ACCESS_TOKEN',
'client_token': 'POST_CLIENT_ITEM_ACCESS_TOKEN',
'environment': 'development' if DEBUG else 'production',
'branch': 'master',
'root': '/absolute/path/to/code/root',
}
Everything else is integrated automatically, you will now collect both server and client side errors.
Migrating Weblate to another server¶
Migrating Weblate to another server should be pretty easy, however it stores data in few locations which you should migrate carefully. The best approach is to stop Weblate for the migration.
Migrating database¶
Depending on your database backend, you might have several options to migrate the database. The most straightforward one is to dump the database on one server and import it on the new one. Alternatively you can use replication in case your database supports it.
The best approach is to use database native tools, as they are usually the most effective (e.g. mysqldump or pg_dump). If you want to migrate between different databases, the only option might be to use Django management to dump and import the database:
# Export current data
weblate dumpdata > /tmp/weblate.dump
# Import dump
weblate loaddata /tmp/weblate.dump
Migrating VCS repositories¶
The VCS repositories stored under DATA_DIR
need to be migrated as
well. You can simply copy them or use rsync to do the migration
more effectively.
Other notes¶
Don’t forget to move other services Weblate might have been using like Redis, Cron jobs or custom authentication backends.