Add secondary user locale (region) to string lookup

[jannispl]

On my system (24H2) I have a combination of en-US and de-DE locales. I use en-US as UI locale, but de-DE is configured as a "region" for date/time formatting etc. Some dialogs (including the credential dialog) seem to choose their language based on the incorrect locale (de-DE). AuthenticatorChooser would choose the wrong strings in this case (en-US) and not do anything in the dialog.

This PR changes string lookup so that strings for the secondary locale are also looked up.

For the record, this is what the dialog looks like for me:

[Aldaviva]

Thanks for contributing this. Sorry for the inconvenience, I think I may have fixed this same issue (or at least the same symptoms) on master in #8 but not released it yet while I was waiting for feedback from the original reporter. But since multiple people are encountering this issue I think it's time to cut a new release.

• Are you able to test this HEAD build (it includes my older fix) and see if it can handle the different locales on your machine? If that fails I will find a way to combine it with the fix from this PR, although I would like to understand why the first fix was fundamentally insufficient.
• If you can share screenshots of Settings > Time & language > Language & region and the different dialogs in intl.cpl, I will be able to set up a test machine with your exact combination of locales too.

[jannispl]

The HEAD build does not work for me:

 i | 2025-03-25 14:49:59.564 | Startup            | AuthenticatorChooser 0.2.1 starting
 i | 2025-03-25 14:49:59.689 | Startup            | Operating system is Microsoft Windows 11 Enterprise 24H2 10.0.26100.1742 AMD64
 i | 2025-03-25 14:49:59.734 | Startup            | Locales are en-US (user) and en-US (system)
 i | 2025-03-25 14:49:59.773 | Startup            | Waiting for Windows Security dialog boxes to open
 t | 2025-03-25 14:50:21.529 | SecurityKeyChooser | Found authenticator choices after 0,122 sec
 d | 2025-03-25 14:50:21.529 | SecurityKeyChooser | USB security key is not a choice, skipping

---

These are my language settings:

Also note that my OS was originally installed as de-DE but I installed the en-US language pack afterwards. It could be that some UIs in Windows are not localized properly, this is the case for my logon screen (everything is en-US except for the "Other User" option and the "Forgot my PIN" link text, these still appear in de-DE..).

[Aldaviva]

Thanks for these updates, it looks like AuthenticatorChooser guessed that the User locale was en-US based on CultureInfo.CurrentUICulture when it was actually de-DE as shown in the "Security Key" and "iPhone" strings. It's weird that CredentialUIBroker.exe and AuthenticatorChooser.exe had different locales when run as the same user. I will have to set up a VM with your settings to see why that's different.

[jannispl]

CultureInfo.CurrentUICulture.Name is en-US on my system, while CultureInfo.CurrentCulture.Name is de-DE.

Unfortunately I cannot tell if the credential dialog is incorrectly using the "format"/"location" locale for UI strings, or if this is because the system was originally installed as de-DE and these are hardcoded somewhere. If it's the latter I guess you can gather the originally installed language from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language..

[Aldaviva]

Thanks. That's probably the issue I was having. Every time I look up the difference between those properties, I think I'm using the right one, and then it turns out I got it backwards.

[jannispl]

I have now changed my locale settings to be all en-US, and realized that the dialog still contains de-DE strings... Thanks, Microsoft.

So I guess the only way to account for this is to have the locale(s) configurable?

[Aldaviva]

I was going to suggest looking at those "Welcome screen and new user accounts settings" because that's what fixed it when I was trying to test with different languages in the dialog, but since you already tried that, I'm not sure why you're still seeing multiple languages in the dialog. I assume you rebooted after making all those changes?

[jannispl]

Yes, I rebooted after changing my locale settings.

[Aldaviva]

When that Windows Security dialog box appears, here are all the relevant-looking registry keys or values I observed CredentialUIBroker.exe trying to access (using Process Monitor):

• HKEY_CURRENT_USER\Control Panel\Desktop\MuiCached
• HKEY_CURRENT_USER\Control Panel\Desktop\LanguageConfiguration
• HKEY_CURRENT_USER\Control Panel\Desktop\PreferredUILanguages
• HKEY_CURRENT_USER\Control Panel\International\User Profile\Languages
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\*\UserLanguageID
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CustomLocale
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\ExtendedLocale

You mentioned you already looked at some of these. Maybe one of these contains the reason you're still seeing de-DE strings in the dialog box even after setting all the locale values to en-US for your user and machine?

[jannispl]

Here are the registry values as configured on my system using en-US for everything except de-DE for "Format"/"Location":

* `HKEY_CURRENT_USER\Control Panel\Desktop\MuiCached`

MachinePreferredUILanguages=en-US

* `HKEY_CURRENT_USER\Control Panel\Desktop\LanguageConfiguration`

de-DE=en-US

en-US=de-DE

* `HKEY_CURRENT_USER\Control Panel\Desktop\PreferredUILanguages`

en-US

* `HKEY_CURRENT_USER\Control Panel\International\User Profile\Languages`

en-US de-DE

* `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\*\UserLanguageID`

1033 (en-US)

* `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CustomLocale`

empty

* `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\ExtendedLocale`

empty

[Aldaviva]

Thank you again for this contribution. I was able to reproduce the same or similar symptom on a VM. In that case, the problem was missing en-US MUI files after installing the English language pack, so Windows was falling back to the de-DE MUI files from when the OS was first installed. I was able to get it working by checking for strings in all installed languages, not just the most preferred one for the user and the system. Feel free to try build 29 for commit b4db9ded13e4a8133247cf2146ea708390403c8d and see if that works on your machine too.