Win32 / MFC · Multilingual Library

MFC Multilingual Library for runtime language selection.

Add in-app language switching to MFC applications that load translated native resources from resource-only DLLs. Multilingual Library detects the available language files, chooses a default language from Windows settings, and helps wire a language menu into the application.

Download binary sample (ZIP, 165 KB) Download source code (ZIP, 52 KB)

Create the language DLLs: Win32 / MFC guide

For: MFC applications with resource-only DLLs
Language files: MyAppDEU.dll, MyAppFRA.dll next to the EXE and DLLs
Default: The Windows language; the user's choice is remembered
Ships as: A binary sample and source code to link with your project

On this page

How it works
When to use it
Integration
Extension DLLs
Release layout
Checklist
FAQ

Localizer creates the language files; Multilingual Library loads them.

Executable code stays in the main application files, and translated UI resources stay in resource-only DLLs, one for each language. At startup, Multilingual Library looks for the language files next to the application, takes the saved choice or the Windows language, and loads the translated resources. A new choice from the language menu applies at the next start.

Lingobit Localizer

Extracts native resources from compiled EXE and DLL files.
Translates dialogs, menus, string tables, and version information, with visual dialog editing.
Reuses translations, pseudo-translates, and runs Validation.
Writes the resource-only DLLs for each language.

Multilingual Library

Finds the language files at runtime, for the EXE and for MFC extension DLLs.
Chooses a default language from Windows settings.
Keeps the user's choice in the registry for later runs.
Provides menu helpers for a language menu.

Use it when one MFC executable should switch between languages.

Modern MFC loads MyAppDEU.dll for the Windows language by itself (Win32 / MFC guide), so you need the library only for applications built with older MFC versions.

Use it when

The application is built with MFC, and its translated UI lives in resource-only DLLs.
One executable should support several UI languages.
Users choose the language inside the application, and the choice is restored on the next start.
MFC extension DLLs also need to load localized resources.

You may not need it when

Each language ships as a separate localized EXE or DLL.
The installer chooses one language, and the application never switches.
The application already has its own resource-loading logic.
The project uses another runtime localization framework or UI layer.

Reference

Link the library, reserve IDs, initialize, and load resources.

The exact class names and initialization point depend on the application. Treat the snippets as integration patterns, not copy-paste-ready code for every MFC project.

Link the MFC project with multilang.lib, and include MultiLang.h where UI resources are initialized or updated.
Reserve a command ID range for the language menu, and add handlers for language changes and menu state.
Initialize the library during application startup.
Load matching resources in MFC extension DLLs where needed, and ship the language files next to the binaries.

Include the header and reserve IDs

#include "MultiLang.h"

#define ID_LANGUAGE_FIRST 32000
#define MAX_LANGUAGES     100

Initialize language selection

MultiLangInitLocalization(
    ID_LANGUAGE_FIRST, MAX_LANGUAGES,
    HKEY_CURRENT_USER,
    _T("Software\\YourCompanyName\\YourProductName"),
    _T("GUILanguage"));

Do not reuse the range from ID_LANGUAGE_FIRST to ID_LANGUAGE_FIRST + MAX_LANGUAGES for other commands. Initialize after the standard MFC startup path has completed and, where possible, before localized UI is created.

Show the menu handlers

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
    ON_COMMAND_RANGE(
        ID_LANGUAGE_FIRST,
        ID_LANGUAGE_FIRST + MAX_LANGUAGES,
        OnLanguageFirst)
    ON_UPDATE_COMMAND_UI_RANGE(
        ID_LANGUAGE_FIRST,
        ID_LANGUAGE_FIRST + MAX_LANGUAGES,
        OnUpdateLanguageFirst)
END_MESSAGE_MAP()

void CMainFrame::OnLanguageFirst(UINT nID)
{
    MultiLangOnClickMenu(nID);
    AfxMessageBox(_T("Please restart the application for changes to take effect."));
}

void CMainFrame::OnUpdateLanguageFirst(CCmdUI* pCmdUI)
{
    MultiLangUpdateMenu(pCmdUI);
}

In many MFC applications, a restart is the safest way to apply the new language: windows, menus, and cached resources may already be loaded.

MFC extension DLLs load the same language.

If the product uses MFC extension DLLs with their own resources, each DLL loads the language file chosen for the main application, so its dialogs, menus, and strings stay in the same language.

#include "MultiLang.h"

YourDLLNameDLL.hResource = MultiLangLoadLibrary(
    hInstance,
    HKEY_CURRENT_USER,
    _T("Software\\YourCompanyName\\YourProductName"),
    _T("GUILanguage"));

Name each language file after its binary and keep it next to it.

Localizer names each resource-only DLL after its binary and the Windows language code: MyAppDEU.dll for German, MyAppFRA.dll for French. The library also finds the names of earlier projects, such as MyAppDE.dll or MyApp.DE. Keep the same set of languages across the main application and its extension DLLs.

Simple application

Application folder
|- MyApp.exe
|- MyAppDEU.dll
|- MyAppFRA.dll
|- MyAppESN.dll
\- MyAppJPN.dll

Application with extension DLLs

Application folder
|- MyApp.exe
|- MyDll1.dll
|- MyDll2.dll
|- MyAppDEU.dll   MyDll1DEU.dll   MyDll2DEU.dll
\- MyAppFRA.dll   MyDll1FRA.dll   MyDll2FRA.dll

The language files can be built by hand, but for real products generate and update them with the Win32 / MFC localization workflow: extract the native resources from the compiled application, translate and adjust the dialogs visually, run Validation, and create the resource-only DLLs for each language. If UI strings are still hardcoded in C++, move them into resources with Lingobit Extractor first.

Development checklist.

Dialogs, menus, string tables, and other UI strings are stored in native resources.
Each target language has its resource-only DLLs, next to the right EXE or DLL.
The language menu lists every expected language.
The default language is right on representative Windows language settings.
Switching and restarting work, and the chosen language is saved and restored.
Extension DLL resources follow the chosen language.
Validation has run before the release is packaged.
The library does not translate the application or replace dialog review, QA, and Validation.

FAQ

Is Multilingual Library a localization tool?

No. It is a developer library for runtime language selection. Use Lingobit Localizer to translate resources and create the localized output.

Does it work without resource-only DLLs?

No. It is designed for applications that keep translated UI resources in separate language files.

Can users switch language inside the application?

Yes. The menu helpers let the application show a language selector and remember the chosen language for later runs.

Where is the selected language stored?

Under an application-specific registry key, typically under HKEY_CURRENT_USER.

Does language switching apply immediately?

No. Usually the safest approach is to restart the application after changing the UI language, because windows, menus, dialogs, and cached resources may already be loaded.

Win32 / MFC — Create and update the resource-only DLLs from your compiled build.
Localization QA — Validation, pseudo-translation, and Crash Finder.
Extractor — Move hardcoded C++ strings into resources.
Download — Try Localizer on a representative MFC build.