Rails 2.2 saiu já há algumas semanas e contínuo empolgado com um novo feature, o I18N ( abreviação de Internacionalização), que na minha opinião, foi o melhor acréscimo.

Com ele podemos definir facilmente em qual idioma nosso aplicativo ou site deve falar… uma verdadeira mão na roda para alterar métodos como number_to_currency e também para traduzir mensagens de erro do ActiveRecord ( ORM do Rails para mapear com database ).

Um grande lance e que ninguém comentou ainda, talvez por que o pessoal de Rails aqui no Brasil não esteja muito ligado neste mercado, é a construção de sites estáticos em Flash. Hoje em dia muitas coisas em sites em Flash são estáticos do ponto de vista de comunicação com banco de dados, mas várias vezes precisamos criar sites sem conteúdo dinâmico porém em vários idiomas… Desta forma nosso I18N do Rails vai facilitar muito, poderemos fazer chamadas do Flash para o Rails que irá escrever as informações traduzidas de acordo com a linguagem escolhida.

Vai ficar mais fácil ainda se você estiver usando algo como framework Gaia de Flash(que já falamos aqui) que lê XML por padrão e os utiliza como conteúdo de seus SWF’s. Ai vai facilitar até mesmo em casos onde você esteja usando conteúdo dinâmico no Rails e mapeando os objetos do ActiveRecord para xml através do método to_xml . Também é possível usar o sistema de templates do Rails para gerar XML’s estáticos multi-idioma.

Ainda estou para fazer um tutorial de construção de um site com GAIA e integração de Flash com Rails também. Parece que as agências web ainda não sacaram o poder do Rails para construção de conteúdo Flash e websites com aquele deadline de 3 dias como gostam de trabalhar. Mas este é um assunto que devemos criar um post exclusivo para ele…

Voltando ao I18N… ao mesmo tempo que é muito legal, a forma como é mantido os arquivos de tradução do seu aplicativo/site podem se tornar um inferno. Por padrão o Rails vai ler tudo que estiver na pasta config/locales podendo o arquivo ser um .YML ou .RB (Ruby) . O problema todo é que em ruby acaba virando algo impossível de dar manutenção se você tiver muita coisa traduzida, então recomendo fortemente, nunca usar arquivos de locale em .rb… use sempre em .yml ….

Podemos encontrar uma série de arquivos para usarmos de base para nossos locales neste link de um projeto de Sven Fuchs no github , porém o exemplo de pt-BR do repositóiro é em .rb … então acabei fazendo fork dele e alterando de .rb para .yml … o meu fork você pode encontrar aqui e o arquivo pt-BR.yml estará dentro da pasta rails/locales.

Também aproveitando o post, compartilho abaixo um locale com todos os países do mundo obtidos do link e já convertidos para .yml também. Esta lista de países pode ser usar com o plugin localized-country-select para o rails.

Baixe aqui o locale com todos os países.