Import-LocalizedData does not load any data when there is mismatch between current UI culture and data available #8219

Activity

1. Ilya (iSazonov)

   added

   Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif

   Area-Cmdlets-Utility

   on Nov 9, 2018
2. Ryan Yates (kilasuit)

   added

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on May 11, 2023
3. chrisdent-de commented on Jun 15, 2023

   

   Chris Dent (chrisdent-de)

   on Jun 15, 2023

   Contributor

   More actions

   Import-LocalizedData walks up the Parent property of either the CurrentUICulture or a supplied -UICulture. However, there is a difference in how the Parent properties are filled between .NET Framework and .NET Core (and higher).

   This difference causes a problem for a reasonable number of the modules in System32 that make use of Import-LocalizedData. The list from my computer is below, not all of these are or can be compatible with Core, nor am I suggesting that any change here will make them so:

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

   Import-LocalizedData uses the static property Globalization.CurrentUICulture when a -UICulture is not supplied:

   [System.Globalization.CultureInfo]::CurrentUICulture

   Then the parent of that culture is explored to try and find a path to import. With a UI culture of en-GB, I see the following parents:

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

   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 to really prove that.

   If I do the same in PowerShell 7 the parent of the first en is 127, Invariant Language (Invariant Country). That is, en-US and it's parent culture(s) are not in the list.

   When I use the -UICulture parameter instead, Import-LocalizedData gets the CultureInfo object using Globalization.GetCultureInfo:

   [System.Globalization.CultureInfo]::GetCultureInfo('en-GB')

   In both .NET Framework and .NET Core+, en-US is not included in the parent culture list.

   Therefore, if my current culture is en-GB and I run this command in Windows PowerShell it will successfully find the localization file:

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

   If I use PowerShell 6 or higher (7.3.4 for my testing), then I will instead receive an error because of the change in how .NET is exposing the Parent culture list for the CurrentUICulture.

   In both cases, if use the -UICulture parameter explicitly (with my en-GB culture) then it will fail.

   I think it can be said that:

   • This was a bug in .NET.
   • This is a bug in localization handling in each of the modules consuming Import-LocalizedData.

   However, it can also be said that the bug in .NET has introduced a behaviour change between PowerShell 5.1 and 6+ and I would assert that it is reasonable to fix this problem in the Import-LocalizedData commmand.

   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, restoring the behaviour of the command as it was in 5.1.
4. IzaacJ commented on Apr 13, 2026

   

   Izaac Brånn (IzaacJ)

   on Apr 13, 2026

   Last edited by IzaacJ

   More actions

   There is seemingly other issues as well. I am trying to make our powershell module cross platform (depends on a couple of COM objects), and this statement is working on Windows, but not on macOS.

   $__Session.Config = Import-LocalizedData -BaseDirectory $__Session.Path.Root -FileName 'configurations.psd1'

   The configuration.psd1 is located in the parent directory of the script and $__Session.Path.Root is the parent directory.
   On Windows using Powershell Core 7.6.0 it loads the pds1 as expected.
   On macOS using Powershell Core 7.6.0 if fails with the error Cannot find the PowerShell data file 'configurations.psd1' in directory '/Users/izaac.braann/Sources/our-module/sv-SE', or in any parent culture directories.
Get-Culture renders the same information on both Windows and macOS.

   Windows Pwsh:

   Name                           Value
   ----                           -----
   PSVersion                      7.6.0
   PSEdition                      Core
   GitCommitId                    7.6.0
   OS                             Microsoft Windows 10.0.26200
   Platform                       Win32NT
   PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
   PSRemotingProtocolVersion      2.4
   SerializationVersion           1.1.0.1
   WSManStackVersion              3.0
   --------------------------------
   LCID             Name             DisplayName
   ----             ----             -----------
   1053             sv-SE            Swedish (Sweden)
   

   macOS Pwsh:

   Name                           Value
   ----                           -----
   PSVersion                      7.6.0
   PSEdition                      Core
   GitCommitId                    7.6.0
   OS                             macOS 26.4.1
   Platform                       Unix
   PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
   PSRemotingProtocolVersion      2.4
   SerializationVersion           1.1.0.1
   WSManStackVersion              3.0
   --------------------------------
   LCID             Name             DisplayName
   ----             ----             -----------
   1053             sv-SE            svenska (Sverige)
   

   Very crude view of the related files and paths:

   our-module/
   - scripts/
   -- helper.ps1
   - configuration.psd1
   
5. Ryan Yates (kilasuit)

   added

   WG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issues

   and removed

   WG-Cmdlets-Utility

   on Jul 17, 2026