MUI Conceitos Fundamentais Explicados

• Pré-requisito para MUI
• Separação do código-fonte dos recursos específicos da linguagem
  • Os primórdios: código e recursos convivem
  • Separar logicamente o código e os recursos localizáveis
  • Separar fisicamente o código e os recursos
• Carregando dinamicamente recursos específicos do idioma
• Construindo aplicativos MUI

Prérequisito para MUI

O pré-requisito básico para criar um aplicativo compatível com MUI para o Windows Vista e além é projetar o aplicativo de acordo com as diretrizes de globalização do Windows .

Separação do código-fonte dos recursos específicos da língua

Uma das premissas fundamentais da tecnologia MUI é a separação do código-fonte do aplicativo dos recursos específicos do idioma, para permitir cenários multilíngues em aplicativos de forma mais eficiente. A separação entre o código e os recursos foi conseguida através de diferentes mecanismos e em diferentes graus ao longo do tempo, tal como descrito nas secções seguintes. Cada método fornecia diferentes graus de flexibilidade na criação, implantação e manutenção do aplicativo.

A solução recomendada para aplicativos compatíveis com MUI é o último método descrito aqui, ou seja, a separação física do código-fonte e dos recursos do aplicativo, com os próprios recursos divididos em um arquivo por idioma suportado para máxima flexibilidade na criação, implantação e manutenção.

Os primórdios: código e recursos convivem

Inicialmente, os aplicativos localizados eram criados editando o código-fonte e alterando os recursos (geralmente strings) no próprio código e recompilando os aplicativos. Isso significava que, para produzir uma versão localizada, era necessário copiar o código-fonte original, traduzir os elementos de texto (recursos) dentro do código-fonte e recompilar o código. A imagem a seguir mostra o código do aplicativo com texto que precisa ser localizado.

Embora essa abordagem permita a criação de aplicativos localizados, ela também tem desvantagens significativas:

• Requer várias versões do código-fonte, pelo menos uma para a língua de partida e uma para cada uma das línguas de chegada. Isso cria problemas significativos ao sincronizar as diferentes versões de idioma do aplicativo. Em particular, quando um defeito precisa ser corrigido no código, o defeito precisa ser corrigido em cada cópia do código-fonte (um por idioma).
• Também é extremamente propenso a erros, pois exigia que os localizadores — que não são desenvolvedores — fizessem modificações no código-fonte, criando assim um risco considerável em termos de integridade do código.

A combinação destes inconvenientes torna esta proposta extremamente ineficiente, sendo necessário um modelo melhor.

Separando logicamente código e recursos localizáveis

Uma melhoria significativa em relação ao modelo anterior é a separação lógica de código e recursos localizáveis para um aplicativo. Isso isola o código dos recursos e garante que o código permaneça intocado quando os recursos estão sendo alterados pela localização. Do ponto de vista da implementação, as cadeias de caracteres e outros elementos da interface do usuário são armazenados em arquivos de recursos, que são relativamente fáceis de traduzir e são logicamente separados das seções de código.

Idealmente, adicionar suporte para qualquer idioma pode ser tão simples quanto traduzir os recursos localizáveis para esse novo idioma e usar esses recursos traduzidos para criar uma nova versão localizada do aplicativo, sem exigir qualquer modificação de código. A imagem a seguir ilustra como o código e os recursos localizáveis devem ser logicamente separados dentro de um aplicativo.

Este modelo permite uma criação mais fácil de versões localizadas de um aplicativo e é uma melhoria significativa em relação ao modelo anterior. Este modelo, implementado através do uso de ferramentas de gestão de recursos, tem sido muito bem sucedido ao longo dos anos e ainda é comumente usado por muitas aplicações hoje. No entanto, tem desvantagens significativas:

• Embora logicamente separados, o código e os recursos localizados ainda estão fisicamente unidos em um arquivo executável. Em particular, a facilidade de manutenção ainda é problemática, pois o mesmo defeito de código (idêntico em todas as versões linguísticas) requer um patch por idioma. Portanto, se um estiver enviando o aplicativo em 20 idiomas, um patch de serviço precisa ser emitido 20 vezes (um para cada idioma), mesmo que o código seja corrigido apenas uma vez.
• A distribuição e a utilização de aplicações multilingues não são adequadamente suportadas por este modelo. Isso pode ser um problema significativo em cenários OEM e empresariais. Por exemplo, se um computador deve ser compartilhado entre dois usuários usando idiomas diferentes, os aplicativos precisarão ser instalados duas vezes com esse modelo e, em seguida, algum mecanismo precisará ser habilitado para alternar entre as duas instalações. Isso pressupõe que não haja dependências adicionais que impeçam até mesmo esse cenário de ser implementado. A imagem a seguir mostra um exemplo de um único defeito de código que requer dois patches.

É claro que, embora esse modelo funcione bem em alguns cenários, suas limitações para aplicativos multilíngues e suas implantações podem ser muito problemáticas.

Uma variação deste modelo que alivia alguns dos problemas de aplicações multilingues é o modelo em que os recursos localizáveis contêm um conjunto de recursos linguísticos diferentes. Este modelo tem uma base de código comum e vários recursos para diferentes idiomas no mesmo aplicativo. Por exemplo, um aplicativo pode ser enviado com inglês, alemão, francês, espanhol, holandês e italiano no mesmo pacote. A imagem a seguir mostra um aplicativo que contém vários recursos de idioma.

Esse modelo facilita a manutenção do aplicativo quando um defeito de código precisa ser corrigido, o que é uma melhoria, mas não melhora em relação aos modelos anteriores quando se trata de oferecer suporte a idiomas adicionais. Neste caso, ainda é necessário lançar uma nova versão do aplicativo (e essa versão é potencialmente complicada pela necessidade de garantir que todos os recursos de idioma sejam sincronizados dentro da mesma distribuição).

Separando fisicamente código e recursos

O próximo passo evolutivo é separar fisicamente o código e os recursos. Neste modelo, os recursos são abstraídos do código e separados fisicamente em diferentes arquivos de implementação. Em particular, isto significa que o código pode tornar-se verdadeiramente independente da linguagem; O mesmo código físico é realmente enviado para todas as versões localizadas de um aplicativo. A imagem a seguir ilustra que o código e os recursos localizáveis devem ser fisicamente separados.

Esta abordagem tem várias vantagens em relação às abordagens anteriores:

• A implantação de soluções multilingues é muito simplificada. Adicionar suporte para qualquer idioma requer apenas o envio e a instalação de um novo conjunto de recursos de idioma para esse idioma específico. Isto é particularmente importante quando os recursos linguísticos não estão todos disponíveis simultaneamente. Com esse modelo, pode-se implantar um aplicativo em um conjunto de linguagens principais e aumentar o número de idiomas suportados ao longo do tempo sem ter que modificar ou reimplantar o código real. Essa vantagem é ampliada por um mecanismo de fallback que permite a localização parcial de aplicativos e componentes do sistema em um determinado idioma, garantindo que os recursos que não são encontrados nesse idioma preferido "retornem" para outro idioma que os usuários também entendam. No geral, esse modelo ajuda a aliviar a carga considerável que as empresas globais enfrentam na implantação de aplicativos em vários idiomas, pois permite a implantação de uma única imagem de forma muito mais eficaz.
• A facilidade de manutenção é melhorada. Um defeito de código só precisa ser corrigido e implantado uma vez, pois o código é completamente independente de localização. Com este modelo, emitir uma correção para um defeito de código, desde que a alteração não esteja relacionada à interface do usuário, é muito mais simples e econômico do que em qualquer um dos modelos anteriores.

Carregamento dinâmico de recursos específicos do idioma

Os conceitos fundamentais do MUI de separar fisicamente o código-fonte dos recursos específicos do idiomae construir um binário central neutro em termos de língua, essencialmente configuram uma arquitetura propícia para implementar o carregamento dinâmico de recursos linguísticos com base nas configurações de idioma do usuário e do sistema para um aplicativo.

O código-fonte do aplicativo empacotado no binário principal com neutralidade de idioma pode utilizar APIs MUI na plataforma Windows para abstrair a seleção da linguagem de interface do usuário de exibição apropriada para um determinado contexto. MUI suporta isso por:

• Construção de uma lista priorizada de idiomas de interface do usuário de exibição com base em configurações de sistema, usuário e aplicativo, nível de usuário e nível de sistema.
• Implementar um mecanismo de fallback que escolha um candidato apropriado a partir dessa lista priorizada de idiomas, com base na disponibilidade de recursos localizados.

Os benefícios de carregar dinamicamente recursos de interface do usuário com fallback priorizado são:

• Ele permite a localização parcial de aplicativos e componentes do sistema em um determinado idioma, pois os recursos que não são encontrados nesse idioma preferido voltarão automaticamente para o próximo idioma na lista de prioridades.
• Ele permite cenários como alternar dinamicamente de um idioma para outro.
• Ele permite a criação de imagens de implantação única regionais ou mundiais que abrangem um conjunto de idiomas para OEMs e empresas.

Criando aplicativos MUI

As seções anteriores descreveram as opções para separar o código-fonte de recursos específicos do idioma e o benefício resultante em poder utilizar as APIs principais da plataforma Windows para carregar dinamicamente recursos localizados. Embora estas sejam diretrizes, também deve ser apontado que não há uma maneira prescritiva específica de desenvolver um aplicativo MUI para a plataforma Windows.

Os desenvolvedores de aplicativos têm total escolha em como lidar com várias configurações de idioma da interface do usuário, opções de criação de recursos e métodos de carregamento de recursos. Os desenvolvedores podem avaliar as diretrizes fornecidas neste documento e escolher uma combinação que atenda aos seus requisitos e ambiente de desenvolvimento.

A tabela a seguir resume as diferentes opções de design disponíveis para desenvolvedores de aplicativos que desejam criar um aplicativo MUI para a plataforma Windows.