Conforme expliquei no artigo anterior, teremos suporte a I18n no Ruby on Rails a partir da próxima versão. E eu prometi escrever um artigo mostrando como funcionaria esta nova implementação, o problema é que demorei e já teve gente se adiantando…

Então só vou mostrar o caminho das pedras.

Antes de começar

Preciso deixar claro uma coisa. Quando estamos falando de internacionalização, ao usar as palavras “localização” e “localizar”, não quero que vocês as entendam como sinônimos de encontrar, achar, etc…

Quando nos referimos a “localização” ou “localizar” estamos falando de L10n. Eu já falei sobre isto no último artigo.

Como funcionará

O alicerce desta implementação é um módulo chamado I18n que vem através de um gem incorporado ao ActiveSupport. Este módulo acrescenta as seguintes funcionalidades ao Rails:

O método translate, que será usado para retornar traduções.

O método localize, que usaremos para “traduzir” objetos Date, DateTime e Time para a localização atual.

Além destes métodos este módulo traz todo o código necessário para armazenar e carregar os backends de “localização”. E já vem com um manipulador de exceções padrão que captura exceções levantadas no backend.

Tanto o backend como o manipulador de exceções podem (devem) ser substituídos. Além disso para facilitar, os métodos #translate e #localize também poderão ser executados usando os métodos #t e #l respectivamente.

Nem tudo está pronto ainda, na verdade muito coisa ainda precisa ser feita e definida por isto é um pouco cedo para dizer com precisão como tudo vai se encaixar no Rails.

Exemplos práticos

Eu encontrei este artigo escrito pelo Diego Carrion que explica um pouco sobre como colocar o translate para funcionar, e para quem quer ver isto na prática Trevor Turk (do El Dorado) criou no GitHub um projeto Rails do zero com este código que o Diego menciona no seu blog.

Assim que as coisas estiverem mais concretas, eu volto a falar mais sobre isto.