Documentation guidelines¶
Writing style guide¶
To ensure consistency in tone and language, follow the Google developer documentation style guide when writing the Wagtail documentation.
Formatting recommendations¶
Wagtail’s documentation uses a mixture of Markdown and reStructuredText. We encourage writing documentation in Markdown first, and only reaching for more advanced reStructuredText formatting if there is a compelling reason.
Here are formats we encourage using when writing documentation for Wagtail.
Paragraphs¶
It all starts here. Keep your sentences short, varied in length.
Separate text with an empty line to create a new paragraph.
Latin phrases and abbreviations¶
Try to avoid Latin phrases (such as ergo
or de facto
) and abbreviations (such as i.e.
or e.g.
), and use common English phrases instead. Alternatively, find a simpler way to communicate the concept or idea to the reader. The exception is etc.
which can be used when space is limited.
Examples:
Don’t use this |
Use this instead |
---|---|
e.g. |
for example, such as |
i.e. |
that is |
viz. |
namely |
ergo |
therefore |
Heading levels¶
Use heading levels to create sections, and allow users to link straight to a specific section. Start documents with an # h1
, and proceed with ## h2
and further sub-sections without skipping levels.
# Heading level 1
## Heading level 2
### Heading level 3
Lists¶
Use bullets for unordered lists, numbers when ordered. Prefer dashes -
for bullets. Nest by indenting with 4 spaces.
- Bullet 1
- Bullet 2
- Nested bullet 2
- Bullet 3
1. Numbered list 1
2. Numbered list 2
3. Numbered list 3
Rendered output
Bullet 1
Bullet 2
Nested bullet 2
Bullet 3
Numbered list 1
Numbered list 2
Numbered list 3
Inline styles¶
Use bold and italic sparingly and inline code
when relevant.
Use **bold** and _italic_ sparingly and inline `code` when relevant.
Code blocks¶
Make sure to include the correct language code for syntax highlighting, and to format your code according to our coding guidelines. Frequently used: python
, css
, html
, html+django
, javascript
, sh
.
```python
INSTALLED_APPS = [
...
"wagtail",
...
]
```
Rendered output
INSTALLED_APPS = [
...
"wagtail",
...
]
When using console (terminal) code blocks¶
Note
$
or >
prompts are not needed, this makes it harder to copy and paste the lines and can be difficult to consistently add in every single code snippet.
Use sh
as it has better support for comment and code syntax highlighting in MyST’s parser, plus is more compatible with GitHub and VSCode.
```sh
# some comment
some command
```
Rendered output
# some comment
some command
Use doscon
(DOS Console) only if explicitly calling out Windows commands alongside their bash equivalent.
```doscon
# some comment
some command
```
Rendered output
# some comment
some command
Links¶
Links are fundamental in documentation. Use internal links to tie your content to other docs, and external links as needed. Pick relevant text for links, so readers know where they will land.
Don’t rely on links over code
, as they are impossible to spot.
An [external link](https://wwww.example.com).
An [internal link to another document](/reference/contrib/legacy_richtext).
An auto generated link label to a page [](/getting_started/tutorial).
A [link to a reference](register_reports_menu_item).
Rendered output
An external link. An internal link to another document. An auto generated link label to a page Your first Wagtail site. A link to a reference.
Reference links¶
Reference links (links to a target within a page) rely on the page having a reference created. Each reference must have a unique name and should use the lower_snake_case
format. A reference can be added as follows:
(my_awesome_section)=
##### Some awesome section title
...
The reference can be linked to, with an optional label, using the Markdown link syntax as follows:
- Auto generated label (preferred) [](my_awesome_section)
- [label for section](my_awesome_section)
Rendered output
Some awesome section title¶
…
Auto generated label (preferred) Some awesome section title
You can read more about other methods of linking to, and creating references in the MyST parser docs section on Targets and cross-referencing.
Intersphinx links (external docs)¶
Due to the large amount of documentation links to Django’s Sphinx documentation, we have added the integration with this via intersphinx references.
You can select widgets from [Django's form widgets](inv:django#ref/forms/widgets)
This parameter allows you to specify a :doc:`Django form widget <django:ref/forms/widgets>` to use instead of the default widget for this field type.
There is no support for id (hash) refs on pages at this time, so these will need to be written out as full URLs, remember to use the stable
URL and not a specific version. In some cases you may be able to reference the name of the hash directly though.
<!-- #django-template-context-processors-i18n does not work, so a full URL will be needed -->
[django.template.context_processors.i18n](https://docs.djangoproject.com/en/stable/ref/templates/api/#django-template-context-processors-i18n)
<!-- #meta-and-multi-table-inheritance does work as a direct name reference -->
[multi-table inheritance](inv:django#meta-and-multi-table-inheritance)
Note and warning call-outs¶
Use notes and warnings sparingly, as they rely on reStructuredText syntax which is more complicated for future editors.
```{note}
Notes can provide complementary information.
```
```{warning}
Warnings can be scary.
```
Rendered output
Note
Notes can provide complementary information.
Warning
Warnings can be scary.
These call-outs do not support titles, so be careful not to include them, titles will just be moved to the body of the call-out.
```{note} Title's here will not work correctly
Notes can provide complementary information.
```
Images¶
Images are hard to keep up-to-date as documentation evolves, but can be worthwhile nonetheless. Here are guidelines when adding images:
All images should have meaningful alt text unless they are decorative.
Images are served as-is – pick the correct format, and losslessly compress all images.
Use absolute paths for image files so they are more portable.
![The TableBlock component in StreamField, with row header, column header, caption fields - and then the editable table](/_static/images/screen40_table_block.png)
Rendered output
Autodoc¶
With its autodoc feature, Sphinx supports writing documentation in Python docstrings for subsequent integration in the project’s documentation pages. This is a very powerful feature that we highly recommend using to document Wagtail’s APIs.
```{eval-rst}
.. module:: wagtail.coreutils
.. autofunction:: cautious_slugify
```
Rendered output
- wagtail.coreutils.cautious_slugify(value)¶
Convert a string to ASCII exactly as Django’s slugify does, with the exception that any non-ASCII alphanumeric characters (that cannot be ASCIIfied under Unicode normalisation) are escaped into codes like ‘u0421’ instead of being deleted entirely.
This ensures that the result of slugifying (for example - Cyrillic) text will not be an empty string, and can thus be safely used as an identifier (albeit not a human-readable one).
Tables¶
Only use tables when needed, using the GitHub Flavored Markdown table syntax.
| Browser | Device/OS |
| ------------- | --------- |
| Stock browser | Android |
| IE | Desktop |
| Safari | Windows |
Rendered output
Browser |
Device/OS |
---|---|
Stock browser |
Android |
IE |
Desktop |
Safari |
Windows |
Tables of contents¶
toctree
and contents
can be used as reStructuredText directives.
```{toctree}
---
maxdepth: 2
titlesonly:
---
getting_started/index
topics/index
```
```{contents}
---
local:
depth: 1
---
```
Version added, changed, deprecations¶
Sphinx offers release-metadata directives to generate this information consistently. Use as appropriate.
```{versionadded} 2.15
```
```{versionchanged} 2.15
```
Rendered output
Added in version 2.15.
Changed in version 2.15.
Progressive disclosure¶
We can add supplementary information in documentation with the HTML <details>
element. This relies on HTML syntax, which can be hard to author consistently, so keep this type of formatting to a minimum.
<details>
<summary>Supplementary information</summary>
This will be visible when expanding the content.
</details>
Example:
Supplementary information
This will be visible when expanding the content.
Formatting to avoid¶
There is some formatting in the documentation which is technically supported, but we recommend avoiding unless there is a clear necessity.
Call-outs¶
We only use {note}
and {warning}
call-outs. Avoid {admonition}
, {important}
, {topic}
, and {tip}
. If you find one of these, please replace it with {note}
.
Glossary¶
Sphinx glossaries (.. glossary::
) generate definition lists. Use plain bullet or number lists instead, or sections with headings, or a table.
Figure¶
reStructuredText figures (.. figure::
) only offer very marginal improvements over vanilla images. If your figure has a caption, add it as an italicised paragraph underneath the image.
Other reStructuredText syntax and Sphinx directives¶
We generally want to favour Markdown over reStructuredText, to make it as simple as possible for newcomers to make documentation contributions to Wagtail. Always prefer Markdown, unless the document’s formatting highly depends on reStructuredText syntax.
If you want to use a specific Sphinx directive, consult with core contributors to see whether its usage is justified, and document its expected usage on this page.
Arbitrary HTML¶
While our documentation tooling offers some support for embedding arbitrary HTML, this is frowned upon. Only do so if there is a necessity, and if the formatting is unlikely to need updates.
Comments¶
Avoid documentation source comments in committed documentation.