Adicione uma biblioteca de i18n em tempo de execução, depois converta as strings que o Copilot já escreveu, e só então evite que novas apareçam. O passo que a maioria das equipes erra é o último, porque um arquivo de instruções do repositório não chega a todas as interfaces pelas quais o Copilot escreve código. O chat e o coding agent o lêm. O autocompletar inline não. O globalize.now é uma infraestrutura de localização com IA que converte a base de código uma única vez e produz as chaves e os arquivos de locale que sua biblioteca de i18n lê.
Por que o Copilot continua fixando strings no código mesmo depois que eu adiciono um arquivo de instruções?
Porque o arquivo de instruções não está conectado ao caminho mais rápido. A documentação do VS Code afirma claramente que as instruções personalizadas não são consideradas nas sugestões inline que aparecem enquanto você digita. E esse é o modo em que a maioria das pessoas passa a maior parte do dia.
Então a regra que você escreveu é real, e ela se aplica quando você faz uma pergunta ao Copilot no chat ou passa uma tarefa ao coding agent. Ela não se aplica quando você digita uma tag JSX e aperta Tab numa sugestão em cinza. As duas ações geram código que acaba sendo commitado. Só uma delas leu sua regra.
Quais interfaces do Copilot leem suas instruções?
Três interfaces escrevem código no seu repositório, e elas não se comportam da mesma forma.
| Interface | Lê as instruções? | Onde o resultado aparece |
|---|---|---|
| Sugestões inline | Não | Direto no arquivo que você está editando |
| Chat e modo agente | Sim | Edições que você revisa no editor |
| Coding agent | Sim | Um pull request em rascunho que você revisa |
O coding agent é o mais amigável dos três para esse problema. Você atribui a ele uma issue, ele trabalha em segundo plano e abre um pull request em rascunho, então o resultado chega a um lugar que um revisor já costuma olhar. As sugestões inline chegam sem passar por nenhum filtro.
Como configurar i18n em um projeto no Copilot?
Primeiro, escolha a biblioteca de tempo de execução que o seu framework pede. next-intl para o App Router do Next.js, react-i18next para qualquer outro app React, Lingui se você quiser extração em tempo de compilação e catálogos PO. Comparamos as três em next-intl vs react-i18next vs Lingui.
O Copilot não é específico de um framework como o Lovable ou o Bolt são, o que significa que a questão da stack fica genuinamente em aberto e a escolha da biblioteca é sua. O que não está em aberto é a ordem. Instale a biblioteca, converta as strings que já existem, e só então se preocupe com prevenção. Uma regra de prevenção escrita sobre uma base de código que ainda está 90% em inglês fixado não te dá nada para medir.
O que deveria constar em .github/copilot-instructions.md?
Um arquivo de instruções do repositório nesse caminho é detectado automaticamente e aplicado às solicitações de chat no workspace. A própria orientação do GitHub é manter cada instrução curta e autocontida, explicar o raciocínio por trás dela e deixar de fora qualquer coisa que um linter já aplique. Uma seção de i18n que segue esse conselho é enxuta:
## User-facing text
- User-facing text belongs in the message catalog, never in a component literal.
- Use the translation function from our i18n library for every visible string.
- Reason: a literal cannot be translated and does not show up as a missing key,
so it ships silently in one language.
- Add new English values to the source catalog only. Never hand-edit other locales.
- Not user-facing: test names, log lines, error codes, internal constants.
A última linha importa mais do que parece. Regras aplicadas em excesso acabam sendo ignoradas, e uma regra que manda um agente envolver mensagens de log vai ensiná-lo que a seção inteira é apenas ruído. Se você ainda não tem nenhum arquivo de instruções, o VS Code pode gerar um rascunho a partir da sua base de código com o comando init no chat, o que é um ponto de partida melhor do que uma folha em branco.
Um arquivo de instruções específico por caminho pode fazer melhor?
Sim, e essa é a única alavanca que o Copilot tem que os arquivos de regras de outros editores não têm. Arquivos terminados em .instructions.md, armazenados em .github/instructions, carregam um glob applyTo no frontmatter e só são carregados quando o agente mexe em um arquivo correspondente.
---
name: 'UI strings'
description: 'String handling rules for components'
applyTo: '**/*.{jsx,tsx}'
---
Every visible string in this file must come from the catalog.
Key format is feature.element.state, lowerCamelCase.
If you add a key here, add its English value to the source catalog in the same change.
Restringir a regra aos arquivos de componente é o que a mantém confiável. Ela dispara onde vive o texto voltado ao usuário e fica em silêncio nas suas rotas de API e nos scripts de migração. Se você já mantém um AGENTS.md ou um CLAUDE.md na raiz do repositório, o Copilot também os lê como instruções sempre ativas, então uma equipe que roda vários agentes não precisa de um arquivo separado para cada ferramenta.
O que pega as strings que as instruções deixam passar?
Uma regra de lint no CI, porque essa é a única camada nessa stack que falha um build. As instruções mudam as chances; uma verificação que falha muda o resultado. Detalhamos essa camada de enforcement em por que agentes de IA continuam adicionando strings fixadas no código, e a configuração se transfere sem alterações para um repositório no Copilot.
O acréscimo específico do Copilot é o pull request. As instruções do repositório se aplicam tanto à revisão de código do Copilot quanto ao chat, então o mesmo arquivo que molda a geração também molda os comentários de revisão no PR em rascunho do coding agent. Isso te dá um único filtro que o autocompletar inline não consegue contornar, o que é o mais próximo de uma correção para a lacuna mencionada no início deste post.
Nada disso quita a dívida que já existe no repositório, e nada disso preenche um arquivo de locale. Pegar um texto literal na revisão te avisa que falta uma string. Alguém ainda precisa transformá-la em chave, traduzi-la e evitar que os outros locales saiam de sincronia.
Onde o globalize.now se encaixa?
Na camada que produz o catálogo, que é a parte que nem sua biblioteca de i18n nem seu arquivo de instruções fazem. Você conecta o repositório no app e ele converte a base de código uma única vez, substituindo as strings fixadas por chaves e gerando os arquivos de locale. Depois dessa conversão pontual, os jobs de push traduzem as novas unidades de catálogo que seus commits introduzem.
A saída é em JSON ou PO, então os catálogos chegam no formato que sua biblioteca de tempo de execução já lê. A mesma abordagem cobre os outros editores agentic: Claude Code e Cursor esbarram na mesma parede por um caminho diferente, e há uma versão passo a passo para uma base de código em Next.js em adicionando i18n a um app Next.js construído com IA. A documentação para desenvolvedores cobre a conversão em mais detalhes, e os planos estão na página de preços.
Resumo rápido
Escreva o arquivo de instruções, restrinja uma regra específica por caminho aos seus arquivos de componente, e coloque uma regra de lint no CI para que a lacuna entre o que o Copilot foi instruído a fazer e o que ele realmente digitou vire um build quebrado em vez de uma string em inglês publicada. Depois converta as pendências acumuladas de uma vez, para que a regra tenha algo consistente para proteger.
O globalize.now transforma textos fixos do app em arquivos de locale prontos para tradução e os mantém atualizados a cada novo lançamento.
Experimente o globalize.now grátis