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
)
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.