Issue with English non-US Culture - powershell

I am able to use Set-Culture (Powershell as Admin) to set the Current Culture to "en-DE" which is English (Germany). However, when I run the different PS commands to view the Current Culture, I am still getting en-US. I checked my Region (Format) and Location as well.
Do I have to change the system locale as well to Germany (German) ?
This is causing an error in an application, because the datetime format is different from en-DE to en-US and causing the date to be read incorrectly.
When I Set-Culture to de-DE, everything appears to be in working order.
I make sure to run Powershell Console as Administrator, Set-Culture, close console. Open Powershell and run Get-Culture, [CultureInfo]::CurrentCulture, [CultureInfo]::CurrentUICulture and a few more to check and and still getting en-US

Note: Use of en-DE as a culture identifier - i.e., mixing language en (English) with normally unrelated region/country DE (Germany) - requires Windows 10 with release channel 1607 or later or Windows Server 2016, according to Microsoft.
However, there's a bug that prevents use of such mixed cultures, observed on Windows 10 Pro (64-bit; Version 1709, OS Build: 16299.371)
While you can successfully set such mixed-culture values with Set-Culture, subsequent sessions do not recognize it and fall back to en-US (as reflected in $PSCulture, Get-Culture and [cultureinfo]::currentCulture)
This problem has been reported on UserVoice.
Note that PowerShell Core is not affected (but it doesn't support Set-Culture).
The rest of this answer discusses persistently setting the current user's culture in general, irrespective of the bug.
Set-Culture - via the registry - sets the culture for future PowerShell sessions (only), not (also) for the current session.
Get-Culture, by contrast, only ever reports the current session's culture at session-startup time. That is, if you change the culture during a session (see below), it will not be reflected in Get-Culture.
In order to also apply the newly set culture to the current session, run the following in addition to the Set-Culture call:
[cultureinfo]::CurrentCulture = 'de-DE'
Caveat re interactive (command-line) use:
In Windows PowerShell (still as of v5.1), the active culture is reset after every command submitted; e.g.,
[cultureinfo]::CurrentCulture = 'de-DE'; Get-Date works as expected, because it is part of the same command line, but when executing just Get-Date as the next command, the current culture has reverted to the one that was current at session-startup time.
This problem has been fixed in PowerShell Core.
This perhaps surprising asymmetry - Set-Culture only applying to future sessions, but Get-Culture reporting the current session's (startup) culture - is something that may change in future PowerShell Core versions.


Missing Help Files in Powershell V5.0

Powershell Version: 5.0.10586.494
I just began working with powershell this weekend and I discovered that I cannot find any help files when using the shell, for example, I was looking to read the about_Comparison_Operators help file but it seems as though the console cannot find it.
When doing: Get-Help About_* the only result I get is About_CimSession... it seems like there are no other help files?
This TechNet article suggests that in Powershell v3 the module must be imported,
To download or update the help files for a module in Windows PowerShell 3.0, use the Update-Help cmdlet.
I don't know if it's the same deal in my case? I've used the update-help cmdlet (as admin) and it does not seem to effect the help files.
EDIT: Forgot to mention, I've been running PS as admin while trying to update help. This runs without error, but the help files remain untouched.
UPDATE: Still no luck, tried updating help by specifying language using the UICulture parameter but this didn't make a difference. Will keep this post updated if I find a fix.
Update: PowerShell updatable help is no longer broken. About_ helpfiles are now downloaded with the correct extension. The formatting of these plaintext files still doesn't equal the old versions, however.
PowerShell updatable help is currently broken. PS5 doesn't ship with those about_* helpfiles, and if you update-help to download them, they aren't stored with the appropriate file extension, so get-help doesn't read them.
Only recently were these files being downloaded at all, so if you haven't tried in a while you should still do update-help -force in an elevated session. Then, see this answer for a one-liner that will rename the files correctly:
However, due to a (probably) unrelated issue, these new help files have some mangled text formatting that makes them very difficult to read any time a table-like layout is being used. If you'd like instead to grab the PS4-era about_* files with proper formatting and use those instead, an alternative solution can be found here: Note that this solution will unzip an archive of about_* files to the en\ locale folder, which may not be your default locale (mine is en-US\, for example). This will work fine since the en\ location will be used as a fallback as long as the desired document doesn't exist in your default locale's folder.
Further reference:
FOR non-English OS only
If you are using PowerShell v5 on an operating system that has not the "en-US" language settings then update-help tries to download the help files for your language which might not be available. Use:
Update-Help -UICulture "en-US"
in an elevated (admin) console.
You can check your language setting with the cmdlet get-culture. In my case I get:
PS C:\> Get-Culture
LCID Name DisplayName
---- ---- -----------
1031 de-DE Deutsch (Deutschland)
and at least today (20.7.2017) there are help-files missing (for example get-services). Note that the get-help applet will still first look for help files in your language before it will resort to "en-US" Quelle (in Deutsch).

PowerShell - Set-Culture doesn't seem to change anything

I have a Cloud Service Web Role that I need to run some PowerShell on to ensure the server is always setup in the right culture: en-AU.
The reason for this is that Microsoft could, at anytime, reset the culture values.
When I run:
I get:
1033 en-US English (United States)
So then I run:
Set-Culture en-AU
But I still get:
1033 en-US English (United States)
I have tried many things but nothing seems to really change the culture.
Any help would be great.
The root cause is because you are not running the PowerShell with Administrator privilege.
Set-Culture needs Administrator privilege to be set on the system.
Just run your PowerShell in Administrator mode and your culture will be set to the new one as below:
Hope this helps!

How to solve ImageMagick's “Fontconfig warning: ignoring UTF-8: not a valid region tag” error?

I want add some text on an image file with ImageMagick,
This is what I entered:
convert -font Verdana label:"Text 123" pic.jpg pic_new.jpg
But it returns an error as follows:
Fontconfig warning: ignoring UTF-8: not a valid region tag
The generated picture doesn't have any test added on.
I googled it but most of the posts are not helping much.
Thanks for any kind of tips!
This warning shows up because your local environment states a locale (UTF-8 in this case) which is not valid.
It all boils down to the environment variable named LC_CTYPE which defines the locale to be used. In your case this will default to UTF-8 which simply isn't a locale that is available on your system and thus you see ImageMagick display the warning.
You can run
echo "$LC_CTYPE"
to see what the current setting is.
I know of two ways to remedy this problem:
A) Fix your shell configuration
Depending on which system you're on, there are ways to apply different defaults to your shell. In my case the problem was local only, and i run OS X, so the solution was very simple. In the configuration of the terminal application under the Advanced tab, there is a section called International.
The Set locale environment variables on startup box was checked by default. After unchecking it and restarting the terminal session, LC_CTYPE was no longer set. Therefore there were no more warnings from ImageMagick.
B) Supply the locale
Personally, i don't think this is a good approach. It's more like a workaround that can be messy, and is best avoided. It is also not the correct way to deal with the issue, but it still leads to no further warnings from ImageMagick.
By finding ImageMagick's locale.xml you can identify a list of locale configuration files. Finding the one that matches your working environment (given that you do NOT wish to work with different locales per default) you can copy that file and leave a reference in locale.xml which is identified by locale="UTF-8".
If your problem occurs on some remote server, you can still apply approach (A) but you need to find out how to set the environment variable LC_CTYPE (or unset it) once the session starts.
Hope this helps.

How can I change language and locale of only my application programmatically

I want to change language and locale of my application alone to a language different than user's default that is set on the system. Say my application should use resources of french even though the system default is set to English.
I found few examples for iOS (How to force NSLocalizedString to use a specific language) but even this is only for language, but nothing for OSX. I have the french resource in my bundle. I just want to override the defaults for my application alone. Without changing the entire OS locale from system preferences.
There are nice apps for this problem: Language Switcher and App Language Chooser to name a few.
To do it programmatically, you can use the defaults command to change the app's AppleLanguages property to (fr) or (en, ko), as the following shell script:
bundleId=BUNDLE_ID_OF_YOUR_APP # such as,
# change AppleLanguages
defaults write $bundleId AppleLanguages "(fr)"
# open your app
open -b $bundleId
# then restore the language
defaults delete $bundleId AppleLanguages
See the answer to this similar question at superuser for more detail: Can I change the default language of a application / program in Snow Leopard?.

ActiveX asks user to install every time the page loads

I have an activeX control, that ask the user if he want's to install it every single time the page loads (Even if it is already installed)...
Can anyone point me in the right direction? What I have tried so far:
Setting new Guids for the class & interface.
Changing interfaces names & method names.
Changing version number
Uninstalling and re-installing the activeX
First see this MSDN post it sounds like what you are experiencing.
This can happen when the VerCache
registry key may not have got updated
during the upgrade of the control. For
"VerCache" This happens if the old and
new versions of the control have the
same “Created” date time stamp,
“Modified” date time stamp and the
file size.
If this registry key doesn't exist,
you may have to use the Sysinternals
Process Monitor tool to log a repro of
the problem, then search the log for
the correct registry value that is
being checked. It's most likely under
regardless, ensure that at least one
of these parameters - “Created” date
time stamp, “Modified” date time stamp
or the file size, on the updated
control is different from the old
version of the control.
Also, I would use Process Monitor (Sysinternals) as the user installs the ActiveX control to check that it is making the correct registry entries. Search through the registry for the any GUID's associated with your "old" controls and latest. You may want to backup your registry before actually deleting any registry keys.
You could also try a registry cleaning or search tool.
If these don't help perhaps you could provide some more details about your ActiveX control.
Did you use binary compatability?
What Version of windows of user?
Which version of IE of user?
Is this only happening to this user? (this works for others?)
Did the user re-install any software lately?
How about checking :
The registry (Does your ActiveX make any registry changes?)
The user's PATH environment variable
Have you had the user unregister the dll? You can run this from the cmd line where the dll file is located on the hard drive:
From the command prompt, type “regsvr32 /u filename.dll” where “filename” is the name of the file that you want to unregister.
To solve this I ended up writing a custom installer action which deleted VerCache before and after each install. I also wrote a really long blog post about it to vent. Hope this helps someone from falling into the same time sink.
In my case the solution was to fix the version of my ActiveX control inside resource file my_active_x_control.rc
I read this blog
Go to any machine and start IE8. Select Tools>Manage Addons then
select the Show:Downloaded Controls dropdown. to view the list of
installed Active X controls...
The version of my control was As soon as I updated version inside the resource file continuous installation disappeared.