Instruções de configuração

Instalar o Weblate

Dependendo da sua configuração e experiência, escolha um método de instalação apropriado para si:

Requisitos de software

Sistema operacional

Weblate é conhecido por funcionar no Linux, FreeBSD e macOS. Outros sistemas como o Unix provavelmente funcionarão também.

O Weblate não é suportado no Windows. Mas ainda pode funcionar e patches são aceitos alegremente.

Outros serviços

Weblate está a usar outros serviços para a operação dele. Precisará pelo menos os seguintes serviços em execução:

Dependências Python

Weblate é escrito em Python e tem suporte de Python 3.6 ou mais novo. Pode instalar dependências a usar pip ou dos pacotes de distribuição deles, a lista completa está disponível em requirements.txt.

As dependências mais notáveis:

Django

https://www.djangoproject.com/

Celery

https://docs.celeryproject.org/

Translate Toolkit

https://toolkit.translatehouse.org/

translation-finder

https://github.com/WeblateOrg/translation-finder

Python Social Auth

https://python-social-auth.readthedocs.io/

Django REST Framework

https://www.django-rest-framework.org/

Dependências opcionais

Os módulos seguintes são necessários para alguns recursos do Weblate. Pode encontrar todos em requirements-optional.txt.

Mercurial (opcional para suporte de repositórios Mercurial)

https://www.mercurial-scm.org/

phply (opcional para suporte de PHP)

https://github.com/viraptor/phply

tesserocr (opcional para OCR de capturas de ecrã)

https://github.com/sirfz/tesserocr

akismet (opcional para a sugestão de proteção de spam)

https://github.com/ubernostrum/akismet

ruamel.yaml (opcional para YAML files)

https://pypi.org/project/ruamel.yaml/

Zeep (opcional para Microsoft Terminology Service)

https://docs.python-zeep.org/

aeidon (opcional para Subtitle files)

https://pypi.org/project/aeidon/

Dependências de backend de banco de dados

O Weblate tem suporte de PostgreSQL, MySQL e MariaDB, consulte Configuração de banco de dados para o Weblate e a documentação dos backends para mais detalhes.

Outros requisitos do sistema

As dependências seguintes devem ser instaladas no sistema:

Git

https://git-scm.com/

Pango, Cairo e ficheiros de cabeçalho relacionados e dados de introspecção gir

https://cairographics.org/, https://pango.gnome.org/, veja Pango e Cairo

git-review (opcional para suporte de Gerrit)

https://pypi.org/project/git-review/

git-svn (opcional para suporte de Subversion)

https://git-scm.com/docs/git-svn

tesseract e os dados dele (opcional para OCR de capturas de ecrã)

https://github.com/tesseract-ocr/tesseract

licensee (opcional para detetar a licença ao criar o componente)

https://github.com/licensee/licensee

Build-time dependencies

To build some of the Dependências Python you might need to install their dependencies. This depends on how you install them, so please consult individual packages for documentation. You won’t need those if using prebuilt Wheels while installing using pip or when you use distribution packages.

Pango e Cairo

Alterado na versão 3.7.

O Weblate usa Pango e Cairo para renderizar widgets de bitmap (ver Promoting the translation) e verificações de renderização (ver Gerir letras). Para instalar as ligações Python corretamente para esses, precisa de instalar bibliotecas de sistemas primeiro - precisa tanto do Cairo quanto do Pango, que por sua vez precisam de GLib. Todos esses devem ser instalados com ficheiros de desenvolvimento e dados de introspecção GObject.

Verificar assinaturas de lançamento

Os lançamentos do Weblate são criptograficamente assinados pelo programador que os lançou. Atualmente é Michal Čihař. A impressão digital da chave PGP é:

63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D

e pode obter mais informações de identificação de <https://keybase.io/nijel>.

Deve verificar se a assinatura corresponde ao ficheiro que descarregou. Desta forma, pode ter certeza de que está a usar o mesmo código que foi lançado. Também deve verificar a data da assinatura para ter certeza de que descarregou a versão mais recente.

Cada arquivo é acompanhado de ficheiros .asc, os quais contêm a assinatura PGP para ele. Uma vez que tenha ambos na mesma pasta, pode verificar a assinatura:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found

Como pode ver, o GPG reclama que não conhece a chave pública. Neste ponto deve fazer um dos seguintes passos:

  • Use wkd para descarregar a chave:

$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub   rsa4096 2009-06-17 [SC]
      63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid           [ultimate] Michal Čihař <michal@cihar.com>
uid           [ultimate] Michal Čihař <nijel@debian.org>
uid           [ultimate] [jpeg image of size 8848]
uid           [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub   rsa4096 2009-06-17 [E]
sub   rsa4096 2015-09-09 [S]
$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
  • Descarregue e importe a chave de um dos servidores principais:

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg:              unchanged: 1

Isso vai melhorar a situação um pouco - neste momento pode verificar que a assinatura da chave dada está correta, mas ainda não pode confiar no nome usado na chave:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE  5A32 9C27 B313 42B7 511D

O problema aqui é que qualquer um poderia emitir a chave com este nome. Precisa garantir que a chave é realmente a propriedade da pessoa mencionada. O Manual de Privacidade do GNU aborda este tópico no capítulo Validating other keys on your public keyring. O método mais confiável é de conhecer o programador pessoalmente e trocar impressões digitais importantes, no entanto também pode confiar na rede de confiança. Dessa forma, pode confiar na chave transitivamente através de assinaturas de outros, que conheceram o programador pessoalmente.

Uma vez que a chave seja confiável, o aviso não ocorrerá:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]

Se a assinatura for inválida (o ficheiro foi alterado), obteria um erro claro, independentemente do fato de que a chave é confiável ou não:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]

Permissões do sistema de ficheiros

The Weblate process needs to be able to read and write to the directory where it keeps data - DATA_DIR. All files within this directory should be owned and writable by the user running all Weblate processes (typically WSGI and Celery, see Executar o servidor and Tarefas de fundo a usar o Celery).

A configuração predefinida põe-os na mesma árvore que as fontes do Weblate, no entanto, pode preferir movê-los para um local melhor, como /var/lib/weblate.

O Weblate tenta criar esses diretórios automaticamente, mas ele falhará quando não tiver permissões para fazê-lo.

Também deve tomar cuidado ao executar Management commands, pois eles devem ser executados sob o mesmo utilizador que o Weblate em si está a ser executado, caso contrário, permissões em alguns ficheiros podem estar erradas.

In the Docker container, all files in the /app/data volume have to be owned by weblate user inside the container (UID 1000).

Configuração de banco de dados para o Weblate

Recomenda-se a executar o Weblate com um servidor de banco de dados PostgreSQL.

PostgreSQL

PostgreSQL é geralmente a melhor escolha para sites baseados em Django. É o banco de dados de referência usado para implementar a camada de banco de dados Django.

Nota

O Weblate usa a extensão trigram que deve ser instalada separadamente em alguns casos. Procure por postgresql-contrib ou um pacote com nome similar.

Veja também

PostgreSQL notes

Criar um banco de dados no PostgreSQL

Geralmente é uma boa ideia executar o Weblate num banco de dados separado e separar a conta do utilizador:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -O weblate weblate

Dica

Se não quiser fazer do utilizador do Weblate um superutilizador no PostgreSQL, pode omiti-lo. Nesse caso, terá que executar algumas das etapas de migração manualmente como um superutilizador do PostgreSQL no esquema Weblate usará:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

Configurar Weblate para usar PostgreSQL

O trecho settings.py para PostgreSQL:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    }
}

The database migration performs ALTER ROLE on database role used by Weblate. In most cases the name of the role matches username. In more complex setups the role name is different than username and you will get error about non-existing role during the database migration (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). This is known to happen with Azure Database for PostgreSQL, but it’s not limited to this environment. Please set ALTER_ROLE to change name of the role Weblate should alter during the database migration.

MySQL e MariaDB

Dica

Alguns recursos do Weblate terão melhor desempenho com PostgreSQL. Isso inclui a memória de pesquisa e tradução, que ambos utilizam recursos de texto completo no banco de dados e a implementação do PostgreSQL é superior.

Weblate can be also used with MySQL or MariaDB, please see MySQL notes and MariaDB notes for caveats using Django with those. Because of the limitations it is recommended to use PostgreSQL for new installations.

Weblate requires MySQL at least 5.7.8 or MariaDB at least 10.2.7.

A configuração seguinte é recomendada para Weblate:

  • Use o conjunto de caracteres utf8mb4 para permitir a representação de planos Unicode mais altos (por exemplo, emojis).

  • Configure the server with innodb_large_prefix to allow longer indices on text fields.

  • Defina o nível de isolamento para READ COMMITTED.

  • O modo SQL deve ser definido como STRICT_TRANS_TABLES.

Below is an example /etc/my.cnf.d/server.cnf for a server with 8 GB of RAM. These settings should be sufficient for most installs. MySQL and MariaDB have tunables that will increase the performance of your server that are considered not necessary unless you are planning on having large numbers of concurrent users accessing the system. See the various vendors documentation on those details.

It is absolutely critical to reduce issues when installing that the setting innodb_file_per_table is set properly and MySQL/MariaDB restarted before you start your Weblate install.

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

Dica

In case you are getting #1071 - Specified key was too long; max key length is 767 bytes error, please update your configuration to include the innodb settings above and restart your install.

Configuring Weblate to use MySQL/MariaDB

The settings.py snippet for MySQL and MariaDB:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

You should also create the weblate user account in MySQL or MariaDB before you begin the install. Use the commands below to achieve that:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Outras configurações

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

O Weblate envia e-mails em várias ocasiões - para a ativação de contas e sobre várias notificações configuradas pelos utilizadores. Para isso, precisa de acesso a um servidor de SMTP.

The mail server setup is configured using these settings: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_TLS, EMAIL_HOST_USER and EMAIL_PORT. Their names are quite self-explanatory, but you can find more info in the Django documentation.

Dica

In case you get error about not supported authentication (for example SMTP AUTH extension not supported by server), it is most likely caused by using insecure connection and server refuses to authenticate this way. Try enabling EMAIL_USE_TLS in such case.

Executar por trás de um proxy reverso

Vários recursos no Weblate dependem de ser capaz de obter o endereço IP do cliente. Isso inclui Limitação de taxa, Spam protection ou Registo de auditoria.

Na configuração predefinida, o Weblate analisa o endereço IP de REMOTE_ADDR que é definido pelo manipulador WSGI.

Se estiver a usar um proxy reverso, este campo provavelmente conterá o seu endereço. Precisa configurar o Weblate para confiar em cabeçalhos HTTP adicionais e analisar o endereço IP destes. Isso não pode ser ativado por predefinição, porque permitiria a falsificação de endereços IP para instalações que não usam um proxy reverso. Ativar IP_BEHIND_REVERSE_PROXY pode ser suficiente para as configurações mais usuais, mas podia precisar de ajustar IP_PROXY_HEADER e IP_PROXY_OFFSET também.

Proxy HTTP

O Weblate executa comandos VCS e esses que aceitam a configuração proxy do ambiente. A abordagem recomendada é definir configurações de proxy em settings.py:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"

Ajustar a configuração

Veja também

Sample configuration

Copie weblate/settings_example.py para weblate/settings.py e ajuste-o para corresponder à configuração. Provavelmente irá ajustar as opções a seguir:

ADMINS

Lista de administradores de sites para receber notificações quando algo dá errado, por exemplo, notificações em mesclagens fracassadas ou erros de Django.

Veja também

ADMINS

ALLOWED_HOSTS

Precisa definir isso para listar os hosts que o seu site deve servir. Por exemplo:

ALLOWED_HOSTS = ["demo.weblate.org"]

Alternativamente, pode incluir curinga:

ALLOWED_HOSTS = ["*"]

SESSION_ENGINE

Configure como as suas sessões serão armazenadas. Caso mantenha o mecanismo de backend do banco de dados predefinido, deve agendar: weblate clearsessions para remover dados de sessão obsoletos do banco de dados.

Se estiver a usar o Redis como cache (veja Ativar o cache) é recomendado também usá-lo para sessões:

SESSION_ENGINE = "django.contrib.sessions.backends.cache"

DATABASES

Conetividade ao servidor de banco de dados, verifique a documentação do Django para obter mais detalhes.

DEBUG

Desative isto para qualquer servidor de produção. Com o modo de depuração ativado, o Django mostrará backtraces em caso de erro aos utilizadores, quando desativá-lo, erros serão enviados por e-mail para ADMINS (veja acima).

O modo de depuração também desacelera o Weblate, já que o Django armazena muito mais informações internamente neste caso.

Veja também

DEBUG

DEFAULT_FROM_EMAIL

Endereço de remetente de e-mail para e-mail de saída, por exemplo, e-mails de registo.

Veja também

DEFAULT_FROM_EMAIL

SECRET_KEY

Chave usada por Django para assinar informações em cookies, consulte Chave secreta do Django para obter mais informações.

Veja também

SECRET_KEY

SERVER_EMAIL

E-mail usado como endereço de remetente para envio de e-mails ao administrador, por exemplo, notificações em mesclagens falhadas.

Veja também

SERVER_EMAIL

Preencher o banco de dados

Depois que a sua configuração estiver pronta, pode executar weblate migrate para criar a estrutura do banco de dados. Agora deve ser capaz de criar projetos de tradução a usar a interface administrativa.

Caso quere executar uma instalação não interativamente, pode usar weblate migrate --noinput e depois criar um utilizador administrativo pelo comando createadmin.

Uma vez feito, também deve verificar o Relatório de desempenho na interface administrativa, o que lhe dará dicas de configuração potencial não ideal no seu site.

Configuração de produção

Para uma configuração de produção, deve realizar ajustes descritos nas seções a seguir. As configurações mais críticas acionarão um aviso, que é indicado por um ponto de exclamação na barra superior se esitver conectado como um superutilizador:

../_images/admin-wrench.png

Também é recomendado inspecionar verificações desencadeadas por Django (embora possa não precisar corrigir todas):

weblate check --deploy

You can also review the very same checklist from the Interface de gestão.

Veja também

Deployment checklist

Desativar o modo de depuração

Desative o modo de depuração do Django (DEBUG) com:

DEBUG = False

Com o modo de depuração ativado, o Django armazena todas as consultas executadas e mostra aos utilizadores backtraces de erros, o que não é desejado numa configuração de produção.

Configurar administradores corretamente

Defina os endereços de administração corretos à configuração ADMINS para definir quem receberá e-mails caso algo dê errado no servidor, por exemplo:

ADMINS = (("Your Name", "your_email@example.com"),)

Definir domínio correto do site

Ajuste o nome e o domínio do site na interface administrativa, caso contrário, ligações no RSS ou e-mails de registo não funcionarão. Isto é configurado usando SITE_DOMAIN que deve conter o nome de domínio do site.

Alterado na versão 4.2: Antes da versão 4.2, a estrutura de sites do Django era usada em vez disso, consulte The “sites” framework.

Configurar HTTPS corretamente

É fortemente recomendado executar Weblate a com o protocolo criptografado HTTPS. Depois de ativá-lo, deve definir ENABLE_HTTPS nas configurações:

ENABLE_HTTPS = True

Dica

Pode também configurar o HSTS, consulte SSL/HTTPS para obter mais detalhes.

Definir SECURE_HSTS_SECONDS corretamente

Se o seu site for servido sobre SSL, deve considerar definir um valor para SECURE_HSTS_SECONDS no settings.py para ativar HTTP Strict Transport Security. Por predefinição, está definido para 0 como mostrado abaixo.

SECURE_HSTS_SECONDS = 0

Se for definido como um valor inteiro não-zero, o cabeçalho django.middleware.security.SecurityMiddleware define o cabeçalho HTTP Strict Transport Security em todas as respostas que ainda não o possuem.

Aviso

Definir isto incorretamente pode quebrar irreversivelmente (por algum tempo) o seu site. Leia primeiro a documentação HTTP Strict Transport Security.

Usar um poderoso mecanismo de banco de dados

Por favor, use PostgreSQL para um ambiente de produção, consulte Configuração de banco de dados para o Weblate para obter mais informações.

Ativar o cache

Se for possível, use Redis do Django e ajuste a variável de configuração CACHES, por exemplo:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

Dica

In case you change Redis settings for the cache, you might need to adjust them for Celery as well, see Tarefas de fundo a usar o Celery.

Cache de avatares

Além do cache de Django, Weblate realiza cache de avatares. Recomenda-se usar um cache separado, baseado em ficheiros para este fim:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

Configurar envio de e-mail

O Weblate precisa enviar e-mails em várias ocasiões e esses e-mails devem ter um endereço de remetente correto, por favor, configure :configuração:`SERVER_EMAIL` e DEFAULT_FROM_EMAIL para combinar com o seu ambiente, por exemplo:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Nota

Para desativar o envio de e-mails pelo Weblate, defina EMAIL_BACKEND a django.core.mail.backends.dummy.EmailBackend.

Isso desativará toda a entrega de e-mail, incluindo e-mails de registo ou redefinição de palavra-passe.

Configuração de hosts permitidos

Django requer ALLOWED_HOSTS para manter uma lista de nomes de domínio que o seu site pode servir, deixá-lo vazio bloqueará todas solicitações.

Caso isso não esteja configurado para corresponder ao seu servidor HTTP, terá erros como Invalid HTTP_HOST header: '1.1.1.1'. Pode ter que adicionar '1.1.1.1' ao ALLOWED_HOSTS.

Dica

No contentor Docker, isso está disponível como WEBLATE_ALLOWED_HOSTS.

Chave secreta do Django

A configuração SECRET_KEY é usada pelo Django para assinar cookies e você deve realmente gerar o seu próprio valor em vez de usar o da configuração do exemplo.

Pode gerar uma nova chave por weblate/examples/generate-secret-key, que vem com o Weblate.

Veja também

SECRET_KEY

Directório inicial

Alterado na versão 2.1: Isso não é mais necessário, agora o Weblate armazena todos os seus dados em DATA_DIR.

O diretório home do utilizador que executa o Weblate deve existir e ser gravável por este utilizador. Isso é especialmente necessário se quiser usar o SSH para acessar repositórios privados, mas o Git pode precisar acessar este diretório também (dependendo da versão git que usa).

Pode alterar o diretório usado pelo Weblate em settings.py, por exemplo, para defini-lo como diretório configuration na árvore do Weblate:

os.environ["HOME"] = os.path.join(BASE_DIR, "configuration")

Nota

No Linux e em outros sistemas como UNIX, o caminho ao diretório home do utilizador é definido em /etc/passwd. Muitas distribuições usam um diretório sem permissão de escrita como predefinição para utilizadores para servir conteúdo web (como apache, www-data ou wwwrun), então tem que executar o Weblate sob um utilizador diferente ou alterar essa configuração.

Veja também

Accessing repositories

Carregar modelos

Recomenda-se usar um carregador de modelo em cache para Django. Armazena modelos analisados e evita a necessidade de analizar cada solicitação. Pode configurá-lo a usar o trecho a seguir (a configuração loaders é importante aqui):

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [
            os.path.join(BASE_DIR, "templates"),
        ],
        "OPTIONS": {
            "context_processors": [
                "django.contrib.auth.context_processors.auth",
                "django.template.context_processors.debug",
                "django.template.context_processors.i18n",
                "django.template.context_processors.request",
                "django.template.context_processors.csrf",
                "django.contrib.messages.context_processors.messages",
                "weblate.trans.context_processors.weblate_context",
            ],
            "loaders": [
                (
                    "django.template.loaders.cached.Loader",
                    [
                        "django.template.loaders.filesystem.Loader",
                        "django.template.loaders.app_directories.Loader",
                    ],
                ),
            ],
        },
    },
]

Executar tarefas de manutenção

Para um desempenho ideal, é uma boa ideia executar algumas tarefas de manutenção em segundo plano. Isso agora é feito automaticamente por Tarefas de fundo a usar o Celery e abrange as seguintes tarefas:

  • Verificação de saúde da configuração (de hora em hora).

  • Realização de commits de alterações pendentes (de hora em hora), consulte Commits adiados e commit_pending.

  • Atualização de alertas de componentes (dialy).

  • Atualização dos ramos remotos (nightly), consulte AUTO_UPDATE.

  • Backup de memória de tradução para JSON (diariamente), consulte dump_memory.

  • Tarefas de manutenção de texto completo e banco de dados (tarefas diárias e semanais), consulte cleanuptrans.

Alterado na versão 3.2: Desde a versão 3.2, a maneira predefinida de executar essas tarefas é usar o Celery e o Weblate já vem com a configuração adequada, consulte Tarefas de fundo a usar o Celery.

Codificação e localidades do sistema

As localidades do sistema devem ser configuradas para UTF-8. Na maioria das distribuições Linux, esta é a configuração predefinida. Se não é o caso no seu sistema, altere as localidades para a variante UTF-8.

Por exemplo, a editar /etc/default/locale e a definir lá LANG="C.UTF-8".

Em alguns casos, os serviços individuais têm uma configuração separada para locais. Por exemplo, ao usar o Apache, pode defini-lo em /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Usar uma autoridade certificadora personalizada

O Weblate verifica os certificados SSL durante as solicitações HTTP. Caso esteja a usar uma autoridade de certificação personalizada que não seja confiável em maços predefinidos, terá que adicionar o seu certificado como confiável.

A abordagem preferida é fazer isso no nível do sistema. Consulte a documentação da sua distro para mais detalhes (por exemplo, no Debian isso pode ser feito a por o certificado da AC em /usr/local/share/ca-certificates/ e executando update-ca-certificates).

Uma vez feito isso, as ferramentas do sistema confiarão no certificado e isso inclui o Git.

Para código em Python, precisará configurar solicitações para usar o pacote de AC do sistema em vez do fornecido . Isso pode ser conseguido pondo os seguintes trechos em settings.py (o caminho é específico do Debian):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

Comprimir os ativos do cliente

O Weblate vem com um monte de ficheiros JavaScript e CSS. Por razões de desempenho, é bom comprimi-los antes de enviar para um cliente. Na configuração predefinida isso é feito rapidamente ao custo de pouca sobrecarga. Em grandes instalações, recomenda-se ativar o modo de compressão offline. Isso precisa ser feito na configuração e a compressão tem que ser acionada em cada atualização do Weblate.

A mudança da configuração é simples ao ativar django.conf.settings.COMPRESS_OFFLINE e configuração django.conf.settings.COMPRESS_OFFLINE_CONTEXT (este último já está incluído na configuração do exemplo):

COMPRESS_OFFLINE = True

Em cada implantação precisa compactar os ficheiros para corresponder à versão atual:

weblate compress

Dica

A imagem oficial do Docker já tem este recurso ativado.

Executar o servidor

Precisará de vários serviços para executar o Weblate, a configuração recomendada consiste em:

Nota

Existem algumas dependências entre os serviços, por exemplo, o cache e o banco de dados devem estar em execução ao iniciar os processos de Celery ou uwsgi.

Na maioria dos casos, executará todos os serviços num único servidor (virtual), mas se a sua instalação estar muito carregada, pode dividir os serviços. A única limitação disso é que os servidores Celery e Wsgi precisam acessar DATA_DIR.

Nota

The WSGI process has to be executed under the same user the Celery process, otherwise files in the DATA_DIR will be stored with mixed ownership, leading to runtime issues.

See also Permissões do sistema de ficheiros and Tarefas de fundo a usar o Celery.

Executar um servidor web

Executar o Weblate não é diferente de executar qualquer outro programa baseado em Django. Django é geralmente executado como uWSGI ou fcgi (consulte exemplos para diferentes servidores web abaixo).

Para fins de teste, pode usar o servidor web incorporado no Django:

weblate runserver

Aviso

NÃO USE ESTE SERVIDOR NUMA CONFIGURAÇÃO DE PRODUÇÃO. Não passou por auditorias de segurança ou testes de desempenho. Veja também a documentação de Django no runserver.

Dica

O servidor embutido do Django serve apenas ficheiros estáticos com DEBUG ativado, pois é destinado apenas ao desenvolvimento. Para uso em produção, consulte as configurações de wsgi em Configuração de amostra para NGINX e uWSGI, Configuração de amostra para Apache, Configuração de amostra para Apache and Gunicorn e Servir ficheiros estáticos.

Servir ficheiros estáticos

Alterado na versão 2.4: Antes da versão 2.4, o Weblate não usava a estrutura de ficheiros estáticos do Django corretamente e a configuração era mais complexa.

Django precisa coletar os ficheiros estáticos dele num único diretório. Para isso, execute weblate collectstatic --noinput. Isso copiará os ficheiros estáticos num diretório especificado pela configuração STATIC_ROOT (isso é a predefinição para um diretório static dentro de DATA_DIR).

Recomenda-se servir ficheiros estáticos diretamente do seu servidor web. Deve usá-los para os seguintes caminhos:

/static/

Serve ficheiros estáticos para Weblate e a interface de administração (definida por STATIC_ROOT).

/media/

Usado para o envio de mídia pelo utilizador (por exemplo, capturas de ecrã).

/favicon.ico

Deve ser reescrito para reescrever uma regra para servir /static/favicon.ico.

Política de segurança de conteúdo

A configuração predefinida do Weblate ativa o middleware weblate.middleware.SecurityMiddleware que define cabeçalhos HTTP relacionados à segurança como Content-Security-Policy ou X-XSS-Protection. São configurados por predefinição para funcionar com o Weblate e a configuração dele, mas isso pode precisar de personalização no seu ambiente.

Configuração de amostra para NGINX e uWSGI

Para executar o servidor web de produção, use o wrapper wsgi instalado com Weblate (no caso de ambiente virtual é instalado como ~/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py). Também não se esqueça de definir o caminho de pesquisa Python para o seu virtualenv (por exemplo, usando virtualenv = /home/user/weblate-env` no uWSGI).

A configuração a seguir executa o Weblate como uWSGI sob o servidor web NGINX.

A configuração para NGINX (também disponível como weblate/examples/weblate.nginx.conf):

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # DATA_DIR/static/favicon.ico
        alias /home/weblate/data/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # DATA_DIR/static/
        alias /home/weblate/data/static/;
        expires 30d;
    }

    location /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

Configuração para uWSGI (também disponível como weblate/examples/weblate.uwsgi.ini):

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Configuração de amostra para Apache

It is recommended to use prefork MPM when using WSGI with Weblate.

A configuração seguinte executa Weblate como WSGI, precisa ter mod_wsgi ativado (disponível como weblate/examples/apache.conf):

#
# VirtualHost for Weblate
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate request-timeout=600
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Nota

Weblate requires Python 3, so please make sure you are running Python 3 variant of the modwsgi. Usually it is available as a separate package, for example libapache2-mod-wsgi-py3.

Configuração de amostra para Apache and Gunicorn

A configuração seguinte executa o Weblate em Gunicorn and Apache 2.4 (disponível como weblate/examples/apache.gunicorn.conf):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !
    ProxyPass /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

A executar o Weblate sob o caminho

Alterado na versão 1.3: This is supported since Weblate 1.3.

It is recommended to use prefork MPM when using WSGI with Weblate.

A sample Apache configuration to serve Weblate under /weblate. Again using mod_wsgi (also available as weblate/examples/apache-path.conf):

#
# VirtualHost for Weblate, running under /weblate path
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /weblate/static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py process-group=weblate request-timeout=600
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.7/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Additionally, you will have to adjust weblate/settings.py:

URL_PREFIX = "/weblate"

Tarefas de fundo a usar o Celery

Novo na versão 3.2.

Weblate uses Celery to process background tasks. A typical setup using Redis as a backend looks like this:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

For development, you might want to use eager configuration, which does process all tasks in place, but this will have performance impact on Weblate:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

You should also start the Celery worker to process the tasks and start scheduled tasks, this can be done directly on the command line (which is mostly useful when debugging or developing):

./weblate/examples/celery start
./weblate/examples/celery stop

Nota

The Celery process has to be executed under the same user as the WSGI process, otherwise files in the DATA_DIR will be stored with mixed ownership, leading to runtime issues.

See also Permissões do sistema de ficheiros and Executar o servidor.

Running Celery as system service

Most likely you will want to run Celery as a daemon and that is covered by Daemonization. For the most common Linux setup using systemd, you can use the example files shipped in the examples folder listed below.

Systemd unit to be placed as /etc/systemd/system/celery-weblate.service:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

Environment configuration to be placed as /etc/default/celery-weblate:

# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker,
# increase concurency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --prefetch-multiplier:backup=2"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

# Internal Weblate variable to indicate we're running inside Celery
CELERY_WORKER_RUNNING="1"

Logrotate configuration to be placed as /etc/logrotate.d/celery:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Periodic tasks using Celery beat

Weblate comes with built-in setup for scheduled tasks. You can however define additional tasks in settings.py, for example see Commits adiados.

The tasks are supposed to be executed by Celery beats daemon. In case it is not working properly, it might not be running or its database was corrupted. Check the Celery startup logs in such case to figure out root cause.

Monitoring Celery status

You can use celery_queues to see current length of Celery task queues. In case the queue will get too long, you will also get configuration error in the admin interface.

Aviso

The Celery errors are by default only logged into Celery log and are not visible to user. In case you want to have overview on such failures, it is recommended to configure Collecting error reports.

Monitoring Weblate

Weblate provides the /healthz/ URL to be used in simple health checks, for example using Kubernetes.

Collecting error reports

Weblate, as any other software, can fail. In order to collect useful failure states we recommend to use third party services to collect such information. This is especially useful in case of failing Celery tasks, which would otherwise only report error to the logs and you won’t get notified on them. Weblate has support for the following services:

Sentry

Weblate has built-in support for Sentry. To use it, it’s enough to set SENTRY_DSN in the settings.py:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Rollbar

Weblate has built-in support for Rollbar. To use it, it’s enough to follow instructions for Rollbar notifier for Python.

In short, you need to adjust settings.py:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "master",
    "root": "/absolute/path/to/code/root",
}

Everything else is integrated automatically, you will now collect both server and client side errors.

Migrating Weblate to another server

Migrating Weblate to another server should be pretty easy, however it stores data in few locations which you should migrate carefully. The best approach is to stop Weblate for the migration.

Migrating database

Depending on your database backend, you might have several options to migrate the database. The most straightforward one is to dump the database on one server and import it on the new one. Alternatively you can use replication in case your database supports it.

The best approach is to use database native tools, as they are usually the most effective (e.g. mysqldump or pg_dump). If you want to migrate between different databases, the only option might be to use Django management to dump and import the database:

# Export current data
weblate dumpdata > /tmp/weblate.dump
# Import dump
weblate loaddata /tmp/weblate.dump

Migrating VCS repositories

The VCS repositories stored under DATA_DIR need to be migrated as well. You can simply copy them or use rsync to do the migration more effectively.

Other notes

Don’t forget to move other services Weblate might have been using like Redis, Cron jobs or custom authentication backends.