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, 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.
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.
Para Weblate para sí hospedado, acceda a repositorios en páginas de alojamiento de código se realiza normalmente creando un usuario dedicado que se asocia con una clave SSH de Weblate (consulte Clave SSH de Weblate). De esta manera asocias la clave SSH de Weblate con un único usuario (las plataformas refuerzan uso único de una clave SSH) y concede a este usuario acceso al repositorio. Entonces puedes utilizar la URL SSH para acceder al repositorio (consulte 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
En GitHub, cada clave puede ser utilizada una vez, consulte 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.
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¶
Hay dos enfoques principales para acceder a los repositorios de GitHub con Weblate:
Opción 1: HTTPS con Vales de Acceso Personal (más sencillo para comenzar)
Usa la autenticación HTTPS con un vale de acceso personal y tu cuenta de GitHub. Esto funciona tanto para acceso de solo lectura (clonación) como para acceso de lectura y escritura (insertar cambios o crear solicitudes de extracción).
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 se empieza a utilizar Weblate o se trabaja con un único repositorio.
Opción 2: SSH con usuario dedicado (recomendado para múltiples repositorios)
Para configuraciones con varios repositorios, se recomienda crear un usuario dedicado para Weblate. Esto evita la limitación de GitHub que cada clave SSH solo se puede usar una vez por plataforma.
Para utilizar este enfoque:
Crea una cuenta de usuario de GitHub dedicada (por ejemplo,
weblate-bot)Añade la clave SSH pública de Weblate a este usuario (consulte Clave SSH de Weblate)
Conceda a este usuario acceso a todos los repositorios que desee traducir
Utiliza las URL de SSH para tus repositorios:
git@github.com:owner/repo.git
Este enfoque también se utiliza para Hosted Weblate, que cuenta con un usuario dedicado weblate para tal propósito.
Nota
Al utilizar Solicitudes de incorporación de 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.
Repositorios en GitLab¶
Es posible acceder a través de SSH (consulte Repositorios SSH), pero en caso de que necesites acceder a más de un repositorio, te encontrarás con una limitación de GitLab en el uso de claves SSH permitidas (ya que cada clave se puede usar solo una vez).
Si no se configura la rama Rama a la que enviar, el proyecto se bifurca y los cambios se envían a través de una bifurcación. Si se configura, los cambios se envían al repositorio original y a la rama seleccionada.
También es posible usar vale de acceso personales o de proyecto. El vale requiere el ámbito write_repository para poder enviar cambios al repositorio. El token de acceso de proyecto requiere el rol Desarrollador para enviar 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.
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¶
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 Solicitudes de incorporación de GitHub crea solicitudes de extracción. Esta última no es necesaria simplemente para acceder a los repositorios de Git.
Necesita configurar credenciales del API (GITHUB_CREDENTIALS) en los ajustes de Weblate para hacer que esto funcione. Una vez configurado, verá una opción de GitHub cuando seleccione Sistema de control de versiones.
Solicitudes de fusión de GitLab¶
Esto tan solo 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 Solicitudes de fusión de GitLab se crea una solicitud de fusión.
Es necesario configurar los API de credenciales (GITLAB_CREDENTIALS) en los ajustes de Weblate para hacer que esto funcione. Una vez configurado, verá una opción en GitLab cuando selecciona Sistema de control de versiones.
Solicitudes de incorporación de Gitea¶
Added in version 4.12.
Esto acaba de agregar 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 proporiconar a un repositorio esté manipulado. Con los cambios de Git son proporcionados directamente para el repositorio, mientras Solicitudes de incorporación de Gitea crea peticiones de incorporar.
Necesitas configurar las credenciales de API (GITEA_CREDENTIALS) dentro de los ajustes de Weblate para realizar este trabajo. Una vez configurado, verá una opción Gitea cuando selecciona Sistema de control de versiones.
Solicitudes de incorporación al Centro de Datos Bitbucket¶
Added in version 4.16.
Esto tan solo 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 Solicitudes de incorporación al Centro de Datos Bitbucket crea solicitudes de extracción.
Necesita configurar las credenciales de API (BITBUCKETSERVER_CREDENTIALS) en los ajustes de Weblate para hacer que esto funcione. Una vez que se configure, verá una opción de Bitbucket Data Center cuando seleccione Sistema de control de versiones.
Solicitud de incorporación a BitBucket Cloud¶
Added in version 5.8.
Esto solo 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 Solicitud de incorporación a BitBucket Cloud crea una solicitud de extracción.
Para que esto funcione, necesita configurar las credenciales del API (BITBUCKETCLOUD_CREDENTIALS) en la configuración de Weblate. Una vez configurada, verá una opción Bitbucket Cloud al seleccionar Sistema de control de versiones.
Solicitudes de fusión de Pagure¶
Added in version 4.3.2.
Esto solo 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 Solicitudes de fusión de Pagure crea una solicitud de fusión.
Para que esto funcione, debe configurar las credenciales del API (PAGURE_CREDENTIALS) en los ajustes de Weblate. Una vez configurada, verá la opción Pagure al seleccionar Sistema de control de versiones.
Gerrit¶
Añade una fina capa sobre Git utilizando la herramienta git-review para permitir enviar los cambios de traducción como solicitudes de revisión de Gerrit, en lugar de enviarlos directamente al repositorio.
La documentación de Gerrit tiene los detalles sobre la configuración necesaria para la puesta en marcha de dichos repositorios.
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 Solicitud de incorporación Azure DevOps crea solicitudes de extracción. Esta última no es necesaria simplemente para acceder a los repositorios de Git.
Necesita configurar las credenciales del API (AZURE_DEVOPS_CREDENTIALS) en los ajustes de Weblate hacer este trabajo. Una vez configurado, verá una opción Azure DevOps al seleccionar Sistema de control de versiones.
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.