Events
Nov 19, 11 PM - Nov 21, 11 PM
Gain the competitive edge you need with powerful AI and Cloud solutions by attending Microsoft Ignite online.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
The basic prerequisite for building a MUI-compliant application for Windows Vista and beyond is to design the application in accordance with Windows globalization guidelines.
One 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.
Initially, 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. The following image shows application code with 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.
A 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. The following image illustrates how code and localizable resources should be logically separated within an application.
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:
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. The following image shows an application that contains 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).
The 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. The following image illustrates that code and localizable resources must be physically separated.
This approach has several advantages over the previous approaches:
The MUI fundamental concepts of physically separating source code from language-specific resources, 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:
The 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.
User interface language settings | Resource creation | Resource loading |
---|---|---|
Follow UI language settings in the operating system${REMOVE}$ |
Single language in a split resource binary (MUI Resource Technology) -or- Multiple languages in a non-split resource binary |
Application calls standard resource loading functions. Resources are returned in the languages matching the operating system settings. |
Application-specific resource mechanism |
Application calls MUI API to retrieve the thread-preferred UI languages or process-preferred UI languages from the operating system and use these settings to load its own resources. |
|
Application-specific UI language settings${REMOVE}$ |
Single language in a split resource binary -or- Multiple languages in a non-split resource binary |
Application calls MUI API to set application-specific UI languages or process-preferred UI languages and then calls standard resource loading functions. Resources are returned in the languages set by the application or system languages. -or- Application probes resources in a specific language and handles its own resource extraction from the retrieved binary data. |
Application-specific resource mechanism |
Application manages its own resource loading. |
Events
Nov 19, 11 PM - Nov 21, 11 PM
Gain the competitive edge you need with powerful AI and Cloud solutions by attending Microsoft Ignite online.
Register now