Miscellaneous changes to enhance overall coherence of the french translations

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1328 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developers-reference.fr.sgml b/developers-reference.fr.sgml
index 8fc9aceb4a98d322f369311e90aaaaecd1068ae8..b93f9a34ba89b091782b7c57bb3a10a462a5763c 100644 (file)
--- a/developers-reference.fr.sgml
+++ b/developers-reference.fr.sgml
@@ -5,7 +5,7 @@
   <!-- common, language independant entities -->
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.19 $">
+  <!entity cvs-rev "$Revision: 1.20 $">
 
   <!-- if you are translating this document, please notate the RCS
        revision of the developers reference here -->
@@ -26,15 +26,14 @@
 
 
 <book>
-<title>Manuel de référence du développeur Debian
+<title>Référence du développeur Debian
 
 <author>Adam Di Carlo, responsable actuel <email>aph@debian.org</email>
 <author>Christian Schwarz <email>schwarz@debian.org</email>
 <author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
 <author>&nbsp;
-<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.fr</email>
-<author>avec la participation de Alain Meessen
-<author>et des membres de la liste
+<author>version française par Antoine Hulin <email>antoine.hulin@origan.fdn.org</email>
+<author>et les membres de la liste
 <email>debian-l10n-french@lists.debian.org</email>
 <version>version &version;, &date-fr;
 
@@ -527,15 +526,15 @@ transmettre ces rapports de bogue aux d
 corrigés dans les prochaines versions.  Il n'est pas de votre responsabilité
 de corriger les bogues qui ne sont pas spécifiques à Debian. Toutefois,
 si vous êtes capable de le faire, nous vous encourageons à contribuer au
-développement amont en proposant un <em>patch</em> qui corrige ce bogue.
-Les utilisateurs et responsables Debian proposent souvent des <em>patches</em>
-pour corriger des bogues amonts, il vous faudra alors évaluer ce
-<em>patch</em> puis le transmettre aux développeurs amonts.
+développement amont en proposant une rustine qui corrige ce bogue.
+Les utilisateurs et responsables Debian proposent souvent des rustines
+pour corriger des bogues amonts, il vous faudra alors évaluer cette
+rustine puis la transmettre aux développeurs amonts.
 
 <p>
 Si vous avez besoin de modifier les sources d'un logiciel pour fabriquer un
-paquet conforme à la charte Debian, alors vous devriez proposer un
-<em>patch</em> aux développeurs amonts pour qu'il soit inclus dans leur
+paquet conforme à la charte Debian, alors vous devriez proposer une 
+rustine aux développeurs amonts pour qu'elle soit incluse dans leur
 version. Ainsi, vous n'aurez plus besoin de modifier les sources lors des
 mises à jour amonts suivantes.  Quels que soient les changements dont vous
 avez besoin, il faut toujours essayer de rester dans la lignée des sources
@@ -1509,9 +1508,9 @@ Il est fortement d
 important car même une modification triviale peut causer un bogue plus 
 tard. Livrer une nouvelle version amont d'un logiciel pour corriger un 
 problème de sécurité est désapprouvé&nbsp;; dans la plupart des cas la
-bonne solution consiste à prendre le <em>patch</em> correspondant de la
+bonne solution consiste à prendre la rustine correspondante de la
 nouvelle version amont et à l'appliquer à l'ancienne (faire un
-<em>backport</em> du <em>patch</em>).
+portage (<em>backport</em>) de la rustine.
 
 <p>
 Les paquets livrés pour <em>stable</em> doivent être compilés avec la
@@ -1896,9 +1895,9 @@ Seuls les responsables Debian officiels peuvent faire des mises 
 indépendantes. Un responsable officiel est une personne dont la clé est dans
 le porte-clés Debian. Toute personne est invitée à télécharger les paquets
 sources pour corriger des bogues&nbsp;; au lieu de faire des mises à jour
-indépendantes, ils pourront soumettre les <em>patch</em> qui le méritent au
+indépendantes, ils pourront soumettre les rustines qui le méritent au
 système de suivi des bogues. Les responsables apprécient presque toujours les
-<em>patch</em> et les rapports de bogue soignés.
+rustines et les rapports de bogue soignés.
 
 
        <sect id="nmu-when">Quand faire une mise à jour indépendante source&nbsp;?
@@ -1947,7 +1946,7 @@ pas il est probablement correct de faire une mise 
        pour corriger le bogue. Donnez-lui quelques jours.
 
        <item>
-       Lancez-vous. Corrigez le bogue et envoyez votre <em>patch</em> au système de
+       Lancez-vous. Corrigez le bogue et envoyez votre rustine au système de
        suivi des bogues. Construisez le paquet et testez-le comme décrit dans
        la section <ref id="upload-checking">. Utilisez le paquet chez vous.
 
@@ -1992,7 +1991,7 @@ id="porter-guidelines">.
 Tout d'abord il est capital que ces mises à jour indépendantes soient aussi peu
 intrusives que possible. Ne faites pas de ménage, ne modifiez pas le nom des
 modules ou des fichiers, ne déplacez pas les répertoires&nbsp;; plus généralement ne
-corrigez pas ce qui n'est pas cassé.  Faites un <em>patch</em> aussi petit que
+corrigez pas ce qui n'est pas cassé.  Faites une rustine aussi petite que
 possible. Si certaines choses froissent votre sens de l'esthétique, parlez-en
 au responsable du paquet, au responsable amont ou soumettez un rapport de
 bogue. Quoiqu'il en soit, les changements esthétiques <em>ne doivent pas</em>
@@ -2108,15 +2107,15 @@ Cela permet de s'assurer que chacun sait que le bogue est corrig
 à jour indépendante tout en laissant le rapport de bogue ouvert jusqu'à ce que
 le responsable du paquet incorpore les modifications de cette mise à jour dans
 la version officielle du paquet. Si nécessaire, ouvrez des rapports de bogue
-avec les <em>patch</em> correspondants ou assurez-vous que l'un des rapports de
-bogue déjà ouverts comporte ces <em>patch</em>.
+avec les rustines correspondantes ou assurez-vous que l'un des rapports de
+bogue déjà ouverts comporte ces rustines.
 
 <p>
-Le responsable officiel pourra choisir d'appliquer le <em>patch</em>, il pourra aussi
+Le responsable officiel pourra choisir d'appliquer la rustine, il pourra aussi
 employer une autre méthode pour régler le problème. Certains bogues sont
 corrigés dans la version amont, ce qui est une bonne raison pour annuler les
 modifications d'une mise à jour indépendante. Si le responsable choisit de
-mettre à jour le paquet sans utiliser les <em>patch</em> de la mise à jour
+mettre à jour le paquet sans utiliser les rustines de la mise à jour
 indépendante, il devra s'assurer que cette nouvelle version corrige
 effectivement chacun des bogues corrigés dans la mise à jour indépendante.