Integraciones de hospedaje para código¶

Weblate se integra con los sitios de alojamiento de código en varios aspectos distintos: acceso al repositorio, recepción de notificaciones y envío de traducciones. La configuración exacta depende de si utilizas Hosted Weblate o gestionas tu propia instancia de Weblate, así como de si Weblate debe enviar las traducciones directamente o crear solicitudes de extracción.

Utilice esta página como un listado de verificación orientada al proveedor. Las páginas de ajustes individuales siguen siendo la referencia canónica para la sintaxis de ajustes.

Descripción general de configuración¶

Concede acceso a Weblate para el repositorio.
- For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. The App gives Hosted Weblate repository access without inviting the hosted weblate user.
- For other Hosted Weblate repositories, and for direct SSH pushes outside the GitHub App workflow, add the hosted weblate user where it is available, see Acceder repositorios desde Hosted Weblate.
- Para Weblate hospedado para sí, crea un usuario dedicado al hospedaje de código y concédele acceso mediante la clave SSH de Weblate o un vale de HTTPS; consulte Acceder a repositorios en sitios de alojamiento de código (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configura Repositorio de código fuente tal que Weblate pueda clonar el repositorio.
Configura las notificaciones entrantes para que Weblate introduzca los cambios poco después de una inserción. El gancho del repositorio o la aplicación debe apuntar a la URL del gancho Weblate correspondiente, y el proyecto debe tener Activar actuadores habilitado.
Decide cómo debería Weblate introducir traducciones de nuevo:
- Utilice Git o Mercurial y URL de envío al repositorio para enviar directamente.
- Utiliza un backend de VCS específico de cada proveedor, como GitHub o GitLab, para crear solicitudes de extracción o de fusión. Estos backends requieren credenciales del API en los ajustes de Weblate.
Opcionalmente establezca Rama a la que enviar cuando Weblate deba introducir en una rama en el repositorio en desarrollo en lugar de usar una bifurcación donde esté admitido.

Enviar cambios efectuados en Weblate¶

Cada componente de traducción puede tener una URL de envío configurada (consulte URL de envío al repositorio ), y en ese caso Weblate podrá enviar cambios al repositorio remoto . Weblate puede configurarse para enviar cambios automáticamente en cada consignación; esto es habilitado por defecto, consulte Enviar al consolidar.

Si no desea que los cambios se introduzcan automáticamente, puede efectuar la inserción manualmente en Mantenimiento de repositorio o mediante el API con wlc push.

En caso de que no desee notificaciones push directas por Weblate, hay apoyo para revisiones de Solicitudes de incorporación de GitHub, Solicitudes de fusión de GitLab, Solicitudes de incorporación de Gitea, Solicitudes de fusión de Pagure, Solicitud de incorporación Azure DevOps, o Solicitudes de revisión de Gerrit. Puedes activarlos eligiendo GitHub, GitLab, Gitea, Gerrit, Azure DevOps, o Pagure como Sistema de control de versiones en Configuración de componentes.

De manera general, están disponibles las opciones siguientes con Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center y Bitbucket Cloud:

Configuración deseada	Sistema de control de versiones	URL de envío al repositorio	Rama a la que enviar
No enviar	Git	vacío	vacío
Enviar directamente	Git	URL SSH	vacío
Enviar en una rama separada	Git	URL SSH	Nombre de rama
No enviar	Mercurial	vacío	vacío
Enviar directamente	Mercurial	URL SSH	vacío
Solicitud de extracción GitHub desde bifurcación	Solicitudes de incorporación de GitHub	vacío	vacío
Solicitud de extracción GitHub desde rama	Solicitudes de incorporación de GitHub	SSH URL [1]	Nombre de rama
Solicita fusión de GitLab desde bifurcación	Solicitudes de fusión de GitLab	vacío	vacío
Fusión GitLab solicitada desde rama	Solicitudes de fusión de GitLab	SSH URL [1]	Nombre de rama
Solicitud de fusión de Gitea desde la bifurcación	Solicitudes de incorporación de Gitea	vacío	vacío
Solicitud de fusión Gitea desde rama	Solicitudes de incorporación de Gitea	SSH URL [1]	Nombre de rama
Solicitud de fusión Pagure desde bifurcación	Solicitudes de fusión de Pagure	vacío	vacío
Solicitud de fusión Pagure desde rama	Solicitudes de fusión de Pagure	SSH URL [1]	Nombre de rama
Solicitud de fusión Azure DevOps desde bifurcación	Solicitud de incorporación Azure DevOps	vacío	vacío
Solicitud de extracción Azure DevOps desde rama	Solicitud de incorporación Azure DevOps	SSH URL [1]	Nombre de rama
Revisión de Gerrit	Solicitudes de revisión de Gerrit	URL SSH	Nombre de rama de destino (opcional)
Solicitud de extracción Bitbucket Data Center desde bifurcación	Solicitudes de incorporación al Centro de Datos Bitbucket	vacío	vacío
Solicitud de extracción Bitbucket Data Center desde rama	Solicitudes de incorporación al Centro de Datos Bitbucket	SSH URL [1]	Nombre de rama
Solicitud de extracción Bitbucket Cloud desde bifurcación	Solicitud de incorporación a BitBucket Cloud	vacío	vacío
Solicitud de extracción Bitbucket Cloud desde rama	Solicitud de incorporación a BitBucket Cloud	SSH URL [1]	Nombre de rama

GitHub¶

Acceso a repositorios en GitHub¶

Hosted Weblate GitHub App¶

On Hosted Weblate, the recommended setup is to connect the Hosted Weblate app from the Weblate workspace where your project lives. Use the Connect GitHub account flow, install the App on the GitHub user or organization that owns your repositories, grant it access to the repositories you want to translate, and import components from the connected GitHub account.

The App-backed workflow uses GitHub installation access tokens for cloning, pushing translation branches, creating pull requests, and receiving incoming notifications. You do not need to invite the Hosted Weblate weblate GitHub user or configure a separate repository webhook for components imported this way.

Use the Hosted Weblate weblate GitHub user only when you intentionally configure direct SSH pushes outside the GitHub App workflow, see Acceder repositorios desde Hosted Weblate.

HTTPS con vales de acceso personal¶

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 Repositorio de código fuente.

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 este enfoque:

Cree un vale de acceso personal como describió en Crear un vale de acceso para utilizar línea de comando.
Incluya el vale en su URL del repositorio: https://username:token@github.com/owner/repo.git.

Esto es adecuado cuando esté comenzando con Weblate o se trabaja con un único repositorio.

SSH con un usuario 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 Repositorio de código fuente, for example git@example.com:group/project.git.

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.

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 Acceder repositorios desde Hosted Weblate.

Para GitHub, crea un usuario dedicado, por ejemplo weblate-bot, y utiliza las URL SSH de GitHub para tus repositorios, por ejemplo git@github.com:owner/repo.git.

On Hosted Weblate, use this SSH-user workflow only for direct SSH pushes outside the recommended Hosted Weblate app workflow.

Nota

Al utilizar GitHub para solicitudes de extracción, la configuración Rama a la que enviar afecta al comportamiento: si no se establece, el proyecto se bifurca y los cambios se envían a través de una bifurcación. Si se establece, los cambios se envían al repositorio ascendente y a la rama elegida.

Notificaciones de GitHub¶

Weblate admite GitHub nativamente.

If you are using Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow. It uses GitHub App webhooks, so you do not need to configure a separate Webhook in GitHub. Components imported from the connected GitHub account also use the App for repository access and pull requests, without inviting the Hosted Weblate weblate GitHub user.

The Hosted Weblate legacy app is kept for existing webhook-only setups. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate.

For self-hosted Weblate, register the GitHub App using the in-app registration flow described below. Weblate generates the App manifest, GitHub returns the credentials, and they are stored in the database - there is no settings-based configuration.

Registering the GitHub App from Weblate¶

The fastest way to add the GitHub App is to let Weblate generate a GitHub App manifest with the correct permissions, events, and webhook URL pre-filled:

Sign in to Weblate with an account that has management access.
Open Manage → VCS Installations → Register Weblate GitHub App.
Fill in the form. The GitHub host defaults to github.com; change it to your GitHub Enterprise hostname if needed. Leave Organization blank to register the App under your personal account, or enter an organization slug to register it under that org.
Click Continue to GitHub and confirm on GitHub’s Create GitHub App page (you can still rename the App there).
GitHub redirects back to Weblate, which exchanges the temporary code for the App ID, private key, webhook secret, and slug and stores them in the database. The Connect GitHub account button is available immediately afterwards.

The manifest requests the permissions and event subscriptions Weblate needs (Contents and Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, and the Installation, Meta and Push events), and sets the callback, setup and per-integration webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the Installation and Installation repositories events to all GitHub Apps by default.

GitHub only offers accounts where the signed-in GitHub user can install or request the app. If an organization is not shown during the install flow, check the user’s organization role and the organization’s GitHub App installation restrictions. On GitHub.com, public apps can be installed on other accounts; private apps can only be installed on the account that owns the app.

Connecting a workspace¶

Connected GitHub accounts are bound to a Weblate workspace. A user with project administration rights for any project in a workspace can connect a GitHub account on that workspace. After connecting, every project in the workspace can import components from repositories the app installation has access to. For organization installations, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub App installation.

Components imported through the GitHub App flow use the dedicated GitHub (via Weblate GitHub app) VCS backend. The component settings UI keeps the repository URL read-only to prevent the App-issued credentials from being redirected to an unrelated repository.

App webhook URL¶

Each registered GitHub App integration has its own webhook URL containing an opaque token that uniquely identifies a single integration:

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

If you are not using a GitHub App, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

El Payload URL consiste en su URL Weblate adjuntada por /hooks/github/, por ejemplo para el servicio Hosted Weblate, esto es https://hosted.weblate.org/hooks/github/.

Puede dejar otros valores en parámetros por defecto. Weblate puede manipular ambos tipos de contenido y consume tan solo el suceso push).

Ver también

Solicitudes de incorporación de GitHub¶

Esto añade una capa delgada encima Git utilizando el API de GitHub para conceder empuje de cambios de traducción como solicitudes de incorporar, en vez de empujar directamente al repositorio.

Git envía los cambios directamente a un repositorio, mientras que el segundo plano de GitHub crea solicitudes de extracción. Esta última no es necesaria simplemente para acceder a los repositorios de Git.

Para crear solicitudes de extracción, selecciona GitHub como Sistema de control de versiones y configura GITHUB_CREDENTIALS. Para GitHub.com, utiliza api.github.com como host del API. El vale debe permitir que Weblate acceda a los contenidos del repositorio, cree solicitudes de extracción. Si Weblate debe bifurcar repositorios privados, el vale también podría necesitar acceso de administración.

GitLab¶

Acceso a repositorios en GitLab¶

HTTPS con vale de acceso personal o proyecto¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 GitLab, el vale necesita el ámbito write_repository para poder enviar cambios al repositorio. El vale de acceso del proyecto requiere el rol Desarrollador para subir cambios.

La URL debe contener un nombre de usuario. Para los vales de acceso personal, es el nombre de usuario real: https://user:personal_access_token@gitlab.com/example/example.git. Para los vales de acceso a proyectos, puede ser un valor que no esté en blanco https://example:project_access_token@gitlab.com/example/example.git.

Nota

Las reglas para usar vales de acceso a proyectos han cambiado entre las versiones de GitLab. El valor no vacío es el requisito actual, pero las versiones anteriores tenían expectativas diferentes (nombre del proyecto, nombre de usuario del bot). Si no estás seguro, consulta la documentación de GitLab correspondiente a tu versión.

SSH con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Para GitLab, cree un usuario dedicado y utilice URL de SSH de GitLab, por ejemplo git@gitlab.com:group/proyecto.git.

Notificaciones GitLab¶

Weblate tiene soporte para ganchos GitLab. Añade un gancho web del proyecto con destino a /hooks/gitlab/ URL en su instalación Weblate, por ejemplo https://hosted.weblate.org/hooks/gitlab/.

Solución de problemas

Compruebe el Historial de solicitudes de webhook de GitLab para ver si se han entregado los enganches de la web.
La carga útil de respuesta contiene información sobre los componentes coincidentes.

Ver también

Solicitudes de fusión de GitLab¶

Esto añade una capa fina encima de Git utilizando el API de GitLab para conceder cambios de traducciones empujadas como solicitudes de fusión en lugar de empujar directamente al repositorio.

No es necesario usar esto para acceder a los repositorios de Git; ordinariamente el comando Git funciona igual; la única diferencia radica en como se proporciona a un repositorio sea gestionado. Con los cambios de Git son enviados directamente al repositorio, mientras que con el backend de GitLab se crea una solicitud de fusión.

Para crear fusionar peticiones, selecciona GitLab como Sistema de control de versiones y configurar GITLAB_CREDENTIALS.

La configuración Rama a la que enviar afecta donde Weblate suba cambios antes de abrir la solicitud de fusión. Si no está establecido, el proyecto se bifurca y los cambios se envían a través de una bifurcación. Si está establecido, los cambios son subidos al repositorio en desarrollo y a la rama elegida.

Gitea, Forgejo y Codeberg¶

Acceso a repositorios en Gitea, Forgejo, y Codeberg¶

HTTPS con vale de acceso¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Para los repositorios de Hosted Weblate en Codeberg, añada el usuario weblate donde se necesita acceso de escritura, consulte Acceder repositorios desde Hosted Weblate.

Notificaciones Gitea¶

Weblate tiene soporte para ganchos web de Gitea. Agrega un Gancho de Gitea para el suceso Notificar automáticamente sucesos con destino a la URL /hooks/gitea/ en tu instalación de Weblate, por ejemplo https://hosted.weblate.org/hooks/gitea/. Esto se puede hacer en Webhooks bajo el repositorio Ajustes.

Ver también

Notificaciones Forgejo¶

Weblate tiene soporte para ganchos web de Forgejo. Agrega un Gancho de Forgejo para el suceso Notificar automáticamente sucesos con destino a la URL /hooks/forgejo/ en tu instalación de Weblate, por ejemplo https://hosted.weblate.org/hooks/forgejo/. Esto se puede hacer en Webhooks bajo el repositorio Ajustes.

Ver también

Solicitudes de incorporación de Gitea¶

Added in version 4.12.

Esto agrega una capa fina encima de Git utilizando el API de Gitea para conceder extraer cambios de traducción como solicitudes de extracción en lugar de empujar directamente al repositorio.

No hay necesitad de utilizar esto para acceder a los repositorios de Git, ordinariamente Git funciona de la misma manera, la única diferente es como proporcionar a un repositorio esté manipulado. Con los cambios de Git son proporcionados directamente para el repositorio, mientras Gitea crea peticiones de incorporar.

Para crear solicitudes de extracción, selecciona Gitea como Sistema de control de versiones y configura GITEA_CREDENTIALS.

Bitbucket¶

Acceso a repositorios en Bitbucket¶

HTTPS con vale de acceso¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Hosted Weblate tiene un usuario weblate dedicado para acceso Bitbucket, consulte Acceder repositorios desde Hosted Weblate.

Para introducir directamente, utiliza Git o Mercurial junto con URL de envío al repositorio.

Notificaciones Bitbucket¶

Weblate tiene soporte para ganchos web de Bitbucket. Agregue un gancho web que se active al enviar el repositorio, con destino a la URL /hooks/bitbucket/ en su instalación de Weblate, por ejemplo https://hosted.weblate.org/hooks/bitbucket/.

Ver también

Solicitudes de incorporación al Centro de Datos Bitbucket¶

Added in version 4.16.

Esto añade una capa fina sobre Git utilizando el API del Centro de Datos Bitbucket para subir los cambios de la traducción como solicitud de subirá en lugar de subirlas directamente al repositorio.

Advertencia

Esto no mantiene el API de Bitbucket Cloud.

No hay necesidad para utilizar esto para acceder a repositorios Git, lo ordinario de Git funciona de la misma manera, la única diferencia es cómo se gestiona el envío a un repositorio. Con los cambios en Git son gestiona directamente el repositorio, mientras que Centro de Datos Bitbucket crea solicitudes de extracción.

Para crear solicitudes pull, seleccione Bitbucket Data Center como Sistema de control de versiones y configure BITBUCKETSERVER_CREDENTIALS.

Solicitud de incorporación a BitBucket Cloud¶

Added in version 5.8.

Esto añade una capa final sobre Git utilizando el API de Bitbucket Cloud para permitir enviar los cambios de traducción como solicitudes de extracción en lugar de enviarlos directamente al repositorio.

Advertencia

Esto es diferente desde el API de Bitbucket Data Center.

No hay necesidad para utilizar esto en acceso a los repositorios Git, normalmente el Git funciona igual, la única diferencia es cómo se gestiona el envío a un repositorio. Con Git, los cambios se envían directamente al repositorio, mientras que el backend de Bitbucket Cloud crea una solicitud de extracción.

para crear solicitudes de pull, seleccione Bitbucket Cloud como Sistema de control de versiones y configure BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Acceso a repositorios en Azure¶

HTTPS con vale de acceso¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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.

Utilice la URL de clones HTTPS mostrada por Azure Repos para el repositorio.

SSH con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Utilice la URL SSH mostrada por Azure Repos para el repositorio.

Notificaciones de Repod Azure¶

Weblate tiene soporte para ganchos de web en Azure Repos. Agregue un gancho web para el suceso Código enviado con destino a la URL /hooks/azure/ en su instalación de Weblate, por ejemplo https://hosted.weblate.org /hooks/azure/. Esto se puede hacer en Ganchos de servicio en Configuración del proyecto .

Ver también

Solicitud de incorporación Azure DevOps¶

Esto añade una fina capa sobre Git utilizando el API de Azure DevOps para permitir enviar los cambios de traducción como solicitudes de extracción, en lugar de enviarlos directamente al repositorio.

Git envía los cambios directamente a un repositorio, mientras que el backend Azure DevOps crea solicitudes de extracción. Esta última no es necesaria simplemente para acceder a los repositorios de Git.

Para crear solicitudes de extracción, selecciona Azure DevOps como Sistema de control de versiones y configura AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Acceso a repositorios en Pagure¶

HTTPS con vale de acceso¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Notificaciones Pagure¶

Weblate tiene soporte para ganchos Pagure. Añada un webhook con destino a /hooks/pagure/ URL en su instalación Weblate, por ejemplo https://hosted.weblate.org/hooks/pagure/. Esto se puede hacer en Activar Web-hooks bajo Opciones del proyecto:

Ver también

Solicitudes de fusión de Pagure¶

Added in version 4.3.2.

Esto añade una fina capa sobre Git utilizando el API de Pagure para permitir enviar los cambios de traducción como solicitudes de fusión en lugar de enviarlos directamente al repositorio.

No es necesario utilizar esto para acceder a los repositorios Git, el Git ordinario funciona igual, la única diferencia es cómo se gestiona el envío a un repositorio. Con Git, los cambios se envían directamente al repositorio, mientras que el Pagure crea una solicitud de fusión.

Para crear solicitudes de fusión, selecciona Pagure como Sistema de control de versiones y configura PAGURE_CREDENTIALS.

Otros flujos¶

Acceso a repositorios en Gitee¶

HTTPS con vale de acceso¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en 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 con un usuario dedicado¶

Configure URL de envío al repositorio only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Enviar cambios efectuados en Weblate.

Notificaciones Gitee¶

Weblate tiene soporte para los ganchos web de Gitee. Añade un WebHook para el suceso Push con destino a la URL /hooks/gitee/ en tu instalación de Weblate, por ejemplo https://hosted.weblate.org/hooks/gitee/. Esto puede hacerse en WebHooks bajo el repositorio Management.

Ver también

Solicitudes de revisión de Gerrit¶

El soporte Gerrit añade una capa fina sobre Git utilizando la herramienta git-review para subir cambios de traducción como solicitudes de revisión de Gerrit, en lugar de enviarlos directamente al repositorio.

La configuración opcional Rama a la que enviar selecciona la rama objetivo para la revisión de Gerrit. Djala vacía para utilizar Rama del repositorio. Utiliza el nombre corto de la rama, como main; Weblate y git-review envían la revisión automáticamente a refs/for/<rama>. Las opciones de subida de Gerrit puede ser aprobadas tras % en cada ajuste, por ejemplo main%topic=l10n. Gerrit interpreta estas opciones como la cuenta Gerrit de Weblate y aplica sus propios permisos.

La documentación de Gerrit tiene los detalles sobre la configuración necesaria para la puesta en marcha de dichos repositorios. No hay ningún código separado hospedando para ajuste credencial para este backend.

Credenciales de Docker¶

Para instalaciones de Docker, las credenciales del código donde hospeda el API además puede ser proporcionado a través de variables del entorno, consulte Credenciales de sitios de alojamiento de código.