jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-25 02:17:36 -05:00
Code Issues Projects Releases Wiki Activity

Update content-style-guide.md

Browse Source
This commit is contained in:
hubwriter
2022-04-25 09:23:17 +01:00
committed by GitHub
parent 935310f0da
commit c5179ac3ee
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
contributing/content-style-guide.md
View File

@@ -410,7 +410,7 @@ For more information, see "[Using SHAs](https://docs.github.com/en/actions/learn
### GitHub Codespaces
Always use "GitHub Codespaces" (`{% data variables.product.prodname_github_codespaces %}`) as the product name, not just "Codespaces". This helps to avoid confusion with "codespaces" (lowercase c), which refers to instances of remote coding workspaces created with GitHub Codespaces.
For the first mention in the body text of an article, use "GitHub Codespaces" (`{% data variables.product.prodname_github_codespaces %}`) as the product name, not just "Codespaces". After the first use, and in headings, you can use just "Codespaces" `{% data variables.product.prodname_github_codespaces %}`, but if a passage refers to the product and instances of codespaces in close proximity, always use `{% data variables.product.prodname_github_codespaces %}` for the product. This helps to avoid confusion between the product and "codespaces" (lowercase c), which refers to instances of remote coding workspaces created with GitHub Codespaces.
Always use "dev container" (or, where clarification is needed, its longer form "development container") and not "devcontainer" (one word), except in file/path names. The single word could form could be considered a brand, which we want to avoid, and we also want to be consistent with the two-word form used in [the Visual Studio Code documentation](https://code.visualstudio.com/docs/remote/create-dev-container#_path-to-creating-a-dev-container).