Prepare all .po files for updating by volunteers
This commit is contained in:
Griatch
parent
ecf757ba7c
commit
7147e3e027
15 changed files with 9116 additions and 1773 deletions
|
|
@ -13,41 +13,41 @@ Markdown files are simple text files that can be edited with a normal text edito
|
|||
contain raw HTML directives (but that is very rarely needed). They primarly use
|
||||
the [Markdown][commonmark] syntax. See [the syntax section below](#Editing-syntax) for more help.
|
||||
|
||||
## Source file structure
|
||||
## Source file structure
|
||||
|
||||
The sources are organized into several rough categories, with only a few administrative documents
|
||||
at the root of `evennia/docs/source/`. The folders are named in singular form since they will
|
||||
at the root of `evennia/docs/source/`. The folders are named in singular form since they will
|
||||
primarily be accessed as link refs (e.g. `Component/Account`)
|
||||
|
||||
- `source/Components/` are docs describing separate Evennia building blocks, that is, things
|
||||
that you can import and use. This extends and elaborates on what can be found out by reading
|
||||
the api docs themselves. Example are documentation for `Accounts`, `Objects` and `Commands`.
|
||||
- `source/Concepts/` describes how larger-scale features of Evennia hang together - things that
|
||||
can't easily be broken down into one isolated component. This can be general descriptions of
|
||||
how Models and Typeclasses interact to the path a message takes from the client to the server
|
||||
- `source/Concepts/` describes how larger-scale features of Evennia hang together - things that
|
||||
can't easily be broken down into one isolated component. This can be general descriptions of
|
||||
how Models and Typeclasses interact to the path a message takes from the client to the server
|
||||
and back.
|
||||
- `source/Setup/` holds detailed docs on installing, running and maintaining the Evennia server and
|
||||
the infrastructure around it.
|
||||
- `source/Coding/` has help on how to interact with, use and navigate the Evennia codebase itself.
|
||||
- `source/Setup/` holds detailed docs on installing, running and maintaining the Evennia server and
|
||||
the infrastructure around it.
|
||||
- `source/Coding/` has help on how to interact with, use and navigate the Evennia codebase itself.
|
||||
This also has non-Evennia-specific help on general development concepts and how to set up a sane
|
||||
development environment.
|
||||
- `source/Contribs/` holds documentation specifically for packages in the `evennia/contribs/` folder.
|
||||
Any contrib-specific tutorials will be found here instead of in `Howtos`
|
||||
- `source/Howtos/` holds docs that describe how to achieve a specific goal, effect or
|
||||
result in Evennia. This is often on a tutorial or FAQ form and will refer to the rest of the
|
||||
- `source/Howtos/` holds docs that describe how to achieve a specific goal, effect or
|
||||
result in Evennia. This is often on a tutorial or FAQ form and will refer to the rest of the
|
||||
documentation for further reading.
|
||||
- `source/Howtos/Starting/` holds all documents part of the initial tutorial sequence.
|
||||
|
||||
|
||||
|
||||
|
||||
Other files and folders:
|
||||
- `source/api/` contains the auto-generated API documentation as `.rst` files. Don't edit these
|
||||
files manually, your changes will be lost. To refer to these files, use `api:` followed by
|
||||
the Python path, for example `[rpsystem contrib](api:evennia.contrib.rpsystem)`.
|
||||
- `source/_templates` and `source/_static` should not be modified unless adding a new doc-page
|
||||
files manually, your changes will be lost. To refer to these files, use `api:` followed by
|
||||
the Python path, for example `[rpsystem contrib](api:evennia.contrib.rpsystem)`.
|
||||
- `source/_templates` and `source/_static` should not be modified unless adding a new doc-page
|
||||
feature or changing the look of the HTML documentation.
|
||||
- `conf.py` holds the Sphinx configuration. It should usually not be modified except to update
|
||||
the Evennia version on a new branch.
|
||||
|
||||
|
||||
|
||||
## Building the docs locally
|
||||
|
||||
|
|
@ -103,12 +103,12 @@ initialize a new game with a default database (you don't need to have any server
|
|||
running)
|
||||
|
||||
- It's recommended that you use a virtualenv. Install your cloned version of Evennia into
|
||||
by pointing to the repo folder (the one containing `/docs`):
|
||||
by pointing to the repo folder (the one containing `/docs`):
|
||||
|
||||
```
|
||||
pip install -e evennia
|
||||
pip install -e evennia
|
||||
```
|
||||
|
||||
|
||||
- Make sure you are in the parent folder _containing_ your `evennia/` repo (so _two_ levels
|
||||
up from `evennia/docs/`).
|
||||
- Create a new game folder called exactly `gamedir` at the same level as your `evennia`
|
||||
|
|
@ -118,8 +118,8 @@ repo with
|
|||
evennia --init gamedir
|
||||
```
|
||||
|
||||
- Then `cd` into it and create a new, empty database. You don't need to start the
|
||||
game or do any further changes after this.
|
||||
- Then `cd` into it and create a new, empty database. You don't need to start the
|
||||
game or do any further changes after this.
|
||||
|
||||
```
|
||||
evennia migrate
|
||||
|
|
@ -234,7 +234,7 @@ smaller and smaller font).
|
|||
|
||||
> Don't use the same heading/subheading name more than once in one page. While Markdown
|
||||
does not prevent it, it will make it impossible to refer to that heading uniquely.
|
||||
The Evennia documentation preparser will detect this and give you an error.
|
||||
The Evennia documentation preparser will detect this and give you an error.
|
||||
|
||||
### Lists
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ The Evennia documentation supports some special reference shortcuts in links:
|
|||
|
||||
##### Github online repository
|
||||
|
||||
- `github:` - a shortcut for the full path to the Evennia repository on github. This must be given
|
||||
- `github:` - a shortcut for the full path to the Evennia repository on github. This must be given
|
||||
with forward-slashes and include the `.py` file ending. It will refer to the `master` branch by default:
|
||||
|
||||
[link to objects.py](github:evennia/objects/objects.py)
|
||||
|
|
@ -337,8 +337,8 @@ with forward-slashes and include the `.py` file ending. It will refer to the `ma
|
|||
##### Bug reports/feature request
|
||||
|
||||
|
||||
- `github:issue` - links to the github issue selection page, where the user can choose which type of
|
||||
issue to create.
|
||||
- `github:issue` - links to the github issue selection page, where the user can choose which type of
|
||||
issue to create.
|
||||
|
||||
If you find a problem, make a [bug report](github:issue)!
|
||||
|
||||
|
|
@ -402,7 +402,7 @@ as the name of the `language` of a literal block:
|
|||
````
|
||||
```eval_rst
|
||||
|
||||
This will be evaluated as ReST.
|
||||
This will be evaluated as ReST.
|
||||
All content must be indented.
|
||||
|
||||
```
|
||||
|
|
@ -420,14 +420,15 @@ There is also a short-hand form for starting a [ReST directive][ReST-directives]
|
|||
```
|
||||
````
|
||||
|
||||
Within a ReST block, one must use Restructured Text syntax, which is not the same as Markdown.
|
||||
Within a ReST block, one must use Restructured Text syntax, which is not the
|
||||
same as Markdown.
|
||||
|
||||
- Single backticks around text makes it _italic_.
|
||||
- Double backticks around text makes it `verbatim`.
|
||||
- A link is written within back-ticks, with an underscore at the end:
|
||||
|
||||
`python <www.python.org>`_
|
||||
|
||||
|
||||
[Here is a ReST formatting cheat sheet](https://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html).
|
||||
|
||||
Below are examples of ReST-block structures.
|
||||
|
|
@ -554,7 +555,7 @@ a plain HTML string in the markdown like so:
|
|||
|
||||
#### Tables
|
||||
|
||||
A table is specified using [ReST table syntax][ReST-tables] (they don't need to be indented):
|
||||
A table is specified using [ReST table syntax][ReST-tables] (they don't need to be indented):
|
||||
````
|
||||
```eval_rst
|
||||
|
||||
|
|
@ -610,7 +611,7 @@ or the more flexible but verbose
|
|||
#### A more flexible code block
|
||||
|
||||
The regular Markdown Python codeblock is usually enough but for more direct control over the style, one
|
||||
can also specify the code block explicitly in `ReST` for more flexibility.
|
||||
can also specify the code block explicitly in `ReST` for more flexibility.
|
||||
It also provides a link to the code block, identified by its name.
|
||||
|
||||
|
||||
|
|
@ -659,11 +660,11 @@ lines or captions since that's not a part of the Markdown specification.
|
|||
## Code documentation
|
||||
|
||||
The source code docstrings will be parsed as Markdown. When writing a module docstring, you can use Markdown formatting,
|
||||
including header levels down to 4th level (`#### SubSubSubHeader`). After the module documentation it's
|
||||
a good idea to end with four dashes `----`. This will create a visible line between the documentation and the
|
||||
including header levels down to 4th level (`#### SubSubSubHeader`). After the module documentation it's
|
||||
a good idea to end with four dashes `----`. This will create a visible line between the documentation and the
|
||||
class/function docs to follow. See for example [the Traits docs](api:evennia.contrib.traits).
|
||||
|
||||
All non-private classes, methods and functions must have a Google-style docstring, as per the
|
||||
All non-private classes, methods and functions must have a Google-style docstring, as per the
|
||||
[Evennia coding style guidelines][github:evennia/CODING_STYLE.md]. This will then be correctly formatted
|
||||
into pretty api docs.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue