Traduçã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 describes basic ways to integrate your development with Weblate. Code-hosting integrations lists provider-specific setup steps for common code-hosting sites.

Este é o processo:

1. Developers make changes and push them to the VCS repository.

2. Opcionalmente, os arquivos de tradução são atualizados, consulte Introduzindo novos textos.

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. Changes are pushed back to the upstream repository (see Fazendo push das alterações do Weblate).

Dica

Upstream code-hosting site 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 to integrate with the majority of common code-hosting services, see Code-hosting integrations. You must also Habilitar ganchos for this to work. Hook deliveries update components whose repository URL matches the payload; see Matching webhook targets.

• Acione manualmente a atualização no gerenciamento do repositório ou usando API REST do Weblate ou Weblate Client

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

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

Sempre que o Weblate atualizar o repositório, os complementos de pós-atualização serão acionadas, consulte Complementos.

Matching webhook targets

Forge webhooks update components whose Repositório do código-fonte exactly matches a repository URL from the payload (HTTPS or SSH as reported by the forge, plus common variants such as a trailing slash).

Generic forge webhook endpoints are compatibility interfaces, and ordinary repository deliveries are not cryptographically authenticated. Legacy GitHub App deliveries containing installation data are an exception: the generic GitHub endpoint verifies their signature using GITHUB_LEGACY_APP_WEBHOOK_SECRET. Repository matching does not apply project or component access control because webhooks also need to update private projects and restricted components. Their JSON responses include diagnostic counts for repository, branch, and enabled-hook matches. Successful responses also include the full project/component slugs and absolute API URLs of updated components. Supplying a matching repository URL can therefore confirm that a repository is registered and reveal these identifiers.

Each matching delivery records a hook event and schedules a repository update. Generic hook deliveries are neither application-rate-limited nor coalesced. Repository operations are serialized to protect repository consistency, but this does not bound the number of accepted deliveries or queued update attempts. An update of an unchanged repository still fetches the configured remote, but stops before merging changes or parsing translation files.

Components managed through an authenticated integration are excluded from generic webhook matching and its diagnostic counts. Currently this applies to the GitHub (via Weblate GitHub app) VCS backend. These components receive notifications only through their dedicated tokenized and signed GitHub App webhook URL. Future authenticated integrations are expected to use the same separation.

The returned API URLs do not grant access to the components. The web interface and API continue to enforce normal access control, and webhook responses do not include repository content, translations, or credentials. Where available, prefer an authenticated integration such as App webhook URL.

Alterado na versão 2026.9: Host and path suffix fallback matching was removed. If updates stop, align Repositório do código-fonte with a URL from the forge webhook payload.

Evitando conflitos de mesclagem

Os conflitos de mesclagem do Weblate surgem quando o mesmo arquivo foi alterado tanto no Weblate quanto fora dele. Dependendo da situação, há várias abordagens que podem ajudar aqui:

• Evitando conflitos de mesclagem alterando arquivos de tradução somente no Weblate

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

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

Evitando conflitos de mesclagem alterando arquivos de tradução somente no Weblate

Evitar edições fora do Weblate é 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:

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

Evitando 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 arquivos 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 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 Weblate Client, por exemplo, curl, ver API REST do Weblate.

Manutenção do repositório

The Repository maintenance view shows repository status for a project, component, or translation and lets privileged users run maintenance operations from the user interface.

For shared repositories, permissions are checked on the component that owns the repository, even when the operation is started from a linked component. Users with repository permissions only on a linked component can open this view to see which permissions they need on the owner. Restrictions identify the owning component when it is accessible; otherwise, ask your project administrator to coordinate access with the repository owner. See Controle de acesso for permission scope.

The same actions can also be triggered using API REST do Weblate or, for the supported subset, Weblate Client.

Availability of individual actions depends on permissions, the configured version control system, whether pushing is configured, and whether the selected object can be locked.

Repository actions started from this view are queued for background processing. For a project, Weblate processes the affected repositories sequentially in one task and shows its progress. Repeating the same action opens the existing task; a different action cannot be started for the same repository until that task finishes.

The Synchronize and Rescan repository operations are queued for background processing as described above. The separate File management actions are available only for an individual translation. They rewrite that translation file and commit the result during the web request; they are not project-wide or component-wide operations.

Operations that read repository content, such as updating, resetting, or rescanning, also reconcile translation files in Weblate. Added or removed translation files are reflected after this processing finishes. Glossary language synchronization and cleanup are described in Language files and synchronization.

Ação	What it does	Typical use
Commit	Commits pending changes stored in Weblate to the local repository.	Flush pending Weblate changes before doing repository work elsewhere.
Push	Pushes committed local repository changes to the configured upstream.	Send committed translations upstream when automatic push is disabled or delayed.
Update	Fetches upstream changes, integrates them using the component’s configured Estilo de mesclagem, and reconciles translation files.	Bring Weblate in sync with upstream using the default integration strategy.
Update with merge	Fetches upstream changes and integrates them with an explicit merge.	Override the default merge style for a single update.
Update with rebase	Fetches upstream changes and rebases local Weblate commits on top of upstream.	Keep history linear when that matches your workflow.
Update with merge without fast-forward	Fetches upstream changes and creates an explicit merge commit even when a fast-forward would be possible.	Preserve merge commits for auditing or branch-management reasons.
Lock / Unlock	Prevents or allows translators to make further changes in Weblate.	Freeze translation changes while doing repository maintenance outside Weblate.
Discard local changes	Resets Weblate’s local repository to upstream, discards local commits and pending translation changes, and reconciles translation files.	Use when upstream should overwrite the local Weblate repository state.
Reset and reapply translations	Resets Weblate’s local repository to upstream, reconciles translation files, and reapplies Weblate’s translations. See Reset and reapply translations recovery behavior.	Recover from diverged history while keeping pending Weblate translations.
Cleanup	Removes untracked files and stale branches from the local repository checkout.	Clean up leftover files or stale repository state in Weblate’s checkout.
Synchronize	Forces Weblate to write all known translations back to the repository files.	Repair cases where repository files became out of sync with the database state.
Rescan	Re-reads translation files from the local repository into Weblate and removes translations whose files no longer match the component configuration.	Import file changes after manual repository work or file creation.
Remove duplicates	Removes repeated strings with the same identifier from one translation file.	Repair duplicate strings reported by Weblate when the file contains repeated units.
Cleanup unused	Removes strings no longer present in the base file from one translation file. The Limpar arquivos de tradução add-on can perform this automatically.	Run a one-time cleanup without installing the add-on.
Remove obsolete	Removes obsolete strings from one PO translation file.	Run a one-time PO cleanup without enabling automatic obsolete string removal.

For Git repositories, both reset actions affect only the configured Ramo do repositório. They do not reset or remove other local branches. Cleanup deletes all other local branches, including any commits that have not been pushed, and removes untracked files. It does not delete branches from the upstream repository.

If you replace an upstream branch with unrelated history, switching to it in Weblate can fail because Weblate reuses its existing local branch and tries to merge or rebase it. Resetting while another branch is configured does not fix that inactive local branch. For example, resetting master leaves an old local dev branch unchanged.

If no local changes on the affected branch need to be kept, configure a working branch, run Cleanup from Repository maintenance, and wait for it to finish. Then switch to the affected branch again. Weblate creates it afresh from upstream. If the affected branch is already configured, use Discard local changes to replace its local history with upstream instead.

Reset and reapply translations recovery behavior

The Reset and reapply translations operation keeps translations from Weblate while resetting the local repository state to match upstream.

If the Git checkout or its entire .git directory is missing, this operation reconstructs it before reapplying translations. Remote repositories are cloned from the configured upstream branch. Local repositories are initialized with new Git metadata while retaining any surviving working files. Both then use the standard reapply flow. Symlinked checkout directories are never replaced automatically.

For local repositories, reapply can recreate missing strings from the database, including source strings in monolingual base files, when the file format supports adding strings. Missing translation files can also be recreated when the format supports creating them or a valid template for new translations is available. This applies to local glossaries as well as other local components, including when their Git checkout is healthy. Remote reapply does not recreate strings removed upstream.

Required files that the format cannot create must be restored from a backup. Weblate reports restoration failures and keeps the database translations and pending changes.

Any surviving checkout without a .git directory is preserved under DATA_DIR/repository-recovery/<component-id>/<unique-id>/. Its location is written to the application log. These copies are not removed automatically; inspect and remove them manually after verifying recovery. Reconstruction cannot restore lost Git history or files and metadata that Weblate does not store.

Recovery is explicit: background updates do not automatically rebuild checkouts. If a checkout is unexpectedly missing, first verify that the data volume is available to the worker performing recovery. Damaged Git metadata in an existing .git directory requires manual inspection and repair by an instance administrator.

The operation can restore pending translations only when the target language files still exist after the reset or when Weblate can create them for the component, for example using a valid Modelo para novas traduções.

If neither of these conditions is met, Weblate keeps the pending changes in its database and reports a recovery error instead of failing later with a generic parse error.

Evitando conflitos de mesclagem concentrando operações no Git

Mesmo quando o Weblate é a única fonte das alterações nos arquivos de tradução, podem surgir conflitos quando se usa o complemento 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).

The reason for merge conflicts is different in this case. Weblate can have new local commits after you merge earlier Weblate commits upstream. This typically happens if merging is not automated and changes wait for days or weeks for a human review. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.

Squash merging Weblate changes makes this harder to recover from. A squash merge creates a new commit instead of preserving the individual Weblate commits in the upstream history. Weblate still has the original commits in its local repository, and Git can no longer prove that upstream already contains them. If the conflict was also resolved manually, the file contents can differ from both repositories, so Weblate can keep failing to update even after the pull request was merged upstream.

If upstream no longer contains Weblate commits because they were squash merged, updating the repository might not be enough. Use Reset and reapply translations from Repository maintenance to reset Weblate to upstream while keeping pending translations; see Reset and reapply translations recovery behavior. Use Discard local changes only when upstream should fully replace Weblate’s local changes.

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:

• Do not use Squash de commits git or squash merging for Weblate changes. Squashing is why Git might no longer recognize the changes after merging.

• When resolving conflicts outside Weblate, merge the Weblate commits with a regular merge commit and push that result upstream. Do not squash merge the conflict-resolution pull request.

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

Code-hosting notifications

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Code-hosting integrations.

Provider-specific notifications

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Code-hosting integrations.

Ver também

• GitHub notifications

• GitLab notifications

• Bitbucket notifications

• Pagure notifications

• Azure Repos notifications

• Gitea notifications

• Forgejo notifications

• Gitee notifications

Automatically updating repositories daily

By default, Weblate automatically fetches remote repositories daily to improve performance when merging changes later. Updates are distributed throughout the day. Set AUTO_UPDATE to "full" to also merge remote changes into the working copy. See AUTO_UPDATE for scheduling details and other update modes.

Fazendo push das alterações do Weblate

Each translation component can have a push URL set up (see URL de envio do repositório), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see Enviar ao fazer commit.

For the push options table and provider-specific pull, merge, and review request workflows, see Fazendo push das alterações do Weblate.

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

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:

• 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ê verá muitos commits. Você pode utilizar o complemento 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 Complementos. Consulte Escrevendo scripts para complementos para obter informações sobre como executar scripts externos através de complementos.

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.

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

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

• Habilitar Permitir propagação de tradução para reusar automaticamente traduções para textos 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.

• Os textos são propagados enquanto traduzir, textos carregados a partir do repositório não são propagados.

Dica

Esta funcionalidade tem limitações no momento, e queremos torná-la mais universal. Por favor compartilhe seu feedback em https://github.com/WeblateOrg/weblate/issues/3166.

Verificação de consistência

A verificação 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 (consulte Tradução automática) ou fazê-la ser executada automaticamente na atualização do repositório usando um complemento (consulte Tradução automática).