While testing that I had fixed the language-switching issues for bug # 34451, I discovered that for some reason, the platform's language environment variables are not being set. I verified in a VM with a clean platform install, but I'm wondering if this is maybe a Win7 issue, or just something that's happened and no one has noticed yet...Or is it just some issue with my machine(s).
Is it running as admin? If so, that's a known issue.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Just running as a normal user. The weirdest thing about is that SystemExplorer Portable correctly detects the variables (which I can't find anywhere), and CrystalDiskInfo doesn't, even though they're using the same Environment Variable to set: PortableApps.comLocaleName, using PAL.
Keep in mind that LocaleName has a different case than some apps are expecting.
Sometimes, the impossible can become possible, if you're awesome!
So this explains why I can get CCleaner language switching working, but not Recuva (same process in practice)? Admin rights cause the variables to not get set?
Is there a date for a fix?
When you launch an app as admin from something else, it loses the entire environment you are coming from. There's no fix for that piece as it's by design. We have a thought as to allowing the app to pass it on by relaunching the launcher passing in environment variables via a config file, though, and having the launcher re-set them before continuing.
Sometimes, the impossible can become possible, if you're awesome!
I saw that in Launcher documentation, it references new language features in 3.0 (which I can't find 3.0 beta), should be able to integrate it into that.
There isn't a 3.0 beta yet.
Sometimes, the impossible can become possible, if you're awesome!
There is one, of when it was still called 2.2 (so it's 3.0 just in spirit). I'm not sure it does include that fix.
Previously known as kAlug.