Instalando a usar Docker

Com a implantação do Weblate dockerizada, pode pôr a sua instância Weblate pessoal em funcionamento em segundos. Todas as dependências do Weblate já estão incluídas. PostgreSQL é configurado como o banco de dados padrão.

Requisitos de hardware

O Weblate deve funcionar em qualquer hardware contemporâneo sem problemas. A seguir está a configuração mínima necessária para executar o Weblate num único host (Weblate, banco de dados e servidor web):

2 GB de RAM
2 núcleos de CPU
1 GB de espaço de armazenamento

Quanto mais memória melhor – ele é usada para cache em todos os níveis (sistema de ficheiros, banco de dados e Weblate).

Muitos utilizadores simultâneos aumentam a quantidade de núcleos de CPU necessários. Para centenas de componentes de tradução é recomendado pelo menos 4 GB de RAM.

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 o tamanho mínimo deles a fazer clones rasos.

Nota

Os requisitos reais para a sua instalação do Weblate variam fortemente com base no tamanho das traduções geridas nele.

Instalação

Os exemplos a seguir presumem que tem um ambiente Docker funcional, com docker-compose instalado. Verifique a documentação do Docker para obter instruções.

Clone o repositório weblate-docker:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

Crie um ficheiro docker-compose.override.yml com as suas configurações. Veja Variáveis de ambiente do Docker para uma lista completa das variáveis de ambiente.

version: '3'
services:
  weblate:
    ports:
      - 80:8080
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SERVER_EMAIL: weblate@example.com
      WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for the admin user
      WEBLATE_ADMIN_EMAIL: weblate.admin@example.com

Nota

Se WEBLATE_ADMIN_PASSWORD não estiver definida, o utilizador admin é criado com uma palavra-passe aleatória mostrada na primeira inicialização.

O exemplo fornecido faz o Weblate escutar na porta 80. Edite o mapeamento da porta no ficheiro docker-compose.override.yml para alterar isso.

Inicie os contentores do Weblate:
```
docker-compose up
```

Aproveite a implantação do Weblate, ele está acessível na porta 80 do contentor weblate.

Alterado na versão 2.15-2: A configuração foi alterada recentemente, antes havia um contentor de servidor web separado, desde 2.15-2 o servidor web está embutido no contentor do Weblate.

Alterado na versão 3.7.1-6: Em julho de 2019 (a começar com a tag 3.7.1-6), os contentores não estão a ser executados como um utilizador root. Isso mudou a porta exposta de 80 para 8080.

Veja também

Invocando comandos de gestão

Escolhendo a tag do hub Docker

Pode usar as seguintes tags no hub do Docker, veja https://hub.docker.com/r/weblate/weblate/tags/ para uma lista completa das tags disponíveis.

Nome da tag	Descrição	Caso de uso
`latest`	Versão estável do Weblate, corresponde à última versão marcada	Atualizações contínuas num ambiente de produção
`<VERSION>-<PATCH>`	Versão estável do Weblate	Implantação bem definida num ambiente de produção
`edge`	Lançamento estável do Weblate com alterações de desenvolvimento no contentor Docker (por exemplo, dependências atualizadas)	Atualizações contínuas num ambiente de teste
`edge-<DATE>-<SHA>`	Lançamento estável do Weblate com alterações de desenvolvimento no contentor Docker (por exemplo, dependências atualizadas)	Implantação bem definida num ambiente de teste
`bleeding`	Versão de desenvolvimento do Weblate do Git	Atualizações contínuas para testar os próximos recursos do Weblate
`bleeding-<DATE>-<SHA>`	Versão de desenvolvimento do Weblate do Git	Implantação bem definida para testar os próximos recursos da Weblate

Cada imagem é testada pelo nosso CI antes de ser publicada, então até mesmo a versão bleeding deve ser bastante segura de usar.

Contentor Docker com suporte a HTTPS

Por favor, veja Instalação para instruções genéricas de implantação, esta secção apenas menciona diferenças em comparação a ela.

Usando os seus próprios certificados SSL

Novo na versão 3.8-3.

No caso de ter o seu próprio certificado SSL que deseja usar, basta pôr os ficheiros no volume de dados Weblate (veja Volumes de contentor Docker):

ssl/fullchain.pem a conter o certificado, incluindo quaisquer certificados CA necessários
ssl/privkey.pem a conter a chave privada

Ambos os ficheiros devem pertencer ao mesmo utilizador que inicia o contentor do docker e ter a máscara de ficheiro definida como 600 (legível e gravável apenas pelo utilizador dono).

Além disso, o contentor Weblate agora aceitará conexões SSL na porta 4443. Ainda quererá incluir o encaminhamento de porta para HTTPS na substituição de composição do docker:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

Se já hospeda outros sites no mesmo servidor, é provável que as portas 80 e 443 sejam usadas por um proxy reverso, como NGINX. Para passar a conexão HTTPS do NGINX para o contentor do docker, pode usar a seguinte configuração:

server {
    listen 443;
    listen [::]:443;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

Substitua <SITE_URL>, <SITE> e <EXPOSED_DOCKER_PORT> por valores reais do seu ambiente.

Certificados SSL automáticos a usar Let’s Encrypt

Caso queira usar certificados SSL Let’s Encrypt gerados automaticamente na instalação pública, precisa adicionar um proxy HTTPS reverso num contentor Docker adicional, https-portal será usado para isso. Isso é usado no ficheiro docker-compose-https.yml. Em seguida, crie um ficheiro docker-compose-https.override.yml com as suas configurações:

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

Sempre que invocar docker-compose, precisa passar os dois ficheios a ele e então fazer:

docker-compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker-compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Atualizando o contentor Docker

Normalmente, é uma boa ideia atualizar apenas o contentor Weblate e manter o contentor PostgreSQL na versão que possui, já que atualizar o PostgreSQL é muito doloroso e na maioria dos casos não traz muitos benefícios.

Alterado na versão 4.10-1: Desde o Weblate 4.10-1, o contentor Docker usa Django 4.0, o que requer PostgreSQL 10 ou mais recente, atualize-o antes de atualizar o Weblate. Veja Atualizar da 4.9 para 4.10 e Atualizando contentor PostgreSQL.

Pode fazer isso a manter o docker-compose existente e apenas obter as imagens mais recentes e reiniciar:

# Fetch latest versions of the images
docker-compose pull
# Stop and destroy the containers
docker-compose down
# Spawn new containers in the background
docker-compose up -d
# Follow the logs during upgrade
docker-compose logs -f

O banco de dados do Weblate deve ser migrado automaticamente na primeira inicialização e não deve haver necessidade de ações manuais adicionais.

Nota

Atualizações entre versões principais não são suportadas pelo Weblate. Se estiver na série 3.x e quiser atualizar para 4.x, primeiro atualize à imagem 4.0.x-y mais recente (no momento em que escrevo esta é a 4.0.4-5), que faça a migração e, em seguida, continue atualizando para as versões mais recentes.

Também pode atualizar o repositório docker-compose, embora não seja necessário na maioria dos casos. Veja Atualizando contentor PostgreSQL para atualizar o servidor PostgreSQL.

Atualizando contentor PostgreSQL

Os contentores PostgreSQL não oferecem suporte a atualização automática entre versões, precisa realizar a atualização manualmente. Os passos a seguir mostram uma das opções de atualização.

Veja também

https://github.com/docker-library/postgres/issues/37

Pare o contentor do Weblate:
```
docker-compose stop weblate cache
```

Faça backup do banco de dados:

docker-compose exec database pg_dumpall --clean --username weblate > backup.sql

Pare o contentor de banco de dados:
```
docker-compose stop database
```

Remova o volume do PostgreSQL:

docker-compose rm -v database
docker volume remove weblate_postgres-data

Ajuste o docker-compose.yml para usar a nova versão do PostgreSQL.
Inicie o contentor de banco de dados:
```
docker-compose up -d database
```

Restaure o banco de dados a partir do backup:

cat backup.sql | docker-compose exec -T database psql --username weblate --dbname postgres

Inicie todos os contentores restantes:
```
docker-compose up -d
```

Autenticação como administrador

Após a configuração do contentor, pode entrar como utilizador admin com a palavra-passe fornecida em WEBLATE_ADMIN_PASSWORD, ou uma palavra-passe aleatória gerada na primeira inicialização se não tiver sido definida.

Para redefinir a palavra-passe do admin, reinicie o contentor com WEBLATE_ADMIN_PASSWORD definido com a nova palavra-passe.

Veja também

WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

Quantidade de processos e consumo de memória

A quantidade de processos de trabalho para uWSGI e Celery é determinado automaticamente com base no quantidade de CPUs. Isso funciona bem para a maioria das máquinas virtuais em nuvem, pois normalmente têm poucas CPUs e boa quantidade de memória.

Caso tenha muitos núcleos de CPU e tenha problemas de memória insuficiente, tente reduzir a quantidade de workers:

environment:
  WEBLATE_WORKERS: 2

Também pode ajustar as categorias de workers individuais:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Veja também

WEBLATE_WORKERS CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, WEB_WORKERS

Dimensionando horizontalmente

Novo na versão 4.6.

Pode executar vários contentores Weblate para dimensionar o serviço horizontalmente. O volume /app/data deve ser compartilhado por todos os contentores, é recomendado usar um sistema de ficheiros de cluster como o GlusterFS para isso. O volume /app/cache deve ser separado para cada contentor.

Cada contentor Weblate tem um papel definido a usar a variável de ambiente WEBLATE_SERVICE. Siga atentamente a documentação, pois alguns dos serviços devem ser executados apenas uma vez no cluster e a ordem dos serviços também é importante.

Pode encontrar configuração de exemplo no repositório docker-compose como docker-compose-split.yml.

Variáveis de ambiente do Docker

Muitas das Configurações do Weblate podem ser definidas no contentor Docker a usar variáveis de ambiente:

Configurações genéricas

WEBLATE_DEBUG

Configura o modo de depuração do Django a usar DEBUG.

Exemplo:

environment:
  WEBLATE_DEBUG: 1

Veja também

Desativar o modo de depuração

WEBLATE_LOGLEVEL: Configura o detalhamento do log.

WEBLATE_LOGLEVEL_DATABASE: Configura o log da verbosidade das consultas ao banco de dados.

WEBLATE_SITE_TITLE: Altera o título do site mostrado no cabeçalho de todas as páginas.

WEBLATE_SITE_DOMAIN: Configura o domínio do site. Este parâmetro é obrigatório.

Veja também

Definir domínio correto do site, SITE_DOMAIN

WEBLATE_ADMIN_NAME

WEBLATE_ADMIN_EMAIL

Configura o nome e o e-mail do administrador do site. É usado para ADMINS e para criar o utilizador admin (veja WEBLATE_ADMIN_PASSWORD para mais informações).

Exemplo:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

Veja também

Autenticação como administrador, Configurar administradores corretamente, ADMINS

WEBLATE_ADMIN_PASSWORD

Define a palavra-passe para o utilizador admin.

Se não for definido e o utilizador admin não existir, ele será criado com uma palavra-passe aleatória mostrada na primeira inicialização do contentor.
Se não for definido e o utilizador admin existir, nenhuma ação será executada.
Se definido, o utilizador admin é ajustado em cada inicialização do contentor para corresponder a WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME e WEBLATE_ADMIN_EMAIL.

Aviso

Pode ser um risco de segurança armazenar a palavra-passe no ficheiro de configuração. Considere usar essa variável apenas para configuração inicial (ou deixe o Weblate gerar uma palavra-passe aleatória na inicialização) ou para recuperação de palavra-passe.

Veja também

Autenticação como administrador, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_PASSWORD_FILE, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_PASSWORD_FILE: Define o caminho para um ficheiro que contém a palavra-passe para o utilizador admin.

Veja também

WEBLATE_ADMIN_PASSWORD

WEBLATE_SERVER_EMAIL: O endereço de e-mail a partir do qual as mensagens de erro são enviadas.

Veja também

SERVER_EMAIL, Configurar envio de e-mail

WEBLATE_DEFAULT_FROM_EMAIL: Configura o endereço para e-mails de saída.

Veja também

DEFAULT_FROM_EMAIL, Configurar envio de e-mail

WEBLATE_CONTACT_FORM: Configura o comportamento do formulário de contato, veja CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS

Configura os nomes de host HTTP permitidos a usar ALLOWED_HOSTS.

O padrão é `` * `` que permite todos os nomes de host.

Exemplo:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

Veja também

ALLOWED_HOSTS, Configuração de hosts permitidos, Definir domínio correto do site

WEBLATE_REGISTRATION_OPEN

Configura se os registos são abertos a alternar REGISTRATION_OPEN.

Exemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS

Configura quais métodos de autenticação podem ser usados para criar uma nova conta via REGISTRATION_ALLOW_BACKENDS.

Exemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_TIME_ZONE

Configura o fuso horário usado no Weblate, veja django: TIME_ZONE.

Nota

Para alterar o fuso horário do próprio contentor do Docker, use a variável de ambiente `` TZ``.

Exemplo:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS

Faz com que o Weblate presuma que é operado por trás de um proxy HTTPS reverso, faz com que o Weblate use HTTPS em e-mail e ligações de API ou defina sinalizadores seguros em cookies.

Dica

Por favor, consulte a documentação de ENABLE_HTTPS para possíveis advertências.

Nota

Isso não faz com que o contentor Weblate aceite conexões HTTPS, precisa configurar isso também, consulte Contentor Docker com suporte a HTTPS para exemplos.

Exemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Veja também

ENABLE_HTTPS Definir domínio correto do site, WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS: Novo na versão 4.12.1.

Permite que o Weblate defina o campo meta[nome=monetização] no cabeçalho do documento. Se vários forem especificados, escolhe um aleatoriamente.

Veja também

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER

Permite que o Weblate obtenha o endereço IP de qualquer cabeçalho HTTP fornecido. Use isso ao usar um proxy reverso na frente do contentor Weblate.

Ativa IP_BEHIND_REVERSE_PROXY e define IP_PROXY_HEADER.

Nota

O formato deve estar de acordo com as expectativas do Django. O Django transforma nomes de cabeçalho HTTP brutos da seguinte forma:

converte todos os caracteres em maiúsculas
substitui todos os hifenes por sublinhados
prefixa o prefixo HTTP_

Portanto, X-Forwarded-For seria mapeado para HTTP_X_FORWARDED_FOR.

Exemplo:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_SECURE_PROXY_SSL_HEADER

Uma tupla que representa uma combinação de cabeçalho/valor HTTP que significa que uma solicitação é segura. Isso é necessário quando o Weblate está a ser executado por trás de um proxy reverso a fazer a terminação SSL que não passa cabeçalhos HTTPS padrão.

Exemplo:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Veja também

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN

Ativa REQUIRE_LOGIN para impor autenticação em todo o Weblate.

Exemplo:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS

Adiciona exceções de URL para autenticação necessária para toda a instalação do Weblate a usar LOGIN_REQUIRED_URLS_EXCEPTIONS.

Pode substituir configurações inteiras ou modificar o valor padrão a usar as variáveis ADD e REMOVE.

WEBLATE_GOOGLE_ANALYTICS_ID: Configura o ID para o Google Analytics a alterar GOOGLE_ANALYTICS_ID.

WEBLATE_GITHUB_USERNAME

WEBLATE_GITHUB_TOKEN

WEBLATE_GITHUB_HOST: Configures GitHub pull-requests integration by changing GITHUB_CREDENTIALS (if WEBLATE_GITHUB_HOST is set), or GITHUB_USERNAME and GITHUB_TOKEN.

Veja também

Pull requests do GitHub

WEBLATE_GITLAB_USERNAME

WEBLATE_GITLAB_TOKEN

WEBLATE_GITLAB_HOST: Configures GitLab merge-requests integration by changing GITLAB_CREDENTIALS (if WEBLATE_GITLAB_HOST is set), or GITLAB_USERNAME and GITLAB_TOKEN.

Veja também

Merge requests do GitLab

WEBLATE_GITEA_USERNAME

WEBLATE_GITEA_TOKEN

WEBLATE_GITEA_HOST: Configures Gitea pull-requests integration by changing GITEA_CREDENTIALS (if WEBLATE_GITEA_HOST is set), or GITEA_USERNAME and GITEA_TOKEN.

Veja também

Pull requests do Gitea

WEBLATE_PAGURE_USERNAME

WEBLATE_PAGURE_TOKEN

WEBLATE_PAGURE_HOST: Configures Pagure merge-requests integration by changing PAGURE_CREDENTIALS (if WEBLATE_PAGURE_HOST is set), or PAGURE_USERNAME and PAGURE_TOKEN.

Veja também

Merge requests do Pagure

WEBLATE_DEFAULT_PULL_MESSAGE: Configura o título e a mensagem padrão para pull requests via API alterando DEFAULT_PULL_MESSAGE

Veja também

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES: Configura a política de simplificação de idioma, veja SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL: Configura o padrão Controlo de acesso para novos projetos, veja DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT: Configura o valor padrão para Acesso restrito para novos componentes, veja DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION: Configura o valor padrão para Permitir propagação da tradução para novos componentes, veja DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL: Configura DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME: Configura DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM: Configura DEFAULT_SHARED_TM.

WEBLATE_AKISMET_API_KEY: Configura a chave API do Akismet, veja AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY: Configura a assinatura GPG de commits, veja WEBLATE_GPG_IDENTITY.

Veja também

Assinando commits do Git com GnuPG

WEBLATE_URL_PREFIX: Configura o prefixo da URL onde o Weblate está a ser executado, veja URL_PREFIX.

WEBLATE_SILENCED_SYSTEM_CHECKS: Configura verificações que não deseja que sejam mostradas, veja django: SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC

WEBLATE_CSP_IMG_SRC

WEBLATE_CSP_CONNECT_SRC

WEBLATE_CSP_STYLE_SRC

WEBLATE_CSP_FONT_SRC: Permite personalizar o cabeçalho HTTP Content-Security-Policy.

Veja também

Política de segurança de conteúdo, CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

WEBLATE_LICENSE_FILTER: Configura LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED: Configura LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED: Configura WEBSITE_REQUIRED

WEBLATE_HIDE_VERSION: Configura HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES: Configura BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH: Configura DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS

WEBLATE_RATELIMIT_LOCKOUT

WEBLATE_RATELIMIT_WINDOW: Novo na versão 4.6.

Configura o limitador de taxa.

Dica

Pode definir a configuração para qualquer escopo do limitador de taxa. Para fazer isso, adicione o prefixo WEBLATE_ a qualquer uma das configurações descritas em Limitação de taxa.

Veja também

Limitação de taxa, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON

WEBLATE_API_RATELIMIT_USER: Novo na versão 4.11.

Configura a limitação de taxa da API. O padrão é 100/day para utilizadores anônimos e 5000/hour para utilizadores autenticados.

Veja também

Limitação de taxa da API

WEBLATE_ENABLE_HOOKS: Novo na versão 4.13.

Configura ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS: Novo na versão 4.6.1.

Configura ENABLE_AVATARS.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH: Novo na versão 4.9.

Configura LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS: Novo na versão 4.9.

Configura SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS: Novo na versão 4.9.

Configura BORG_EXTRA_ARGS.

WEBLATE_ENABLE_SHARING: Novo na versão 4.14.1.

Configures ENABLE_SHARING.

Configurações de sugestões automáticas

Alterado na versão 4.13: Serviços de sugestões automáticas agora são configurados na interface de utilizador, consulte Configurando sugestões automáticas.

As variáveis de ambiente atuais são importadas durante a migração ao Weblate 4.13, mas alterá-las não surtirá nenhum efeito.

Configurações de autenticação

LDAP

WEBLATE_AUTH_LDAP_SERVER_URI

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE

WEBLATE_AUTH_LDAP_USER_ATTR_MAP

WEBLATE_AUTH_LDAP_BIND_DN

WEBLATE_AUTH_LDAP_BIND_PASSWORD

WEBLATE_AUTH_LDAP_BIND_PASSWORD_FILE: Caminho ao ficheiro que contém a palavra-passe de ligação do servidor LDAP.

Veja também

WEBLATE_AUTH_LDAP_BIND_PASSWORD

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS

WEBLATE_AUTH_LDAP_USER_SEARCH

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER

Configuração de autenticação LDAP.

Exemplo para vinculação direta:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

Exemplo para pesquisa e vinculação:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

Exemplo para vinculação e pesquisa de união:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Exemplo com pesquisar e vincular ao Active Directory:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

Veja também

Autenticação por LDAP

GitHub

WEBLATE_SOCIAL_AUTH_GITHUB_KEY

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID: Ativa Autenticação por GitHub.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET: Ativa Autenticação por Bitbucket.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET: Ativa OAuth 2 do Facebook.

Google

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS: Ativa OAuth 2 do Google.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL: Ativa OAuth 2 do GitLab.

Active Directory do Azure

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET: Ativa autenticação por Active Directory do Azure, veja Active Directory do Microsoft Azure.

Active Directory do Azure com suporte a Tenant

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID: Ativa autenticação por Active Directory do Azure com suporte a Tenant, veja Active Directory do Microsoft Azure.

Keycloak

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY

WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET

WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM

WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL

WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE

WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE: Ativa autenticação com Keycloak, veja a documentação.

Fornecedores Linux

Pode ativar a autenticação a usar serviços de autenticação de fornecedores Linux, a definir as seguintes variáveis para qualquer valor.

WEBLATE_SOCIAL_AUTH_FEDORA

WEBLATE_SOCIAL_AUTH_OPENSUSE

WEBLATE_SOCIAL_AUTH_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY

SOCIAL_AUTH_SLACK_SECRET: Ativa a autenticação Slack, veja Slack.

OpenID Connect

Novo na versão 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT

WEBLATE_SOCIAL_AUTH_OIDC_KEY

WEBLATE_SOCIAL_AUTH_OIDC_SECRET

WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY: Configura a intergração genérica do OpenID Connect.

Veja também

OIDC (OpenID Connect)

SAML

Chaves SAML autoassinadas são geradas automaticamente na primeira inicialização do contentor. Caso queira usar chaves próprias, ponha o certificado e a chave privada em /app/data/ssl/saml.crt e /app/data/ssl/saml.key.

WEBLATE_SAML_IDP_ENTITY_ID

WEBLATE_SAML_IDP_URL

WEBLATE_SAML_IDP_X509CERT

WEBLATE_SAML_IDP_IMAGE

WEBLATE_SAML_IDP_TITLE: Configurações do provedor de identidade SAML, consulte Autenticação por SAML.

Outras configurações de autenticação

WEBLATE_NO_EMAIL_AUTH: Desativa autenticação por e-mail quando definido com algum valor. Veja Desativar autenticação por palavra-passe.

Configuração de banco de dados PostgreSQL

O banco de dados é criado por docker-compose.yml, então essas configurações afetam os contentores Weblate e PostgreSQL.

Veja também

Configuração de banco de dados para o Weblate

POSTGRES_PASSWORD: Palavra-passe do PostgreSQL.

POSTGRES_PASSWORD_FILE: Caminho para o ficheiro que contém a palavra-passe do PostgreSQL. Use como uma alternativa para POSTGRES_PASSWORD.

POSTGRES_USER: Nome de utilizador do PostgreSQL.

POSTGRES_DATABASE: Nome do banco de dados PostgreSQL.

POSTGRES_HOST: Nome de host ou endereço IP do servidor PostgreSQL. O padrão é database.

POSTGRES_PORT: Porta do servidor PostgreSQL. O padrão é nenhum (usa o valor padrão).

POSTGRES_SSL_MODE: Configura como o PostgreSQL lida com SSL em conexão com o servidor, para as opções possíveis, consulte SSL Mode Descriptions

POSTGRES_ALTER_ROLE: Configura o nome da função para alterar durante as migrações, consulte Configurar Weblate para usar PostgreSQL.

POSTGRES_CONN_MAX_AGE

Novo na versão 4.8.1.

O tempo de vida de uma conexão de banco de dados, como um número inteiro de segundos. Use 0 para fechar as conexões do banco de dados no final de cada requisição (este é o comportamento predefinido).

Ativar a persistência da conexão normalmente causará uma conexão mais aberta com o banco de dados. Por favor, ajuste a sua configuração do banco de dados antes de ativar.

Exemplo de configuração:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Veja também

CONN_MAX_AGE, Persistent connections

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Novo na versão 4.9.1.

Desativa os cursores do lado do servidor no banco de dados. Isso é necessário em algumas configurações do pgbouncer.

Exemplo de configuração:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Veja também

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

Configurações de backup de base de dados

Veja também

Dados despejados para backups

WEBLATE_DATABASE_BACKUP: Configura o despejo diário do banco de dados a usar DATABASE_BACKUP. O padrão é plain.

Configuração do servidor de cache

O uso do Redis é altamente recomendado pelo Weblate e deve fornecer uma instância do Redis ao executar o Weblate no Docker.

Veja também

Ativar o cache

REDIS_HOST: O nome de host ou endereço IP do servidor Redis. O padrão é cache.

REDIS_PORT: A porta do servidor Redis. O padrão é 6379.

REDIS_DB: O número do banco de dados Redis, o padrão é 1.

REDIS_PASSWORD: A palavra-passe do servidor Redis, não usada por padrão.

REDIS_PASSWORD_FILE: Caminho ao ficheiro que contém a palavra-passe do servidor Redis.

Veja também

REDIS_PASSWORD

REDIS_TLS: Ativa o uso de SSL para conexão Redis.

REDIS_VERIFY_SSL: Pode ser usado para desativar a verificação de certificado SSL para conexão Redis.

Configuração do servidor de e-mail

Para fazer com que o e-mail de saída funcione, precisa fornecer um servidor de e-mail.

Exemplo de configuração TLS:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

Exemplo de configuração SSL:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1

Veja também

Configuração de e-mail de saída

WEBLATE_EMAIL_HOST: Nome de host ou endereço IP do servidor de correio.

Veja também

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, WEBLATE_EMAIL_USE_TLS, EMAIL_HOST

WEBLATE_EMAIL_PORT: Porta do servidor de correio, o padrão é 25.

Veja também

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER: Utilizador da autenticação por e-mail.

Veja também

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD: Palavra-passe da autenticação por e-mail.

Veja também

EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_HOST_PASSWORD_FILE: Caminho para o ficheiro que contém a palavra-passe da autenticação por e-mail.

Veja também

WEBLATE_EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL: Se deve usar uma conexão TLS (segura) implícita ao falar com o servidor SMTP. Na maioria das documentações de e-mail, esse tipo de conexão TLS é conhecido como SSL. Geralmente é usado na porta 465. Se estiver a ter problemas, consulte a configuração TLS explícita WEBLATE_EMAIL_USE_TLS.

Alterado na versão 4.11: O suporte a SSL/TLS é ativado automaticamente com base em WEBLATE_EMAIL_PORT.

Veja também

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_TLS, EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS: Se deve usar uma conexão TLS (segura) ao falar com o servidor SMTP. Isso é usado para conexões TLS explícitas, geralmente na porta 587 ou 25. Se estiver a ter conexões travadas, consulte a configuração TLS implícita WEBLATE_EMAIL_USE_SSL.

Alterado na versão 4.11: O suporte a SSL/TLS é ativado automaticamente com base em WEBLATE_EMAIL_PORT.

Veja também

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND: Configura o back-end do Django para usar no envio de e-mails.

Veja também

Configurar envio de e-mail, EMAIL_BACKEND

WEBLATE_AUTO_UPDATE: Configura se e como o Weblate deve atualizar os repositórios.

Veja também

AUTO_UPDATE

Nota

Esta é uma configuração booleana (use "true" ou "false").

Integração do site

WEBLATE_GET_HELP_URL: Configura GET_HELP_URL.

WEBLATE_STATUS_URL: Configura STATUS_URL.

WEBLATE_LEGAL_URL: Configura LEGAL_URL.

WEBLATE_PRIVACY_URL: Configura PRIVACY_URL.

Relatório de erro

É recomendado coletar erros da instalação sistematicamente, veja Coletando relatórios de erros.

Para ativar o suporte para Rollbar, defina o seguinte:

ROLLBAR_KEY: O seu token de acesso ao servidor de postagem Rollbar.

ROLLBAR_ENVIRONMENT: O seu ambiente Rollbar, o padrão é production.

Para ativar o suporte para Sentry, defina o seguinte:

SENTRY_DSN: O seu DSN no Sentry.

SENTRY_ENVIRONMENT: O seu ambiente no Sentry (opcional).

CDN de localização

WEBLATE_LOCALIZE_CDN_URL

WEBLATE_LOCALIZE_CDN_PATH

Novo na versão 4.2.1.

Configuração para CDN de localização JavaScript.

O WEBLATE_LOCALIZE_CDN_PATH é o caminho dentro do contentor. Ele deve ser armazenado no volume persistente e não no armazenamento temporário.

Uma das possibilidades é armazenar isso dentro do diretório de dados do Weblate:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

Nota

É responsável por configurar o serviço dos ficheiros gerados pelo Weblate, ele só armazena os ficheiros no local configurado.

Veja também

Traduzir HTML e JavaScript a usar CDN Weblate, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

Alterar aplicações, verificações, extensões ou correções automáticas ativados

Novo na versão 3.8-5.

A configuração embutida de verificações, extensões ou correções automática ativados pode ser ajustada pelas seguintes variáveis:

WEBLATE_ADD_APPS

WEBLATE_REMOVE_APPS

WEBLATE_ADD_CHECK

WEBLATE_REMOVE_CHECK

WEBLATE_ADD_AUTOFIX

WEBLATE_REMOVE_AUTOFIX

WEBLATE_ADD_ADDONS

WEBLATE_REMOVE_ADDONS

Exemplo:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Veja também

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

Configurações do contentor

WEBLATE_WORKERS

Novo na versão 4.6.1.

Quantidade base de processos de trabalho em execução no contentor. Quando não definido, é determinado automaticamente na inicialização do contentor com base na quantidade de núcleos de CPU disponíveis.

É usado para determinar CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS e WEB_WORKERS. Pode usar essas configurações para fazer o ajuste fino.

CELERY_MAIN_OPTIONS

CELERY_NOTIFY_OPTIONS

CELERY_MEMORY_OPTIONS

CELERY_TRANSLATE_OPTIONS

CELERY_BACKUP_OPTIONS

CELERY_BEAT_OPTIONS

Essas variáveis permitem que ajuste as opções do worker do Celery. Pode ser útil ajustar a simultaneidade (--concurrency 16) ou usar diferentes implementações de pool (--pool=gevent).

Por padrão, a quantidade de workers simultâneos é baseado em WEBLATE_WORKERS.

Exemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Veja também

Opções de worker do Celery, Tarefas de fundo a usar o Celery

WEB_WORKERS

Configura quantos workers uWSGI devem ser executados.

O padrão é WEBLATE_WORKERS.

Exemplo:

environment:
  WEB_WORKERS: 32

WEBLATE_SERVICE

Define quais serviços devem ser executados dentro do contentor. Use isto para Dimensionando horizontalmente.

Os seguintes serviços são definidos:

celery-beat: Agendador de tarefas do Celery, apenas uma instância deve estar em execução. Este contentor também é responsável pelas migrações da estrutura do banco de dados e deve ser iniciado antes dos demais.
celery-backup: Worker do Celery para backups, apenas uma instância deve estar em execução.
celery-celery: Worker genérico do Celery.
celery-memory: Worker do Celery para memória de tradução.
celery-notify: Worker do Celery para notificações.
celery-translate: Worker do Celery para tradução automática.
web: Servidor web.

Volumes de contentor Docker

Há dois volumes (dados e cacho) exportados pelo contentor Weblate. Os outros contentores de serviço (PostgreSQL ou Redis) também têm os volumes de dados deles, mas eles não são cobertos por este documento.

O volume de dados é usado para armazenar dados persistentes do Weblate, como repositórios clonados ou para personalizar a instalação do Weblate.

O posicionamento do volume Docker no sistema hospedeiro depende da configuração do Docker, mas geralmente é armazenado em /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (o caminho consiste no nome de seu diretório docker-compose, contentor e nomes de volume). No contentor, ele é montado como /app/data.

O volume do cache é montado como /app/cache e é usado para armazenar ficheiros estáticos. O conteúdo deles é recriado na inicialização do contentor e o volume pode ser montado a usar um sistema de ficheiros efêmero como tmpfs.

Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o utilizador usado dentro do contentor.

Veja também

Documentação sobre volumes do Docker

Personalização adicional da configuração

Pode personalizar ainda mais a instalação do Weblate no volume de dados, veja Volumes de contentor Docker.

Ficheiros de configuração personalizados

Também pode sobrescrever a configuração em /app/data/settings-override.py (veja Volumes de contentor Docker). Isso é executado no final das configurações embutidas, depois que todas as configurações de ambiente são carregadas e pode ajustá-las ou substituí-las.

Substituindo o logotipo e outros ficheiros estáticos

Novo na versão 3.8-5.

Os ficheiros estáticos que vêm com Weblate podem ser sobrescritos a colocar em /app/data/python/customize/static (veja Volumes de contentor Docker). Por exemplo, criar /app/data/python/customize/static/favicon.ico substituirá o favicon.

Dica

Os ficheiros são copiados para o local correspondente na inicialização do contentor, portanto, é necessário reiniciar o Weblate após alterar o conteúdo do volume.

Essa abordagem também pode ser usada para substituir os modelos Weblate. Por exemplo documentos legais podem ser postos em /app/data/python/customize/templates/legal/documents.

Como alternativa, também pode incluir o próprio módulo (veja ../ customize) e adicioná-lo como um volume separado ao contentor do Docker, por exemplo:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

Adicionando os seus próprios módulos Python

Novo na versão 3.8-5.

Pode pôr os próprios módulos Python em /app/data/python/ (veja Volumes de contentor Docker) e eles podem ser carregados pelo Weblate, provavelmente a usar docker-custom -config.

Veja também

Personalizar o Weblate

Configurando o servidor PostgreSQL

O contentor PostgtreSQL usa a configuração padrão do PostgreSQL e não utilizará efetivamente os núcleos de CPU ou memória dele. Recomenda-se personalizar a configuração para melhorar o desempenho.

A configuração pode ser ajustada conforme descrito em Database Configuration em https://hub.docker.com/_/postgres. A configuração correspondente ao seu ambiente pode ser gerada usando https://pgtune.leopard.in.ua/.