Integración de control de versiones¶
Weblate admite actualmente Git (con mantenimiento extendido para Solicitudes de incorporación de GitHub, Solicitudes de fusión de GitLab, Solicitudes de incorporación de Gitea, Solicitudes de revisión de Gerrit, Subversion, Solicitud de incorporación a BitBucket Cloud, Solicitudes de incorporación al Centro de Datos Bitbucket, y Solicitud de incorporación Azure DevOps) y Mercurial como versión de control en segundo plano.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Integraciones de alojamiento de código.
Acceder a repositorios¶
El repositorio VCS que desea usar debe ser accesible para Weblate. Con un repositorio disponible públicamente tan solo necesita introducir la URL correcta (por ejemplo, https://github.com/WeblateOrg/weblate.git); sin embargo, para repositorios privados o URL de inserción, la configuración es más compleja y requiere autenticación.
Troubleshooting repository URLs¶
Weblate validates repository and push URLs before connecting. HTTPS and SSH
are permitted by default; instance administrators can adjust this using
VCS_ALLOW_SCHEMES.
Repository hostnames have to resolve from the Weblate server. When
VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations
which resolve to internal or otherwise non-public addresses. Use a publicly
reachable repository URL where possible. For an intentionally private
repository on a trusted network, ask the instance administrator to add its
hostname to VCS_ALLOW_HOSTS.
Git over HTTPS and SSH can bind connections to addresses approved during
validation. Backends which cannot do this safely, including Mercurial and
Subversion, require the trusted repository hostname in
VCS_ALLOW_HOSTS while private-address restrictions are enabled.
Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.
Acceder repositorios desde Hosted Weblate¶
Nota
Esta sección se aplica solo en Hosted Weblate (hosted.weblate.org). Si está ejecutando su propia instancia de Weblate hospedada para sí, consulte the next section en su lugar.
For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow whenever possible. The App grants repository access, receives incoming notifications, pushes translation branches, and creates pull requests without inviting the Hosted Weblate weblate user. See Acceso a repositorios en GitHub for the full setup.
For direct SSH access outside the GitHub App workflow, and for Bitbucket,
Codeberg, and GitLab repositories, Hosted Weblate has a dedicated push user
(with the username weblate, e-mail hosted@weblate.org, and a
name or profile description Weblate push user).
Consejo
Puede haber más usuarios de Weblate en las plataformas designadas para otras instancias de Weblate. Se recomienda buscar por correo electrónico hosted@weblate.org para encontrar el usuario correcto para Hosted Weblate alojado.
Debe agregar a este usuario como colaborador y otorgarle los permisos correspondientes en su repositorio (solo lectura para clonar, escritura para enviar). Según el servicio y la configuración de su organización, esto se realiza de inmediato o requiere confirmación de Weblate.
The weblate user on GitHub accepts invitations automatically within five minutes when you intentionally use direct SSH access there. Manual processing might be needed on the other services, so please be patient.
For this direct SSH-user setup, once the weblate user is added to
your repository, you can configure Repositorio de código fuente and
URL de inserción en repositorio using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Nota
Esta sección se aplica a instancias autoalojadas de Weblate. Si utiliza Hosted Weblate (hosted.weblate.org), en cambio consulte Acceder repositorios desde Hosted Weblate.
For self-hosted Weblate, a single private repository is often easiest to set up using an HTTPS repository URL with an access token, see Integraciones de alojamiento de código.
For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Clave SSH de Weblate). This way you associate Weblate SSH key with a single user, because platforms frequently enforce single use of an SSH key. Grant this user access to the repositories, and use SSH URLs to access them (see Repositorios SSH).
Repositorios SSH¶
One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Clave SSH de Weblate) to access the upstream repository this way.
Advertencia
En GitHub, cada clave puede ser utilizada una vez, consulte Acceso a repositorios en GitHub y Acceder repositorios desde Hosted Weblate.
Weblate también almacena la huella digital de la clave del host en la primera conexión y, no puede conectarse al host si se cambia más tarde (consulte Verificar las claves host SSH).
En caso de que necesite efectuar ajustes, hágalos desde la interfaz administrativa de Weblate:
Clave SSH de Weblate¶
Distinto en la versión 4.17: Weblate ahora genera ambas claves RSA y Ed25519 SSH. Se recomienda usar Ed25519 para nuevas configuraciones.
La clave pública de Weblate es visible para todos los usuarios explorando la página About.
Los administradores pueden generar o exhibir la clave pública utilizada actualmente por Weblate en la conexión (desde claves SSH) en la página de inicio de la interfaz administrativa.
Nota
La correspondiente clave privada de SSH actualmente no puede tener una contraseña, por tanto asegúrese que esté bien protegido.
Consejo
Haga un respaldo de la clave privada SSH de Weblate generada.
Verificar las claves host SSH¶
Weblate almacena automáticamente las claves host de SSH en el primer acceso y los recuerda para uso posterior.
When VCS_RESTRICT_PRIVATE is enabled, Weblate resolves and validates
the repository host before scanning its key and connects ssh-keyscan only
to the approved addresses. The stored key remains associated with the original
hostname.
For Git connections, Weblate also applies HostName and Port from
DATA_DIR/ssh/config before validating and pinning the effective
destination. SSH configuration and SSH_EXTRA_ARGS are trusted
administrator-controlled inputs. They can alter connection routing, and
SSH_EXTRA_ARGS can override Weblate’s address pinning;
administrators are responsible for their effects.
Si desea verificar la huella digital de la clave antes de conectarse al repositorio, agregue las claves de host SSH de los servidores a los que accederá en Agregar clave de host, desde la misma sección de la interfaz administrativa. Ingrese el nombre del host al que accederá (p. ej., gitlab.com) y presione Enviar. Verifique que su huella digital coincida con el servidor que agregó.
Las claves añadidas con huellas son mostradas en el mensaje de confirmación:
Conectar a servidores SSH heredados¶
Weblate suppresses the OpenSSH warning about connections without post-quantum key exchange so that it does not obscure repository errors. This does not change algorithm negotiation: post-quantum key exchange is still used when supported by both the client and server. Other SSH warnings remain enabled. Upgrade or configure the SSH server to support post-quantum key exchange to protect against «store now, decrypt later» attacks.
Las versiones recientes de OpenSSH (por ejemplo, la utilizada en el contenedor Docker de Weblate) desactivan las firmas RSA mediante el algoritmo hash SHA-1 de forma predeterminada. Este cambio se debe a que el algoritmo hash SHA-1 presenta vulnerabilidades criptográficas y es posible crear colisiones de hash con prefijo seleccionado por menos de USD$50K.
Para la mayoría de los usuarios, este cambio debería ser invisible y no es necesario reemplazar las claves ssh-rsa. OpenSSH admite las firmas RFC8332 RSA/SHA-256/512 desde la versión 7.2 y las claves ssh-rsa existentes utilizarán automáticamente el algoritmo más fuerte siempre que sea posible.
La incompatibilidad es más como cuando conecta a implementaciones de SSH más antiguas que no haber sido mejorados o no son seguidas de cerca las mejoras en el protocolo SSH. La conexión de SSH para tal servidor fallará cuando:
no matching host key type found. Their offer: ssh-rsa
En estos casos, puede ser necesario reactivar RSA/SHA1 selectivamente para permitir la conexión o la autenticación de usuarios mediante las opciones HostkeyAlgorithms y PubkeyAcceptedAlgorithms. Por ejemplo, la siguiente sección en DATA_DIR/ssh/config habilitará RSA/SHA1 para la autenticación de host y usuarios en un único host de destino:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Recomendamos habilitar solo RSA/SHA1 como una medida de solución provisional hasta que las implementaciones heredadas pueden ser mejoradas o reconfiguradas con otro tipo de clave (tal como ECDSA o Ed25519).
Repositorios en GitHub¶
Detailed GitHub repository access is covered in Acceso a repositorios en GitHub.
Repositorios en GitLab¶
Detailed GitLab repository access is covered in Acceso a repositorios en GitLab.
URL internos de Weblate¶
Compartir una configuración de repositorio entre diferentes componentes por referenciar a su sitio como weblate://project/component dentro de otro componente (enlazado). De esta manera, el componente enlazado utiliza la configuración del repositorio VCS del componente (referenciado ) principal.
Advertencia
Retirar componente principal además retira componentes enlazados.
Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component’s repository configuration.
Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.
Automáticamente Weblate ajusta la URL del repositorio cuando crea un componente si encuentra un componente con una configuración de repositorio que coincida. Puede sobrescribir esto en el último paso de la configuración del componente.
Razones para utilizar esto:
Ahorra espacio en disco en el servidor, ya que el repositorio se almacena solo una vez.
Acelera las actualizaciones, ya que solo se actualiza un repositorio.
Solo hay un único repositorio exportado con traducciones de Weblate (consulte Exportador de Git).
Ciertos complementos pueden operar en varios componentes que compartan un repositorio, como Concentrar consignaciones de Git.
Repositorios HTTPS¶
Para acceder a repositorios HTTPS protegidos, incluya el apodo y la contraseña en el URL. No se preocupe, Weblate quitará estos datos al mostrar el URL a los usuarios (incluso si se les permite ver el URL del repositorio).
Por ejemplo, la URL de GitHub con autenticación añadida se vería como: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
En el caso que no proporcione las credenciales dentro de la URL y el repositorio la requiere, Git fallará con un error:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Distinto en la versión 5.10.2: Weblate usa autenticación proactiva con Git 2.46.0 y versiones posteriores cuando se proporcionan credenciales HTTP.
Esto hace que sea posible acceder a los repositorios Azure DevOps y realizar acceso para hacer más rápidos los repositorios autenticados.
Nota
Si su apodo o contraseña contiene caracteres especiales, estos deben ser codificados en la URL, por ejemplo https://user%40ejemplo.com:%24contrasenia%23@bitbucket.org/….
Uso de «proxy»¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in Proxy HTTP.
Parámetros del control de versiones¶
Added in version 2026.9.
Version control parameters tune how a component interacts with its repository without having to choose a different version control system. They are configured per component in Parámetros del control de versiones, and only the parameters applicable to the selected Sistema de control de versiones are offered.
Lista de parámetros del control de versiones¶
Nombre del parámetro |
Version control systems |
Etiqueta |
Texto de ayuda |
|---|---|---|---|
create_merge_request |
|
Create merge requests |
Open a pull or merge request for the translation changes. When turned off, Weblate pushes to the translated branch directly, which requires write access to it. |
git_force_push |
|
Forzar inserción |
Overwrite the remote branch instead of refusing to push non-fast-forward changes. Only use this with a repository dedicated to translations, as it discards upstream commits which are not present in Weblate. |
merge_request_automerge |
|
Fusionar solicitudes de extracción automáticamente |
Turn on GitHub auto-merge for pull requests created by Weblate, so that they are merged once the required checks pass. Pull requests with nothing to wait for are merged right away. |
merge_request_merge_method |
|
Método de fusión |
Método usado para fusionar automáticamente las solicitudes de incorporación de cambios. El repositorio debe permitirlo. Elecciones disponibles:
|
Git¶
Consejo
Weblate needs Git 2.46 or newer.
Nota
Weblate validates permanent HTTP redirects which stay on the repository hostname and automatically stores the canonical repository URL. The change is recorded in the component history as repository maintenance. Redirects to another hostname have to be configured manually.
Ver también
Consulte Acceder a repositorios para info sobre como acceder directamente a familias de repositorios.
Git LFS¶
Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.
A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.
For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.
Git submodules¶
Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.
If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.
Force pushing¶
Turn on the git_force_push version control parameter to
make Weblate always force push. This is intended only in the case of using a
separate repository for translations.
Advertencia
Utilice con precaución, ya que esto conduce fácilmente a las consignas perdidas en su repositorio en desarrollo.
Distinto en la versión 2026.9: This used to be a separate Git with force push version control
system. Existing components were migrated to Git with the git_force_push
parameter turned on.
Personalizar configuración de Git¶
Weblate invoca todas las instrucciones de VCS con HOME=$DATA_DIR/home (consulte DATA_DIR), por lo tanto editar la configuración de usuario necesita ser hecho en DATA_DIR/home/.git.
Solicitudes de incorporación de GitHub¶
Detailed GitHub pull request setup is covered in Solicitudes de incorporación de GitHub.
Solicitudes de fusión de GitLab¶
Detailed GitLab merge request setup is covered in Solicitudes de fusión de GitLab.
Solicitudes de incorporación de Gitea¶
Detailed Gitea pull request setup is covered in Solicitudes de incorporación de Gitea.
Solicitudes de incorporación al Centro de Datos Bitbucket¶
Detailed Bitbucket Data Center pull request setup is covered in Solicitudes de incorporación al Centro de Datos Bitbucket.
Solicitud de incorporación a BitBucket Cloud¶
Detailed Bitbucket Cloud pull request setup is covered in Solicitud de incorporación a BitBucket Cloud.
Solicitudes de fusión de Pagure¶
Detailed Pagure merge request setup is covered in Solicitudes de fusión de Pagure.
Gerrit¶
Detailed Gerrit review request setup is covered in Solicitudes de revisión de Gerrit.
Solicitud de incorporación Azure DevOps¶
Detailed Azure DevOps pull request setup is covered in Solicitud de incorporación Azure DevOps.
Mercurial¶
Mercurial es otro sistema de control de versiones que puede utilizar directamente en Weblate.
Nota
Debería funcionar con cualquier versión de Mercurial, pero a veces hay cambios incompatibles en la interfaz de línea de órdenes que quebrantan la integración con Weblate.
Ver también
Consulte Acceder a repositorios para info sobre como acceder directamente a familias de repositorios.
Subversion¶
Weblate emplea git-svn para interactuar con los repositorios subversion. Es un script de Perl que permite a subversión ser utilizada por un cliente Git, permitiendo a los usuarios mantener un clon completo del repositorio interno y consignan localmente.
Nota
Weblate intenta detectar automáticamente la estructura del repositorio Subversion; admite tanto URL directas para ramas como repositorios con estructura estándar (branches/, tags/ y trunk/). Para obtener más información al respecto, consulte la documentación de git-svn. Si su repositorio no tiene una estructura estándar y encuentra errores, intente incluir el nombre de la rama en la URL del repositorio y deje la rama vacía.
Datos de acceso de Subversion¶
Weblate espera que hayas aceptado el certificado por adelantado (y tus credenciales si es necesario). Intentará insertarlos en el directorio DATA_DIR. Acepta el certificado utilizando svn una vez con la variable de entorno $HOME establecida en DATA_DIR:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Ver también
Archivos locales¶
Consejo
Por lo tanto, esto utiliza Git. Requiere instalado el Git y concederle cambiar a utilizar el Git nativo con histórico completo de sus traducciones.
Weblate también puede funcionar sin un VCS remoto. Las traducciones iniciales se importan mediante su carga. Posteriormente, puede sustituir archivos individuales mediante la carga de archivos o añadir cadenas de traducción directamente desde Weblate (actualmente solo disponible para traducciones monolingües).
En el segundo plano Weblate crea un repositorio Git para ti y todos los cambios son seguidos dentro. En caso que más tarde decida utilizar un VCS para almacenar las traducciones, ya tiene un repositorio dentro de Weblate que pude basar su integración.