Integração com controle de versão

Weblate atualmente tem suporte a Git (com suporte estendido a Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Gerrit e Subversion) e Mercurial como back-ends de controle de versão.

Acessando repositórios

O repositório VCS que você deseja usar tem que ser acessível ao Weblate. Com um repositório disponível publicamente, você 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.

Acessando repositórios do Hosted Weblate

Para Hosted Weblate há um usuário dedicado para fazer push registrado no GitHub, Bitbucket, Codeberg e GitLab (com o nome de usuário weblate, e-mail hosted@weblate.org e chamado Weblate push user). Você precisa adicionar esse usuário como colaborador e dar a permissão apropriada ao seu repositório (somente leitura está bom para clonagem, escrita é necessária para fazer push). Dependendo do serviço e das configurações da sua organização, isso acontece imediatamente, ou requer confirmação do lado do Weblate.

O usuário weblate no GitHub aceita convites automaticamente dentro de cinco minutos. O processamento manual pode ser necessário nos outros serviços, por isso, por favor, seja paciente.

Uma vez adicionado o usuário weblate, você pode configurar o Repositório do código-fonte e a URL de push do repositório utilizando o protocolo SSH (por exemplo, git@github.com:WeblateOrg/weblate.git).

Repositórios SSH

O método mais usado para acessar repositórios privados é baseado no SSH. Autorize a chave pública SSH do Weblate (veja Chave SSH do Weblate) para acessar o repositório upstream desta forma.

Aviso

No GitHub, cada chave só pode ser utilizada uma vez, veja Repositórios do GitHub e Acessando repositórios do Hosted Weblate.

Weblate também armazena a impressão digital da chave do host na primeira conexão, e não se conecta ao host caso ele seja alterado posteriormente (veja Verificando chaves SSH do host).

Caso o ajuste seja necessário, faça-o a partir da interface de administração Weblate:

_images/ssh-keys.png

Chave SSH do Weblate

A chave pública do Weblate está visível para todos os usuários 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 senha 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 delas para uso posterior.

Caso você queira verificar a impressão digital da chave antes de se conectar ao repositório, adicione as chaves SSH dos servidores que você vai acessar em Adicionar chave de host, a partir da mesma seção da interface de administração. Digite o nome do host que você vai acessar (por exemplo, gitlab.com), e pressione Enviar. Verifique se sua impressão digital corresponde ao servidor que você adicionou.

As chaves adicionadas com impressões digitais são mostradas na mensagem de confirmação:

_images/ssh-keys-added.png

Repositórios do GitHub

O acesso via SSH é possível (veja Repositórios SSH), mas caso você precise acessar mais de um repositório, você atingirá uma limitação do GitHub no uso permitido da chave SSH (já que cada chave pode ser usada apenas uma vez).

Caso o Ramo do push não seja definido, é criado um fork do projeto e feito um push das alterações através do fork. Caso seja definido, os pushes são feitos para o repositório upstream e para o ramo escolhido.

Para implantações menores, use autenticação HTTPS com um token de acesso pessoal e sua conta GitHub, veja Criando um token de acesso para uso em linha de comando.

Para configurações maiores, geralmente é melhor criar um usuário dedicado para o Weblate, atribuir-lhe a chave SSH pública gerada no Weblate (ver Chave SSH do Weblate) e concedê-lo acesso a todos os repositórios que você deseja traduzir. Essa abordagem também é usada para o Hosted Weblate, há usuário dedicado weblate para isso.

URLs internas do Weblate

Compartilhe uma configuração de repositório entre diferentes componentes, fazendo referência à sua colocação 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.

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. Você 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 acessar repositórios HTTPS protegidos, inclua o nome de usuário e a senha na URL. Não se preocupe, o Weblate irá remover essas informações quando a URL for mostrada aos usuários (se mesmo 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.

Nota

Se seu nome de usuário ou senha contiver caracteres especiais, eles devem ser codificados para URL; por exemplo, https://usuario%40example.com:%24senha%23@bitbucket.org/….

Usando proxy

Se você precisar acessar repositórios VCS por HTTP/HTTPS usando um servidor proxy, configure o VCS para usá-lo.

Isto pode ser feito utilizando as variáveis de ambiente http_proxy, https_proxy e all_proxy (como descrito na documentação do cURL) ou aplicando-a na configuração do VCS, por exemplo:

git config --global http.proxy http://user:password@proxy.example.com:80

Nota

A configuração do proxy precisa ser feita com o usuário executando Weblate (veja também Permissões do sistema de arquivos) e com HOME=$DATA_DIR/home (veja DATA_DIR), caso contrário o Git executado pelo Weblate não o utilizará.

Git

Dica

O Weblate requer o Git 2.12 ou mais recente.

Ver também

Consulte Acessando repositórios para obter informações sobre como acessar diferentes tipos de repositórios.

Git com push forçado

Ele se comporta exatamente como o próprio Git, a única diferença é que ele sempre força pushes. Isso se destina apenas no caso de usar um repositório separado para traduções.

Aviso

Use com cautela, pois isso facilmente leva a commits perdidos em seu repositório upstream.

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 usuário precisa ser feita em DATA_DIR/home/.git.

Auxiliares de remotos do Git

Você também pode usar os auxiliares de remotos do Git para ter suporte adicionalmente a outros sistemas de controle de versão, mas esteja preparado para depurar problemas que isso pode levar.

Neste momento, os auxiliares de Bazaar e Mercurial estão disponíveis em repositórios separados no GitHub: git-remote-hg e git-remote-bzr. Baixe-os manualmente e coloque em algum lugar em seu caminho de pesquisa (por exemplo, ~/bin). Certifique-se de ter os sistemas de controle de versão correspondentes instalados.

Uma vez instalados, esses controles podem ser usados para especificar um repositório no Weblate.

Para clonar o projeto gnuhello do Launchpad usando Bazaar:

bzr::lp:gnuhello

Para o repositório hello de selenic.com usando Mercurial:

hg::http://selenic.com/repo/hello

Aviso

O inconveniente de usar auxiliares de remotos Git é, por exemplo, com o Mercurial, o auxiliar de remoto às vezes cria uma nova dica ao fazer push das mudanças de volta.

Pull requests do GitHub

Novo na versão 2.3.

Isto adiciona uma camada fina sobre o Git utilizando a API do GitHub para permitir fazer push de alterações de tradução como pull requests, ao invés de fazer push diretamente para o repositório.

Git faz push das alterações diretamente para um repositório, enquanto Pull requests do GitHub cria pull requests. Este último não é necessário para apenas acessar repositórios Git.

Você precisa configurar as credenciais da API (GITHUB_CREDENTIALS) nas configurações do Weblate para fazer isso funcionar. Uma vez configurado, você verá uma opção GitHub ao selecionar Sistema de controle de versão.

Merge requests do GitLab

Novo na versão 3.9.

Isto apenas adiciona uma camada fina sobre o Git usando a API do GitLab para permitir fazer push de alterações de tradução como merge requests, ao invés de fazer push diretamente para o repositório.

Não há necessidade de usá-lo para acessar repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença como o push para um repositório é manipulado. Com Git, o push das alterações é feito diretamente para o repositório, enquanto Merge requests do GitLab cria merge request.

Você precisa configurar as credenciais da API (GITLAB_CREDENTIALS) nas configurações do Weblate para fazer isso funcionar. Uma vez configurado, você verá uma opção GitLab ao selecionar Sistema de controle de versão.

Pull requests do Gitea

Novo na versão 4.12.

Isto apenas adiciona uma camada fina sobre o Git utilizando a API do Gitea para permitir fazer push de alterações de tradução como pull requests, ao invés de fazer push diretamente para o repositório.

Não há necessidade de usá-lo para acessar repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença como o push para um repositório é manipulado. Com Git, o push das alterações é feito diretamente para o repositório, enquanto Pull requests do Gitea cria pull requests.

Você precisa configurar as credenciais da API (GITEA_CREDENTIALS) nas configurações do Weblate para fazer isso funcionar. Uma vez configurado, você verá uma opção Gitea ao selecionar Sistema de controle de versão.

Merge requests do Pagure

Novo na versão 4.3.2.

Isto apenas adiciona uma camada fina sobre o Git usando a API do Pagure para permitir fazer push de alterações de tradução como merge requests, ao invés de fazer push diretamente para o repositório.

Não há necessidade de usá-lo para acessar repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença como o push para um repositório é manipulado. Com Git, o push das alterações é feito diretamente para o repositório, enquanto Merge requests do Pagure cria merge request.

Você precisa configurar as credenciais da API (PAGURE_CREDENTIALS) nas configurações do Weblate para fazer isso funcionar. Uma vez configurado, você verá uma opção Pagure ao selecionar Sistema de controle de versão.

Gerrit

Novo na versão 2.2.

Adiciona uma camada fina sobre o Git usando a ferramenta git-review para permitir fazer push de alterações de tradução como review requests do Gerrit, ao invés de fazer push diretamente para o repositório.

A documentação Gerrit tem os detalhes sobre a configuração necessária para configurar tais repositórios.

Mercurial

Novo na versão 2.1.

Mercurial é outro VCS que você 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.

Ver também

Consulte Acessando repositórios para obter informações sobre como acessar diferentes tipos de repositórios.

Subversion

Novo na versão 2.8.

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, permitindo que os usuários mantenham um clone completo do repositório interno e façam commit localmente.

Nota

O Weblate tenta detectar o layout do repositório Subversion automaticamente – ele tem suporte a URLs diretas para remos ou repositórios com layout padrão (branches/, tags/ e trunk/). Mais informações sobre isso podem ser encontradas na documentação do git-svn. Se o repositório não tiver um layout padrão e você encontrar erros, tente incluir o nome do ramo na URL do repositório e deixar o ramo vazio.

Alterado na versão 2.19: Antes disso, apenas repositórios usando o layout padrão eram suportados.

Credenciais de Subversion

Weblate espera que você tenha aceito o certificado com antecedência (e suas credenciais, se necessário). Ele procurará inseri-las no diretório DATA_DIR. Aceite o certificado utilizando 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

Ver também

DATA_DIR

Arquivos locais

Git

Dica

Internamente, ele usa Git. Ele requer Git instalado e permite que você mude para usar o Git nativamente com histórico completo de suas traduções.

Novo na versão 3.8.

O Weblate também pode operar sem um VCS remoto. As traduções iniciais são importadas carregando-as. Mais tarde, você pode substituir arquivos individuais enviando arquivos ou adicionando textos de tradução diretamente do Weblate (atualmente disponível apenas para traduções monolíngues).

Em segundo plano, o Weblate cria um repositório de Git para você e todas as alterações são rastreadas. Caso você decida mais tarde usar um VCS para armazenar as traduções, você já tem um repositório dentro do Weblate pode basear sua integração.