Spec-Zone.ru › Wagtail

Рекомендации по документации

  • Рекомендации по форматированию
  • Форматирование, которого следует избегать

Рекомендации по форматированию

Документация Wagtail использует смесь Markdown и reStructuredText. Рекомендуется сначала написать документацию в формате Markdown, и переходить к более сложным форматам reStructuredText только в случае необходимости.

Ниже приведены форматы, которые рекомендуется использовать при написании документации для Wagtail.

Абзацы

Всё начинается здесь. Держите предложения короткими и разнообразными по длине.

Разделяйте текст пустой строкой, чтобы создать новый абзац.

Уровни заголовков

Используйте уровни заголовков для создания разделов и позволяйте пользователям переходить непосредственно к определённому разделу. Начинайте документы с # h1, и продолжайте с ## h2 и последующими подразделами, не пропуская уровни.

# Heading level 1

## Heading level 2

### Heading level 3

Списки

Используйте точки для неупорядоченных списков и цифры для упорядоченных. Предпочтительнее использовать тире - для маркеров списка. Вложенные списки создаются с помощью отступов в 4 пробела.

-   Bullet 1
-   Bullet 2
    -   Nested bullet 2
-   Bullet 3

1. Numbered list 1
2. Numbered list 2
3. Numbered list 3
Результат рендеринга
  • Пункт 1
  • Пункт 2

    • Вложенный пункт 2
  • Пункт 3
  1. Упорядоченный список 1
  2. Упорядоченный список 2
  3. Упорядоченный список 3

Стили встраиваемых элементов

Используйте жирный шрифт и курсив экономно, встраивая code при необходимости.

Use **bold** and _italic_ sparingly, inline `code` when relevant.

Блоки кода

Убедитесь, что вы указали правильный код языка для подсветки синтаксиса и отформатировали код в соответствии с нашими рекомендациями по кодированию. Часто используемые: python, css, html, html+django, javascript, sh.

```python
INSTALLED_APPS = [
    ...
    "wagtail",
    ...
]
```
Результат рендеринга
INSTALLED_APPS = [
    ...
    "wagtail",
    ...
]

Использование блоков кода консоли (терминала)

Примечание

$ или > приглашения не нужны, это затрудняет копирование и вставку строк и может быть сложно последовательно добавлять в каждый фрагмент кода.

Используйте sh , так как он имеет лучшую поддержку комментариев и подсветки синтаксиса кода в анализаторе MyST, а также более совместим с GitHub и VSCode.

```sh
# some comment
some command
```
Результат рендеринга
# some comment
some command

Используйте doscon (консоль DOS) только в том случае, если явно указываете команды Windows наряду с их эквивалентами bash.

```doscon
# some comment
some command
```
Результат рендеринга
# some comment
some command

Ссылки

Ссылки являются основополагающими в документации. Используйте внутренние ссылки для связи вашего содержимого с другими документами и внешние ссылки по мере необходимости. Выбирайте релевантный текст для ссылок, чтобы читатели понимали, куда они попадут.

Не полагайтесь на links over code, так как их трудно заметить.

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).
Результат рендеринга

Внешняя ссылка external link. Внутренняя ссылка на другой документ внутренняя ссылка на другой документ. Автоматически сгенерированная метка ссылки на страницу Ваш первый сайт Wagtail. Ссылка на справочник ссылка на справочник.

Ссылки на справочник

Ссылки на справочник (ссылки на целевой объект на странице) зависят от того, есть ли на странице созданный справочник. Каждый справочник должен иметь уникальное имя и использовать формат lower_snake_case. Справочник можно добавить следующим образом:

(my_awesome_section)=

##### Some awesome section title

...

К справочнику можно получить доступ с помощью синтаксиса ссылки Markdown, с необязательной меткой:

-   Auto generated label (preferred) [](my_awesome_section)
-   [label for section](my_awesome_section)
Результат рендеринга
Some awesome section title

…

  • Автоматически сгенерированная метка (предпочтительный вариант) Some awesome section title
  • Метка раздела

Дополнительную информацию об других методах связи и создания ссылок можно найти в разделе документации MyST по Целям и перекрестным ссылкам.

Примечания и предупреждения

Используйте заметки и предупреждения экономно, так как они основаны на синтаксисе reStructuredText, что более сложно для будущих редакторов.

```{note}
Notes can provide complementary information.
```

```{warning}
Warnings can be scary.
```
Результат рендеринга

Примечание

Примечания могут предоставить дополнительную информацию.

Предупреждение

Предупреждения могут быть пугающими.

Эти выноски не поддерживают заголовки, поэтому будьте осторожны, чтобы не включать их, так как заголовки просто будут перенесены в тело выноски.

```{note} Title's here will not work correctly
Notes can provide complementary information.
```

Изображения

Изображения трудно поддерживать в актуальном состоянии по мере развития документации, но они могут быть полезными. Вот рекомендации по добавлению изображений:

  • Все изображения должны иметь осмысленный альтернативный текст, если они не декоративные.
  • Изображения передаются как есть — выберите правильный формат и сжатие без потерь для всех изображений.
  • Используйте абсолютные пути к файлам изображений для большей портативности.
![The TableBlock component in StreamField, with row header, column header, caption fields - and then the editable table](/_static/images/screen40_table_block.png)
Результат рендеринга

The TableBlock component in StreamField, with row header, column header, caption fields - and then the editable table

Autodoc

С помощью функции autodoc Sphinx поддерживает запись документации в строках документации Python для последующей интеграции на страницы документации проекта. Это очень мощная функция, которую мы настоятельно рекомендуем использовать для документирования API Wagtail.

```{eval-rst}
.. module:: wagtail.coreutils

.. autofunction:: cautious_slugify
```
Результат рендеринга

Таблицы

Используйте таблицы только при необходимости, используя синтаксис таблиц GitHub Flavored Markdown.

| Browser       | Device/OS |
| ------------- | --------- |
| Stock browser | Android   |
| IE            | Desktop   |
| Safari        | Windows   |
Результат рендеринга

Браузер

Устройство/ОС

Стандартный браузер

Android

IE

Рабочий стол

Safari

Windows

Оглавления

toctree и contents могут быть использованы как директивы reStructuredText.

```{toctree}
---
maxdepth: 2
titlesonly:
---
getting_started/index
topics/index
```

```{contents}
---
local:
depth: 1
---
```

Добавление, изменение, устаревание версий

Sphinx предлагает директивы метаданных выпуска для генерации этой информации последовательно. Используйте их по мере необходимости.

```{versionadded} 2.15
```

```{versionchanged} 2.15
```
Результат рендеринга

Новая в версии 2.15.

Изменено в версии 2.15.

Постепенное раскрытие

Мы можем добавить дополнительную информацию в документацию с помощью HTML-элемента <details>. Это основано на синтаксисе HTML, который может быть трудно создавать последовательно, поэтому старайтесь минимизировать использование этого типа форматирования.

<details>
    <summary>Supplementary information</summary>

    This will be visible when expanding the content.
</details>

Пример:

Дополнительная информация

Это будет видно при раскрытии содержимого.

© 2014-present Torchbox Ltd and individual contributors.
All rights are reserved.
Licensed under the BSD License.
https://docs.wagtail.org/en/stable/contributing/documentation_guidelines.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API