Integração de controlo de versões¶
Weblate atualmente tem apoio a Git (com apoio estendido a Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Pedidos de revisão Gerrit, Subversion, Pull requests do Bitbucket Cloud, Pull requests do Bitbucket Data Center, and Pull requests do Azure DevOps) e Mercurial como back-ends de controlo de versão.
Para etapas de configuração específicas ao fornecedor que combinam acesso de repositório, chegada de notificações, e o envio de traduções de volta, veja Integrações de hospedagem de código.
Acessando repositórios¶
O repositório VCS que deseja usar tem que ser acessível ao Weblate. Com um repositório disponível publicamente, só precisa inserir a URL correta (por exemplo https://github.com/WeblateOrg/weblate.git), mas para repositórios privados ou para URLs de push a configuração é mais complexa e requer autenticação.
Troubleshooting repository URLs¶
Weblate validates repository and push URLs before connecting. HTTPS and SSH
are permitted by default; instance administrators can adjust this using
VCS_ALLOW_SCHEMES.
Repository hostnames have to resolve from the Weblate server. When
VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations
which resolve to internal or otherwise non-public addresses. Use a publicly
reachable repository URL where possible. For an intentionally private
repository on a trusted network, ask the instance administrator to add its
hostname to VCS_ALLOW_HOSTS.
Git over HTTPS and SSH can bind connections to addresses approved during
validation. Backends which cannot do this safely, including Mercurial and
Subversion, require the trusted repository hostname in
VCS_ALLOW_HOSTS while private-address restrictions are enabled.
Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.
Acessando repositórios do Hosted Weblate¶
Nota
Esta secção aplica-se apenas para o Hosted Weblate (hosted.weblate.org). Se está a executar a sua própria instância auto-alojada do Weblate, por favor em vez disso veja a seguinte secção.
Para repositórios GitHub no Hosted Weblate, utilize a aplicação Hosted Weblate do fluxo do Weblate Conectar conta GitHub quando possível. A Aplicação garante acesso de repositório, recebe notificações, submeter para os ramos de traduções, e cria pull requests sem convidar o utilizador Hosted Weblate weblate. Veja Acesso do repositório GitHub para a configuração completa.
Para acesso SSH direto fora do fluxo de trabalho da GitHub App, e para repositórios BitBucket, Codeberg e GitLab, o Hosted Weblate têm um utilizador de envio dedicado (com o nome de utilizador weblate, e-mail hosted@weblate.org e um nome ou descrição de perfil Weblate push user).
Dica
Pode haver mais utilizadores do Weblate nas plataformas, designados para outras instâncias Weblate. É recomendável buscar por e-mail hosted@weblate.org para encontrar o utilizador correto para Hosted Weblate.
Precisa adicionar este utilizador como colaborador e dar a permissão apropriada ao seu repositório (de apenas para leitura é suficiente para clonagem, de escrita é necessária para fazer push). Dependendo do serviço e das configurações da sua organização, isto acontece imediatamente, ou requer confirmação do lado do Weblate.
O utilizador do Weblate no GitHub aceita os convites automaticamente dentro de cinco minutos quando utiliza intencionalmente o acesso SSH direto lá. O processamento manual pode ser necessário nos outros serviços, por isso, por favor, seja paciente.
Para esta configuração de utilizador SSH direta, uma vez adicionado o utilizador weblate ao seu repositório, pode configurar o Repositório do código-fonte e a URL de submissão do repositório pelo protocolo SSH, por exemplo, git@example.com:group/project.git.
Aceder repositórios em sites de hospedagem de código (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Nota
Esta secção aplica-se a instâncias Weblate auto-alojadas. Se está a usar o Hosted Weblate (hosted.weblate.org), em vez disso veja Acessando repositórios do Hosted Weblate.
Para o Weblate auto-alojado, um repositório privado individual é frequentemente o mais fácil de configurar usando um URL de repositório HTTPS com um token de acesso, veja Integrações de hospedagem de código.
Para múltiplos repositórios crie um utilizador de hospedagem de código dedicado que é associado a uma chave SSH do Weblate (consulte Chave SSH do Weblate). Dessa forma, associa a chave SSH do Weblate a um único utilizador, porque as plataformas frequentemente impõem o uso único de uma chave SSH. Conceda a este utilizador acesso ao repositório, e use um URL SSH para aceder o repositório (consulte Repositórios SSH).
Repositórios SSH¶
Um método comum mais usado para aceder a repositórios privados é baseado em SSH. Autorize a chave pública SSH do Weblate (veja Chave SSH do Weblate) para aceder ao repositório upstream desta forma.
Aviso
No GitHub, cada chave só pode ser utilizada uma vez, veja Acesso do repositório GitHub e Acessando repositórios do Hosted Weblate.
Weblate também guarda a impressão digital da chave na primeira ligação, e não se coneta ao anfitrião caso ele seja alterado posteriormente (consulte Verificando chaves SSH do host).
Caso o ajuste seja necessário, faça-o a partir da interface de administração Weblate:
Chave SSH do Weblate¶
Alterado na versão 4.17: O Weblate agora gera chaves SSH RSA e Ed25519. Usar Ed25519 é recomendado para novas configurações.
A chave pública do Weblate está visível para todos os utilizadores que navegam na página Sobre.
Os administradores podem gerar ou exibir a chave pública usada atualmente pelo Weblate na conexão (a partir de Chaves SSH) na página inicial da interface administrativa.
Nota
A chave SSH privada correspondente não pode ter uma palavra-passe no momento, por isso certifique-se de que ela está bem protegida.
Dica
Faça um backup da chave SSH privada gerada do Weblate.
Verificando chaves SSH do host¶
O Weblate armazena automaticamente as chaves SSH do host no primeiro acesso e lembra-se delas para uso posterior.
Quando VCS_RESTRICT_PRIVATE está ativado, o Weblate resolve e valida o anfitrião de repositório antes de analisar a sua chave e conecta ssh-keyscan apenas nos endereços aprovados. A chave armazenada permanece associada com o nome de anfitrião original.
Para conexões Git, o Weblate também aplica HostName ae Port a partir de DATA_DIR/ssh/config antes de validar e afixar o destino efetivo. Configuração SSH e SSH_EXTRA_ARGS são entradas confiadas controladas por um administrador. Eles podem alterar roteamento de conexão, e SSH_EXTRA_ARGS pode sobrescrever o afixar de endereços do Weblate; administradores são responsáveis pelos seus efeitos.
Caso queira verificar a impressão digital da chave antes de se ligar ao repositório, adicione as chaves SSH dos servidores que vai aceder em Adicionar chave de Host, a partir da mesma secção da interface de administração. Digite o nome do Host que vai aceder (por exemplo, gitlab.com) e pressione Enviar. Verifique se a sua impressão digital corresponde ao servidor que adicionou.
As chaves adicionadas com impressões digitais são mostradas na mensagem de confirmação:
Conectar a servidores SSH legados¶
Lançamentos recentes do OpenSSH (por exemplo, o usado no contentor Weblate Docker) desativam assinaturas RSA usando o algoritmo de hash SHA-1 por padrão. Esta alteração foi feita porque o algoritmo de hash SHA-1 é criptograficamente quebrado e é possível criar colisões de hash de prefixo escolhido por <USD$50K.
Para a maioria dos utilizadores, esta alteração deve ser invisível e não há necessidade de substituir chaves ssh-rsa. O OpenSSH tem suporte para assinaturas RFC8332 RSA/SHA-256/512 desde a versão 7.2 e as chaves ssh-rsa existentes usarão automaticamente o algoritmo mais forte sempre que possível.
A incompatibilidade é mais provável ao conectar-se a implementações SSH mais antigas que não foram atualizadas ou não acompanharam de perto as melhorias no protocolo SSH. A conexão SSH com tal servidor falhará com:
no matching host key type found. Their offer: ssh-rsa
Para estes casos, pode ser necessário reativar seletivamente o RSA/SHA1 para permitir a conexão e/ou autenticação do utilizador por meio das opções HostkeyAlgorithms e PubkeyAcceptedAlgorithms. Por exemplo, a seguinte estrofe em DATA_DIR/ssh/config ativará o RSA/SHA1 para autenticação de host e utilizador para um único host de destino:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Recomendamos ativar RSA/SHA1 apenas como uma medida paliativa até que implementações legadas possam ser atualizadas ou reconfiguradas com outro tipo de chave (como ECDSA ou Ed25519).
Repositórios do GitHub¶
Acesso de repositório GitHub detalhado é abordado em Acesso do repositório GitHub.
Repositórios do GitLab¶
Acesso de repositório GitLab detalhado é abordado em Acesso de repositório GitLab.
URLs internas do Weblate¶
Partilhe uma configuração de repositório entre diferentes componentes, a fazer referência ao seu posicionar como weblate://projeto/componente em outros componentes (vinculados). Desta forma, os componentes vinculados utilizam a configuração do repositório VCS do componente principal (referenciado).
Aviso
A remoção do componente principal também remove componentes vinculados.
Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component’s repository configuration.
Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.
O Weblate ajusta automaticamente a URL do repositório ao criar um componente se encontrar um componente com uma configuração de repositório correspondente. Pode anular isso na última etapa da configuração do componente.
Motivos para usar isso:
Economiza espaço em disco no servidor, o repositório é armazenado apenas uma vez.
Torna as atualizações mais rápidas, apenas um repositório é atualizado.
Há apenas um repositório exportado com traduções do Weblate (ver Exportador git).
Algumas extensões podem operar em vários componentes compartilhando um repositório; por exemplo, Squash de commits git.
Repositórios HTTPS¶
Para aceder a repositórios HTTPS protegidos, inclua o nome de utilizador e senha na URL. Não se preocupe, o Weblate irá remover essas informações quando a URL for mostrada aos utilizadores (mesmo se for permitido ver a URL do repositório).
Por exemplo, a URL do GitHub com autenticação adicionada pode parecer: https://usuario:seu_token_de_acesso@github.com/WeblateOrg/weblate.git.
Em caso de não fornecer credenciais no URL e o repositório exija os mesmos, o Git falhará com um erro:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Alterado na versão 5.10.2: Weblate usa autenticação proativa com o Git 2.46.0 e versões mais recentes quando as credenciais HTTP são fornecidas.
Isto possibilita o acesso aos repositórios do Azure DevOps e agiliza o acesso aos repositórios autenticados.
Nota
Se o seu nome de utilizador ou palavra-passe contiver caracteres especiais, eles devem ser codificados para URL; por exemplo, https://usuario%40example.com:%24senha%23@bitbucket.org/….
Usando proxy¶
Se precisa de aceder a repositórios Git através de HTTPS usando um servidor proxy, configure as variáveis de ambiente por protocolo descritas em Proxy HTTP.
Version control parameters¶
Added in version 2026.9.
Version control parameters tune how a component interacts with its repository without having to choose a different version control system. They are configured per component in Version control parameters, and only the parameters applicable to the selected Sistema de controlo de versões are offered.
List of version control parameters¶
Nome do parâmetro |
Version control systems |
Etiqueta |
Texto de ajuda |
|---|---|---|---|
create_merge_request |
|
Create merge requests |
Open a pull or merge request for the translation changes. When turned off, Weblate pushes to the translated branch directly, which requires write access to it. |
git_force_push |
|
Force push |
Overwrite the remote branch instead of refusing to push non-fast-forward changes. Only use this with a repository dedicated to translations, as it discards upstream commits which are not present in Weblate. |
merge_request_automerge |
|
Merge pull requests automatically |
Turn on GitHub auto-merge for pull requests created by Weblate, so that they are merged once the required checks pass. Pull requests with nothing to wait for are merged right away. |
merge_request_merge_method |
|
Método de união |
Method used when merging pull requests automatically. The repository has to allow it. Escolhas disponíveis:
|
Git¶
Dica
O Weblate requer o Git 2.46 ou mais recente.
Nota
O Weblate valida redirecionamentos HTTP permanentes que permanecem no nome de anfitrião do repositório e armazenam automaticamente o URL de repositório canónico. A alteração é gravada no histórico do componente enquanto manutenção do repositório. Redirecionamentos para outro nome de anfitrião têm que ser configurados manualmente.
Veja também
Consulte Acessando repositórios para obter informações sobre como aceder a diferentes tipos de repositórios.
Git LFS¶
Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.
A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.
For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.
Git submodules¶
Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.
If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.
Force pushing¶
Turn on the git_force_push version control parameter to
make Weblate always force push. This is intended only in the case of using a
separate repository for translations.
Aviso
Use com cautela, pois isso facilmente leva a commits perdidos no seu repositório upstream.
Alterado na versão 2026.9: This used to be a separate Git with force push version control
system. Existing components were migrated to Git with the git_force_push
parameter turned on.
Personalizando a configuração do Git¶
Weblate invoca todos os comandos VCS com HOME=$DATA_DIR/home (veja DATA_DIR), portanto a edição da configuração do utilizador precisa ser feita em DATA_DIR/home/.git.
Pull requests do GitHub¶
Configuração de pull request do GitHub de formada detalhada é abordado em Pull requests do GitHub.
Merge requests do GitLab¶
A configuração de merge request do GitLab detalhado é coberto em Merge requests do GitLab.
Pull requests do Gitea¶
Configuração de pull request do Gitea detalhado é abordado em Pull requests do Gitea.
Pull requests do Bitbucket Data Center¶
Configuração do pull request do BitBucket Data Center de forma detalhada é abordada em Pull requests do Bitbucket Data Center.
Pull requests do Bitbucket Cloud¶
Configuração de pull request do BitBucket Cloud de forma detalhada é abordada em Pull requests do Bitbucket Cloud.
Merge requests do Pagure¶
Configuração de merge request do Pagure detalhada é abordada em Merge requests do Pagure.
Gerrit¶
Configuração de pedido de revisão do Gerrit de forma detalha é abordada em Pedidos de revisão Gerrit.
Pull requests do Azure DevOps¶
Configuração de pull request do Azure DevOps de forma detalhada está coberta em Pull requests do Azure DevOps.
Mercurial¶
Mercurial é outro VCS que pode usar diretamente no Weblate.
Nota
Ele deve funcionar com qualquer versão Mercurial, mas às vezes há alterações incompatíveis na interface de linha de comando que quebra a integração Weblate.
Veja também
Consulte Acessando repositórios para obter informações sobre como aceder a diferentes tipos de repositórios.
Subversion¶
O Weblate usa git-svn para interagir com repositórios subversion. É um script Perl que permite que o subversion seja usado por um cliente Git, a permitir que os utilizadores mantenham um clone completo do repositório interno e façam commit localmente.
Nota
O Weblate tenta detetar o layout do repositório Subversion automaticamente – ele tem suporta a URLs diretas para remos ou repositórios com layout padrão (branches/, tags/ e trunk/). Mais informações sobre isso encontram-se na documentação do git-svn. Se o repositório não tiver um layout padrão e encontrar erros, tente incluir o nome do ramo na URL do repositório e deixar a ramo vazia.
Credenciais de Subversion¶
Weblate espera que tenha aceito o certificado com antecedência (e as suas credenciais, se necessário). Ele procurará inseri-las no diretório DATA_DIR. Aceite o certificado a utilizar svn uma vez com a variável de ambiente $HOME definida como DATA_DIR:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Veja também
Ficheiros locais¶
Dica
Internamente, isto utiliza Git. Este requer o Git instalado e permite que mude para utilizar o Git nativamente com o histórico completo das suas traduções.
O Weblate também pode operar sem um VCS remoto. As traduções iniciais são importadas a carrega-las. Mais tarde, pode substituir ficheiros individuais a enviar ficheiros ou a adicionar cadeias de tradução diretamente do Weblate (atualmente disponível apenas para traduções monolíngues).
No fundo, o Weblate cria um repositório de Git para si e todas as alterações são rastreadas. Caso decida mais tarde usar um VCS para armazenar as traduções, já tem um repositório dentro do Weblate pode basear na sua integração.