Latest Posts

Changes in Documentation Rules

Revision Differences of Revision 10

[TOC] ¶

## Introduction ¶

Our [lua documentation](https://www.widelands.org/documentation/index.html) is build with the [Sphinx-doc Documentation creator](https://www.sphinx-doc.org/en/master/index.html). You might have noticed that the documentation has some chapters containing the word "python". This is due Sphinx-doc is mainly used to document python projects, but there is no Lua documentation creator out there so we use Sphinx-doc with some difficulties. This article covers how it works, some styling rules and some examples for easy copy and paste. ¶

## Build the documentation locally ¶

We encourage to build the documentation locally when you want to work on the documentation and check the made changes locally before proposing them. ¶

The prerequisites for building the documentation locally are: ¶

* python, at least version 3.6 ¶
* [sphinx](https://www.sphinx-doc.org/en/master/usage/installation.html) ¶
* the source code of widelands, see [[ DownloadPage/#development-version | Development version]] ¶

To build the documentation see the file README in the subfolder _"doc/sphinx"_ of the widelands source code. ¶

Locally created documentation looks different (does not have the same style) as on the homepage. ¶

## extract_rst.py ¶

This script gathers [[ Documentation Rules/#rst-comments | RST-Comments ]] from different locations and stores them as files in _"doc/sphinx/source"_. It creates/adds also some entries to the documentation tocs. ¶

TODO: When to modify this script (new files, ....) ¶

## RST Comments ¶

RST stands for _restructered text_, a markup language. Depending on the file type the comments are for files of type C++ ¶

~~~~ ¶
/* RST ¶
Every ¶
line ¶
will be an RST comment until comment end ¶
*/ ¶
~~~~ ¶
Everything between `/* RST` and `*/` will be extracted by extract_rst.py and added to a corresponding file. ¶

For files of type Lua: ¶

~~~~ ¶
-- RST ¶
-- This is ¶
-- a block of ¶
-- RST comment ¶
-- ¶

-- This comment does not belong to the RST comment (one empty line between comment blocks) ¶
~~~~ ¶
Every comment block starting with `-- RST` will be extracted by extract_rst.py and added to a corresponding file. ¶

### Restructered Text Primer ¶

If you are looking at the our documentation, e.g. [wl.game](/documentation/autogen_wl_game) you will find a link called _"Show Source"_ in the left sidebar. Clicking this link will show you the restructered text markup which cshoverws the [[ Documentation Rules/#rst-comments | RST- Comments ]], of course without the comment signmarkers (`/* RST` .. `/*`, `-- RST`... `--`). Comparing this page with the rendered content will give you a feeling for _restrucetred text_ . ¶

The following paragraphs points out some typical failures when using restructered text for widelands. ¶

For a more detailed description of the markup of restructered text see: [Sphinx restructered text primer](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html) ¶

### Heading markup matters ¶

Sections have an additional line of punctuation characters. Be sure that this additional line is at least as long as the section header: ¶

~~~~ ¶
Section Header ¶
=========== # wrong: Line is too short ¶
~~~~ ¶

See [Sections](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html/#sections) for more about sections. ¶

### Indentation matters ¶

All lines of the same paragraph must be left-aligned to the same level of indentation. Keep an eye on this for _ripped_ documentation e.g. documenting a class with attributes: ¶

~~~~ ¶
/* RST ¶
.. class:: Foo ¶

Desciption of class ¶
over multiple lines ¶
*/ ¶

Lines of C++ Code defining the class ¶

/* RST ¶
.. attribue:: bar # wrong indentation for attribute bar of class Foo ¶

Description of bar ¶

.. attribue:: bar # correct indentation ¶

Description of bar ¶
*/ ¶

Lines of C++ code defining the attribute ¶
~~~~

See [Sections](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html/#sections) for more about sections.

## Formatting rules ¶

We want to have all pages have the same formatting rules. See next paragraphs for our rules. Use this markup: ¶

* constants: Use two backticks for them, e.g. ` ``true`` ` ¶


## C&P Examples ¶

### class ¶

### function ¶

### codeblock ¶

### images