Na maioria dos projetos que trabalhei, a escolha padrão pra internacionalização sempre foi o react-i18next. Funciona bem e resolve muita coisa. Mas quando comecei um projeto pessoal pequeno chamado Veedgee, veio a dúvida: precisava mesmo de tudo isso?

Era um app simples. Poucos textos e apenas dois idiomas. Ainda assim, eu teria que instalar uma lib grande, configurar bastante coisa e ainda lidar com aquele setup chato nos testes. Então, baseado nas especificações extremamente simples do site que eu estava prestes a fazer, decidi experimentar algo diferente desta vez: criar meu próprio mecanismo de tradução. O mecanismo ficou minúsculo e acabou funcionando muito bem.

Depois do Veedgee, levei essa ideia pro meu site pessoal e funcionou bem de novo. Então, o próximo passo foi óbvio: transformar isso numa lib. Assim nasceu a Polang.

O problema com o react-i18next (pra apps pequenos)

Não é sobre a lib ser ruim. Ela é robusta. O problema é usar um canhão pra matar mosquito, e estes são os pontos que mais me incomodam:

1. Primeiro contato confuso

Você bate o olho e não entende como integrar tudo que é necessário logo de cara. Sobram partes obscuras, tornando a experiência de configuração em algo não muito agradável

2. Testes são chatos

O setup da lib precisa ser repetido nos testes, então configurá-los costuma envolver operações assíncronas, mocks e mais setup do que deveria, bem longe de algo plug and play.

3. Persistência de idioma

Se você quiser salvar o idioma preferido do usuário, ou usar search param para carregar o site com um idioma prédefinido, vai precisar configurar na mão ou adicionar plugin. Infelizmente, nada disso vem embutido por padrão.

4. Tradução longe do componente

Se você quiser deixar suas traduções junto ao componente, como provavelmente já faz com estilos e testes, vai ter um trabalhinho adicional já que a lib não é desenhada para ser usada dessa forma.

A proposta da Polang

A ideia da Polang é resolver esses pontos de maneira indolor. Tudo que você precisa é:

Importar o Provider de i18n e definir os locales suportados

import { I18nProvider } from '@compilorama/polang';

const locales = [
  { code: 'en-US', name: 'English US' },
  { code: 'pt-BR', name: 'Português BR' },
];

export default function App() {
  return (
    <I18nProvider locales={locales}>
      <YourApp />
    </I18nProvider>
  );
}

Adicionar o LocaleSelect no layout

import { useTranslation, LocaleSelect } from '@compilorama/polang';
import translations from './header.t.js';

export default function Header() {
  const { t } = useTranslation(translations);
  return (
    <header>
      <LocaleSelect aria-label={t('locale')} />
    </header>
  );
}

Feito! Agora é só escrever traduções e conectá-las ao componente com o hook useTranslation. Sem mágica, sem configurações obscuras ou misteriosas.

Testando componentes que usam tradução

Mesma lógica simples. Para testar qualquer componente que use tradução:

1. Envolva-o com o Provider i18n
2. Passe pelo menos um locale para o provider

Pronto. O teste vai rodar liso.

Traduções orientadas a componentes

A Polang funciona muito bem em uma abordagem orientada a componente. Você pode manter componente, estilos, testes e traduções tudo junto no mesmo lugar.

Quando usar (e quando não usar)

Use Polang se:

• seu app é pequeno ou médio
• poucos idiomas
• você quer setup rápido
• quer evitar complexidade

Não use se:

• precisa de i18n avançado
• múltiplos namespaces complexos
• integrações pesadas

Enfim, nem todo projeto precisa de uma solução gigante. Às vezes, menos é melhor. A Polang nasceu para resolver o básico muito bem, sem fricção.

Se fizer sentido pra você, confira repositório da lib para saber mais. E se quiser conferir um exemplo real de uso da lib, acesse o repo do site da própria Polang.