Integrações de hospedagem de código¶

O Weblate integra-se com sites de hospedagem de código em vários sítios separadamente: acesso de repositório, notificações recebidas, e adiar traduções. A configuração exata depende se utiliza Hosted Weblate ou se executa a sua instância Weblate, e se o Weblate deve dar push diretamente ou criar novos pull requests.

Utilize esta página como uma lista de verificações orientada para o fornecedor. As páginas de definições individuais permanecem enquanto referência canónica para a definição de sintaxe.

Configurar sinopse¶

Garantir acesso do repositório ao Weblate.
- Para repositórios GitHub no Hosted Weblate, utilize a ` aplicação Hosted Weblate <https://github.com/apps/hosted-weblate>`_ do fluxo de Conectar conta GitHub Weblate. A Aplicação fornece ao Hosted Weblate acesso de repositório sem convidar o utilizador weblate hospedado.
- Para outros repositórios Hosted Weblate, e para pushes SSH diretos fora do fluxo de trabalho da Aplicação GitHub, adicione o utilizador weblate onde está disponível, veja Acessando repositórios do Hosted Weblate.
- Para um Weblate auto-hospedado, cria um utilizador de hospedagem de código dedicado e garanta-lhe acesso usando a chave Weblate SSH ou um token HTTPS, veja Aceder repositórios em sites de hospedagem de código (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configura Repositório do código-fonte para que o Weblate possa clonar o repositório.
Configure notificações recebidas para que o Weblate receba mudanças pouco depois de um push. O webhook do repositório ou aplicação têm que apontar para o URL do hook Weblate correspondente, e o projeto tem que ter Ativar hooks ativado.
Decide como é que o Weblate deve enviar traduções de volta:
- Utilize Git ou Mercurial e URL de submissão do repositório para enviar diretamente.
- Utilize um backend VSC específico do provedor, tal como GitHub ou GitLab, para criar pull ou merge requests. Estes backends precisam de credenciais de API nas definições Weblate.
Opcionalmente defina Ramo do push quando o Weblate deve dar push para um ramo no repositório principal em vez de usar uma bifurcação onde suportado.

Fazendo push das alterações do Weblate¶

Cada componente de tradução pode ter uma URL de push configurada (veja URL de submissão do repositório) e, nesse caso, o Weblate será capaz de fazer push das alterações ao repositório remoto. O Weblate também pode ser configurado para fazer push automaticamente das alterações em cada commit; isso é ativo por predefinição, veja Enviar ao submeter.

Se não quer que mudanças sejam enviadas automaticamente, pode dar push manualmente sob Manutenção de repositório ou usando a API através de wlc push.

Caso não queira pushes diretos pelo Weblate, há suporte para Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Merge requests do Pagure, Pull requests do Azure DevOps, ou revisões Pedidos de revisão Gerrit. Pode ativar estes ao escolher GitHub, GitLab, Gitea, Gerrit, Azure DevOps, ou Pagure tal como Sistema de controlo de versões em Configuração de componente.

No geral, as seguintes opções estão disponíveis com Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center e Bitbucket Cloud:

Configuração desejada	Sistema de controlo de versões	URL de submissão do repositório	Ramo do push
Sem push	Git	vazio	vazio
Push diretamente	Git	URL de SSH	vazio
Empurrar para um ramo separado	Git	URL de SSH	Nome do ramo
Sem push	Mercurial	vazio	vazio
Push diretamente	Mercurial	URL de SSH	vazio
Pull request de GitHub do fork	Pull requests do GitHub	vazio	vazio
Pull request de GitHub do ramo	Pull requests do GitHub	URL de SSH [1]	Nome do ramo
Merge request de GitLab do fork	Merge requests do GitLab	vazio	vazio
Merge request de GitLab do ramo	Merge requests do GitLab	URL de SSH [1]	Nome do ramo
Merge request de Gitea do fork	Pull requests do Gitea	vazio	vazio
Merge request de Gitea do ramo	Pull requests do Gitea	URL de SSH [1]	Nome do ramo
Merge request de Pagure do fork	Merge requests do Pagure	vazio	vazio
Merge request de Pagure do ramo	Merge requests do Pagure	URL de SSH [1]	Nome do ramo
Solicitação pull do Azure DevOps a partir do fork	Pull requests do Azure DevOps	vazio	vazio
Solicitação pull do Azure DevOps a partir do branch	Pull requests do Azure DevOps	URL de SSH [1]	Nome do ramo
Revisão Gerrit	Pedidos de revisão Gerrit	URL de SSH	Nome do ramo alvo (opcional)
Pull request de Bitbucket Server do fork	Pull requests do Bitbucket Data Center	vazio	vazio
Pull request de Bitbucket Data Center do ramo	Pull requests do Bitbucket Data Center	URL de SSH [1]	Nome do ramo
Pull request de Bitbucket Cloud do fork	Pull requests do Bitbucket Cloud	vazio	vazio
Pull request de Bitbucket Cloud do ramo	Pull requests do Bitbucket Cloud	URL de SSH [1]	Nome do ramo

GitHub¶

Acesso do repositório GitHub¶

Aplicação GitHub Hosted Weblate¶

No Hosted Weblate, a configuração recomendada é conectar a aplicação Hosted Weblate do espaço de trabalho Weblate onde o seu projeto reside. Utilize o fluxo Conectar conta GitHub, instale a Aplicação no utilizador GitHub ou organização que possui os seus repositórios, garanta-lhe acesso aos repositórios que pretende traduzir, e importe componentes da conta de GitHub conectada.

O fluxo de trabalho do backend da Aplicação utiliza tokens de acesso de instalação GitHub para clonar, dar push de ramos de tradução, criar pull requests, e receber notificações. Não precisa de convidar o utilizador Hosted Weblate GitHub weblate ou configure um webook de um repositório separado para componentes importados desta maneira.

Utilize o utilizador Hosted Weblate GitHub weblate apenas quando configura intencionalmente pushes SSH diretos fora do fluxo de trabalho da Aplicação GitHub, veja Acessando repositórios do Hosted Weblate.

HTTPS com token de acesso pessoal¶

For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Repositório do código-fonte.

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Para utilizar esta abordagem:

Crie um token de acesso pessoal conforme descrito em Criar um token de acesso para o uso na linha de comando.
Inclua o token no seu URL do repositório: https://username:token@github.com/owner/repo.git.

Isto é adequado quando está a começar com o Weblate ou a trabalhar com um único repositório.

SSH com um utilizador dedicado¶

For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in Repositório do código-fonte, for example git@example.com:group/project.git.

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Isto também evita restrições de fornecedor na regra de reutilização da chave SSH. Alguns sites de hospedagem de código permitem uma chave SSH pública que seja adicionada apenas uma vez, ou que um utilizador único ou entrada de chave de implementação. Manter a chave SSH do Weblate em um utilizador dedicado permite que o utilizador seja concedido acesso a múltiplos repositórios sem reutilizar a chave em vários sítios.

This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.

On Hosted Weblate, use provider integrations where available. For GitHub, the recommended setup is the Hosted Weblate app. For direct SSH access on supported code hosting sites, use the hosted weblate user, see Acessando repositórios do Hosted Weblate.

Para o GitHub, crie um utilizador dedicado, por exemplo weblate-bot, e use URLs SSH do GitHub para os seus repositórios, por exemplo git@github.com:owner/repo.git.

No Hosted Weblate, utilize este fluxo de trabalho utilizador SSH apenas para dar push direto SSH fora do fluxo de trabalho da aplicação Hosted Weblate.

Nota

U usar o GitHub para pedidos de integração, a configuração Ramo do push afeta o comportamento: se não for definido, o projeto é bifurcado e as mudanças são submetidas através de uma bifurcação. Se definido, mudanças são enviadas para o repositório fonte e do ramo escolhido.

Notificações GitHub¶

O Weblate vem com suporte nativo ao GitHub.

Se está a usar o Hosted Weblate, utilize a aplicação Hosted Weblate do fluxo Weblate Conectar conta GitHub. Usa os webhook da Aplicação GitHub, por isso não precisa de configurar um Webhook separado no GitHub. Componentes importados da conta de GitHub conectada também usam a Aplicação para acesso de repositório e pull requests, sem convidar o utilizador Hosted Weblate weblate GitHub.

A Aplicação de legado Hosted Weblate é mantida apenas para configurações apenas de webhook. Utilize-o apenas quando precisa que a aplicação legada entregue notificações GitHub para o Hosted Weblate.

Para Weblate auto-hospedado, registe a Aplicação GitHub usando o fluxo de registo dentro da aplicação descrito abaixo. O Weblate gera o manifesto da Aplicação, o GitHub retorna as credenciais, e elas são armazenados na base de dados - não há configuração baseada em definições.

Registar a Aplicação GitHub para o Weblate¶

A maneira mais rápida de adicionar a Aplicação GitHub é deixar o Weblate gerar um manifesto da Aplicação GitHub com as permissões corretas, eventos, e URL de webhook pré-preenchidos:

Inicie sessão no Weblate com uma conta que têm acesso de gestão.
Abra Gerir → Instalações VCS → Registar Aplicação Weblate GitHub.
Preencha o formulário. O anfitrião GitHub tem o valor predefinido de github.com; mude-o para o seu nome GitHub Enterprise se necessário. Deixe Organização em branco para registar a Aplicação sob a sua conta pessoal, ou insira uma abreviação da organização para registá-la sob essa organização.
Clique em Continuar para o GitHub e confirme na página Criar Aplicação GitHub (ainda pode renomear a aplicação aí).
O GitHub redireciona-o de volta ao Weblate, que troca o código temporário pelo ID da Aplicação, chave privada, segredo webhook, e abreviação e armazena-os na base de dados. O botão Conectar conta GitHub está disponível logo a seguir.

O manifesto exige as permissões e subscrições de evento que o Weblate precisa (Contents e Pull requests leitura/escrita, Metadata apenas leitura, Organization administration apenas leitura, Workflows leitura/escrita, e a Installation, Meta e eventos Push), e define a função de chamada de retorno, e URLs de configuração e por integração automaticamente, para que a configuração manual da Aplicação GitHub seja necessária. O GitHub fornece os eventos Instalação e Repositórios de Instalação para todas as Aplicações de GitHub por predefinição.

O GitHub apenas oferece contas onde o utilizador com sessão iniciada pode instalar ou pedir a aplicação. Se uma organização não é mostrada durante o fluxo de instalação, verifique o papel do utilizador na organização e as restrições de instalação de organização da Aplicação GitHub. Em GitHub.com, aplicações públicas podem ser instaladas em outras contas; aplicações privadas só podem ser instaladas na conta que possui a aplicação.

A conectar a um espaço de trabalho¶

As contas de GitHub conectadas estão vinculadas a um espaço de trabalho Weblate. Um utilizador com direitos de administração de projeto para qualquer projeto em um espaço de trabalho pode conectar uma conta GitHub nesse espaço de trabalho. Após conectar, cada projeto no espaço de trabalho pode importar componentes de repositórios que a instalação da aplicação tenha acesso. Para instalações de organização, o Weblate verifica que o utilizador install-time GitHub pode administrar a instalação da organização.

Projetos que não estão em um espaço de trabalho não podem conectar-se a uma instalação de Aplicação GitHub.

Componentes importados através da Aplicação GitHub usam o backend VCS GitHub (através da aplicação Weblate GitHub). O UI das definições de componente mantêm o URL do diretório apenas em leitura para prevenir credenciais fornecidos pela Aplicação de serem redirecionados para um repositório não relacionado.

URL do Webhook da Aplicação¶

Cada integração de Aplicação GitHub registada tem o seu URL webhook que contém um token opaco que identifica de forma única uma integração:

https://weblate.example.com/hooks/integrations/<webhook_token>/

Se não está a utilizar a Aplicação GitHub, adicione o webhook do Weblate nas configurações do repositório (Webhooks) para receber notificações em cada push para um repositório GitHub, como mostrado na imagem abaixo:

A Payload URL consiste na sua URL do Weblate anexada por /hooks/github/, por exemplo, para o serviço Hosted Weblate, é https://hosted.weblate.org/hooks/github/.

Pode deixar outros valores nas configurações predefinidas. O Weblate pode lidar com ambos os tipos de conteúdo e consome apenas o evento push.

Veja também

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 que o backend GitHub cria pull requests. Este último não é necessário se for apenas para aceder a repositórios Git.

Para criar pull requests, selecione GitHub enquanto Sistema de controlo de versões e configure GITHUB_CREDENTIALS. Para o GitHub.com, utilize api.github.com como anfitrião da API. O token tem que permitir que o Weblate leia e escreva conteúdos de repositório e crie pull requests. Se o Weblate deve bifurcar diretórios privados, o token também poderá precisar de acesso de administração.

GitLab¶

Acesso de repositório GitLab¶

HTTPS com token de acesso pessoal ou de projeto¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Para o GitLab, o token precisa do escopo write_repository para ser possível enviar mudanças para o repositório. O token de acesso de projeto requer o papel Desenvolvedor para enviar.

O URL necessita de conter um nome de utilizador. Para um token de acesso pessoal, isto é o nome de utilizador efetivo: https://user:personal_access_token@gitlab.com/example/example.git. Para tokens de acesso de projeto, podem ser um valor em branco: https://example:project_access_token@gitlab.com/example/example.git.

Nota

As regras para usar tokens de acesso de projeto mudaram entre lançamentos do GitLab, o valor que não está em branco é o requisito atual, mas versões mais antigas têm diferentes expectativas (nome do projeto, nome de utilizador do robô). Verifique a documentação GitLab correspondente à sua versão se não tem certeza.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Para o GitLab, crie um utilizador dedicado e utilize URLs SSH do GitLab, por exemplo git@gitlab.com:group/project.git.

Notificações GitLab¶

O Weblate tem suporte para ganchos do GitLab. Adicione um webhook de projeto com destino a URL /hooks/gitlab/ na instalação do Weblate, por exemplo, https://hosted.weblate.org/hooks/gitlab/.

Soluções de problemas

Verifique Histórico de pedidos webhook GitLab se os webhooks são entregues.
A carga da resposta contém informação sobre componentes correspondentes.

Veja também

Merge requests do GitLab¶

Isto 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 que o backend GitLab cria um pedido de fusão.

Para criar merge request, selecione GitLab enquanto Sistema de controlo de versões e configure GITLAB_CREDENTIALS.

A configuração Ramo do push afeta onde o Weblate envia mudanças antes de abrir o merge request. Se não está definido, é criado um fork do projeto e é feito um push das alterações através do fork. Se está definido, os pushes são feitos para o repositório upstream e para o ramo escolhido.

Gitea, Forgejo, e Codeberg¶

Acesso de repositório Gitea, Forgejo, e Codeberg¶

HTTPS com um token de acesso¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Para repositórios Hosted Weblate no Codeberg, adicione o utilizador weblate hospedado onde acesso de escrita é necessário, veja Acessando repositórios do Hosted Weblate.

Notificações Gitea¶

Weblate tem suporte para webhooks do Gitea. Adicione um Gitea Webhook para o evento Push events com destino ao URL /hooks/gitea/ na instalação do Weblate, por exemplo, https://hosted.weblate.org/hooks/gitea/. Isso pode ser feito no Webhooks em Settings do repositório.

Veja também

Notificações Forgejo¶

Weblate tem suporte para webhooks do Forgejo. Adicione um Webhook Forgejo para o evento Eventos push com destino ao URL /hooks/forgejo/ na instalação do Weblate, por exemplo https://hosted.weblate.org/hooks/forgejo/. Isso pode ser feito no Webhooks em Definições do repositório.

Veja também

Pull requests do Gitea¶

Added in version 4.12.

Isto 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.

Para criar pull requests, selecione Gitea enquanto Sistema de controlo de versões e configure GITEA_CREDENTIALS.

Bitbucket¶

Repositórios de acesso do Bitbucket¶

HTTPS com um token de acesso¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

O Hosted Weblate tem um utilizador weblate dedicado para acesso Bitbucket, veja Acessando repositórios do Hosted Weblate.

Para dar push diretamente, utilize Git ou Mercurial com URL de submissão do repositório.

Notificações Bitbucket¶

O Weblate tem suporte para webhooks do Bitbucket. Adicione um webhook que aciona no push do repositório, com destino a URL /hooks/bitbucket/ na instalação do Weblate por exemplo, https://hosted.weblate.org/hooks/bitbucket/.

Veja também

Pull requests do Bitbucket Data Center¶

Added in version 4.16.

Isto 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 que o backend Bitbucket Data Center cria pull requests.

Para criar pull requests, selecione Bitbucket Data Center enquanto Sistema de controlo de versões e configure BITBUCKETSERVER_CREDENTIALS.

Pull requests do Bitbucket Cloud¶

Added in version 5.8.

Isto 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 o backend Bitbucket Cloud cria um pull request.

Para criar pull requests, selecione Bitbucket Cloud enquanto Sistema de controlo de versões e configure BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Acesso de repositório Azure Repos¶

HTTPS com um token de acesso¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Utilize o clone HTTPS do URL mostrado pelo Azure Repos para este repositório.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Utilize o URL SSH mostrado pelo Azure Repos para o repositório.

Notificações Azure Repos¶

O Weblate tem suporte para webhooks do Azure Repos. Adicione um webhook para evento Código enviado com destino para URL /hooks/azure/ na instalação do Weblate por exemplo, https://hosted.weblate.org/hooks/azure/. Isto pode ser feito no Ganchos de serviço em Configurações do projeto.

Veja também

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 que o backend Azure DevOps cria pull requests. Este último não é necessário para apenas aceder repositórios Git.

Para criar pull requests, selecione Azure DevOps enquanto Sistema de controlo de versões e configure AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Acesso de repositório Pagure¶

HTTPS com um token de acesso¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Pagure notifications¶

O Weblate tem suporte para ganchos Pagure. Adicione um webhook com destino a URL /hooks/pagure/ na instalação do Weblate por exemplo, https://hosted.weblate.org/hooks/pagure/. Isso pode ser feito em Web-hooks em Project options:

Veja também

Merge requests do Pagure¶

Added in version 4.3.2.

Isto 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.

Para criar merge requests, selecione Pagure enquanto Sistema de controlo de versões e configure PAGURE_CREDENTIALS.

Outros fluxos de trabalho¶

Acesso de repositório Gitee¶

HTTPS com um token de acesso¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH com um utilizador dedicado¶

Configure URL de submissão do repositório only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Fazendo push das alterações do Weblate.

Notificações Gitee¶

O Weblate tem suporte para webhooks Gitee. Adicione um WebHook para o evento Push com destino para URL /hooks/gitee/ na instalação do Weblate por exemplo, https://hosted.weblate.org/hooks/gitee/. Isso pode ser feito em WebHooks sob Management do repositório.

Veja também

Pedidos de revisão Gerrit¶

Suporte do 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 definição opcional Ramo do push seleciona o ramo alvo a partir da revisão Gerrit. Deixe-o vazio para usar Ramo do repositório. Use o nome curto do ramo, como main; Weblate and git-review envia a revisão para refs/for/<branch> automaticamente. O Gerrit envia opções que podem ser adicionadas depois de % em qualquer uma das configurações, por exemplo main%topic=l10n. O Gerrit interpreta estas opções enquanto as contas de Weblate Gerrit configuradas e aplica as suas próprias permissões.

A documentação Gerrit tem os detalhes sobre a configuração necessária para configurar tais repositórios. Não há definição de credenciais de hospedagem de código separada para este backend.

Credenciais do Docker¶

Para instalações Docker, credenciais de API de hospedagem de código também podem ser fornecidas através de variáveis de ambiente, consulte Credenciais de sites de hospedagem de código.