Localização contínua

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

Ver também

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

Este é o processo:

  1. Os desenvolvedores fazem alterações e fazem push delas para o repositório VCS.

  2. Opcionalmente, os arquivos de tradução são atualizados, consulte Introducing new strings.

  3. O Weblate extrai as alterações do repositório VCS, analisa os arquivos de tradução e atualiza o banco de dados, consulte Atualizando repositórios.

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

  5. Quando os tradutores terminam, o Weblate faz o commit das alterações no repositório local (consulte Commits adiados).

  6. As alterações são enviadas de volta ao repositório upstream (consulte Fazendo push das alterações do 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 "]; }

Dica

A hospedagem de código upstream não é necessária, você pode usar o Weblate com Arquivos locais onde há apenas o repositório dentro do Weblate.

Atualizando repositórios

Você deve configurar alguma maneira de atualizar repositórios de backend a partir de sua fonte.

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

Evitando conflitos de mesclagem

Os conflitos de mesclagem do Weblate surgem quando o mesmo arquivo 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 ele descarte alterações antes de atualizar os arquivos fora do Weblate.

A primeira abordagem é fácil com arquivos monolíngues — você pode adicionar novos textos no Weblate e deixar a edição completa dos arquivos lá. Para arquivos bilíngues, geralmente há algum tipo de processo de extração de mensagens para gerar arquivos traduzíveis a partir 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 usando xgettext) e, em seguida, o processo mais mescla-o em traduções reais (os arquivos GETTEXT PO são atualizados usando msgmerge). Você pode executar o segundo passo dentro do Weblate e ele garantirá que todas as alterações pendentes sejam incluídas antes desta operação.

A segunda abordagem pode ser alcançada usando API REST do Weblate para forçar o Weblate a fazer push de todas as alterações pendentes e bloquear a tradução enquanto você 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 você tiver vários componentes compartilhando o mesmo repositório, você precisa bloqueá-los todos separadamente:

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

Nota

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

Evitando conflitos de mesclagem em alterações originadas no Weblate

Mesmo quando o Weblate é a única fonte das alterações nos arquivos de tradução, podem surgir conflitos quando se usa a extensão Squash de commits git, Estilo de mesclagem está configurado para Rebase ou você está esmagando commits fora do Weblate (por exemplo, ao mesclar um pull request).

O motivo dos conflitos de mesclagem é diferente neste caso - existem alterações no Weblate que ocorreram após você mesclar commits do Weblate. Isso geralmente acontece se a mesclagem não for automatizada e aguardar dias ou semanas para que um humano as revise. O Git às vezes não consegue mais identificar as alterações upstream como correspondentes às do Weblate e se recusa a realizar um rebase.

Para abordar isso, você precisa minimizar a quantidade de alterações pendentes no Weblate ao mesclar um pull request, ou evitar os conflitos completamente ao não mesclar as alterações.

Aqui estão algumas opções de como evitar isso:

  • Não use Squash de commits git nem squash no momento da mesclagem. Essa é a causa raiz do fato de o git não reconhecer as alterações após a mesclagem.

  • Permita que o Weblate commit as alterações pendentes antes de mesclar. Isso atualizará o pull request com todas as suas alterações e ambos os repositórios estarão sincronizados.

  • Use os recursos de revisão no Weblate (consulte Fluxos de trabalho de tradução), para que você possa mesclar automaticamente os pull requests do GitHub após a aprovação do CI.

  • Use o bloqueio no Weblate para evitar alterações enquanto o pull request do GitHub estiver sendo revisado.

Ver também

Weblate Client

Recebendo automaticamente alterações do GitHub

O Weblate vem com suporte nativo ao GitHub.

Se você estiver usando o Hosted Weblate, a abordagem recomendada é instalar o aplicativo Weblate, dessa forma você terá a configuração correta sem ter que configurar muita coisa. 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/.

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

Recebendo automaticamente alterações do Bitbucket

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

Recebendo automaticamente alterações do GitLab

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/).

Recebendo automaticamente alterações do Pagure

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 no Web-hooks em Project options:

../_images/pagure-webhook.png

Recebendo automaticamente alterações do Azure Repos

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

Recebendo automaticamente alterações do Gitea Repos

Weblate tem suporte para webhooks do Gitea, adicione um Gitea Webhook para evento Push events com destino para a 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.

Recebendo automaticamente alterações de Gitee Repos

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.

Atualizando automaticamente repositórios nightly

O Weblate busca automaticamente repositórios remotos nightly para melhorar o desempenho ao mesclar alterações mais tarde. Você 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 envio do repositório) e, nesse caso, o Weblate será capaz de fazer push de alteração para o repositório remoto. O Weblate também pode ser configurado para fazer push automaticamente das alterações em cada commit (isso é o padrão, veja Enviar ao fazer commit). Se você não quiser que seja feito push automático das alterações, você pode fazer isso manualmente em Manutenção do repositório ou usando API via wlc push.

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

Caso você não queira pushes diretos pelo Weblate, há suporte para Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Merge requests do Pagure, solicitações pull Azure DevOps pull requests ou revisões Gerrit, você pode ativá-las escolhendo GitHub, GitLab, Gitea, Gerrit, Azure DevOps ou Pagure como Sistema de controle de versão em Configuração de componente.

No geral, as seguintes opções estão disponíveis com Git, Mercurial, GitHub, GitLab, Gitea, Pagure e Azure DevOps:

Configuração desejada

Sistema de controle de versão

URL de envio do repositório

Ramo do push

Sem push

Git

vazio

vazio

Push diretamente

Git

URL de SSH

vazio

Fazer push para ramo separado

Git

URL de SSH

Nome do ramo

Sem push

Mercurial

vazio

vazio

Push diretamente

Mercurial

URL de SSH

vazio

Fazer push para ramo separado

Mercurial

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

Solicitação pull do Azure DevOps a partir do fork

Azure DevOps pull requests

vazio

vazio

Solicitação pull do Azure DevOps a partir do branch

Azure DevOps pull requests

URL de SSH [1]

Nome do ramo

Nota

Você também pode habilitar o push automático de alterações após o Weblate fazer commit, isso pode ser feito em Enviar ao fazer commit.

Ver também

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

Ramos protegidos

Se você estiver usando o Weblate em ramo protegido, você 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 você não conhece). Uma abordagem alternativa é abrir mão desta limitação em favor do usuário de push no Weblate.

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

../_images/github-protected.png

Interagindo com os outros

O Weblate facilita a interação com outras pessoas usando sua API.

Ver também

API REST do Weblate

Commits adiados

O comportamento do Weblate é agrupar commits do mesmo autor em um só commit, se possível. Isso reduz consideravelmente o número de commits, no entanto, você pode precisar dizer explicitamente para ele fazer os commits no caso de você querer deixar o repositório VCS em sincronia, por exemplo, para mesclagem (isso é por padrão permitido para o grupo Gerenciadores, consulte Lista de privilégios).

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

Dica

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

Se quiser confirmar as alterações com mais frequência e sem verificações de idade, você pode agendar uma tarefa regular para realizar um commit. Isso pode ser feito usando Tarefas Periódicas em A interface administrativa do Django. Primeiro, crie o Intervalo desejado (por exemplo, 120 segundos). Em seguida, adicione uma nova tarefa periódica e escolha weblate.trans.tasks.commit_pending como Tarefa com {"hours": 0} como Argumentos de Palavra-chave e o intervalo desejado.

Processando 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.

Mantendo traduções iguais entre componentes

Uma vez que você tenha vários componentes de tradução, você pode querer garantir que os mesmos textos tenham a mesma tradução. Isso pode ser alcançado em vários níveis.

Propagação de tradução

Com Permitir propagação de tradução habilitada (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 usuário 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 os textos são diferentes. Você pode usar isso para revisar 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. Você 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).