Code-hosting integrations¶

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 or merge 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.
- Para repositorios GitHub en Hosted Weblate, utilice el Hosted Weblate app desde el flujo Weblate Conexión de cuenta GitHub. El App proporciona acceso al repositorio Hosted Weblate sin invitar el usuario hospedado weblate..
- Para otros repositorios de Hosted Weblate, y para subida externa directa en SSH el flujo de trabajo GitHub App, y el usuarios hospedado de weblate 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 Accessing repositories on code-hosting sites (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¶

GitHub App de Weblate Hospedado¶

En Hosted Weblate, la configuración recomendada es conectar la aplicación Hosted Weblate desde el espacio de trabajo de Weblate donde se encuentra tu proyecto. Sigue el flujo de Conectar cuenta de GitHub, instala la aplicación en el usuario u organización de GitHub que posee tus repositorios, concédele acceso a los repositorios que deseas traducir e importa los componentes desde la cuenta de GitHub conectada.

El flujo de trabajo respaldado por la aplicación utiliza vales de acceso de instalación de GitHub para clonar, enviar ramas de traducción, crear solicitudes de extracción y recibir notificaciones entrantes. No es necesario invitar al usuario de Hosted GitHub weblate ni configurar un webhook de repositorio independiente para los componentes importados de esta manera.

Utilice el Weblate Hospedado weblate del usuario de GitHub solo cuando configura intencionalmente SSH directo subido fuera del flujo de trabajo GitHub App, consulte 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.

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.

En Hosted Weblate, utilice este flujo de trabajo de usuario SSH solo para envíos SSH directos fuera de lo recomendado Flujo de Weblate app hospedado.

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 hospedado desde el flujo de la Conexión a cuenta GitHub. Esto utiliza los ganchos web de GitHub, tales que no necesite configurar un Webhook separado en GitHub. Los componentes importados desde la cuenta GitHub conectada además utilizan la App para acceder al repositorio y subir solicitudes, sin invitar al usuario de GitHub que el Weblate Hospede weblate.

La app heredada Weblate Hospedada es mantenida solo para instalaciones de ganchos web existentes. Utilícela solo cuando necesite que la app heredada entregue notificaciones en GitHub al Weblate Hospedado.

Para Weblate autoalojado, registre la aplicación de GitHub utilizando el proceso de registro integrado que se describe a continuación. Weblate genera el manifiesto de la aplicación, GitHub devuelve las credenciales y estas se almacenan en la base de datos; no existe ninguna configuración basada en ajustes.

Registrando el GitHub App desde Weblate¶

La forma más rápida de agregar la aplicación de GitHub es dejar que Weblate genere un manifiesto de la aplicación de GitHub con los permisos, eventos y URL de webhook correctos precargados:

Inicie a Weblate con una cuenta que ha gestionado acceso.
Open Manage → Code-hosting connections → Register Weblate GitHub App.
Rellene en el formulario. El host GitHub por defecto para github.com; cámbielo al nombre de host GitHub Enterprise si es necesario. Deje la Organization en blanco para registrar la App bajo su cuenta personal, o introduzca una indicación de organización para registrarlo bajo esta org.
Pulse Continuar a GitHub y confirme en la página Crear App de GitHub de GitHub (puede renombrar aún la App allí).
GitHub redirige a Weblate, que intercambia el código temporal por el ID de la aplicación, la clave privada, el secreto del webhook y el slug, y los almacena en la base de datos. El botón Conectar cuenta de GitHub está disponible inmediatamente después.

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-app 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 solo ofrece cuentas donde el usuario registrado puede instalar o solicitar la aplicación. Si no se muestra una organización durante el proceso de instalación, verifique el rol del usuario en la organización y las restricciones de instalación de aplicaciones de GitHub de dicha organización. En GitHub.com, las aplicaciones públicas se pueden instalar en otras cuentas; las aplicaciones privadas solo se pueden instalar en la cuenta propietaria de la aplicación.

Conectando un espacio trabajo¶

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 GitHub App installation has access to. For organization accounts, Weblate verifies that the install-time GitHub user can administer the organization installation.

Projects that are not in a workspace cannot connect a GitHub account through the GitHub App.

Los componentes importados a través del flujo de la aplicación de GitHub utilizan el dedicado VCS (vía Weblate GitHub app) en segundo plano. La interfaz de configuración del componente mantiene la URL del repositorio en modo de solo lectura para evitar que las credenciales emitidas por la aplicación se redirijan a un repositorio no relacionado.

URL de gancho a App¶

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

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

Si no estás utilizando GitHub App, 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.

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

For Hosted Weblate repositories on GitLab, add the hosted weblate user with the required repository permissions, see Acceder repositorios desde Hosted Weblate.

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.

For Hosted Weblate repositories on Codeberg, add the hosted weblate user with the required repository permissions, 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.

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.

For Hosted Weblate repositories on Bitbucket, add the hosted weblate user with the required repository permissions, see 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.

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.

Credenciales de Docker¶

For Docker installations, code-hosting API credentials can also be provided through environment variables, see Code-hosting sites credentials.