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 descreve maneiras básicas de integrar o seu desenvolvimento com o Weblate.
O processo é o seguinte:
Os programadores fazem alterações e submetem-nas ao repositório VCS.
Opcionalmente, os ficheiros de tradução são atualizados, consulte Introduzindo novas cadeias de carateres.
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.
Os tradutores enviam traduções a usar a interface web do Weblate ou enviam alterações feitas offline.
Quando os tradutores terminam, o Weblate faz o commit das alterações no repositório local (consulte Commits adiados).
As alterações são enviadas de volta para o repositório principal (consulte Fazendo push das alterações do Weblate).
Dica
A hospedagem de código upstream não é necessária, pode usar o Weblate com Ficheiros locais onde há apenas o repositório dentro do Weblate.
Atualizar repositórios¶
Deve configurar alguma maneira de atualizar repositórios de backend a partir da fonte dele.
Use Hooks de notificação para integrar com a maioria dos serviços comuns de hospedagem de código:
Também deve Ativar hooks para que isto funcione.
Acione manualmente a atualização na gestão do repositório ou a usar API REST do Weblate ou Cliente Weblate
Ative
AUTO_UPDATEpara atualizar todos os componentes na sua instância Weblate automaticamenteExecute
updategit(com a seleção de um projeto ou--allpara 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 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:
A extração gera modelo (por exemplo, o Gettext POT é gerado usando xgettext).
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 usa Cliente Weblate, que precisa de configuração (chaves de API) para ser capaz de controlar o Weblate remotamente. Também pode conseguir isto usando qualquer cliente HTTP em vez de Cliente Weblate, por exemplo, curl, ver API REST do Weblate.
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 correspondo - existem alterações no Weblate que ocorreram após mesclar commits do Weblate. Isto 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 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 nem squash no momento da mesclagem. Esta é 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. 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
Receber alterações do GitHub automaticamente¶
O Weblate vem com suporte nativo ao GitHub.
Se estiver a utilizar o Hosted Weblate, a abordagem recomendada é instalar a aplicação Weblate, dessa forma terá a configuração correta sem ter que configurar muito. Esta também pode ser utilizada para submeter alterações.
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:
A Payload URL consiste na sua URL do Weblate anexada por /hooks/github/, por exemplo, para o serviço Hosted Weblate, é 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/).
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/).
Soluções de problemas
Check GitLab webhook request history if webhooks are delivered.
The response payload contains information about matched components.
Receber alterações do Pagure automaticamente¶
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:
Receber alterações dos Azure Repos automaticamente¶
O Weblate tem suporte para webhooks do Azure Repos, adicione um webhook para evento Código enviado com destino para URL /hooks/azure/ na instalação do Weblate (por exemplo, https://hosted.weblate.org/hooks/azure/). Isto pode ser feito no Ganchos de serviço em Configurações do projeto.
Receber alterações dos Gitea Repos automaticamente¶
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¶
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.
Automatically updating repositories nightly¶
Weblate automatically fetches remote repositories nightly to improve
performance when merging changes later. You can optionally turn this into doing
nightly merges as well, by enabling 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.
Caso 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 Pull requests do Azure DevOps ou revisões Gerrit, pode ativá-las escolhendo GitHub, GitLab, Gitea, Gerrit, Azure DevOps ou Pagure como Sistema de controlo de versões em Configuração de componente.
No geral, as seguintes opções estão disponíveis com Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center e Bitbucket Cloud:
Configuração desejada |
|||
|---|---|---|---|
Sem push |
vazio |
vazio |
|
Push diretamente |
URL de SSH |
vazio |
|
Empurrar para um ramo separado |
URL de SSH |
Nome do ramo |
|
Sem push |
vazio |
vazio |
|
Push diretamente |
URL de SSH |
vazio |
|
Empurrar para um ramo separado |
URL de SSH |
Nome do ramo |
|
Pull request de GitHub do fork |
vazio |
vazio |
|
Pull request de GitHub do ramo |
URL de SSH [1] |
Nome do ramo |
|
Merge request de GitLab do fork |
vazio |
vazio |
|
Merge request de GitLab do ramo |
URL de SSH [1] |
Nome do ramo |
|
Merge request de Gitea do fork |
vazio |
vazio |
|
Merge request de Gitea do ramo |
URL de SSH [1] |
Nome do ramo |
|
Merge request de Pagure do fork |
vazio |
vazio |
|
Merge request de Pagure do ramo |
URL de SSH [1] |
Nome do ramo |
|
Solicitação pull do Azure DevOps a partir do fork |
vazio |
vazio |
|
Solicitação pull do Azure DevOps a partir do branch |
URL de SSH [1] |
Nome do ramo |
|
Pull request de Bitbucket Server do fork |
vazio |
vazio |
|
Pull request de Bitbucket Data Center do ramo |
URL de SSH [1] |
Nome do ramo |
|
Pull request de Bitbucket Cloud do fork |
vazio |
vazio |
|
Pull request de Bitbucket Cloud do ramo |
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:
Interagir com os outros¶
O Weblate facilita a interação com outras pessoas a usar a API dele.
Veja também
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).