Conceitos fundamentais da MUI explicados
- Pré-requisito para MUI
- Separação do código-fonte de recursos específicos da linguagem
- Carregar dinamicamente recursos específicos do idioma
- Criando aplicativos MUI
Pré-requisito para MUI
O pré-requisito básico para criar um aplicativo compatível com MUI para Windows Vista e além é projetar o aplicativo de acordo com as diretrizes de globalização do Windows.
Separação do código-fonte de recursos específicos da linguagem
Uma das premissas fundamentais da tecnologia MUI é a separação do código-fonte do aplicativo de recursos específicos da linguagem, para habilitar cenários multilíngues em aplicativos com mais eficiência. A separação de código e recursos foi obtida por meio de diferentes mecanismos e em diferentes graus ao longo do tempo, conforme descrito nas seções a seguir. Cada método forneceu 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 ainda mais em um arquivo por linguagem com suporte para obter máxima flexibilidade na criação, implantação e manutenção.
Os primeiros dias: código e recursos vivem juntos
Inicialmente, os aplicativos localizados foram criados editando o código-fonte e alterando os recursos (geralmente cadeias de caracteres) no próprio código e recompilando os aplicativos. Isso significava que, para produzir uma versão localizada, era preciso 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:
- Ele requer várias versões do código-fonte, pelo menos uma para o idioma de origem e outra para cada um dos idiomas de destino. 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 (uma por idioma).
- Ele 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 dessas desvantagens torna essa uma proposta extremamente ineficiente e um modelo melhor era necessário.
Separando logicamente o código e os 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, cadeias de caracteres e outros elementos de 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 a necessidade de nenhuma modificação de código. A imagem a seguir ilustra como o código e os recursos localizáveis devem ser separados logicamente em um aplicativo.
Esse 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. Esse modelo, implementado por meio do uso de ferramentas de gerenciamento de recursos, tem sido muito bem-sucedido ao longo dos anos e ainda é comumente usado por muitos aplicativos atualmente. No entanto, ele tem desvantagens significativas:
- Embora separados logicamente, o código e os recursos localizados ainda são fisicamente unidos em um arquivo executável. Em particular, a capacidade de serviço ainda é problemática, pois o mesmo defeito de código (idêntico em todas as versões de idioma) requer um patch por idioma. Portanto, se um estiver enviando o aplicativo em 20 idiomas, um patch de serviço precisará ser emitido 20 vezes (uma para cada idioma), mesmo que o código seja corrigido apenas uma vez.
- A distribuição e o uso de aplicativos multilíngues não têm suporte adequado por esse modelo. Isso pode ser um problema significativo em cenários corporativos e OEM. 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 que esse cenário seja 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 desse modelo que alivia alguns dos problemas de aplicativos multilíngues é o modelo em que os recursos localizáveis contêm um conjunto de recursos de linguagem diferentes. Esse modelo tem uma base de código comum e vários recursos para idiomas diferentes 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 o serviç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 dar suporte a idiomas adicionais. Nesse 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 linguagem sejam sincronizados na mesma distribuição).
Separar fisicamente o código e os recursos
A próxima etapa evolutiva é separar fisicamente o código e os recursos. Nesse modelo, os recursos são abstraídos do código e fisicamente separados em arquivos de implementação diferentes. Em particular, isso significa que o código pode se tornar 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.
Essa abordagem tem várias vantagens em relação às abordagens anteriores:
- A implantação de soluções multilíngues é muito simplificada. Adicionar suporte para qualquer idioma específico requer apenas o envio e a instalação de um novo conjunto de recursos de idioma para esse idioma específico. Isso é particularmente importante quando os recursos de linguagem não estão todos disponíveis simultaneamente. Com esse modelo, é possível implantar um aplicativo em um conjunto de linguagens principais e aumentar o número de idiomas com suporte ao longo do tempo sem precisar modificar ou reimplantar o código real. Essa vantagem é ainda mais estendida 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 preferencial "recuem" para outro idioma que os usuários também entendem. 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 imagem única de maneira muito mais eficaz.
- A capacidade de serviço foi aprimorada. Um defeito de código só precisa ser corrigido e implantado uma vez, pois o código é completamente independente de localização. Com esse 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.
Carregar dinamicamente recursos específicos do idioma
Os conceitos fundamentais da MUI de separar fisicamente o código-fonte de recursos específicos da linguagem e criar um binário de núcleo neutro da linguagem para um aplicativo, essencialmente configuram uma arquitetura que é propícia para implementar o carregamento dinâmico de recursos específicos da linguagem com base nas configurações de idioma do usuário e do sistema.
O código-fonte do aplicativo agrupado no binário de núcleo neutro da linguagem 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. A MUI dá suporte a isso:
- Construir uma lista priorizada de idiomas de interface do usuário de exibição com base nas configurações no nível do sistema, do usuário e do aplicativo, no nível do usuário e no nível do sistema.
- Implementar um mecanismo de fallback que escolhe um candidato apropriado nessa 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 preferencial retornarão automaticamente para o próximo idioma na lista priorizada.
- 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 descrevem 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 essas sejam diretrizes, também deve-se ressaltar que não há uma maneira prescritiva específica de desenvolver um aplicativo MUI para a plataforma Windows.
Os desenvolvedores de aplicativos têm a opção completa de como lidam com várias configurações de linguagem de 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 requisitos e ao ambiente de desenvolvimento.
A tabela a seguir resume as diferentes opções de design disponíveis para desenvolvedores de aplicativos que estão procurando criar um aplicativo MUI para a plataforma Windows.
| Configurações de idioma da interface do usuário | Criação de recursos | Carregamento de recursos |
|---|---|---|
| Siga as configurações do idioma da interface do usuário no sistema operacional${REMOVE}$ |
Linguagem única em um binário de recurso dividido (Tecnologia de Recursos MUI) -ou- Vários idiomas em um binário de recurso não dividido |
O aplicativo chama funções de carregamento de recursos padrão. Os recursos são retornados nos idiomas que correspondem às configurações do sistema operacional. |
| Mecanismo de recurso específico do aplicativo |
O aplicativo chama a API mui para recuperar os idiomas de interface do usuário preferidos por thread ou idiomas de interface do usuário preferenciais do processo do sistema operacional e usar essas configurações para carregar seus próprios recursos. |
|
| Configurações de idioma da interface do usuário específicas do aplicativo${REMOVE}$ |
Idioma único em um binário de recurso dividido -ou- Vários idiomas em um binário de recurso não dividido |
O aplicativo chama a API mui para definir idiomas de interface do usuário específicos do aplicativo ou idiomas de interface do usuário preferenciais do processo e, em seguida, chama funções de carregamento de recursos padrão. Os recursos são retornados nos idiomas definidos pelos idiomas do aplicativo ou do sistema. -ou- O aplicativo investiga recursos em um idioma específico e manipula sua própria extração de recursos dos dados binários recuperados. |
| Mecanismo de recurso específico do aplicativo |
O aplicativo gerencia seu próprio carregamento de recursos. |