Multilingual User Interface

The Multilingual User Interface (MUI) is a localization framework used in Microsoft Windows and compatible Windows applications; it allows language files to be modular and separate from application logic. It is designed to simplify software development and deployment when localizing a user interface.

MUI provides a framework for localizing language strings, addressing the limitations of older localization methods; for instance, MUI uses dedicated language files (called Language Packs, or LPs) instead of hardcoding language strings into software. With MUI, it is possible to:

• Add support for a language using Language Packs instead of editing source code, separating language from logic and allowing developers to update or deploy one without involving the other.

• Use Windows language preferences (set in the Control Panel) to select a Language Pack for compatible applications.

• Use the Win32 API to load resources from Language Packs.

The MUI framework, API, and Language Packs were introduced in Windows 2000; 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.

The MUI technology^[1] is integrated into Windows and can be used in an application by storing localizable strings in a Language Pack and using the Win32 API to retrieve strings from it.

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 resource

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

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.

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^[2] 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);

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

Several Win32 functions that read application resources are compatible with MUI, including LoadString, FormatMessage, and LoadImage.^[3]

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".^[4]

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.^[5] 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.

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^[6]
• Registry String Redirection^[7]

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.

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.^{[citation needed]}

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.^{[citation needed]}

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.^[8] 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.

MUI was introduced with Windows 2000 and is supported in each subsequent Windows release.

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.^{[citation needed]}

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

Set 2

Set 3

Set 4

Set 5

Windows Vista updated the MUI protocol to separate language resources from the application logic binary files; the application logic files are now language-independent (no longer containing American English). This separation allows for true language switching, and to have multiple Language Packs independent of the application logic binaries. Languages are applied as Language Packs containing the resources required to localize the user interface.

Language Packs are available for Windows Vista Enterprise and as an optional extra for Windows Vista Ultimate.

Beginning with Windows Vista, MUI APIs were also made available to developers for application development. This allowed third-party developers to use the MUI technology.

At launch, the following 16 language packs were released:

On October 23, 2007, an additional 19 language packs were released:

Language Packs are available for Windows 7 Enterprise and Ultimate, as well as Windows Phone 7.

Beginning with Windows 7, Microsoft introduced a new format of language pack, called a Language Interface Pack (abbreviated as LIP). These serve to provide partial translations that are not present in a base LP.^[9]

At launch, the following 15 language packs were released^[10] (Chinese (Hong Kong) is not available on mobile):

On October 31, 2009, an additional 22 language packs were released (Estonian, Croatian, Latvian, Lithuanian, Romanian, Slovak, Slovenian, Serbian, Bulgarian, Hebrew, Arabic, and Thai are not available on mobile):

At launch, only six languages were supported:

With the launch of Windows Phone 7.5 on September 27, 2011, twenty more languages are added (Turkish and Ukrainian are not supported as display languages until Windows Phone 8).^[11] The first LIPs for Windows Phone 7 were Indonesian and Malay with the Tango update.^[12]

Beginning with Windows 8/RT, almost all editions of Windows are able to download and install Language Packs and LIPs,^[13] with a few exceptions:

• In Single Language editions of Windows, only one LP is allowed to be installed,^[14] the same behavior as editions of Windows 7 and earlier that are not Enterprise or Ultimate.
• In OEM editions of Windows, the exact LIPs that are preinstalled/available for download depend on the device manufacturer and country/region of purchase (and the mobile operator for devices with cellular connectivity). This is a mixture of a local-market feature and a feature for everyone everywhere. There may be multiple display languages preinstalled on the device by the manufacturer and/or wireless carrier, but each manufacturer and/or wireless carrier installs two different sets of languages: one set of preloaded languages and one set of languages that can be installed by the end user. This rule is currently used in Windows Phones as of Windows Phone 7^[15] and PCs as of Windows 8 (since Windows 8 and Windows Phone 8 share the same Windows NT kernel) and was later dropped in Windows 10 version 1803, but was later quietly reinstated as of Windows 10 version 1809. An end user could install a retail license on top of an OEM license by performing a clean install through the Media Creation Tool to circumvent the region locking and install any display language that they want.
  • The Windows update process does not affect the currently installed display languages in any way, but it may give the end user access to newly released language packs made available by the OEM (PCs only). However, when installing a new feature update, it may change the display language back to the one set during the initial setup process. For example, if the Samsung ATIV Smart PC on AT&T is upgraded from Windows 8.1 to Windows 10 Anniversary Update, it will now be able to install Portuguese (Brazil), Vietnamese, Chinese (Simplified and Traditional), and Japanese in addition to English, Spanish, French, German, Italian, and Korean (the last three languages can be downloaded by the end user at the time of its launch), just like with the Galaxy S8 series and the Verizon-based Galaxy Book.
  • On the other hand, a Samsung Galaxy Book device does not support Afrikaans as a display language, because Samsung apps do not officially support Afrikaans.^[16] Furthermore, cellular variants of the Galaxy Book laptops sold in North America support fewer display languages than their Wi-Fi-only counterparts, just like on Samsung smartphones.
  • Certain language packs like English (Australia) and English (Canada) are only supported on the Xbox consoles and the Surface Duo.
  • Some LIPs require certain Language Packs to be present or compatible.^[17] If the Language Pack dependency is not present or compatible, then that LIP cannot be installed on that device.

Beginning with Windows 10 version 1803, Microsoft phased out LIPs in favor of Local Experience Packs (LXPs)..^[18] In addition to installation via Windows Settings, LXPs are also available through the Microsoft Store^[19]; the latter enabling remote installation for consumer editions of Windows.^[20] As with all applications from the Microsoft Store, only the LXPs that are compatible with that Windows device are shown in the Microsoft Store app.

Supported languages by OS version are as follows:

The multilingual user interface for Windows Phones did not appear until version 7.0.

Modern SaaS and web applications apply the core MUI principle by storing language-specific resources separately (often externally, like in JSON files) and selecting the user interface language automatically according to browser or account preferences.^[21][22] This separation allows new languages to be added or updated without modifying application logic. Industry research shows that each additional language can increase annual support and QA costs by 10–15%, and that incomplete localization—such as untranslated onboarding, billing, or support workflows—is a major reason for user churn in new markets.^[23] Best practices include automating translation management, involving native-speaking testers, and ensuring that all customer-facing workflows are fully localized for every market.

The MUI technology is covered by an international patent titled "Multilingual User Interface for an Operating System".^[24] The inventors are Bjorn C. Rettig, Edward S. Miller, Gregory Wilson, and Shan Xu.

• Windows MUI Knowledge Center (archived)
• Windows Language Packs (Microsoft reference)
• Language Interface Pack (LIP)
• GNU gettext: both a UNIX system for localization and a function similar to LoadString