Adicione multilíngue ao seu app Next.js.
Traduza seus arquivos de localidade, conteúdo Markdown e páginas HTML através de uma única chamada de API. Funciona com o App Router, next-intl e qualquer configuração de roteamento i18n.
Next.js oferece roteamento. Não oferece traduções.
O Next.js App Router tem excelente suporte embutido para roteamento baseado em localidade. Bibliotecas como next-intl facilitam o gerenciamento de arquivos de tradução e a troca de localidade. O que elas não resolvem é a tradução em si — alguém precisa produzir o conteúdo traduzido em cada idioma, e esse alguém geralmente é você. Para a maioria das equipes, o fluxo de trabalho é copiar o JSON em inglês para o DeepL, corrigir a formatação que ele quebra, colar o resultado de volta, repetir para cada idioma. É lento, propenso a erros e não escala.
O fluxo mais comum é escrever todas as strings da interface em inglês dentro do código-fonte, depois traduzir o arquivo messages.json para cada idioma alvo. Na teoria, isso é simples. Na prática, manter mais de 10 arquivos de localidade sincronizados com as mudanças no código-fonte se torna um ponto de dor recorrente. Toda vez que o texto em inglês muda, todos os arquivos de localidade precisam ser atualizados. Ao usar APIs de tradução padrão para isso, os nomes das chaves são corrompidos, os espaços reservados de variáveis são traduzidos e a estrutura JSON diverge entre as localidades — causando bugs sutis em tempo de execução difíceis de rastrear.
PolyLingo se encaixa na sua configuração i18n existente do Next.js.
Se você usa next-intl ou qualquer outra biblioteca i18n, suas mensagens já estão em JSON. O PolyLingo pega esse JSON, envia para o modelo de tradução e retorna cópias traduzidas para cada idioma alvo — com as chaves intactas, a estrutura preservada e os valores de string corretamente traduzidos. Você pode chamá-lo a partir de um script de build, um webhook ou da interface do PolyLingo. O resultado vai direto para o seu diretório de mensagens.
O fluxo: escreva seu messages.json em inglês. Execute um único script que chama a API PolyLingo com seu arquivo fonte e todos os códigos dos idiomas alvo. Receba um arquivo JSON traduzido por idioma, com estrutura idêntica. Escreva cada um no seu diretório messages/. Faça commit. Pronto.
Para sites com muito conteúdo em Markdown em CMS (Sanity, Contentful), a mesma abordagem se aplica ao conteúdo: exporte como Markdown ou HTML, traduza, escreva de volta no CMS via sua API. Todo o pipeline pode rodar como etapa de build ou acionado por webhook.
// This repository: frontend/scripts/translate-messages.mjs
// Chunks large namespaces (e.g. home) so the model stays within output limits.
//
// export POLYLINGO_API_KEY=pl_xxx
// npm run i18n:polylingo
//
// Writes messages/es.json, fr.json, … from messages/en.json via POST /v1/translate
// with format: "json". See MARKETING_I18N.md for options and CI notes.
//
// Minimal one-shot pattern (fine for small message files):
//
// const source = readFileSync('./messages/en.json', 'utf8')
// const { translations } = await fetch(apiUrl + '/translate', {
// method: 'POST',
// headers: { Authorization: `Bearer ${apiKey}`, 'Content-Type': 'application/json' },
// body: JSON.stringify({
// content: source, format: 'json', source: 'en',
// targets: ['es', 'fr', 'de'], model: 'standard',
// }),
// }).then((r) => r.json())
//
// for (const [lang, raw] of Object.entries(translations)) {
// const obj = typeof raw === 'string' ? JSON.parse(raw) : raw
// writeFileSync(`./messages/${lang}.json`, JSON.stringify(obj, null, 2))
// }// i18n.ts (next-intl v4)
import { getRequestConfig } from 'next-intl/server'
export const locales = [
'en', 'ar', 'bn', 'cs', 'da', 'de', 'el', 'es', 'fa', 'fi',
'fr', 'he', 'hi', 'id', 'it', 'ja', 'ko', 'ms', 'nl', 'no',
'pl', 'pt', 'ru', 'sv', 'sw', 'th', 'tr', 'uk', 'vi', 'zh',
] as const
export type Locale = (typeof locales)[number]
export default getRequestConfig(async ({ requestLocale }) => {
const locale = await requestLocale
return {
locale,
messages: (await import(`./messages/${locale}.json`)).default,
}
})// package.json
{
"scripts": {
"dev": "next dev",
"build": "next build",
"i18n:polylingo": "node scripts/translate-messages.mjs",
"translate:build": "npm run i18n:polylingo && next build"
}
}Por que PolyLingo se encaixa no fluxo i18n do Next.js
- ✓Traduza arquivos messages/*.json diretamente — chaves sempre preservadas
- ✓Traduza conteúdo Markdown para posts de blog e páginas de documentação
- ✓Funciona com next-intl, next-i18next e configurações personalizadas
- ✓API REST integra com scripts de build e webhooks de CMS
- ✓Todos os 36 idiomas em uma única requisição
- ✓Plano gratuito — 100.000 tokens por mês
- ✓Este repositório usa o próprio fluxo: npm run i18n:polylingo regenera localidades de marketing a partir de messages/en.json (veja MARKETING_I18N.md).
- ✓Funciona com App Router e Pages Router
- ✓Arquivos de saída prontos para commit — sem necessidade de reformatação
Configure multilíngue no seu app Next.js
Configure next-intl com seu arquivo de mensagens em inglês
Instale next-intl e configure seu i18n.ts e middleware. Escreva todas as strings da interface em messages/en.json. Estruture o arquivo como seu app precisar — plano ou aninhado. Este será sua única fonte de verdade.
Execute o script de tradução
Use a API JSON do PolyLingo a partir de um pequeno script Node (veja o código acima). Neste monorepo, execute npm run i18n:polylingo a partir de frontend/ com POLYLINGO_API_KEY configurada — ele divide namespaces grandes para maior confiabilidade. Execuções típicas levam bem menos de um minuto para um pacote completo de marketing.
Faça commit dos arquivos de localidade e faça o deploy
Os arquivos de localidade gerados são JSON válidos com estrutura idêntica ao seu arquivo fonte. Faça commit no seu repositório. Adicione o script de tradução ao seu pipeline CI para manter as localidades sincronizadas a cada mudança de conteúdo.
Casos de uso multilíngue para Next.js
Apps SaaS e dashboards
Traduza toda sua biblioteca de strings da interface em uma execução de script. Suporta todos os recursos de formatação do next-intl — datas, números, plurais — porque a estrutura JSON é preservada exatamente.
Sites de conteúdo e blogs
Para sites Next.js com muito conteúdo usando Sanity ou Contentful, use PolyLingo para traduzir o conteúdo das páginas além das strings da interface — mesma API, mesmas garantias de preservação de formato.
E-commerce com variantes regionais
Traduza nomes de produtos, descrições, páginas de categoria e interface de checkout. Use o modelo Avançado para textos de marketing onde a voz da marca importa, e o modelo Padrão para strings funcionais da interface.
Perguntas frequentes
Isso funciona com o Next.js App Router?
Sim. A integração PolyLingo é apenas um script que lê e escreve arquivos JSON — não depende dos internos do Next.js. Funciona com App Router, Pages Router ou qualquer framework. O exemplo de configuração next-intl mostrado usa a API v4 com requestLocale, compatível com Next.js 13, 14 e 15.
E se meu messages.json mudar frequentemente?
O padrão recomendado é adicionar o script de tradução ao seu pipeline CI/CD, acionado nas mudanças do messages/en.json. Isso mantém todos os arquivos de localidade sincronizados automaticamente. Para equipes com mudanças frequentes de texto, isso previne completamente a divergência de localidades.
PolyLingo funciona com next-i18next assim como com next-intl?
Sim. next-i18next usa a mesma estrutura JSON de localidade. O script de tradução funciona da mesma forma — aponte para seu diretório public/locales/en/ e escreva as saídas para os outros diretórios de localidade. A compatibilidade do formato JSON é a mesma.
E quanto a conteúdo dinâmico que não está no arquivo de mensagens?
Conteúdo dinâmico — posts de blog, descrições de produtos, conteúdo gerado pelo usuário — deve ser traduzido na camada de dados, seja no seu CMS ou via script de build que processa o conteúdo antes de chegar ao Next.js. PolyLingo lida igualmente bem com Markdown, HTML e texto simples para esse propósito.
Posso traduzir apenas as strings que mudaram desde a última execução?
Tradução incremental (traduzir apenas chaves alteradas) está no roadmap. Atualmente o script retraduz o arquivo completo. Para a maioria dos arquivos de mensagens (menos de 20KB), isso é rápido o suficiente para rodar a cada commit. Para arquivos muito grandes, dividir por namespace é a abordagem recomendada.
Existe uma forma de revisar as traduções antes de irem para produção?
O padrão recomendado é fazer commit dos arquivos de localidade traduzidos em um branch ou PR separado para revisão antes de mesclar ao main. Isso é prática padrão para equipes que precisam de revisão humana na qualidade da tradução. PolyLingo gera uma boa primeira versão — para a maioria das strings da interface, a saída do modelo Padrão não requer edição.
Guias relacionados
Traduza arquivos JSON de localidade
Como o PolyLingo lida com estrutura JSON, objetos aninhados e variáveis de interpolação.
Multilíngue para CMS headless
Traduzindo conteúdo no nível do CMS junto com a tradução das strings da interface.
Traduza Markdown sem quebrar a formatação
Para sites Next.js com posts de blog em Markdown ou páginas MDX.
Tenha seu primeiro arquivo de localidade traduzido em menos de 5 minutos.
Chave de API gratuita. Sem cartão de crédito. Cole seu JSON de mensagens e veja o resultado imediatamente.
Obtenha sua chave de APIO script de tradução leva 5 minutos para configurar. Plano gratuito — sem necessidade de cartão de crédito.