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 describes basic ways to integrate your development with Weblate.

This is the process:

  1. Developers make changes and push them to the VCS repository.

  2. Opcionalmente los archivos de traducción se actualizan , ver Introducing new strings.

  3. Weblate extrae los cambios del repositorio VCS , analiza los archivos de traducción y actualiza su base de datos, consulte Updating repositories .

  4. Los traductores envían las traducciones a través de la interfaz web de Weblate o cargan los cambios sin conexión.

  5. Una vez que los traductores han terminado, Weblate confirma los cambios en el repositorio local (véase Consignas diferidas).

  6. Changes are pushed back to the upstream repository (see Enviar cambios efectuados en Weblate).

digraph translations { graph [fontname = "sans-serif", fontsize=10, ranksep=0.6, newrank=true]; node [fontname = "sans-serif", fontsize=10, margin=0.15]; edge [fontname = "sans-serif", fontsize=10]; subgraph cluster_codehosting { rank=same; graph [color=lightgrey, label="Upstream code hosting", style=filled ]; "VCS repository" [shape=cylinder]; } subgraph cluster_weblate { rank=same; graph [color=lightgrey, label="Weblate", style=filled ]; repo [label="Weblate repository", shape=cylinder]; database [label=Database, shape=cylinder]; } "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> repo [label=" 3. Pull "]; repo -> database [label=" 3. Parse translations "]; "database" -> repo [label=" 5. Commit changes "]; "Translators" -> "database" [label=" 4. Translate "]; "repo" -> "VCS repository" [label=" 6. Push repository "]; }

Consejo

Upstream code hosting is not necessary, you can use Weblate with Archivos locales where there is only the repository inside Weblate.

Updating repositories

You should set up some way of updating backend repositories from their source.

Siempre que Weblate actualice el repositorio, se activarán los complementos posteriores a la actualización, consulte Complementos.

Evitar conflictos de fusión

The merge conflicts from Weblate arise when same file was changed both in Weblate and outside it. Depending on the situation, there are several approaches that might help here:

Avoiding merge conflicts by changing translation files in Weblate only

Avoiding edits outside Weblate is easy with monolingual files — you can add new strings within Weblate and leave whole editing of the files there. For bilingual files, there is usually some kind of message extraction process to generate translatable files from the source code. In some cases, this can be split into two parts:

  1. The extraction generates template (for example gettext POT is generated using xgettext).

  2. Further process merges it into actual translations (the gettext PO files are updated using msgmerge).

You can perform the second step within Weblate and it will ensure that all pending changes are included before this operation.

Avoiding merge conflicts by locking Weblate while doing outside changes

Integrating Weblate into your updating process so that it flushes changes before updating the files outside Weblate can be achieved by using API REST de Weblate to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.

El script para realizar actualizaciones puede verse así:

# 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

If you have multiple components sharing the same repository, you need to lock them all separately:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Nota

The example uses Cliente de Weblate, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of Cliente de Weblate, for example curl, see API REST de Weblate.

Avoiding merge conflicts by focusing on Git operations

Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Concentrar consignas de Git add-on, Estilo de fusión is configured to Rebase, or you are squashing commits outside of Weblate (for example, when merging a pull request).

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.

To approach this, you either need to minimize the amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.

Here are few options how to avoid that:

  • No utilice 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 después de la fusión.

  • Let Weblate commit pending changes before merging. This will update the pull request with all its changes, and both repositories will be in sync.

  • Use the review features in Weblate (see Flujos de trabajo de traducción) so that you can automatically merge GitHub pull requests after CI passes.

  • Use locking in Weblate to avoid changes while GitHub pull request is in review.

Ver también

Cliente de Weblate

Recibir cambios automáticamente de GitHub

Weblate admite GitHub nativamente.

If you are using Hosted Weblate, the recommended approach is to install the Weblate app, that way you will get the correct setup without having to set much up. It can also be used for pushing changes back.

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:

../_images/github-settings.png

The Payload URL consists of your Weblate URL appended by /hooks/github/, for example for the Hosted Weblate service, this is https://hosted.weblate.org/hooks/github/.

You can leave other values at default settings (Weblate can handle both content types and consumes just the push event).

Recibir cambios automáticamente de Bitbucket

Weblate has support for Bitbucket webhooks, add a webhook which triggers upon repository push, with destination to /hooks/bitbucket/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/bitbucket/).

../_images/bitbucket-settings.png

Automatically receiving changes from GitLab

Weblate has support for GitLab hooks, add a project webhook with destination to /hooks/gitlab/ URL on your Weblate installation (for example 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:

../_images/pagure-webhook.png

Recibir cambios automáticamente de Azure Repos

Weblate tiene soporte para webhooks de Azure Repos. Agregue un webhook 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 :guilabel:` Configuración del proyecto` .

Recibir cambios automáticamente de Gitea

Weblate tiene soporte para webhooks de Gitea, agrega un Gitea Webhook 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 en el repositorio Ajustes.

Recibir cambios automáticamente de Gitee

Weblate tiene soporte para los webhooks de Gitee, añade un WebHook para el evento Notificar automáticamente ` 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 Gestión.

Automatically updating repositories nightly

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 (ver 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, ver Enviar al consignar). Si no desea que los cambios se envíen automáticamente, puede hacerlo manualmente en :guilabel:` Mantenimiento del repositorio` o usando la API a través de wlc push.

The push options differ based on the Integración de control de versiones used, more details are found in that chapter.

En caso de que no desee envíos directos por Weblate , hay soporte 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 `, :guilabel:`Azure DevOps o Pagure como Sistema de control de versiones en Configuración de componentes.

Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center and Bitbucket Cloud:

Configuración deseada

Sistema de control de versiones

URL de envío al repositorio

Rama a la que enviar

No push

Git

empty

empty

Enviar directamente

Git

URL SSH

empty

Enviar en una rama separada

Git

URL SSH

Nombre de la rama

No push

Mercurial

empty

empty

Enviar directamente

Mercurial

URL SSH

empty

Enviar en una rama separada

Mercurial

URL SSH

Nombre de la rama

GitHub pull request from fork

Solicitudes de incorporación de GitHub

empty

empty

GitHub pull request from branch

Solicitudes de incorporación de GitHub

SSH URL [1]

Nombre de la rama

GitLab merge request from fork

Solicitudes de fusión de GitLab

empty

empty

GitLab merge request from branch

Solicitudes de fusión de GitLab

SSH URL [1]

Nombre de la rama

Solicitud de fusión de Gitea desde la bifurcación

Solicitudes de incorporación de Gitea

empty

empty

Gitea la solicitud de fusión desde la rama

Solicitudes de incorporación de Gitea

SSH URL [1]

Nombre de la rama

Pagure merge request from fork

Solicitudes de fusión de Pagure

empty

empty

Pagure merge request from branch

Solicitudes de fusión de Pagure

SSH URL [1]

Nombre de la rama

Azure DevOps pull request from fork

Azure DevOps pull requests

empty

empty

Azure DevOps pull request from branch

Azure DevOps pull requests

SSH URL [1]

Nombre de la rama

Bitbucket Data Center pull request from fork

Bitbucket Data Center pull requests

empty

empty

Bitbucket Data Center pull request from branch

Bitbucket Data Center pull requests

SSH URL [1]

Nombre de la rama

Bitbucket Cloud pull request from fork

Bitbucket Cloud pull requests

empty

empty

Bitbucket Cloud pull request from branch

Bitbucket Cloud pull requests

SSH URL [1]

Nombre de la rama

Nota

You can also enable automatic pushing of changes after Weblate commits, this can be done in Enviar al consignar.

Ver también

See Accessing repositories for setting up SSH keys, and Consignas diferidas for info about when Weblate decides to commit changes.

Ramas protegidas

If you are using Weblate on protected branch, you can configure it to use pull requests and perform actual review on the translations (what might be problematic for languages you do not know). An alternative approach is to waive this limitation for the Weblate push user.

For example on GitHub this can be done in the repository configuration:

../_images/github-protected.png

Interactuar con otros

Weblate facilita la interacción con otras herramientas mediante su API.

Ver también

API REST de Weblate

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:

Consejo

Commits are created for every component. So in case you have many components you will still see lot of commits. You might utilize Concentrar consignas de Git add-on in that case.

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 el repositorio con secuencias

The way to customize how Weblate interacts with the repository is Complementos. Consult Ejecutar scripts desde el complemento for info on how to execute external scripts through add-ons.

Mantener iguales las traducciones entre los componentes

Once you have multiple translation components, you might want to ensure that the same strings have same translation. This can be achieved at several levels.

Propagación de traducciones

With Permitir propagación de traducciones enabled (what is the default, see Configuración de componentes), all new translations are automatically done in all components with matching strings. Such translations are properly credited to currently translating user in all components.

Nota

The translation propagation requires the key to be match for monolingual translation formats, so keep that in mind when creating translation keys.

Comprobación de coherencia

The Incoherente check fires whenever the strings are different. You can utilize this to review such differences manually and choose the right translation.

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 (véase Traducción automática).