Multilingual User Interface

The following MUI related terms are either used in or derived from the Microsoft documentation.

Language-neutral (LN): Describes 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: Windows binary containing the application logic and language-neutral resources

Language-specific (LS): Describes something that has significantly different meaning based on the languages of the viewer. The most common LS items are interface strings but can be other items such as an image with text in it

LS resource file: A set of resources localized for one language; a.k.a. 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:

std::string languageIdSpec = "en-US";
languageIdSpec.push_back('\0'); // must be double-null terminated
ULONG langCount = 1;
if (!::SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, languageIdSpec.c_str(), &langCount))
    throw std::runtime_error("Unable to set thread preferred UI language.");

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 MUI-enabled, 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)
    throw std::runtime_error("Unable to find resource.");
std::wstring text;
text.append(resourceCharArray, resourceLength);

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 std::string and its c_str() method is guaranteed to be null terminated. Therefore, there is no need to append a null. 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]

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.

Up to Windows XP, MUI packs for a product are applied on top of an English version to provide a localized user experience. There are a total of 5 sets of MUI packs.

Windows Vista enhanced MUI technology to separate the English resources from the application logic binary files. The application logic files are now language-neutral a.k.a. language-independent. In other words, the application logic files are no longer English-centric. This separation allows for changing languages completely without changing the core binaries of Windows, and to have multiple languages installed using the same application logic binaries. Languages are applied as language packs containing the resources required to localize part of or the entire user interface in Windows Vista.

MUI packs are available to Windows Vista Enterprise users and as an Ultimate Extras to Windows Vista Ultimate users.

Beginning with Windows Vista, the set of associated MUI APIs are also made available to developers for application development. [This allows anyone to use the MUI technology?]

At launch, the following 16 language packs were released:

On October 23, 2007, the remaining 19 language packs were released:

MUI is available to Windows 7 Enterprise and Ultimate edition users, as well as Windows Phone 7.

Beginning with Windows 7, Microsoft started referring to a "MUI pack" as a "Language Pack"; not to be confused with a Language Interface Pack (LIP).[9]

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

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

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

• In Single Language editions of Windows, only one language pack is allowed to be installed, [12] the same behavior as editions of Windows 7 and earlier that are not Enterprise or Ultimate.
• In OEM editions of Windows, the exact language packs 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[13] 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 (not necessarily done in one go), 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.[14] 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 their smartphones.
  • Certain language packs like English (Australia) and English (Canada) are only supported on the Xbox consoles and the Surface Duo.
  • Some LIP packs require certain MUI packs (base languages) to be present or compatible.[15] If that base language is not present or compatible, then that LIP cannot be installed on that device.

Beginning with Windows 10 version 1803, Microsoft started using the term "Local Experience Pack" (LXP) in some places [store?] instead of the older term "Language Pack", but they work the same way.[16] In addition to installing via Windows Settings, these 110 LXPs are also available through the Microsoft Store (app and web); the latter enabling remote installation for consumer editions of Windows.[17] 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.

An LXP is updated through the Microsoft Store; outside of the normal Windows update cycle.[18]

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