1

This is something that is driving me nuts for a while and I haven't been able to find a solution for this problem anywhere.

I am running Windows 7 and my "Language for non-Unicode programs" setting is set to Russian. I need for some non-unicode software that has a Russian UI.

However, for most of my software I prefer to use the English UI. A lot of software out there is multilingual and is too smart for my liking. When installing, it switches the UI to Russian and the software UI stays in Russian after the installation without an option to change that, besides setting the "non-unicode language" to English. It switches back to Russian once I revert the setting and reboot. Most of the time it is driver software, i.e: Intel, HP, etc.

How can force the installation to run English and stay that way after install, ignoring the "Language for non-Unicode programs" setting? Now, I understand this might be specific to the installer: MSI, Install Shield, etc. But any solution will be good, even if I have to apply it for every software installation.

Thanks in advance for any helpful information!

mitya
  • 11
  • 2

1 Answers1

0

Sadly, you can't. (As answered here) Windows does not allow you to have a per-process locale. You can either run one of the locales in a VM or have another user profile for the other locale. The VM is a bit more work, but allows easier switching and better integration (i.e. with VirtualBox seamless mode)

Community
  • 1
Aurelia
  • 118
  • 1
  • 14
  • I think you're missing the point here. It's not a Windows problem. If software package is English only, it will run just fine under Russian locale. The problem is with software being to smart and automatically switching the language to whatever the system is set to. I just want to disable or override this behavior. The English UI is already there inside the software package, I just want to use it! My main UI language is English and I don't want software to decide to use a different language based on a setting that was intended for another purpose. – mitya Nov 09 '12 at 11:58
  • Still, you can't run per-process locales. There is no hidden switch in the properties, at least not on Windows side. – Aurelia Nov 09 '12 at 12:58
  • This is not about locales. Some software gives you an option to select the installation language. I select 'English' and it works fine, with ANY locale. Some software selects the installation language automatically based on a faulty logic. I know that both MSI and InstallShield have a lot of settings to override default behavior during installation with command line switches and parameters. I just don't know which setting to use to force English installation language. – mitya Nov 09 '12 at 13:12
  • Still, the only generic solution would be applying locales per-process, so the installer can't detect your system runs on another locale. You need to be more specific then, command line switches are *not* standardized. See? You're asking for a generic solution, to a specific issue. – Aurelia Nov 09 '12 at 13:14
  • No, I didn't ask for a generic solution. Read the last two sentences of my original question again. But there should be a single solution for each installer type. – mitya Nov 09 '12 at 13:16
  • Yes, you are... Even though you acknowledge the solution might be specific, you're still asking for the one generic solution you can "apply for every software installation". The only generic solution I'd know would be hooking the processes call to the Windows API to determine the locale. There are no secret command line switches for "cooked" installers. They either ask you or have an "autodetect" script. – Aurelia Nov 09 '12 at 13:21
  • I am asking for a solution per installer type, i.e. command line option. And yes, there are command line switches for MSI and InstallShield, because they support silent/unattended installations. I don't understand why are trying to convince me there is no solution. You suggested something, I declined. This is not an argument, I don't have to accept your point of view. I will wait for other responses to my questions. Feel free to move on now. – mitya Nov 09 '12 at 13:30