Como Traduzir um Videogame com IA

A localização de jogos começa com um arquivo que seu engine já criou, e o objetivo é enviar esse arquivo para algum lugar que o leia exatamente como ele é. O Unity fornece XLIFF ou CSV. O Unreal fornece PO. O Godot fornece qualquer um dos dois. Nenhum deles precisa ser reformatado primeiro.

Este guia é a versão detalhada: o que a localização de jogos realmente envolve, por que vale a pena, qual arquivo cada engine fornece, o que você pode ou não solicitar dependendo do formato desse arquivo, como a plataforma executa um trabalho hoje e como entregar todo esse ciclo a um agente de IA para que a tradução para dez idiomas seja uma única decisão, em vez de quarenta cliques.

O que a localização de jogos realmente envolve

Localização consiste em quatro tarefas distintas que as pessoas resumem em uma única palavra, e saber em qual delas você está evita a maior parte dos problemas.

1. Internacionalização, que é código, não idioma. Seu jogo precisa ser capaz de exibir outro idioma: nada de texto fixo em uma textura, nenhuma frase montada por concatenação de strings, uma fonte com os glifos necessários e layouts que suportem o crescimento de um rótulo. Cada engine tem um sistema para isso, e é no sistema de cada engine que as strings acabam residindo.

2. Extração, que o engine faz. O Unity coleta seus textos em String Table Collections. O Localization Dashboard do Unreal os reúne em um target e os exporta. O Godot lê uma planilha ou um catálogo gettext. O resultado desta etapa é o arquivo que você irá traduzir.

3. Tradução, que é a parte sobre a qual este artigo trata. Um arquivo entra, um arquivo sai, no mesmo formato.

4. Reimportação e testes. O arquivo volta para onde veio, o jogo é reconstruído e alguém lê o menu principal em alemão para verificar se nada transbordou.

A única etapa que precisa sair do seu engine é a terceira. Qualquer coisa que exija que você reestruture o arquivo antes de traduzi-lo adicionou uma quinta tarefa que ninguém precisava.

Por que localizar

O argumento é de mercado, não de polimento. Um jogo publicado em inglês é descobrivel e jogável por pessoas que leem inglês, e o resto do mundo continua sendo o resto do mundo.

A pesquisa “Can’t Read, Won’t Buy” da CSA Research, com 8.709 consumidores em 29 países, descobriu que 40% dos consumidores não compram de sites em outro idioma, e que 76% preferem comprar produtos com informações em sua própria língua. Essa pesquisa trata de compras online em geral, e não especificamente de jogos, que é exatamente por isso que vale a pena citá-la aqui: a preferência não é uma peculiaridade dos gamers, é como as pessoas compram qualquer coisa.

Mais três efeitos que importam especialmente para um jogo, sem um número anexo a nenhum deles, porque não temos um que valha a pena publicar:

• Descoberta na loja. Uma página de loja em um idioma é pesquisável em um único idioma. Títulos, descrições e tags são três telas de texto ao lado de quarenta horas de conteúdo.
• Avaliações e reembolsos. Um jogador que não consegue ler um tutorial escreve sobre o tutorial.
• Alcance por unidade de trabalho. Seus sistemas, arte e áudio já estão prontos. O texto é a coisa mais barata de duplicar no seu projeto.

Se seu jogo tem algumas centenas de strings, isso é um fim de semana de trabalho cuidadoso de qualquer maneira. Acima de alguns milhares, a diferença entre um fluxo de trabalho e um hábito é o projeto inteiro.

Como isso se posiciona em relação a um sistema de gestão de tradução

Grandes estúdios gerenciam sua localização por meio de um TMS: memoQ, Phrase, Crowdin, Lokalise e seus pares. Essas são plataformas de coordenação. Elas armazenam as strings, a memória de tradução, as vagas de revisor, os estados do fluxo de trabalho e as integrações; para uma equipe de vinte pessoas com fornecedores vinculados, essa coordenação é o produto.

Se você é uma equipe de uma a quinze pessoas, esse geralmente não é o seu problema. Você não precisa de gestão de vagas, estados e fornecedores. Você precisa que as strings exportadas desta build sejam bem traduzidas, com seu vocabulário inventado intacto, antes do milestone. Isso é um trabalho, não uma plataforma.

Então, a posição honesta: um TMS é onde uma equipe grande organiza pessoas, e o AI Glot é onde um arquivo é traduzido. Muitas equipes mantêm a exportação do seu engine como a única fonte de verdade, traduzem aqui e fazem o commit do resultado, sem nenhum terceiro sistema no meio.

O que sua engine exporta e o que nós lemos

AI Glot lê doze formatos: CSV, Excel, JSON e ARB, YAML, XLIFF, PO, Android XML, iOS .strings, Java .properties, .NET RESX, legendas SRT e arquivos ZIP contendo qualquer um desses. Os dois formatos que as engines de jogos realmente usam, PO do Unreal e XLIFF e CSV do Unity, são nativos. Esse é o objetivo desta seção: não há exportação, conversão, tradução e depois nova conversão para voltar ao original.

Unity

O pacote de Localization exporta String Table Collections de três formas, e qualquer uma delas funciona aqui.

XLIFF, nas versões 1.2 e 2.0, é o formato criado para isso. A documentação do Unity descreve a exportação de String Table Collections para um ou mais arquivos XLIFF, a edição em uma ferramenta externa e a importação de volta com as traduções atualizadas, que é exatamente o ciclo de trabalho. Envie para o tradutor de XLIFF e ele retornará com as mesmas unidades na mesma ordem.

CSV é a outra opção de exportação, e é mais legível se você quiser dar uma olhada rápida. O CSV do Unity traz uma coluna Key com a chave que você atribuiu, uma coluna Id com o ID que o Unity atribuiu e uma coluna por localidade na Tabela de Strings. A variante “CSV com comentários” adiciona uma coluna de comentário por localidade, que serve de contexto para o tradutor e não deve ser traduzida. Essa distinção é feita com uma frase na sua instrução, e é para isso que a página do tradutor de CSV existe. Há um passo a passo completo de ambas as exportações do Unity, com a instrução exata a escrever para cada uma.

Google Sheets é a terceira via: o pacote sincroniza uma String Table Collection com uma planilha. Exporte essa planilha como CSV ou XLSX e você estará de volta ao primeiro caso.

Unreal Engine

O Localization Dashboard do Unreal utiliza um fluxo de trabalho PO. A própria documentação da Epic, na página de ferramentas de localização, recomenda o uso “combinado com uma ferramenta de tradução externa (como Poedit, OneSky ou XLOC)” para o trabalho de tradução real, em vez do editor integrado. AI Glot é essa ferramenta externa, com a diferença de que o arquivo não precisa de um humano sentado à frente dele.

Uma entrada PO tem três partes importantes para você. A linha de contexto contém a identidade do Unreal para aquela entrada, construída a partir de seu namespace e chave. O source é o texto em inglês. O slot de tradução fica vazio até que alguém o preencha. Envie o arquivo para o tradutor de PO e apenas essa terceira parte será alterada.

É por isso que msgctxt e msgid são tratados como estrutura e não como texto. Alterar qualquer um deles fará com que o Unreal não consiga encontrar a entrada ou trate a tradução como desatualizada.

Godot e builds mobile

Godot suporta ambos os caminhos. Sua documentação afirma que possui um importador que lê arquivos CSV e que também suporta o carregamento de traduções escritas no formato gettext .po. Ambos são arquivos que já conseguimos ler.

Se você publica em celulares, as strings da loja e da plataforma são Android strings.xml e iOS .strings, e ambos possuem suas próprias ferramentas gratuitas: Android XML e iOS .strings. Legendas de cutscenes e trailers são SRT, que segue o mesmo fluxo de traduzir legendas do YouTube.

Não pretendemos substituir o Unity, Unreal, Godot ou qualquer plataforma de localização. Nós processamos o que eles exportam.

Uma coluna por idioma ou um arquivo por idioma

Isso é a coisa mais importante a entender antes de escrever uma instrução, pois define o que você pode solicitar.

Portanto, “traduza meu jogo para francês, alemão, espanhol e japonês” é um único trabalho se você tiver um CSV do Unity com quatro colunas de locale, e quatro trabalhos se você tiver quatro arquivos PO do Unreal. Solicitar que um formato de idioma único contenha dois idiomas resultará em erro, e isso acontecerá na etapa de planejamento, e não silenciosamente, que é o momento correto para falhar.

Enviando uma pasta de arquivos de locale como um único arquivo

Um repositório de jogo não possui apenas um arquivo de localização. Ele possui um diretório por cultura, cada um com o mesmo nome de arquivo. Toda essa estrutura é enviada como um único ZIP, que é a finalidade do tradutor de ZIP.

Vale a pena conhecer os limites antes de criar o arquivo: até 200 arquivos, 20 MB para o arquivo compactado e 4 MB por arquivo interno. Arquivos únicos maiores são aceitáveis, pois os limites são bem mais altos: 60 MB para CSV, 50 MB para XLSX, 12 MB para XLIFF, Android XML e RESX, 8 MB para JSON e 4 MB para PO, YAML, .properties, .strings e SRT.

Todo arquivo no pacote deve ter o mesmo formato e a mesma estrutura, e “mesma estrutura” significa algo específico por formato:

• CSV: colunas idênticas, na mesma ordem.
• Android XML, iOS .strings, Java .properties, RESX: um conjunto idêntico de chaves. Conjuntos de pastas por cultura passam nessa verificação naturalmente, pois são gerados a partir de uma única fonte.
• XLIFF: a mesma versão e estrutura de unidade. Os arquivos podem declarar pares de idiomas diferentes, por isso uma exportação mista de vários destinos ainda é considerada um único arquivo.
• PO: qualquer arquivo PO, já que a estrutura de um catálogo é o seu próprio formato.

Um arquivo que falhe na verificação de estrutura é recusado com a indicação da divergência, em vez de ser processado parcialmente.

Como uma tradução funciona agora

Não há tela de mapeamento de colunas nem etapa de configuração. Não existem modos fixos para escolher desde agosto de 2026.

1. Faça o upload do arquivo exportado pelo seu software.
2. Diga o que precisa, em inglês simples. Uma frase, ou cinco.
3. Leia o plano. Ele mostra os idiomas, o escopo compreendido, a contagem de palavras e o custo.
4. Corrija se estiver errado. Isso é gratuito e repetível.
5. Aprove. Esta é a etapa que consome créditos.
6. Baixe um arquivo, no formato em que foi enviado.

A instrução é em texto livre e o motor a compila em código verificado, por isso frases de escopo que nenhum tradutor automático consegue expressar funcionam aqui: “only the entries whose translation is still empty”, “only the rows where the German column still holds the English text”, “translate the dialogue and the item names, leave the developer comments alone”.

Tudo até a etapa cinco não custa nada. Um plano que leu seu arquivo incorretamente pode ser corrigido gratuitamente, portanto, não há motivo para tentar adivinhar.

Textos que precisam caber no espaço

Um botão que cabe em inglês transborda em alemão. Textos traduzidos costumam ser de 15% a 30% mais longos, e uma interface criada com a largura do inglês é uma interface criada para o menor cenário possível.

A solução errada é traduzir primeiro e cortar depois, o que gera abreviações que ninguém usaria. A solução certa é informar a restrição antecipadamente, para que a linha seja escrita para caber no espaço:

Keep every UI label under 28 characters, including spaces. If the natural
translation is longer, choose a shorter phrasing rather than abbreviating.

Isso deve constar nas instruções ao nível de string, passadas na aprovação, pois um limite de caracteres descreve algo visível dentro de uma única string. Peça isso uma vez por arquivo e a regra será aplicada enquanto cada etiqueta é escrita.

Duas coisas que isso não substitui: teste as strings mais longas na versão final, pois um limite de caracteres não é a mesma medida de pixels da sua fonte. E mantenha o limite realista: 28 caracteres para um botão, não 28 caracteres para a descrição de uma missão, ou você terá descrições de missões que parecem telegramas.

As duas instruções que as pessoas confundem

Esta é a única coisa em todo o fluxo de trabalho que falha silenciosamente, por isso vale a pena gastar trinta segundos nisso.

A instrução do plano decide o que será traduzido. Ela é lida uma única vez, com base na estrutura de todo o arquivo, e é nela que devem constar o idioma de destino e o escopo. “Translate every entry whose translation slot is still empty into German.”

As instruções ao nível de string são aplicadas enquanto cada string é escrita. Nesse momento, o motor está analisando apenas uma string, portanto, elas só podem descrever o que é visível dentro dela: um limite de caracteres, um registro, um placeholder como {count} para manter exatamente como escrito ou um nome para não traduzir.

Se você colocar um limite de caracteres no plano, ele não terá efeito útil. Se colocar “skip the first column” ou “only translate the second half of the file” no campo de instruções de string, não acontecerá nada, pois não há um arquivo em vista naquele momento. Nada gera erro. Você apenas recebe um resultado que ignorou suas instruções.

Nomes, itens e feitiços que não podem variar

O lore é onde a tradução de jogos difere de tudo o mais. Um catálogo de produtos tem centenas de termos que devem permanecer fixos. Um jogo tem milhares, eles são inventados e recorrem em milhares de linhas e em cada atualização que você lança nos próximos três anos.

Coloque-os em um workspace glossary apenas uma vez: nomes de personagens, nomes de lugares, nomes de itens e feitiços, a tradução oficial de uma frase recorrente e os nomes que não devem ser traduzidos. Um glossário pertence a um par de idiomas e é capturado no momento em que um plano é criado, portanto, um lote em execução nunca é alterado e o próximo arquivo recebe os termos atuais.

Vale a pena conferir os limites do plano com sua lista de termos: um glossário com 50 termos no Free, três com 150 no Starter e glossários ilimitados com 500 termos cada no Pro.

E você não precisa digitar essa lista manualmente. O glossário é acessível via servidor MCP, com ferramentas para listar glossários, ler um, e adicionar, alterar ou substituir termos. Assim, um agente que já esteja com seu projeto aberto pode fazer a parte tediosa: ler suas Tabelas de Strings ou seus arquivos de diálogo, extrair os nomes próprios e as palavras inventadas recorrentes, propor a lista para você e gravar os termos aprovados no workspace antes de qualquer tradução ser executada.

Isso vale mais do que parece. Um glossário que ninguém preenche não protege nada, e preencher um manualmente para um jogo com mil termos inventados é exatamente a tarefa que acaba sendo adiada para sempre. Peça ao seu agente para criar o rascunho e, depois, edite a lista dele em vez de escrever uma do zero.

Este é também o motivo técnico pelo qual um tradutor automático geral tem dificuldades com jogos. O glossário dele substitui um termo sempre que encontra uma correspondência, então a frase ao redor da substituição nunca é reconsiderada, e um substantivo inventado com um gênero acaba no meio de uma frase em francês que não concorda com ele. Aqui, o glossário é integrado como significado enquanto a linha é escrita, então o termo se flexiona na frase. A mesma diferença se aplica ao uso de um assistente de chat para esse trabalho: funciona bem para dez strings, mas não consegue manter uma única regra com confiabilidade na string 18.000.

Deixe um agente gerenciar o ciclo de localização do seu jogo

Esta é a parte que a maioria dos estúdios ainda não adotou. Existe uma API REST, uma ferramenta de linha de comando e um servidor MCP, então um agente de codificação pode executar todo o ciclo sem que um humano precise abrir o navegador.

Instale-o e faça login uma vez:

npm install --global @ai-glot/cli
aiglot auth login

Isso abre um navegador para autorizar a máquina. Em um servidor de build sem navegador, aiglot auth login --device fornece o fluxo de código de dispositivo, e aiglot auth login --key <key> funciona em CI.

O prompt para entregar ao seu agente

Cole isto, alterando os caminhos e a lista de idiomas. Foi escrito para ser entregue a um agente, não para você executar manualmente.

My Unreal project is at ~/dev/starfall. The Localization Dashboard exported
PO files to Content/Localization/Game/<culture>/Game.po, and their msgstr
lines are still empty.

Translate the French, German, Spanish and Japanese files with the aiglot CLI.
Read `aiglot batches create --help` and `aiglot batches approve --help` first
so you use the real flags, and run `aiglot languages` to confirm each language
tag before you start.

A PO file holds one target language, so create ONE batch per culture, four in
total. The source language is English: say so explicitly in every instruction
rather than letting it be inferred.

The plan instruction should translate only the entries whose msgstr is still
empty, and leave msgctxt, msgid and every placeholder or rich-text tag exactly
as written.

At approval, pass this as the string-level instruction: "Keep UI labels under
28 characters. Keep placeholders exactly as written. Do not translate any name
that appears in the glossary."

Show me all four plans, the total word count and the cost BEFORE you approve
anything, then wait for me to confirm.

After I confirm, approve with the lite quality tier, poll until each batch
reaches a terminal status, and download each result next to the original as
Game.translated.po. Do not overwrite the source files. Tell me if any batch
failed.

Quatro coisas nesse prompt estão fazendo o trabalho real, e são as partes que você deve copiar para o seu próprio.

Ele instrui o agente a ler a ajuda primeiro. Um agente que tenta adivinhar nomes de flags falha na primeira chamada e depois inventa um motivo plausível. Ler a ajuda real, ou aiglot help --json para toda a árvore de comandos de uma vez, elimina isso.

Ele deixa claro que deve haver um lote por cultura. Um agente que assume que um único trabalho com quatro destinos escreverá uma instrução que um arquivo PO não pode processar, e você gastará um ciclo de plano para descobrir isso.

Ele especifica o idioma de origem. Sem isso, a origem é inferida pelo conteúdo, e essa inferência é menos confiável justamente onde mais custa caro: rótulos curtos de UI, arquivos que já possuem uma linha traduzida perdida e textos repletos de nomes inventados.

Ele coloca uma trava antes do gasto. aiglot batches approve é o único comando que consome créditos. Tudo antes disso é gratuito e repetível, então pedir para ver quatro planos primeiro não custa nada. Essa propriedade é o que torna um ciclo de agente não assistido razoável em vez de assustador: um agente que te entende mal queima planos, não dinheiro.

O que o agente realmente executa

for pair in fr:French de:German es:Spanish ja:Japanese; do
  code=${pair%%:*}
  lang=${pair#*:}
  po=~/dev/starfall/Content/Localization/Game/${code}/Game.po

  # 1. Create the batch. Free. Returns the file and its plan.
  id=$(aiglot batches create "$po" \
        --instruction "The source language is English. Translate into ${lang} only the entries whose msgstr is still empty. Leave msgctxt and msgid exactly as they are, and keep every placeholder and rich-text tag untouched." \
        --json | jq -r '.data.id')

  # 2. Read the plan, still free.
  aiglot batches get "$id" --json | jq '.data.plan'

  # 3. Approve. The only step that spends credits.
  aiglot batches approve "$id" --quality lite \
    --instructions "Keep UI labels under 28 characters. Keep placeholders exactly as written."

  # 4. Wait for a TERMINAL status, not for a specific one.
  until status=$(aiglot batches get "$id" --json | jq -r '.data.status'); \
    [ "$status" = "completed" ] || [ "$status" = "failed" ] || [ "$status" = "cancelled" ]; do
    sleep 5
  done

  [ "$status" = "completed" ] && \
    aiglot batches download "$id" --output "${po%.po}.translated.po"
done

Um detalhe ali vale a pena ser aproveitado mesmo que você nunca traduza um jogo. O ciclo aguarda qualquer status de terminal em vez de monitorar apenas por completed. Um script que espera apenas pelo status esperado aguardará para sempre em caso de falha, porque a comparação com um valor que nunca chega não é um erro. É apenas sempre falso.

Se o seu agente prefere ferramentas a um shell, o aiglot mcp faz a ponte com o servidor MCP. A CLI é o melhor ponto de partida: funciona em scripts, funciona em CI e você pode ler exatamente o que foi executado.

A outra metade: um agente que apenas prepara os arquivos

A automação total não é o único formato útil e, para uma primeira passagem, muitas vezes não é o ideal.

Um agente é igualmente valioso fazendo a parte chata e parando por aí. Peça para ele percorrer o repositório, encontrar cada arquivo de localização, relatar quais culturas existem e quais entradas ainda não foram traduzidas, e montar um único ZIP com um arquivo por cultura. Então, você mesmo faz o upload desse arquivo, lê o plano, aprova e deixa o agente colocar os resultados nos caminhos corretos depois. Essa divisão mantém as duas decisões com a pessoa que deve tomá-las, qual conjunto de idiomas você está pagando e se o plano está correto, e entrega à máquina a manipulação de arquivos, que é a parte genuinamente tediosa e propensa a erros. A página de soluções de localização de jogos demonstra esse mesmo processo via navegador, caso você prefira visualizá-lo antes de criar o script.

Onde o humano ainda é essencial

Não vamos dizer que a tradução por IA substitui um tradutor de jogos, porque, especificamente para jogos, ela não substitui.

Use para o volume bruto. Strings de UI, descrições de itens e equipamentos, tooltips, nomes de conquistas, notas de atualização, a longa lista de barks e textos de ambientação. Esse é o volume que faz os estúdios adiarem a localização por um ano, e é irrelevante em uma primeira passagem.

Deixe a revisão humana para onde ela realmente agrega valor. Sua primeira hora de jogo, as vozes dos personagens principais, qualquer coisa cômica ou que rime. Uma primeira versão seguida de um revisor é um bom uso de um especialista e um mau uso de uma semana gasta dentro de arquivos.

Contrate um especialista diretamente para a página da sua loja e para o seu trailer, que são os dois textos que decidem se alguém verá o resto.

A razão pela qual essa divisão funciona é que volume e importância não estão correlacionados, e, quando você percebe isso, a decisão do orçamento torna-se óbvia. A página da sua loja tem algumas centenas de palavras que carregam a maior parte do risco de reputação: pagar um especialista nativo por ela é barato em termos absolutos e obviamente vale a pena. Já as suas nove mil strings de interface e de itens em oito idiomas representam quase a totalidade das palavras, mas nenhum do mesmo risco, e nenhum orçamento sobrevive a uma taxa por palavra para elas.

Portanto, processe o volume aqui e depois defina seu próprio limite. Alguns estúdios enviam o resultado direto para a build. Outros adicionam revisão profissional nos seus dois maiores mercados, ou apenas nos textos de missões, e deixam o restante como foi retornado. Ambas as abordagens são razoáveis, e nenhuma delas é um reparo de uma primeira versão mal feita.

A automação existe para que o tempo do especialista seja dedicado ao idioma, e não à manipulação de arquivos. Essa é a proposta completa, e ela é honesta.

Comece com o arquivo que você já tem

Exporte do seu engine. Envie esse arquivo. Leia o plano. Nada é cobrado até que você aprove, então o custo para descobrir se isso se encaixa no seu projeto é apenas um upload e dois minutos.

Se você tem uma Unity String Table, uma pasta de arquivos PO do Unreal ou uma planilha de diálogos que está esperando desde o seu último marco, esse é o ponto de partida. Cadastre-se no AI Glot e traduza um arquivo primeiro, depois direcione um agente para o restante.