Integración de hospedaje de código¶

Weblate integrates with code hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull requests.

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.
- En un Hosted Weblate, agrega el usuario del weblate hospedado donde esté disponible, consulte Acceder repositorios desde Hosted Weblate.
- For self-hosted Weblate, create a dedicated code hosting user and grant access using Weblate’s SSH key or an HTTPS token, see 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.
Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have Activar actuadores enabled.
Decide how Weblate should push translations back:
- Use Git or Mercurial and URL de envío al repositorio to push directly.
- Use a provider-specific VCS backend, such as GitHub or GitLab, to create pull or merge requests. These backends need API credentials in the Weblate settings.
Optionally set Rama a la que enviar when Weblate should push to a branch in the upstream repository instead of using a fork where supported.

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.

If you do not want changes to be pushed automatically, you can push manually under Repository maintenance or using the API via 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¶

HTTPS with personal access token¶

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 with a dedicated user¶

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 the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted Weblate.

For GitHub, create a dedicated user, for example weblate-bot, and use GitHub SSH URLs for your repositories, for example git@github.com:owner/repo.git.

Este enfoque también se utiliza para Hosted Weblate, que cuenta con un usuario dedicado weblate para tal propósito.

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.

Si utilizas Hosted Weblate, lo recomendado es instalar la aplicación Weblate. Esta aplicación envía notificaciones de GitHub a Hosted Weblate, por lo que no necesitas configurar un Webhook aparte en GitHub. Sin embargo, no otorga automáticamente a Hosted Weblate acceso de escritura al repositorio. Para enviar los cambios, aún necesitas agregar al usuario de GitHub weblate de Hosted Weblate como colaborador con acceso de escritura; consulta Acceder repositorios desde Hosted Weblate.

Si no estás utilizando la aplicación, agrega el gancho webhook de Weblate en los ajustes del repositorio (Webhooks) para recibir notificaciones en cada envío a un repositorio de GitHub, como se muestra en la imagen a continuación:

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.

To create pull requests, select GitHub as Sistema de control de versiones and configure GITHUB_CREDENTIALS. For GitHub.com, use api.github.com as the API host. The token must allow Weblate to read and write repository contents and create pull requests. If Weblate should fork private repositories, the token might also need administration access.

GitLab¶

Acceso a repositorios en GitLab¶

HTTPS with personal or project access token¶

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.

For GitLab, the token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.

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 with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted Weblate.

For GitLab, create a dedicated user and use GitLab SSH URLs, for example git@gitlab.com:group/project.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.

To create merge requests, select GitLab as Sistema de control de versiones and configure 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, and Codeberg¶

Gitea, Forgejo, and Codeberg repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted Weblate.

For Hosted Weblate repositories on Codeberg, add the hosted weblate user where write access is needed, see 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.

To create pull requests, select Gitea as Sistema de control de versiones and configure GITEA_CREDENTIALS.

Bitbucket¶

Bitbucket repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted Weblate.

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

To push directly, use Git or Mercurial with 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¶

Azure Repos repository access¶

HTTPS with an access token¶

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.

Use the HTTPS clone URL shown by Azure Repos for the repository.

SSH with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted Weblate.

Use the SSH URL shown by Azure Repos for the repository.

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.

To create pull requests, select Azure DevOps as Sistema de control de versiones and configure AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted 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.

To create merge requests, select Pagure as Sistema de control de versiones and configure PAGURE_CREDENTIALS.

Otros flujos¶

Gitee repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Acceder repositorios desde Hosted 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¶

Gerrit support adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

The optional Rama a la que enviar setting selects the target branch for the Gerrit review. Leave it empty to use Rama del repositorio. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Do not include Gerrit push options such as %submit or %l=Code-Review+2 in the branch name.

The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code hosting credential setting for this backend.

Docker credentials¶

For Docker installations, code hosting API credentials can also be provided through environment variables, see Credenciales de sitios de alojamiento de código.