The Multilingual User Interface (MUI) is a dynamic localization framework used in Microsoft Windows, Windows Phone, and compatible programs; it allows language files to be modular and separate from application logic. It is designed to simplify the development and deployment of localized software. MUI has a number of advantages compared to traditional static localization. Software that uses MUI can do the following:
Store language resources in dedicated files instead of hardcoding them into program binaries, making it possible to update localizations and code dynamically without recompilation. Automatically select a language from Windows' language preferences, instead of asking the user at runtime. Use the Win32 API to load resources from MUI language files. The MUI framework, API, and its localization files (called Language Packs, or LPs) were introduced in Windows 2000; these were significantly expanded on with Windows Vista, which allowed developers to use MUI in their software. Language Interface Packs (LIPs) were added in Windows 7 to supplement Language Packs. LIPs were replaced by Local Experience Packs (LXPs) in Windows 10 build 1809.
Overview The MUI technology is integrated into Windows, and can be used in an application by storing localizable resources in a language file and using the MUI API to load those resources at runtime. A relatively simple implementation of MUI in an application stores the strings of each language in a string-table resource of the binary file and uses the Win32 function LoadString to load strings at runtime. No other MUI-related configuration or code is required. The following optional capabilities of MUI can be implemented if desired:
Store the resources of each language in a separate DLL in order to enable deployment/installation flexibility An application can use dedicated MUI functions to provide more control of localizable asset consumption such as using a language other than the system-defined user preference Localizable assets can be stored in a format other than resources. The design of MUI attempts to provide a common way to store application localization information that alleviates limitations of more traditional and monolithic designs for localization such as including all languages in the application logic files (i.e. resources). With MUI, the following deployment scenarios are possible:
Add support for a language by installing only Language Packs—without modifying application logic or other language files Add new features and fix bugs by installing only application logic files—without having to include localized strings
Technological components
Terminology The following MUI-related terms are either used in or derived from the Microsoft documentation: Language-neutral (LN): Something that conveys a meaning regardless of the languages of the viewer, such as an image without text or other localizable aspects LN resource: A resource that is shared by and installed for all language versions of the application LN file: A Windows binary containing application logic and language-neutral resources. Language-specific (LS): Describes something that varies significantly by language. The most common LS items are interface strings but can be other items, such as an image that contains text. LS resource file: A set of resources localized for one language; also called an MUI file.
Language preferences A language selection is stored by the system for the system (shared by all users and maybe used as default for a new user) and for each user. These selections can be modified by the user via the system Control Panel but cannot be modified by an application. These preferences control the language that the OS uses for UI elements. Applications can also use these preferences, and via MUI-enabled system functions (such as LoadString) the use is automatic and transparent (requires no MUI-specific code to use). But use of these preferences is optional and customizable. An application can be designed to ignore the language preferences. Or it may use them in ways other than that provided by MUI-enabled system functions. An application can use MUI functions to read language preferences—that default to the user selection [assumed] and are a list of languages in preference order. These preferences are provided at the system, user, process and thread levels [assumed that changing at a higher level modifies the preferences for lower levels]. An application can modify these language preference lists (via SetThreadPreferredUILanguages and other functions) in order to influence the behavior of MUI. For example:
Resource storage MUI provides support for localized resources stored in Windows binary (a.k.a. Win32 PE) files (DLL, EXE, SYS) -- usually DLL files. The resources for a language can either be stored in the application binary or in a MUI (a.k.a. LS) file—one per language. For MUI to find resources, a MUI file must be in the same directory as its associated LN file and be named the same as the LN file plus ".LCID.mui". For example, for LN file my-lib.dll, the MUI file for en-US would be named my-lib.dll.0409.mui. String resources are coded as string table like so:
LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL STRINGTABLE BEGIN 1 L"message text" END
Resource retrieval Several Win32 functions that read application resources are compatible with MUI, including LoadString, FormatMessage, and LoadImage. Each function attempts to read a resource for a language as selected by global language preferences, from application resources or associated MUI files (co-located with LN file and following naming convention). Each uses the global language preferences to choose a language that is available. If loading the resource for the first preferred language fails either because the MUI file does not exist or the resource does not exist in the MUI file, the function will try the next preferred language and so on until all preferences have been tried. If load fails for all preferred languages, then tries the LN file. The most commonly used function is LoadString which loads strings from a string-table resource. Example using LoadString:
… excerpt ends here. Continue reading the full article.
