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.
- En un Hosted Weblate, agrega el usuario del weblate hospedado donde esté disponible, consulte 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¶

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 the hosted weblate user on supported code hosting sites, 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.

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.

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.

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

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

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.

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.

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

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.

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.

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¶

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.

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. Gerrit push options can be appended after % in either setting, for example main%topic=l10n. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions.

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.