Docs-fr: fixes

1 files changed, 16 insertions, 16 deletions

diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst
index a77ff605d..32aac1045 100644
--- a/docs/fr/source/interface-administrateur.rst
+++ b/docs/fr/source/interface-administrateur.rst
@@ -28,21 +28,21 @@ Dans les pages d'administration, les listes de types se retrouvent sous les dén
 - **Ishtar - Commun** : contient les listes de types transversales utilisées par plusieurs types d'éléments ;
 - **Ishtar - Opération** : contient les listes de types concernant les opérations et les entités archéologiques/sites ;
 - **Ishtar - Unités d'enregistrement** : contient les listes de types relatives aux Unités d'enregistrement et aux datations ;
-- **Ishtar - Mobilier** : contient les listes de types relatives au mobilier et au traitements ;
+- **Ishtar - Mobilier** : contient les listes de types relatives au mobilier et aux traitements ;
 - **Ishtar - Lieu de conservation** : contient les listes de types relatives aux lieux de conservation et aux contenants ;
 - **Ishtar - Dossier** : contient les listes de types relatives aux dossiers administratifs.
 
 Dans Ishtar, chaque type est défini au minimum par les champs suivants :
 
 - **Dénomination**
-- **Identifiant textuel** : L'identifiant textuel est une version standardisée du nom. Il ne contient que des lettres en minuscule, des nombres et des tirets (-). Chaque identifiant textuel doit être unique dans la liste de type. Ces identifiants sont des clés permettant les échanges entre bases de données et pour des traductions. Ces identifiants peuvent être utilisés dans le code source de l'application. Une fois créés il ne faut a priori pas changer ces identifiants textuels.
+- **Identifiant textuel** : L'identifiant textuel est une version standardisée du nom. Il ne contient que des lettres en minuscule non accentuées, des nombres et des tirets (-). Chaque identifiant textuel doit être unique dans la liste de types. Ces identifiants sont des clés permettant les échanges entre bases de données et pour des traductions. Ces identifiants peuvent être utilisés dans le code source de l'application. Une fois créés il ne faut a priori pas changer ces identifiants textuels.
 - **Commentaire** : Le contenu du commentaire est affiché dans l'aide en ligne sur les formulaires.
-- **Disponibilité** : Décocher ce champ rend indisponible ce type dans les formulaires.
+- **Disponibilité** : Décocher ce champ rend indisponible ce type dans les formulaires, sans détruire l'information pour ce qui est déjà présent en base ; l'information est toujours visible dans les fiches.
 - **Ordre** : Dans les listes les champs sont ordonnés par ce numéro d'ordre et en cas d'égalité par ordre alphabétique.
 
-Certains types permettent de mettre en place une hiérarchie. Pour cela le champ **parent** est disponible. Chaque « sous-type » renseigne ce champ avec le « sur-type » adéquat. 
+Certains types permettent de mettre en place une hiérarchie. Pour cela le champ **parent** est disponible. Pour chaque type enfant, ce champ est renseigné avec le type parent adéquat. 
 
-Certains types disposent aussi d'autres champs spécifiques ils sont explicites ou disposent d'une aide en ligne.
+Certains types disposent aussi d'autres champs spécifiques ; ceux-ci sont explicites ou disposent d'une aide en ligne.
 
 .. note:: Pour travailler sur ces listes de types ou les transmettre à des tiers, la possibilité est offerte d'exporter ces listes de types via l'interface d'administration. On sélectionne les éléments à exporter (ou tous les éléments) puis on utilise l'action « Exporter les éléments sélectionnés en fichier CSV ». Le fichier peut alors être édité dans un tableur. Pour une mise à jour, il est important de ne pas modifier les identifiants textuels qui sont la clé de rapprochement pour le ré-import. L'action d'import est disponible en haut à droite : « Import depuis un CSV ».
 
@@ -50,7 +50,7 @@ Certains types disposent aussi d'autres champs spécifiques ils sont explicites
 Champs personnalisés
 --------------------
 
-Ishtar propose un certain nombre de champ standards et génériques permettant de disposer dès le départ d'une base solide et aussi pour assurer un certain degré d'inter-opérabilité entre les différentes installations d'Ishtar. Néanmoins nul ne peut prétendre à l'exhaustivité et, notamment dans le cadre d'une utilisation d'Ishtar axée recherche, le besoin se fera probablement sentir d'ajouter des champs.
+Ishtar propose un certain nombre de champs standards et génériques permettant de disposer dès le départ d'une base solide et aussi pour assurer un certain degré d'inter-opérabilité entre les différentes installations d'Ishtar. Néanmoins nul ne peut prétendre à l'exhaustivité et, notamment dans le cadre d'une utilisation d'Ishtar axée recherche, le besoin se fera probablement sentir d'ajouter des champs.
 
 Dans Ishtar ces champs sont appelés : **Champs personnalisés**. Le format JSON étant utilisé pour stocker ces données, le nom **Données JSON** est aussi utilisé.
 
@@ -59,8 +59,8 @@ Ajouter un champ personnalisé se fait via l'interface d'administration au nivea
 Les différentes données à rentrer sont :
 
 * **Nom** : Ce nom sera repris dans les formulaires et la fiche.
-* **Type de contenu** : Le type d'objet auquel sera rattaché le champ - Opération, Site, Unité d'Enregistrement et Mobilier.
-* **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent ou un tiret bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tiret bas d'affilée dans la clé de base). On peut structurer les données personnalisée de manière hiérarchique. Pour les clés hiérarchiques on utilise « __ » entre les sections. Par exemple pour la clé « ma_sousclef » dans la catégorie « ma_categorie », la clé sera notée : *ma_categorie__ma_sousclef*.
+* **Type de contenu** : Le type d'objet auquel sera rattaché le champ - Opération, Site, Unité d'Enregistrement, Mobilier, ...
+* **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent et des tirets bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tirets bas d'affilée dans la clé de base). On peut structurer les données personnalisée de manière hiérarchique. Pour les clés hiérarchiques on utilise « __ » entre les sections. Par exemple pour la clé « ma_sousclef » dans la catégorie « ma_categorie », la clé sera notée : *ma_categorie__ma_sousclef*.
 * **Type** : Les types de données disponibles sont les suivants :
 
   * Texte,
@@ -83,9 +83,9 @@ Sauf si un champ personnalisé est uniquement destiné à des données importée
 Formulaires personnalisés
 -------------------------
 
-La plupart des formulaires peuvent être personnalisés dans Ishtar, notamment tous les formulaires des wizards ainsi que les formulaires de recherche. À ce jour, il n'est pas encore possible d'ajouter de nouveaux formulaires.
+La plupart des formulaires peuvent être personnalisés dans Ishtar, notamment tous les formulaires de création/modification ainsi que les formulaires de recherche. À ce jour, il n'est pas encore possible d'ajouter de nouveaux formulaires.
 
-Les formulaires personnalisés permettent deux choses : enlever les champs disponibles de base dans le formulaire et ajouter des champs JSON dans le formulaire. Chaque formulaire personnalisé peut être mis à disposition pour tous ou seulement certains utilisateurs.
+Les formulaires personnalisés permettent deux choses : soustraire de l'affichage du formulaire les champs disponibles par défaut et ajouter des champs JSON dans le formulaire. Chaque formulaire personnalisé peut être mis à disposition pour tous ou seulement certains utilisateurs.
 
 La configuration de ces champs se fait en administration via : *Ishtar - Commun › Formulaires personnalisés*.
 
@@ -97,7 +97,7 @@ Le paramétrage de base demande les champs suivants :
 * **Formulaire** : le formulaire à personnaliser. Le nom utilisé permet d'identifier assez simplement le formulaire correspondant car il correspond dans l'ordre (séparé par des tirets) au :
 
   * type d'objet concerné (par exemple : « Mobilier »),
-  * éventuellement, le numéro d'ordre dans le wizard,
+  * éventuellement, le numéro d'ordre dans les formulaires successifs,
   * nom du formulaire.
 * **À qui s'applique ce formulaire**, cela peut être au choix :
 
@@ -108,7 +108,7 @@ Le paramétrage de base demande les champs suivants :
 Une fois ce paramétrage de base enregistré, la configuration précise du formulaire peut se faire :
 
 * **champs à exclure** : chaque champ de base présent dans le formulaire actuel peut être sélectionné dans la liste pour être écarté de la saisie.
-* **champs JSON** : tous les champs JSON préalablement paramétrés concernant l'élément courant peuvent être sélectionnés. La dénomination permet éventuellement de surcharger le nom par défaut du champ JSON. L'ordre permet de placer le champ dans le formulaire. L'aide permet éventuellement d'ajouter un texte pour aider à la saisie.
+* **champs JSON** : tous les champs JSON préalablement paramétrés concernant l'élément courant (mobilier, OA, ...) peuvent être sélectionnés. La dénomination permet éventuellement de surcharger le nom par défaut du champ JSON. L'ordre permet de placer le champ dans le formulaire. L'aide permet éventuellement d'ajouter un texte pour aider à la saisie.
 
 .. warning:: Sur les formulaires de création, il est impératif de ne pas exclure des champs obligatoires sans quoi la création devient impossible.
 
@@ -125,7 +125,7 @@ Dans Ishtar, un compte doit être associé à une personne. Si la personne n'exi
 
 Ensuite on créé un compte associé à cette personne, toujours via l'interface d'Ishtar : *Administration › Compte › Ajout/modification*. Dans les différents panneaux, il est demandé : l'identifiant du compte, le courriel rattaché, le mot de passe puis le type de profil.
 
-Les types de profil définiront les types de permissions auquel aura accès l'utilisateur. Sur ces types de profil, des zones peuvent être définies afin de permettre des règles de rattachement spécifique (cf. :ref:`permissions dans Ishtar<permissions-ishtar>`).
+Les types de profil définiront les types de permissions auxquelles aura accès l'utilisateur. Sur ces types de profil, des zones peuvent être définies afin de permettre des règles de rattachement spécifique (cf. :ref:`permissions dans Ishtar<permissions-ishtar>`).
 
 Cette interface de création de compte permet aussi de modifier le mot de passe de comptes existants.
 
@@ -151,7 +151,7 @@ Chacun de ces droit est décliné en deux modalités :
 - droits sur tous les éléments ;
 - droit sur les éléments rattachés.
 
-Un élément est dit « rattaché » à une personne en fonction de règles précises spécifiées dans l':ref:`annexe 1 - règles de rattachement à un élément <annexe-1-rattachement>`. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associé à l'élément. Par exemple cela permet donner les droits de modification du mobilier d'une opération au responsable scientifique de cette opération.
+Un élément est dit « rattaché » à une personne en fonction de règles précises spécifiées dans l':ref:`annexe 1 - règles de rattachement à un élément <annexe-1-rattachement>`. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associées à l'élément. Par exemple cela permet donner les droits de modification du mobilier d'une opération au responsable scientifique de cette opération.
 
 En pratique, globalement, les groupes de droits permettent d'accéder à certaines actions :
 
@@ -161,12 +161,12 @@ En pratique, globalement, les groupes de droits permettent d'accéder à certain
 
 Dans le détail, il y a certaines actions qui sont ouvertes en fonction d'appartenance à des groupes en particulier. Tout cela est détaillé dans l':ref:`annexe 2 - permissions nécessaires pour les actions <annexe-2-permission-action>`.
 
-.. note:: La page *Ishtar - Commun › Résumés des types de profil* permet d'accéder à un tableau qui reprend toutes les permissions associées aux types de profil.
+.. note:: La page *Ishtar - Commun › Résumés des types de profil* permet d'accéder à un tableau qui reprend et rend explicites toutes les permissions associées aux types de profil.
 
 Permissions dans les pages d'administration
 *******************************************
 
-Les permissions des pages d'administration sont gérées différemment. Elles utilisent le système de permission du framework Django, framework utilisé par Ishtar.
+Les permissions des pages d'administration sont gérées différemment. Elles utilisent le système de permission du framework Django, framework (cadre de développement logiciel) utilisé par Ishtar.
 Une fois le compte créé, les droits se spécifient dans les pages d'administration : *Authentification et autorisation › Utilisateurs*.
 
 L'ouverture de l'accès aux pages d'administration se fait en cochant le « Statut équipe ». Si l'on souhaite n'ouvrir l'accès qu'à certaines pages spécifiques, on ajoute les « Permissions de l'utilisateur » correspondant aux tables que l'on souhaite ouvrir, si l'on souhaite ouvrir l'accès à toutes les tables, il suffit de cocher le « Statut super-utilisateur ».