Documentation proofreading

1 files changed, 6 insertions, 6 deletions

diff --git a/docs/fr/source/principes.rst b/docs/fr/source/principes.rst
index d068c5203..83d703f62 100644
--- a/docs/fr/source/principes.rst
+++ b/docs/fr/source/principes.rst
@@ -72,8 +72,8 @@ Module lieux de conservation
 - gestion des mouvements de mobilier,
 - production automatique de documents tels conventions de prêts, fiches d'état, etc.
 - conditionnement,
-- sélection par « panier »,
-- gestion des contenants et étiquetage : il n'est pas prévu qu'Ishtar génère directement des étiquettes (pdf) mais plutôt des fichiers csv pouvant être utilisés selon tout format d'étiquette via « publi-postage » dans un logiciel tiers (libre-office, excel, etc.).
+- sélection par « panier »,
+- gestion des contenants et étiquetage : il n'est pas prévu qu'Ishtar génère directement des étiquettes (pdf) mais plutôt des fichiers csv pouvant être utilisés selon tout format d'étiquette via « publi-postage » dans un logiciel tiers (libre-office, excel, etc.).
 
 Modules / configuration
 =======================
@@ -109,7 +109,7 @@ Au sein d'Ishtar, l'opération archéologique est définie comme une action (ou
 
 Si l'opération est au centre du modèle de données d'Ishtar plutôt que le site ou l'entité archéologique, c'est parce que ce dernier est une interprétation (comme toute interprétation, sujette à évolution dans le temps) des données, alors que l'opération est l'information qui permet au mieux de regrouper un corpus documentaire cohérent mettant en lien des documents (plans, rapports, photos, etc.) et du mobilier.
 
-Il est possible de créer des liens entre des opérations, soit en les associant à un même dossier source (avec le module « administratif », ex. : un permis de construire qui est associé à un diagnostic et une fouille préventive), soit en définissant une relation entre des opérations globales (ex. : PCR, suivi d'autoroutes, etc.) et d'autres plus ponctuelles (phases, tranches, secteurs, etc.). Le regroupement d'opérations est également pratique en contexte de fouilles programmées, où il peut être utile d'avoir des inventaires pour chaque opération par année, mais également une vision globale de la succession des fouilles (opération globale). En contexte de grande opération préventive, ce système peut servir à individualiser des secteurs de fouilles disposant de modes d’enregistrements spécifiques. L'utilisateur a toute latitude pour organiser les opérations entres elles selon ses besoins, du moment que ces éléments clefs représentent bien des lots documentaires et mobilier a priori cohérents.
+Il est possible de créer des liens entre des opérations, soit en les associant à un même dossier source (avec le module « administratif », ex. : un permis de construire qui est associé à un diagnostic et une fouille préventive), soit en définissant une relation entre des opérations globales (ex. : PCR, suivi d'autoroutes, etc.) et d'autres plus ponctuelles (phases, tranches, secteurs, etc.). Le regroupement d'opérations est également pratique en contexte de fouilles programmées, où il peut être utile d'avoir des inventaires pour chaque opération par année, mais également une vision globale de la succession des fouilles (opération globale). En contexte de grande opération préventive, ce système peut servir à individualiser des secteurs de fouilles disposant de modes d’enregistrements spécifiques. L'utilisateur a toute latitude pour organiser les opérations entres elles selon ses besoins, du moment que ces éléments clefs représentent bien des lots documentaires et mobilier a priori cohérents.
 
 
 Site/entité archéologique
@@ -120,7 +120,7 @@ Malgré le choix de l'opération comme rôle central de son modèle de données,
 Parcelle
 --------
 
-Les parcelles sont gérées précisément au sein d'Ishtar en étant directement rattachées aux UE. Cela permet de faciliter la gestion des questions légales concernant le mobilier (réalisation du « partage » ou responsabilité en cas de restauration). Si la parcelle de l'UE n'est pas connue ou si elle n'est pas sujette a contrainte légale, il est possible d'associer une parcelle virtuelle ou de ne pas renseigner ce champ.
+Les parcelles sont gérées précisément au sein d'Ishtar en étant directement rattachées aux UE. Cela permet de faciliter la gestion des questions légales concernant le mobilier (réalisation du « partage » ou responsabilité en cas de restauration). Si la parcelle de l'UE n'est pas connue ou si elle n'est pas sujette a contrainte légale, il est possible d'associer une parcelle virtuelle ou de ne pas renseigner ce champ.
 
 Unité d'enregistrement
 ----------------------
@@ -147,7 +147,7 @@ Le mobilier actuel (généralement juste appelé « mobilier » au sein d'Isht
 
 Le distinguo entre de ces deux notions permet notamment une gestion fine des traitements simples (destructif ou non) et complexes (tri, remontage, etc.) avec une connaissance précise de l'historique de l'objet (lieux, responsables et documentations peuvent être associées à chaque traitement).
 
-Sur la figure ci-dessous chaque « Fiche mobilier » correspond à un élément « mobilier actuel » en base de données. Chaque élément et chaque traitement a une fiche associée.
+Sur la figure ci-dessous chaque « Fiche mobilier » correspond à un élément « mobilier actuel » en base de données. Chaque élément et chaque traitement a une fiche associée.
 
 .. image:: _static/traitement.png
 
@@ -186,7 +186,7 @@ Un élément localisé dispose des champs suivants (entre parenthèses le nom du
 - un champ polygone ou plus précisément un champ multi-polygone (`multi_polygon`) - par abus de langage polygone est repris dans la suite de la documentation. Pour l'instant ce champ n'est éditable qu'en import (mais visible sur les fiches) .
 - l'origine des coordonnées (`point_source`) et l'origine du polygone (`multi_polygon_source`). Trois origines sont possibles :
 
-  - « précis » (valeur **P** pour *precise*). Les coordonnées ou le polygone ont été relevés précisément.
+  - « précis » (valeur **P** pour *precise*). Les coordonnées ou le polygone ont été relevés précisément.
   - le polygone (valeur **M** pour *multi-polygon*). Ne concerne que le point : reprend le centroïde du polygone. **Géré automatiquement par Ishtar** quand le polygone a été défini précisément et qu'il n'y a pas de coordonnées précises associées.
   - la commune (valeur **T** pour *town*). Le point a été déduit du centroïde de la commune, le polygone reprend celui de la commune. **Géré automatiquement par Ishtar** quand aucune autre source n'est disponible.