Now that at least _some_ of the custom error messages for parameter validation attributes support custom error messages - see #3745, it should be possible to support _localization_ of these error messages - currently, only literal strings are supported.
Without this ability, localized scripts are effectively prevented from using such validation attributes.
What currently works:
function foo {
param(
[ValidatePattern('o', ErrorMessage = 'Must have an "o".')]
$bar
)
$bar
}
foo -bar baz
This yields:
foo : Cannot validate argument on parameter 'bar'. Must have an "o".
What support for localization _might_ look like (not sure about feasibility; solely based on noticing that some attributes accept _script blocks_):
$stringTable = DATA {
@{
msg = 'Must have an "o".'
}
}
function foo {
param(
[ValidatePattern('o', ErrorMessage = { $stringTable.msg })]
$bar
)
$bar
}
foo -bar baz
PowerShell Core v6.0.0-beta (v6.0.0-beta.1)
Related https://github.com/PowerShell/PowerShell/pull/2728#discussion_r91215074
if we go that route, we need localization support similar to HelpMessageBaseName and HelpMessageResourceId in ParameterAttribute
Are HelpMessageBaseName and HelpMessageResourceId currently working?
Still waiting for this. Come on, Microsoft, your're a global company.
@wbpluto It is an open source project so you can pull PR.
@iSazonov, I think @wbpluto's concern is localization support _in general_, which requires a concerted, sustained effort, not just individual user contributions - see #666
@mklement0 I only point that everybody can contribute and do not wait.
For the issue a solution was mentioned in https://github.com/PowerShell/PowerShell/issues/3765#issuecomment-301155358
Thanks, @iSazonov - coming back here I'd forgotten that this issue is about enabling localization of a user-supplied message, not about localizing PowerShell's own messages (which is what #666 is about).