# HG changeset patch
# User André Sintzoff <andre.sintzoff@gmail.com>
# Date 1259575062 -3600
# Node ID 746a888fb41bce52235a2d62befe42d2722e53d9
# Parent  75456ed9654995f0dcdbd6a54015f08deca58160
some typo and better french translation

diff -r 75456ed96549 -r 746a888fb41b fr/ch06-collab.xml
--- a/fr/ch06-collab.xml	Mon Nov 30 10:57:15 2009 +0100
+++ b/fr/ch06-collab.xml	Mon Nov 30 10:57:42 2009 +0100
@@ -16,7 +16,7 @@
     <title>Interface web de Mercurial</title>
 
     <para id="x_44b">Mercurial possède une interface web puissante qui
-      propose plusieurs capacités utiles.</para>
+      propose plusieurs fonctions utiles.</para>
 
     <para id="x_44c">Pour une utilisation intensive, l'interface web vous
       permet de naviguer dans un ou une collection de dépôt. Vous pouvez voir
@@ -26,7 +26,7 @@
       graphique de la relation entre les modifications individuelles et les
       fusions (merge).</para>
 
-    <para id="x_44d">De plus, pour la consommation humaine, l'interface web
+    <para id="x_44d">De plus, pour l'utilisation humaine, l'interface web
       fournit des flux Atom et RSS des changements dans un dépôt. Ceci vous
       permet de <quote>souscrire</quote> à un dépôt en utilisant votre
       lecteur de flux favori, et être automatiquement avertis de l'activité
@@ -41,7 +41,7 @@
       ci, et (lorsque le serveur est configuré pour l'autoriser) lui envoyer
       (push) des changements. Le protocole de tunnel HTTP de Mercurial
       compresse agressivement les données, ainsi, il fonctionne efficacement,
-      même au dessus des réseaux avec une bande passante faible.</para>
+      même au-dessus des réseaux avec une faible bande passante.</para>
 
     <para id="x_44f">La plus simple façon de démarrer avec l'interface
       utilisateur est d'utiliser votre navigateur web pour visiter un dépôt
@@ -54,22 +54,22 @@
     <para id="x_69d">La façon la plus simple et la plus rapide pour commencer
       dans un environnement informel est d'utiliser la commande <command
         role="hg-cmd">hg serve</command> qui est la plus adaptée à un service
-      à court terme et <quote>léger</quote>. Référez vous à <xref
-        linkend="sec:collab:serve"/> plus pas pour les détails d'utilisation
+      à court terme et <quote>léger</quote>. Référez-vous à <xref
+        linkend="sec:collab:serve"/> plus bas pour les détails d'utilisation
       de cette commande.</para>
 
     <para id="x_69e">Pour des dépôts dont la durée de vie est plus longue, où
       vous voudriez un service accessible en permanence, il existe plusieurs
       services publics d'hébergement qui sont accessibles. Certains sont
       libres et gratuits pour les projets Open Source, alors que d'autres
-      offrent un hébergement commercial et payant. Une lise à jour est
+      offrent un hébergement commercial et payant. Une liste à jour est
       disponible à l'adresse : <ulink
         url="http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting">http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting</ulink>.</para>
 
     <para id="x_6a0">Si vous préférez héberger vos propres dépôts, Mercurial
-      possède un support intégré pour plusieurs technologies pupulaires
+      possède un support intégré pour plusieurs technologies populaires
       d'hébergement, plus particulièrement CGI (Common Gateway Interface) et
-      WSGI (Web Services Gateway Interface). Référez vous à <xref
+      WSGI (Web Services Gateway Interface). Référez-vous à <xref
         linkend="sec:collab:cgi"/> pour des détails sur la configuration CGI
       et WSGI.</para>
   </sect1>
@@ -77,9 +77,9 @@
   <sect1>
     <title>Modèles de collaboration</title>
 
-    <para id="x_451">Avec un outil convenablement flexible, faire des
-      décisions sur les workflow est plus un problème d'ingénierie sociale
-      qu'un problème technique. Mercurial n'impose que peu de limitations sur
+    <para id="x_451">Avec un outil convenablement flexible, prendre des
+      décisions sur les workflows est plus un problème d'ingénierie sociale
+      qu'un problème technique. Mercurial impose peu de limitations sur
       la façon dont vous pouvez structurer le flux de travail dans un projet,
       donc, c'est à vous et votre groupe de fixer et vivre avec un modèle qui
       convient à vos besoins particuliers.</para>
@@ -105,15 +105,15 @@
         détails du modèle que je préconisais.</para>
 
       <para id="x_454">Ne balayez pas les problèmes sociaux ou techniques de
-        la main. Quelquesoit le schéma que vous promulguez, vous devriez
-        plannifier un protocole pour prévenir, ou rapidement vous relever de
+        la main. Quelque soit le schéma que vous établirez, vous devriez
+        planifier un protocole pour prévenir, ou rapidement vous relever de
         troubles que vous pouvez anticiper. Par exemple, si vous vous
-        attentez à avoir une branche pour les changements pas-pour-release,
-        vous devriez penser très tôt sur la possibilité qu'une personne
+        attendez à avoir une branche pour les changements pas-pour-release,
+        vous devriez penser très tôt à la possibilité qu'une personne
         fusionne (merge) accidentellement ces changements avec une branche de
         release. Vous pouvez empécher ce problème particulier en écrivant un
         hook qui prévient les changements d'être fusionnés à partir d'une
-        branche inapropriée.</para>
+        branche inopportune.</para>
     </sect2>
 
     <sect2>
@@ -128,9 +128,9 @@
         de collaborateurs qui ne se rencontre physiquement que très rarement.
         Certains groupes aiment vaincre l'isolation du travail à distance en
         organisant occasionnellement des <quote>sprints</quote>. Dans un
-        sprint, le nombre de personne qui viennent ensemble dans un même
-        localité (la salle de conférence d'une companie, la salle de réunion
-        d'un hotel, ce type d'endroit) et y passe plusieurs jours, plus ou
+        sprint, des personnes viennent ensemble dans un même
+        endroit (la salle de conférence d'une société, la salle de réunion
+        d'un hôtel, ce genre d'endroit) et y passent plusieurs jours, plus ou
         moins enfermés, et hackant intensément sur une poignée de
         projets.</para>
 
@@ -139,18 +139,18 @@
           role="hg-cmd">hg serve</command> puisque <command role="hg-cmd">hg
           serve</command> n'a pas besoin d'une infrastructure extraordinaire
         de serveurs. Vous pouvez commencer avec la commande <command
-          role="hg-cmd">hg serve</command> en un moment, en lisant <xref
+          role="hg-cmd">hg serve</command> en quelques instants, en lisant <xref
           linkend="sec:collab:serve"/> plus bas  Ensuite, dites simplement à
-        la personne à coté de vous que vous exécutez un serveur, envoyez lui
+        la personne à côté de vous que vous exécutez un serveur, envoyez-lui
         l'URL par un message instantané, et vous avez immédiatement un moyen
         simple et rapide de travailler ensemble. Ils peuvent taper votre URL
-        dans leur navigateur web et rapidement avoir une revue des
+        dans leur navigateur web et rapidement revoir vos
         changements ; ou ils peuvent récupérer chez vous un bugfix et le
         vérifier ; ou ils peuvent cloner une branche contenant une nouvelle
         fonctionnalité et la tester.</para>
         
       <para id="x_458">Le charme et le problème en faisant les choses ainsi,
-        dans une mode ad-hoc est que seules les personnes qui sont au courant
+        dans un mode ad-hoc est que seules les personnes qui sont au courant
         de vos changements, et de leur emplacement, peuvent les voir. Une
         telle approche informelle ne passe simplement pas à l'échelle au delà
         d'une poignée de personnes, puisque chacun a besoin de connaître
@@ -165,7 +165,7 @@
         outil de gestion de révision centralisé, la façon la
         plus simple de commencer est certainement d'avoir un flux de
         changement à partir d'un unique dépôt central. Il s'agit aussi du
-        <quote>bloc de construction</quote> pour des schémas de workflow plus
+        <quote>composant</quote> pour des schémas de workflow plus
         ambitieux.</para>
 
       <para id="x_45a">Les contributeurs commencent par cloner une copie de
@@ -177,10 +177,10 @@
 
       <para id="x_45b">Dans ce modèle, il peut encore être sensé pour les
         gens de récupérer les changements directement entre eux, sans passer
-        par le dépôt central. Considérez le cas où j'ai une tentative de bug
-        fix, mais je m'inquiète de savoir si, dans le cas où je la publiais,
+        par le dépôt central. Considérez le cas où j'ai un bug
+        fix provisoire, mais je m'inquiète de savoir si, dans le cas où je le publiais,
         cela ne casserait pas l'arbre des autres contributeurs s'ils la
-        récupèrerais. Pour réduire les dommages potentiels, je peux vous
+        récupèreraient. Pour réduire les dommages potentiels, je peux vous
         demander de cloner mon dépôt dans un dépôt temporaire qui vous
         appartient et de le tester. Ceci nous permet de ne pas publier les
         modification potentiellement dangereuses tant qu'elles n'ont pas
@@ -203,16 +203,16 @@
 
       <para id="x_6a1">Une chose magnifique au sujet des services
         d'hébergement comme <ulink
-          url="http://bitbucket.org/">Bitbucket</ulink> est qu'ils ne font
-        pas seulement gérer les détails minutieux de la configuration du
-        serveur, tels que les comptes utilisateur, l'authentification, les
+          url="http://bitbucket.org/">Bitbucket</ulink> est qu'ils ne gèrent
+        pas uniquement les détails minutieux de la configuration du
+        serveur, tels que les comptes utilisateurs, l'authentification, les
         protocoles sécurisés, ils fournissent aussi une infrastructure
-        additionnelle pour faire en sorte que ce modèle fonctionne
+        additionnelle pour que ce modèle fonctionne
         bien.</para>
 
       <para id="x_6a2">Par exemple, un service d'hébergement bien conçu
         laissera les personnes cloner leurs copies d'un dépôt à l'aide d'un
-        simple click. Ceci laisse les personnes travailler dans des espaces
+        simple clic. Ceci laisse les personnes travailler dans des espaces
         séparés et partager leurs changements lorsqu'ils sont prêts.</para>
 
       <para id="x_6a3">De plus, un bon service d'hébergement laissera les
@@ -243,7 +243,7 @@
         <quote>direction de développement</quote> peut vivre dans son propre
         dépôt central, et vous pouvez récupérez les changements de l'un ou
         l'autre lorsque le besoin s'en fait sentir. Parce que les dépôts sont
-        indépendant les un des autres, les modifications instables dans une
+        indépendant les uns des autres, les modifications instables dans une
         branche de développement n'affecteront jamais une branche stable,
         sauf si quelqu'un fusionne (merge) explicitement ces changements dans
         la branche stable.</para>
@@ -265,13 +265,13 @@
     
       &interaction.branching.tag;
 
-      <para id="x_462">Disons que du developpement continue a lieu sur la
+      <para id="x_462">Disons que du developpement continue sur la
         branche principale.</para>
 
       &interaction.branching.main;
 
-      <para id="x_463">En utilisant le tag qui enregistre l'étape importante,
-        les gens qui clonenent ce dépôt peuvent à tout moment dans le futur
+      <para id="x_463">En utilisant le tag enregistré à l'étape importante,
+        les gens qui clonent ce dépôt peuvent à tout moment dans le futur
         utiliser la commande <command role="hg-cmd">hg update</command> pour
         avoir une copie du répertoire de travail exactement comme il était
         lorsque cette révision "tag" a été committée.</para>
@@ -319,9 +319,9 @@
 
     <sect2>
       <title>Feature branches</title>
-
+<!-- TODO : Branches de fonctionnalité ? -->
       <para id="x_469">Pour de plus gros projets, une façon efficace de gérer
-        les changements est de casser l'équipe en plus pettis groupes. Chaque
+        les changements est de diviser l'équipe en plus petits groupes. Chaque
         groupe a une branche partagée qui lui est attitrée, clonée à partir
         d'une unique branche <quote>principale</quote> utilisée pour le
         projet entier. Les personnes travaillant sur une branche individuelle
@@ -337,8 +337,8 @@
       </figure>
 
       <para id="x_46b">Lorsqu'une fonctionnalité particulière est réputée
-        pour être dans une forme adaptée, quelqu'un de l'équipe qui s'occupe
-        de cette fonctionnalité récupère les changements (pull) à partir de
+        pour être dans une forme adaptée, quelqu'un de l'équipe qui s'en occupe
+        récupère les changements (pull) à partir de
         la branche principale vers la branche de cette fonctionnalité,
         fusionne (merge) et renvoie (push) le tout vers la branche
         principale.</para>
@@ -347,10 +347,11 @@
     <sect2>
       <title>Le train des releases</title>
 <!-- J'ai laissé train en traduction à train mais peut être que suite, file,
-... sont des mots qui conviennent mieux ? A méditer -->
+... sont des mots qui conviennent mieux ? À méditer -->
+<!-- Je mettrais suite -->
 
       <para id="x_46c">Certains projets sont organisés comme un
-        <quote>train</quote> basique : une release est planifiée tous les
+        <quote>train</quote> élémentaire : une release est planifiée tous les
         quelques mois, et, toutes les fonctionnalités disponibles lorsque le
         <quote>train</quote> est prêt à s'arrêter sont autorisées ici.
 
@@ -359,13 +360,13 @@
         fonctionnalité rate le train, quelqu'un de l'équipe qui travaille sur
         cette fonctionnalité récupère (pull) et fusionne (merge) ce qui a été
         ajouté à la release du train dans la branche de la fonctionnalité,
-        puis, l'équipe continue son travail au dessus de cette release afin
+        puis, l'équipe continue son travail au-dessus de cette release afin
         que leur fonctionnalité puisse être ajoutée à la prochaine
         release.</para>
     </sect2>
 
     <sect2>
-      <title>Le modèle du Noyau Linux</title>
+      <title>Le modèle du noyau Linux</title>
 
       <para id="x_46e">Le développement du noyau Linux est doté d'une
         structure hiérarchique superficielle, entourée par un nuage de chaos
@@ -376,21 +377,20 @@
         vous aimez ces idées, l'approche se traduit correctement à travers
         les outils.</para>
 
-      <para id="x_46f">Au centre de la communauté siège Linux Torvalds, le
-        créateur de Linux. Il publie un unique dépôt de sources qui est
-        considéré comme faisant <quote>authorité</quote> sur l'arborescence
+      <para id="x_46f">Au centre de la communauté siège Linus Torvalds, le
+        créateur de Linux. Il publie un dépôt unique de sources qui est
+        considéré comme faisant <quote>autorité</quote> sur l'arborescence
         par la communauté entière de développeurs. Tout le monde peut cloner
-        l'arbre de Linus, mais il est très difficile d'être choisi pour que
-        ses changements soient intégrés à l'arbre principal.</para>
-
-      <para id="x_470">Linus a plusieurs <quote>leutenants de
+        l'arbre de Linus, mais il ne récupère (pull) pas les changements de n'importe quelle arborescence.</para>
+
+      <para id="x_470">Linus a plusieurs <quote>lieutenants de
           confiance</quote>. Comme règle générale, il récupère (pull) tous
         les changements qu'ils publient, dans la plupart des cas sans même
         relire ces modifications. Certains de ces lieutenants sont
         généralement autorisés à être <quote>mainteneurs</quote>,
-        responsables pour un sous-système spécifique du noyau. Si un kernel
-        hacker aléatoire veut apporter des modification au sous-système
-        qu'ils veut voir intégré à l'arbre de Linus, il doit trouver qui est
+        responsables pour un sous-système spécifique du noyau. Si un 
+        hacker du noyau veut apporter des modification au sous-système
+        qu'il veut voir intégré à l'arbre de Linus, il doit trouver 
         le mainteneur du sous-système, et lui demander de récupérer ses
         changements. Si le mainteneur relit ses changements et les accepte,
         ils seront transmis à Linus le moment venu.</para>
@@ -408,51 +408,51 @@
 
       <para id="x_472">Ce modèle a deux caractéristiques remarquables. La
         première est qu'il s'agit de <quote>pull seulement</quote>. Vous
-        devez demander, convaincre, ou mendier au près d'un autre développeur
-        pour prendre vos modifications, puiqu'il n'y a vraissemblablement pas
-        d'abre où plus d'une personne peut envoyer des changement (push), et
+        devez demander, convaincre, ou mendier auprès d'un autre développeur
+        pour prendre vos modifications, puisqu'il n'y a vraisemblablement pas
+        d'arbre où plus d'une personne peut envoyer des changements (push), et
         qu'il n'y a pas de possibilité d'envoyer des changements (push) vers
         un arbre que quelqu'un d'autre contrôle.</para>
 
       <para id="x_473">La seconde est que c'est basé sur la réputation et
         l'acclamation. Si vous êtes un inconnu, Linus va probablement ignorer
-        vos changement sans même répondre. Cependant, un mainteneur de
+        vos changements sans même répondre. Cependant, un mainteneur de
         sous-système les relira probablement, et les acceptera sûrement s'ils
-        passent ses critaires d'acceptation. Plus vous contriburez du
-        <quote>bon</quote> code à un mainteneur, et plus celui ci aura
-        confiance en votre jugement pour accepter vos changements. Si vous
+        passent ses critères d'acceptation. Plus vous enverrez du
+        <quote>bon</quote> code à un mainteneur, et plus celui-ci aura
+        confiance en votre jugement et acceptera vos changements. Si vous
         êtes bien connu et maintenez une branche ancienne pour quelque chose
         que Linus n'a pas encore accepté, les gens avec un intérêt similaire
         devraient récupérer vos changements régulièrement pour rester à jour
-        vis à vis de votre travail.</para>
+        vis-à-vis de votre travail.</para>
 
       <para id="x_474">La réputation et l'acclamation ne nécessite pas de
-        système croisé ou de limites <quote>personnelles</quote>. Si vous
+        système croisé ou de limites <quote>entre les gens</quote>. Si vous
         êtes respectés mais que vous êtes un hacker spécialisé dans la
         sauvegarde, et que vous tentez de corriger un bug réseau, ce
-        changement recevra un examen approfondu de la part du mainteneur
+        changement recevra un examen approfondi de la part du mainteneur
         responsable du réseau comparable à celui d'un total étranger.</para>
 
       <para id="x_475">Pour les personnes qui viennent d'un projet dont
-        l'arrière plan est plus ordonné, le processus chaotique de
-        développement du noyau Linux en comparaison apparaît totalement
-        dément. C'est le sujet de bien des caprices d'individualistes ;
-        des personnes qui balayent les changements même s'ils croient que
-        c'est approprié ; et l'allure du développement de Linux est
-        ahurissant. Et pourtant, Linux est un bout de logiciel d'une grande
+        le milieu est plus ordonné, le processus chaotique de
+        développement du noyau Linux en comparaison apparaît souvent totalement
+        dément. C'est sujet aux caprices d'individus ;
+        des personnes font des changements considérables quand ils les
+        jugent appropriés ; et l'allure du développement est
+        ahurissante. Et pourtant, Linux est un bout de logiciel d'une grande
         réussite et bien considéré.</para>
     </sect2>
 
     <sect2>
       <title>Collaboration pull seulement versus pull partagé</title>
 
-      <para id="x_476">Une source perpétuelle de heurs dans une communauté
-        opensource est si un modèle de développement est celui où les
-        personnes ne peuvent que récupérer (pull) les changements ou l'autre
-        <quote>meilleur</quote> dans lequel de multiples personnes peuvent
+      <para id="x_476">Une source perpétuelle de heurts dans la communauté
+        opensource est de savoir si un modèle de développement où les
+        personnes ne peuvent que récupérer (pull) les changements d'autres est
+        <quote>meilleur</quote> que celui dans lequel de multiples personnes peuvent
         envoyer (push) leurs changements vers un dépôt partagé.</para>
 
-      <para id="x_477">Typiquement, les bailleurs de fonds du modèle push
+      <para id="x_477">Typiquement, les partisans du modèle push
         partagé utilisent des outils qui renforcent activement cette
         approche. Si vous utilisez un outil centralisé de gestion de révision
         comme Subversion, il n'y a pas la possibilité de choisir quel modèle
@@ -463,7 +463,7 @@
       <para id="x_478">Un bon outil de gestion distribuée de révisions doit
         supporter les deux modèles. Vous et vos collaborateurs pouvez ensuite
         structurer la façon dont vous travaillez ensemble en vous basant sur
-        vos besoins et vos préférences, et non sur les contortions que vos
+        vos besoins et vos préférences, et non sur les contorsions que vos
         outils vous forcent à effectuer.</para>
     </sect2>
     <sect2>
@@ -472,18 +472,18 @@
       <para id="x_479">Lorsque vous et votre équipe configurez des dépôts
         partagés et commencez à propager vos changement dans tous les sens
         entre les dépôts locaux et partagés, vous commencez à être face à un
-        challenge apparenté, mais un peu différent : celui de gérer les
+        défi connexe, mais un peu différent : celui de gérer les
         multiples directions vers lesquelles votre équipe pourrait aller au
         même moment. Même si ce sujet est intimement lié à la façon dont
-        votre équipe collabore, il est suffisement dence pour mériter un
+        votre équipe collabore, il est suffisement dense pour mériter un
         traitement à part dans <xref linkend="chap:branch"/>.</para>
     </sect2>
   </sect1>
 
   <sect1>
-    <title>Le coté technique du partage</title>
-
-    <para id="x_47a">Le reste de ce chapitre est dévoué à la question du
+    <title>Le côté technique du partage</title>
+
+    <para id="x_47a">Le reste de ce chapitre est consacré à la question du
       partage des changements avec vos collaborateurs.</para>
   </sect1>
 
@@ -498,14 +498,14 @@
       réseau.</para>
 
     <para id="x_47c">Exécutez <command role="hg-cmd">hg serve</command> à
-      l'intérieur d'un dépôtn et en moins d'une seconde, cela mettra en place
+      l'intérieur d'un dépôt et en moins d'une seconde, cela mettra en place
       un serveur HTTP spécialisé ; qui va accepter les connexions de tout
-      client, et servir les donnée pour ce dépôt jusqu'à ce que vous le
-      terminiez. Toute personne qui connaît l'URL du serveur que vous venez
+      client, et servir les données pour ce dépôt jusqu'à ce que vous 
+      l'arrêtiez. Toute personne qui connaît l'URL du serveur que vous venez
       de démarrer, peut ensuite utiliser un navigateur web ou Mercurial pour
       lire les données de ce dépôt. Une URL pour une instance exécutée de 
       <command role="hg-cmd">hg serve</command> sur un ordinateur portable
-      ressemblera vraissemblablement à
+      ressemblera vraisemblablement à
       <literal>http://my-laptop.local:8000/</literal>.</para>
 
     <para id="x_47d">La commande <command role="hg-cmd">hg serve</command>
@@ -527,7 +527,7 @@
       utilisation en lecture seule.</para>
 
     <para id="x_481">Si vous commencez avec Mercurial, il n'y a rien qui vous
-      empèche d'utiliser <command role="hg-cmd">hg serve</command> pour
+      empêche d'utiliser <command role="hg-cmd">hg serve</command> pour
       publier un dépôt sur votre ordinateur, utilisez ensuite des commandes
       telles que <command role="hg-cmd">hg clone</command>, <command
         role="hg-cmd">hg incoming</command>, et ainsi de suite pour parler à
@@ -538,19 +538,19 @@
     <sect2>
       <title>Quelques choses à garder à l'esprit</title>
 
-      <para id="x_482">Puisque ceci fournit un accès en lecture sans
+      <para id="x_482">Puisque il fournit un accès en lecture sans
         authentification à tous les clients, vous devriez utiliser la
         commande <command role="hg-cmd">hg serve</command> dans un
-        environnement dans lequel vous ne vous inquiétez pas ou où vous avez
+        environnement où vous ne vous inquiétez pas ou vous avez
         tout contrôle sur qui peut avoir accès au réseau et récupérer les
         données de votre dépôt.</para>
 
       <para id="x_483">La commande <command role="hg-cmd">hg serve</command>
-        ne connaît sait rien sur un quelconque firewall que vous auriez
+        ne sait rien sur un quelconque firewall que vous auriez
         installé sur votre système ou réseau. Elle ne peut pas détecter ou
         contrôler votre logiciel de pare-feu. Si d'autre personnes ont la
         possibilité de dialoguer avec une instance de <command
-          role="hg-cmd">hg serve</command> ma seconde chose que vous devriez
+          role="hg-cmd">hg serve</command> la seconde chose que vous devriez
         faire (<emphasis>après</emphasis> être sûr qu'ils utilisent l'URL
         correcte) est de vérifier la configuration de votre firewall.</para>
 
@@ -573,26 +573,26 @@
     <title>Utiliser le protocole Secure Shell (ssh)</title>
 
     <para id="x_486">Vous pouvez récupérer (pull) ou envoyer (push) des
-      changements de façon sécurisé au dessus d'une connexion utilisatnt le
+      changements de façon sécurisé au dessus d'une connexion utilisant le
       protocole Secure Shell (<literal>ssh</literal>). Pour l'utiliser avec
-      succès, vous pouriez avoir à faire un peu de configuration du coté
+      succès, vous pourriez avoir à faire un peu de configuration du côté
       client ou serveur.</para>
 
     <para id="x_487">Si vous n'êtes pas familiers avec ssh, c'est le nom de
       la commande et d'un protocole réseau qui vous permet d'établir une
       communication sécurisée avec un autre ordinateur. Pour l'utiliser avec
-      Mercurial, vous allez configurer un ou plusieurs comptes utilisateur
-      sur un serveur, comme ça, les utilisateurs distants peuvent logger et
+      Mercurial, vous allez configurer un ou plusieurs comptes utilisateurs
+      sur un serveur, comme ça, les utilisateurs distants peuvent se connecter et
       exécuter les commandes.</para>
 
     <para id="x_488">(Si vous <emphasis>êtes</emphasis> familiers avec ssh,
-      vous allez probablement trouver quelques une des informations qui
+      vous allez probablement trouver quelques-unes des informations qui
       suivent élémentaires par nature.)</para>
 
     <sect2>
       <title>Comment lire et écrire des URLs ssh</title>
 
-      <para id="x_489">Une URL ssh tent à ressembler à ceci :</para>
+      <para id="x_489">Une URL ssh a tendance à ressembler à ceci :</para>
       <programlisting>ssh://bos@hg.serpentine.com:22/hg/hgbook</programlisting>
       <orderedlist>
         <listitem><para id="x_48a">Le préfixe
@@ -601,49 +601,49 @@
         </listitem>
         <listitem><para id="x_48b">Le composant
             <quote><literal>bos@</literal></quote> indique que le nom
-            d'utilisateur à logger sur le serveur. Vous pouvez le laisser
+            d'utilisateur à connecter sur le serveur. Vous pouvez le laisser
             vide si le nom d'utilisateur sur le serveur distant est le même
             que localement.</para>
         </listitem>
         <listitem><para id="x_48c">La partie
             <quote><literal>hg.serpentine.com</literal></quote> donne le nom
-            d'hôte du serveur sur lequel se logger.</para>
+            d'hôte du serveur sur lequel se connecter.</para>
         </listitem>
         <listitem><para id="x_48d">Le <quote>:22</quote> identifie le numéro
             de port où se connecter au serveur. Le port par défaut est 22,
-            donc vous n'avez besoin de spécifier ceci que si vous
+            donc vous avez besoin de spécifier ceci que si vous
             <emphasis>n'</emphasis>utilisez <emphasis>pas</emphasis> le port
             22.</para>
         </listitem>
         <listitem><para id="x_48e">Le reste de l'URL est le chemin local du
             dépôt sur le serveur.</para></listitem></orderedlist>
     
-      <para id="x_48f">Il y a beaucoup de place pour la confusion sur le
+      <para id="x_48f">Il y a beaucoup de risque de confusion sur le
         chemin du composant d'une URL ssh puisqu'il n'y a pas de façon
-        standard pour les outils de l'intérpréter. Certains programmes se
-        comportent différemment des autres lorsqu'ils traient ces chemins. Il
+        standard pour les outils de l'interpréter. Certains programmes se
+        comportent différemment des autres lorsqu'ils traitent ces chemins. Il
         ne s'agit pas d'une situation idéale, mais ce n'est pas prêt de
-        changer. Lisez SVP les prochains paragraphes avec attention.</para>
+        changer. Lisez les prochains paragraphes avec attention.</para>
 
       <para id="x_490">Mercurial traite le chemin vers un dépôt sur le
         serveur comme relatif au répertoire personnel de l'utilisateur sur le
         serveur distant. Par exemple, si un utilisateur
         <literal>foo</literal> sur le serveur a un répertoire personnel
         <filename class="directory">/home/foo</filename>, alors l'URL ssh qui
-        vientient un composant chemin de <filename
+        contient un composant chemin de <filename
           class="directory">bar</filename> réfère en
         <emphasis>réalité</emphasis> au répertoire <filename
           class="directory">/home/foo/bar</filename>.</para>
 
-      <para id="x_491">Si vous voulez spécifier un chemin relatif à au
+      <para id="x_491">Si vous voulez spécifier un chemin relatif au
         répertoire personnel d'un autre utilisateur, vous pouvez préciser un
-        chemin qui commence à l'aide du caractère tilde suivit du nom de
+        chemin qui commence à l'aide du caractère tilde suivi du nom de
         l'utilisateur (appelons le <literal>otheruser</literal>),
         ainsi.</para>
       <programlisting>ssh://server/~otheruser/hg/repo</programlisting>
 
       <para id="x_492">Et si vous voulez vraiment spécifier un chemin
-        <emphasis>absolu</emphasis> sur le serveur, débutez la composante
+        <emphasis>absolu</emphasis> sur le serveur, débutez le composant
         chemin par deux slashs comme dans cet exemple.</para>
       <programlisting>ssh://server//absolute/path</programlisting>
     </sect2>
@@ -656,29 +656,29 @@
         <literal>which ssh</literal> pour trouver où la commande
         <command>ssh</command> est installée (il s'agit généralement de
         <filename class="directory">/usr/bin</filename>). Dans le cas peu
-        probable où il ne serait pas présent, regarder à la documentation de
+        probable où il ne serait pas présent, regarder la documentation de
         votre système pour voir comment l'installer.</para>
 
-      <para id="x_494">Sous Windows, le packetage ToirtoiseHg est livré avec
+      <para id="x_494">Sous Windows, le paquet TortoiseHg est livré avec
         une version de l'excellente commande <command>plink</command> de
-        Simon Tatham's, et ne devrait pas avoir besoin de plus de
+        Simon Tatham, et ne devrait pas avoir besoin de plus de
         configuration.</para>
     </sect2>
 
     <sect2>
-      <title>Générer une paire de clef</title>
+      <title>Créer une paire de clef</title>
 
       <para id="x_499">Pour éviter d'avoir à chaque fois taper un mot de
-        passe lorsque vous utilisez votre client ssh, je recommande le fait
-        de générer une paire de clefs.</para>
+        passe lorsque vous utilisez votre client ssh, je recommande 
+        de créer une paire de clefs.</para>
 
       <tip>
         <title>Les paires de clefs ne sont pas obligatoires</title>
       
         <para id="x_6a4">Mercurial ne sait rien du tout de l'authentification
           de ssh ou de la paire de clefs. Vous pouvez, si vous le désirez,
-          ignorer sans risque cette section et ce qu'il suit jusqu'à ce que
-          vous soyez fatigué de constament retaper des mots de passe
+          ignorer sans risque cette section et la suivante jusqu'à ce que
+          vous soyez fatigué de constamment retaper des mots de passe
           ssh.</para>
       </tip>
 
@@ -686,25 +686,25 @@
         <listitem> <para id="x_6a5">Sur un système de type Unix, la commande
             <command>ssh-keygen</command> fera l'affaire.</para></listitem>
         <listitem> <para id="x_6a6">Sous Windows, si vous utilisez
-            ToirtoiseHg, vous devriez avoir besoin de télécharger la commande
+            TortoiseHg, vous devriez avoir besoin de télécharger la commande
             nommée <command>puttygen</command> à partir du <ulink
               url="http://www.chiark.greenend.org.uk/~sgtatham/putty">site
-              web de PuTTY</ulink> pour générer une paire de clefs.  Référez
-            vous à <ulink
+              web de PuTTY</ulink> pour créer une paire de clefs.  Référez-vous
+               à <ulink
               url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter8.html#pubkey-puttygen">la
               documentation <command>puttygen</command></ulink> pour les
             détails sur l'utilisation de cette commande.</para></listitem>
       </itemizedlist>
 
-      <para id="x_49a">Lorsque vous générez une paire de clefs, il est
-        habituellement <emphasis>autement</emphasis> recommendé de la
+      <para id="x_49a">Lorsque vous créez une paire de clefs, il est
+        habituellement <emphasis>hautement</emphasis> recommandé de la
         protéger avec un mot de passe. (Le seul moment où vous pourriez ne
         pas devoir le faire est lorsque vous utilisez le protocole ssh pour
         des tâches automatisées sur un réseau sécurisé.)</para>
 
-      <para id="x_49b">Le simple fait de générer une paire de clefs n'est
-        cependant pas suffisent. Vous aurez besoin d'ajouter la clef publique
-        à l'ensemble des clefs authorisées pour tout utilisateur que vous
+      <para id="x_49b">Le simple fait de créer une paire de clefs n'est
+        cependant pas suffisant. Vous aurez besoin d'ajouter la clef publique
+        à l'ensemble des clefs autorisées pour tout utilisateur que vous
         utilisez pour vous connecter à distance. Pour les serveurs utilisant
         OpenSSh (la grande majorité), ceci voudra dire d'ajouter la clef
         publique à la liste dans un fichier appelé <filename
@@ -723,15 +723,15 @@
 
       <para id="x_49d">Un agent d'authentification est un démon qui
         enregistre les mots de passe en mémoire (il oublira ainsi les mots de
-        passe si vous vous déloggez et reloggez). Un client ssh sera averti
+        passe si vous vous déconnectez et reconnectez). Un client ssh sera averti
         si un tel agent est en fonctionnement, et lui demandera un mot de
         passe. S'il n'y a pas d'agent en fonctionnement, ou si l'agent ne
         connaît pas le mot de passe nécessaire, vous aurez à taper votre mot
         de passe chaque fois que Mercurial tente de communiquer avec un
-        serveur en votre nom (ex. lorsque vous faite un pull ou un push sur
-        des changements).</para>
-
-      <para id="x_49e">L'inconveignant de sauvegarder les mots de passes dans
+        serveur en votre nom (ex. lorsque vous faite un pull ou un push 
+        de changements).</para>
+
+      <para id="x_49e">L'inconvénient de sauvegarder les mots de passes dans
         un agent est qu'il est possible pour un attaquant bien préparé de
         retrouver le mot de passe clair, dans certains cas, même si votre
         système a été redémarré. Vous devriez vous faire votre propre
@@ -741,12 +741,12 @@
       <itemizedlist>
         <listitem> <para id="x_49f">Sur les systèmes de type Unix, l'agent
             est appelé <command>ssh-agent</command>, et est souvent lancé
-            automatiquement pour vous lorsque vous vous loggez. Vous aurez
+            automatiquement pour vous lorsque vous vous connectez. Vous aurez
             besoin d'utiliser la commande <command>ssh-add</command> pour
             ajouter des mots de passe à l'entrepôt de l'agent.</para>
         </listitem>
         <listitem>
-          <para id="x_6a7">Sous Windows, si vous utilisez ToirtoiseHg, la
+          <para id="x_6a7">Sous Windows, si vous utilisez TortoiseHg, la
             commande <command>pageant</command> agit comme un agent. Comme
             avec <command>puttygen</command>, vous aurez besoin de <ulink
               url="http://www.chiark.greenend.org.uk/%7Esgtatham/putty/download.html">télécharger
@@ -754,11 +754,13 @@
             PuTTY et lire <ulink
               url="http://the.earth.li/~sgtatham/putty/0.60/htmldoc/Chapter9.html#pageant">sa
               documentation</ulink>.  La commande <command>pageant</command>
-            ajoute une icône à votre barre de tâches qui vous permettra de
+            ajoute une icône à votre zone de notification (à droite de la barre
+            de tâches) qui vous permettra de
             gérer les mots de passe stockés.</para></listitem>
           <!-- TODO : J'ai traduit system tray par barre des tâches, mais ne
           conaissant pas windows, je ne suis pas sûr du nom réel. A corriger
           le cas échéant ! -->
+          <!-- J'ai précisé avec ce que j'ai trouvé sur Wikipedia -->
       </itemizedlist>
     </sect2>
 <!-- TODO : part 2/4 -->