Como traduzir jogos Unreal Engine

Um jogo em Unreal Engine parece a coisa mais difícil de traduzir no seu disco. Não há pasta data, não há arquivos de script, não há um .json para abrir — só um executável, um diretório Content/Paks com um ou dois arquivos .pak enormes e, talvez, um par de containers .utoc/.ucas. A boa notícia é que o texto que você realmente quer normalmente não está escondido dentro desses arquivos de propósito. O Unreal tem um sistema de localização de primeira classe, e a maioria dos jogos lançados o usa. Seu trabalho é achar a tabela, trocar as strings e entregar ao motor um arquivo pequeno que tem prioridade sobre o original.

Essa última parte é o que torna o Unreal agradável depois que você entende como funciona. Você não reconstrói um jogo de 60 GB. Você produz um arquivo de override medido em kilobytes e o coloca ao lado dos originais.

Uma coisa antes dos passos: o suporte a Unreal no RuneTranslate é de melhor esforço e mais novo que o de motores como RPG Maker ou Ren'Py. Ele já foi confirmado jogável em títulos UE4 reais, mas a superfície do formato é enorme e cada estúdio empacota de um jeito. Verifique uma build exportada dentro do jogo antes de se comprometer com uma execução longa de tradução.

O que um jogo Unreal realmente distribui

O Unreal guarda o texto voltado ao jogador em arquivos `.locres` — a forma compilada do FTextLocalizationResource. Há um por cultura, num caminho como <Game>/Content/Localization/Game/ja/Game.locres, com irmãos para en, zh-Hans e o que mais o estúdio tenha distribuído. Um jogo sem tradução nenhuma normalmente ainda tem um, para a cultura em que foi escrito.

Um .locres não é um arquivo de texto nem uma lista simples de chave/valor. É uma tabela binária organizada em namespaces, cada um contendo keys, e cada key apontando para uma string. Nas versões modernas, o namespace e a key são armazenados como hashes (CRC32 na versão 2, CityHash64 sobre UTF-16 na versão 3) em vez de nomes legíveis, e as próprias strings ficam numa tabela de busca compartilhada e desduplicada, com contagem de referências. O runtime nunca procura uma string pelo texto em inglês — ele a procura por aquele par namespace/key, que é compilado nos Blueprints e no C++ do jogo em tempo de build.

Essa estrutura dita a única forma segura de editar um. O RuneTranslate preserva cada hash de namespace, hash de key e hash de string de origem byte a byte e muda só o valor, depois reconstrói a tabela de strings desduplicada e suas contagens de referência. Nada recalcula um hash, então nada pode produzir uma key que o jogo não encontre. As traduções ficam livres para ser mais longas ou mais curtas que o original.

Esses arquivos .locres são então empacotados em arquivos .pak — identificados por um valor mágico 0x5A6F12E1 num footer bem no fim do arquivo — ou, em títulos UE5 modernos, em containers IoStore .utoc/.ucas.

Confira o escopo antes de gastar uma hora

O .locres cobre interface, menus, mensagens de sistema, texto de tutorial, nomes de itens e habilidades, e legendas — algo em torno de 90% do texto visível de um jogo típico. É essa parte que o RuneTranslate lê e grava.

O que ele não cobre: texto compilado em DataTables ou embutido em pacotes `.uasset` cozidos. Alguns estúdios — em especial em projetos menores ou muito movidos a Blueprint — guardam o diálogo ali, e não no sistema de localização. Essas strings ficam endereçadas por hash dentro dos pacotes cozidos, sem índice de diretório legível, e lê-las direito exige um arquivo de mapeamento .usmap que o jogo distribuído não inclui. Se o seu jogo guarda o script ali, a extração volta com menus e botões e nenhum diálogo, e o RuneTranslate relata isso como um resultado explícito de fora do escopo, em vez de fingir que deu certo.

Vale saber cedo: a forma mais rápida de conferir é rodar a criação do projeto e olhar o que saiu. Algumas centenas de strings curtas, todas do tipo Continue, Options, Are you sure?, significam que a interface está localizada e o script não. Vários milhares de strings, com frases inteiras, significam que você está em boa situação.

A chave AES, e por que ela não é um muro

Boa parte dos paks distribuídos é criptografada com AES-256 — especificamente no modo ECB, sem IV, aplicado ao índice do arquivo e muitas vezes também às entradas individuais. Sem a chave, o arquivo é opaco: você não consegue nem listar o que há dentro dele.

A chave é recuperável por um motivo direto. O jogo precisa ler os próprios arquivos em tempo de execução, numa máquina sem rede e sem servidor de licença, então a chave está presente no binário distribuído como dado comum. O RuneTranslate varre o executável e suas DLLs em busca de janelas de 32 bytes, poda os candidatos com um filtro de entropia (uma chave AES real tem pelo menos 25 bytes distintos entre os 32), faz uma checagem barata descriptografando o primeiro bloco do índice e perguntando se o valor inicial se lê como um tamanho de string plausível, e então verifica os sobreviventes de verdade: descriptografa o índice inteiro e compara o SHA-1 dele com o hash que o próprio footer do pak registra. Esse último passo é a diferença entre isto e os buscadores de chave por ranking de entropia que circulam por aí — ou o candidato reproduz o hash que o próprio arquivo registrou, ou é rejeitado. Uma chave errada nunca pode ser aceita.

Alguns jogos guardam a chave como texto em vez de bytes crus, e alguns a dividem entre instruções separadas no binário; os dois casos são tratados. Se nada disso funcionar, a caixa de diálogo de Novo projeto aceita uma chave colada em hex (0x… ou 64 caracteres hexadecimais) ou em base64, e, uma vez recuperada, a chave fica em cache por projeto, para você não varrer um executável de 85 MB a cada exportação.

O IoStore do UE5 é diferente, e a extração é direcionada

Títulos UE5 distribuem cada vez mais containers IoStore em vez de paks simples: um diretório .utoc acompanhado de um blob de dados .ucas, usando compressão Oodle e criptografia própria. A abordagem ingênua aqui é descompactar tudo, o que num jogo de 105 GB nem chega a ser uma abordagem.

O RuneTranslate embute o retoc (licenciado sob MIT) e pede a ele que converta os containers para um pak legado filtrado só nos arquivos de localização — o equivalente a to-legacy -f locres --no-shaders --no-script-objects. Um título IoStore de 105 GB filtra para alguns kilobytes de .locres, em segundos e não em horas. O retoc também cuida do AES e do Oodle do próprio container, e é por isso que jogos IoStore contornam o problema de Oodle que paks soltos podem ter.

A metade importante disso é que o IoStore só complica a leitura. A escrita é universal, e é o assunto da próxima seção.

A saída é um pak de override, não um jogo reconstruído

Essa é a parte que nenhum guia concorrente explica direito, e é o motivo de traduzir Unreal ser barato assim que funciona.

O Unreal monta os arquivos pak numa ordem definida, e qualquer arquivo cujo nome termine em `_P` é montado por último. As montagens posteriores vencem. Então um arquivo pequeno contendo nada além do seu .locres modificado, no mesmo caminho virtual que o jogo base usa, simplesmente sobrepõe o original — o gerenciador de localização carrega o seu e nunca vê o que veio no jogo.

• Sem re-assinar. A assinatura de pak é um mecanismo RSA totalmente separado e raramente é exigida em títulos comerciais distribuídos; o override não mexe nisso.
• Sem chave AES para a saída. O override é gravado sem criptografia e sem compressão. A chave só era necessária para ler o original.
• Sem reempacotar o jogo. Os arquivos base ficam intocados. Uma instalação de 60 GB continua com 60 GB; sua tradução é um arquivo medido em kilobytes.
• Funciona para jogos IoStore também. O .locres é lido pelo sistema de arquivos de pak, e não pelo carregador de pacotes Zen, então um _P.pak solto e comum é reconhecido até por um jogo UE5 cujos assets moram todos em .utoc/.ucas.

Você instala copiando o _P.pak produzido para <Game>/Content/Paks/ — a mesma pasta em que estão os originais. Alguns jogos também montam uma subpasta ~mods/, o que funciona igualmente bem. Remover a tradução é apagar aquele único arquivo, o que torna o rollback trivial e torna seguro testar cedo.

Os passos

1. Instale o RuneTranslate pela página de download e entre na conta. É preciso entrar com uma conta gratuita do Patreon no primeiro início; o tier gratuito libera todos os motores e todos os provedores — ele limita a velocidade e mantém um projeto por vez.
2. Crie um novo projeto e aponte-o para a pasta raiz do jogo — aquela que contém o executável e o diretório <Game>. A detecção procura por Content/Paks e pelo valor mágico do footer de pak, ou por .utoc/.ucas.
3. Se os arquivos estiverem criptografados, deixe a recuperação de chave rodar. Ela varre os binários distribuídos e verifica cada candidato contra o hash de índice do próprio pak. Se vier vazia, cole uma chave na caixa de diálogo.
4. Deixe a extração terminar. Você recebe as entradas .locres da cultura de origem, agrupadas por alvo de localização, prontas para revisão.
5. Escolha um provedor e traduza. Strings curtas de interface e diálogos longos podem ir para provedores diferentes, se você quiser gastar dinheiro só onde importa.
6. Revise o que voltou. Strings de menu são onde a tradução automática é mais fraca — um Save ou Load sozinho não tem contexto, e um botão de duas palavras que volta como uma frase vai estourar o widget.
7. Exporte. O RuneTranslate grava um único _P.pak sem criptografia, contendo o seu .locres modificado no caminho correto relativo ao motor.
8. Copie esse arquivo para <Game>/Content/Paks/ e inicie o jogo.

Teste depois do passo 8 com um punhado de strings traduzidas, antes de passar o jogo inteiro por um provedor. Se o override for ser ignorado — pasta errada, cultura errada, montagem incomum —, você quer descobrir isso em cinco minutos, e não depois de pagar por 9.000 strings.

Placeholders e rich text

A formatação de FText do Unreal usa {0}, {1} para argumentos posicionais e {PlayerName}, {Count} para os nomeados, além da marcação <RichText> com fechamento </> para estilo inline. Se um provedor de tradução descarta ou corrompe um desses, o jogo não mostra uma frase levemente errada — ele mostra uma string de formato quebrada, ou o argumento some da linha em silêncio.

O RuneTranslate mascara cada um deles atrás de um placeholder neutro antes de o provedor ver a string, e os restaura depois. O provedor traduz em volta dos marcadores em vez de através deles, então um argumento não pode ser apagado por um modelo que achou que as chaves eram um erro de digitação. Se você quiser ir além e segurar strings específicas fora da tradução por completo, os filtros de exclusão por regex funcionam em qualquer motor, e um glossário mantém os nomes próprios estáveis no jogo inteiro.

A armadilha dos acentos, que é um bug de codificação e não de fonte

Esta merece documentação própria porque o sintoma aponta exatamente para o lado errado. O Unreal serializa uma string com um prefixo de tamanho: tamanho positivo significa um byte por caractere, tamanho negativo significa UTF-16. O motor escolhe a forma estreita só quando todo caractere é ASCII de 7 bits — a checagem dele rejeita qualquer coisa acima de 0x7F. O carregador foi feito do mesmo jeito, então, se receber uma string estreita contendo um byte alto, ele substitui cada um por um ? literal.

A consequência prática: uma tradução com poción mágica escrita na forma estreita chega ao jogador como poci?n m?gica. E a faixa afetada é U+0080–U+00FF, que é exatamente a das letras acentuadas do espanhol, do francês, do alemão, do português, do italiano e das línguas nórdicas. Polonês, turco, tcheco, grego, cirílico, japonês e chinês ficam todos acima de U+00FF, tomam o ramo largo automaticamente e nunca são afetados.

Então a assinatura é: os acentos quebram em espanhol, mas o russo está bem. Se você vir isso, é um bug de codificação em quem escreveu o arquivo, e não um glifo faltando na fonte do jogo — um glifo faltando aparece como um quadradinho ou como nada, nunca como uma interrogação. O RuneTranslate tinha exatamente esse bug e o corrigiu na 0.49.4; o codificador agora mora em um lugar só e grava a forma larga para qualquer coisa fora do ASCII. Vale conhecer porque outras ferramentas dessa área ainda erram nisso.

Escolhendo um provedor

Três dos nove provedores não exigem chave de API nenhuma — o Google, o DeepL gratuito e os modelos Classic/Next-gen do DeepL — e o tier gratuito te dá todos eles. Para um jogo que é quase só interface, um provedor gratuito serve muito bem. Para títulos com muito diálogo, um provedor de LLM lida com contexto muito melhor; o OpenAI, o Anthropic, o DeepSeek, qualquer endpoint compatível com OpenAI e um modelo local via Ollama ou LM Studio estão todos disponíveis. A comparação de provedores percorre no que cada um é bom e ruim, com números reais de custo.

Resolução de problemas

O jogo roda, mas nada está traduzido

Quase sempre é uma de três coisas. O arquivo não está em <Game>/Content/Paks/ — colocá-lo ao lado do executável não faz nada. O nome do arquivo perdeu o sufixo _P, caso em que ele monta na ordem alfabética comum e o pak base pode vencer. Ou o jogo está rodando numa cultura que você não traduziu: ele carrega o .locres da cultura que resolveu na inicialização, então um jogo que força en vai ignorar um override escrito só para ja. Confira antes de tudo o idioma configurado no jogo.

A extração falha num pak solto comprimido com Oodle

Um .pak solto comprimido com Oodle precisa de um descompressor que não pode ser embutido. Se o jogo também distribui containers IoStore, o caminho pelo retoc cuida do Oodle e você está bem. Se forem só paks soltos, isso é uma parada definitiva por enquanto, relatada de forma explícita e não como um resultado vazio silencioso.

O jogo não tem .locres em lugar nenhum

Então o texto dele está compilado em assets cozidos, e este caminho não o alcança. O exemplo mais claro é um grande título UE5 de serviço ao vivo cujo índice IoStore é reduzido a hashes de conteúdo, sem nome de arquivo nenhum — centenas de milhares de chunks e zero .locres. O RuneTranslate diz isso, em vez de moer o container inteiro.

A detecção não dispara

Aponte para a pasta que contém o executável, não para o Content/Paks em si e nem para uma pasta-mãe cheia de outros jogos. Se ainda assim não detectar, o empacotamento é incomum e vale relatar — o formato pak tem layouts de footer específicos por versão, e um dialeto que ninguém viu ainda é exatamente o tipo de coisa que acaba sendo adicionado.

Limites honestos

O suporte a Unreal é de melhor esforço. .locres dentro de paks soltos e criptografados e dentro do IoStore do UE5 é o caminho comprovado, confirmado jogável dentro do jogo num título UE4 em espanhol. Texto em DataTable e em .uasset cozido não é coberto. Paks soltos comprimidos com Oodle sem um equivalente IoStore não são suportados. Paks com assinatura exigida não podem ser sobrepostos, embora sejam raros na prática. E como o formato varia tanto entre versões de motor e estúdios, trate a primeira exportação como um teste, e não como a entrega.

O que você acaba tendo é uma build traduzida e jogável que fica na sua máquina: o jogo original intocado, mais um arquivo pequeno que você pode apagar para desfazer tudo. Se você está comparando motores ou checando se o seu jogo é coberto, a página do motor Unreal tem o detalhe técnico e todos os motores lista os dezessete formatos suportados, incluindo Unity e RPG Maker. Se você é novo em todo esse processo, comece com o guia geral e volte aqui para as partes específicas do Unreal.