Globalização

Diz-se que um aplicativo que pode apresentar informações a usuários de acordo com convenções culturais regionais é globalizado: O aplicativo pode ser configurado para interagir com usuários de diferentes localidades de maneiras culturalmente apropriadas. Em um aplicativo globalizado, um usuário em uma região vê mensagens de erro, saída e elementos de interface no idioma solicitado. Os formatos de data e hora, bem como moedas, são apresentados da maneira apropriada para usuários da região especificada. Um usuário de outro país verá a saída no idioma ou formato convencionais desse país. A globalização consiste em duas fases: internacionalização (ativando um componente de aplicativo para suporte multicultural) e localização (convertendo e implementando uma convenção regional específica).

Historicamente, a criação de aplicativos globalizados tem sido restrita a grandes empresas, que desenvolvem sistemas complexos. Entretanto, dado o crescimento da computação distribuída e do uso da World Wide Web, os desenvolvedores de aplicativos são pressionados a globalizar uma variedade muito maior de aplicativos. Essa tendência exige que as técnicas de globalização sejam muito mais acessíveis aos desenvolvedores de aplicativos.

A internacionalização de um aplicativo é orientada por duas variáveis, o fuso horário e o locale. O fuso horário indica como computar a hora local como um deslocamento de um horário padrão como a Hora de Greenwich. O código do idioma é uma coleta de informações sobre idioma, moeda e as convenções para apresentar informações como datas. Um fuso horário pode abranger muitos locales, e um único locale pode ter vários fusos horários. Com o fuso horário e o locale, a data, a hora, a moeda e o idioma para os usuários em uma região específica podem ser determinados.

Por convenção, um determinado código de idioma é especificado com um par de códigos (para idioma e região) administrados por padrões diferentes. O padrão ISO-639 administra o código do idioma; o padrão ISO-3166 administra o código regional. Na escrita, os dois códigos são normalmente unidos por um caractere de sublinhado (_), por exemplo, en_US para inglês dos Estados Unidos. No código Java™, os códigos do idioma são definidos e recuperados por meio da classe java.util.Locale.

Uma Primeira Etapa: Localização das Cadeias de Interface

Em um aplicativo não globalizado, a interface com o usuário é gravada inalteravelmente no código do aplicativo. A internacionalização de uma interface com o usuário inclui uma camada de abstração no design de um aplicativo. A camada adicional de abstração permite localizar o aplicativo para cada código do idioma que deve ser suportado pelo aplicativo.

Em um aplicativo localizado, o código do idioma determina o catálogo de mensagens do qual o aplicativo recupera cadeias de mensagens. Em vez de imprimir uma mensagem de erro, o aplicativo representa a mensagem de erro com algumas informações de linguagem neutra; no caso mais simples, cada condição de erro corresponde a uma chave. Para imprimir uma mensagem de erro utilizável, o aplicativo procura a chave em um catálogo de mensagens. Cada catálogo de mensagens é uma lista de chaves com cadeias associadas. Diferentes catálogos de mensagens fornecem cadeias para os diferentes idiomas suportados. O aplicativo procura a chave no catálogo apropriado, recupera a mensagem de erro correspondente no idioma pedido e imprime a cadeia para o usuário.

A localização de texto pode ser utilizada para muito mais do que traduzir mensagens de erro. Por exemplo, utilizando chaves para representar cada elemento em uma GUI (Interface Gráfica com o Usuário) e fornecendo os catálogos de mensagens apropriados, a GUI (botões, menus, etc.) pode suportar vários idiomas. Estender o suporte para idiomas adicionais exige que sejam fornecidos catálogos de mensagens para esses idiomas; em muitos casos, o aplicativo não necessita de modificações adicionais.

O localizable-text package é um conjunto de classes e interfaces Java que podem ser utilizadas para localizar facilmente as cadeias em aplicativos distribuídos. Catálogos de mensagens específicos de idiomas podem ser armazenados centralmente para que possam ser mantidos eficientemente.

Desafios de Globalização em Aplicativos Distribuídos

Com o advento de modelos computacionais de negócios baseados na Internet, os aplicativos consistem crescentemente em clientes e servidores que operam em diferentes regiões geográficas. Essas diferenças apresentam os seguintes desafios para a tarefa de projetar uma infra-estrutura sólida de cliente-servidor:

Os clientes e servidores podem ser executados em computadores que possuem arquiteturas endian ou conjuntos de códigos diferentes

Os clientes e os servidores podem residir em computadores que possuem arquiteturas endian diferentes: um cliente pode residir em uma CPU little-endian, enquanto o código do servidor é executado em uma big-endian. Um cliente pode desejar chamar um método de negócios em um servidor executando um conjunto de códigos diferente do que o do cliente.

Uma infra-estrutura de cliente-servidor deve definir regras exatas de conversão e monitoração do conjunto de códigos e de endian. A plataforma Java quase eliminou esses problemas de maneira exclusiva, contando com sua JVM (Java virtual machine), que codifica todos os dados de cadeia no formato UCS-2 e externaliza tudo no formato big-endian. A JVM utiliza um conjunto de programas específicos da plataforma para fazer interface com a plataforma nativa. Esses programas executam quaisquer conversões necessárias do conjunto de códigos entre o UCS-2 e o conjunto nativo de códigos de uma plataforma.

Os clientes e servidores podem ser executados em computadores com configurações de código do idioma diferentes

Os processos de cliente e de servidor podem usar configurações de código do idioma diferentes. Por exemplo, um cliente espanhol pode chamar um método de negócios para um objeto que reside em um servidor para inglês dos Estados Unidos. Alguns métodos de negócios fazem distinção de códigos de idioma por natureza; por exemplo, fornecido um método de negócios que retorna uma lista classificada de cadeias, o cliente espanhol espera que a lista seja classificada de acordo com a sequência intercalada do espanhol, não na sequência intercalada do inglês do servidor. Como os procedimentos de recuperação e classificação de dados são executados no servidor, o código do idioma do cliente deve estar disponível para executar uma classificação legítima.

Uma consideração similar aplica-se em instâncias em que o servidor tem que retornar cadeias contendo mensagens de data, hora, moeda e exceção, e assim por diante, formatadas de acordo com as expectativas culturais do cliente.

Os clientes e os servidores podem residir em diferentes fusos horários

Os processos de cliente e de servidor podem ser executados em fuso horários diferentes. Até o momento, toda a literatura e os recursos de internacionalização concentram-se principalmente em questões relacionadas ao conjunto de códigos e locale. O problema de fuso horário tem geralmente sido ignorado, mesmo que os métodos de negócios possa ser sensíveis ao fuso horário e ao locale.

Por exemplo, suponhamos que um fornecedor informe que os pedidos recebidos antes das 14:00 h são processados até as 17:00 h do mesmo dia. Os horários fixados, é claro, estão no fuso horário do servidor que está processando o pedido. É importante saber o fuso horário do cliente para fornecer aos clientes em outros fusos horários os horários corretos para os processos no mesmo dia.

Outras operações sensíveis ao fuso horário incluem data e hora de mensagens registradas em um servidor e o acesso a recursos de arquivos ou de bancos de dados. O conceito de horário de verão complica a questão de fuso horário.

Java Platform, Enterprise Edition (Java EE) fornece suporte para componentes de aplicativo que são executados em computadores com conjuntos de código e arquitetura endian diferentes. Ele não fornece suporte dedicado para componentes de aplicativo executados em computadores com diferentes códigos do idioma ou fusos horários.

O método convencional para resolver a incompatibilidade de códigos do idioma e fusos horários nos componentes de aplicativos remotos é transmitir um ou mais parâmetros extras em todos os métodos de negócios necessários para transportar o código do idioma ou fuso horário do lado do cliente para o servidor. Embora simples, essa técnica tem as seguintes limitações quando utilizada em aplicativos EJB (Enterprise JavaBeans):
  • É intrusiva porque requer que um ou mais parâmetros sejam adicionados a todos os métodos de beans na cadeia de chamadas para métodos sensíveis a locales e fusos horários.
  • É inerentemente propensa a erros.
  • É impraticável em aplicativos que não suportam modificação, tais como, aplicativos legados.

O serviço de internacionalização trata dos desafios apresentados pela incompatibilidade de códigos do idioma e fusos horários sem incorrer nas limitações de técnicas convencionais. O serviço gerencia sistematicamente a distribuição de contextos de internacionalização nos diversos componentes de aplicativos EJB, incluindo aplicativos clientes, enterprise beans e servlets.Para obter mais informações, consulte Visão Geral da Tarefa: Internacionalizando Componentes de Aplicativo (Serviço de Internacionalização).


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cin_main
Nome do arquivo: cin_main.html