How to translate a game’s .po and .mo files (gettext)

Se você abriu a pasta de um jogo e encontrou um diretório locale cheio de arquivos .po e .mo, esse jogo é localizado com gettext — e o RuneTranslate agora consegue traduzi-lo de ponta a ponta, da criação do projeto até exportar uma build jogável.

Este guia explica o que esses dois tipos de arquivo realmente são, por que editar aquele que você consegue ler geralmente não muda nada no jogo, e como traduzi-los corretamente.

.po x .mo — a distinção em que todo mundo tropeça

São duas formas do mesmo catálogo:

• `.po` — Portable Object. Um arquivo de texto simples que você abre em qualquer editor. Cada entrada tem um msgid (o texto original) e um msgstr (a tradução). É nele que os tradutores trabalham.
• `.mo` — Machine Object. Uma versão binária compilada dos mesmos dados, organizada para que o jogo encontre um texto instantaneamente. É este o arquivo que o jogo lê em execução.

Esse último ponto custa uma tarde a muita gente. Você pode traduzir cada linha de um .po, salvar, abrir o jogo — e não ver mudança nenhuma, porque o jogo nunca abre o .po. Ele carrega o .mo ao lado, que ainda guarda o texto antigo. Normalmente você compilaria um no outro com msgfmt, das ferramentas GNU gettext. O RuneTranslate grava os dois, então não há etapa de compilação separada.

Como é a pasta de um jogo com gettext

O layout canônico é um diretório locale indexado por código de idioma:

• MyGame/game.exe
• MyGame/locale/en/LC_MESSAGES/mygame.mo
• MyGame/locale/fr/LC_MESSAGES/mygame.mo
• MyGame/locale/de/LC_MESSAGES/mygame.mo

A pasta LC_MESSAGES faz parte da convenção, não é um engano, e mygame é o domínio de texto — o nome que o jogo pede ao carregar seus textos. Muitos jogos usam uma forma mais plana, como lang/fr.po, e isso também funciona.

Quais jogos usam gettext?

O gettext nasceu no mundo Unix e virou a forma padrão de localizar software escrito em C, Python e tudo baseado em GTK. Em jogos, isso significa:

• Jogos em Python e pygame
• Solarus, SDL e outros motores em C/C++
• Jogos localizados via Poedit, Weblate ou Crowdin, que falam PO nativamente
• Alguns projetos em Godot, que aceitam PO como fonte de tradução

É muito mais comum em jogos indie ocidentais do que japoneses — motores japoneses como Kirikiri e RPG Maker guardam o texto em formatos próprios.

Traduzindo um jogo gettext com o RuneTranslate

1. Aponte o RuneTranslate para a pasta do jogo. Aquela com locale/, lang/ ou i18n/ dentro. A detecção lê os bytes reais em vez de confiar na extensão, então um .mo que na verdade é uma cena 3D é ignorado em vez de gerar um projeto quebrado.
2. Confira o resumo. Antes de criar o projeto você vê a contagem de catálogos, a divisão entre .mo compilados e .po fonte, os idiomas que o jogo já traz e o total de strings.
3. Escolha um idioma e um provedor. Google ou DeepL gratuitos, ou sua própria chave da DeepL, OpenAI, Claude ou DeepSeek — veja a comparação de provedores.
4. Revise e exporte. Você recebe uma cópia completa do jogo com a tradução aplicada.

As duas coisas que quebram uma tradução gettext em silêncio

Os marcadores. Um msgid é uma string de formato, não um texto pronto. Em Hello, %s! o nome do jogador é substituído em tempo de execução. Tradutores automáticos costumam apagar %s, separá-lo com espaços ou — na forma nomeada do Python, %(player)s — traduzir a palavra de dentro. As consequências não são estéticas: um %s perdido desloca todos os argumentos seguintes e a maioria dos motores trava. O RuneTranslate mascara cada marcador que encontra (%s, %d, %(player)s, {count}, {0}) antes de enviar o texto ao provedor e os restaura depois.

Formas plurais. O inglês tem duas (“1 coin” / “5 coins”). Japonês e turco, uma. Russo e polonês, três. Um catálogo declara no cabeçalho quantas usa, e se esse número não bate com o idioma, o gettext acessa além do fim da lista e recorre em silêncio ao original sem tradução. O RuneTranslate reajusta as formas ao idioma de destino e reescreve o cabeçalho de acordo.

Por que a exportação grava o catálogo duas vezes

A exportação produz tanto um idioma novo correto — locale/<seu idioma>/LC_MESSAGES/ — quanto uma cópia atualizada do catálogo que o jogo já carregava.

O segundo é o que faz a tradução realmente aparecer. Um jogo decide qual idioma carregar por caminhos que a pasta não revela: pode ler o idioma do sistema, um arquivo de configuração, um parâmetro do lançador, ou simplesmente ter isso fixo no código. Adicionar um catálogo em português a um jogo que só pede inglês deixaria você olhando para uma build aparentemente igual. Sobrescrever o catálogo que ele de fato carrega elimina o palpite. Ambos acontecem apenas na cópia exportada — sua pasta original não é modificada.

As strings que você não traduziu mantêm a tradução que o jogo já trazia, então um projeto pela metade nunca apaga a localização do próprio desenvolvedor.

O que isto não consegue fazer

Só é possível traduzir o texto que já está em um catálogo. Se o desenvolvedor escreveu uma string direto no código em vez de passá-la pelo gettext, ela não está no .po nem no .mo, e nenhuma ferramenta PO pode achá-la ali. É um limite do formato, não da ferramenta.

O RuneTranslate também trata o msgid como texto fonte, que é o que o próprio gettext especifica. Alguns projetos deixam msgids em inglês enquanto o idioma original real fica no msgstr; esses serão traduzidos a partir do inglês.

Por fim, se o jogo roda em um motor com suporte direto — Godot, Unity, Ren’Py — quem cuida dele é esse motor, para que o restante do texto do jogo também fique acessível, e não só seus catálogos.

Antes de compartilhar

Abra a build exportada e leia algumas telas. Menus e botões são a checagem mais rápida, porque é onde vive a maior parte do texto de catálogo. Se algo estiver errado — o jogo não é detectado, o export não abre, ou o texto continua no idioma original — relate pelo menu Ajuda do aplicativo ou no Discord. Baixe o RuneTranslate e abra seu primeiro catálogo.