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, Gerrit, Subversion, Pull requests do Bitbucket Cloud, Pull requests do Bitbucket Data Center e Pull requests do Azure DevOps) e Mercurial como back-ends de controlo de versão.
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.
Acessando repositórios do Hosted Weblate¶
Para o Hosted Weblate, há um utilizador para push dedicado registado no GitHub, Bitbucket, Codeberg e GitLab (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. O processamento manual pode ser necessário nos outros serviços, por isso, por favor, seja paciente.
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@github.com:WeblateOrg/weblate.git).
Aceder repositórios em sites de hospedagem de código (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
O acesso a repositórios em sites de hospedagem de código é normalmente feito criando um utilizador 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 (as plataformas frequentemente impõem o uso único de uma chave SSH) e concede a este utilizador acesso ao repositório. Pode então usar a URL SSH para aceder o repositório (consulte Repositórios SSH).
Dica
Num Hosted Weblate, isto é pré-configurado para a maioria dos sites públicos, consulte Acessando repositórios do Hosted Weblate.
Repositórios SSH¶
O método 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 Repositórios do 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.
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¶
O acesso via SSH é possível (veja Repositórios SSH), mas caso precise aceder a mais de um repositório, 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 implementações menores, utilize a autenticação HTTPS com um código de acesso pessoal e a sua conta do GitHub, consulte Criar um código de acesso para utilizar na linha de comandos.
Para configurações maiores, geralmente é melhor criar um utilizador 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 deseja traduzir. Essa abordagem também é usada para o Hosted Weblate, há utilizador dedicado weblate para isso.
GitLab repositories¶
Access via SSH is possible (see Repositórios SSH), but in case you need to access more than one repository, you will hit a GitLab limitation on allowed SSH key usage (since each key can be used only once).
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.
Using personal or project access tokens is possible as well. The token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.
The URL needs to contain an username, for personal access token it is the
actual username (
https://user:personal_access_token@gitlab.com/example/example.git) for
project access tokens it can be non-blank value
(https://example:project_access_token@gitlab.com/example/example.git).
Nota
The rules for using project access tokens has changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure.
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.
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¶
Veja também
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.
In case you don’t provide credentials in the URL and the repository requires it, Git will fail with an error:
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 precisar aceder a repositórios VCS por HTTP/HTTPS a usar um servidor proxy, configure o VCS para o usar.
Isto pode ser feito a utilizar as variáveis de ambiente http_proxy, https_proxy e all_proxy (como descrito na documentação do cURL) ou a aplicar-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 utilizador a executar Weblate (veja também Permissões do sistema de ficheiros) e com HOME=$DATA_DIR/home (veja DATA_DIR), caso contrário o Git executado pelo Weblate não o utilizará.
Veja também
Git¶
Dica
O Weblate requer o Git 2.28 ou mais recente.
Veja também
Consulte Acessando repositórios para obter informações sobre como aceder a 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 no 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 utilizador precisa ser feita em DATA_DIR/home/.git.
Auxiliares de remotos do Git¶
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. Descarregue-os manualmente e ponha em algum lugar no 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 a usar Bazaar:
bzr::lp:gnuhello
Para o repositório hello de selenic.com a usar Mercurial:
hg::https://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¶
Isto adiciona uma camada fina sobre o Git a utilizar 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 se for apenas para aceder a repositórios Git.
Tem de configurar as credenciais da API (GITHUB_CREDENTIALS) nas definições do Weblate para que isto funcione. Uma vez configurado, irá ver uma opção do GitHub quando seleciona Sistema de controlo de versões.
Merge requests do GitLab¶
Isto apenas adiciona uma camada fina sobre o Git a usar 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 usar isto para aceder a repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença o modo como o envio para um repositório é manipulado. Com Git, o envio das alterações é feito diretamente para o repositório, enquanto Merge requests do GitLab cria pedidos de fusão.
Precisa configurar as credenciais da API (GITLAB_CREDENTIALS) nas configurações da Weblate para funcionar. Uma vez configurado, verá uma opção GitLab ao selecionar Sistema de controlo de versões.
Pull requests do Gitea¶
Added in version 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 ao repositório.
Não há necessidade de usar isto para aceder a repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença o modo como o envio para um repositório é manipulado. Com Git, o envio das alterações é feito diretamente para o repositório, enquanto Pull requests do Gitea cria pedidos de fusão.
Precisa configurar as credenciais da API (GITEA_CREDENTIALS) nas configurações do Weblate para fazer isso funcionar. Uma vez configurado, verá uma opção Gitea ao selecionar Sistema de controlo de versões.
Pull requests do Bitbucket Data Center¶
Added in version 4.16.
Isto apenas adiciona uma camada fina sobre o Git utilizando a API do Bitbucket Data Center para permitir fazer push de alterações de tradução como pull requests, ao invés de fazer push diretamente para o repositório.
Aviso
Isto não é compatível com a API do Bitbucket Cloud.
Não há necessidade de usá-lo para aceder repositórios Git, o Git comum funciona da mesma forma, o que é 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 Bitbucket Data Center cria pull requests.
Precisa configurar as credenciais da API (BITBUCKETSERVER_CREDENTIALS) nas configurações do Weblate para fazer isto funcionar. Uma vez configurado, verá uma opção Bitbucket Data Center ao selecionar Sistema de controlo de versões.
Pull requests do Bitbucket Cloud¶
Added in version 5.8.
Isto apenas adiciona uma camada fina sobre o Git pela API do Bitbucket Cloud para permitir fazer push de alterações de tradução como pull requests, ao invés de fazer push diretamente para o repositório.
Aviso
Isto é diferente da API do Bitbucket Data Center.
Não há necessidade de usá-lo para aceder repositórios Git, o Git comum funciona da mesma forma, a ser 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 Bitbucket Cloud cria pull request.
Precisa configurar as credenciais da API (BITBUCKETCLOUD_CREDENTIALS) nas configurações do Weblate para fazê-lo funcionar. Uma vez configurado, verá uma opção Bitbucket Cloud ao selecionar Sistema de controlo de versões.
Merge requests do Pagure¶
Added in version 4.3.2.
Isto apenas adiciona uma camada fina sobre o Git a usar 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 usar isto para aceder a repositórios Git, o Git comum funciona da mesma forma, sendo a única diferença o modo como o envio para um repositório é manipulado. Com Git, o envio das alterações é feito diretamente para o repositório, enquanto Merge requests do Pagure cria pedidos de fusão.
Precisa configurar as credenciais da API (PAGURE_CREDENTIALS) nas configurações da Weblate para funcionar. Uma vez configurado, verá uma opção Pagure ao selecionar Sistema de controlo de versões.
Gerrit¶
Adiciona uma camada fina sobre o Git a usar 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.
Pull requests do Azure DevOps¶
Isto adiciona uma camada fina sobre o Git pela API do Azure DevOps 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 Azure DevOps cria pull requests. Este último não é necessário para apenas aceder repositórios Git.
Precisa configurar as credenciais da API (AZURE_DEVOPS_CREDENTIALS) nas configurações do Weblate para fazer isto funcionar. Uma vez configurado, verá uma opção Azure DevOps ao selecionar Sistema de controlo de versões.
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.