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

Integrating with 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 (isso depende do formato do arquivo, consulte Why does Weblate still show old translation strings when I’ve updated the template?).

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

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

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

  6. Uma vez que os tradutores tenham finalizado, 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 "]; }

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 ou Weblate Client

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

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

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

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

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

Recebendo automaticamente alterações do Azure Repos

Novo na versão 3.8.

O Weblate tem suporte para webhooks do Azure Repos, adicione um webhook para 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.

Recebendo automaticamente alterações do Gitea Repos

Novo na versão 3.9.

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

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.

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.

No caso de você não querer pushes diretos pelo Weblate, há suporte para pull requests do GitHub,do vcs-gitlab`e do :ref:`vcs-pagure ou revisões do Gerrit, você pode ativá-los escolhendo GitHub, GitLab, Gerrit ou Pagure, como Sistema de controle de versão em Component configuration.

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

Configuração desejada

Sistema de controle de versão

URL de push 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

Pull request de GitHub do fork

GitHub

vazio

vazio

Pull request de GitHub do ramo

GitHub

URL de SSH 1

Nome do ramo

Merge request de GitLab do fork

GitLab

vazio

vazio

Merge request de GitLab do ramo

GitLab

URL de SSH 1

Nome do ramo

Merge request de Pagure do fork

Pagure

vazio

vazio

Merge request de Pagure do ramo

Pagure

URL de SSH 1

Nome do ramo

1(1,2,3)

Pode estar vazia caso o Repositório do código-fonte tenha suporte a push.

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 Accessing repositories 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

Merge ou rebase

Por padrão, o Weblate mescla o repositório upstream em seu próprio. Esta é a maneira mais segura no caso de você também acessar o repositório subjacente por outros meios. Caso você não precise disso, você pode permitir fazer rebase de alterações em upstream, o que produzirá um histórico com menos compromissos de mesclagem.

Nota

Rebasing pode causar problemas em caso de mesclagens complicadas, então considere cuidadosamente se você quer ou não habilitá-los.

Interagindo com os outros

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

Ver também

API

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 Controle de acesso).

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 você quiser fazer commit das alterações com mais frequência e sem verificar a idade, você pode agendar uma tarefa regular para realizar um commit:

CELERY_BEAT_SCHEDULE = {
    # Unconditionally commit all changes every 2 minutes
    "commit": {
        "task": "weblate.trans.tasks.commit_pending",
        # Ommiting hours will honor per component settings,
        # otherwise components with no changes older than this
        # won't be committed
        "kwargs": {"hours": 0},
        # How frequently to execute the job in seconds
        "schedule": 120,
    }
}

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 a propagação de tradução habilitada (que é o padrão, consulte Component configuration), todas as novas traduções são feitas automaticamente em todos os componentes com strings 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 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. 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).