Redigera

Get started contributing to PowerShell documentation

  • Artikel

This article is an overview of how to get started as a contributor to the PowerShell documentation.

PowerShell-Docs structure

The PowerShell-Docs repository is divided into two groups of content: reference and conceptual.

Reference content

The reference content is the PowerShell cmdlet reference for the cmdlets that ship in PowerShell. The cmdlet reference is collected in versioned folders (like 5.1, 7.0, and 7.2), which contain reference for the modules that ship with PowerShell. This content is also used to create the help information displayed by the Get-Help cmdlet.

Conceptual content

The conceptual documentation isn't organized by version. All articles are displayed for every version of PowerShell.

Note

Anytime a conceptual article is added, removed, or renamed, the TOC must be updated and deleted or renamed files must be redirected.

Creating new articles

A GitHub issue must be created for any new document you want to contribute. Check for existing issues to make sure you're not duplicating efforts. Assigned issues are considered to be in progress. If you wish to collaborate on an issue, contact the person assigned to the issue.

Similar to the PowerShell RFC process, create an issue before you write the content. The issue ensures you don't waste time and effort on work that gets rejected by the PowerShell-Docs team. The issue allows us to consult with you on the scope of the content and where it fits in the PowerShell documentation. All articles must be included in the Table of Contents (TOC). The proposed TOC location should be included in the issue discussion.

Note

The TOC for reference content is autogenerated by the publishing system. You don't have to update the TOC.

Updating existing articles

Where applicable, cmdlet reference articles are duplicated across all versions of PowerShell maintained in this repository. When reporting an issue about a cmdlet reference or an About_ article, list the versions of the article that have the problem.

Apply the appropriate change to each version of the file.

Localized content

The PowerShell documentation is written in English and translated into 17 other languages. The English content is stored in the GitHub repository named MicrosoftDocs/PowerShell-Docs. Issues found in the translated content should be submitted to the English repository.

All translations start from the English content first. We use both human and machine translation.

Translation method Languages
Human translation de-DE, es-ES, fr-FR, it-IT, ja-JP, ko-KR, pt-BR, ru-RU, zh-CN, zh-TW
Machine translation cs-CZ, hu-HU, nl-NL, pl-PL, pt-PT, sv-SE, tr-TR

The content translated by machine translation may not always result in correct word choices and grammar. If you find an error in translation for any language, rather than in the technical details of the article, open an issue explaining why you think the translation is wrong.

Some translation issues can be fixed by changing the English source files. However, some issues may require updates to our internal translation system. For those cases, we must submit the issue to our internal localization team for review and response.

Next steps

There are two common ways of submitting changes in GitHub. Both methods are described in the central Contributor's Guide:

  1. You can make quick edits to existing documents in the GitHub web interface.
  2. Use the full GitHub workflow for adding new articles, updating multiple files, or other large changes.

Before starting any changes, you should create a fork of the PowerShell-Docs repository. The changes should be made in a working branch in you copy of the PowerShell-Docs. If you're using the quick edit method in GitHub, these steps are handled for you. If you're using the full GitHub workflow, you must be set up to work locally.

Both methods end with the creation of a Pull Request (PR). See Submitting a pull request for more information and best practices.