Écrire la documentation

We place high importance on the consistency and readability of documentation. After all, Django was created in a journalism environment! So we treat our documentation like we treat our code: we aim to improve it as often as possible.

Les modifications de documentation se présentent généralement sous deux formes :

  • Des améliorations générales : corrections d’orthographe, résolutions d’erreurs et meilleures explications par une écriture plus claire et davantage d’exemples.
  • Nouvelles fonctionnalités : documentation de fonctionnalités ajoutées au cadre logiciel depuis la version précédente.

Cette section explique comment les rédacteurs peuvent préparer les modifications de documentation de la manière la plus utile possible et qui évite au maximum les erreurs.

Obtention de la documentation brute

Bien que la documentation de Django soit destinée à être lue au format HTML sur https://docs.djangoproject.com/, nous l’éditons dans un ensemble de fichiers textes pour une souplesse maximale. Ces fichiers se trouvent dans le répertoire de premier niveau docs/ d’une publication de Django.

If you’d like to start contributing to our docs, get the development version of Django from the source code repository (see Installation de la version de développement). The development version has the latest-and-greatest documentation, just as it has the latest-and-greatest code. We also backport documentation fixes and improvements, at the discretion of the merger, to the last release branch. That’s because it’s highly advantageous to have the docs for the last release be up-to-date and correct (see Différences entre versions).

Introduction à Sphinx

La documentation de Django utilise le système de documentation Sphinx, qui se base lui-même sur docutils. L’idée de base est de transformer de la documentation en texte brut avec une mise en forme minimale en HTML, PDF ou tout autre format de sortie.

Pour construire la documentation localement, installez Sphinx :

$ python -m pip install Sphinx

...\> py -m pip install Sphinx

Puis, à partir du répertoire docs, construisez la version HTML :

$ make html

...\> make.bat html

Pour commencer à contribuer, il est recommandé de lire la référence reStructuredText.

La documentation construite localement possède un thème graphique différent de celui de la documentation sur docs.djangoproject.com. Cela ne pose pas de problème. Si vos modifications apparaissent correctement sur votre machine locale, elles seront aussi correctes sur le site Web.

Organisation de la documentation

La documentation est scindée en plusieurs catégories :

  • Les tutoriels prennent l’utilisateur par la main à travers une série d’étapes pour créer quelque chose.

    L’aspect important d’un tutoriel est d’aider le lecteur à accomplir quelque chose d’utile, de préférence aussi vite que possible, dans le but de lui donner confiance.

    Expliquez la nature du problème à résoudre afin que le lecteur comprenne ce que l’on est en train de faire. Ne pensez pas qu’il faille commencer par des explications sur le fonctionnement des choses ; ce qui compte est ce que le lecteur fait, et non pas ce que vous expliquez. Il peut être utile de faire référence à ce que l’on a fait dans des explications a posteriori.

  • Les guides thématiques visent à expliquer un concept ou un sujet d’un point de vue assez général.

    Faites des liens vers le matériel de référence plutôt que de le répéter. Utilisez des exemples et n’hésitez pas à expliquer des choses qui vous semblent évidentes, il pourrait s’agir de l’explication dont quelqu’un a vraiment besoin.

    La mise à disposition de contexte sous-jacent aide les débutants à faire des liens entre le sujet et des éléments qu’ils connaissent déjà.

  • Reference guides contain technical references for APIs. They describe the functioning of Django’s internal machinery and instruct in its use.

    Restez bien centré sur le sujet du matériel de référence. Vous pouvez compter sur la connaissance des concepts de base par le lecteur, mais celui-ci cherche à savoir ou à se rappeler comment Django les applique.

    Les guides de référence ne sont pas l’endroit pour des explications générales. Si vous êtes en train d’expliquer des concepts de base, il pourrait être nécessaire de déplacer ce contenu vers un guide thématique.

  • Les guides pratiques sont des marches à suivre qui accompagnent le lecteur dans une suite d’étapes dans des sujets clés.

    Ce qui compte le plus dans un guide pratique est le résultat attendu par son lecteur. Un guide pratique doit toujours être orienté sur le résultat plutôt que sur des détails internes sur la manière dont Django implémente ce qui est en cours d’étude.

    Ces guides vont plus loin que les tutoriels et comptent sur un certaine connaissance du fonctionnement de Django. On part du principe que le lecteur a suivi les tutoriels. N’hésitez pas à réorienter le lecteur sur un tutoriel adéquat plutôt que de répéter un contenu existant.

Style d’écriture (anglais)

When using pronouns in reference to a hypothetical person, such as « a user with a session cookie », gender-neutral pronouns (they/their/them) should be used. Instead of:

  • he ou she… utilisez they.
  • him ou her… utilisez them.
  • his ou her… utilisez their.
  • his ou hers… utilisez theirs.
  • himself ou herself… utilisez themselves.

Essayez d’éviter des mots qui minimisent la difficulté impliquée par une tâche ou une opération, tels que « easily », « simply », « just », « merely », « straightforward », etc. L’expérience des gens ne correspond pas forcément à votre attente, et ceux-ci pourraient ressentir de la frustration lorsqu’ils ne trouvent pas qu’une étape est si simple ou évidente que le texte ne le laissait penser.

Termes fréquemment utilisés

Voici quelques lignes directrices de style pour des termes fréquemment utilisés dans la documentation :

  • Django – lorsque vous vous référez au cadriciel, toujours avec un D majuscule. Il n’est en minuscules que dans le code Python et dans le logo djangoproject.com.
  • email – sans trait d’union.
  • HTTP – la prononciation anglaise habituelle est « Éitch Ti Ti Pi », le terme doit donc être précédé de « an », et pas « a ».
  • MySQL, PostgreSQL, SQLite
  • SQL – lorsqu’on se réfère à SQL, la prononciation attendue est « èsquiouèl » et non pas « sicouèl ». Ainsi, dans une phrase comme « Returns an SQL expression », « SQL » doit être précédé d’un « an » et non pas de « a ».
  • Python – mettre une majuscule quand c’est une référence au langage.
  • realize, customize, initialize, etc. – utiliser le suffixe américain « ize » et non « ise ».
  • subclass – en un mot sans trait d’union, que ce soit pour un verbe (« subclass that model ») ou un nom (« create a subclass »).
  • the web, web framework – sans majuscule.
  • website – en un seul mot, sans majuscule.

Terminologie spécifique à Django

  • model – sans majuscule.
  • template – sans majuscule.
  • URLconf – trois premières lettres en majuscules, sans espace avant « conf ».
  • view – sans majuscule.

Directives pour les fichiers reStructuredText

Ces lignes directrices régulent le format de notre documentation reST (reStructuredText) :

  • Dans les titres de section, ne mettez en majuscules que les mots initiaux et les noms propres.

  • Limitez les lignes de la documentation à 80 caractères, sauf si un exemple de code est manifestement moins lisible lorsqu’il est réparti sur deux lignes, ou pour une autre bonne raison.

  • La chose principale à garder en tête lors de l’écriture et de l’édition de la documentation est que plus il y a de balisage sémantique, mieux c’est. Donc

    Add ``django.contrib.auth`` to your ``INSTALLED_APPS``...

    N’est pas aussi utile que

    Add :mod:`django.contrib.auth` to your :setting:`INSTALLED_APPS`...

    La raison en est que Sphinx va générer des liens adéquats avec ce deuxième exemple, ce qui aide grandement les lecteurs.

    Il est possible de préfixer la cible par un ~ (caractère tilde) pour que seul le dernier composant du chemin soit affiché. Par exemple, :mod:`~django.contrib.auth` affichera un lien sur le mot « auth » seul.

  • Utilisez intersphinx pour ajouter des références aux documentations de Python et de Sphinx.

  • Ajoutez .. code-block:: <lang> aux blocs littéraux pour que leur syntaxe soit mise en évidence. Mais on préfère en général laisser agir la coloration syntaxique automatique en utilisant :: (deux fois deux-points). L’avantage est que du code contenant de la syntaxe non valable ne sera pas coloré. Si par exemple on ajoute .. code-block:: python, la coloration syntaxique sera forcée même si la syntaxe n’est pas entièrement valable.

  • Pour améliorer la lisibilité, utilisez .. admonition:: Titre descriptif plutôt que .. note::. Utilisez ces boîtes de manière parcimonieuse.

  • Utilisez ces styles d’en-têtes

    ===
One
===

Two
===

Three
-----

Four
~~~~

Five
^^^^

  • Utilisez :rfc: pour faire référence à des RFC et essayez de faire le lien vers la section adéquate si possible. Par exemple, écrivez :rfc:`2324#section-2.3.2` ou :rfc:`Texte de lien personnalisé <2324#section-2.3.2>`.

  • Utilisez :pep: pour faire référence aux propositions d’amélioration de Python (PEP) et essayez de faire le lien vers la section adéquate si possible. Par exemple, écrivez :pep:`20#easter-egg` ou :pep:`Easter Egg <20#easter-egg>`.

  • Utilisez :mimetype: pour vous référer à un type MIME sauf si la valeur est entre guillemets pour un exemple de code.

  • Utilisez :envvar: pour vous référer à une variable d’environnement. Il est parfois aussi nécessaire de définir une référence à la documentation pour cette variable d’environnement en utilisant .. envvar::.

Balisage spécifique à Django

En plus du balisage propre à Sphinx, la documentation de Django définit quelques unités descriptives supplémentaires :

  • Réglages

    .. setting:: INSTALLED_APPS

    Pour faire un lien vers un réglage, utilisez :setting:`INSTALLED_APPS`.

  • Balises de gabarit

    .. templatetag:: regroup

    Pour faire le lien, utilisez :ttag:`regroup`.

  • Filtres de gabarit

    .. templatefilter:: linebreaksbr

    Pour faire le lien, utilisez :tfilter:`linebreaksbr`.

  • Requêtes de champs (par ex. Foo.objects.filter(bar__exact=qqchose)):

    .. fieldlookup:: exact

    Pour faire le lien, utilisez :lookup:`exact`.

  • Commandes django-admin:

    .. django-admin:: migrate

    Pour faire le lien, utilisez :djadmin:`migrate`.

  • Options de ligne de commande django-admin:

    .. django-admin-option:: --traceback

    Pour faire le lien, utilisez :option:`nom_commande --traceback` (ou omettez nom_commande pour les options partagées par toutes les commandes comme --verbosity).

  • Liens vers les tickets Trac (typiquement réservés pour les notes de publication des versions correctives)

    :ticket:`12345`

La documentation de Django utilise une directive console personnalisée pour la documentation des exemples en ligne de commande impliquant django-admin, manage.py, python, etc.). Dans la production HTML de la documentation, deux onglets apparaîtront dans l’interface, un avec l’invite de commande de type Unix et l’autre avec une invite de commande de style Windows.

Par exemple, vous pouvez remplacer ce fragment

use this command:

.. code-block:: console

    $ python manage.py shell

par celui-ci

use this command:

.. console::

    $ python manage.py shell

Remarquez deux choses :

  • Vous allez généralement remplacer les occurrences de la directive .. code-block:: console.
  • Vous n’avez pas besoin de modifier le contenu effectif de l’exemple de code. Vous l’écrivez toujours en imaginant un environnement de type Unix (c’est-à-dire un symbole d’invite '$', '/' comme séparateur de chemins de systèmes de fichiers, etc.)

L’exemple ci-dessus va produire un bloc d’exemple de code avec deux onglets. Le premier contiendra :

$ python manage.py shell

(aucun changement par rapport au rendu .. code-block:: console standard).

Le second contiendra :

...\> py manage.py shell

Documentation de nouvelles fonctionnalités

Notre politique pour les nouvelles fonctionnalités est la suivante :

All documentation of new features should be written in a way that clearly designates the features that are only available in the Django development version. Assume documentation readers are using the latest release, not the development version.

La méthode préférée pour marquer les nouvelles fonctionnalités est de précéder leur documentation par « .. versionadded:: X.Y », suivi d’une ligne vierge obligatoire et d’une description facultative (avec indentation).

General improvements or other changes to the APIs that should be emphasized should use the « .. versionchanged:: X.Y » directive (with the same format as the versionadded mentioned above.

Ces blocs versionadded et versionchanged doivent être « autonomes », c’est-à-dire que dans la mesure où ces annotations ne sont conservées que dans deux versions principales, il est utile de pouvoir simplement les enlever sans devoir remettre en forme, changer l’indentation ou modifier le texte avoisinant. Par exemple, au lieu de placer toute la description d’une fonctionnalité nouvelle ou modifiée dans un bloc, faite quelque chose comme ceci

.. class:: Author(first_name, last_name, middle_name=None)

    A person who writes books.

    ``first_name`` is ...

    ...

    ``middle_name`` is ...

    .. versionchanged:: A.B

        The ``middle_name`` argument was added.

Placez les annotations pour les modifications au bas de la section, et non pas au-dessus.

De même, évitez de faire référence à une version spécifique de Django en dehors des blocs versionadded et versionchanged. Même dans un bloc, il est souvent redondant de mentionner des versions puisque le rendu automatique de ces annotations produit respectivement « New in Django A.B » et « Changed in Django A.B ».

Si une fonction, un attribut, etc. a été ajouté, il est aussi admis d’utiliser une annotation versionadded comme ceci

.. attribute:: Author.middle_name

    .. versionadded:: A.B

    An author's middle name.

Nous pouvons enlever l’annotation .. versionadded:: A.B sans aucun changement d’indentation lorsque ce sera le bon moment.

Minimiser les images

Optimisez la taille de compression des images quand c’est possible, pour les fichiers PBG, utilisez OptiPNG et advpng de AdvanceCOMP :

$ cd docs
$ optipng -o7 -zm1-9 -i0 -strip all `find . -type f -not -path "./_build/*" -name "*.png"`
$ advpng -z4 `find . -type f -not -path "./_build/*" -name "*.png"`

Cet exemple est basé sur la version 0.7.5 de OptiPNG. Les versions plus anciennes peuvent se plaindre que l’option -strip all perd des données.

Un exemple

Pour un exemple rapide sur la manière dont tout s’enchaîne, considérez l’exemple hypothétique suivant :

  • Tout d’abord, la disposition générale du document ref/settings.txt pourrait ressembler à ceci :

    ========
Settings
========

...

.. _available-settings:

Available settings
==================

...

.. _deprecated-settings:

Deprecated settings
===================

...

  • Ensuite, le document topics/settings.txt pourrait contenir quelque chose comme :

    You can access a :ref:`listing of all available settings
<available-settings>`. For a list of deprecated settings see
:ref:`deprecated-settings`.

You can find both in the :doc:`settings reference document
</ref/settings>`.

    We use the Sphinx doc cross-reference element when we want to link to another document as a whole and the ref element when we want to link to an arbitrary location in a document.

  • Puis, voyez comment les réglages sont annotés :

    .. setting:: ADMINS

ADMINS
======

Default: ``[]`` (Empty list)

A list of all the people who get code error notifications. When
``DEBUG=False`` and a view raises an exception, Django will email these people
with the full exception information. Each member of the list should be a tuple
of (Full name, email address). Example::

    [('John', 'john@example.com'), ('Mary', 'mary@example.com')]

Note that Django will email *all* of these people whenever an error happens.
See :doc:`/howto/error-reporting` for more information.

    Ceci balise l’en-tête suivante comme la cible « canonique » du réglage ADMINS. Cela signifie que lors de chaque mention de ADMINS, on peut y faire référence avec :setting:`ADMINS`.

C’est grosso modo ainsi que le tout fonctionne.

Correction orthographique

Avant de commiter la documentation, il est recommandé de lancer le correcteur orthographique. Vous devez pour cela installer d’abord sphinxcontrib-spelling <https://pypi.org/project/sphinxcontrib-spelling/>. Puis, à partir du répertoire docs, lancez make spelling. Le cas échéant, les mots faux ainsi que le fichier et le numéro de ligne où ils apparaissent seront enregistrés dans _build/spelling/output.txt.

Si vous rencontrez des faux positifs (des erreurs signalées qui n’en sont pas), faites l’une des choses suivantes :

  • Entourez le code imbriqué ou les noms de marques ou de technologie avec des accents graves(`).
  • Cherchez des synonymes que le correcteur orthographique connaît.
  • Si vous êtes certain-e que le mot utilisé est correct, ajoutez-le à la liste docs/spelling_wordlist (en prenant soin de respecter l’ordre alphabétique).

Traduction de la documentation

Consultez Traduction de la documentation de Django si vous souhaitez aider à traduire la documentation dans une autre langue.

Page de manuel django-admin

Sphinx peut générer une page de manuel pour la commande django-admin. Ceci est configuré dans docs/conf.py. Au contraire d’autres productions de documentation, cette page de manuel devrait être contenue dans le dépôt de Django et dans ses publications comme docs/man/django-admin.1. Il n’est pas nécessaire de mettre à jour ce fichier lors de la mise à jour de la documentation, car sa mise est jour fait partie du processus de publication.

Pour générer une version à jour de la page de manuel, lancez make man dans le répertoire docs. La nouvelle page de manuel sera écrite dans docs/_build/man/django-admin.1.

Back to Top