Instalando usando Docker¶

With dockerized Weblate deployment you can get your personal Weblate instance up and running in seconds. All of Weblate’s dependencies are already included. PostgreSQL is set up as the default database and Redis as a caching backend.

Requisitos de hardware¶

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

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

Nota

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

Memory usage¶

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

Dica

For systems with less memory than recommended, Single-process Celery setup is recommended.

CPU usage¶

Many concurrent users increase the amount of needed CPU cores.

Storage usage¶

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Nodes¶

For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Configuração de banco de dados para o Weblate).

Instalação¶

Dica

The following examples assume you have a working Docker environment, with docker-compose-plugin installed. Please check the Docker documentation for instructions.

This creates a Weblate deployment server via HTTP, so you should place it behind HTTPS terminating proxy. You can also deploy with a HTTPS proxy, see Certificados SSL automáticos usando Let’s Encrypt. For larger setups, please see Dimensionamento horizontal.

Clone o repositório weblate-docker:

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

Crie um arquivo docker-compose.override.yml com 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 usuário admin é criado com uma senha aleatória mostrada na primeira inicialização.

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

Inicie os contêineres do Weblate:
```
docker compose up
```

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

Ver também

Invocando comandos de gerenciamento

Choosing Docker image registry¶

Weblate containers are published to following registries:

Docker Hub, see https://hub.docker.com/r/weblate/weblate
GitHub Packages registry, see https://github.com/WeblateOrg/docker/pkgs/container/weblate

Nota

All examples currently fetch images from Docker Hub, please adjust the configuration accordingly to use a different registry.

Choosing Docker image tag¶

Please choose a tag that matches your environment and expectations:

Nome da tag	Descrição	Caso de uso
`latest`	Versão estável do Weblate, corresponde à última versão marcada	Atualizações contínuas em um ambiente de produção
`<MAJOR>`	Versão estável do Weblate	Rolling updates within a major version in a production environment
`<MAJOR>.<MINOR>`	Versão estável do Weblate	Rolling updates within a minor version in a production environment
`<VERSION>.<PATCH>`	Versão estável do Weblate	Implantação bem definida em um ambiente de produção
`edge`	Lançamento estável do Weblate com alterações de desenvolvimento no contêiner Docker (por exemplo, dependências atualizadas)	Atualizações contínuas em um ambiente de teste
`edge-<DATE>-<SHA>`	Lançamento estável do Weblate com alterações de desenvolvimento no contêiner Docker (por exemplo, dependências atualizadas)	Implantação bem definida em um 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.

Full list of published tags can be found at GitHub Packages

Contêiner Docker com suporte a HTTPS¶

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

Usando seus próprios certificados SSL¶

No caso de você ter seu próprio certificado SSL que deseja usar, basta colocar os arquivos no volume de dados Weblate (veja Volumes de contêiner Docker):

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

Ambos os arquivos devem pertencer ao mesmo usuário que inicia o contêiner do docker e ter a máscara de arquivo definida como 600 (legível e gravável apenas pelo usuário dono).

Além disso, o contêiner Weblate agora aceitará conexões SSL na porta 4443. Você ainda vai 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 você 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 contêiner do docker, você pode usar a seguinte configuração:

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

    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 de seu ambiente.

Certificados SSL automáticos usando Let’s Encrypt¶

Caso você queira usar certificados SSL Let’s Encrypt gerados automaticamente na instalação pública, você precisa adicionar um proxy HTTPS reverso em um contêiner Docker adicional, https-portal será usado para isso. Isso é usado no arquivo docker-compose-https.yml. Em seguida, crie um arquivo docker-compose-https.override.yml com 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'

Whenever invoking docker compose you need to pass both files to it, and then do:

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 contêiner Docker¶

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

Alterado na versão 4.17-1: Since Weblate 4.17-1, the Docker container uses Django 4.2 what requires PostgreSQL 12 or newer, please upgrade it prior to upgrading Weblate. See Atualizando contêiner PostgreSQL.

Você pode fazer isso mantendo 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 você estiver na série 3.x e quiser atualizar para 4.x, primeiro atualize para a 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.

Você também pode querer atualizar o repositório docker-compose, embora não seja necessário na maioria dos casos. Veja Atualizando contêiner PostgreSQL para atualizar o servidor PostgreSQL.

Atualizando contêiner PostgreSQL¶

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

Ver também

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

Pare o contêiner do Weblate:
```
docker compose stop weblate cache
```

Faça backup do banco de dados:

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

Pare o contêiner de banco de dados:
```
docker compose stop database
```
Remova o volume do PostgreSQL:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Dica

The volume name contains name of the Docker Compose project, which is by default the directory name what is weblate-docker in this documentation.
Ajuste o docker-compose.yml para usar a nova versão do PostgreSQL.
Inicie o contêiner 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 weblate
```
Dica

Please check that the database name matches POSTGRES_DB.
(Optional) Update password for the Weblate user. This might be needed when migrating to PostgreSQL 14 or 15 as way of storing passwords has been changed:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
Dica

Please check that the database name matches POSTGRES_DB.
Inicie todos os contêineres restantes:
```
docker compose up -d
```

Autenticação como administrador¶

Após a configuração do contêiner, você pode entrar como usuário admin com a senha fornecida em WEBLATE_ADMIN_PASSWORD, ou uma senha aleatória gerada na primeira inicialização se não tiver sido definida.

Para redefinir a senha do admin, reinicie o contêiner com WEBLATE_ADMIN_PASSWORD definido com a nova senha.

Ver também

WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

Número de processos e consumo de memória¶

O número de processos de trabalho para uWSGI e Celery é determinado automaticamente com base no número 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 você tenha muitos núcleos de CPU e tenha problemas de memória insuficiente, tente reduzir o número de workers:

environment:
  WEBLATE_WORKERS: 2

Você 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

Ver também

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

Dimensionamento horizontal¶

Adicionado na versão 4.6.

Você pode executar vários contêineres Weblate para dimensionar o serviço horizontalmente. O volume /app/data deve ser compartilhado por todos os contêineres, é recomendado usar um sistema de arquivos de cluster como o GlusterFS para isso. O volume /app/cache deve ser separado para cada contêiner.

Cada contêiner Weblate tem um papel definido usando 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.

Você 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 contêiner Docker usando as variáveis de ambiente descritas abaixo.

Se você precisar definir uma configuração não exposta por meio de variáveis de ambiente do Docker, consulte Configuração além das variáveis de ambiente.

Passing secrets¶

Adicionado na versão 5.0.

Weblate container supports passing secrets as files. To utilize that, append _FILE suffix to the environment variable and pass secret file via Docker.

Related docker-compose.yml might look like:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

Ver também

How to use secrets in Docker Compose

Configurações genéricas¶

WEBLATE_DEBUG¶

Configura o modo de depuração do Django usando DEBUG.

Exemplo:

environment:
  WEBLATE_DEBUG: 1

Ver também

Desabilitar o modo de depuração

WEBLATE_LOGLEVEL¶

Configures the logging verbosity. Set this to DEBUG to get more detailed logs.

Defaults to INFO when WEBLATE_DEBUG is turned off, DEBUG is used when debug mode is turned on.

For more silent logging use ERROR or WARNING.

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.

Ver 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 usuário admin (veja WEBLATE_ADMIN_PASSWORD para mais informações).

Exemplo:

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

Ver também

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

WEBLATE_ADMIN_PASSWORD¶

Define a senha para o usuário admin.

Se não for definido e o usuário admin não existir, ele será criado com uma senha aleatória mostrada na primeira inicialização do contêiner.
Se não for definido e o usuário admin existir, nenhuma ação será executada.
Se definido, o usuário admin é ajustado em cada inicialização do contêiner para corresponder a WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME e WEBLATE_ADMIN_EMAIL.

Aviso

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

Ver também

Autenticação como administrador, Passing secrets, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

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

Ver também

SERVER_EMAIL, Configurar envio de e-mail

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

Ver também

DEFAULT_FROM_EMAIL, Configurar envio de e-mail

WEBLATE_ADMINS_CONTACT¶: Configures ADMINS_CONTACT.

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

WEBLATE_ALLOWED_HOSTS¶

Configura os nomes de host HTTP permitidos usando ALLOWED_HOSTS.

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

Exemplo:

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

Ver também

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

WEBLATE_REGISTRATION_OPEN¶

Configura se os registros são abertos alternando 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_REGISTRATION_REBIND¶: Adicionado na versão 4.16.

Configures REGISTRATION_REBIND.

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 contêiner 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 links de API ou defina marcadores 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 contêiner Weblate aceite conexões HTTPS, você precisa configurar isso também, consulte Contêiner Docker com suporte a HTTPS para exemplos.

Exemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Ver também

ENABLE_HTTPS Definir domínio correto do site, WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶: Adicionado 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.

Ver 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 contêiner Weblate.

Habilita 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_IP_PROXY_OFFSET¶: Adicionado na versão 5.0.1.

Configures IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT¶: Adicionado na versão 5.0.1.

A boolean that specifies whether to use the X-Forwarded-Port header in preference to the SERVER_PORT META variable. This should only be enabled if a proxy which sets this header is in use.

Ver também

USE_X_FORWARDED_PORT

Nota

This is a boolean setting (use "true" or "false").

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á sendo executado por trás de um proxy reverso fazendo 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

Ver também

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN¶

Habilita 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 usando LOGIN_REQUIRED_URLS_EXCEPTIONS.

Você pode substituir configurações inteiras ou modificar o valor padrão usando as variáveis ADD e REMOVE.

To enforce authentication for the contact form, do:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$

WEBLATE_GOOGLE_ANALYTICS_ID¶: Configura o ID para o Google Analytics alterando GOOGLE_ANALYTICS_ID.

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

Ver 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 Controle 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 de 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.

Ver também

Assinando commits do Git com GnuPG

WEBLATE_URL_PREFIX¶: Configura o prefixo da URL onde o Weblate está sendo executado, veja URL_PREFIX.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: Configura verificações que você 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.

Ver 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¶: Adicionado na versão 4.6.

Configura o limitador de taxa.

Dica

Você 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.

Ver também

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

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Adicionado na versão 4.11.

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

Ver também

Limitação de taxa da API

WEBLATE_ENABLE_HOOKS¶: Adicionado na versão 4.13.

Configura ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Adicionado na versão 4.6.1.

Configura ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Adicionado na versão 4.15.

Configura AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Adicionado na versão 4.9.

Configura LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Adicionado na versão 4.9.

Configura SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Adicionado na versão 4.9.

Configures BORG_EXTRA_ARGS as a comma separated list of args.

Exemplo:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Adicionado na versão 4.14.1.

Configura ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK¶: Adicionado na versão 5.5.

Configures SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Adicionado na versão 4.15.

Configura EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Adicionado na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Adicionado na versão 4.15.

Configura PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS¶: Adicionado na versão 4.17.

Configures UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Adicionado na versão 4.16.

Allow CORS requests from given origins.

Exemplo:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

CLIENT_MAX_BODY_SIZE¶

Adicionado na versão 4.16.3.

Configures maximal body size accepted by the built-in web server.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Dica

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Certificados SSL automáticos usando Let’s Encrypt.

Code hosting sites credentials¶

In the Docker container, the code hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for Pull requests do GitHub, but applies to all Integração com controle de versão with appropriately changed variable names.

An example configuration for GitHub might look like:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

Will be used as:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

Alternatively the Python dictionary can be provided as a string:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

WEBLATE_GITHUB_USERNAME¶

WEBLATE_GITHUB_TOKEN¶

WEBLATE_GITHUB_HOST¶

WEBLATE_GITHUB_CREDENTIALS¶: Configures Pull requests do GitHub by changing GITHUB_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Configures Merge requests do GitLab by changing GITLAB_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Configures Pull requests do Gitea by changing GITEA_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Configures Merge requests do Pagure by changing PAGURE_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Configures Bitbucket Server pull requests by changing BITBUCKETSERVER_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Configures Azure DevOps pull requests by changing AZURE_DEVOPS_CREDENTIALS.

Ver também

Configuring code hosting credentials in Docker

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 usuário, consulte Sugestões automáticas.

As variáveis de ambiente atuais são importadas durante a migração para o 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_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)

Ver também

Passing secrets, 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¶: Habilita Autenticação por GitHub.

GitHub Enterprise Edition¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶: Enables Autenticação por GitHub EE.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET¶: Habilita Autenticação por Bitbucket.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Habilita 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¶: Habilita Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Habilita OAuth 2 do GitLab.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Habilita autenticação por Gitea.

Active Directory do Azure¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Habilita 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¶: Habilita 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¶: Habilita autenticação com Keycloak, veja a documentação.

Fornecedores Linux¶

Você pode habilitar a autenticação usando serviços de autenticação de fornecedores Linux, definindo as seguintes variáveis para qualquer valor.

WEBLATE_SOCIAL_AUTH_FEDORA¶

WEBLATE_SOCIAL_AUTH_OPENSUSE¶

WEBLATE_SOCIAL_AUTH_OPENINFRA¶

WEBLATE_SOCIAL_AUTH_UBUNTU¶

Slack¶

WEBLATE_SOCIAL_AUTH_SLACK_KEY¶

SOCIAL_AUTH_SLACK_SECRET¶: Habilita a autenticação Slack, veja Slack.

OpenID Connect¶

Adicionado 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¶: Configures generic OpenID Connect integration.

Ver também

OIDC (OpenID Connect)

SAML¶

Chaves SAML autoassinadas são geradas automaticamente na primeira inicialização do contêiner. Caso você queira usar chaves próprias, coloque 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.

WEBLATE_SAML_ID_ATTR_NAME¶

WEBLATE_SAML_ID_ATTR_USERNAME¶

WEBLATE_SAML_ID_ATTR_EMAIL¶

WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶: Adicionado na versão 4.18.

SAML attributes mapping.

Outras configurações de autenticação¶

WEBLATE_NO_EMAIL_AUTH¶: Desabilita autenticação por e-mail quando definido com algum valor. Veja Desativando autenticação por senha.

WEBLATE_MIN_PASSWORD_SCORE¶: Minimal password score as evaluated by the zxcvbn password strength estimator. Defaults to 3, set to 0 to disable strength checking.

Configuração de banco de dados PostgreSQL¶

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

Ver também

Configuração de banco de dados para o Weblate

POSTGRES_PASSWORD¶: Senha do PostgreSQL.

Ver também

Passing secrets

POSTGRES_USER¶: Nome de usuário do PostgreSQL.

POSTGRES_DB¶: 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 Configurando Weblate para usar PostgreSQL.

POSTGRES_CONN_MAX_AGE¶

Adicionado na versão 4.8.1.

The lifetime of a database connection, as an integer of seconds. Use 0 to close database connections at the end of each request.

Alterado na versão 5.1: The default behavior is to have unlimited persistent database connections.

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

Exemplo de configuração:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Ver também

CONN_MAX_AGE, Persistent connections

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Adicionado na versão 4.9.1.

Desabilita 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

Ver também

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

WEBLATE_DATABASES¶: Adicionado na versão 5.1.

Set to false to disables environment based configuration of the database connection. Use Substituindo as configurações do volume de dados to configure the database connection manually.

MySQL or MariaDB server¶

Neither MySQL nor MariaDB can not be configured via environment variables. See MySQL e MariaDB for info on using those with Weblate. Use WEBLATE_DATABASES to configure the database connection manually.

Configurações de backup de banco de dados¶

Ver também

Dados despejados para os backups

WEBLATE_DATABASE_BACKUP¶: Configura o despejo diário do banco de dados usando DATABASE_BACKUP. O padrão é plain.

Configuração do servidor de cache¶

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

Ver também

Habilitar 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 senha do servidor Redis, não usada por padrão.

Ver também

Passing secrets

REDIS_TLS¶: Habilita 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, você 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

Ver também

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

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

Ver 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.

Ver também

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Usuário da autenticação por e-mail.

Ver também

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶: Senha da autenticação por e-mail.

Ver também

Passing secrets, 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 você estiver tendo problemas, consulte a configuração TLS explícita WEBLATE_EMAIL_USE_TLS.

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

Ver 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 você estiver tendo 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 é habilitado automaticamente com base em WEBLATE_EMAIL_PORT.

Ver 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.

Ver também

Configurar envio de e-mail, EMAIL_BACKEND

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

Ver 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.

Collecting error reports and monitoring performance¶

É recomendado coletar erros da instalação sistematicamente, veja Collecting error reports and monitoring performance.

Para habilitar o suporte para Rollbar, defina o seguinte:

ROLLBAR_KEY¶: Seu token de acesso ao servidor de postagem Rollbar.

ROLLBAR_ENVIRONMENT¶: Seu ambiente Rollbar, o padrão é production.

Para habilitar o suporte para Sentry, defina o seguinte:

SENTRY_DSN¶: Your Sentry DSN, see SENTRY_DSN.

SENTRY_ENVIRONMENT¶: Your Sentry Environment (optional), defaults to WEBLATE_SITE_DOMAIN.

SENTRY_TRACES_SAMPLE_RATE¶

Configure sampling rate for performance monitoring. Set to 1 to trace all events, 0 (the default) disables tracing.

Exemplo:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

Ver também

Sentry Performance Monitoring,

SENTRY_PROFILES_SAMPLE_RATE¶

Configure sampling rate for profiling monitoring. Set to 1 to trace all events, 0 (the default) disables tracing.

Exemplo:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

Ver também

Sentry Profiling

SENTRY_SEND_PII¶: Configures SENTRY_SEND_PII.

CDN de localização¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Adicionado na versão 4.2.1.

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

O WEBLATE_LOCALIZE_CDN_PATH é o caminho dentro do contêiner. 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

Você é responsável por configurar o serviço dos arquivos gerados pelo Weblate, ele só armazena os arquivos no local configurado.

Ver também

Traduzindo HTML e JavaScript usando CDN do Weblate, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

Alterando aplicativos, verificações, extensões ou correções automáticas habilitados¶

A configuração embutida de verificações, extensões ou correções automática habilitados 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

Ver também

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

Configurações do contêiner¶

WEBLATE_WORKERS¶

Adicionado na versão 4.6.1.

Número base de processos de trabalho em execução no contêiner. Quando não definido, é determinado automaticamente na inicialização do contêiner com base no número 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. Você 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 você 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, o número de workers simultâneos é baseado em WEBLATE_WORKERS.

Exemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Ver também

Opções de worker do Celery, Tarefas de fundo usando 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 contêiner. Use isto para Dimensionamento horizontal.

Os seguintes serviços são definidos:

celery-beat: Agendador de tarefas do Celery, apenas uma instância deve estar em execução. Este contêiner 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 contêiner Docker¶

Há dois volumes (dados e cacho) exportados pelo contêiner Weblate. Os outros contêineres de serviço (PostgreSQL ou Redis) também têm seus volumes de dados, 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, contêiner e nomes de volume). No contêiner, ele é montado como /app/data.

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs.

Ao criar os volumes manualmente, os diretórios devem pertencer ao UID 1000, pois é o usuário usado dentro do contêiner.

Ver também

Documentação sobre volumes do Docker

Read-only root filesystem¶

Adicionado na versão 4.18.

When running the container with a read-only root filesystem, two additional tmpfs volumes are required - /tmp and /run.

Configuração além das variáveis de ambiente¶

As variáveis de ambiente do Docker destinam-se a expor a maioria das definições de configuração de relevância para as instalações do Weblate.

Se você encontrar uma configuração que não está exposta como uma variável de ambiente, e você acredita que deveria estar, sinta-se à vontade para pedir que ela seja exposta em uma versão futura do Weblate.

Se você precisar modificar uma configuração que não está exposta como uma variável de ambiente do Docker, ainda poderá fazê-lo a partir do volume de dados ou estendendo a imagem do Docker.

Ver também

Personalizando o Weblate

Substituindo as configurações do volume de dados¶

Você pode criar um arquivo em /app/data/settings-override.py, ou seja, na raiz do volume de dados, para estender ou substituir as configurações definidas por meio de variáveis de ambiente .

Substituindo as configurações estendendo a imagem do Docker¶

Para substituir as configurações no nível da imagem do Docker em vez do volume de dados:

Crie um pacote Python personalizado.
Adicione um módulo ao seu pacote que importe todas as configurações de weblate.settings_docker.

Por exemplo, dentro da estrutura de pacote de exemplo definida em Criando um módulo Python, você pode criar um arquivo em weblate_customization/weblate_customization/settings.py com o seguinte código inicial:
```
from weblate.settings_docker import *
```

Crie um Dockerfile personalizado que herde da imagem oficial do Weblate Docker e, em seguida, instale seu pacote e aponte a variável de ambiente DJANGO_SETTINGS_MODULE para seu módulo de configurações:

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

Em vez de usar a imagem Docker oficial do Weblate, construa uma imagem personalizada a partir deste arquivo Dockerfile.

Não existe nenhuma maneira limpa <https://github.com/docker/compose/issues/7231>`__ de fazer isso com ``docker-compose.override.yml. Você poderia adicionar build: . ao nó weblate nesse arquivo, mas sua imagem personalizada será marcada como weblate/weblate em seu sistema, o que pode ser problemático.

Então, ao invés de usar o docker-compose.yml direto do repositório oficial, não modificado, e estendê-lo através do docker-compose .override.yml, você pode querer fazer uma cópia do arquivo docker-compose.yml oficial, e editar sua cópia para substituir image: weblate/weblate por build: ..

Consulte a Referência de compilação do arquivo Compose para obter detalhes sobre como criar imagens a partir da fonte ao usar docker-compose.
Estenda seu módulo de configurações personalizadas para definir ou redefinir as configurações.

You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overridden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overridden.

Você também pode ir mais longe. Por exemplo, você pode reproduzir algumas das coisas que weblate.docker_settings faz, como expor configurações como variáveis de ambiente ou permitir a substituição de configurações de arquivos Python no volume de dados.

Substituindo o logotipo e outros arquivos estáticos¶

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

Dica

Os arquivos são copiados para o local correspondente na inicialização do contêiner, 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 colocados em /app/data/python/customize/templates/legal/documents.

Como alternativa, você também pode incluir o próprio módulo (veja ../ customize) e adicioná-lo como um volume separado ao contêiner 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

Configurando o servidor PostgreSQL¶

O contêiner PostgreSQL usa a configuração padrão do PostgreSQL e não utilizará efetivamente seus núcleos de CPU ou memória. 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/.

Partes internas do contêiner¶

O contêiner está usando supervisor para iniciar serviços individuais. No caso de Dimensionamento horizontal, ele inicia apenas um único serviço em um contêiner.

Para verificar o status dos serviços, use:

docker compose exec --user weblate weblate supervisorctl status

Existem serviços individuais para cada fila Celery (veja Tarefas de fundo usando Celery para detalhes). Você pode interromper o processamento de algumas tarefas parando o worker apropriado:

docker compose exec --user weblate weblate supervisorctl stop celery-translate