Integração com controle de versão¶
Weblate currently supports Git (with extended support for Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Gerrit review requests, Subversion, Pull requests do Bitbucket Cloud, Pull requests do Bitbucket Data Center, and Pull requests do Azure DevOps) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Code hosting integrations.
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 particulares ou para URLs de push a configuração é mais complexa e requer autenticação.
Acessando repositórios do Hosted Weblate¶
Nota
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
Para o Hosted Weblate, há um usuário para push dedicado registrado no GitHub, Bitbucket, Codeberg e GitLab (com o nome de usuário weblate, e-mail hosted@weblate.org e um nome ou descrição de perfil Weblate push user).
Dica
Pode haver mais usuários do Weblate nas plataformas, designados para outras instâncias Weblate. É recomendável buscar por e-mail hosted@weblate.org para encontrar o usuário correto para Hosted Weblate.
Você precisa adicionar esse usuário como colaborador e dar as permissões apropriadas 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.
On GitHub, you need to add or invite the Hosted Weblate weblate user with write access even when you use the Hosted Weblate GitHub app. The app handles incoming notifications from GitHub, but pushing changes back still uses the Hosted Weblate weblate user.
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 ao seu repositório, você pode configurar o Repositório do código-fonte e a URL de envio do repositório utilizando o protocolo SSH (por exemplo, git@github.com:WeblateOrg/weblate.git).
Acessando repositórios em sites de hospedagem de código (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Nota
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Acessando repositórios do Hosted Weblate instead.
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Chave SSH do Weblate). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of an SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Repositórios SSH).
Repositórios SSH¶
O método mais usado para acessar repositórios particulares é baseado no SSH. Autorize a chave pública SSH do Weblate (consulte Chave SSH do Weblate) para acessar o repositório upstream desta forma.
Aviso
On GitHub, each key can only be used once, see GitHub repository access and 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 (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 usuários que navegam na página Sobre.
Os administradores podem gerar ou mostrar 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:
Conectando a servidores SSH legados¶
Lançamentos recentes do OpenSSH (por exemplo, o usado no contêiner Weblate Docker) desabilitam assinaturas RSA usando o algoritmo de hash SHA-1 por padrão. Essa 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 usuários, essa 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 esses casos, pode ser necessário reativar seletivamente o RSA/SHA1 para permitir a conexão e/ou autenticação do usuário por meio das opções HostkeyAlgorithms e PubkeyAcceptedAlgorithms. Por exemplo, a seguinte estrofe em DATA_DIR/ssh/config habilitará o RSA/SHA1 para autenticação de host e usuário para um único host de destino:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Recomendamos habilitar 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¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab repositories¶
Detailed GitLab repository access is covered in GitLab repository access.
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).
Alguns complementos podem operar em vários componentes compartilhando um repositório; por exemplo, Squash de commits git.
Repositórios HTTPS¶
Ver também
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.
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.
Isso possibilita o acesso aos repositórios do Azure DevOps e agiliza o acesso aos repositórios autenticados.
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.28 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.
Pull requests do GitHub¶
Detailed GitHub pull request setup is covered in Pull requests do GitHub.
Merge requests do GitLab¶
Detailed GitLab merge request setup is covered in Merge requests do GitLab.
Pull requests do Gitea¶
Detailed Gitea pull request setup is covered in Pull requests do Gitea.
Pull requests do Bitbucket Data Center¶
Detailed Bitbucket Data Center pull request setup is covered in Pull requests do Bitbucket Data Center.
Pull requests do Bitbucket Cloud¶
Detailed Bitbucket Cloud pull request setup is covered in Pull requests do Bitbucket Cloud.
Merge requests do Pagure¶
Detailed Pagure merge request setup is covered in Merge requests do Pagure.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Pull requests do Azure DevOps¶
Detailed Azure DevOps pull request setup is covered in Pull requests do Azure DevOps.
Mercurial¶
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¶
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.
Credenciais de Subversion¶
Weblate espera que você tenha aceito o certificado com antecedência (e suas credenciais, se necessário). Ele tentará 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
Arquivos locais¶
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.
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.