Revisitando Internacionalização – Parte 1

Algumas aplicações devem servir clientes que se situam em regiões ou países diferentes. Como consequência é esperado que nem todos os usuários sejam capazes de compreender o conteúdo apresentado, a menos que o mesmo seja exibido em sua forma nativa, tanto na escrita como na utilização de símbolos. Na maioria dos países de cultura ocidental, por exemplo, é comum utilizar o símbolo √ para representar que algo está correto, porém no Japão o mesmo quer dizer justamente o oposto.

Internacionalização (I18N) e localização (L10N) são técnicas utilizadas nessas situações, nas quais uma aplicação deve ser desenvolvida para dar suporte a mais de um idioma e/ou região. A fusão desses termos é conhecida como globalização. Embora sejam eventualmente confundidos, a rigor, I18N refere-se ao mecanismo utilizado para tornar possível a L10N. No coração da L10N está a funcionalidade de se apresentar texto traduzido para determinados idiomas, porém o escopo geral da L10N pode ser muito maior, por ventura demandando a especialização de recursos como imagens, arquivos CSS, entre outros, visando prover um sistema ou serviço que possa ser consumido de forma “nativa” por clientes de diferentes regiões. Por exemplo, se uma aplicação contém um componente do tipo Calendário que destaca feriados, além da tradução dos nomes dos meses e dias da semana, será necessário também especializar a lógica demarcadora de feriados para cada região suportada.

A maioria dos frameworks web para a plataforma Java provê suporte à I18N em diversos níveis. Alguns se preocupam apenas com a parte da localização de mensagens traduzidas e outros, como o Apache Wicket, fornecem também um mecanismo para a inclusão de outros recursos como arquivos JavaScript, CSS e imagens de acordo com a instância de java.util.Locale utilizada pelo cliente (navegador).

Em uma arquitetura em camadas, onde a camada de negócio é desacoplada da camada de apresentação, uma aplicação tende a utilizar diferentes modelos de I18N, empregando os mecanismos suportados pelo framework adotado na camada de apresentação e outros na camada de negócio.

Consideremos como exemplo o seguinte cenário: existe um formulário para o cadastro de um cliente que valida alguns dados como e-mail, nome e idade, exibindo mensagens de erro caso sejam submetidos dados com valores inválidos. Ao mesmo tempo existe um serviço de cadastro de clientes em lote, o qual é realizado através da importação de arquivos TXT. Este processo é realizado de forma assíncrona (e.g. como um batch) e além da inclusão dos registros, o mesmo também deve gerar um arquivo de log com um sumário (total de registros, mensagens de erro de formato – como limite do número de caracteres excedido para o nome ou máscara de e-mail inválida – para cada linha, etc.) para posterior consulta.

A geração deste log pode estar condicionada ao idioma do cliente que submeteu o arquivo para importação e o escopo de mensagens a serem apresentadas é similar ao do cadastro unitário, ou seja, idealmente ambos os componentes (apresentação e negócio) devem ter acesso ao mesmo conjunto de dados para prover feedback ao usuário. Porém, qual seria a forma ideal de compartilhar estas mensagens entre a apresentação e o negócio? Estratégias típicas de I18N para a camada de apresentação podem envolver taglibs (JSPs), referências a ResourceBundles em faces-config.xml (JSF), StringResourceModels (Wicket), etc. Já a camada de negócio pode, por exemplo, empregar MessageSources (Spring).

Independentemente dos frameworks utilizados, deve-se pensar em um mecanismo que possibilite o compartilhamento deste conteúdo de I18N entre essas camadas. E mesmo quando bem compartilhado, qual a melhor maneira de se reconhecer que uma mensagem está associada a um contexto específico? À medida que um projeto cresce, se estas questões não forem levantadas, a lógica de internacionalização poderá ficar fragmentada entre as camadas, fazendo com que o escopo de mensagens não seja transparente, dificultando a manutenção tanto do código quanto do conteúdo de I18N.

A maioria dos frameworks aborda I18N, no contexto da resolução de Strings para Locales específicos, através de estruturas de dados do tipo dicionário (Maps e ResourceBundles), ou seja, o código tende a ficar poluído com expressões do tipo map.get(“chave.para.algum.contexto”). Embora aceitável para um número pequeno de mensagens, esta técnica tende a degradar a expressividade do código que a utiliza na medida em que o número de chaves se multiplica. Para lidar com este tipo de situação, o framework GWT introduziu uma nova abordagem: Contêineres de mensagens. A ideia fundamental consiste em definir quais mensagens serão utilizadas em um determinado escopo e utilizar interfaces para representá-las, de tal forma que as mesmas possam ser obtidas através de invocações de métodos, caracterizando um mecanismo expressivo, type-safe.

Neste artigo, vamos apresentar uma solução simples para lidar com mensagens, similar à utilizada no GWT, que pode ser incorporada em qualquer framework e empregada em qualquer camada da aplicação. Inicialmente vamos expor como criar esse mecanismo, e ao longo do artigo mostraremos um exemplo de como utilizá-lo via injeção de dependências num ambiente de CDI e JSF 2, além de entrar em detalhes técnicos como Serialização, que podem ser relevantes dependendo do ambiente de publicação e do ponto de vista não-funcional de uma aplicação.

Criando contêineres de mensagens

Para trabalhar de forma segura com internacionalização, vamos adotar a seguinte prática: dado um conjunto de dados que necessitem de tradução para determinados Locales, criaremos uma interface para representá-los. A ideia é utilizar esta interface para substituir as chamadas a um ResourceBundle ou Map em um determinado escopo, por exemplo, em um backing bean ou tela. Por exemplo, se o escopo possuir dois pontos de I18N, um label e um texto para cumprimentar o usuário, esses dois pontos podem ser representados como métodos de uma interface conforme a Listagem 1, isto é, ao invés de utilizar myResourceBundle.get('labelName') ...