fix double back-quotes

source/admin/advices.rst

@@ -11,16 +11,16 @@ Lors de la définition d'une nouvelle classe, et puisque l'ORM se base sur Activ
 Une représentation textuelle
 ============================
 
-Surcharger la fonction `def __str__(self)` sur la classe permettra de retourner une chaîne de caractère qui représentera l'instance de la classe. Cette information est utilisée un peu partout dans le code, et donnera une meilleure idée de ce qu'on manipule. 
+Surcharger la fonction ``def __str__(self)`` sur la classe permettra de retourner une chaîne de caractère qui représentera l'instance de la classe. Cette information est utilisée un peu partout dans le code, et donnera une meilleure idée de ce qu'on manipule. 
 En plus, c'est aussi ceci qui est appelé lorsque l'admin de Django historisera une action (et ceci sera inaltérable).
 
 URL absolue
 ===========
 
-La méthode `def get_absolute_url(self)` retourne l'URL à laquelle on peut envoyer une requête pour obtenir le maximum d'informations 
+La méthode `def get_absolute_url(self)` retourne l'URL à laquelle on peut envoyer une requête pour obtenir le maximum d'informations
-concernant cette instance. 
+concernant cette instance.
 
-Par exemple: 
+Par exemple:
 
 .. code-block:: python
 
@@ -44,7 +44,7 @@ Meta
 Titre
 =====
 
-Le titre de l'administration peut être modifié de deux manières: 
+Le titre de l'administration peut être modifié de deux manières:
 
  * Soit en modifiant le template de l'administration
  * Soit en ajoutant l'assignation suivante dans le fichier `urls.py`: `admin.site.site_header = "SuperBook Secret Area`.
@@ -52,5 +52,4 @@ Le titre de l'administration peut être modifié de deux manières:
 Greffons
 ========
 
-L'interface d'administration est extensible dans une certaine mesure. Notamment utiliser ``django_extensions`` pour avoir les ForeignKey auto-complétées. 
+L'interface d'administration est extensible dans une certaine mesure. Notamment utiliser ``django_extensions`` pour avoir les ForeignKey auto-complétées.
-

source/intro/01-prerequisites.rst

@@ -13,7 +13,7 @@ Les morceaux de code seront développés pour Python3.4+ et Django 1.8+. Ils né
 Création de l'environnement
 ===========================
 
-Commencez par créer un environnement virtuel, afin d'y stocker les dépendances. Vérifiez dans votre fichier `~/.bashrc` (ou tout fichier lancé au démarrage de votre session) que la variable ``WORKON_HOME`` est bien définie. Faites ensuite un `source` sur le fichier `virtualenvwrapper.sh` (à adapter en fonction de votre distribution):
+Commencez par créer un environnement virtuel, afin d'y stocker les dépendances. Vérifiez dans votre fichier ``~/.bashrc`` (ou tout fichier lancé au démarrage de votre session) que la variable ``WORKON_HOME`` est bien définie. Faites ensuite un ``source`` sur le fichier ``virtualenvwrapper.sh`` (à adapter en fonction de votre distribution):
 
 .. code-block:: shell
 
@@ -26,7 +26,7 @@ Commencez par créer un environnement virtuel, afin d'y stocker les dépendances
 
 L'intérêt de ceci ? Ne pas devoir se soucier de l'emplacement des environnements virtuels, et pouvoir entièrement les découpler des sources sur lesquelles vous travaillez, en plus d'isoler le code, de créer un containeur pour les dépendances et d'être indépendant des librairies tierces déjà installées sur le système.
 
-Lancez `mkvirtualenv gwift-env`.
+Lancez ``mkvirtualenv gwift-env``.
 
 .. code-block:: shell
 
@@ -42,9 +42,9 @@ Ceci créera l'arborescence de fichiers suivante, qui peut à nouveau être un p
     $ ls gwift-env
     Include/ Lib/ Scripts/
 
-Nous pouvons ensuite l'activer grâce à la commande `source gwift-env/bin/activate` avec `virtualenv` et `workon gwift-env` avec `virtualenvwrapper`.
+Nous pouvons ensuite l'activer grâce à la commande ``source gwift-env/bin/activate`` avec ``virtualenv`` et ``workon gwift-env`` avec ``virtualenvwrapper``.
 
-A présent, tous les binaires présents dans cet environnement prendront le pas sur les binaires du système. De la même manière, une variable *PATH* propre est définie et utilisée, afin que les librairies Python soient stockées dans le répertoire `gwift-env/Lib/site-packages/`. C'est notamment ici que nous retrouverons le code-source de Django, ainsi que des librairies externes une fois que nous les aurons installées.
+A présent, tous les binaires présents dans cet environnement prendront le pas sur les binaires du système. De la même manière, une variable ``PATH`` propre est définie et utilisée, afin que les librairies Python soient stockées dans le répertoire ``gwift-env/Lib/site-packages/``. C'est notamment ici que nous retrouverons le code-source de Django, ainsi que des librairies externes une fois que nous les aurons installées.
 
 .. code-block:: shell
 
@@ -60,7 +60,7 @@ A présent, tous les binaires présents dans cet environnement prendront le pas
 Fichiers sources
 ================
 
-Nous commençons par créer le répertoire du projet, à savoir `gwift-project`.
+Nous commençons par créer le répertoire du projet, à savoir ``gwift-project``.
 
 .. code-block:: shell
 
@@ -69,7 +69,7 @@ Nous commençons par créer le répertoire du projet, à savoir `gwift-project`.
 
 Comme l'environnement est activé, on peut à présent y installer Django. La librairie restera indépendante du reste du système, et ne polluera pas les autres projets.
 
-C'est parti: `pip install django`!
+C'est parti: ``pip install django``!
 
 .. code-block:: shell
 
@@ -80,15 +80,15 @@ C'est parti: `pip install django`!
     Installing collected packages: django
     Successfully installed django-1.8.4
 
-Les commandes de création d'un nouveau site sont à présent disponibles, la principale étant `django-admin startproject`. Par la suite, nous utiliserons `manage.py`, qui constitue un *wrapper* autour de `django-admin`.
+Les commandes de création d'un nouveau site sont à présent disponibles, la principale étant ``django-admin startproject``. Par la suite, nous utiliserons ``manage.py``, qui constitue un *wrapper* autour de `django-admin`.
 
-Pour démarrer notre projet, nous lançons `django-admin startproject gwift`.
+Pour démarrer notre projet, nous lançons ``django-admin startproject gwift``.
 
 .. code-block:: shell
 
     $ django-admin startproject gwift
 
-Cette action aura pour effet de créer un nouveau dossier `gwift`, dans lequel on trouve la structure suivante:
+Cette action aura pour effet de créer un nouveau dossier ``gwift``, dans lequel on trouve la structure suivante:
 
 .. code-block:: shell
 
@@ -111,14 +111,14 @@ Chacun de ces fichiers sert à:
 Gestion des dépendances
 =======================
 
-Comme nous venons d'ajouter une dépendance à notre projet, nous allons créer un fichier reprenant tous les dépendances de notre projet. Ceux-ci sont placés normalement dans un fichier `requirements.txt`. Dans un premier temps, ce fichier peut être placé directement à la racine du projet, mais on préférera rapidement le déplacer dans un sous-répertoire spécifique (`requirements`), afin de grouper les dépendances en fonction de leur utilité:
+Comme nous venons d'ajouter une dépendance à notre projet, nous allons créer un fichier reprenant tous les dépendances de notre projet. Ceux-ci sont placés normalement dans un fichier ``requirements.txt``. Dans un premier temps, ce fichier peut être placé directement à la racine du projet, mais on préférera rapidement le déplacer dans un sous-répertoire spécifique (``requirements``), afin de grouper les dépendances en fonction de leur utilité:
 
- * `base.txt`
+ * ``base.txt``
- * `dev.txt`
+ * ``dev.txt``
- * `staging.txt`
+ * ``staging.txt``
- * `production.txt`
+ * ``production.txt``
 
-Au début de chaque fichier, il suffira d'ajouter la ligne `-r base.txt`, puis de lancer l'installation grâce à un `pip install -r <nom du fichier>`. De cette manière, il est tout à fait acceptable de n'installer `flake8` et `django-debug-toolbar` qu'en développement par exemple.  Dans l'immédiat, ajoutez simplement `django` dans le fichier `requirements/base.txt`.
+Au début de chaque fichier, il suffira d'ajouter la ligne ``-r base.txt``, puis de lancer l'installation grâce à un ``pip install -r <nom du fichier>``. De cette manière, il est tout à fait acceptable de n'installer `flake8` et `django-debug-toolbar` qu'en développement par exemple.  Dans l'immédiat, ajoutez simplement ``django`` dans le fichier ``requirements/base.txt``.
 
 .. code-block:: shell
 

source/intro/02-create-django-app.rst

@@ -14,11 +14,11 @@ On voit bien ici le principe de **contexte**: l'application viendra avec son mod
 Gestion
 =======
 
-Comme expliqué un peu plus haut, le fichier `manage.py` est un *wrapper* sur les commandes `django-admin`. A partir de maintenant, nous n'utiliserons plus que celui-là pour tout ce qui touchera à la gestion de notre projet:
+Comme expliqué un peu plus haut, le fichier ``manage.py`` est un *wrapper* sur les commandes `django-admin`. A partir de maintenant, nous n'utiliserons plus que celui-là pour tout ce qui touchera à la gestion de notre projet:
 
- * `manage.py check` pour vérifier que votre projet ne rencontre aucune erreur
+ * ``manage.py check`` pour vérifier que votre projet ne rencontre aucune erreur
- * `manage.py runserver` pour lancer un serveur de développement
+ * ``manage.py runserver`` pour lancer un serveur de développement
- * `manage.py test` pour découvrir les tests unitaires disponibles et les lancer.
+ * ``manage.py test`` pour découvrir les tests unitaires disponibles et les lancer.
 
 La liste complète peut être affichée avec `manage.py help`. Vous remarquerez que ces commandes sont groupées: