# Integraciones de alojamiento 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 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 1. Concede acceso a Weblate para el repositorio. * Para repositorios GitHub en Hosted Weblate, utilice el [Hosted Weblate app](https://github.com/apps/hosted-weblate) 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](https://docs.weblate.org/es/latest/vcs.md#hosted-push). * Para Weblate hospedado para sí, crea un usuario dedicado al código‐hospedado y concédele acceso mediante la clave SSH de Weblate o un vale de HTTPS; consulte [Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)](https://docs.weblate.org/es/latest/vcs.md#vcs-repos-code-hosting). 2. Configura [Repositorio de código fuente](https://docs.weblate.org/es/latest/admin/projects.md#component-repo) tal que Weblate pueda clonar el repositorio. 3. 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](https://docs.weblate.org/es/latest/admin/projects.md#project-enable-hooks) enabled. Component [Repositorio de código fuente](https://docs.weblate.org/es/latest/admin/projects.md#component-repo) must match a repository URL from the webhook payload; see [Matching webhook targets](https://docs.weblate.org/es/latest/admin/continuous.md#hooks-target-matching). 4. Decide cómo debería Weblate introducir traducciones de nuevo: * Utilice [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) o [Mercurial](https://docs.weblate.org/es/latest/vcs.md#vcs-mercurial) y [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) 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. 5. Opcionalmente establezca [Rama para inserción](https://docs.weblate.org/es/latest/admin/projects.md#component-push-branch) 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 inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) ), 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 [Insertar al consignar](https://docs.weblate.org/es/latest/admin/projects.md#component-push-on-commit). 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`](https://docs.weblate.org/es/latest/wlc.md#cmdoption-wlc-arg-push). En caso de que no desee notificaciones push directas por Weblate, hay apoyo para revisiones de [Solicitudes de incorporación de GitHub](#code-hosting-github-pull-requests), [Solicitudes de fusión de GitLab](#code-hosting-gitlab-merge-requests), [Solicitudes de incorporación de Gitea](#code-hosting-gitea-pull-requests), [Solicitudes de fusión de Pagure](#code-hosting-pagure-merge-requests), [Solicitud de incorporación Azure DevOps](#code-hosting-azure-devops-pull-requests), o [Solicitudes de revisión de Gerrit](#code-hosting-gerrit). Puedes activarlos eligiendo GitHub, GitLab, Gitea, Gerrit, Azure DevOps, o Pagure como [Sistema de control de versiones](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) en [Configuración de componentes](https://docs.weblate.org/es/latest/admin/projects.md#component). 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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) | [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) | [Rama para inserción](https://docs.weblate.org/es/latest/admin/projects.md#component-push-branch) | |-----------------------------------------------------------------|----------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------| | No enviar | [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) | vacío | vacío | | Enviar directamente | [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) | URL SSH | vacío | | Enviar en una rama separada | [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) | URL SSH | Nombre de rama | | No enviar | [Mercurial](https://docs.weblate.org/es/latest/vcs.md#vcs-mercurial) | vacío | vacío | | Enviar directamente | [Mercurial](https://docs.weblate.org/es/latest/vcs.md#vcs-mercurial) | URL SSH | vacío | | Solicitud de extracción GitHub desde bifurcación | [Solicitudes de incorporación de GitHub](#code-hosting-github-pull-requests) | vacío | vacío | | Solicitud de extracción GitHub desde rama | [Solicitudes de incorporación de GitHub](#code-hosting-github-pull-requests) | SSH URL [1](#empty) | Nombre de rama | | Solicita fusión de GitLab desde bifurcación | [Solicitudes de fusión de GitLab](#code-hosting-gitlab-merge-requests) | vacío | vacío | | Fusión GitLab solicitada desde rama | [Solicitudes de fusión de GitLab](#code-hosting-gitlab-merge-requests) | SSH URL [1](#empty) | Nombre de rama | | Solicitud de fusión de Gitea desde la bifurcación | [Solicitudes de incorporación de Gitea](#code-hosting-gitea-pull-requests) | vacío | vacío | | Solicitud de fusión Gitea desde rama | [Solicitudes de incorporación de Gitea](#code-hosting-gitea-pull-requests) | SSH URL [1](#empty) | Nombre de rama | | Solicitud de fusión Pagure desde bifurcación | [Solicitudes de fusión de Pagure](#code-hosting-pagure-merge-requests) | vacío | vacío | | Solicitud de fusión Pagure desde rama | [Solicitudes de fusión de Pagure](#code-hosting-pagure-merge-requests) | SSH URL [1](#empty) | Nombre de rama | | Solicitud de fusión Azure DevOps desde bifurcación | [Solicitud de incorporación Azure DevOps](#code-hosting-azure-devops-pull-requests) | vacío | vacío | | Solicitud de extracción Azure DevOps desde rama | [Solicitud de incorporación Azure DevOps](#code-hosting-azure-devops-pull-requests) | SSH URL [1](#empty) | Nombre de rama | | Revisión de Gerrit | [Solicitudes de revisión de Gerrit](#code-hosting-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](#code-hosting-bitbucket-data-center-pull-requests) | vacío | vacío | | Solicitud de extracción Bitbucket Data Center desde rama | [Solicitudes de incorporación al Centro de Datos Bitbucket](#code-hosting-bitbucket-data-center-pull-requests) | SSH URL [1](#empty) | Nombre de rama | | Solicitud de extracción Bitbucket Cloud desde bifurcación | [Solicitud de incorporación a BitBucket Cloud](#code-hosting-bitbucket-cloud-pull-requests) | vacío | vacío | | Solicitud de extracción Bitbucket Cloud desde rama | [Solicitud de incorporación a BitBucket Cloud](#code-hosting-bitbucket-cloud-pull-requests) | SSH URL [1](#empty) | Nombre de rama | * **[1]** Puede estar vacío en caso [Repositorio de código fuente](https://docs.weblate.org/es/latest/admin/projects.md#component-repo) admita subida. ## 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](https://github.com/apps/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://docs.weblate.org/es/latest/vcs.md#hosted-push). #### 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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: 1. Cree un vale de acceso personal como describió en [Crear un vale de acceso para utilizar línea de comando](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). 2. 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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](https://github.com/apps/hosted-weblate). #### NOTE Al utilizar GitHub para solicitudes de extracción, la configuración [Rama para inserción](https://docs.weblate.org/es/latest/admin/projects.md#component-push-branch) 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](https://github.com/apps/hosted-weblate) 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. The [Hosted Weblate legacy app](https://github.com/apps/hosted-weblate-legacy) is kept for existing webhook-only setups. Its deliveries use the generic GitHub webhook URL and are authenticated using a separate webhook secret configured by the Hosted Weblate operator. Use it only when you need the legacy app to deliver GitHub notifications to Hosted Weblate. 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: 1. Inicie a Weblate con una cuenta que ha gestionado acceso. 2. Abra: Gestión → Conexiones de Código‐hospedado → Registrar App GitHub en Weblate. 3. 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. 4. Pulse Continuar a GitHub y confirme en la página Crear App de GitHub de GitHub (puede renombrar aún la App allí). 5. 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`, `Push` and `Repository` 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 Las cuentas de GitHub conectadas están vinculadas a un [espacio de trabajo](https://docs.weblate.org/es/latest/admin/workspaces.md#workspaces) de Weblate. Un usuario con permisos de administrador para cualquier proyecto en un espacio de trabajo puede conectar una cuenta de GitHub a dicho espacio. Tras la conexión, todos los proyectos del espacio de trabajo pueden importar componentes de los repositorios a los que tenga acceso la instalación de la Apl GitHub. En el caso de cuentas de organizaciones, Weblate verifica que el usuario de GitHub que realizó la instalación tenga permisos de administrador para dicha organización. Los proyectos que no estén dentro de un espacio de trabajo no pueden conectar una cuenta GitHub a través de la Apl GitHub. Removing a connected GitHub account also uninstalls the App from GitHub when no other Weblate workspace uses that installation. If another workspace still uses the installation, Weblate removes only the selected workspace connection. Components imported through that connection lose access to their repositories. Removing a workspace uninstalls its connected accounts the same way. Weblate removes the connection even when GitHub no longer knows about the installation, and keeps it only when GitHub could not be reached, so that the removal can be retried. 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. #### Migrating existing components Weblate reports an informational diagnostic for Git and GitHub pull request components that can be migrated to a registered Weblate GitHub App. Follow the Migrate to GitHub App link from the diagnostic to review all eligible components in the workspace. Connect or update the GitHub account for the workspace, grant the App access to the listed repositories, and select the components to migrate. Weblate changes the selected components to the GitHub (via Weblate GitHub app) VCS backend, replaces their repository addresses with canonical HTTPS clone URLs, and removes separate push URLs because the App authenticates pushes to the source repository. #### URL de gancho a App Cada Weblate GitHub App registrada tiene su propio gancho web URL conteniendo un vale opaco que únicamente identifica una única Apl registrada: ```text https://weblate.example.com/hooks/integrations// ``` Components using the GitHub (via Weblate GitHub app) VCS backend are matched only through this dedicated endpoint. All generic forge webhook endpoints exclude them from matching and response diagnostics, including `/hooks/github/`. Legacy GitHub App deliveries sent to the generic endpoint can match only components using a non-App VCS backend. When a repository is renamed or transferred on GitHub, the `Repository` event makes Weblate refresh the repositories of the connected GitHub account and point the affected components to the new repository URL. Apps registered before Weblate 2026.10.1 are not subscribed to this event; enable Repository under Subscribe to events in the App settings on GitHub. Refreshing repositories of a connected GitHub account retargets such components too, for example when the event was missed. Use [`refresh_github_repositories`](https://docs.weblate.org/es/latest/admin/management.md#weblate-admin-refresh_github_repositories) to do this for all connected GitHub accounts at once. 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: ![image](images/github-settings.png) 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). #### SEE ALSO * [`POST /hooks/github/`](https://docs.weblate.org/es/latest/api.md#post--hooks-github-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de incorporación de GitHub Esto añade una capa delgada encima [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de GitHub](https://docs.github.com/en/rest) para conceder empuje de cambios de traducción como solicitudes de incorporar, en vez de empujar directamente al repositorio. [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configura [`GITHUB_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-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. If creating a pull request fails with `404 Not Found`, GitHub can be refusing API access even when the repository is readable. Weblate checks the repository’s pull request creation policy and, for user tokens, the authenticated account. The failure alert reports confirmed findings and provides further checks when the cause remains unknown. Diagnostic lookup failures preserve the original pull request error. Check that the effective API token belongs to the intended fork owner and allows creating pull requests. For fine-grained tokens, check repository selection, resource owner, and Pull requests write permission. Also check organization restrictions and access to the source branch. For GitHub Apps, check installation access to the repositories and pull request permissions. A successful Git push does not verify API access: pushing can use a separate SSH key. The repository log includes GitHub’s request ID and permission headers when available to help investigate the failure. Accepted permission headers describe endpoint requirements, not the permissions granted to the token. ## GitLab ### Acceso a repositorios en GitLab #### HTTPS con vale de acceso personal o proyecto 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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`. #### NOTE 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 GitLab, cree un usuario dedicado y utilice URL de SSH de GitLab, por ejemplo `git@gitlab.com:group/proyecto.git`. Para los repositorios de Hosted Weblate en GitLab, agregue el usuario weblate hospedado con los permisos del repositorios requeridos, consulte [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push). ### 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/`. #### SEE ALSO * [`POST /hooks/gitlab/`](https://docs.weblate.org/es/latest/api.md#post--hooks-gitlab-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de fusión de GitLab Esto añade una capa fina encima de [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de GitLab](https://docs.gitlab.com/api/) 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](https://docs.weblate.org/es/latest/vcs.md#vcs-git) funciona igual; la única diferencia radica en como se proporciona a un repositorio sea gestionado. Con los cambios de [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configurar [`GITLAB_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-GITLAB_CREDENTIALS). La configuración [Rama para inserción](https://docs.weblate.org/es/latest/admin/projects.md#component-push-branch) 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 los repositorios de Hosted Weblate en Codeberg, añada el usuario weblate hospedado con los permisos del repositorio requeridos, consulte [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push). ### 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. #### SEE ALSO * [Webhooks in Gitea manual](https://docs.gitea.com/usage/repository/webhooks) * [`POST /hooks/gitea/`](https://docs.weblate.org/es/latest/api.md#post--hooks-gitea-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### 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. #### SEE ALSO * [Ganchos web en documentación de Forgejo](https://forgejo.org/docs/latest/user/webhooks/) * [`POST /hooks/forgejo/`](https://docs.weblate.org/es/latest/api.md#post--hooks-forgejo-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de incorporación de Gitea #### Versionadded Added in version 4.12. Esto agrega una capa fina encima de [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de Gitea](https://docs.gitea.com/development/api-usage) 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](https://docs.weblate.org/es/latest/vcs.md#vcs-git) funciona de la misma manera, la única diferente es como proporcionar a un repositorio esté manipulado. Con los cambios de [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configura [`GITEA_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-GITEA_CREDENTIALS). ## Bitbucket ### Acceso a repositorios en Bitbucket #### HTTPS con vale de acceso 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 los repositorios de Hosted Weblate en Bitbucket, añada el usuario weblate con los permisos de repositorio requeridos, consulte [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push). Para introducir directamente, utiliza [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) o [Mercurial](https://docs.weblate.org/es/latest/vcs.md#vcs-mercurial) junto con [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push). ### 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/`. ![image](images/bitbucket-settings.png) #### SEE ALSO * [`POST /hooks/bitbucket/`](https://docs.weblate.org/es/latest/api.md#post--hooks-bitbucket-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de incorporación al Centro de Datos Bitbucket #### Versionadded Added in version 4.16. Esto añade una capa fina sobre [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API del Centro de Datos Bitbucket](https://developer.atlassian.com/server/bitbucket/) para subir los cambios de la traducción como solicitud de subirá en lugar de subirlas directamente al repositorio. #### WARNING Esto no mantiene el API de Bitbucket Cloud. No hay necesidad para utilizar esto para acceder a repositorios Git, lo ordinario de [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configure [`BITBUCKETSERVER_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-BITBUCKETSERVER_CREDENTIALS). ### Solicitud de incorporación a BitBucket Cloud #### Versionadded Added in version 5.8. Esto añade una capa final sobre [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de Bitbucket Cloud](https://developer.atlassian.com/cloud/bitbucket/) para permitir enviar los cambios de traducción como solicitudes de extracción en lugar de enviarlos directamente al repositorio. #### WARNING 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](https://docs.weblate.org/es/latest/vcs.md#vcs-git) funciona igual, la única diferencia es cómo se gestiona el envío a un repositorio. Con [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configure [`BITBUCKETCLOUD_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-BITBUCKETCLOUD_CREDENTIALS). ## Azure DevOps ### Acceso a repositorios en Azure #### HTTPS con vale de acceso 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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. 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 . #### SEE ALSO * [Ganchos web en manual de Azure DevOps](https://learn.microsoft.com/es/azure/devops/service-hooks/services/webhooks?view=azure-devops) * [`POST /hooks/azure/`](https://docs.weblate.org/es/latest/api.md#post--hooks-azure-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitud de incorporación Azure DevOps Esto añade una fina capa sobre [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de Azure DevOps](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.2) para permitir enviar los cambios de traducción como solicitudes de extracción, en lugar de enviarlos directamente al repositorio. [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configura [`AZURE_DEVOPS_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-AZURE_DEVOPS_CREDENTIALS). ## Pagure ### Acceso a repositorios en Pagure #### HTTPS con vale de acceso 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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. ### 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: ![image](images/pagure-webhook.png) #### SEE ALSO * [`POST /hooks/pagure/`](https://docs.weblate.org/es/latest/api.md#post--hooks-pagure-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de fusión de Pagure #### Versionadded Added in version 4.3.2. Esto añade una fina capa sobre [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando el [API de Pagure](https://pagure.io/api/0/) 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](https://docs.weblate.org/es/latest/vcs.md#vcs-git) ordinario funciona igual, la única diferencia es cómo se gestiona el envío a un repositorio. Con [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-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](https://docs.weblate.org/es/latest/admin/projects.md#component-vcs) y configura [`PAGURE_CREDENTIALS`](https://docs.weblate.org/es/latest/admin/config.md#std-setting-PAGURE_CREDENTIALS). ## Otros flujos ### Acceso a repositorios en Gitee #### HTTPS con vale de acceso 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo). Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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 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](https://docs.weblate.org/es/latest/admin/projects.md#component-repo), for example `git@example.com:group/project.git`. Configure [URL de inserción en repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-push) only when Weblate should push changes directly or when the chosen workflow requires a push URL, see [Enviar cambios efectuados en Weblate](#code-hosting-push-options). 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. ### 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. #### SEE ALSO * [Manual de ganchos web en Gitea](https://help.gitee.com/webhook) * [`POST /hooks/gitee/`](https://docs.weblate.org/es/latest/api.md#post--hooks-gitee-) * [Acceder repositorios desde Hosted Weblate](https://docs.weblate.org/es/latest/vcs.md#hosted-push) ### Solicitudes de revisión de Gerrit El soporte Gerrit añade una capa fina sobre [Git](https://docs.weblate.org/es/latest/vcs.md#vcs-git) utilizando la herramienta [git-review](https://pypi.org/project/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 para inserción](https://docs.weblate.org/es/latest/admin/projects.md#component-push-branch) selecciona la rama objetivo para la revisión de Gerrit. Djala vacía para utilizar [Rama del repositorio](https://docs.weblate.org/es/latest/admin/projects.md#component-branch). Utiliza el nombre corto de la rama, como `main`; Weblate y `git-review` envían la revisión automáticamente a `refs/for/`. 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‐hospedaje separado para ajuste credencial para este segundo plano. ### Credenciales de Docker Para instalaciones de Docker, las credenciales del API del código‐hospedaje además puede ser proporcionado a través de variables del entorno, consulte [Credenciales de sitios de alojamiento de código](https://docs.weblate.org/es/latest/admin/install/docker.md#docker-vcs-config).