Should I translate my window class names?

Raymond Chen

March 31st, 20228 0

The default Windows Desktop project template used by Visual Studio loads the window class name from resources:

WCHAR szWindowClass[MAX_LOADSTRING];

LoadStringW(hInstance, IDC_PROJECTNAME, szWindowClass, MAX_LOADSTRING); 

ATOM MyRegisterClass(HINSTANCE hInstance)
{
    WNDCLASSEXW wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);

    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_PROJECTNAME));
    wcex.hCursor        = LoadCursor(nullptr, IDC_ARROW);
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = MAKEINTRESOURCEW(IDC_PROJECTNAME);
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

    return RegisterClassExW(&wcex);
}

Do window class name need to be a translatable resource?

Window class names are never shown to the user, so there’s no need for them to be translated.

Okay, but even though there’s no requirement that they be translated, should they be translated?

No, they shouldn’t.

Window class names are often the subject of automation. Screen readers and other assistive technologies use class names to identify windows so that they can apply custom functionality for that window. For example, if they see a window whose class name is CabinetWClass, then they know that it is an Explorer window and can activate Explorer-specific behaviors, like maybe enabling special commands for opening and closing the Preview Pane. If the name of the window class changed as the user changed languages, the assistive technology tools would have to keep updating to catch up with the different translations.

Back in the days of 16-bit Windows, it was common for the programmatic interface to parts of the system to be based on window class names. For example, if you wanted to open a particular Control Panel, you launched control.exe, and then looked for a window whose class name is Control Panel and sent it a specific message. If these class names were translated for each locale, it would be nearly impossible to write an installer: You would have to write something like this:

HWND FindControlPanelWindow()
{
    // English?
    HWND hwnd = FindWindow("Control Panel", NULL);
    if (hwnd) return hwnd;

    // German?
    HWND hwnd = FindWindow("Systemsteuerung", NULL);
    if (hwnd) return hwnd;

    // French?
    HWND hwnd = FindWindow("Panneau de configuration", NULL);
    if (hwnd) return hwnd;

    // Vietnamese? (Điều khiển)
    // Note that Vietnamese uses code page 1258, but our source
    // code is in code page 1252, so this string is intentional
    // mojibake.¹ 
    HWND hwnd = FindWindow("ÐiêÌu khiêÒ", NULL);
    if (hwnd) return hwnd;

    //... and so on ...
}

And then each time Windows added support for another language (over 100 of them now), you’d have to ship an updated installer.

For these reasons, window class names should be treated as programmatic names and should not be localized.

¹ By an interesting coincidence, code unit D0 in code page 1258 is U+0110 (LATIN CAPITAL LETTER D WITH STROKE) “Đ” which looks very similar to code unit D0 in code page 1252: U+00D0 (LATIN CAPITAL LETTER ETH) “Д.

Raymond Chen

Read next

8 comments

Discussion is closed. Login to edit/delete existing comments.

  • Marcel Transier 0

    That brings me to the next question: Why is it best practice to use a translatable resource to store the windowclass name?

    • Solomon Ucko 0

      Maybe to make them easier to change in case of compatibility problems or whatnot?

    • Raymond ChenMicrosoft employee 0

      I just argued that they shouldn’t.

      • David N 0

        Shouldn’t be changed or shouldn’t be stored in a resource? That then begs the question, why does the Windows Desktop project template do it that way?

  • George Jansen 0

    I don’t think I’ve ever seen a capital Eth before.

  • skSdnW 0

    “if they see a window whose class name is CabinetWClass” Explorer used to be pretty special, use the /e switch and the Explorer window would change its window class. Why, I don’t actually know. I assume for compatibility but that does not make much sense either because even without the folder tree, a Win95 cabinet window is very different from what came before (ListView or even a custom NSE with custom controls).

  • 紅樓鍮 0

    Does that mean windows class names are part of the public API surface of a GUI app?

    • skSdnW 0

      For the most part, NO! For example, APIs related to the taskbar do FindWindow+SendMessage but those are internal details, just use the documented functions. For automation, use MSAA/UI Automation.

      Of course 3rd-party apps may use their class as part of the API. The most popular mp3 player back in the day had a public SDK where the class name was part of the API and there were/are messages to send for play/pause/next/isplaying/getlength etc. But it has its downsides if you don’t plan well.

      1) Their class name ends with “v1.x” which is a bit silly when they are at v5.

      2) They added a switch to use a custom class name. I think this was to allow multiple instances in some sort of DJ mode but also breaks people looking for the class name.

Feedback usabilla icon