Vou apresentar aqui uma classe para tradução a partir de catálogos .PO e .POT, compatíveis com o GNU GETTEXT, mas antes vamos falar um pouco sobre os conceitos envolvidos na internacionalização de sites e softwares.

O termo "i18n" vem de i + nternationalizatio (18 letras) + n - internationalization ou internacionalização. Mas há também o conceito de localização, ao qual nos referimos por "l10n" - localization e uma grande confusão quanto às diferenças entre os dois. Depois de ler o que diz a wikipedia ainda fiquei com dúvidas e foi aqui que tive um esclarecimento um pouco maior. Vou tentar resumir nas minhas palavras.

Internacionalização

O processo de internacionalização consiste em colocar seu software ao alcance da comunidade internacional, traduzindo a interface para outros idiomas e substituindo este ou aque detalhe específico do seu "local cultural" por versões aceitas internacionalmente - me refiro a coisas como formatos de valores e datas, por exemplo.

Este é um processo de abertura, que busca mais abrangência. Alcançar um público mais diverso, que está familiarizado com "multilanguage interfaces".

A internacionalização é colocada como um estágio necessário à localização de um aplicativo. Localizar um aplicativo é algo que acontece com o tempo e se o aplicativo preenche certos requesitos, mas a internacionalização é para ser incluída no momento de desenvolver o projeto.
————————————————

Localização

Aqui a direção se inverte. Enquanto a internacionalização anda em direção ao mundo, a localização se dirige a um local específico - usualmente um país, e deve englobar detalhes específicos da cultura local, como se tivesse sido feito para este público específico.

Aqui falamos de suporte a caracteres de outros alfabetos, direção do texto na página (curiosidade: wikipedia em hebreu) , uso de linguagem local (pt_BR em vez de pt), imagens específicas, etc.

Isso inclui possívelmente a mudança do layout e outras coisas que vão além da simples tradução do texto.
————————————————

Já viu que o que se faz em geral é a internacionalização, né? o processo de localizar um software para todas as mais relevantes culturas é apenas para sistemas operacionais e programas comerciais como photoshop, etc. Trata-se de um trabalho que inclui muita pesquisa e adaptações, às vezes pesadas, no software.

O PHP tem suporte nativo ao GetText do GNU, que usa arquivos .MO - binários compilados a partir de catálogos .PO. Legal, muito rápido por usar arquivos compilados. Mas quando tentei usar um esquema mais complexo, com múltiplos textdomains, me enrolei todo, achei complicado e sem documentação, principalmente em português. Como sempre acontece comigo, resolvi fazer eu mesmo um sistema e criei uma alternativa intermediária.

A classe i18n usa os catálogos PO sem compilação para fazer a tradução e trabalha com múltiplos textdomains sem complicação. Através de i18n::parsePoFile() podemos parsear os arquivos e extrair as mensagens para usá-las na tradução.

Uma vantagem é preservar a possibilidade de usar editores como o PoEdit para ler as mensagens nos arquivos fonte e editar a tradução normalmente. Apenas na hora de ler nós faremos isso por nossa conta. É bom lembrar que para usar domínios diferentes para traduzir os mesmos arquivos, ao ler as mensagens, o PoEdit irá ignorar os domínios e acrescentar todas as mensagens a cada domíno - o ideal é usar domínios diferentes para diretórios diferentes (que não estejam contidos um no outro).

Como vamos usar o catálogo sem compilação, human-readable, não precisaremos ocupar espaço com os arquivos .MO que o PoEdit gera automaticamente, a não ser que queiramos usar ambos os métodos simultaneamente - o que é possível. Nesse caso, usaremos como domínio principal do i18n um domínio diferente do setado com bindtextdomain(). E podemos usar quantos textdomains quisermos no i18n, preservando o domínio principal para a função gettext() do PHP.

Código e exemplo da classe i18n