Multilanguage User Interface

Multilingual User Interface (MUI) enables the localization of the user interface of an application.

MUI is provided by Microsoft as an integrated feature of its operating system Windows 11 down to Windows 2000 with some limitations in older versions.

MUI is used for localizing flagship Microsoft products Microsoft Windows and Microsoft Office and as an open technology can be used in any application that runs in a version of Windows that supports MUI.

The core feature of MUI is the user-defined, system settings for preferred language that can be used/shared by all applications on a computer. The next most core feature is system functions (i.e. LoadString) that use this preference to load user interface assets at runtime from resources in the user's preferred language. To be MUI-enabled, an application need only store user interface assets as language-specific resources and use LoadStrIng to load them at runtime.

MUI also supports storing user interface assets as separate, single-language files which provides for development and deployment flexibility. This feature is optional. The resources can be stored in the application binary.

MUI also provides system functions that allow for custom and extended localization behavior.

Overview

The MUI technology is integrated into the Windows OS and can be leveraged in an application by storing localizable assets as resources in a prescribed way and using MUI-enabled win32 functions to read the resources.

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 languages files -- without modifying application logic or other language files
* Add new features and fix bugs by installing only application logic files -- without modifying the installed language files

Terminology

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

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 ssumedand are a list of languages in preference order. These preferences are provided at the system, user, process and thread levels ssumed 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.");

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 MUI-enabled, 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)
    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".

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

Implementing

Basic tasks to support/implement MUI:

* Use LoadString in the application code to read resources; it uses user preference, system settings to read resources that are in the language that is most preferred by the user based on availability
* Author resource source code (RC) for each language; recommended to store each language in a separate RC file
Upon completing the basic tasks, an application is MUI-enabled. But there are other features of MUI that an application can optionally take advantage of.

The basic tasks imply storing all languages in the resources of the application binary -- which means it is ''not'' language neutral. This structure provides all 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:

*Configure the application binary project to exclude all LS resources -- making it the LN file
*Configure project(s) to build each language to a resource DLL; named the same as the LN file + "''LCID''.mui" -- MUI files
*Deploy/install MUI files in same directory as the LN file

To store localized assets in formats other than resource, the application must implement a mechanism for reading assets at runtime based on the language preference system settings (see GetThreadUILanguage). In other words, the application loads UI assets based on the system language preference settings without using LoadString. The application might leverage the MUI file-per-language location and naming convention by using GetFileMUIPath.

Advantages over Localized Version

The MUI technology was developed in response and as an improvement to ''localized versions'' -- an older technology for globalizing and deploying software packages. This section describes the differences and advantages of MUI over localized versions.

Windows localized via a MUI pack achieves the same goal as a localized version, 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. [what does this mean? some special folders are localizable (Documents, Downloads, ...) but a user created file/folder is not localizable (by the OS). Doesn't a language pack localize the special folder names? What else could it do?]

A localized version of Windows translates the base operating system, as well as all included programs [what programs?], including file and folder names [so it does localize file/folder names. this contradicts above], objects names hat's an object? strings in registry eally? what strings? and any other internal strings used by Windows 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. hat is not the case for MUI?
A MUI version does not contain translated administrative functions such as registry entries egistry entries are functions?and items in Microsoft Management Console.

One advantage of a MUI version is that each user of a computer can use a different language. For a localized version of the OS, this is not possible. It may be possible for localized applications but requires installing multiple versions; one for each language, and this may lead to application storage space and side-by-side installation issues. With MUI, the single version supports multiple languages, and the OS and applications use the user's preferred language. Further, the same OS can host an application that uses any of the application's supported languages which may be different than the OS selected language and even a language that's not supported by the OS.

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

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.

= Set 1

=

* German
* French
* Japanese
* Korean
* Chinese (Simplified)
* Chinese (Traditional)

= Set 2

=

* Arabic
* Hebrew
* Spanish
* Italian
* Swedish
* Dutch
* Portuguese (Brazil)

= Set 3

=

* Norwegian
* Danish
* Finnish
* Russian
* Czech

= Set 4

=

* Polish
* Hungarian
* Portuguese (Portugal)
* Turkish
* Greek

= Set 5

=

* Bulgarian
* Estonian
* Croatian
* Latvian
* Lithuanian
* Romanian
* Slovak
* Slovenian
* Thai

Windows Vista

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. his allows anyone to use the MUI technology?
At launch, the following 16 language packs were released:

* Danish
* German
* English
* Spanish
* French
* Italian
* Dutch
* Norwegian
* Portuguese (Brazil)
* Finnish
* Swedish
* Russian
* Korean
* Chinese (Simplified)
* Chinese (Traditional)
* Japanese

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

* Czech
* Estonian
* Croatian
* Latvian
* Lithuanian
* Hungarian
* Polish
* Portuguese (Portugal)
* Romanian
* Slovak
* Slovenian
* Serbian
* Turkish
* Greek
* Bulgarian
* Ukrainian
* Hebrew
* Arabic
* Thai

Windows 7

MUI is available to Windows 7 Enterprise and Ultimate edition users.

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).

Windows 8/8.1/RT

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

* In Single Language editions of Windows, only one language pack is allowed to be installed, 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 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. 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. If that base language is not present or compatible, then that LIP cannot be installed on that device.

Windows 10

Beginning with Windows 10 version 1803, Microsoft started using the term "Local Experience Pack" (LXP) in some places tore?instead of the older term "Language Pack", but they work the same way. 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. 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.

Supported languages

Supported languages by OS version is as follows:

PC

Mobile

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

Patent

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

See also

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

References

{{Microsoft APIs

Windows administration