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:
Os desenvolvedores fazem alterações e fazem push delas para o repositório VCS.
Optionally the translation files are updated, see Introducing new strings.
Weblate pulls changes from the VCS repository, parses translation files and updates its database, see Atualizando repositórios.
Os tradutores enviam traduções usando a interface web do Weblate ou enviam alterações feitas offline.
Once the translators are finished, Weblate commits the changes to the local repository (see Commits adiados).
Changes are pushed back to the upstream repository (see Fazendo push das alterações do Weblate).
Dica
Upstream code hosting is not necessary, you can use Weblate with Arquivos locais where there is only the repository inside Weblate.
Atualizando repositórios¶
Você deve configurar alguma maneira de atualizar repositórios de backend a partir de sua fonte.
Use Ganchos de notificação para integrar com a maioria dos serviços comuns de hospedagem de código:
Acione manualmente a atualização no gerenciamento do repositório ou usando API REST do Weblate ou Weblate Client
Habilite
AUTO_UPDATEpara atualizar automaticamente todos os componentes na sua instância do WeblateExecute
updategit(with selection of project or--allto update all)
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.
The first approach 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 - one for the extraction generates template (for example gettext POT is generated using xgettext) and then 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 prior to this operation.
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.
Avoiding merge conflicts on Weblate originated changes¶
Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Squash de commits git add-on, Estilo de mesclagem is configured to Rebase, or you are squashing commits outside of Weblate (for example when merging a pull request).
The reason for merge conflicts is different in this case - there are changes in Weblate which happened after you merged Weblate commits. This typically happens if merging is not automated and waits for days or weeks for a human to review them. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.
To approach this, you either need to minimize 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:
Do not use neither Squash de commits git nor squashing at merge time. This is the root cause why git doesn’t recognize changes after merging.
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 Fluxos de trabalho de tradução), 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 também
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:
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/).
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 em Web-hooks em Project options:
Recebendo automaticamente alterações do Azure Repos¶
Weblate has support for Azure Repos webhooks, add a webhook for
Code pushed event with destination to /hooks/azure/ URL on your
Weblate installation (for example https://hosted.weblate.org/hooks/azure/).
This can be done in Service hooks under 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 push 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 Push 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.
In case you do not want direct pushes by Weblate, there is support for Pull requests do GitHub, Merge requests do GitLab, Pull requests do Gitea, Merge requests do Pagure, Azure DevOps pull requests pull requests or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Sistema de controle de versão in Configuração de componente.
Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, and Azure DevOps:
Configuração desejada |
|||
|---|---|---|---|
Sem push |
vazio |
vazio |
|
Push diretamente |
URL de SSH |
vazio |
|
Fazer push para ramo separado |
URL de SSH |
Nome do ramo |
|
Sem push |
vazio |
vazio |
|
Push diretamente |
URL de SSH |
vazio |
|
Fazer push para 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 |
|
Azure DevOps pull request from fork |
vazio |
vazio |
|
Azure DevOps pull request from branch |
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 Push 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:
Interagindo com os outros¶
O Weblate facilita a interação com outras pessoas usando sua API.
Ver também
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 List of privileges).
As alterações neste modo têm seu commit feito assim que qualquer uma das seguintes condições são cumpridas:
Outra pessoa altera um texto já alterado.
Um merge do upstream é feito.
Um commit explícito é solicitado.
É solicitado o download de um arquivo.
A alteração é mais antiga do que o período definido como Idade das alterações para fazer commit em Configuração de componente.
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.
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.
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).