Tradução contínua

Há infraestrutura em vigor para que a sua tradução acompanhe o desenvolvimento de perto . Desta forma, os tradutores podem trabalhar em traduções o tempo todo, em vez de trabalhar com uma enorme quantidade de texto novo pouco antes do lançamento.

Veja também

Integrando com Weblate descreve maneiras básicas de integrar o seu desenvolvimento com o Weblate.

O processo é o seguinte:

  1. Os programadores fazem alterações e fazem push delas so repositório VCS.

  2. Opcionalmente, os ficheiros de tradução são atualizados (isso depende do formato do ficheiro, consulte Por que é que o Weblate ainda mostra as cadeias de tradução antigas quando atualizei o modelo?).

  3. O Weblate faz o pull das alterações do repositório VCS, consulte Atualizar repositórios.

  4. Uma vez que o Weblate deteta alterações nas traduções, os tradutores são notificados com base na configurações de assinatura deles.

  5. Os tradutores enviam traduções a usar a interface web do Weblate ou enviam alterações feitas offline.

  6. Uma vez que os tradutores acabaram, o Weblate faz commit das alterações no repositório local (veja Commits adiados) e faz push delas de volta se tiver permissões para fazê-lo (veja Fazendo push das alterações do Weblate).

digraph translations { graph [fontname = "sans-serif", fontsize=10]; node [fontname = "sans-serif", fontsize=10, margin=0.1, height=0]; edge [fontname = "sans-serif", fontsize=10]; "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" -> "Weblate" [label=" 3. Pull "]; "Weblate" -> "Translators" [label=" 4. Notification "]; "Translators" -> "Weblate" [label=" 5. Translate "]; "Weblate" -> "VCS repository" [label=" 6. Push "]; }

Atualizar repositórios

Deve configurar alguma maneira de atualizar repositórios de backend a partir da fonte dele.

Sempre que o Weblate atualiza o repositório, as extensões de pós-atualização serão acionadas, consulte Extensões.

Evitar conflitos de mesclagem

Os conflitos de mesclagem do Weblate surgem quando o mesmo ficheiro foi alterado tanto no Weblate quanto fora dele. Existem duas abordagens para lidar com isso - evitar edições fora do Weblate ou integrar o Weblate no seu processo de atualização, de modo que descarte alterações antes de atualizar os ficheiros fora do Weblate.

A primeira abordagem é fácil com ficheiros monolingues - pode adicionar novas cadeias no Weblate e deixar a edição completa dos ficheiros lá. Para ficheiros bilíngues, geralmente há algum tipo de processo de extração de mensagens para gerar ficheiros traduzíveis do código-fonte. Em alguns casos, isso pode ser dividido em duas partes - uma para a extração gera modelo (por exemplo, o GETTEXT POT é gerado a usar xgettext) e depois o processo a seguir mescla-o em traduções reais (os ficheiros GETTEXT PO são atualizados a usar msgmerge). Pode executar o segundo passo dentro do Weblate e garantirá que todas as alterações pendentes sejam incluídas antes desta operação.

A segunda abordagem pode ser alcançada a usar o API REST do Weblate para forçar o Weblate a fazer push de todas as alterações pendentes e bloquear a tradução enquanto está fazendo alterações do seu lado.

O script para fazer atualizações pode ser assim:

# 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

Se tiver vários componentes compartilhando o mesmo repositório, deve bloqueá-los todos separadamente:

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

Nota

O exemplo usa Cliente Weblate, que precisa de configuração (chaves de API) para ser capaz de controlar o Weblate remotamente. Também pode conseguir isso a usar qualquer cliente HTTP em vez de wlc, por exemplo, curl, ver API REST do Weblate.

Veja também

Cliente Weblate

Receber alterações do GitHub automaticamente

O Weblate vem com suporte nativo ao GitHub.

Se estiver a usar o Hosted Weblate, a abordagem recomendada é instalar o app Weblate, dessa forma terá a configuração correta sem ter que configurar muito. Também pode ser usado para fazer push de mudanças de volta.

Para receber notificações em cada push a um repositório do GitHub, adicione o webhook do Weblate nas configurações do repositório (Webhooks) como mostrado na imagem abaixo:

../_images/github-settings.png

Para a URL de carga útil, anexar /hooks/github/ à URL do Weblate, por exemplo, para o serviço Hosted Weblate, este é https://hosted.weblate.org/hooks/github/.

Pode deixar outros valores nas configurações predefinidas (o Weblate pode lidar com ambos os tipos de conteúdo e consome apenas o evento push).

Receber alterações do Bitbucket automaticamente

O Weblate tem suporte para webhooks do Bitbucket, adicione um webhook que aciona no push do repositório, com destino a URL /hooks/bitbucket/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/bitbucket/).

../_images/bitbucket-settings.png

Receber alterações do GitLab automaticamente

O Weblate tem suporte para ganchos do GitLab, adiciona um webhook de projeto com destino a URL /hooks/gitlab/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/gitlab/).

Receber alterações do Pagure automaticamente

Novo na versão 3.3.

O Weblate tem suporte para ganchos Pagure. Adicione um webhook com destino a URL /hooks/pagure/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/pagure/). Isso pode ser feito em Web-hooks em Project options:

../_images/pagure-webhook.png

Receber alterações dos Azure Repos automaticamente

Novo na versão 3.8.

O Weblate tem suporte para webhooks dos Azure Repos, adicione um webhook para o evento Code pushed com destino para URL /ganchos/azure/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/azure/). Isso pode ser feito em Service hooks ` em :guilabel:`Project settings.

Receber alterações dos Gitea Repos automaticamente

Novo na versão 3.9.

Weblate tem suporte para webhooks do Gitea, adicione um Gitea Webhook para o evento Push events com destino ao URL /hooks/gitea/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/gitea/). Isso pode ser feito no Webhooks em Settings do repositório.

Receber alterações de Gitee Repos automaticamente

Novo na versão 3.9.

O Weblate tem suporte para webhooks Gitee, adicione um WebHook para o evento Push com destino para URL /hooks/gitee/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/gitee/). Isso pode ser feito em WebHooks sob Management do repositório.

Atualizar repositórios nightly automaticamente

O Weblate busca automaticamente repositórios remotos nightly para melhorar o desempenho ao mesclar alterações mais tarde. Pode opcionalmente transformar isso em fazer mesclagens noturnas também, ativando AUTO_UPDATE.

Fazendo push das alterações do Weblate

Cada componente de tradução pode ter uma URL de push configurada (veja URL de submissão do repositório) e, nesse caso, o Weblate será capaz de fazer push da alteração ao repositório remoto. O Weblate também pode ser configurado para fazer push automaticamente das alterações em cada commit (isso é a predefinição, veja Enviar ao submeter). Se não quiser que seja feito push automático das alterações, pode fazer-lo manualmente em Manutenção do repositório ou a usar API via wlc push.

As opções de push diferem com base no Integração de controlo de versões usado, mais detalhes são encontrados nesse capítulo.

No caso de não querer pushes diretos pelo Weblate, há suporte para pull requests do Pull requests do GitHub, do Merge requests do GitLab, do Pull requests do Gitea e do Merge requests do Pagure ou revisões do Gerrit, pode ativá-los escolhendo GitHub, GitLab, Gitea, Gerrit ou Pagure, como Sistema de controlo de versões em Configuração de componente.

No geral, as opções a seguir estão disponíveis com Git, GitHub e GitLab:

Configuração desejada

Sistema de controlo de versões

URL de submissão do repositório

Ramo do push

Sem push

Git

vazio

vazio

Push diretamente

Git

URL de SSH

vazio

Empurrar para um ramo separado

Git

URL de SSH

Nome do ramo

Pull request de GitHub do fork

Pull requests do GitHub

vazio

vazio

Pull request de GitHub do ramo

Pull requests do GitHub

URL de SSH [1]

Nome do ramo

Merge request de GitLab do fork

Merge requests do GitLab

vazio

vazio

Merge request de GitLab do ramo

Merge requests do GitLab

URL de SSH [1]

Nome do ramo

Merge request de Gitea do fork

Pull requests do Gitea

vazio

vazio

Merge request de Gitea do ramo

Pull requests do Gitea

URL de SSH [1]

Nome do ramo

Merge request de Pagure do fork

Merge requests do Pagure

vazio

vazio

Merge request de Pagure do ramo

Merge requests do Pagure

URL de SSH [1]

Nome do ramo

Nota

Também pode ativar o push automático de alterações após o Weblate fazer commit, isso pode ser feito em Enviar ao submeter.

Veja também

Consulte Acessando repositórios para configurar chaves de SSH e Commits adiados para obter informações sobre quando o Weblate decide fazer commit de alterações.

Ramos protegidos

Se estiver a usar o Weblate em ramo protegido, pode configurá-lo para usar pull requests e executar revisão real sobre as traduções (o que pode ser problemático para idiomas que não conhece). Uma abordagem alternativa é abrir mão desta limitação em favor do utilizador de push no Weblate.

Por exemplo, no GitHub, isso pode ser feito na configuração do repositório:

../_images/github-protected.png

Interagir com os outros

O Weblate facilita a interação com outras pessoas a usar a API dele.

Veja também

API REST do Weblate

Commits adiados

O comportamento do Weblate é de agrupar commits do mesmo autor num só commit, se for possível. Isso reduz a quantidade de commits consideravelmente, no entanto, pode precisar de dizer explicitamente para fazer os commits no caso de querer deixar o repositório VCS em sincronia, por exemplo, para mesclarem (isso é por predefinição permitido para o grupo Managers, consulte Lista de privilégios e funções embutidas).

As alterações neste modo têm o commit delas feitas assim que qualquer uma das seguintes condições são cumpridas:

Dica

Os commits são criados para cada componente. Então, caso tenha muitos componentes, ainda verá muitos compromissos. Pode utilizar a extensão Squash de commits git neste caso.

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit. This can be done using Periodic Tasks in A interface administrativa do Django. First create desired Interval (for example 120 seconds). Then add new periodic task and choose weblate.trans.tasks.commit_pending as Task with {"hours": 0} as Keyword Arguments and desired interval.

Processar repositório com scripts

A maneira de personalizar como o Weblate interage com o repositório é com Extensões. Consulte Escrevendo scripts para extensões para obter informações sobre como executar scripts externos através de extensões.

Manter traduções iguais entre componentes

Uma vez que tenha vários componentes de tradução, pode garantir que as mesmas cadeias tenham a mesma tradução. Isso pode ser alcançado em vários níveis.

Propagação de tradução

Com Permitir propagação da tradução ativada (que é o padrão, consulte Configuração de componente), todas as novas traduções são feitas automaticamente em todos os componentes com textos correspondentes. Estas traduções são devidamente creditadas ao utilizador que traduz atualmente em todos os componentes.

Nota

A propagação de tradução requer a chave para ser compatível com formatos de tradução monolíngue, por isso tenha isso em mente ao criar chaves de tradução.

Verificação de consistência

A verificação check-inconsistente é acionada sempre que as cadeias são diferentes. Pode usar isso para rever tais diferenças manualmente e escolher a tradução certa.

Tradução automática

A tradução automática com base em diferentes componentes pode ser uma maneira de sincronizar as traduções entre os componentes. Pode acioná-la manualmente (veja Tradução automática) ou fazê-la ser executada automaticamente na atualização do repositório usando uma extensão (veja Tradução automática).