Summary of the new feature / enhancement

Import-LocalizedData should implement a default culture fallback when -UICulture is not specified to simulate the functionality of the command in Windows PowerShell.

PR: #19896

Proposed technical implementation details (optional)

Import-LocalizedData is used by several of the modules released by other teams in Microsoft, most of which as cdxml with a small amount of other code.

For example, in PowerShell 7, attempting to import the SmbShare module will result in an error:

PS> Import-Module SmbShare
Import-LocalizedData: Cannot find the PowerShell data file 'SmbLocalization.psd1' in directory
'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\SmbShare\en-GB', or in any parent culture directories.

Or more directly:

Push-Location C:\Windows\system32\WindowsPowerShell\v1.0\Modules\smbshare
Import-LocalizedData -BindingVariable _system_translations -fileName SmbLocalization.psd1 -ea stop
$_system_translations
Pop-Location

This error is not present in Windows PowerShell.

This error is caused by a difference in how .NET Core+ and .NET Framework handle the CurrentUICulture static property
In .NET Core and higher, the values in the parent list are arguably correct:

$culture = [System.Globalization.CultureInfo]::CurrentUICulture
do { $culture.Name; $culture = $culture.Parent } while ($culture.Name)

For my culture of en-GB results in the following list:

en-GB
en
# <Invariant>

However, if the same test is repeated in Windows PowerShell en-US is implicitly added to the bottom of the list. This only happens when the culture is found using the static property CultureInfo.CurrentUICulture .

The result in Windows PowerShell is shown below.

PS> $culture = [System.Globalization.CultureInfo]::CurrentUICulture
PS> do { $culture.Name; $culture = $culture.Parent } while ($culture.Name)
en-GB
en
en-US
en
# <Invariant>

A spot check of a few other non-en-US UI cultures shows similar results, but I haven't looked hard enough to find a simple way to change the current UI culture (in Windows PowerShell) to really prove that.

For Import-LocalizedData this represents an implicit fallback culture in Windows PowerShell. While this is arguably caused by a bug in .NET, the result is that modules were released with content that worked based on the presence of this bug.

Import-LocalizedData is used by a fairly broad set of modules in the system32 directory, including:

Appx
AssignedAccess
BitLocker
DhcpServer
FailoverClusters
HgsClient
IpamServer
IscsiTarget
Microsoft.PowerShell.Archive
Microsoft.PowerShell.ODataUtils
MsDtc
NetworkSwitchManager
RemoteDesktop
ServerManager
SmbShare
StorageQoS
StorageReplica

I propose that when the -UICulture parameter is not supplied, that en-US should be added to the bottom of the list of parent cultures to search. This restores the behaviour of the command as it was in 5.1.