Ash's helpful answer is the best solution for machines running Windows 8 or above / Windows Server 2012 R2 or above.

If you still need to run remotely on a Windows 7 / Windows Server 2012 machine:

(Get-ItemProperty 'HKCU:\Control Panel\Desktop' PreferredUILanguages).PreferredUILanguages[0]

Background information:

In local execution, the simplest solution is to use $PSUICulture (returns a string with the language name, such as en-US) or Get-UICulture (returns a [cultureinfo] object), as shown in this answer.

However, this doesn't work when you use PowerShell remoting (which is why the above solution / Ash's solution is necessary):

# Does NOT return the target user's display language.
# Seemingly always returns the OS installation language.
Invoke-Command -ComputerName $someComputer { $PSUICulture }

I'm unclear on the exact reasons, but it may be related to the fact that remotely executed PowerShell code runs in an invisible window station that is distinct from the interactive desktop.

You could check their value of PreferredUILanguages registry value. This is found in HKEY_CURRENT_USER\Control Panel\Desktop

Assuming they are logged off you could loop through all users, load their ntuser.dat registry hive from root of their user directory and retrieve this value.

For example, in powershell :

$Users = ls c:\users -exclude $env:UserName,(split-path $env:Public -leaf)

ForEach ($User in $Users){
  $Name=$User.Name
  reg load HKU\$Name "C:\Users\$Name\ntuser.dat"
  $Lang = (Get-ItemProperty "Registry::HKEY_USERS\$Name\Control Panel\Desktop").PreferredUILanguages
  Write-Host $Name $Lang
  reg unload HKU\$Name
}

How about this? [system.globalization.cultureinfo]::GetCultures("AllCultures")

The restriction only applies to the execution of scripts. It is not a real security measure, it's only there to prevent users from accidentally run PS scripts. Here are some of many ways to bypass the resrtiction without applying changes to the system:

1. Run PS from CMD and pass your command with the -Command parameter:

   powershell -Command "Get-WinUserLanguageList"
   

   You can pass multiple lines (aka a script) by separating the lines by ;:

   powershell -Command "Get-WinUserLanguageList; Write-Host 'Hello World!'"
   

2. Run PS from CMD and pass your code to stdin:

   echo Get-WinUserLanguageList | powershell 
   

3. Run PS from CMD, bypass the execution policy and execute a script file:

   powershell -ExecutionPolicy Bypass -File .\my_script.ps1
   

In a comment you note that the problem was that Set-WinUserLanguageList complained about an invalid language passed as part of the array of languages to -LanguageList and, indeed, ua-UA should have been uk-UA (Ukrainian).^[1]

You could have avoided the problem if you hadn't hardcoded the array passed to -LanguageList and instead retrieved the list of installed user language programmatically:

# Get the current list of installed user languages (as an array).
$userLangs = (Get-WinUserLanguageList).LanguageTag

You could then simply swap the array's first two entries for your successive Set-WinUserLanguageList calls, and use a single call to powershell.exe, the Windows PowerShell CLI.

Here's the PowerShell code in isolation, spread across multiple lines for readability, with comments (note that the Set-WinUserLanguageList calls emit warnings, which you can suppress with -WarningAction Ignore; the Start-Sleep 1 call (1-second sleep) shouldn't be necessary, but, sadly, is):

# Get the list (array) of user languages.
$userLangs = (Get-WinUserLanguageList).LanguageTag
# Create a copy that has the 1st and 2nd elements swapped.
$userLangsModified = $userLangs[1, 0] + $(if ($userLangs.Count -ge 3) { $userLangs[2..($userLangs.Count-1)] })
# Apply the workaround:
# Set the modified list.
Set-WinUserLanguageList -Force -LanguageList $userLangsModified
# Sleep a little. !! As you've found out, this is necessary
# for the 2nd call to take effect.
Start-Sleep 1
# Switch back to the original list.
Set-WinUserLanguageList -Force -LanguageList $userLangs

And here's the (of necessity) single-line form for your batch file:

@echo off

powershell -c "$userLangs = (Get-WinUserLanguageList).LanguageTag; $userLangsModified = $userLangs[1, 0] + $(if ($userLangs.Count -ge 3) { $userLangs[2..($userLangs.Count-1)] }); Set-WinUserLanguageList -Force -LanguageList $userLangsModified; Start-Sleep 1; Set-WinUserLanguageList -Force -LanguageList $userLangs"

Optional reading: How to test the validity of a culture name / language tag (whether it refers to a predefined culture / language):

It is not obvious how to test this, given that you can call a [cultureinfo] constructor with any name that is formally correct ([a-z][a-z] or [a-z][a-z]-[A-Z][A-Z], although case doesn't matter and there are variations with additional/longer tokens) without causing an error; similarly, the .GetCultureInfo() method doesn't report an error by default.

• Windows PowerShell (the legacy, ships-with-Windows, Windows-only edition of PowerShell whose latest and last version is 5.1) / .NET Framework solution:

  $cultureNameToTest = 'ua-UA'
  $isValid = 
    try { ([cultureinfo] $cultureNameToTest).EnglishName -notmatch 'Unknown Locale' } 
    catch { $false }
  

  • Note: Interactively, you can just do something like [cultureinfo] 'ua-UA' and see if the DisplayName column contains substring Unknown Locale or an error is reported.

• PowerShell (Core) 7 (the modern, cross-platform, install-on-demand edition) / .NET solution:

  # Using the Get-Culture cmdlet
  $cultureNameToTest = 'ua-UA'
  $isValid = 
    try { [bool] (Get-Culture $cultureNametoTest) } 
    catch { $false }
  
  # Alternatively, using [cultureinfo]::GetCultureInfo() with the
  # overload with the `predefinedOnly` parameter
  $cultureNameToTest = 'ua-UA'
  $isValid = 
    try { [cultureinfo]::GetCultureInfo($cultureNameToTest, $true) } 
    catch { $false }
  

  • Note: Interactively, you can just do something like Get-Culture ua-UA and see if an error is reported.

^{[1] While the call still succeeds for those languages that are valid (you only get a warning stating The list you attempted to set contained invalid languages which were ignored), the original uk-UA (Ukrainian) entry will in effect disappear from the list (since you mistakenly tried to reference it as ua-UA, which was ignored).}

Don't know if this still works on Windows 7 but it does in Windows XP

reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage

Then you can parse the ouput. e.g.

0409 --> English
0407 --> German