typo: Whatif -> WhatIf (#3961)

Author: nschonni

developer/cmdlet/required-development-guidelines.md

@@ -116,7 +116,7 @@ To make these calls the cmdlet must specify that it supports confirmation reques
 > [!NOTE]
 > If the Cmdlet attribute of the cmdlet class indicates that the cmdlet supports calls to the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method, and the cmdlet fails to make the call to the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method, the user could modify the system unexpectedly.
 
-Use the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method for any system modification. A user preference and the `Whatif` parameter control the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method. In contrast, the [System.Management.Automation.Cmdlet.ShouldContinue*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldContinue) call performs an additional check for potentially dangerous modifications. This method is not controlled by any user preference or the `Whatif` parameter. If your cmdlet calls the [System.Management.Automation.Cmdlet.ShouldContinue*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldContinue) method, it should have a `Force` parameter that bypasses the calls to these two methods and that proceeds with the operation. This is important because it allows your cmdlet to be used in non-interactive scripts and hosts.
+Use the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method for any system modification. A user preference and the `WhatIf` parameter control the [System.Management.Automation.Cmdlet.ShouldProcess*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldProcess) method. In contrast, the [System.Management.Automation.Cmdlet.ShouldContinue*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldContinue) call performs an additional check for potentially dangerous modifications. This method is not controlled by any user preference or the `WhatIf` parameter. If your cmdlet calls the [System.Management.Automation.Cmdlet.ShouldContinue*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldContinue) method, it should have a `Force` parameter that bypasses the calls to these two methods and that proceeds with the operation. This is important because it allows your cmdlet to be used in non-interactive scripts and hosts.
 
 If your cmdlets support these calls, the user can determine whether the action should actually be performed. For example, the [Stop-Process](/powershell/module/microsoft.powershell.management/stop-process) cmdlet calls the [System.Management.Automation.Cmdlet.ShouldContinue*](/dotnet/api/System.Management.Automation.Cmdlet.ShouldContinue) method before it stops a set of critical processes, including the System, Winlogon, and Spoolsrv processes.
 

gallery/how-to/publishing-packages/publishing-a-package.md

@@ -131,16 +131,16 @@ RequiredVersion.
 Most of the other options in the command line should be in the manifest data for the item you are
 publishing, so you should not need to specify them in the command.
 
-To avoid errors, it is strongly recommended that you try the commands using -Whatif -Verbose,
+To avoid errors, it is strongly recommended that you try the commands using -WhatIf -Verbose,
 before publishing. This will save considerable time, since every time you publish to the PowerShell
 Gallery, you must update the version number in the manifest section of the item.
 
 Examples would be:
 
-* `Publish-Module -Path ".\MyModule" -NugetAPIKey "GUID" -Whatif -Verbose`
-* `Publish-Script -Path ".\MyScriptFile.PS1" -NugetAPIKey "GUID" -Whatif -Verbose`
+* `Publish-Module -Path ".\MyModule" -NugetAPIKey "GUID" -WhatIf -Verbose`
+* `Publish-Script -Path ".\MyScriptFile.PS1" -NugetAPIKey "GUID" -WhatIf -Verbose`
 
-Review the output carefully, and if you see no errors or warnings, repeat the command without -Whatif.
+Review the output carefully, and if you see no errors or warnings, repeat the command without -WhatIf.
 
 All items that are published to the PowerShell Gallery will be scanned for viruses, and will be
 analyzed using the PowerShell Script Analyzer. Any issues that arise at that time will be sent back

reference/3.0/Microsoft.PowerShell.Security/Set-Acl.md

@@ -100,10 +100,10 @@ The **Force** parameter gets hidden files, which would otherwise be excluded.
 
 The pipeline operator (|) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the **AclObject** parameter to all of the files in the pipeline.
 
-In practice, it is best to use the **Whatif** parameter with all `Set-Acl` commands that can affect more than one item.
+In practice, it is best to use the **WhatIf** parameter with all `Set-Acl` commands that can affect more than one item.
 In this case, the second command in the pipeline would be "`Set-Acl -AclObject $NewAcl -WhatIf`".
 This command lists the files that would be affected by the command.
-After reviewing the result, you can run the command again without the **Whatif** parameter.
+After reviewing the result, you can run the command again without the **WhatIf** parameter.
 
 ## PARAMETERS
 

reference/4.0/Microsoft.PowerShell.Security/Set-Acl.md

@@ -93,10 +93,10 @@ The **Force** parameter gets hidden files, which would otherwise be excluded.
 
 The pipeline operator (|) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the **AclObject** parameter to all of the files in the pipeline.
 
-In practice, it is best to use the **Whatif** parameter with all `Set-Acl` commands that can affect more than one item.
+In practice, it is best to use the **WhatIf** parameter with all `Set-Acl` commands that can affect more than one item.
 In this case, the second command in the pipeline would be "`Set-Acl -AclObject $NewAcl -WhatIf`".
 This command lists the files that would be affected by the command.
-After reviewing the result, you can run the command again without the **Whatif** parameter.
+After reviewing the result, you can run the command again without the **WhatIf** parameter.
 
 ## PARAMETERS
 

reference/5.0/Microsoft.PowerShell.Security/Set-Acl.md

@@ -99,10 +99,10 @@ The **Force** parameter gets hidden files, which would otherwise be excluded.
 
 The pipeline operator (|) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the **AclObject** parameter to all of the files in the pipeline.
 
-In practice, it is best to use the **Whatif** parameter with all `Set-Acl` commands that can affect more than one item.
+In practice, it is best to use the **WhatIf** parameter with all `Set-Acl` commands that can affect more than one item.
 In this case, the second command in the pipeline would be "`Set-Acl -AclObject $NewAcl -WhatIf`".
 This command lists the files that would be affected by the command.
-After reviewing the result, you can run the command again without the **Whatif** parameter.
+After reviewing the result, you can run the command again without the **WhatIf** parameter.
 
 ## PARAMETERS
 

reference/5.1/Microsoft.PowerShell.Security/Set-Acl.md

@@ -94,10 +94,10 @@ The **Force** parameter gets hidden files, which would otherwise be excluded.
 
 The pipeline operator (|) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the **AclObject** parameter to all of the files in the pipeline.
 
-In practice, it is best to use the **Whatif** parameter with all `Set-Acl` commands that can affect more than one item.
+In practice, it is best to use the **WhatIf** parameter with all `Set-Acl` commands that can affect more than one item.
 In this case, the second command in the pipeline would be "`Set-Acl -AclObject $NewAcl -WhatIf`".
 This command lists the files that would be affected by the command.
-After reviewing the result, you can run the command again without the **Whatif** parameter.
+After reviewing the result, you can run the command again without the **WhatIf** parameter.
 
 ## PARAMETERS
 

reference/6/Microsoft.PowerShell.Security/Set-Acl.md

@@ -98,10 +98,10 @@ The **Force** parameter gets hidden files, which would otherwise be excluded.
 
 The pipeline operator (|) sends the objects representing the retrieved files to the `Set-Acl` cmdlet, which applies the security descriptor in the **AclObject** parameter to all of the files in the pipeline.
 
-In practice, it is best to use the **Whatif** parameter with all `Set-Acl` commands that can affect more than one item.
+In practice, it is best to use the **WhatIf** parameter with all `Set-Acl` commands that can affect more than one item.
 In this case, the second command in the pipeline would be "`Set-Acl -AclObject $NewAcl -WhatIf`".
 This command lists the files that would be affected by the command.
-After reviewing the result, you can run the command again without the **Whatif** parameter.
+After reviewing the result, you can run the command again without the **WhatIf** parameter.
 
 ## PARAMETERS