Ir para o conteúdo

Análises opcionais, gravação de sessões e publicidade permanecem desativadas, a menos que aceite. Pode rejeitá-las e utilizar o Transglot. Altere a sua escolha em qualquer altura em Preferências de cookies. Política de Cookies

para equipas que fazem merge todos os dias

Localização contínua: todas as línguas, em cada merge.

A localização contínua traduz cadeias novas e alteradas à medida que o código muda, em vez de numa fase separada antes de cada lançamento. Todas as línguas ficam prontas para ser lançadas com o código que as necessita.

Uma simulação das duas formas de trabalhar, não uma medição. Clique em "Merge a change" e leia a coluna da direita: é o que os utilizadores dessa língua veem.
acme / web
mainAdd a gift cardcheckout.gift_card
frAjouter une carte cadeautraduzido
deGeschenkkarte hinzufügentraduzido
jaギフトカードを追加traduzido
arأضف بطاقة هديةtraduzido
pt-BRAdicionar vale-presentetraduzido
Línguas que pode lançar agora5 de 5
Cadeias em atraso face ao mainnenhum
a resposta curta

O que é a localização contínua?

A localização contínua é uma forma de trabalhar na qual as cadeias novas e alteradas são enviadas para tradução automaticamente assim que mudam, e o texto traduzido volta para o produto sem que ninguém tenha de o agendar.

Não existe uma fase de tradução, porque a tradução nunca para. Um programador faz merge de uma cadeia, as traduções acompanham no mesmo fluxo que o código e um lançamento não fica à espera do ficheiro de ninguém.

É a metade de localização da entrega contínua. Uma equipa que faz merge todos os dias e entrega a tradução a cada poucas semanas tem línguas em atraso face ao seu código durante a maior parte de cada mês. A localização contínua reduz essa lacuna ao tempo de uma execução.

Não significa que o output automático seja publicado sem revisão. Decide quais as cadeias que precisam de intervenção humana e um lançamento pode incluir apenas o que foi revisto.

localização contínua vs. tradicional

A diferença está no momento da tradução, não em quem a faz.

Tradutores, revisores e glossários existem em ambas as colunas. O que muda é o momento em que o trabalho começa e a dimensão de cada parte.
Lado a lado
Quando ocorre a tradução
Numa fase anterior a cada lançamento
O que inicia o processo
Alguém exporta um ficheiro
A dimensão de cada parte
Semanas de cadeias de texto de uma só vez
O que um lançamento aguarda
Que o ficheiro seja devolvido
Uma alteração tardia de cópia
Outra viagem de ida e volta
Com que informação trabalha o tradutor
Uma folha de cálculo com cadeias de texto
Idiomas no lançamento
Escalonados, uma onda após outra
uma cadeia de texto, do início ao fim

Como funciona a localização contínua

Acompanhe uma nova cadeia de texto ao longo do ciclo. Cada etapa mostra o que realmente veria.

o seu terminal ou o registo do seu CI
+ "checkout.gift_card": "Add a {brand} gift card"
$ git push origin main
$ transglot push --wait
push locales/en.json (en, json_nested)
Batch: #4182
$ transglot pull
written locales/fr.json
written locales/ja.json
checkout.gift_card
origemAdd a {brand} gift card
frAjouter une carte cadeau {brand}Rascunho do Glossa
de{brand}-Geschenkkarte hinzufügenda memória, 0 palavras
ja{brand} ギフトカードを追加Rascunho do Glossa
arأضف بطاقة هدية {brand}Rascunho do Glossa
as quatro verificações, uma execução
Marcadores1 reparado
Formas pluraisaprovado
Termos do glossárioaprovado
Duraçãoaprovado
ja · marcador perdido, reparado uma vez, verificado novamenteギフトカードを追加{brand} ギフトカードを追加
cart.save
origem alteradaSave Save draft
frEnregistrerrevisto por uma pessoa: mantido, reportado a siSugerido: Enregistrer le brouillon
deEntwurf speichernlinha automática: traduzida novamente
pull requestatualizado no local
Atualizar traduçõestransglot/sync → mainaberto, um por repositório
locales/fr.json+3 −1
locales/de.json+3 −1
locales/ja.json+3 −1
ou, num pull request no GitHub, comente/translate

A alteração chega ao Transglot através da CLI, da GitHub Action ou da aplicação no seu anfitrião Git. Os ficheiros de origem são analisados num dos 20 formatos nativos e cada cadeia é comparada com o que o projeto já contém. Apenas as cadeias novas e alteradas prosseguem.

Uma correspondência exata da memória de tradução preenche a linha e não consome palavras. O que sobrar vai para o Glossa com o seu glossário, o seu guia de estilo e o contexto dessa chave.

Os marcadores, as formas plurais, os termos do glossário e o comprimento são verificados em cada linha de cada execução. Um marcador quebrado, uma forma plural em falta ou um termo proibido do glossário é reparado uma vez e verificado novamente; se falhar uma segunda vez, é rejeitado e não é enviado. Uma linha que apenas exceda o seu comprimento é escrita e, a partir do plano Team, a aprovação automática ou uma execução de QA sinaliza-a para revisão.

Uma execução nunca substitui uma linha que uma pessoa tenha editado ou revisto. Se a sua origem mudar mais tarde, o texto mantém-se, a execução conta a linha e informa-o e, a partir do plano Team, uma atualização sugerida aguarda ao lado para alguém aceitar.

As aplicações Git confirmam os ficheiros de localidade numa branch de sincronização e mantêm um pull request atualizado. No GitHub, comente /translate num pull request e os ficheiros vão para a branch desse pull request. Ou publique na CDN e o produto em execução lê a alteração sem qualquer lançamento.

onde as equipas saem prejudicadas

Seis formas como a localização contínua falha e o que impede cada uma

Uma execução substitui o trabalho de uma pessoa

Cada redator verifica primeiro o estado da linha: uma execução, uma correspondência de memória e um envio. Uma linha editada ou revista por uma pessoa é mantida, e a execução reporta-a.

fr, revisto, fonte acabou de mudar

mantido, contado, reportado

Uma cadeia quebrada chega à produção

Cada token que entrou tem de sair. Num projeto ICU, uma mensagem que causaria erro no momento da renderização fica fora do pull, do conector e do pacote CDN, e a execução identifica-a.

{count, plural, one {# article}

excluído do ficheiro, identificado na execução

O repositório enche-se de pull requests de bots

Um ramo de sincronização e um pull request por repositório. Dois envios rápidos convergem para ele em vez de abrir um segundo.

#812 #815 #819 #823 atualização l10n

#812 transglot/sync, atualizado no local

Uma edição na fonte deixa traduções antigas para trás

Cada linha de destino regista a fonte contra a qual foi escrita, por isso sabe-se imediatamente que uma cadeia alterada está desatualizada em todos os idiomas, e apenas essa chave é executada novamente.

Guardar tornou-se Guardar rascunho. fr, de, ja ainda dizem Save

fr, de, ja executados novamente nessa única chave

Cada execução fatura novamente todo o projeto

Uma execução é dimensionada com base no que mudou. Uma cadeia inalterada não é enviada, uma correspondência exata de memória não custa palavras e uma linha da responsabilidade de uma pessoa é recusada antes de qualquer gasto.

ficheiro contém 48.000 palavras

esta execução: 60 palavras

Um pull inacabado apaga um ficheiro de localidade

Se o servidor não reportar entradas para uma localidade, o pull recusa-se a sobrescrever um ficheiro que tem conteúdo e sai com código 1 para que o pipeline pare aí.

pull: 0 entradas para ja, ficheiro contém 1.204

recusando sobrescrever locales/ja.json com um pacote vazio

  • run 4182 fr: marcador em falta no rascunho, reparado na nova tentativa
  • run 4182 de: 3 linhas mantidas, uma pessoa é responsável por elas
  • run 4182 ja: 41 linhas da memória, 0 palavras
  • run 4183 ar: forma plural em falta após nova tentativa, linha recusada
  • pull escrito locales/pt-BR.json
  • sync transglot/sync atualizado, pull request #812
medido em relação aos dois que está a comparar

Todos os três ligam-se ao seu repositório. A diferença está no que acontece ao fazer o merge.

Lido nas páginas de cada empresa a 5 de novembro de 2026. A linha de preços provém das nossas páginas de comparação, ligadas abaixo, que mostram o plano e os cálculos. Os preços e planos mudam, por isso verifique-os antes de decidir.

Transglot
Uma nova cadeia é integrada
Traduzido por predefinição
O push inicia a execução. Uma definição do projeto desativa-a.
Uma tradução falha numa verificação
Reparado uma vez, depois recusado
Para um marcador quebrado, forma plural ou termo proibido, em cada linha de cada execução. Um excesso de comprimento é registado. Num projeto ICU, uma linha com erros fica fora do pull, dos conectores e da CDN.
Uma pessoa já editou a linha
A execução recusa escrevê-la
O mesmo acontece com uma correspondência de memória e um push. Se a origem mudar mais tarde, a execução reporta a linha.
Pull requests num repositório movimentado
Um ramo, um pull request
Atualizado no local em cada push.
O que o plano contabiliza
Palavras traduzidas, uma vez por idioma
Correspondências exatas de memória não têm custo. Armazenar uma cadeia não tem custo.
O que paga a IA
As palavras do plano
Não é faturado separadamente.
O mesmo trabalho: 5,000 cadeias em 10 idiomas
$39 por mês
Team, tradução incluída
GitHub, GitLab, Bitbucket, Azure Repos, uma CLI e um servidor MCP
Todos eles
As aplicações Git começam no plano Team e abrangem as edições na nuvem.
utilize o que já executa

Inicie a partir de onde as suas cadeias de texto estão alojadas. Todas as portas conduzem à mesma pipeline.

A mesma memória, glossário, barreiras e revisão, independentemente da porta por onde a cadeia de texto entrou.
.github/workflows/translations.yml
on:
push:
branches: [main]
jobs:
translations:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v7
- uses: transglot/transglot-action@v1
with:
token: ${{ secrets.TRANSGLOT_TOKEN }}
o que fazer primeiro

Como configurar a localização contínua

  1. Extrair cadeias de caracteres do código

    Cada cadeia de caracteres visível ao utilizador precisa de uma chave estável num ficheiro de localidade. O Transglot lê 20 formatos, por isso mantenha o que já tem.

  2. Ligar o repositório

    O comando init encontra os seus ficheiros de localidade, autentica-o através do navegador, carrega o que já tem e executa a primeira tradução.

  3. Executar em cada merge

    Adicione a GitHub Action, chame a CLI de qualquer outro CI ou instale a aplicação para GitHub, GitLab, Bitbucket ou Azure Repos.

  4. Decidir o que necessita de intervenção humana

    Defina min_state como reviewed numa regra de pull request e esse ficheiro só transportará cadeias de caracteres revistas por uma pessoa. Deixe desativado e as versões preliminares serão publicadas.

faça as contas com os seus próprios números

O custo de executar em cada merge: as palavras que foram alteradas.

Uma palavra é uma palavra de origem, contada uma vez por idioma de destino. Uma execução é dimensionada pelo que foi alterado, por isso um merge que afeta doze palavras em cinco idiomas conta como sessenta, independentemente da dimensão do projeto.

25
40
6
20,000
Palavras por mês26,000com estes números · 25 merges por semana, 40 palavras cada, 6 idiomas

Enquadra-se no plano Starter: $19/mo, 300,000 palavras por mês.

Isso representa cerca de 9% do limite.

Primeira execução, única120,000As suas cadeias de caracteres existentes em todos os idiomas. As traduções que importa não são traduzidas novamente.

Isto conta apenas traduções. Verificações de qualidade, rascunhos de voz da marca e reparações também contam como palavras, e correspondências exatas da memória não têm custo. A CLI e a Ação do GitHub começam no plano Starter, e as aplicações para GitHub, GitLab, Bitbucket e Azure Repos começam no plano Team.

o que não fará por si

Três coisas que a localização contínua não resolve

Cadeias ainda presas no código

Uma pipeline só pode traduzir o que consegue ler. Cadeias codificadas e frases coladas a partir de partes têm de ser corrigidas primeiro, e são a razão habitual pela qual uma implementação estagna.

Ninguém responsável pelas palavras

A automação move cadeias. Não decide como o seu produto chama as coisas. Alguém tem de ser responsável pelo glossário, ou um idioma que ninguém lê desvia-se sem que ninguém note.

Texto que requer julgamento

Texto legal, preços e slogans de marca merecem uma pessoa. Envie-os para revisão e mantenha-os fora dos ficheiros que são distribuídos até alguém aprovar.

Perguntas frequentes sobre localização contínua

As perguntas que as equipas fazem antes de a ativar.

O que é a localização contínua?
Uma forma de trabalhar em que novas e alteradas cadeias vão para tradução automaticamente à medida que mudam, e o texto traduzido regressa ao produto sem uma entrega agendada. Substitui a fase de tradução antes de um lançamento por uma pequena execução após cada alteração.
A localização tradicional agrupa cadeias num ficheiro, envia-o perto de um lançamento e espera. A localização contínua move cada alteração à medida que acontece, para que as peças sejam pequenas, os idiomas sejam lançados em conjunto e uma alteração tardia de texto custe apenas uma nova execução de uma chave em vez de outra viagem de ida e volta.
Não. O CI/CD compila, testa e lança código. A localização contínua mantém as traduções a mover-se em paralelo. Encontram-se na pipeline: o push que executa os seus testes também pode enviar cadeias para tradução e trazer os ficheiros de volta.
Não. As aplicações para GitHub, GitLab, Bitbucket e Azure Repos reagem a um push sem nada adicionado à sua pipeline, e os conectores de conteúdo reagem a alterações num CMS ou loja. A CLI e a Ação do GitHub estão disponíveis se as quiser dentro do seu próprio fluxo de trabalho.
Não. Os rascunhos podem ser distribuídos, ou uma regra de pull pode levar apenas o que uma pessoa reviu, ficheiro por ficheiro. Os revisores trabalham no editor com os termos do glossário, correspondências de memória e capturas de ecrã ao lado de cada linha.
Não. Uma execução, uma correspondência de memória e um push verificam primeiro a linha, e uma linha que uma pessoa editou ou reviu mantém-se. Se a sua fonte mudar mais tarde, o texto permanece, a execução conta a linha e reporta-a, e a partir do plano Team uma atualização sugerida é anexada para alguém aceitar.
Tende a importar mais numa equipa pequena, porque ninguém tem a função de gerir entregas. Se lançar num idioma sem plano para um segundo, pode esperar.
Uma execução é dimensionada antes de começar. O plano gratuito é um limite rígido. Um plano pago para na sua allowance, a menos que ative o excesso medido, que para num limite de gastos que definir. No CI, a CLI sai com o código 3 quando uma execução ultrapassaria o limite, para que a pipeline possa agir sobre isso.
Sim, no GitLab.com, Bitbucket Cloud e Azure DevOps Services. As aplicações não cobrem GitLab autoalojado ou Bitbucket Data Center, mas a CLI executa em qualquer CI que tenha Node 22 e possa aceder à API.
Sim. Os conectores de conteúdo leem a partir de um CMS, uma loja ou uma central de ajuda, e os bidirecionais escrevem o idioma revisto de volta. Alguns são apenas de importação e a página de cada conector indica quais são.
Sim. Publique um locale na CDN e o seu produto lê-o em tempo de execução através dos SDKs de runtime. O URL mais recente é colocado em cache durante sessenta segundos, cada versão publicada mantém o seu próprio URL e as últimas vinte versões são mantidas.
O importador transfere projetos, chaves e traduções existentes a partir de Lokalise, Phrase, Crowdin, Transifex, Weblate and POEditor. As traduções importadas contam como trabalho humano, por isso nenhuma execução as substitui. É gratuito em qualquer plano e executa-se uma vez.