Tradução contínua

Existe uma infraestrutura em vigor para que a sua tradução acompanhe de perto o desenvolvimento. Desta forma, os tradutores podem trabalhar sempre nas traduções, em vez de trabalharem com uma enorme quantidade de novos textos pouco antes do lançamento.

Veja também

Integrando com Weblate describes basic ways to integrate your development with Weblate. Code-hosting integrations lists provider-specific setup steps for common code-hosting sites.

O processo é o seguinte:

1. Os programadores fazem alterações e submetem-nas ao repositório VCS.

2. Opcionalmente, os ficheiros de tradução são atualizados, consulte Introduzindo novas cadeias de carateres.

3. O Weblate extrai as alterações do repositório VCS, analisa os ficheiros de tradução e atualiza a base de dados, consulte Atualizar repositórios.

4. Os tradutores enviam traduções a usar 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 para o repositório principal (consulte Fazendo push das alterações do Weblate).

Dica

Upstream code-hosting site is not necessary, you can use Weblate with Ficheiros locais where there is only the repository inside Weblate.

Atualizar repositórios

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

• Use Hooks de notificação to integrate with the majority of common code-hosting services, see Code-hosting integrations. You must also Ativar hooks for this to work.

• Acione manualmente a atualização na gestão do repositório ou a usar API REST do Weblate ou Cliente Weblate

• Ative AUTO_UPDATE para atualizar todos os componentes na sua instância Weblate automaticamente

• Execute updategit (com a seleção de um projeto ou --all para atualizar tudo)

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. Dependendo da situação, há várias abordagens que podem ajudar aqui:

• Evitar conflitos de mesclagem alterando ficheiros de tradução somente no Weblate

• Evitar conflitos de mesclagem bloqueando o Weblate ao fazer alterações externas

• Evitar conflitos de mesclagem concentrando operações no Git

Evitar conflitos de mesclagem alterando ficheiros de tradução somente no Weblate

Evitar edições fora do Weblate é fácil com ficheiros monolíngues — 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 a partir do código-fonte. Em alguns casos, isto pode ser dividido em duas partes:

1. A extração gera modelo (por exemplo, o Gettext POT é gerado usando xgettext).

2. Em seguida, o processo mais mescla-o em traduções reais (os ficheiros Gettext PO são atualizados usando msgmerge).

Pode executar o segundo passo dentro do Weblate e ele garantirá que todas as alterações pendentes sejam incluídas antes desta operação.

Evitar conflitos de mesclagem bloqueando o Weblate ao fazer alterações externas

A integração do Weblate no seu processo de atualização para que ele libere as alterações antes de atualizar os ficheiros fora do Weblate 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 faz 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 partilhando o mesmo repositório, precisa bloqueá-los todos separadamente:

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

Nota

O exemplo utiliza Cliente Weblate, que precisa de configuração (chaves da API) para poder controlar o Weblate remotamente. Também pode conseguir isto utilizando qualquer cliente HTTP, em vez de Cliente Weblate, por exemplo, curl, ver API REST do Weblate.

Manutenção do repositório

A vista de Repositório de manutenção mostra o estado do repositório para um projeto, componente, ou tradução e permite utilizadores privilegiados de executar operações de manutenção a partir da interface de utilizador.

As mesmas ações também podem ser ativadas usando API REST do Weblate ou, para o subconjunto suportado, Cliente Weblate.

Disponibilidade de ações individuais depende de permissões, da versão de sistema de controlo, se dar push está configurado, e se o objeto selecionado pode ser bloqueado.

As ações Gestão de ficheiro estão disponíveis apenas a partir de Manutenção de repositório para uma tradução individual. Estas ações rescrevem esse ficheiro de tradução e fazem commit do resultado; elas não são operações ao nível do projeto ou do componente.

Operações que leem conteúdo do repositório, tal como atualizar, reiniciar, ou reanalisar, também reconciliam ficheiros de tradução no Weblate. Ficheiros de traduções adicionados ou removidos são refletidos após este procedimento terminar. Sincronização de glossário de idioma e limpeza são descritos em Language files and synchronization.

Ação	O que faz	Uso típico
Submeter	Envia mudanças pendentes armazenadas no Weblate para o repositório local.	Limpa as mudanças Weblate pendentes antes de fazer trabalho do repositório em outro sítio.
Enviar	Envia mudanças do repositório local para a fonte configurada.	Envia traduções para a fonte quando o envio automático está desativado ou atrasado.
Atualizar	Busca mudanças da fonte, integra-as usando o Estilo de união do componente configurado, e reconcilia ficheiros de tradução.	Mantém o Weblate sincronizado com a fonte usando a estratégia predefinida de integração.
Atualizar merge	Busca as mudanças na fonte e integra as mesmas com um merge explícito.	Sobrescreve o estilo predefinido d emerge para uma única atualização.
Atualizar com rebase	Busca as mudanças na fonte e dá rebase dos commits do Weblate local por cima da fonte.	Mantém o histórico linear quando isso corresponde ao seu fluxo de trabalho.
Atualizar com merge sem fast-forward	Busca mudanças na fonte e cria um merge commit explícito mesmo quando um fast-forward fosse possível.	Preserva merge commits para fins de auditoria ou razões de gestão de ramo.
Bloquear / Desbloquear	Previne ou permite que tradutores façam mudanças adicionais no Weblate.	Congelar mudanças de tradução ao fazer manutenção do repositório fora do Weblate.
Reiniciar e descartar	Reinicia o repositório Weblate local para a fonte, descarta mudanças Weblate pendentes, e reconcilia ficheiros de tradução.	Utilize quando a fonte deve sobrescrevem o estado do repositório Weblate local.
Reiniciar e reaplicar	Reinicia o repositório Weblate local para a fonte, reconcilia os ficheiros de tradução, e reaplica traduções pendentes. Veja Reiniciar e reaplicar comportamento de recuperação.	Recuperar de histórico divergido, mantendo as traduções pendentes do Weblate.
Limpar	Remove ficheiros não registado e ramos desatualizados do checkout do repositório local.	Limpa ficheiros residuais ou o estado desatualizado do repositório no checkout do Weblate.
Sincronizar	Força o Weblate a escrever todas as traduções conhecidas de volta para os ficheiros do repositório.	Repara casos onde os ficheiros de repositório ficam fora de sincroniza com o estado da base de dados.
Re-analisar	Lê ficheiros de tradução novamente a partir do repositório local para o Weblate e remove traduções cujos ficheiros já não correspondem à configuram de componente.	Importa mudanças de ficheiro após trabalho manual do repositório ou criação de ficheiro.
Remover duplicados	Remove cadeias de carateres duplicadas com o mesmo identificado de um ficheiro de tradução.	Repara cadeias de carateres duplicadas relatadas pelo Weblate quando o ficheiro contém unidades repetidas.
Limpar inutilizados	Remove cadeias de carateres que já não estão presentes no ficheiro base de um ficheiro de tradução. O extra Limpeza de ficheiros de tradução pode fazer isto automaticamente.	Executar uma limpeza pontual sem instalar o extra.
Remover obsoleto	Remove cadeias de carateres obsoletas de um ficheiro de tradução PO.	Executa uma limpeza pontual PO sem ativar a remoção automática de cadeias de carateres obsoletas.

Reiniciar e reaplicar comportamento de recuperação

A operação Reiniciar e reaplicar mantém traduções pendentes do Weblate enquanto reinicia o estado do repositório local para corresponder à fonte.

A operação pode restaurar traduções pendentes apenas quando os ficheiros de idioma alvo ainda existem após o reiniciar ou quando o Weblate pode criá-los para o componente, por exemplo usado um Modelo para novas traduções válido.

Se nenhuma destas condições forem cumpridas, o Weblate mantém as mudanças pendentes na sua base de dados e comunica um erro de recuperação em vez de falhar mais tarde com um erro genérico de análise.

Evitar conflitos de mesclagem concentrando operações no Git

Mesmo quando o Weblate é a única fonte das alterações nos ficheiros de tradução, podem surgir conflitos quando usar o complemento Squash de commits git, Estilo de união está configurado para Rebase ou esmaga commits fora do Weblate (por exemplo, ao mesclar um pull request).

O motivo dos conflitos de mesclagem é diferente neste caso. O Weblate pode ter novos commits locais após mesclar commits prévios do Weblate da fonte. Isto geralmente acontece se a mesclagem não for automatizada e as mudanças aguardam dias ou semanas por uma revisão humana. O Git às vezes não consegue mais identificar as alterações upstream como correspondentes às do Weblate e recusa-se a realizar um rebase.

Dar squash e fusão de alterações Weblate torna mais difícil recuperar a situação. Uma fusão squash cria uma nova submissão em vez de preservar as submissões Weblate individuais no histórico da fonte. O Weblate ainda tem as submissões originais no seu repositório local, e o Git já não pode provar que a fonte já os contém. Se o conflito foi resolvido manualmente, os conteúdos do ficheiro podem diferir de ambos os repositórios, e então o Weblate pode continuar a falhar em atualizar ainda após o pedido de submissão foi fundido na fonte.

Se a fonte já não contém commits Weblate porque foram squash merged, atualizar o repositório podem não ser suficiente. Utilize Reiniciar e reaplicar de Manutenção de repositório para reiniciar o Weblate para a fonte enquanto mantém as traduções pendentes; veja Reiniciar e reaplicar comportamento de recuperação. Utilize Reiniciar e descartar apenas quando a fonte deve substituir completamente as mudanças locais do Weblate.

Para abordar isto, 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 ou squash merging para mudanças Weblate. Squashing é o motivo pelo qual o Git pode não reconhecer as mudanças após dar merge.

• Ao resolver conflitos fora do Weblate, dê merge dos commits Weblate com um merge commit normal e envie esse resultado para a fonte. Não dê squash merge do pull request da resolução de conflitos.

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

• Utilize as funcionalidades de revisão no Weblate (consulte Fluxos de trabalho de tradução), e assim, pode unir automaticamente os pedidos de submissão do GitHub depois da aprovação do CI.

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

Veja também

Cliente Weblate

Code-hosting notifications

A aplicação específica de fornecedor e instruções do webhook para o GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, e Gitee são cobertos em Code-hosting integrations.

Notificações específicas ao fornecedor

Estas âncoras de legado são mantidas para compatibilidade. A aplicação atual específica ao fornecedor e a configuração de webhook são documentadas em Code-hosting integrations.

Veja também

• Notificações GitHub

• Notificações GitLab

• Notificações Bitbucket

• Notificações Pagure

• Notificações Azure Repos

• Notificações Gitea

• Notificações Forgejo

• Notificações Gitee

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, veja Enviar ao submeter.

Para a tabela de opções de push e pull específico de fornecedor, merge, e fluxos de trabalho de pedido de revisão, veja Fazendo push das alterações do Weblate.

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:

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

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

• Outra pessoa altera uma cadeia já alterada.

• Um merge do upstream é feito.

• Um commit explícito é solicitado.

• É solicitado a descarrega de um ficheiro.

• A alteração é mais antiga do que o período definido como Idade das alterações a fazer commit em Configuração de componente.

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.

Se quiser confirmar as alterações com mais frequência e sem verificações de idade, pode agendar uma tarefa regular para realizar um commit. Isto 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.

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 cadeias correspondentes. Estas traduções são devidamente creditadas ao utilizador que traduz atualmente em todos os componentes.

Pré-condições para propagação:

• Todos os componentes devem residir num único projeto (vincular componente não é suficiente).

• Ativar Permitir propagação da tradução para reusar automaticamente traduções para cadeias correspondentes.

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

• As cadeias são propagadas enquanto traduzir, cadeias carregadas a partir do repositório não são propagadas.

Dica

De momento, esta funcionalidade tem limitações e queremos torná-la mais universal. Partilhe a sua opinião em; consulte https://github.com/WeblateOrg/weblate/issues/3166

Verificação de consistência

A verificação 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 (consulte Tradução Automática) ou execute-a automaticamente na atualização do repositório utilizando um extra (consulte Tradução Automática).