Instalando usando Docker

Com a implantação do Weblate dockerizada, você pode colocar 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 em um ú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 arquivos, banco de dados e Weblate).

Muitos usuários 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 seu tamanho mínimo fazendo clones rasos.

Nota

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

Instalação

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

  1. Clone o repositório weblate-docker:

    git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
    cd weblate-docker
    
  2. 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.

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

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

Alterado na versão 3.7.1-6: Em julho de 2019 (começando com a tag 3.7.1-6), os contêineres não estão sendo executados como um usuário root. Isso mudou a porta exposta de 80 para 8080.

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

Novo na versão 3.8-3.

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;
    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 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'

Sempre que invocar docker-compose, você precisa passar os dois arquivos para 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 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.

Você pode fazer isso mantendo o docker-compose existente e apenas obter as imagens mais recentes e reiniciar:

docker-compose stop
docker-compose pull
docker-compose up

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 na 3.0 não são suportadas pelo Weblate. Se você estiver na série 2.x e quiser atualizar para 3.x, primeiro atualize para a imagem 3.0.1-x mais recente (no momento em que escrevo esta é a imagem 3.0.1-7), 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. Cuidado com as mudanças de versão do PostgreSQL neste caso, pois não é simples atualizar o banco de dados, consulte este issue do GitHub para mais informações.

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.

Number of processes and memory consumption

The number of worker processes for both uWSGI and Celery is determined automatically based on number of CPUs. This works well for most cloud virtual machines as these typically have few CPUs and good amount of memory.

Caso você tenha muitos núcleos de CPU e tenha problemas de memória insuficiente, tente reduzir o número de workers:

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

Scaling horizontally

Novo na versão 4.6.

Aviso

This feature is a technology preview.

You can run multiple Weblate containers to scale the service horizontally. The /app/data volume has to be shared by all containers, it is recommended to use cluster filesystem such as GlusterFS for this. The /app/cache volume should be separate for each container.

Each Weblate container has defined role using WEBLATE_SERVICE environment variable. Please follow carefully the documentation as some of the services should be running just once in the cluster and the ordering of the services matters as well.

You can find example setup in the docker-compose repo as docker-compose-split.yml.

Variáveis de ambiente do Docker

Muitas das Configurações do Weblate podem ser definidas no contêiner Docker usando variáveis de ambiente:

Configurações genéricas

WEBLATE_DEBUG

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

Exemplo:

environment:
  WEBLATE_DEBUG: 1
WEBLATE_LOGLEVEL

Configura o detalhamento do log.

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.

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

WEBLATE_SERVER_EMAIL
WEBLATE_DEFAULT_FROM_EMAIL

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

WEBLATE_CONTACT_FORM

Configures contact form behavior, see 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
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_TIME_ZONE

Configura o fuso horário usado no Weblate, veja 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 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 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
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_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
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.

WEBLATE_GOOGLE_ANALYTICS_ID

Configura o ID para o Google Analytics alterando GOOGLE_ANALYTICS_ID.

WEBLATE_GITHUB_USERNAME

Configura o nome de usuário do GitHub para pull requests do GitHub alterando GITHUB_USERNAME.

Ver também

GitHub

WEBLATE_GITHUB_TOKEN

Novo na versão 4.3.

Configura o token de acesso pessoal do GitHub para pull requests do GitHub via API alterando GITHUB_TOKEN.

Ver também

GitHub

WEBLATE_GITLAB_USERNAME

Configura o nome de usuário do GitLab para merge requests do GitLab alterando GITLAB_USERNAME

Ver também

GitLab

WEBLATE_GITLAB_TOKEN

Configura o token de acesso pessoal do GitLab para merge requests do GitLab via API alterando GITLAB_TOKEN

Ver também

GitLab

WEBLATE_PAGURE_USERNAME

Configura o nome de usuário do Pagure para merge requests do Pagure alterando PAGURE_USERNAME

Ver também

Pagure

WEBLATE_PAGURE_TOKEN

Configura o token de acesso pessoal do Pagure para merge requests do Pagure via API alterando PAGURE_TOKEN

Ver também

Pagure

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.

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

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

You can set configuration for any rate limiter scopes. To do that add WEBLATE_ prefix to any of setting described in Limitação de taxa.

Configurações de tradução automática

WEBLATE_MT_APERTIUM_APY

Habilita tradução automática do Apertium e define MT_APERTIUM_APY

WEBLATE_MT_AWS_REGION
WEBLATE_MT_AWS_ACCESS_KEY_ID
WEBLATE_MT_AWS_SECRET_ACCESS_KEY

Configura tradução automática da AWS.

environment:
  WEBLATE_MT_AWS_REGION: us-east-1
  WEBLATE_MT_AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE
  WEBLATE_MT_AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
WEBLATE_MT_DEEPL_KEY

Habilita tradução de máquina do DeepL e define MT_DEEPL_KEY

WEBLATE_MT_DEEPL_API_VERSION

Configura a versão da API do DeepL para usar, veja MT_DEEPL_API_VERSION.

WEBLATE_MT_GOOGLE_KEY

Habilita Google Translate e define MT_GOOGLE_KEY

WEBLATE_MT_MICROSOFT_COGNITIVE_KEY

Habilita Microsoft Cognitive Services Translator e define MT_MICROSOFT_COGNITIVE_KEY

WEBLATE_MT_MICROSOFT_ENDPOINT_URL

Define MT_MICROSOFT_ENDPOINT_URL. Note que isto deve conter apenas o nome de domínio.

WEBLATE_MT_MICROSOFT_REGION

Define MT_MICROSOFT_REGION

WEBLATE_MT_MICROSOFT_BASE_URL

Define MT_MICROSOFT_BASE_URL

WEBLATE_MT_MODERNMT_KEY

Habilita ModernMT e define MT_MODERNMT_KEY.

WEBLATE_MT_MYMEMORY_ENABLED

Habilita tradução de máquina do MyMemory e define MT_MYMEMORY_EMAIL para WEBLATE_ADMIN_EMAIL.

Exemplo:

environment:
  WEBLATE_MT_MYMEMORY_ENABLED: 1
WEBLATE_MT_GLOSBE_ENABLED

Habilita tradução de máquina do Glosbe.

environment:
  WEBLATE_MT_GLOSBE_ENABLED: 1
WEBLATE_MT_MICROSOFT_TERMINOLOGY_ENABLED

Habilita tradução de máquina do Microsoft Terminology Service.

environment:
  WEBLATE_MT_MICROSOFT_TERMINOLOGY_ENABLED: 1
WEBLATE_MT_SAP_BASE_URL
WEBLATE_MT_SAP_SANDBOX_APIKEY
WEBLATE_MT_SAP_USERNAME
WEBLATE_MT_SAP_PASSWORD
WEBLATE_MT_SAP_USE_MT

Configura tradução de máquina do SAP Translation Hub.

environment:
    WEBLATE_MT_SAP_BASE_URL: "https://example.hana.ondemand.com/translationhub/api/v1/"
    WEBLATE_MT_SAP_USERNAME: "user"
    WEBLATE_MT_SAP_PASSWORD: "password"
    WEBLATE_MT_SAP_USE_MT: 1

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_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)

GitHub

WEBLATE_SOCIAL_AUTH_GITHUB_KEY
WEBLATE_SOCIAL_AUTH_GITHUB_SECRET

Habilita Autenticação por GitHub.

Bitbucket

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 OAuth 2 do Google.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Habilita OAuth 2 do GitLab.

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

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_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY
SOCIAL_AUTH_SLACK_SECRET

Habilita a autenticação Slack, veja Slack.

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

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

Outras configurações de autenticação

WEBLATE_NO_EMAIL_AUTH

Desabilita autenticação por e-mail quando definido com algum valor.

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.

POSTGRES_PASSWORD

Senha do PostgreSQL.

POSTGRES_USER

Nome de usuário 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 Configurando Weblate para usar PostgreSQL.

Configurações de backup de banco de dados

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.

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
WEBLATE_EMAIL_HOST

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

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

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.

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.

WEBLATE_EMAIL_BACKEND

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

Integração do site

WEBLATE_GET_HELP_URL

Configura GET_HELP_URL.

WEBLATE_STATUS_URL

Configura STATUS_URL.

Configura LEGAL_URL.

Relatório de erro

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

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

Seu DSN no Sentry.

SENTRY_ENVIRONMENT

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

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

Novo na versão 3.8-5.

A configuração embutida de verificações, complementos 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

Configurações do contêiner

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 corresponde ao número de processadores (exceto o worker de backup, que deve ser executado apenas uma vez).

Exemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16
UWSGI_WORKERS

Configura quantos workers uWSGI devem ser executados.

O padrão é o número de processadores + 1.

Exemplo:

environment:
  UWSGI_WORKERS: 32
WEBLATE_SERVICE

Defines which services should be executed inside the container. Use this for Scaling horizontally.

Following services are defined:

celery-beat

Celery task scheduler, only one instance should be running. This container is also responsible for the database structure migrations and it should be started prior others.

celery-backup

Celery worker for backups, only one instance should be running.

celery-celery

Generic Celery worker.

celery-memory

Translation memory Celery worker.

celery-notify

Notifications Celery worker.

celery-translate

Automatic translation Celery worker.

web

Web server.

Volumes de contêiner Docker

There are two volumes (data and cache) exported by the Weblate container. The other service containers (PostgreSQL or Redis) have their data volumes as well, but those are not covered by this document.

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/. No contêiner, ele é montado como /app/data.

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

Personalização adicional da configuração

Você pode personalizar ainda mais a instalação do Weblate no volume de dados, veja Volumes de contêiner Docker.

Arquivos de configuração personalizados

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

Substituindo o logotipo e outros arquivos estáticos

Novo na versão 3.8-5.

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.

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

Adicionando seus próprios módulos Python

Novo na versão 3.8-5.

Você pode colocar os próprios módulos Python em /app/data/python/ (veja Volumes de contêiner Docker) e eles podem ser carregados pelo Weblate, provavelmente usando docker-custom -config.

Selecione sua máquina – provedores locais ou em nuvem

Com Docker Machine, você pode criar sua implantação Weblate em sua máquina local ou em qualquer grande número de implantações baseadas em nuvem, por exemplo, Amazon AWS, Greenhost e muitos outros provedores.