René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Import-LocalizedData implicit Localization fallback","articleBody":"### Summary of the new feature / enhancement\n\n`Import-LocalizedData` should implement a default culture fallback when `-UICulture` is not specified to simulate the functionality of the command in Windows PowerShell.\r\n\r\nPR: #19896\n\n### Proposed technical implementation details (optional)\n\n`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.\r\n\r\nFor example, in PowerShell 7, attempting to import the SmbShare module will result in an error:\r\n\r\n```powershell\r\nPS\u003e Import-Module SmbShare\r\nImport-LocalizedData: Cannot find the PowerShell data file 'SmbLocalization.psd1' in directory\r\n'C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\SmbShare\\en-GB', or in any parent culture directories.\r\n```\r\n\r\nOr more directly:\r\n\r\n```powershell\r\nPush-Location C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\smbshare\r\nImport-LocalizedData -BindingVariable _system_translations -fileName SmbLocalization.psd1 -ea stop\r\n$_system_translations\r\nPop-Location\r\n```\r\n\r\nThis error is not present in Windows PowerShell.\r\n\r\nThis error is caused by a difference in how .NET Core+ and .NET Framework handle the `CurrentUICulture` static property\r\nIn .NET Core and higher, the values in the parent list are arguably correct:\r\n\r\n```powershell\r\n$culture = [System.Globalization.CultureInfo]::CurrentUICulture\r\ndo { $culture.Name; $culture = $culture.Parent } while ($culture.Name)\r\n```\r\n\r\nFor my culture of en-GB results in the following list:\r\n\r\n```\r\nen-GB\r\nen\r\n# \u003cInvariant\u003e\r\n```\r\n\r\nHowever, 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` .\r\n\r\nThe result in Windows PowerShell is shown below.\r\n\r\n```powershell\r\nPS\u003e $culture = [System.Globalization.CultureInfo]::CurrentUICulture\r\nPS\u003e do { $culture.Name; $culture = $culture.Parent } while ($culture.Name)\r\nen-GB\r\nen\r\nen-US\r\nen\r\n# \u003cInvariant\u003e\r\n```\r\n\r\nA 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.\r\n\r\nFor `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.\r\n\r\n`Import-LocalizedData` is used by a fairly broad set of modules in the `system32` directory, including:\r\n\r\n```\r\nAppx\r\nAssignedAccess\r\nBitLocker\r\nDhcpServer\r\nFailoverClusters\r\nHgsClient\r\nIpamServer\r\nIscsiTarget\r\nMicrosoft.PowerShell.Archive\r\nMicrosoft.PowerShell.ODataUtils\r\nMsDtc\r\nNetworkSwitchManager\r\nRemoteDesktop\r\nServerManager\r\nSmbShare\r\nStorageQoS\r\nStorageReplica\r\n```\r\n\r\nI 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.","author":{"url":"https://github.com/chrisdent-de","@type":"Person","name":"chrisdent-de"},"datePublished":"2023-07-11T08:19:03.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/19923/PowerShell/issues/19923"}