Repository navigation
Add Import-LocalizedStringData cmdlet #5390
Description
The steps to reproduce is difficult but we have wasted multiple man days chasing issues with Import-Module/Import-LocalizedData with servers running En-GB culture. We've seen it with smbshare and powershell.archive. An example of the issue is captured in #4180. While that bug was closed and the user told to file a bug in the Archive specific location the ultimate issue is with Import-LocalizedData or Import-Module. If a language specific localization is not found it MUST NOT fail to load the module.
Activity
SteveL-MSFT commentedon Nov 9, 2017
The problem is that
import-moduledoesn’t know why the psm1 script failed, only that an error was thrown. The issue is in the module. I’ll submit a PR to fix Archive modulesdecker commentedon Nov 9, 2017
We've also seen this in the SmbShare. I'm sure we saw it with another module but it was a while ago and I'm having trouble finding. This has moved from an anomaly to a recurring problem. How is this not a Import-LocalizedData bug? Why is it throwing instead of warning?
sdecker commentedon Nov 9, 2017
Another way to put this. Adding a work around to the Archive module is fixing the symptom not the disease.
Jaykul commentedon Nov 9, 2017
I gotta agree with sdecker on this, Steve Lee (@SteveL-MSFT) -- if
Import-LocalizedDataever throws because the user is in a culture that the author hasn't thought of, that's makesImport-LocalizedDataHARMFUL ...The design of the module is that it has the fallback strings in a data section, and it's trying to call
Import-LocalizedDatato load better strings if they're available. Is that not the wayImport-LocalizedDataworks?[-]Import-Module/Import-LocalizedData must NEVER cause module import to load if culture not found[/-][+]Import-LocalizedData must NEVER error if culture not found[/+]SteveL-MSFT commentedon Nov 9, 2017
I've updated the title to focus on
Import-LocalizedData. I'm open to discussing having some fallback capability toImport-LocalizedData.Jaykul commentedon Nov 9, 2017
As I see it, the problem is two things:
If a module calls
Import-LocalizedDatawithout suppressing the inevitable error, that doesn't techincally stop the module from being imported and used. As a result, of TWENTY THREE modules in $PSHome\Modules which use Import-LocalizedData (on my Windows 10, PS5.1 system) only two use-ErrorActionto suppress the errors. I don't know how many of these modules are actually localized, but if there's a betting pool, I'm taking ZERO.This is a problem because if another module or script specifies a dependency on any of these modules (e.g. via
RequiredModulesin the manifest or via#requires -moduleor just by callingImport-Module -ErrorAction Stop... then those modules or scripts break whenever they are used in a locale that isn't explicitly localized.The only reason I can think of that this hasn't come up before is that module authors basically never document their dependency on "in the box" modules, and nobody but Microsoft bothers to localize at all...
If I just use a cmdlet from a module with a localization problem, you'll see the localization error from the autoloading, but the cmdlet will run and produce results with no problems. It's only when I put the module in my RequiredModules or use a
#requiresthat it causes a terminating error.1 remaining item
Jaykul commentedon Nov 9, 2017
I should note that many of these modules (e.g. Appx, BitLocker, etc) don't even have the fallback data section in the file -- sdecker has been lucky so far, Archive and SmbShare module do have default values in a data section, so this localization error isn't fatal to the module except when the module import happens when
ErrorActionPreferenceis set to Stop. For these other modules like Appx and Bitlocker, the Import-LocalizedData failure will result in further errors whenever anything tries to access that LocalizedData.Clearly Microsoft isn't setting a good example for how to localize modules, so there should be no surprise that nobody else is doing it.
From my perspective, the most immediate change that would help would be for the help to be changed to highlight the fact that when the localization files are missing it will produce an error, and that the caller really must decide how to handle that and do something.
A single useful example should show the right way to do it, combining the default data in Example 5 and error handling! Perhaps the example could turn the error into a warning that English messages will be used instead...
Jaykul commentedon Nov 10, 2017
If you want my 2c on a better long-term design for Import-LocalizedData:
Make a Import-LocalizedStringData which:
SupportedCommandparameter[dictionary[string,string]]rather than a hashtableString dictionaries are clearly the main use case for localization, the other features of Import-LocalizedData aren't generally used for translation, and they make it more complicated to use for it's primary purpose: almost every use of Import-LocalizedData has an internal ConvertFrom-StringData which would be unnecessary with Import-LocalizedStringData.
DefaultDatastring dictionary parameterThis would ensure that the command never needs to produce an error -- it can fall back to the DefaultData -- it would also allow partial localizations to use the default strings for untranslated content.
This would allow knowledgeable users to easily produce translations for themselves, without waiting for Microsoft to get around to supporting UK English 😉
FriedrichWeinmann commentedon Nov 10, 2017
Totally agree. This has been awkward for a long time and caused plenty of issues so far. Great write-up for a solution.
SteveL-MSFT commentedon Nov 10, 2017
Joel Bennett (@Jaykul) I like your proposal and something we can look into for 6.1.0. If we go that route, then we wouldn't make any changes to Import-LocalizedData.
Jaykul commentedon Nov 10, 2017
Agreed Steve Lee (@SteveL-MSFT), given the varied uses of
Import-LocalizedDatalike mine for non-localization, and my count of the modules in$PSHomethat wouldn't work even if you made it warn instead of error -- I'd be reluctant to change it much -- especially to suppress an error which can already be suppressed with-ErrorActionFocus on improving the documentation, and on fixing whatever testing process is allowing you to release "localized" modules that crash on anything other than en-US -- and of course, on fixing the actual modules. For now, I'm at the point where it's clearly problematic for us to add a dependency on any module that's localized.
We currently work around the Archive module bug like this:
Although we could, arguably, use
$PSDefaultParameterValuesto force en-US instead (which might work for some of these other modules) ...[-]Import-LocalizedData must NEVER error if culture not found[/-][+]Add Import-LocalizedStringData cmdlet[/+]microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.