Conceptos básicos de MUI explicados
- Requisito previo para MUI
- Separación del código fuente de los recursos específicos del lenguaje
- Carga dinámica de recursos específicos del lenguaje
- Creación de aplicaciones MUI
Requisito previo para MUI
El requisito previo básico para compilar una aplicación compatible con MUI para Windows Vista y versiones posteriores es diseñar la aplicación de acuerdo con las directrices de globalización de Windows.
Separación del código fuente de los recursos específicos del lenguaje
Una de las instalaciones fundamentales de la tecnología MUI es la separación del código fuente de la aplicación de los recursos específicos del lenguaje, para habilitar escenarios multilingües en aplicaciones de forma más eficaz. La separación del código y los recursos se ha logrado a través de diferentes mecanismos y en distintos grados a lo largo del tiempo, como se describe en las secciones siguientes. Cada método proporcionó distintos grados de flexibilidad en la creación, implementación y mantenimiento de la aplicación.
La solución recomendada para aplicaciones compatibles con MUI es el último método que se describe aquí, es decir, la separación física del código fuente y los recursos de la aplicación, con los propios recursos desglosados en un archivo por idioma admitido para obtener la máxima flexibilidad en la creación, implementación y mantenimiento.
Los primeros días: el código y los recursos residen juntos
Inicialmente, las aplicaciones localizadas se crearon editando el código fuente y cambiando los recursos (normalmente cadenas) en el propio código y recompilando las aplicaciones. Esto significaba que para generar una versión localizada, tenía que copiar el código fuente original, traducir los elementos de texto (recursos) dentro del código fuente y volver a compilar el código. En la imagen siguiente se muestra el código de aplicación con texto que debe localizarse.
Aunque este enfoque permite la creación de aplicaciones localizadas, también tiene importantes inconvenientes:
- Requiere varias versiones del código fuente, al menos una para el idioma de origen y otra para cada uno de los idiomas de destino. Esto crea problemas significativos que sincronizan las distintas versiones de idioma de la aplicación. En concreto, cuando se debe corregir un defecto en el código, el defecto debe corregirse en cada copia del código fuente (uno por idioma).
- También es extremadamente propenso a errores, ya que requiere localizadores (que no son desarrolladores) para realizar modificaciones en el código fuente, lo que crea un riesgo considerable en términos de integridad de código.
La combinación de estos inconvenientes hace que esta propuesta sea extremadamente ineficaz y se necesita un modelo mejor.
Separación lógica de código y recursos localizables
Una mejora significativa del modelo anterior es la separación lógica de código y recursos localizables para una aplicación. Esto aísla el código de los recursos y garantiza que el código permanece intacto cuando la localización cambia los recursos. Desde el punto de vista de la implementación, las cadenas y otros elementos de la interfaz de usuario se almacenan en archivos de recursos, que son relativamente fáciles de traducir y se separan lógicamente de las secciones de código.
Idealmente, agregar compatibilidad con cualquier idioma determinado puede ser tan sencillo como traducir los recursos localizables a este nuevo idioma y usar estos recursos traducidos para crear una nueva versión localizada de la aplicación, sin necesidad de ninguna modificación de código. En la imagen siguiente se muestra cómo el código y los recursos localizables deben estar separados lógicamente dentro de una aplicación.
Este modelo permite una creación más sencilla de versiones localizadas de una aplicación y es una mejora significativa del modelo anterior. Este modelo, implementado a través del uso de herramientas de administración de recursos, ha sido muy exitoso a lo largo de los años y sigue siendo utilizado por muchas aplicaciones hoy en día. Sin embargo, tiene importantes inconvenientes:
- Aunque los recursos localizados y de código separados lógicamente siguen unidos físicamente en un archivo ejecutable. En concreto, la capacidad de servicio sigue siendo problemática, ya que el mismo defecto de código (idéntico en todas las versiones de lenguaje) requiere una revisión por idioma. Por lo tanto, si se envía la aplicación en 20 idiomas, se debe emitir una revisión de servicio 20 veces (una para cada idioma), aunque el código solo se corrigió una vez.
- Este modelo no admite adecuadamente la distribución y el uso de aplicaciones multilingües. Esto puede ser un problema significativo en escenarios oem y empresariales. Por ejemplo, si un equipo se va a compartir entre dos usuarios que usan distintos idiomas, las aplicaciones deberán instalarse dos veces con este modelo y, a continuación, algún mecanismo deberá habilitarse para alternar entre las dos instalaciones. Esto supone que no hay dependencias adicionales que impidan que incluso este escenario se implemente. En la imagen siguiente se muestra un ejemplo de un único defecto de código que requiere dos revisiones.
Es evidente que, aunque este modelo funciona bien en algunos escenarios, sus limitaciones para las aplicaciones multilingües y sus implementaciones pueden ser muy problemáticas.
Una variación de este modelo que alivia algunos de los problemas de las aplicaciones multilingües es el modelo en el que los recursos localizables contienen un conjunto de recursos de lenguaje diferentes. Este modelo tiene una base de código común y varios recursos para distintos lenguajes en la misma aplicación. Por ejemplo, una aplicación puede enviarse con inglés, alemán, francés, español, holandés e italiano en el mismo paquete. En la imagen siguiente se muestra una aplicación que contiene varios recursos de lenguaje.
Este modelo facilita el servicio de la aplicación cuando es necesario corregir un defecto de código ( que es una mejora), pero no mejora con respecto a los modelos anteriores cuando se trata de admitir lenguajes adicionales. En este caso, todavía es necesario liberar una nueva versión de la aplicación (y esa versión es potencialmente complicada por la necesidad de asegurarse de que todos los recursos de lenguaje se sincronizan dentro de la misma distribución).
Separación física de código y recursos
El siguiente paso evolucionista es separar físicamente el código y los recursos. En este modelo, los recursos se abstraen del código y se separan físicamente en diferentes archivos de implementación. En particular, esto significa que el código puede convertirse en verdaderamente independiente del lenguaje; el mismo código físico se envía realmente para todas las versiones localizadas de una aplicación. En la imagen siguiente se muestra que el código y los recursos localizables deben estar separados físicamente.
Este enfoque tiene varias ventajas sobre los enfoques anteriores:
- La implementación de soluciones multilingües se simplifica considerablemente. Agregar compatibilidad con cualquier idioma determinado solo requiere el envío e instalación de un nuevo conjunto de recursos de idioma para este idioma determinado. Esto es especialmente importante cuando los recursos de idioma no están disponibles simultáneamente. Con este modelo, se puede implementar una aplicación en un conjunto de lenguajes principales y aumentar el número de idiomas admitidos a lo largo del tiempo sin tener que modificar o volver a implementar el código real. Esta ventaja se amplía aún más mediante un mecanismo de reserva que permite la localización parcial de aplicaciones y componentes del sistema en un idioma determinado al garantizar que los recursos que no se encuentran en este idioma preferido "retroceda" a otro idioma que los usuarios también comprendan. En general, este modelo ayuda a aliviar la considerable carga a la que se enfrentan las empresas globales en la implementación de aplicaciones en varios lenguajes, ya que permite la implementación de imágenes únicas de una manera mucho más eficaz.
- Se ha mejorado la capacidad de servicio. Un defecto de código solo debe corregirse e implementarse una vez, ya que el código es completamente independiente de la localización. Con este modelo, la emisión de una corrección para un defecto de código, siempre que el cambio no esté relacionado con la interfaz de usuario, es mucho más sencillo y rentable que en cualquiera de los modelos anteriores.
Carga dinámica de recursos específicos del lenguaje
Los conceptos fundamentales de MUI de separar físicamente el código fuente de los recursos específicos del lenguaje y crear un binario principal independiente del lenguaje para una aplicación, básicamente configuran una arquitectura que resulta favorable a implementar la carga dinámica de recursos específicos del lenguaje en función de la configuración de idioma y del sistema.
El código fuente de la aplicación agrupado en el binario principal neutro del lenguaje puede usar LAS API de MUI en la plataforma Windows para abstraer la selección del lenguaje de interfaz de usuario de visualización adecuado para un contexto determinado. MUI lo admite:
- Construir una lista prioritaria de idiomas de interfaz de usuario para mostrar en función de la configuración de sistema, usuario y aplicación, nivel de usuario y nivel de sistema.
- Implementar un mecanismo de reserva que elija un candidato adecuado de esta lista prioritaria de idiomas, en función de la disponibilidad de los recursos localizados.
Las ventajas de cargar dinámicamente los recursos de la interfaz de usuario con reserva prioritaria son:
- Permite la localización parcial de aplicaciones y componentes del sistema en un idioma determinado, ya que los recursos que no se encuentran en este idioma preferido se revertirán automáticamente al siguiente idioma en la lista prioritaria.
- Permite escenarios como cambiar dinámicamente de un idioma a otro.
- Permite crear imágenes de implementación únicas regionales o mundiales que cubren un conjunto de lenguajes para oem y empresas.
Creación de aplicaciones MUI
En las secciones anteriores se describen las opciones para separar el código fuente de los recursos específicos del lenguaje y la ventaja resultante de poder usar las API principales de la plataforma Windows para cargar dinámicamente los recursos localizados. Aunque estas son directrices, también debe señalarse que no hay ninguna manera prescriptiva específica de desarrollar una aplicación MUI para la plataforma Windows.
Los desarrolladores de aplicaciones tienen la opción completa de cómo controlan varias opciones de idioma de interfaz de usuario, opciones de creación de recursos y métodos de carga de recursos. Los desarrolladores pueden evaluar las directrices proporcionadas en este documento y elegir una combinación que se ajuste a sus requisitos y entorno de desarrollo.
En la tabla siguiente se resumen las diferentes opciones de diseño disponibles para los desarrolladores de aplicaciones que buscan crear una aplicación MUI para la plataforma Windows.
| Configuración del idioma de la interfaz de usuario | Creación de recursos | Carga de recursos |
|---|---|---|
| Siga la configuración del idioma de la interfaz de usuario en el sistema operativo${REMOVE}$ |
Idioma único en un binario de recursos divididos (tecnología de recursos MUI) O bien Varios lenguajes en un binario de recursos no divididos |
La aplicación llama a las funciones de carga de recursos estándar. Los recursos se devuelven en los idiomas que coinciden con la configuración del sistema operativo. |
| Mecanismo de recursos específico de la aplicación |
La aplicación llama a la API MUI para recuperar los idiomas de interfaz de usuario preferidos por subprocesos o los idiomas de interfaz de usuario preferidos por el proceso del sistema operativo y usar esta configuración para cargar sus propios recursos. |
|
| Configuración del idioma de la interfaz de usuario específica de la aplicación${REMOVE}$ |
Idioma único en un binario de recursos divididos O bien Varios lenguajes en un binario de recursos no divididos |
La aplicación llama a la API de MUI para establecer lenguajes de interfaz de usuario específicos de la aplicación o lenguajes de interfaz de usuario preferidos por el proceso y, a continuación, llama a las funciones de carga de recursos estándar. Los recursos se devuelven en los idiomas establecidos por la aplicación o los idiomas del sistema. O bien La aplicación sondea los recursos en un idioma específico y controla su propia extracción de recursos de los datos binarios recuperados. |
| Mecanismo de recursos específico de la aplicación |
La aplicación administra su propia carga de recursos. |