PowerShell scope of changes in lines with multiple commands - UICulture

Question

During my tinkering with PS 5.1 related to the objective of question Fully change language for the current PowerShell session I observed a "strange" behavior:

Answer 1

Due to a bug in Windows PowerShell^[1] (PowerShell [Core] v6+ is not affected), in-session changes to [cultureinfo]::CurrentUICulture and [cultureinfo]::CurrentCulture are automatically reset to the values at startup time^[2] at the command prompt, whenever a command finishes executing.

Trying to modify the culture(s) in $PROFILE is equally affected, unfortunately.

However, for a given script, in-script culture changes remain in effect for the entire script as well as its callees (on the main thread) - see this answer.

There are two possible workarounds:

• Use reflection to modify the non-public field where Windows PowerShell stores the start-up culture value(s) - see this answer.

  • Note: Modifying non-public fields is generally ill-advised, but should be fine in this case, given that Windows PowerShell will see no new development; however, note that $PSUICulture / $PSCulture will not reflect the culture put into effect by the workaround - use [cultureinfo]::CurrentCulture / [cultureinfo]::CurrentUICulture instead.

• Alternatively, change the current user's OS-level language / locale settings before starting PowerShell:

  • Programmatically,

    • you can change the current user's display language (UI culture, reflected in [cultureinfo]::CurrentUICulture) with Set-WinUILanguageOverride

    • you can change the locale (culture, reflected in [cultureinfo]::CurrentCulture) with Set-Culture

    • Note that both commands require at least Windows 8 / Windows Server 2012 R2 and that Set-WinUILanguageOverride requires a logoff of reboot to take effect, while Set-Culture changes only take effect in future sessions (but don't require a logoff / reboot).

---

^{[1] There is no official bug report I am aware of, but the following factors lead me to classify Windows PowerShell's behavior as a bug: The behavior is counterintuitive, cannot be avoided other than via a hack, and has been corrected in PowerShell [Core] v6+. Also, a core member of the PowerShell team had this to say in this GitHub issue: "I forget exact details, but the current culture is reset for reasons I never understood."}

^{[2] The values at startup of the PowerShell process, as determined by the user's OS-level display language and locale settings (regional format).}