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: LPCWSTR languageIdSpec = L"en-US\0"; ULONG langCount = 1; if (!SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, languageIdSpec, &langCount)) MessageBoxW(NULL, L"Unable to set thread preferred UI language.", NULL, MB_ICONERROR);
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: wchar_t *resourceCharArray; int resourceLength = LoadStringW(moduleHandle, resourceId, (LPWSTR)&resourceCharArray, 0); if (!resourceLength) { MessageBoxW(NULL, L"Unable to find resource.", NULL, MB_ICONERROR); return -1; }
wchar_t *text = (LPWSTR)malloc((resourceLength + 1) * sizeof(wchar_t)); wcsncpy(text, resourceCharArray, resourceLength); text[resourceLength] = L'\0'; // null terminate This retrieves the address of the resource text character buffer which is not guaranteed to be null terminated. Then, this copies the characters to a new buffer and appends a null terminator. Another option is to have LoadString copy the string to a passed buffer, but that requires using a fixed-length buffer which has downsides like usually allocating more than needed or truncation if too short.
Oddly, MS documentation for LoadString does not mention its interaction with MUI—use of language preference.
FormatMessage is also MUI-enabled. Its function reference page describes its interaction with the user's language preference when parameter dwLanguageId is passed as 0. But FormatMessage reads from a message table, not a string table and as Raymond Chen says, "nobody actually uses message tables".
Non-Resource Storage and Retrieval MS documentation recommends storing UI assets as resources since MUI fully supports retrieving from this storage, but it notes that MUI supports any other file format, such as XML, JSON or flat text file. This implies that using the resource retrieval aspect of MUI is not required for an application to be MUI-enabled. An application can use its own, custom UI asset retrieval logic.
To be MUI-enabled, the application must use the system language preferences. The custom UI asset retrieval logic might optionally use the MUI function GetFileMUIPath to leverage the MUI file location and naming conventions.
Other Aspects The MS MUI documentation describes the following concepts, but it is unclear how they relate to MUI and what value they offer:
Resource Configuration File Registry String Redirection
Implementation
Basic implementation of MUI entails the following:
Use LoadString to read resources, taking into consideration user preferences and system settings to serve the best available localization. Author resource source code (RC) for each language; it is recommended to store each language in a separate RC file.
Upon completing the basic tasks, an application is compatible with MUI, but there are other MUI features that an application can take advantage of.
A program that uses MUI can store localization directly in its binaries; this provides all the runtime localization benefits of MUI and simple, single-file deployment, but does not allow for deployment flexibility that MUI provides. In order to take advantage of the deployment flexibility:
Separate localized strings from application logic Store your localization in Language Packs, separated by language. You can also use LIPs or LXPs to store localization data. Place these Language Packs in the same directory as the application binary.
To store localized assets in formats other than resources, the application must implement a mechanism for reading assets at runtime based on the system's language preferences (see GetThreadUILanguage). In other words, the application loads UI assets based on preferences without using LoadString; the application may leverage the MUI file-per-language location and naming convention by using GetFileMUIPath.
Advantages over static localization The MUI technology was developed in response to, and as an improvement over, static localization—an older technology for globalizing and deploying software packages.
Software localized via a Language Pack achieves the same goal as a static localization, but there are key differences. While both display menus and dialogs in the targeted language, only a localized version uses translated file and folder names.
In Windows, a system-wide Language Pack translates the base operating system, as well as all MUI-capable applications, into a particular language. Localized versions of Windows support upgrading from a previous localized version and user interface resources are completely localized, which is not the case for MUI versions of a product.
A Language Pack does not translate administrative content such as registry entries and items in the Microsoft Management Console.
One advantage of MUI is that each Windows user can set a different language. For a version of Windows that only has static localization, this is not possible. With MUI, a single piece of software can support multiple languages, and the OS and applications use the user's set language. In addition, an operating system that is localized with a particular Language Pack can run applications that are localized with different Language Packs.
History MUI was introduced with Windows 2000 and is supported in each subsequent Windows release.
Windows 2000 and Windows XP MUI products for these versions were available only through volume agreements from Microsoft. They were not available through retail channels. However, some OEMs distributed the product.
Languages in Windows XP In Windows 2000 and XP, Language Packs for a product replace hardcoded American English strings. There are a total of 5 Language Pack sets.
Set 1
Deutsch Français 한국어 中文 (简体) 中文 (繁體) 日本語
Set 2
Español Italiano Nederlands Português (Brasil) Svenska עברית العربية
Set 3
Čeština Dansk Norsk bokmål Suomi Русский
Set 4
Magyar Polski