Integração de controlo de versões¶
Weblate currently supports Git (with extended support for Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Gerrit, Subversion, Bitbucket Server pull requests, and Azure DevOps pull requests) and Mercurial as version control back-ends.
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¶
For Hosted Weblate, there is a dedicated push user registered on GitHub,
Bitbucket, Codeberg, and GitLab (with the username weblate, e-mail
hosted@weblate.org, and a name or profile description Weblate push user).
Dica
There can be more Weblate users on the platforms, designated for other Weblate instances.
Searching by e-mail hosted@weblate.org is recommended to find the correct
user for Hosted Weblate.
You need to add this user as a collaborator and give it appropriate permissions to your repository (read-only is okay for cloning, write is required for pushing). Depending on the service and your organization’s settings, this happens immediately, or requires confirmation on the Weblate side.
O utilizador 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 utente.
Once the weblate user is added to your repository, you can configure
Repositório do código-fonte and URL de submissão do repositório using the SSH protocol (for example
git@github.com:WeblateOrg/weblate.git).
Accessing repositories on code hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
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 (this of frequently enforced by the platform) and grant this user access to the repository. You can then use SSH URL to access the repository (see Repositórios SSH).
Dica
On a Hosted Weblate, this is pre-cofigured for most of the public sites, please see Acessando repositórios do Hosted Weblate.
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 vcs-repos-github`e :ref:`hosted-push.
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:
Chave SSH do Weblate¶
Alterado na versão 4.17: Weblate now generates both RSA and Ed25519 SSH keys. Using Ed25519 is recommended for new setups.
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
The corresponding private SSH key can not currently have a password, so ensure it is well protected.
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 conectar ao repositório, adicione as chaves SSH dos servidores que vai acessar em Adicionar chave de host, a partir da mesma secção da interface de administração. Digite o nome do host que vai acessar (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:
Connecting to legacy SSH servers¶
Recent OpenSSH releases (for example the one used in Weblate Docker container) disable RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. The SSH connection to such server will fail with:
no matching host key type found. Their offer: ssh-rsa
For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow
connection and/or user authentication via the HostkeyAlgorithms and
PubkeyAcceptedAlgorithms options. For example, the following stanza in
DATA_DIR/ssh/config will enable RSA/SHA1 for host and user
authentication for a single destination host:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
Repositórios do GitHub¶
O acesso via SSH é possível (veja Repositórios SSH), mas caso precise acessar 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 implantações menores, use autenticação HTTPS com um token de acesso pessoal e a sua conta no GitHub, veja Criando um token de acesso para uso em linha de comando.
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.
Veja também
URLs internas do Weblate¶
Compartilhe uma configuração de repositório entre diferentes componentes, a fazer 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. 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 utilizador e a palavra-passe na URL. Não se preocupe, o Weblate irá remover essas informações quando a URL for mostrada aos utilizadores (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 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 acessar repositórios VCS por HTTP/HTTPS a usar um servidor proxy, configure o VCS para usá-lo.
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.12 ou mais recente.
Veja 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 no seu repositório upstream.
Personalizando a configuração do Git¶
Weblate invoca todos os comandos VCS com HOME=$DATA_DIR/home (veja :set:`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, :file:`~/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::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¶
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 para apenas acessar repositórios Git.
Precisa configurar as credenciais da API (GITHUB_CREDENTIALS) nas configurações do Weblate par fazê-lo funcionar. Uma vez configurado, verá uma opção GitHub ao selecionar Sistema de controlo de versões.
Veja também
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 usá-lo para acessar repositórios de 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 Merge requests do GitLab cria merge request.
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.
Veja também
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 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 ao repositório, enquanto Pull requests do Gitea cria pull requests.
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.
Veja também
Bitbucket Server pull requests¶
Added in version 4.16.
This just adds a thin layer atop Git using the Bitbucket Server API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Aviso
This does not support Bitbucket Cloud API.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Bitbucket Server pull requests creates pull request.
You need to configure API credentials (BITBUCKETSERVER_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Server option when selecting 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 usá-lo para acessar repositórios de 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 Merge requests do Pagure cria merge request.
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.
Veja também
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.
Azure DevOps pull requests¶
This adds a thin layer atop Git using the Azure DevOps API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.
Git pushes changes directly to a repository, while Azure DevOps pull requests creates pull requests. The latter is not needed for merely accessing Git repositories.
You need to configure API credentials (AZURE_DEVOPS_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Azure DevOps option when selecting 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 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, 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 :set:`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, ele usa Git. Ele requer Git instalado e permite que mude para usar o Git nativamente com 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.