From: Emmanuel S. <se...@us...> - 2004-11-20 00:23:29
|
Update of /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20016 Modified Files: bug-writing.html.tmpl fields.html.tmpl linked.html.tmpl linkify.html.tmpl voting.html.tmpl Log Message: traduction de pages/ Index: linked.html.tmpl =================================================================== RCS file: /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages/linked.html.tmpl,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** linked.html.tmpl 6 Sep 2004 20:41:13 -0000 1.1.1.1 --- linked.html.tmpl 20 Nov 2004 00:23:16 -0000 1.2 *************** *** 21,30 **** #%] ! [% INCLUDE global/header.html.tmpl title = "Your Linkified Text" %] [% USE Bugzilla %] [% cgi = Bugzilla.cgi %] <p> ! Copy and paste the text below: </p> --- 21,30 ---- #%] ! [% INCLUDE global/header.html.tmpl title = "Votre Texte Lié" %] [% USE Bugzilla %] [% cgi = Bugzilla.cgi %] <p> ! Copiez et collez le texte ci-dessous </p> *************** *** 40,45 **** <p> ! If you place it in <tt><pre></tt> tags, ! the text will end up looking like this: </p> --- 40,45 ---- <p> ! Si vous placez le dans des balises <tt><pre></tt>, ! le texte ressemblera à ceci : </p> Index: bug-writing.html.tmpl =================================================================== RCS file: /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages/bug-writing.html.tmpl,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** bug-writing.html.tmpl 6 Sep 2004 20:41:13 -0000 1.1.1.1 --- bug-writing.html.tmpl 20 Nov 2004 00:23:16 -0000 1.2 *************** *** 27,86 **** [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "$terms.Bug Writing Guidelines" %] ! <h3>Why You Should Read This</h3> <blockquote> ! <p>Simply put, the more effectively you report [% terms.abug %], the more ! likely an ! engineer will actually fix it.</p> ! <p>These guidelines are a general tutorial to teach novice and ! intermediate [% terms.bug %] reporters how to compose effective ! [% terms.bug %] reports. Not ! every sentence may precisely apply to your software project.</p> </blockquote> ! <h3>How to Write a Useful [% terms.Bug %] Report</h3> <blockquote> ! <p>Useful [% terms.bug %] reports are ones that get [% terms.bugs %] fixed. ! A useful [% terms.bug %] report normally has two qualities:</p> <ol> ! <li><b>Reproducible.</b> If an engineer can't see the [% terms.bug %] ! herself to prove that it exists, she'll probably stamp your [% terms.bug %] ! report "WORKSFORME" or "INVALID" and move on to the next [% terms.bug %]. ! Every detail you can provide helps.<br> <br> </li> ! <li><b>Specific.</b> The quicker the engineer can isolate the ! [% terms.bug %] to a specific area, the more likely she'll expediently ! fix it. (If a programmer or tester has to decipher [% terms.abug %], ! they may spend more time cursing the submitter than solving the ! problem.)<br> <br> ! [ <a href="#tips" name="Anchor">Tell Me More</a> ]</li> </ol> ! <p>Let's say the application you're testing is a web browser. You crash ! at foo.com, and want to write up a [% terms.bug %] report:</p> <blockquote> ! <p><b>BAD:</b> "My browser crashed. I think I was on www.foo.com. I ! play golf with Bill Gates, so you better fix this problem, or I'll ! report you to him. By the way, your Back icon looks like a squashed ! rodent. UGGGLY. And my grandmother's home page is all messed up in your ! browser. Thx 4 UR help."</p> ! <p><b>GOOD:</b> "I crashed each time I went to www.foo.com, using the ! 2002-02-25 build on a Windows 2000 system. I also rebooted into Linux, ! and reproduced this problem using the 2002-02-24 Linux build.</p> ! <p>It again crashed each time upon drawing the Foo banner at the top of ! the page. I broke apart the page, and discovered that the following ! image link will crash the application reproducibly, unless you remove ! the "border=0" attribute:</p> <p><tt><IMG SRC="http://www.foo.com/images/topics/topicfoos.gif" --- 27,83 ---- [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "Recommandations d'Ãcriture de $terms.Bug" %] ! <h3>Pourquoi Vous Devriez Lire Ceci</h3> <blockquote> ! <p>Très simplement, le plus éficace votre rapport d'[% terms.abug %], le plus vous ! avez de chance qu'un ingénieur va le réparer.</p> ! <p>Ces recommandations sont un guide général pour les rapporteurs de [% terms.bug %] ! débutants et intermediares pour écrire des rapports de [% terms.bug %] efficaces. ! Toutes les phrases ne s'appliquent pas à votre projet de logiciel.</p> </blockquote> ! <h3>Comment Ãcrire un Rapport de [% terms.Bug %] Utile</h3> <blockquote> ! <p>Les rapports de [% terms.bug %] utiles sont ceux qui permettent de régler des [% terms.bugs %]. ! Un rapport de [% terms.bug %] utile a normalement deux qualités:</p> <ol> ! <li><b>Reproductible.</b> Si un ingénieur ne peut pas voir le [% terms.bug %] ! lui-même pour montrer qu'il existe, il marquera probablement votre rapport de ! [% terms.bug %] "WORKSFORME" ou "INVALID" et passera ensuite au [% terms.bug %] suivant. ! Tout détail que vous pouvez donner aide.<br> <br> </li> ! <li><b>Précis.</b> Le plus rapidement l'ingénieur peut isoler le ! [% terms.bug %] à un endroit précis, le plus rapidement il pourra ! le réparer. (Si un developpeur ou un testeur doit déchiffrer ! [% terms.abug %], ils passeront plus de temps à maudire le rapporteur ! qu'à resoudre le problème.)<br> <br> ! [ <a href="#tips" name="Anchor">Dites Moi en Plus</a> ]</li> </ol> ! <p>Disons que l'application que vous testez est un navigateur web. Vous plantez ! sur foo.com et décidez d'écrire un rapport de [% terms.bug %] :</p> <blockquote> ! <p><b>MAUVAIS :</b> "Mon navigateur a planté. Je crois que j'étais sur foo.com. Je ! joue au golf avec Bill Gates alors vous avez intérêt a réparer mon problème ou ! je lui parlerais de vous. Pendant que j'y suis, votre icon Précedant ressemble ! à un rongeur écrasé. MOOOOCHE. Et la page web de ma grand-mère s'affiche mal ! dans votre navigateur. Rci pr vot ède."</p> ! <p><b>BON :</b> "J'ai planté à chaque visite de www.foo.com en utilisant la ! version 2002-02-25 sur une machine Windows 2000. J'ai aussi rebooté dans Linux ! et reproduit le problème avec la version Linux 2002-02-24.</p> ! <p>Elle a encore planté à chaque reprise en dessinant la bannière Foo au sommet ! de la page. J'ai décomposé la page et découvert que le lien image uivant fera ! planter l'application a tout les coups sauf si on enlève l'attribut "border=0" :</p> <p><tt><IMG SRC="http://www.foo.com/images/topics/topicfoos.gif" *************** *** 89,281 **** </blockquote> ! <h3>How to Enter your Useful [% terms.Bug %] Report ! into [% terms.Bugzilla %]:</h3> <blockquote> ! <p>Before you enter your [% terms.bug %], use [% terms.Bugzilla %]'s ! <a href="query.cgi">search page</a> to determine whether the defect ! you've discovered is a known, already-reported [% terms.bug %]. If ! your [% terms.bug %] is the 37th duplicate of a known issue, ! you're more likely to annoy the engineer. (Annoyed engineers fix fewer ! [% terms.bugs %].)</p> ! <p>Next, be sure to reproduce your [% terms.bug %] using a recent build. ! Engineers tend to be most interested in problems affecting the code base ! that they're actively working on. After all, the [% terms.bug %] you're ! reporting may already be fixed.</p> ! <p>If you've discovered a new [% terms.bug %] using a current build, report ! it in [% terms.Bugzilla %]:</p> <ol> ! <li>From your [% terms.Bugzilla %] main page, choose ! "<a href="enter_bug.cgi">Enter a new [% terms.bug %]</a>".</li> ! <li>Select the product that you've found a [% terms.bug %] in.</li> ! <li>Enter your e-mail address, password, and press the "Login" button. ! (If you don't yet have a password, leave the password field empty, and ! press the "E-mail me a password" button instead. You'll quickly receive ! an e-mail message with your password.)</li> </ol> ! <p>Now, fill out the form. Here's what it all means:</p> ! <p><b>Where did you find the [% terms.bug %]?</b></p> <blockquote> ! <p><b>Product: In which product did you find the [% terms.bug %]?</b><br> ! You just specified this on the last page, so you can't edit it ! here.</p> ! <p><b>Version: In which product version did you find ! the [% terms.bug %]?</b><br> ! (If applicable)</p> ! <p><b>Component: In which component does the [% terms.bug %] ! exist?</b><br> ! [% terms.Bugzilla %] requires that you select a component to enter ! a [% terms.bug %]. (Not sure which to choose? Click on the Component link. ! You'll see a description of each component, to help you make the best ! choice.)</p> ! <p><b>OS: On which Operating System (OS) did you find ! this [% terms.bug %]?</b> ! (e.g. Linux, Windows 2000, Mac OS 9.)<br> ! If you know the [% terms.bug %] happens on all OSs, choose 'All'. ! Otherwise, select the OS that you found the [% terms.bug %] on, or ! "Other" if your OS isn't listed.</p> </blockquote> ! <p><b>How important is the [% terms.bug %]?</b></p> <blockquote> ! <p><b>Severity: How damaging is the [% terms.bug %]?</b><br> ! This item defaults to 'normal'. If you're not sure what severity your ! [% terms.bug %] deserves, click on the Severity link. You'll see a ! description of each severity rating.<br> </p> </blockquote> ! <p><b>Who will be following up on the [% terms.bug %]?</b></p> <blockquote> ! <p><b>Assigned To: Which engineer should be responsible for fixing ! this [% terms.bug %]?</b><br> ! [% terms.Bugzilla %] will automatically assign the [% terms.bug %] to a ! default engineer upon submitting [% terms.abug %] report. If you'd prefer ! to directly assign the [% terms.bug %] to someone else, enter their e-mail ! address into this field. (To see the list of default engineers for each ! component, click on the Component link.)</p> ! <p><b>Cc: Who else should receive e-mail updates on changes to this [% terms.bug %]?</b><br> ! List the full e-mail addresses of other individuals who should receive ! an e-mail update upon every change to the [% terms.bug %] report. You can ! enter as many e-mail addresses as you'd like, separated by spaces or ! commas, as long as those people have [% terms.Bugzilla %] accounts.</p> </blockquote> ! <p><b>What else can you tell the engineer about the [% terms.bug %]?</b></p> <blockquote> ! <p><b>Summary:</b> <b>How would you describe the [% terms.bug %], in ! approximately 60 or fewer characters?</b><br> ! A good summary should <b>quickly and uniquely identify [% terms.abug %] ! report</b>. Otherwise, an engineer cannot meaningfully identify your ! [% terms.bug %] by its summary, and will often fail to pay attention to ! your [% terms.bug %] report when skimming through a 10 ! page [% terms.bug %] list.<br> <br> ! A useful summary might be "<tt>PCMCIA install fails on Tosh Tecra ! 780DVD w/ 3c589C</tt>". "<tt>Software fails</tt>" or "<tt>install ! problem</tt>" would be examples of a bad summary.<br> <br> ! [ <a href="#summary">Tell Me More</a> ]<br> <br> ! <b>Description:</b><br> ! Please provide a detailed problem report in this field. Your ! [% terms.bug %]'s recipients will most likely expect the following ! information:</p> <blockquote> ! <p><b>Overview Description:</b> More detailed expansion of ! summary.</p> <blockquote> <pre> ! Drag-selecting any page crashes Mac builds in NSGetFactory </pre> </blockquote> ! <p><b>Steps to Reproduce:</b> Minimized, easy-to-follow steps that ! will trigger the [% terms.bug %]. Include any special setup steps.</p> <blockquote> <pre> ! 1) View any web page. (I used the default sample page, resource:/res/samples/test0.html) ! 2) Drag-select the page. (Specifically, while holding down ! the mouse button, drag the mouse pointer downwards from any ! point in the browser's content region to the bottom of the ! browser's content region.) </pre> </blockquote> ! <p><b>Actual Results:</b> What the application did after performing ! the above steps.</p> <blockquote> <pre> ! The application crashed. Stack crawl appended below from MacsBug. </pre> </blockquote> ! <p><b>Expected Results:</b> What the application should have done, ! were the [% terms.bug %] not present.</p> <blockquote> <pre> ! The window should scroll downwards. Scrolled content should be selected. ! (Or, at least, the application should not crash.) </pre> </blockquote> ! <p><b>Build Date & Platform:</b> Date and platform of the build ! that you first encountered the [% terms.bug %] in.</p> <blockquote> <pre> ! Build 2002-03-15 on Mac OS 9.0 </pre> </blockquote> ! <p><b>Additional Builds and Platforms:</b> Whether or not ! the [% terms.bug %] takes place on other platforms (or browsers, ! if applicable).</p> <blockquote> <pre> ! - Also Occurs On ! Mozilla (2002-03-15 build on Windows NT 4.0) ! - Doesn't Occur On ! Mozilla (2002-03-15 build on Red Hat Linux; feature not supported) ! Internet Explorer 5.0 (shipping build on Windows NT 4.0) ! Netscape Communicator 4.5 (shipping build on Mac OS 9.0) </pre> </blockquote> ! <p><b>Additional Information:</b> Any other debugging information. ! For crashing [% terms.bugs %]:</p> <ul> ! <li><b>Win32:</b> if you receive a Dr. Watson error, please note ! the type of the crash, and the module that the application crashed ! in. (e.g. access violation in apprunner.exe)</li> ! <li><b>Mac OS:</b> if you're running MacsBug, please provide the ! results of a <b>how</b> and an <b>sc</b>:</li> </ul> --- 86,279 ---- </blockquote> ! <h3>Comment Soumettre Votre Rapport de [% terms.Bug %] Utile ! à [% terms.Bugzilla %]:</h3> <blockquote> ! <p>Avant de soumettre votre [% terms.bug %], utilisez la <a href="query.cgi">page de requête</a> ! de [% terms.Bugzilla %] pour savoir si le défaut que vous avez découvert est un ! [% terms.bug %] connu, déja rapporté. Si votre [% terms.bug %] est le 37ieme ! doublon d'une erreur connue, vous allez probablement ennuyer ! l'ingénieur. (Les ingénieurs annuyés reparent moins de [% terms.bugs %].)</p> ! <p>Ensuite, essayez de reproduire votre [% terms.bug %] avec une version récente. ! Les ingénieurs sont plus intéressés par les problèmes qui affectent une version ! du code sur laquelle ils travaillent. Après tout, le [% terms.bug %] que ! vous rapportez est peut-être déjà réglé.</p> ! <p>Si vous avez découvert un nouveau [% terms.bug %] en utilisant une version courante, rapportez ! le dans [% terms.Bugzilla %]:</p> <ol> ! <li>De votre page princiaple [% terms.Bugzilla %], choisissez ! "<a href="enter_bug.cgi">Enter un nouveau [% terms.bug %]</a>".</li> ! <li>Sélectionnez le produit dans lequel vous avez trouvé un [% terms.bug %].</li> ! <li>Entrer votre adresse mail, mot de passe et appuyer sur le bouton "Connexion". ! (Si vous n'avez pas encore le mot de passe, laissez le champ du mot de passe vide et ! appuyez au lieu sur le bouton "Envoyer le mot de passe par mail". Vous recevrez ! rapidement un mail avec votre mot de passe.)</li> </ol> ! <p>Maintenant, remplissez le formulaire. Voici ce que ça veut dire :</p> ! <p><b>Ou avez vous trouvé le [% terms.bug %]?</b></p> <blockquote> ! <p><b>Produit : Dans quel produit avez vous trouvé le [% terms.bug %]?</b><br> ! Vous l'avez spécifié sur la page précédante donc vous ne pouvez pas le modifier ! ici.</p> ! <p><b>Version : Dans quel version du produit avez vous trouvé ! le [% terms.bug %]?</b><br> ! (Si applicable)</p> ! <p><b>Composant : Dans quel composant le [% terms.bug %] ! existe-il ?</b><br> ! [% terms.Bugzilla %] vous oblige à choisir un composant pour entrer ! un [% terms.bug %]. (Pas sur lequel choisir ? Cliquez sur le lien Composant. ! Vous y verrez la description de chaque composant pour vous aider a faire le ! meilleur choix.)</p> ! <p><b>SE : Sur quel Système d'Exploitation (SE) avez vous trouvé ! ce [% terms.bug %]?</b> ! (i.e. Linux, Windows 2000, Mac OS 9.)<br> ! Si vous savez que ce [% terms.bug %] se produit sur tout SE, Choisissez 'All'. ! Sinon, sélectionnez le SE sur lequel vous avez trouvé le [% terms.bug %], ou ! "Other" si votre SE n'est pas dans la liste.</p> </blockquote> ! <p><b>A quel point votre [% terms.bug %] est-il important ?</b></p> <blockquote> ! <p><b>Severité : Quels type de dégats provoque votre [% terms.bug %]?</b><br> ! Le choix par défaut ici est 'normal'. Si vous n'êtes pas sur quel sévérité votre ! [% terms.bug %] mérite, cliquez sur le lien Sévérité. Vous voyez une ! description de chaque type de sévérité.<br> </p> </blockquote> ! <p><b>Qui va suivre le [% terms.bug %]?</b></p> <blockquote> ! <p><b>Assigné A : Quel ingénieur doit être responsable pour regler ! ce [% terms.bug %]?</b><br> ! [% terms.Bugzilla %] va automatiquement assigner le [% terms.bug %] à un ! ingénieur par défaut lors de la soumission d'un rapport de [% terms.bug %]. Si vous ! préférez assigner le [% terms.bug %] directement à quelqu'un, entrez son adresse ! mail dans ce champ. (Pour voir la liste des ingénieurs par défaut pour chaque ! composant, cliquez sur le lien Composant.)</p> ! <p><b>Cc : Qui d'autre doit recevoir par mail les mises à jour de ce [% terms.bug %]?</b><br> ! Listez l'adresse mail complète d'autres individus qui doivent recevoir une mise ! à jour par mail à chaque modification du rapport du [% terms.bug %]. Vous pouvez ! entrer autant adresses mail que vous voulez, séparés par des espaces ou des ! virgules, du moment que ces personnes aient des comptes [% terms.Bugzilla %].</p> </blockquote> ! <p><b>Que pouvez vous dire d'autre à l'ingénieur sur le [% terms.bug %]?</b></p> <blockquote> ! <p><b>Sommaire :</b> <b>Comment pourriez vous décrire le [% terms.bug %] en ! a peu près 60 caractères ou moins ?</b><br> ! Un bon sommaire doit <b>rapidement et de manière unique un rapport de ! [% terms.bug %]</b>. Sinon, un ingénieur ne peut identifier de manière fiable ! votre [% terms.bug %] par son sommaire et n'arrivera pas à préter attention à ! votre rapport de [% terms.bug %] en parcourant en diagonale une liste ! de [% terms.bug %] longue de 10 pages.<br> <br> ! Un sommaire utile pourrait être "<tt>Installation par PCMCIA echoue sur Tosh Tecra ! 780DVD w/ 3c589C</tt>". "<tt>Ãchec du logiciel</tt>" ou "<tt>problème ! d'installation</tt>" pourrait être des exemples d'un mauvais sommaire.<br> <br> ! [ <a href="#summary">Dites moi en plus</a> ]<br> <br> ! <b>Description :</b><br> ! Donnez un rapport détaillé du problème dans ce champ. Les destinataires ! de votre rapport de [% terms.bug %] s'attendent probablement aux informations ! suivantes :</p> <blockquote> ! <p><b>Description Globale :</b> Une description plus détaillé du ! sommaire.</p> <blockquote> <pre> ! Tirer n'importe quel page plantera des installations Mac dans NSGetFactory </pre> </blockquote> ! <p><b>Ãtapes pour Reproduire :</b> Des étapes simples et minimales qui ! déclencheront le [% terms.bug %]. Inclure toute étape spéciale de ! configuration.</p> <blockquote> <pre> ! 1) Voir n'importe quelle page web. (J'ai utilisé la page type par défaut, resource:/res/samples/test0.html) ! 2) Tirez la page. (Précisément, pendant qu'on appuie sur le ! bouton de souris, tirez le pointeur de souris vers le bas de ! n'importe quel point de la region de contenu du navigateur ! vers le bas de la region de contenu du navigateur.) </pre> </blockquote> ! <p><b>Résultats Actuels :</b> Ce que l'application a fait après l'execution ! des étapes ci-dessus.</p> <blockquote> <pre> ! L'application a planté. Copie de la pile ajouté ci-dessous de MacsBug. </pre> </blockquote> ! <p><b>Resultats Attendus :</b> Ce que l'application aurait du faire, ! si le [% terms.bug %] n'était pas la.</p> <blockquote> <pre> ! La fenêtre devrait défiler vers le bas. Le contenu défilant devrait ! être sélectionné. ! (En tout cas, l'application ne devrait pas planter.) </pre> </blockquote> ! <p><b>Date de Version & Plateforme :</b> Date et plateforme de la version ! dans laquelle vous avez rencontré le [% terms.bug %] pour la première fois.</p> <blockquote> <pre> ! Version 2002-03-15 sur Mac OS 9.0 </pre> </blockquote> ! <p><b>Versions et Plateformes Supplémentaires :</b> Si le [% terms.bug %] ! se produit ou pas sur d'autres plateformes (ou navigateurs, si ! applicable).</p> <blockquote> <pre> ! - Se Produit Aussi Sur ! Mozilla (version 2002-03-15 sur Windows NT 4.0) ! - Ne Se Produit Pas Sur ! Mozilla (version 2002-03-15 sur Red Hat Linux; fonctionalité non supporté) ! Internet Explorer 5.0 (version livrée sur Windows NT 4.0) ! Netscape Communicator 4.5 (version livrée sur Mac OS 9.0) </pre> </blockquote> ! <p><b>Informations Supplémentaires :</b> Toute autre information. ! Piur les [% terms.bugs %] qui plantent :</p> <ul> ! <li><b>Win32 :</b> si vous récuperez une erreur Dr. Watson, notez ! le type de plantage et le module dans lequel l'application a planté. ! (i.e. violation d'accés dans apprunner.exe)</li> ! <li><b>Mac OS:</b> si vous faites tourner MacsBug, donnez les ! resultats d'un <b>how</b> et d'un <b>sc</b> :</li> </ul> *************** *** 294,387 **** </blockquote> ! <p>You're done!<br> <br> ! After double-checking your entries for any possible errors, press the ! "Commit" button, and your [% terms.bug %] report will now be in ! the [% terms.Bugzilla %] database.<br> </p> </blockquote> <hr> ! <h3>More Information on Writing Good [% terms.Bugs %]</h3> <blockquote> ! <p><b><a name="tips"></a> 1. General Tips for a Useful [% terms.Bug %] ! Report</b></p> <blockquote> ! <p><b>Use an explicit structure, so your [% terms.bug %] reports are easy ! to skim.</b> [% terms.Bug %] report users often need immediate access to ! specific sections of your [% terms.bug %]. If your [% terms.Bugzilla %] ! installation supports the [% terms.Bugzilla %] Helper, use it.</p> ! <p><b>Avoid cuteness if it costs clarity.</b> Nobody will be laughing ! at your funny [% terms.bug %] title at 3:00 AM when they can't remember how ! to find your [% terms.bug %].</p> ! <p><b>One [% terms.bug %] per report.</b> Completely different people ! typically fix, verify, and prioritize different [% terms.bugs %]. If you ! mix a handful of [% terms.bugs %] into a single report, the right people ! probably won't discover your [% terms.bugs %] in a timely fashion, or at ! all. Certain [% terms.bugs %] are also more important than others. It's ! impossible to prioritize [% terms.abug %] report when ! it contains four different issues, all of differing importance.</p> ! <p><b>No [% terms.bug %] is too trivial to report.</b> Unless you're ! reading the source code, you can't see actual software [% terms.bugs %], ! like a dangling pointer -- you'll see their visible manifestations, such ! as the segfault when the application finally crashes. Severe software ! problems can manifest themselves in superficially trivial ways. File them ! anyway.<br> </p> </blockquote> ! <p><b><a name="summary"></a>2. How and Why to Write Good [% terms.Bug %] ! Summaries</b></p> <blockquote> ! <p><b>You want to make a good first impression on the [% terms.bug %] ! recipient.</b> Just like a New York Times headline guides readers ! towards a relevant article from dozens of choices, will ! your [% terms.bug %] summary suggest that your [% terms.bug %] report is ! worth reading from dozens or hundreds of choices?</p> ! <p>Conversely, a vague [% terms.bug %] summary like <tt>install ! problem</tt> forces anyone reviewing installation [% terms.bugs %] to waste ! time opening up your [% terms.bug %] to determine whether it matters.</p> ! <p><b>Your [% terms.bug %] will often be searched by its summary.</b> Just ! as you'd find web pages with Google by searching by keywords through ! intuition, so will other people locate your [% terms.bugs %]. ! Descriptive [% terms.bug %] summaries are ! naturally keyword-rich, and easier to find.</p> ! <p>For example, you'll find a [% terms.bug %] titled "<tt>Dragging icons ! from List View to gnome-terminal doesn't paste path</tt>" if you search on ! "List", "terminal", or "path". Those search keywords wouldn't have ! found a [% terms.bug %] titled "<tt>Dragging icons doesn't paste</tt>".</p> ! <p>Ask yourself, "Would someone understand my [% terms.bug %] from just ! this summary?" If so, you've written a fine summary.</p> ! <p><b>Don't write titles like these:</b></p> <ol> ! <li>"Can't install" - Why can't you install? What happens when you ! try to install?</li> ! <li>"Severe Performance Problems" - ...and they occur when you do ! what?</li> ! <li>"back button does not work" - Ever? At all?</li> </ol> ! <p><b>Good [% terms.bug %] titles:</b></p> <ol> ! <li>"1.0 upgrade installation fails if Mozilla M18 package present" - ! Explains problem and the context.</li> ! <li>"RPM 4 installer crashes if launched on Red Hat 6.2 (RPM 3) ! system" - Explains what happens, and the context.</li> </ol> </blockquote> --- 292,388 ---- </blockquote> ! <p>Vous avez terminé <br> <br> ! Après avoir relu vote entrée pour d'eventuelles erreurs, appuyer sur le ! bouton "Soumettre" et votre rapport de [% terms.bug %] sera alors dans la ! base de données [% terms.Bugzilla %]<br> </p> </blockquote> <hr> ! <h3>Plus d'Informations sur l'Ãcriture de Bons [% terms.Bugs %]</h3> <blockquote> ! <p><b><a name="tips"></a> 1. Astuces Générales pour un Rapport de [% terms.Bug %] ! Utile</b></p> <blockquote> ! <p><b>Utilisez une structure explicite pour que votre rapport de [% terms.bug %] soit facile ! à parcourir.</b> Les utilisateurs de rapports de [% terms.Bug %] sont ! souvent besoin d'un accés immédiat à des parties spécifiques de votre ! [% terms.bug %]. Si votre instance de [% terms.Bugzilla %] permet ! l'utilisation du [% terms.Bugzilla %] Helper, faites le.</p> ! <p><b>Ãvitez d'être drôle si cela nuit à la clarté.</b> Personne ne rigolera ! à votre titrede [% terms.bug %] rigolo à 3 heures du matin lorsqu'ils ne se ! souviendront plus comment trouver votre [% terms.bug %].</p> ! <p><b>Un [% terms.bug %] par rapport.</b> Typiquement, des personnes ! complètement différentes règlent, vérifient et mettent une priorité à ! différent [% terms.bugs %]. Si vous mettez plusieurs [% terms.bugs %] ! dans un seul rapport, les bonnes personnes ne découvriront probablement ! pas vos [% terms.bugs %] très rapidement, voire pas du tout. Certains ! [% terms.bugs %] sont aussi plus importants que d'autres. Il est ! impossible de prioriser un rapport de [% terms.bug %] lorsqu'il contient ! quatre problèmes différents, tous d'une importance différente.</p> ! <p><b>Aucun [% terms.bug %] n'est trop triviale pour être rapporter.</b> A moins ! de lire le code source, vous ne voyez pas les [% terms.bugs %] actuels d'un ! logiciel, comme un pointeur dans le vide -- vous voyez leur mannifestations ! visibles, tel que l'erreur de segmentation lorsque l'application finit par planter. ! Des problèmes sévères de logiciels peuvent se manifester par des manières ! triviales. Rapportez les quand même.<br> </p> </blockquote> ! <p><b><a name="summary"></a>2. Comment et Pourquoi Ãcrire de Bons Sommaires de ! [% terms.Bug %]</b></p> <blockquote> ! <p><b>Vous voulez faire une bonne première impression sur le destinataire du ! [% terms.bug %].</b> De la même façon qu'un titre du New York Times guide les ! lecteurs vers un article pertinant parmi des dizaines de choix, votre sommaire ! de [% terms.bug %] indique t-il que votre rapport de [% terms.bug %] est ! digne d'être lu parmi des dizaines ou centaines de choix ?</p> ! <p>De la même façon, un sommaire de [% terms.bug %] vague comme <tt>problème ! d'installation</tt> force toute personne passant en revue les [% terms.bugs %] ! d'installation de perdre son temps en ouvrant votre [% terms.bug %] pour ! déterminer s'il importe.</p> ! <p><b>Votre [% terms.bug %] sera souvent cherché par son sommaire.</b> Tout ! comme vous pouvez trouver des pages web avec Google en cherchant des mots-clé ! par intuition, d'autres personnes trouveront vos [% terms.bugs %]. ! Des sommaires de [% terms.bug %] descriptifs sont naturellement riches en ! mots-clé et facile à trouver.</p> ! <p>Par exemple, vous trouverez un [% terms.bug %] titré "<tt>Tirer des icones ! de la vue Liste vers gnome-terminal ne copie pas le chemin</tt>" si vous faîtes ! une requête sur "Liste", "terminal" ou "chemin". Ces mots-clé de requête ne ! trouveront pas un [% terms.bug %] titré "<tt>Tirer des icones ne copie pas</tt>".</p> ! <p>Posez vous la question, "Quelqu'un comprendera t-il mon [% terms.bug %] avec ! simplement ce sommaire ?" Si oui, vous avez écrit un bon sommaire.</p> ! <p><b>N'écrivez pas des titres comme ceux-ci :</b></p> <ol> ! <li>"Impossible d'installer" - Pourquoi ne pouvez vous pas installer ? Que ! se passe t-il lorsque vous éssayez d'installer ?</li> ! <li>"Problèmes Sévères de Performance" - ...et ils se produisent quand vous faîtes ! quoi </li> ! <li>"bouton précédent ne marche pas" - du tout ? Jamais ?</li> </ol> ! <p><b>De bons titres de [% terms.bug %] :</b></p> <ol> ! <li>"L'installation de la mise à jour de 1.0 échoue si Mozilla M18 est présent" - ! Explique le problème et le contexte.</li> ! <li>"L'installeur RPM 4 plante si lancé sur un système Red Hat 6.2 ! (RPM 3)" - Explique ce qui se passe et le contexte.</li> </ol> </blockquote> Index: linkify.html.tmpl =================================================================== RCS file: /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages/linkify.html.tmpl,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** linkify.html.tmpl 6 Sep 2004 20:41:13 -0000 1.1.1.1 --- linkify.html.tmpl 20 Nov 2004 00:23:16 -0000 1.2 *************** *** 22,31 **** [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "Linkify Text" %] <p> ! If you enter some text, this form will return it marked up like a ! standard [% terms.Bugzilla %] comment. That is, valid [% terms.bug %] numbers, ! URLs, email addresses and so on will be replaced with appropriate HTML links. </p> --- 22,32 ---- [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "Lien de Texte" %] <p> ! Si vous entrez du texte, ce formulaire le retournera marqué comme un commentaire ! standard [% terms.Bugzilla %]. Ce qui veut dire que des nombres de [% terms.bug %] valables, ! des URLs, des adresses mail et ainsi de suite devront être remplacés avec les liens HTML ! appropriés. </p> Index: voting.html.tmpl =================================================================== RCS file: /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages/voting.html.tmpl,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** voting.html.tmpl 6 Sep 2004 20:41:13 -0000 1.1.1.1 --- voting.html.tmpl 20 Nov 2004 00:23:16 -0000 1.2 *************** *** 24,65 **** [% INCLUDE global/header.html.tmpl title = "Voting" %] ! <p>[% terms.Bugzilla %] has a "voting" feature. Each product allows users to ! have a certain number of votes. (Some products may not allow any, which means ! you can't vote on things in that product at all.) With your vote, you indicate ! which [% terms.bugs %] you think are the most important to be fixed.</p> ! <p>Depending on how the administrator has configured the relevant product, ! you may be able to vote for the same [% terms.bug %] more than one time. But ! remember, you only have so many votes to use in total! So, you can either vote ! a little for many [% terms.bugs %], or vote a lot for a few [% terms.bugs %]. </p> ! <p>To look at votes:</p> <ul> ! <li>Go to the query page. Do a normal query, but enter 1 in the "At least ! ___ votes" field. This will show you items that match your query that ! have at least one vote.</li> </ul> ! <p>To vote for [% terms.abug %]:</p> <ul> ! <li>Bring up the [% terms.bug %] in question.</li> ! <li>Click on the "Vote for this [% terms.bug %]" link that appears just ! above the "Additional Comments" field. (If no such link appears, then voting ! may not be allowed in this [% terms.bug %]'s product.)</li> ! <li>Indicate how many votes you want to give this [% terms.bug %]. This page ! also displays how many votes you've given to other [% terms.bugs %], so you ! may rebalance your votes as necessary.</li> </ul> ! <p>You will automatically get email notifying you of any changes that occur ! on [% terms.bugs %] you vote for.</p> ! <p>You may review your votes at any time by clicking on the "<a href= ! "votes.cgi?action=show_user">My Votes</a>" link in the page footer.</p> [% INCLUDE global/footer.html.tmpl %] --- 24,68 ---- [% INCLUDE global/header.html.tmpl title = "Voting" %] ! <p>[% terms.Bugzilla %] a une fonctionalité de "vote". Chaque produit permet aux utilisateurs ! d'avoir un certain nombre de votes. (Certains produits n'en autorisent aucun ce qui veut ! dire que vous ne pouvez voter sur rien du tout.) Avec votre vote, vous pouvez ! indiquer quels [% terms.bugs %] vous trouvez important de régler.</p> ! <p>Suivant la façon dont votre administrateur a configuré le produit en question, ! vous pouvez voter pour le même [% terms.bug %] plus d'une fois. Mais, ! souvenez vous, vous n'avez qu'un certain nombre de votes en tout ! Donc, ! vous pouvez voter un peu pour beaucoup de [% terms.bugs %] ou voter ! beaucoup pour quelques [% terms.bugs %]. </p> ! <p>Pour voir les votes :</p> <ul> ! <li>Allez à la page de requête. Faites une requête normale mais entrer 1 dans ! le champ "Au moins __ votes". Ceci vous montera les éléments qui correspondent ! à votre requète qui ont au moins un vote.</li> </ul> ! <p>Pour voter sur [% terms.abug %]:</p> <ul> ! <li>Afficher le [% terms.bug %] en question.</li> ! <li>Cliquer sur le lien "Votez sur ce [% terms.bug %]" qui apparaît juste ! au dessus du champ "Commentaires Supplémentaires". (Si aucun lien de ce type ! apparaît, alors les votes ne sont pas autorisés pour le produit de ce ! [% terms.bug %].)</li> ! <li>Indiquer combien de votes vous voulez donner à ce [% terms.bug %]. Cette page ! affiche aussi le nombre de votes que vous avez donné à d'autres [% terms.bugs %] ! donc vous pouvez redistribuer vos votes si nécessaire.</li> </ul> ! <p>Vous recevrez automatiquement un mail vous avertissant de tout changement ! sur les [% terms.bugs %] pour lesquels vous avez voté.</p> ! <p>Vous pouvez revoir vos votes à n'importe quel moment en cliquant sur ! le lien "<a href="votes.cgi?action=show_user">Mes Votes</a>" sur le pied ! de page.</p> [% INCLUDE global/footer.html.tmpl %] Index: fields.html.tmpl =================================================================== RCS file: /cvsroot/bugzilla-fr/Bugzilla-fr_2.18/fr/default/pages/fields.html.tmpl,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -C2 -d -r1.1.1.1 -r1.2 *** fields.html.tmpl 6 Sep 2004 20:41:13 -0000 1.1.1.1 --- fields.html.tmpl 20 Nov 2004 00:23:16 -0000 1.2 *************** *** 22,30 **** [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "A $terms.Bug's Life Cycle" %] <p> ! The <b>status</b> and <b>resolution</b> fields define and track the life ! cycle of [% terms.abug %]. </p> --- 22,30 ---- [% PROCESS global/variables.none.tmpl %] ! [% INCLUDE global/header.html.tmpl title = "Le Cycle de Vie d'un $terms.Bug" %] <p> ! Les champs <b>statut</b> et <b>résolution</b> definissent et suivent le cycle ! de vie d'[% terms.abug %]. </p> *************** *** 35,52 **** <tr align="center" valign="top"> <td width="50%"> ! <h1>STATUS</h1> </td> <td> ! <h1>RESOLUTION</h1> </td> </tr> <tr valign="top"> ! <td>The <b>status</b> field indicates the general health of a ! [% terms.bug %]. Only certain status transitions are allowed.</td> ! <td>The <b>resolution</b> field indicates what happened to this ! [% terms.bug %].</td> </tr> --- 35,51 ---- <tr align="center" valign="top"> <td width="50%"> ! <h1>STATUT</h2> </td> <td> ! <h1>RÃSOLUTION</h1> </td> </tr> <tr valign="top"> ! <td>Le champ <b>statut</b> indique la santé générale d'un ! [% terms.bug %]. Seuls certaines transitions de status sont autorisés.</td> ! <td>Le champ <b>résolution</b> indique ce qui est arrivé à ce [% terms.bug %].</td> </tr> *************** *** 56,87 **** <dt><b>UNCONFIRMED</b></dt> ! <dd>This [% terms.bug %] has recently been added to the database. ! Nobody has validated that this [% terms.bug %] is true. Users who have ! the "canconfirm" permission set may confirm this [% terms.bug %], ! changing its state to NEW. Or, it may be directly resolved and marked ! RESOLVED.</dd> <dt><b>NEW</b></dt> ! <dd>This [% terms.bug %] has recently been added to the assignee's list ! of [% terms.bugs %] and must be processed. [% terms.Bugs %] in this ! state may be accepted, and become <b>ASSIGNED</b>, passed on to someone ! else, and remain <b>NEW</b>, or resolved and marked <b>RESOLVED</b>. </dd> <dt><b>ASSIGNED</b></dt> ! <dd>This [% terms.bug %] is not yet resolved, but is assigned to the ! proper person. From here [% terms.bugs %] can be given to another ! person and become <b>NEW</b>, or resolved and become <b>RESOLVED</b>. </dd> <dt><b>REOPENED</b></dt> ! <dd>This [% terms.bug %] was once resolved, but the resolution was ! deemed incorrect. For example, a <b>WORKSFORME</b> [% terms.bug %] is ! <b>REOPENED</b> when more information shows up and the [% terms.bug %] ! is now reproducible. From here [% terms.bugs %] are either marked ! <b>ASSIGNED</b> or <b>RESOLVED</b>.</dd> </dl> </td> --- 55,86 ---- <dt><b>UNCONFIRMED</b></dt> ! <dd>Ce [% terms.bug %] a été ajouté récemment à la base de donnée. ! Personne n'a validé ce [% terms.bug %] comme étant vrai. Les utilisateurs ! qui ont le droit "canconfirm" peuvent confirmer ce [% terms.bug %], ! ce qui changera son état en NEW. Ou alors, il peut être résolu ! directement et marqué RESOLVED.</dd> <dt><b>NEW</b></dt> ! <dd>Ce [% terms.bug %] a été ajouté récemment à la liste de [% terms.bugs %] ! de l'assigné et doît être traité. Les [% terms.bugs %] dans cet ! état doivent être acceptés et devenir <b>ASSIGNED</b>, donnés à quelqu'un ! et rester <b>NEW</b> ou résolu et marqués <b>RESOLVED</b>. </dd> <dt><b>ASSIGNED</b></dt> ! <dd>Ce [% terms.bug %] n'est pas encore résolu mais a été assigné à la bonne ! bonne personne. D'ici, les [% terms.bugs %] peuvent être donnés à ! quelqu'un d'autre et devenir <b>NEW</b> ou résolu et devenir <b>RESOLVED</b>. </dd> <dt><b>REOPENED</b></dt> ! <dd>Ce [% terms.bug %] a été resolu mais la résolution a été jugée ! incorrecte. Par exemple, un [% terms.bug %] <b>WORKSFORME</b> est ! <b>REOPENED</b> lorsque plus d'informations arrivent et que le [% terms.bug %] ! devient reproductible. D'ici, les [% terms.bugs %] sont marqués soit ! <b>ASSIGNED</b> ou <b>RESOLVED</b>.</dd> </dl> </td> *************** *** 89,96 **** <td> <dl> ! <dd>No resolution yet. All [% terms.bugs %] which are in one of ! these "open" states have the resolution set to blank. All ! other [% terms.bugs %] will be marked with one of the following ! resolutions.</dd> </dl> </td> --- 88,94 ---- <td> <dl> ! <dd>Aucune résolution à l'heure actuelle. Tous les [% terms.bugs %] qui sont dans l'un ! des états "ouverts" auront une résolution vide. Tout autre ! [% terms.bug %] sera marqué avec l'une des résolutions suivantes.</dd> </dl> </td> *************** *** 102,122 **** <dt><b>RESOLVED</b></dt> ! <dd>A resolution has been taken, and it is awaiting verification by ! QA. From here [% terms.bugs %] are either re-opened and become ! <b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for good ! and marked <b>CLOSED</b>.</dd> <dt><b>VERIFIED</b></dt> ! <dd>QA has looked at the [% terms.bug %] and the resolution and ! agrees that the appropriate resolution has been taken. [% terms.Bugs %] ! remain in this state until the product they were reported against ! actually ships, at which point they become <b>CLOSED</b>.</dd> <dt><b>CLOSED</b></dt> ! <dd>The [% terms.bug %] is considered dead, the resolution is correct. ! Any zombie [% terms.bugs %] who choose to walk the earth again must ! do so by becoming <b>REOPENED</b>.</dd> </dl> </td> --- 100,120 ---- <dt><b>RESOLVED</b></dt> ! <dd>Une résolution a été prise et elle attend une vérification de ! QA. D'ici, les [% terms.bugs %] sont soit ré-ouvert et deviennent ! <b>REOPENED</b>, sont marqués <b>VERIFIED</b>, ou sont fermés pour ! de bon et marqués <b>CLOSED</b>.</dd> <dt><b>VERIFIED</b></dt> ! <dd>QA a regardé le [% terms.bug %] et la résolution et est d'accord pour ! dire que la résolution appropriée a été prise. Les [% terms.bugs %] ! restent dans cet état jusqu'a ce que le produit contre lequel ils ont ! été rapportés soit livré, a partir de quoi ils deviennent <b>CLOSED</b>.</dd> <dt><b>CLOSED</b></dt> ! <dd>Le [% terms.bug %] est considéré mort, la résolution est correcte. ! Tout [% terms.bugs %] zombie qui choisit de fouler à nouveau le sol doit ! le faire en devenant <b>REOPENED</b>.</dd> </dl> </td> *************** *** 126,160 **** <dt><b>FIXED</b></dt> ! <dd>A fix for this [% terms.bug %] is checked into the tree and ! tested.</dd> <dt><b>INVALID</b></dt> ! <dd>The problem described is not [% terms.abug %]</dd> <dt><b>WONTFIX</b></dt> ! <dd>The problem described is [% terms.abug %] which will never be ! fixed.</dd> <dt><b>DUPLICATE</b></dt> ! <dd>The problem is a duplicate of an existing [% terms.bug %]. Marking ! [% terms.abug %] duplicate requires the [% terms.bug %]# of the ! duplicating [% terms.bug %] and will at least put that [% terms.bug %] ! number in the description field.</dd> <dt><b>WORKSFORME</b></dt> ! <dd>All attempts at reproducing this [% terms.bug %] were futile, ! reading the code produces no clues as to why this behavior would occur. ! If more information appears later, please re-assign ! the [% terms.bug %], for now, file it.</dd> <dt><b>MOVED</b></dt> ! <dd>The problem was specific to a related product ! whose [% terms.bugs %] are tracked in another [% terms.bug %] database. ! The [% terms.bug %] has been moved to that database.</dd> </dl> </td> --- 124,157 ---- <dt><b>FIXED</b></dt> ! <dd>Un correctif pour ce [% terms.bug %] a été intégré dans l'arbre et testé.</dd> <dt><b>INVALID</b></dt> ! <dd>Le problème décrit n'est pas [% terms.abug %]</dd> <dt><b>WONTFIX</b></dt> ! <dd>Le problème décrit est [% terms.abug %] qui ne sera jamais ! corrigé.</dd> <dt><b>DUPLICATE</b></dt> ! <dd>Le problème est un doublon d'un [% terms.bug %] existant. Marquer ! [% terms.abug %] doublon nécessite le numéro de [% terms.bug %] du ! [% terms.bug %] dupliqué et mettera au moins ce numéro de [% terms.bug %] ! dans le champ description.</dd> <dt><b>WORKSFORME</b></dt> ! <dd>Toutes les tentatives pour reproduire ce [% terms.bug %] ont étés futiles, ! lire le code ne donne aucun indice sur la raison de ce comportement. ! Si plus d'informations apparaissent plus tard, re-assigner le [% terms.bug %] ! mais pour l'instant, le classer</dd> <dt><b>MOVED</b></dt> ! <dd>Le problème était spécifique à un produit donné dont les [% terms.bugs %] ! sont suivis dans une autre base de données de [% terms.bug %]. ! Le [% terms.bug %] a été déplacé vers cette base.</dd> </dl> </td> *************** *** 163,167 **** <h2><a name="bug_severity">Severity</a></h2> ! This field describes the impact of [% terms.abug %]. <table> --- 160,164 ---- <h2><a name="bug_severity">Severity</a></h2> ! Ce champ décrit l'impact d'[% terms.abug %]. <table> *************** *** 169,173 **** <th>Blocker</th> ! <td>Blocks development and/or testing work</td> </tr> --- 166,170 ---- <th>Blocker</th> ! <td>Bloque le developpement et/ou le travail de test</td> </tr> *************** *** 175,179 **** <th>Critical</th> ! <td>crashes, loss of data, severe memory leak</td> </tr> --- 172,176 ---- <th>Critical</th> ! <td>plantages, pertes de données, pertes de mémoire sévères</td> </tr> *************** *** 181,185 **** <th>Major</th> ! <td>major loss of function</td> </tr> --- 178,182 ---- <th>Major</th> ! <td>perte majeure de fonctionalité</td> </tr> *************** *** 187,192 **** <th>Minor</th> ! <td>minor loss of function, or other problem where easy ! workaround is present</td> </tr> --- 184,189 ---- <th>Minor</th> ! <td>perte mineure fonctionalité ou autre problème pour lequel une ! solution temporaire est disponible</td> </tr> *************** *** 194,199 **** <th>Trivial</th> ! <td>cosmetic problem like misspelled words or misaligned ! text</td> </tr> --- 191,196 ---- <th>Trivial</th> ! <td>problème cosmetique comme des fautes d'orthographe ou du texte mal ! aligné</td> </tr> *************** *** 201,221 **** <th>Enhancement</th> ! <td>Request for enhancement</td> </table> ! <h2><a name="priority">Priority</a></h2> ! This field describes the importance and order in which [% terms.abug %] ! should be fixed. This field is utilized by the ! programmers/engineers to prioritize their work to be done. The ! available priorities range from <b>P1</b> (most important) to ! <b>P5</b> (least important.) ! <h2><a name="rep_platform">Platform</a></h2> ! This is the hardware platform against which the [% terms.bug %] was ! reported. Legal platforms include: <ul> ! <li>All (happens on all platforms; cross-platform [% terms.bug %])</li> <li>Macintosh</li> --- 198,217 ---- <th>Enhancement</th> ! <td>Requête pour une amélioration</td> </table> ! <h2><a name="priority">Priorité</a></h2> ! Ce champ décrit l'importance et l'ordre dans lesquels [% terms.abug %] ! doivent être réglés. Ce champ est utilisé par les developpeurs/ingénieurs ! pour prioriser le travail à faire. Les priorités disponibles vont de ! <b>P1</b> (plus important) à <b>P5</b> (moins important.) ! <h2><a name="rep_platform">Platforme</a></h2> ! Ceci est la plateforme matériel contre laquelle le [% terms.bug %] a été ! rapporté. Les plateformes légales incluent : <ul> ! <li>All (arrive sur toutes les plateformes; [% terms.bug %] multi-plateformes)</li> <li>Macintosh</li> *************** *** 227,242 **** <li>HP</li> </ul> ! <b>Note:</b> When searching, selecting the option "All" does not ! select [% terms.bugs %] ! assigned against any platform. It merely selects [% terms.bugs %] that are ! marked as occurring on all platforms, i.e. are designated "All". ! <h2><a name="op_sys">Operating System</a></h2> ! This is the operating system against which the [% terms.bug %] was ! reported. Legal operating systems include: <ul> ! <li>All (happens on all operating systems; cross-platform ! [% terms.bug %])</li> <li>Windows 95</li> --- 223,237 ---- <li>HP</li> </ul> ! <b>Note:</b> Pendant une requête, choisir l'option "All" ne sélectionne pas ! les [% terms.bugs %] assignés contre n'importe quelle platforme. Cela sélectionne ! les [% terms.bugs %] marqués comme se produisant sur toutes les plateformes, ! i.e. sont désignés "All". ! <h2><a name="op_sys">Système id'Exploitation</a></h2> ! Ceci est le système d'exploitation contre lequel le [% terms.bug %] a ! été rapporté. Les systèmes d'exploitation légaux sont : <ul> ! <li>All (arrive sur tous les systèmes d'exploitation; [% terms.bug %] multi-systèmes)</li> <li>Windows 95</li> *************** *** 246,264 **** <li>Linux</li> </ul> ! Sometimes the operating system implies the platform, but not ! always. For example, Linux can run on PC and Macintosh and ! others. ! <h2><a name="assigned_to">Assigned To</a></h2> <p> ! This is the person in charge of resolving the [% terms.bug %]. Every time ! this field changes, the status changes to <b>NEW</b> to make it ! easy to see which new [% terms.bugs %] have appeared on a person's list.</p> <p> ! The default status for queries is set to NEW, ASSIGNED and ! REOPENED. When searching for [% terms.bugs %] that have been resolved or ! verified, remember to set the status field appropriately. </p> --- 241,259 ---- <li>Linux</li> </ul> ! Quelques fois le système d'exploitation implique la plateforme mais pas ! toujours. Par exemple, Linux peut tourner sur PC et Macintosh et ! d'autres. ! <h2><a name="assigned_to">Assigné Ã</a></h2> <p> ! Ceci est la personne en charge de résoudre le [% terms.bug %]. Chaque fois ! que ce champ change, le statut passe à <b>NEW</b> pour permettre plus facilement ! de voir quels nouveaux [% terms.bugs %] sont apparus sur la liste de quelqu'un.</p> <p> ! Le statut par défaut pour les requêtes est mis à NEW, ASSIGNED et ! REOPENED. Lors d'une requête pour des [% terms.bugs %] qui ont été résolus ou ! vérifiés, n'oubliez pas de changer le champ de statut comme il convient. </p> |