Integración de control de versiones¶
Weblate currently supports Git (with extended support for Solicitudes de incorporación de GitHub, Solicitudes de fusión de GitLab, Solicitudes de incorporación de Gitea, Gerrit review requests, Subversion, Solicitud de incorporación a BitBucket Cloud, Solicitudes de incorporación al Centro de Datos Bitbucket, and Solicitud de incorporación Azure DevOps) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Code hosting integrations.
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.
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.
Para Weblate Hosted, hay un usuario dedicado al envío registrado en GitHub, Bitbucket, Codeberg y GitLab (con el nombre de usuario weblate, correo-e hosted@weblate.org, y un nombre o descripción de perfil Usuario push de Weblate).
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.
En GitHub, necesita añadir o invitar al usuario weblate de Hosted Weblate con permisos de escritura, incluso cuando uses la aplicación de GitHub de Hosted Weblate. La aplicación gestiona las notificaciones entrantes de GitHub, pero al enviar los cambios, se sigue utilizando el usuario weblate de Hosted Weblate.
El usuario weblate en GitHub acepta invitaciones automáticamente en cinco minutos. Es posible que se requiera procesamiento manual en otros servicios, así que tenga paciencia.
Una vez que el usuario weblate se agrega a su repositorio, puede configurar Repositorio de código fuente y URL de envío al repositorio usando el protocolo SSH (p.e. git@github.com:WeblateOrg/weblate.git).
Acceder a repositorios en sitios de alojamiento de código (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, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Clave SSH de Weblate). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of an SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see Repositorios SSH).
Repositorios SSH¶
El método más utilizado para acceder a repositorios privados se basa en SSH. Autorice la clave SSH pública de Weblate (consulte Clave SSH de Weblate) para acceder al repositorio original de esta manera.
Advertencia
On GitHub, each key can only be used once, see GitHub repository access and 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.
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¶
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 GitHub repository access.
Repositorios en GitLab¶
Detailed GitLab repository access is covered in GitLab repository access.
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.
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.
Hace que las actualizaciones sean más rápidas, solo se actualiza un repositorio.
Tan solo hay exportado un único repositorio con traducciones de Weblate (consulte Exportador de Git).
Algunos complementos pueden operar sobre múltiples componentes compartiendo un repositorio, por ejemplo Concentrar consolidaciones de Git.
Repositorios HTTPS¶
Ver también
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¶
Si necesita acceder a repositorios VCS por HTTP/HTTPS utilizando un servidor proxy, configure el VCS para utilizarlo.
Esto puede ser hecho utilizando las variables de entorno http_proxy, https_proxy, y all_proxy, (como descrito en la documentación de cURL) o forzándolo en la configuración VCS, por ejemplo:
git config --global http.proxy http://user:password@proxy.example.com:80
Nota
La configuración proxy necesita ser hecha bajo la ejecución del usuario en Weblate (consulte además Permisos del sistema de archivos) y con HOME=$DATA_DIR/home (consulte DATA_DIR), en otro caso ejecutado Git por Weblate no lo utilizará.
Ver también
Git¶
Consejo
Weblate necesita Git 2.28 o posterior.
Ver también
Consulte Acceder a repositorios para info sobre como acceder directamente a familias de repositorios.
Git con envío forzado¶
Esto se comporta exactamente como el mismo Git, la única diferencia solo es que siempre fuerza envíos. Esto solo está pensado para el caso de utilizar un repositorio independiente para traducciones.
Advertencia
Utilice con precaución, ya que esto conduce fácilmente a las consignas perdidas en su repositorio en desarrollo.
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 Gerrit review requests.
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.