Understanding MUIMUI Fundamental Concepts Explained
On this page Prerequisite for MUI Separation of source code from language specific resources Dynamically loading language specific resources Building MUI applications
Prerequisite for MUIThe basic prerequisite for building a MUI-compliant application for Windows Vista and beyond is to design the application in accordance with Windows globalization guidelines .
Separation of source code from language specific resourcesOne of the fundamental premises of MUI technology is the separation of application source code from language-specific resources, to enable multi-lingual scenarios in applications more efficiently. The separation of code and resources has been achieved via different mechanisms and to different degrees over time, as outlined in the following sections. Each method provided varying degrees of flexibility in building, deploying and servicing the application. The recommended solution for MUI-compliant applications is the last method outlined here, namely the physical separation of application source code and resources, with the resources themselves further broken down into one file per supported language for maximum flexibility in building, deploying and servicing.
The early days: code and resources live togetherInitially, localized applications were created by editing the source code and changing the resources (usually strings) in the code itself and recompiling the applications. This meant that to produce a localized version, one had to copy the original source code, translate the text (resources) elements within the source code, and recompile the code.
Figure 3 • Application code contains text that needs to be localized
While this approach enables the creation of localized applications, it also has significant drawbacks:
The combination of these drawbacks makes this an extremely inefficient proposition and a better model was needed.
Logically separating code and localizable resourcesA significant improvement over the preceding model is the logical separation of code and localizable resources for an application. This isolates the code from the resources and ensures that code remains untouched when resources are being changed by localization. From an implementation standpoint, strings and other user interface elements are stored in resource files, which are relatively easy to translate and are logically separated from the code sections. Ideally, adding support for any given language can be as simple as translating the localizable resources into this new language and using these translated resources to create a new localized version of the application—without requiring any code modification.
Figure 4 • Logically separating code and localizable resources
This model enables an easier creation of localized versions of an application and is a significant improvement over the previous model. This model, implemented through the use of resource management tools, has been very successful over the years and is still commonly used by many applications today. However, it does have significant drawbacks:
Figure 5 • Example of a single code defect that requires two patches
It is clear that while this model works well in some scenarios, its limitations for multi-lingual applications and their deployments can be very problematic. A variation of this model that alleviates some of the multi-lingual applications issues is the model where the localizable resources contain a set of different language resources. This model has a common code base and several resources for different languages in the same application. For example, an application can ship with English, German, French, Spanish, Dutch and Italian in the same package.
Figure 6 • Application containing multiple language resources
This model makes it easier to service the application, when a code defect needs to be fixed—which is an improvement—but does not improve over previous models when it comes to supporting additional languages. In this case, one still needs to release a new version of the application (and that release is potentially complicated by the need to ensure that all language resources are synchronized within the same distribution).
Physically separating code and resourcesThe next evolutionary step is to physically separate code and resources. In this model, the resources are abstracted from the code and physically separated in different implementation files. In particular, this means that the code can become truly language independent: the same physical code is actually shipped for all localized versions of an application.
Figure 7 • Physically separating code and localizable resources
This approach has several advantages over the previous approaches:
Dynamically loading language specific resourcesThe MUI fundamental concepts of separating source code from language-specific resources physically and building a language-neutral core binary for an application essentially set up an architecture that is conducive to implementing the dynamic loading of language-specific resources based on user and system language settings. Application source code bundled into the language-neutral core binary can utilize MUI APIs in the Windows platform to abstract the selection of the appropriate display user interface language for a given context. MUI supports this by:
The benefits of dynamically loading user-interface resources with prioritized fallback are that:
Building MUI applicationsThe previous sections outlined the options for separating source code from language-specific resources and the resultant benefit in being able to utilize core Windows platform APIs to dynamically load localized resources. While these are guidelines, it should also be pointed out that there is no specific prescriptive way to develop a MUI application for the Windows platform. Application developers have full choice in how they handle various user-interface language settings, resource creation options, and resource loading methods. Developers can evaluate the guidelines provided in this document and choose a combination that fits their requirements and development environment. The following table summarizes the different design options available to application developers who are looking to create a MUI application for the Windows platform.
|