[gentoo-commits] gentoo commit in xml/htdocs/doc/fr: bugzilla-howto.xml

[Camille Huot (cam)]

cam         07/10/28 12:07:46

  Modified:             bugzilla-howto.xml
  Log:
  Typos fixed.

Revision  Changes    Path
1.3                  xml/htdocs/doc/fr/bugzilla-howto.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml?rev=1.3&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml?r1=1.2&r2=1.3

Index: bugzilla-howto.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- bugzilla-howto.xml	28 Oct 2007 11:09:34 -0000	1.2
+++ bugzilla-howto.xml	28 Oct 2007 12:07:46 -0000	1.3
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml,v 1.2 2007/10/28 11:09:34 titefleur Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/bugzilla-howto.xml,v 1.3 2007/10/28 12:07:46 cam Exp $ -->
 
 <guide link="/doc/fr/bugzilla-howto.xml">
 <title>Guide de rapport de bogue de Gentoo</title>
@@ -201,9 +201,9 @@
 <p>
 Il semble que cette personne avait raison. Puisque le programme est
 effectivement corrompu, nous avons un bogue sous la main. À présent, il est
-temps d'utiliser <c>GDB</c> pour aider à résoudre ce problème. Tout d'abord nous
-lançons <c>GDB</c> avec <c>--args</c> suivi du programme complet avec ses
-arguments comme voici&nbsp;:
+temps d'utiliser <c>GDB</c> pour nous aider à résoudre ce problème. Tout
+d'abord nous lançons <c>GDB</c> avec <c>--args</c> suivi du programme complet
+avec ses arguments comme voici&nbsp;:
 </p>
 
 <pre caption="Exécution de notre programme dans GDB">
@@ -218,7 +218,7 @@
 </pre>
 
 <note>
-On peut également déboguer avec des sauvegardes d'image mémoire (NdT&nbsp;:
+On peut également déboguer avec des sauvegardes d'images mémoires (NdT&nbsp;:
 «&nbsp;core dumps&nbsp;»). Ces fichiers du noyau contiennent les mêmes
 informations que ce que le programme produirait en l'exécutant avec GDB. Pour
 déboguer notre programme bad_code avec un tel fichier, vous devez exécuter
@@ -227,7 +227,7 @@
 </note>
 
 <p>
-Vous devriez voir une invite de commande indiquant «&nbsp;(gdb))&nbsp;» et
+Vous devriez voir une invite de commande indiquant «&nbsp;(gdb)&nbsp;» et
 attendant une saisie clavier. D'abord, nous devons exécuter le programme. En
 écrivant <c>run</c> sur la ligne de commande nous obtenons une information telle
 que celle-ci&nbsp;:
@@ -341,11 +341,11 @@
 à la taille du fichier par rapport à celui qui contient les symboles de
 débogage. Toutefois, comme nous l'avons vu, ce poids supplémentaire peut valoir
 le coup pour présenter les informations de débogage aux développeurs. Le traçage
-peut être sauvegardé dans un fichier en copiant et collant depuis le terminal
-(si c'est un terminal qui n'utilise pas le serveur X, vous pouvez utiliser GPM.
+peut être sauvegardé dans un fichier en copiant et collant depuis le terminal.
+(Si c'est un terminal qui n'utilise pas le serveur X, vous pouvez utiliser GPM.
 Afin de garder cette documentation simple, je vous recommande de lire la
 <uri link="/doc/fr/gpm.xml#doc_chap4">documentation pour GPM</uri> pour voir
-comment copier et coller avec). Maintenant que nous avons fait ce que nous
+comment copier et coller avec.) Maintenant que nous avons fait ce que nous
 devions avec <c>GDB</c>, nous pouvons en sortir.
 </p>
 
@@ -427,7 +427,7 @@
 <p>
 Aha! Voilà donc le problème. Quelqu'un a changé l'emplacement du répertoire de
 configuration vers <path>.foobar2</path> au lieu de <path>.foobar</path>. Nous
-voyons également que le programme lit &nbsp;bar&nbsp;» comme prévu. Dans ce
+voyons également que le programme lit «&nbsp;bar&nbsp;» comme prévu. Dans ce
 cas-ci, nous recommandons au mainteneur de l'ebuild d'ajouter un avertissement à
 ce propos. Pour le moment toutefois, nous pouvons remplacer le fichier de
 configuration avec celui du répertoire <path>.foobar</path> et le modifier afin
@@ -708,9 +708,9 @@
 
 <p>
 Les champs «&nbsp;Product &nbsp;» (NdT&nbsp;: «&nbsp;produit&nbsp;»),
-«&nbsp;Component&nbsp;» (NdT&nbsp;: pour la partie) et «&nbsp;Version &nbsp;»
-vont tous être laissés par défaut. Cela nous évite d'être trop précis et de
-manquer tous les bogues.
+«&nbsp;Component&nbsp;» (NdT&nbsp;: «&nbsp;pour la partie&nbsp;») et
+«&nbsp;Version &nbsp;» vont tous être laissés par défaut. Cela nous évite
+d'être trop précis et de manquer tous les bogues.
 </p>
 
 <p>
@@ -723,9 +723,9 @@
 l'exemple de notre erreur de xclass&nbsp;:
 </p>
 
-<pre caption="Contenu de la ligne commentée">
+<pre caption="Contenu de la ligne Comment">
 menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
-<comment>(Remove the quotes ' ')</comment>
+<comment>(Enlevez la ponctuation ` ' :.)</comment>
 menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu
 </pre>
 
@@ -811,7 +811,7 @@
 Bugzilla"/>
 
 <p>
-Cliquez sur "Report a Bug - Using the guided format" (NdT&nbsp;:
+Cliquez sur «&nbsp;Report a Bug - Using the guided format&nbsp;» (NdT&nbsp;:
 «&nbsp;Rapporter un bogue, utilisation du format guidé&nbsp;»).
 </p>
 
@@ -835,10 +835,10 @@
 <p>
 Une autre idée reçue et qui est fausse concerne nos bogues de documentation.
 Par exemple, un utilisateur trouve un bogue avec la
-<uri link="/proj/en/releng/catalyst/">documentation des Catalyst</uri>. La
+<uri link="/proj/en/releng/catalyst/">documentation de Catalyst</uri>. La
 tendance générale est de répertorier un bogue dans «&nbsp;Docs-user&nbsp;», qui
-est en fait assigné à la <uri link="http://gdp.gentoo.org">GDP</uri>, alors
-qu'il devrait être envoyé à un membre de l'équipe du projet <uri
+est en fait assigné à l'équipe du <uri link="http://gdp.gentoo.org">GDP</uri>,
+alors qu'il devrait être envoyé à un membre de l'équipe du projet <uri
 link="/proj/en/releng/">Release Engineering</uri>. En général, seule la
 documentation se trouvant dans <path>http://www.gentoo.org/doc/*</path>
 appartient à la GDP. Toute documentation se trouvant dans
@@ -893,12 +893,12 @@
     utilisateur) ou Gentoo Linux (pour les ebuilds et semblables).
   </li>
   <li>
-    La partie («&nbsp;Composent&nbsp;») est où exactement le problème est
+    La partie («&nbsp;Component&nbsp;») est où exactement le problème est
     apparu, plus précisément dans quelle partie du produit sélectionné le bogue
     est arrivé. Cela rend la classification plus facile.
   </li>
   <li>
-    La plateforme matérielle («&nbsp;Hardware Platform&nbsp;») est
+    La plate-forme matérielle («&nbsp;Hardware Platform&nbsp;») est
     l'architecture que vous utilisez. Si vous utilisez SPARC, vous devrez mettre
     SPARC.
   </li>
@@ -917,7 +917,7 @@
 <ul>
   <li>Product - Gentoo Linux (puisque c'est un problème d'ebuild)</li>
   <li>
-    Composent - Application (c'est une erreur provenant d'une application,
+    Component - Application (c'est une erreur provenant d'une application,
     foobar2)
   </li>
   <li>
@@ -935,10 +935,9 @@
 
 <ul>
   <li>
-    La marque de construction, «&nbsp;Build Identifier&nbsp;» est généralement
-    l'application utilisateur (NdT&nbsp;: «&nbsp;User Agent&nbsp;») du
-    navigateur utilisée pour rapporter les bogues (pour enregistrer les
-    propositions). Vous pouvez laisser comme tel.
+    La marque de construction («&nbsp;Build Identifier&nbsp;») est simplement
+    le nom du navigateur (l'«&nbsp;User Agent&nbsp;») utilisé pour rapporter le
+    bogue (à des fins de journalisation). Vous pouvez laisser comme tel.
   </li>
   <li>
     L'URL est optionnelle et sert à pointer l'information appropriée sur un
@@ -990,8 +989,8 @@
 
 <p>
 Nous avons expliqué comment nous avons trouvé le bogue. La prochaine étape
-consiste à expliquer quels étaient résultats que vous avions obtenus et ce que
-nous pensons qu'ils devraient être en réalité.
+consiste à expliquer quels ont été les résultats que nous avons obtenus et ce
+que nous pensons qu'ils auraient dû être en réalité.
 </p>
 
 <figure link="/images/docs/bugzie-results.png" caption="Résultats"/>
@@ -1118,15 +1117,15 @@
 <p>
 Soyez judicieux quand vous testez et demandez des nouvelles versions de paquets.
 Cherchez dans Bugzilla avant de poster votre requête d'estampillage&nbsp;: n'y
-a-t-il pas déjà un bogue ouvert&nbsp;? Avez-vous synchronisé il y a longtemps;
-n'est-ce pas déjà dans Portage&nbsp;? Le paquet a-t-il bien été libéré par
-l'équipe en amont&nbsp;? Un peu de bon sens fera bon chemin, et vous fera
-apprécier des développeurs qui ont déjà beaucoup à faire. Si cela fait quelques
-jours que la version est sortie et que vous êtes sûr qu'il n'y a pas d'autres
-demandes pour celle-ci (et qu'elle n'est pas non plus dans Portage), alors vous
-pouvez ouvrir un nouveau bogue. Assurez-vous de mentionner qu'il compile et
-fonctionne bien sur votre architecture. Toute autre information pouvant aider
-et que vous fournirez sera la bienvenue.
+a-t-il pas déjà un bogue ouvert&nbsp;? Avez-vous synchronisé il y a
+longtemps&nbsp;; n'est-ce pas déjà dans Portage&nbsp;? Le paquet a-t-il bien
+été libéré par l'équipe en amont&nbsp;? Un peu de bon sens fera bon chemin, et
+vous fera apprécier des développeurs qui ont déjà beaucoup à faire. Si cela
+fait quelques jours que la version est sortie et que vous êtes sûr qu'il n'y a
+pas d'autres demandes pour celle-ci (et qu'elle n'est pas non plus dans
+Portage), alors vous pouvez ouvrir un nouveau bogue. Assurez-vous de mentionner
+qu'il compile et fonctionne bien sur votre architecture. Toute autre
+information pouvant aider et que vous fournirez sera la bienvenue.
 </p>
 
 <p>
@@ -1191,7 +1190,7 @@
 </pre>
 
 <p>
-Notez la section «&nbsp;maintener&nbsp;» (NdT&nbsp;: «&nbsp;mainteneur&nbsp;»).
+Notez la section «&nbsp;maintainer&nbsp;» (NdT&nbsp;: «&nbsp;mainteneur&nbsp;»).
 Elle renseigne sur le mainteneur du paquet, qui est moi-même, Chris White, dans
 ce cas-ci. L'adresse électronique listée est chriswhite@g.o. Nous allons
 l'utiliser afin de réassigner le bogue à la bonne personne. Pour se faire,
@@ -1337,7 +1336,7 @@
 
 <p>
 Votre fichier diff est ainsi créé. Pendant que nous faisons tout ça, supposez
-qu'une autre personne trouve votre bogue en cherchant sur le bugzilla et est
+qu'une autre personne trouve votre bogue en cherchant sur le Bugzilla et est
 curieuse de garder sa trace, elle peut le faire en ajoutant son adresse email au
 champ CC du bogue comme montré ci-dessous. Vous pouvez également suivre la trace
 d'autres bogues de la même façon.
@@ -1398,7 +1397,7 @@
 </ul>
 
 <p>
-Maintenant ci-dessous, nous trouvons l'erreur de le journal de strace,
+Maintenant ci-dessous, nous trouvons l'erreur dans le journal de strace,
 corrigeons le bogue, le marquons comme RESOLVED FIXED, mentionnons qu'il y a eu
 un changement de l'emplacement des fichiers de configuration, et mettons à jour
 l'ebuild avec un avertissement à ce propos. Le bogue est alors résolu, et il
@@ -1422,7 +1421,7 @@
 
 <ul>
   <li>
-    FIXED (NdT&nbsp;: Corrigé) - le bogue est corrigé, suivez les instructions
+    FIXED (NdT&nbsp;: Corrigé) - Le bogue est corrigé, suivez les instructions
     pour résoudre le problème.
   </li>
   <li>



-- 
gentoo-commits@g.o mailing list