Localización continua¶
Existe una infraestructura para que la traducción siga de cerca el desarrollo. De este modo, los traductores pueden trabajar en las traducciones todo el tiempo, en lugar de trabajar con una enorme cantidad de texto nuevo justo antes del lanzamiento.
Ver también
Integración con Weblate describe maneras básicas para integrar su desarrollo con Weblate.
Este es el proceso:
Los desarrolladores hacen cambios y los suben al repositorio VCS.
Opcionalmente son actualizados los archivos de traducción, consulte Introducing new strings.
Weblate extrae los cambios del repositorio VCS , interpreta los archivos de traducción y actualiza su base de datos, consulte Actualizar repositorios .
Los traductores envían las traducciones a través de la interfaz web de Weblate, o suben los cambios sin conexión.
Una vez que los traductores han terminado, Weblate efectúa los cambios en el repositorio local (consulte Consignas diferidas).
Los cambios son traspasados al repositorio ascendente (consulte Enviar cambios efectuados en Weblate).
Consejo
Hospedaje de código ascendente no es necesario, puede utilizar Weblate con: Archivos locales donde solo hay el repo dentro de Weblate.
Actualizar repositorios¶
Debería configurar de alguna manera la actualización de los repos de backend desde su fuente.
Modo de empleo Actuadores de notificación para integrar con mayoría de código común hospedando servicios:
Además deve Activar actuadores para que funcione esto.
Activar manualmente la actualización ya sea en la administración del repositorio o usando API REST de Weblate o Cliente de Weblate
Habilite
AUTO_UPDATEpara actualizar automáticamente todos los componentes en su instancia de WeblateEjecute
updategit(con selección del proyecto o--allpara actualizar todo)
Siempre que Weblate actualice el repositorio, se activarán los complementos posteriores a la actualización, consulte Complementos.
Evitar conflictos de fusión¶
El conflicto de unión desde Weblate surge cuando el mismo archivo fue cambiado a la vez en Weblate y fuera de esto. Dependiendo de la situación, hay varias aproximaciones que quizá le ayude aquí:
Evitar conflictos de unión por cambio de archivos de traducción en Weblate solamente
Evitar conflictos de fusión bloqueando Weblate mientras realizan cambios externos
Evitar conflictos de unión por cambio de archivos de traducción en Weblate solamente¶
Evita editar fuera de Weblate es fácil con archivos monolínguos — puede añadir cadenas neuvas con Weblate y dejar completas editando allí los archivos. Para archivos bilingües, es usualmente alguna familia de mensajes de proceso de extracción para generar archivos traducibles a partir del código fuente. En algunos casos, esto se puede desglosar en dos partes:
La extracción genera la plantilla (por ejemplo, gettext POT se genera usando xgettext).
Luego el proceso lo fusiona en traducciones reales (los archivos gettext PO se actualizan usando msgmerge).
Puede realizar el segundo paso dentro de Weblate y se asegurará de que todos los cambios pendientes se incluyan antes de esta operación.
Evitar conflictos de fusión bloqueando Weblate mientras realizan cambios externos¶
Integrar Weblate en su proceso de actualización tal que purga los cambios antes de actualizar los archivos externos de Weblate puede ser logrado utilizando API REST de Weblate para forzar Weblate a purgar todos los cambios pendientes y loquear la traducción mientras está haciendo los cambios en su lado.
El script para realizar actualizaciones puede verse como este:
# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock
Si tiene múltiples componentes compartiendo el mismo repositorio, necesita bloquearlo todos separadamente:
wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj
Nota
El ejemplo utiliza Cliente de Weblate, el cual necesita configuración (teclas API) para ser capaz de controlar remotamente Weblate. Además puede lograr esto utilizando cualquier cliente HTTP en vez de Cliente de Weblate, por ejemplo curl, consulte API REST de Weblate.
Evitar conflictos de unión enfocando en operaciones Git¶
Incluso cuando Weblate es la única fuente de los cambios en los archivos de traducción, los conflictos pueden aparecer cuando se utiliza Concentrar consignas de Git adjunta, Estilo de fusión está configurado a Rebase, o está aplastando confirmaciones fuera de Weblate (por ejemplo, al fusionar una solicitud de extracción).
La razón de los conflictos de fusión es diferente en este caso - hay cambios en Weblate que ocurrieron después de que usted fusionara los commits de Weblate. Esto suele ocurrir si la fusión no está automatizada y se espera durante días o semanas a que un humano los revise. Git a veces ya no es capaz de identificar los cambios aguas arriba como coincidentes con los de Weblate y se niega a realizar un rebase.
Para aprobar esto, o bien necesita minimizar la cantidad de cambios pendientes en Weblate cuando una un pull request, o evitar los conflictos completamente no aplastando los cambios.
Aquí hay pocas opciones sobre como evitar eso:
No utilice ni Concentrar consignas de Git ni squashing en el momento de la fusión. Esta es la causa principal por la que git no reconoce los cambios tras la fusión.
Deje que Weblate confirme los cambios pendientes antes de fusionarlos. Esto actualizará la solicitud de extracción con todos sus cambios, y ambos repositorios estarán sincronizados.
Utiliza las características de revisión en Weblate (consulte Flujos de trabajo de traducción) tal que pueda unir automáticamente solicitudes de tirar unidas tras aprobar CI.
Utilice bloqueo en Weblate para evitar cambios mientras solicita subidas GitHub está dentro de revisión.
Ver también
Recibir cambios automáticamente de GitHub¶
Weblate admite GitHub nativamente.
Si está utilizando Hosted Weblate, la aproximación recomendada es instalar la app Weblate, esa manera obtendrá la configuración correcta sin tener que establecer mucho. Además puede ser utilizada para bajar cambios devueltos.
Para recibir notificaciones en cada push a un repositorio de GitHub, añade el Webhook de Weblate en la configuración del repositorio (Webhooks) como se muestra en la imagen de abajo:
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 evento push).
Recibir cambios automáticamente de 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/).
Recibiendo cambios automáticamente desde 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/).
Recibir cambios automáticamente de 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:
Recibir cambios automáticamente de Azure Repos¶
Weblate tiene soporte para ganchos de web en Azure Repos, agregue un gancho web para el evento 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 .
Recibir cambios automáticamente desde Repos de Gitea¶
Weblate tiene soporte para ganchos web de Gitea, agrega un Gancho de Gitea para el evento Notificar automáticamente eventos 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.
Recibir cambios automáticamente desde Repos Gitee¶
Weblate tiene soporte para los ganchos web de Gitee, añade un WebHook para el evento 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.
Actualizando repositorios automáticamente por la noche¶
Weblate busca automáticamente repositorios remotos todas las noches para mejorar el rendimiento al fusionar cambios más adelante. Opcionalmente, también puedes convertir esto en fusiones nocturnas, habilitando AUTO_UPDATE.
Enviar cambios efectuados en Weblate¶
Cada componente de traducción puede tener una URL de envío configurada (consulte URL de envío al repositorio ), y en ese caso Weblate podrá enviar cambios al repositorio remoto . Weblate también puede configurarse para enviar cambios automáticamente en cada confirmación (esto es predeterminado, consulte Enviar al consignar). Si no desea que los cambios se envíen automáticamente, puede hacerlo manualmente en Mantenimiento del repositorio o usando la API a través de wlc push.
Las opciones de subir difieren basadas en la Integración de control de versiones utilizada, más detalles son encontrados en ese capítulo.
En caso de que no desee envíos directos por Weblate, hay mantenimiento para Solicitudes de incorporación de GitHub, Solicitudes de fusión de GitLab, Solicitudes de incorporación de Gitea, Solicitudes de fusión de Pagure, Azure DevOps pull requests solicitudes de extracción o Gerrit revisiones, puede activarlas eligiendo GitHub, GitLab, Gitea, Gerrit, Azure DevOps o Pagure como Sistema de control de versiones en Configuración de componentes.
De manera general, están disponibles las opciones siguientes con Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center y Bitbucket Cloud:
Configuración deseada |
|||
|---|---|---|---|
No enviar |
empty |
empty |
|
Enviar directamente |
URL SSH |
empty |
|
Enviar en una rama separada |
URL SSH |
Nombre de rama |
|
No enviar |
empty |
empty |
|
Enviar directamente |
URL SSH |
empty |
|
Enviar en una rama separada |
URL SSH |
Nombre de rama |
|
Solicitud de extracción GitHub desde bifurcación |
empty |
empty |
|
Solicitud de extracción GitHub desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicita fusión de GitLab desde bifurcación |
empty |
empty |
|
Fusión GitLab solicitada desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicitud de fusión de Gitea desde la bifurcación |
empty |
empty |
|
Solicitud de fusión Gitea desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicitud de fusión Pagure desde bifurcación |
empty |
empty |
|
Solicitud de fusión Pagure desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicitud de fusión Azure DevOps desde bifurcación |
empty |
empty |
|
Solicitud de extracción Azure DevOps desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicitud de extracción Bitbucket Data Center desde bifurcación |
empty |
empty |
|
Solicitud de extracción Bitbucket Data Center desde rama |
SSH URL [1] |
Nombre de rama |
|
Solicitud de extracción Bitbucket Cloud desde bifurcación |
empty |
empty |
|
Solicitud de extracción Bitbucket Cloud desde rama |
SSH URL [1] |
Nombre de rama |
Nota
También puedes habilitar el empuje automático de cambios tras cometer Weblate, esto puede ser hecho en Enviar al consignar.
Ver también
Consulte Accessing repositories para configurar claves SSH, y Consignas diferidas para informe sobre cuando Weblate decida consignar cambios.
Ramas protegidas¶
Si está utilizando Weblate en ramas protegidas, puede configurarla para utilizar solicitudes de envío y realizar revisión actual en las traducciones (que tal vez es problemática para idiomas que no conozca). Una aproximación alternativa es renunciar esta limitación para el usuario Weblate.
Por ejemplo en GitHub esto puede realizarse en la configuración del repositorio:
Interactuar con otros¶
Weblate facilita la interacción con otras herramientas mediante su API.
Ver también
Consignas diferidas¶
El comportamiento de Weblate es agrupar las confirmaciones del mismo autor en una sola , si es posible. Esto reduce en gran medida la cantidad de confirmaciones, sin embargo, es posible que deba indicarle explícitamente que realice las confirmaciones en caso de que desee sincronizar el repositorio VCS , por ejemplo, para la fusión (esto está permitido de manera predeterminada para el grupo Administradores, consulte Lista de privilegios).
Los cambios en esta modalidad se consignan una vez que cualquiera de estas condiciones se cumpla:
Alguien más modifica una cadena ya modificada.
Se produce una fusión desde el origen ascendente.
Se solicita explícitamente una consigna.
Se solicita una descarga de archivos.
El cambio es anterior al período definido como Antigüedad de cambios por consignar en Configuración de componentes.
Consejo
Efectuados son creados para cada componente. Por tanto en caso que tenfa muchos componentes aún consulte el lote de instrucciones. Quizá utilice Concentrar consignas de Git agregado en ese caso.
Si deseas confirmar cambios con mayor frecuencia y sin verificar la antigüedad, puedes programar una tarea regular para realizar una confirmación. Esto se puede hacer usando Tareas periódicas en La interfaz administrativa de Django. Primero crea el Intervalo deseado (por ejemplo, 120 segundos). Luego, agregue una nueva tarea periódica y elija weblate.trans.tasks.commit_pending como Tarea con {"hours": 0} como Argumentos de palabras clave y el intervalo deseado.
Procesar repositorio con guiones¶
La manera de personalizar como Weblate interactúa con el repositorio está en Complementos. Consulte Ejecutar scripts desde el complemento para informe sobre como ejecutar guiones externos a través de agregados.
Mantener las mismas traducciones entre componentes¶
Una vez que tiene múltiples componentes de traducción, quizá desea asegurar que las mismas cadenas tienen la misma traducción. Esto puede ser logrado en varios niveles.
Propagación de traducción¶
Con Permitir propagación de traducciones activado (que es lo predet., consulte Configuración de componentes), todas las traducciones nuevas son realizadas automáticamente en todos los componentes con cadenas coincidentes. Tales traducciones son apropiadamente crediticias al usuario de traducción actualmente en todos los componentes.
Propagation preconditions:
All components have to reside in a single project (linking component is not enough).
Enable Permitir propagación de traducciones to automatically reuse translations for matching strings.
La propagación de traducción requiere la clave para ser coincidida para formatos de traducción monolingual, por tanto conseve eso en mente cuando cree claves de traducción.
The strings are propagated while translating, strings loaded from the repository are not propagated.
Truco
This feature currently has limitations, and we want to make it more universal. Please share your feedback at https://github.com/WeblateOrg/weblate/issues/3166.
Comprobación de coherencia¶
La comprobación Incoherente dispara en cuanto las cadenas son diferentes. Puede utilizar esto para revisar tales diferencias manualmente y elija la traducción correcta.
Traducción automática¶
La traducción automática basada en diferentes componentes puede ser una forma de sincronizar las traducciones entre componentes. Puede activarla manualmente (véase Traducción automática) o hacer que se ejecute automáticamente al actualizar el repositorio mediante un complemento (consulte Traducción automática).