Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Dec 2008 14:06:03 GMT
From:      Rene Ladan <rene@FreeBSD.org>
To:        Perforce Change Reviews <perforce@FreeBSD.org>
Subject:   PERFORCE change 155242 for review
Message-ID:  <200812241406.mBOE63hN005951@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=155242

Change 155242 by rene@rene_self on 2008/12/24 14:05:21

	Finalize translation.
	Checked build, language, spelling, whitespace.

Affected files ...

.. //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#8 edit

Differences ...

==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#8 (text+ko) ====

@@ -51,31 +51,31 @@
   <section id="pr-intro">
     <title>Introductie</title>
 
-    <para>E&eacute;n van de meest frusterende ervaringen die een
+    <para>E&eacute;n van de meest frustrerende ervaringen die een
       gebruiker van software kan hebben is om een probleemrapport in te
-      versturen om het vervolgens afgehandeld te zien met een korte en
+      sturen om het vervolgens afgehandeld te zien met een korte en
       onbehulpzame uitleg als <quote>geen bug</quote> of <quote>fout
 	PR</quote>.  Evenzo is &eacute;&eacute;n van de meest
-      frusterende ervaringen als ontwikkelaar van software om overspoeld
-      te worden met probleemrapporten die niet echt een probleemrapport
-      zijn maar ondersteuningsverzoeken, of die weinig tot geen
-      informatie bevatten over wat het probleem is en hoe het te
-      reproduceren.</para>
+      frustrerende ervaringen als ontwikkelaar van software om
+      overspoeld te worden met probleemrapporten die niet echt een
+      probleemrapport zijn maar ondersteuningsverzoeken, of die weinig
+      tot geen informatie bevatten over wat het probleem is en hoe het
+      te reproduceren.</para>
 
     <para>Dit document poogt te beschrijven hoe goede probleemrapporten
       te schrijven.  Wat is een goed probleemrapport?  Kort door de
       bocht is een goed probleemrapport een rapport dat geanalyseerd kan
-      worden en waar snel mee kan wordne omgegaan, voor het wederzijdse
-      plezier van zowel de gebruiker als de ontwikkelaar.</para>
+      worden en waar snel mee kan worden omgegaan, voor de wederzijdse
+      voldoening van zowel de gebruiker als de ontwikkelaar.</para>
 
     <para>Hoewel de nadruk van dit artikel ligt op probleemrapporten
-      voor &os;, zou het meeste ook op andere softwareprojecten van
-      toepassing moeten zijn.</para>
+      voor &os;, zou het meeste ook in sterke mate op andere
+      softwareprojecten van toepassing moeten zijn.</para>
 
     <para>Merk op dat dit artikel thematisch in plaats van chronologisch
       is ingedeeld, dus u dient het hele document te lezen alvorens een
-      probleemrapport op te sturen, in plaats van het als een
-      stapsgewijze tutorial te behandelen.</para>
+      probleemrapport in te sturen, en het niet als een stapsgewijze
+      tutorial te behandelen.</para>
   </section>
 
   <section id="pr-when">
@@ -85,12 +85,12 @@
       zijn voor een probleemrapport.  Natuurlijk is niemand perfect dus
       zal het soms voorkomen dat u overtuigd bent dat u een bug in een
       programma heeft gevonden terwijl u in feite de syntaxis voor een
-      commando verkeerd begrepen of een typfout in een
+      commando verkeerd begrepen heeft of een typefout in een
       instellingenbestand gemaakt heeft (hoewel dat soms zelf al op
       slechte documentatie of slechte foutafhandeling in de applicatie
       kan wijzen).  Er zijn nog steeds veel gevallen waarin het insturen
       van een probleemrapport duidelijk <emphasis>niet</emphasis> de
-      juiste handeling is, en het alleen tot frustatie bij uzelf en de
+      juiste handeling is, en het alleen tot frustratie bij uzelf en de
       ontwikkelaars leidt.  Omgekeerd zijn er gevallen waarin het juist
       kan zijn om een probleemrapport in te sturen over iets anders dan
       een bug&mdash;bijvoorbeeld voor een verbetering of een
@@ -98,7 +98,7 @@
 
     <para>Dus hoe wordt bepaald of iets wel of niet een bug is?  Een
       eenvoudige vuistregel is dat uw probleem <emphasis>geen</emphasis>
-      bug is als het als een vraag kan worden uitgedrukt (meestal in de
+      bug is als het als een vraag kan worden uitgedrukt (meestal van de
       vorm <quote>Hoe doe ik X?</quote> of <quote>Waar kan ik Y
 	vinden?</quote>).  Het is niet altijd zo zwart-wit, maar de
       vraagregel gaat in de meeste gevallen op.  Overweeg, als u een
@@ -122,14 +122,14 @@
 	  gereedschappen van GNU).</para>
 
 	<para>Voor onbeheerde ports (<makevar>MAINTAINER</makevar> bevat
-	  <literal>ports@FreeBSD.org</literal> kan zo'n updatemelding
+	  <literal>ports@FreeBSD.org</literal>) kan zo'n updatemelding
 	  opgepakt worden door een ge&iuml;nteresseerde committer, of u
 	  kunt gevraagd worden om een patch aan te leveren om de port
 	  bij te werken; door dit van te voren aan te bieden verhoogt u
 	  in sterke mate de kans dat de port binnen een redelijk
 	  tijdsbestek wordt bijgewerkt.</para>
 
-	<para>Als de port beheerd wordt, zijn PRs die nieuwe
+	<para>Als de port beheerd wordt, zijn PR's die nieuwe
 	  stroomopwaartse uitgaven aankondigen niet erg nuttig aangezien
 	  ze aanvullend werk voor de committers genereren, en
 	  waarschijnlijk weet de beheerder al dat er een nieuwe versie
@@ -139,29 +139,29 @@
 
 	<para>In beide gevallen zal het volgen van het proces zoals
 	  beschreven in het <ulink
-	    url="&url.books.porters-handbook;/port-upgrading.html">Porters
-	    Handboek</ulink> tot de beste resultaten leiden.  (U bent
-	  misschien ook ge&iuml;nteresseerd in <ulink
+	    url="&url.books.porters-handbook;/port-upgrading.html">
+	    Porters Handboek</ulink> tot de beste resultaten leiden.  (U
+	  bent misschien ook ge&iuml;nteresseerd in <ulink
 	    url="&url.articles.contributing-ports;/article.html">
 	    Bijdragen aan de &os; Portscollectie</ulink>.)</para>
       </listitem>
     </itemizedlist>
 
-    <para>Een bug die niet reproduceerbaar is kan zelden gemaakt worden.
-      Als een bug slechts eenmalig voorkwam en u deze niet kunt
-      reproduceren, en het bijna niemand anders lijkt voor te komen, dan
+    <para>Een bug die niet reproduceerbaar is kan zelden gerepareerd
+      worden.  Als een bug slechts eenmalig voorkwam en u deze niet kunt
+      reproduceren, en het bij niemand anders lijkt voor te komen, dan
       bestaat de kans dat geen van de ontwikkelaars het kan reproduceren
       of kan uitzoeken wat er mis is.  Dit betekent niet dat het niet
-      gebeurde, maar wel dat de kansen dat uw probleemrapport ooit tot
-      een reparatie leidt erg klein zijn.  Om het allemaal erger te
-      maken, worden dit soort bugs vaak veroorzaakt door falende harde
-      schijven of oververhitte processoren &mdash; u dient altijd te
-      proberen om deze problemen, indien mogelijk, uit te sluiten
-      voordat u een PR instuurt.</para>
+      gebeurde, maar wel dat de kans dat uw probleemrapport ooit tot een
+      reparatie leidt erg klein is.  Om het allemaal erger te maken,
+      worden dit soort bugs vaak veroorzaakt door falende harde schijven
+      of oververhitte processoren &mdash; u dient altijd te proberen om
+      deze oorzaken, indien mogelijk, uit te sluiten voordat u een PR
+      instuurt.</para>
 
-    <para>Vervolgens, voordat u besluit aan wie u uw probleemrapport
-      dient te sturen, moet u weten dat de software waaruit &os; bestaat
-      uit verschillende elementen is opgebouwd:</para>
+    <para>Vervolgens, om te besluiten aan wie u uw probleemrapport dient
+      te sturen, moet u weten dat de software waaruit &os; bestaat uit
+      verschillende elementen is opgebouwd:</para>
 
     <itemizedlist>
       <listitem>
@@ -177,15 +177,15 @@
 
       <listitem>
 	<para>Code in het basissysteem die geschreven is en onderhouden
-	  wordt door anderen, en ge&iuml;mporteerd is in &os; en is
+	  wordt door anderen, en in &os; is ge&iuml;mporteerd en
 	  aangepast.  Voorbeelden zijn <application>bind</application>,
 	  &man.gcc.1;, en &man.sendmail.8;.  De meeste bugs in deze
 	  gebieden dienen aan de &os;-ontwikkelaars gerapporteerd te
 	  worden; maar in sommige gevallen kan het zijn dat ze aan de
 	  originele auteurs gerapporteerd moeten worden als de problemen
-	  niet specifiek voor &os; zijn.  Gewoonlijk vallen deze bugs
-	  ofwel in de categorie <literal>bin</literal> ofwel in de
-	  categorie <literal>gnu</literal>.</para>
+	  niet specifiek voor &os; zijn.  Gewoonlijk vallen deze bugs in
+	  ofwel de categorie <literal>bin</literal> ofwel de categorie
+	  <literal>gnu</literal>.</para>
       </listitem>
 
       <listitem>
@@ -196,12 +196,12 @@
 	  wat &os; biedt is slechts een raamwerk om de applicatie te
 	  installeren.  Daarom dient u alleen een probleem aan de
 	  &os;-ontwikkelaars te rapporteren als u gelooft dat het
-	  probleem &os;-specifiek is; anders dient u het aan de auteurs
-	  van de software te rapporteren.</para>
+	  probleem specifiek voor &os; is; anders dient u het aan de
+	  auteurs van de software te rapporteren.</para>
       </listitem>
     </itemizedlist>
 
-    <para>Daarna dient u vast te stellen of het probleem tijdig is.  Er
+    <para>Daarna dient u vast te stellen of het probleem actueel is.  Er
       zijn maar weinig dingen die een ontwikkelaar meer irriteren dan
       het ontvangen van een probleemrapport over een bug die reeds
       gerepareerd is.</para>
@@ -209,21 +209,21 @@
     <para>Als het probleem in het basissysteem zit, dient u eerst het
       FAQ-gedeelte over <ulink
 	url="&url.books.faq;/introduction.html#LATEST-VERSION">
-	&os;-versies</ulink> te lezen, als u niet reeds bekend bent met
-      het onderwerp.  Het is niet mogelijk voor &os;om problemen in iets
-      anders dan bepaalde recente takken van het basissysteem op te
-      lossen, dus leidt het insturen van een bugrapport over een oudere
+	&os;-versies</ulink> te lezen als u niet reeds bekend bent met
+      het onderwerp.  Het is niet mogelijk voor &os; om problemen in
+      iets anders dan bepaalde recente takken van het basissysteem op te
+      lossen, dus leidt het insturen van een bug-rapport over een oudere
       versie waarschijnlijk alleen tot het advies van een ontwikkelaar
-      die u adviseert om naar een ondersteunde versie bij te werken om
-      te kijken of het probleem nog steeds voorkomt.  Het Security
-      Officer Team onderhoudt de <ulink url="&url.base;/security/">lijst
-	van ondersteunde versies</ulink>.</para>
+      om naar een ondersteunde versie bij te werken om te kijken of het
+      probleem nog steeds voorkomt.  Het Security Officer Team
+      onderhoudt de <ulink url="&url.base;/security/">lijst van
+	ondersteunde versies</ulink>.</para>
 
     <para>Als het probleem in een port zit, moet u uw Portscollectie
       eerst naar de laatste versie bijwerken en kijken of het probleem
       nog steeds van toepassing is.  Wegens de hoge snelheid waarmee
-      deze applicaties veranderen, is het onhaalbaar voor &os; om andere
-      dan de allernieuwste versies te ondersteunen, en problemen met
+      deze applicaties veranderen, is het onhaalbaar voor &os; om iets
+      anders dan de allernieuwste versies te ondersteunen, problemen met
       oudere versies van applicaties kunnen simpelweg niet worden
       opgelost.</para>
   </section>
@@ -232,13 +232,12 @@
     <title>Voorbereidingen</title>
 
     <para>Een goede regel is om altijd een vooronderzoek te doen voordat
-      er een probleemrapport wordt ingestuurd.  Misschien is uw probleem
-      reeds gerapporteerd; misshien wordt het besproken op de
-      mailinglijsten, of gebeurde dat recentelijk; misschien is het al
-      gerepareerd in een nieuwere versie dan die u draait.  Om deze
-      redenen dient u alle voor de hand liggende plaatsen te controleren
-      voordat u uw probleemrapport instuurt.  Voor &os; betekent
-      dit:</para>
+      u een probleemrapport ingestuurd.  Misschien is uw probleem reeds
+      gerapporteerd; misschien wordt het besproken op de mailinglijsten,
+      of gebeurde dat recentelijk; misschien is het al gerepareerd in
+      een nieuwere versie dan die u draait.  Om deze redenen dient u
+      alle voor de hand liggende plaatsen te controleren voordat u uw
+      probleemrapport instuurt.  Voor &os; betekent dit:</para>
 
     <itemizedlist>
       <listitem>
@@ -250,15 +249,16 @@
 	    hardware</ulink>,
 	  <ulink url="&url.books.faq;/applications.html">
 	    gebruikersapplicaties</ulink>, en
-	  <ulink url="&url.books.faq;/kernelconfig.html">kernelconfiguratie</ulink>.</para>
+	  <ulink url="&url.books.faq;/kernelconfig.html">
+	    kernelconfiguratie</ulink>.</para>
       </listitem>
 
       <listitem>
 	<para>De
 	  <ulink
-	    url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">mailinglijsten</ulink>
-	  &mdash;als u niet geabonneerd bent, gebruik dan
-	  <ulink
+	    url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">
+	    mailinglijsten</ulink>&mdash;als u niet geabonneerd bent,
+	  gebruik dan <ulink
 	    url="http://www.FreeBSD.org/search/search.html#mailinglists">;
 	    de doorzoekbare archieven</ulink> op de &os;-website.  Als
 	  uw probleem niet op de lijsten bediscussieerd is, kunt u
@@ -269,8 +269,8 @@
 
       <listitem>
 	<para>Optioneel, het gehele web&mdash;gebruik uw favoriete
-	  zoekmachine om enige referenties naar uw probleem te vinden. U
-	  kunt zelfs hits krijgen van gearchiveerde mailinglijsten of
+	  zoekmachine om referenties naar uw probleem te vinden. U kunt
+	  zelfs hits krijgen van gearchiveerde mailinglijsten of
 	  nieuwsgroepen die u niet kende of waarvan u er niet aan had
 	  gedacht om die te doorzoeken.</para>
       </listitem>
@@ -294,7 +294,7 @@
 	    url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING"></ulink>;
 	  te bestuderen.  (Dit is essenti&euml;le informatie als u van
 	  de ene naar een andere versie bijwerkt&mdash;in het bijzonder
-	  als u naar de &os.current;-tak bijwerkt.)</para>
+	  als u naar de tak &os.current; bijwerkt.)</para>
 
 	<para>Als het probleem echter zit in iets wat als deel van de
 	  &os; Portscollectie was ge&iuml;nstalleerd, dan dient u
@@ -306,7 +306,6 @@
 	  en
 	  <ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES"></ulink>;
 	  zijn ook beschikbaar via CVSweb.</para>
-
       </listitem>
     </itemizedlist>
   </section>
@@ -317,7 +316,7 @@
     <para>Nu u besloten heeft dat uw probleem een probleemrapport
       verdiend, en het een probleem met &os; is, is het tijd om het
       eigenlijke probleemrapport te schrijven.  Voordat het mechanisme
-      van het programma dat gebruikt wordt om PRs aan te maken en in te
+      van het programma dat gebruikt wordt om PR's aan te maken en in te
       sturen wordt behandeld, zijn hier wat tips en trucs die ervoor
       zorgen dat uw PR het meest effectief is.</para>
 
@@ -328,28 +327,28 @@
       <itemizedlist>
 	<listitem>
 	  <para><emphasis>Laat de regel <quote>Synopsis</quote> niet
-	      leeg.</emphasis>  De PRs gaan zowel naar een mailinglijst
+	      leeg.</emphasis> De PR's gaan zowel naar een mailinglijst
 	    die over de gehele wereld wordt verspreid (waar de
 	    <quote>Synopsis</quote> wordt gebruikt voor de
 	    <literal>Onderwerp:</literal>-regel), als in een database.
-	    Iedereen die later de database op onderwerp doorzoekt, en
+	    Iedereen die later de database op samenvatting doorzoekt, en
 	    een PR met een lege onderwerpsregel aantreft, zal het
-	    waarschijnlijk gewoon overslaan.  Onthoud dat PRs in deze
+	    waarschijnlijk gewoon overslaan.  Onthoud dat PR's in deze
 	    database blijven staan totdat iemand ze sluit; een anoniem
 	    PR zal slechts in de massa opgaan.</para>
 	</listitem>
 
 	<listitem>
 	  <para><emphasis>Voorkom het gebruik van een zwakke
-	    <quote>Synopsis</quote>-regel.</emphasis>  U mag niet
-	    aannemen dat iemand die uw PR leest enige context van uw
-	    inzending heeft, dus hoe meer u biedt, des te beter.  Op
-	    welk deel van het systeem heeft het probleem betrekking?
+	    <quote>Synopsis</quote>-regel.</emphasis> U mag niet
+	    aannemen dat iemand die uw PR leest enige achtergrondkennis
+	    van uw inzending heeft, dus des meer u biedt, des te beter.
+	    Op welk deel van het systeem heeft het probleem betrekking?
 	    Ziet u het probleem alleen tijdens het installeren, of
 	    tijdens het draaien?  Ter illustratie, in plaats van
-	    <literal>Synopsis: portupgrade is kapot</literal>, zie
+	    <literal>Synopsis: portupgrade is broken</literal>, zie
 	    hoeveel informatiever dit lijkt: <literal>Synopsis: port
-	      pors-mgmt/portupgrade dumpt core op -current</literal>.
+	      pors-mgmt/portupgrade coredumps on -current</literal>.
 	    (In het geval van ports is het bijzonder behulpzaam om zowel
 	    de categorie als de portnaam in de
 	    <quote>Synopsis</quote>-regel te vermelden.)</para>
@@ -362,13 +361,13 @@
 	    bijsluit, plaats dan de tekst <literal>[patch]</literal>
 	    (inclusief de haken) aan het begin van de
 	    <quote>Synopsis</quote>.  (Alhoewel het niet verplicht is om
-	    die exacte tekst te gebruiken, is dat per conventie diegene
+	    die exacte tekst te gebruiken, is dat per conventie degene
 	    die gebruikt wordt.)</para>
 	</listitem>
 
 	<listitem>
 	  <para><emphasis>Als u een onderhouder bent, zeg dat
-	      dan.</emphasis>  Als u een deel van de broncode onderhoudt
+	      dan.</emphasis> Als u een deel van de broncode onderhoudt
 	    (bijvoorbeeld een port), kunt u overwegen om de tekst
 	    <literal>[maintainer update]</literal> (inclusief de haken)
 	    aan het begin van de onderwerpsregel te plaatsen, en dient u
@@ -379,7 +378,7 @@
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Ben specifiek.</emphasis>  Des te meer
+	  <para><emphasis>Ben specifiek.</emphasis> Des te meer
 	    informatie u aanlevert over wat voor probleem u heeft, des
 	    te groter is de kans dat u een antwoord krijgt.</para>
 
@@ -387,11 +386,11 @@
 	    <listitem>
 	      <para>Vermeld de versie van &os; die u draait (hier is een
 		plaats voor, zie hieronder) en op welke architectuur dat
-		is.  U dient aan te geven of u van een uitgave draait
-		(bijvoorbeeld een CD-ROM of een download), of van een
+		is.  U dient aan te geven of u een uitgave draait
+		(bijvoorbeeld een CD-ROM of een download), of een
 		systeem dat met &man.cvsup.1; wordt onderhouden (en
-		zoja, hoe recentelijk u heeft bijgewerkt).  Als u de
-		&os.current;-tak volgt, is dat het allereerste wat
+		zoja, hoe recentelijk u dat heeft bijgewerkt).  Als u de
+		tak &os.current; volgt, is dat het allereerste wat
 		iemand zal vragen, omdat reparaties (in het bijzonder
 		voor opvallende problemen) de neiging hebben om snel
 		gecommit te worden, en gebruikers van &os.current;
@@ -403,25 +402,26 @@
 		<filename>make.conf</filename> heeft gespecificeerd.
 		Noot: het specificeren van <literal>-O2</literal> en
 		hoger aan &man.gcc.1; staat in veel situaties als
-		buggevoelig bekend.  Hoewel de &os;-ontwikkelaar patches
-		zullen accepteren, zijn ze over het algemeen niet bereid
-		om zulke gevallen te onderzoeken vanwege een simpel
-		gebrek aan tijd en vrijwilligers, en zullen ze in plaats
-		hiervan antwoorden met dat dit gewoon niet ondersteund
-		is.</para>
+		bug-gevoelig bekend.  Hoewel de &os;-ontwikkelaars
+		patches zullen accepteren, zijn ze over het algemeen
+		niet bereid om zulke gevallen te onderzoeken vanwege een
+		simpel gebrek aan tijd en vrijwilligers, en zullen ze in
+		plaats hiervan antwoorden met dat dit gewoon niet
+		ondersteund is.</para>
 	    </listitem>
 
 	    <listitem>
 	      <para>Als het een probleem met de kernel betreft, reken er
 		dan op om de volgende informatie aan te leveren.  (U
 		hoeft deze niet standaard bij te sluiten, wat alleen de
-		database opvult, maar u dient uitreksels bij te sluiten
+		database opvult, maar u dient uittreksel bij te sluiten
 		die u relevant acht):</para>
 
 	      <itemizedlist>
 		<listitem>
 		  <para>uw kernelconfiguratie (inclusief welke
-		    hardware-apparaten u heeft ge&iuml;nstalleerd)</para>
+		    hardware-apparaten u heeft
+		    ge&iuml;nstalleerd)</para>
 		</listitem>
 		<listitem>
 		  <para>of u wel of niet debug-opties aan heeft staan
@@ -455,7 +455,7 @@
 	      <para>Als het een probleem met de ports betreft, reken er
 		dan op om de volgende informatie aan te leveren.  (U
 		hoeft deze niet standaard bij te sluiten, wat alleen de
-		database opvult, maar u dient uitreksels bij te sluiten
+		database opvult, maar u dient uittreksels bij te sluiten
 		die u relevant acht):</para>
 
 	      <itemizedlist>
@@ -482,7 +482,7 @@
 
 	<listitem>
 	  <para><emphasis>Voorkom vage verzoeken voor
-	    mogelijkheden.</emphasis>  PR's van de vorm <quote>iemand
+	    mogelijkheden.</emphasis> PR's van de vorm <quote>iemand
 	      moet echt iets dat zus-en-zo doet implementeren</quote>
 	    leveren minder waarschijnlijk resultaat op dan zeer
 	    specifieke verzoeken.  Onthoud dat de broncode voor iedereen
@@ -496,7 +496,7 @@
 
 	<listitem>
 	  <para><emphasis>Verzeker u ervan dat niemand anders reeds een
-	    soortgelijk PR heeft ingestuurd.</emphasis>  Alhoewel dit al
+	    soortgelijk PR heeft ingestuurd.</emphasis> Alhoewel dit al
 	    hierboven genoemd is, is het het herhalen hier waard.  Het
 	    duurt slechts een minuut of twee om de webgebaseerde
 	    zoekmachine op <ulink
@@ -507,23 +507,23 @@
 
 	<listitem>
 	  <para><emphasis>Voorkom controversi&euml;le
-	    verzoeken.</emphasis>  Als uw PR een gebied behandelt dat in
+	    verzoeken.</emphasis> Als uw PR een gebied behandelt dat in
 	    het verleden controversieel was, dient u waarschijnlijk
-	    bereid te zijn om niet alleen patches aan te leveren, maar
-	    ook een verklaring waarom de patches <quote>Het Juiste Ding
-	      Om Te Doen</quote> zijn.  Zoals hierboven vermeld, is het
-	    zorgvuldig doorzoeken van de mailinglijsten door gebruik te
-	    maken van de archieven op <ulink
+	    bereid te zijn om niet alleen patches, maar ook een
+	    verklaring waarom de patches <quote>Het Juiste Ding Om Te
+	      Doen</quote> zijn aan te leveren.  Zoals hierboven
+	    vermeld, is het zorgvuldig doorzoeken van de mailinglijsten
+	    door gebruik te maken van de archieven op <ulink
 	      url="http://www.FreeBSD.org/search/search.html#mailinglists">;
 	   </ulink> altijd een goede voorbereiding.</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Ben beleefd.</emphasis>  Bijna iedereen die
-	    aan uw PR zal werken is een vrijwilliger.  Niemand houdt
-	    ervan om te horen dat ze iets moeten doen wat ze al aan het
-	    doen zijn voor een andere motivatie dan geld.  Dit is iets
-	    goeds om altijd in de gaten te houden bij Open Source
+	  <para><emphasis>Ben beleefd.</emphasis> Bijna iedereen die aan
+	    uw PR zal werken is een vrijwilliger.  Niemand houdt ervan
+	    om te horen dat ze iets moeten doen wat ze al aan het doen
+	    zijn voor een andere motivatie dan geld.  Dit is iets goeds
+	    om altijd in de gaten te houden bij Open Source
 	    projecten.</para>
 	</listitem>
       </itemizedlist>
@@ -539,20 +539,20 @@
 
       <para>U dient er ook zeker van te zijn dat het afleveren van mail
 	goed werkt.  &man.send-pr.1; gebruikt mailberichten voor het
-	insturen en volgen van probleemrapporten.  ALs u geen
+	insturen en volgen van probleemrapporten.  Als u geen
 	mailberichten kunt posten op de machine waarop u &man.send-pr.1;
 	draait, zal uw probleemrapport de GNATS-database niet bereiken.
 	Zie voor details over het opzetten van mail op &os; het
-	hoofdstuk <quote>Electronische post</quote> van het &os;
+	hoofdstuk <quote>Elektronische post</quote> van het &os;
 	Handboek op
 	<ulink url="http://www.FreeBSD.org/doc/nl_NL.ISO8859-1/books/handbook/mail.html"></ulink>.</para>;
 
       <para>Verzeker u ervan dat uw mailprogramma het bericht onderweg
-	naar GNATS niet vermangelt.  In het bijzonder, als uw mailer
-	automatisch regels afbreekt, tabs in spaties verandert, of
-	nieuwe-regel-tekens ontvlucht, zal elke patch die u instuurt
-	onbruikbaar worden.  Voor de tekstgedeelten vragen wij u echer
-	om handmatig regels rond de 70 tekens af te breken, zodat de
+	naar GNATS niet vermangelt.  In het bijzonder zal elke patch die
+	u instuurt onbruikbaar worden, als uw mailer automatisch regels
+	afbreekt, tabs in spaties verandert, of nieuwe-regel-tekens
+	escapet.  Voor de tekstgedeelten vragen wij u echter om
+	handmatig regels rond de 70 tekens af te breken, zodat de
 	webversie van het PR leesbaar is.</para>
 
       <para>Dezelfde soort overwegingen gelden als u het <ulink
@@ -584,28 +584,28 @@
 	om de namen van de bij te voegen bestanden te
 	specificeren:</para>
 
-<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>
+<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/fouten</userinput></screen>
 
       <para>Maakt u zich geen zorgen over binaire bestanden, deze worden
-	automatisch gecodeerd zodat ze de mailagent niet
+	automatisch gecodeerd zodat ze de mail-agent niet
 	verontrusten.</para>
 
       <para>Als u een patch bijvoegt, gebruik dan de optie
-	<option>-c</option> of <option>-u</option> met &man.diff.1; om
+	<option>-c</option> of <option>-u</option> van &man.diff.1; om
 	een context- of verenigde diff (verenigd is geprefereerd) aan te
-	maken, en zorg ervoor dat u de exactie revisienummers uit CVS
-	specificeert vna de bestanden die u heeft gewijzigd zodat de
+	maken, en zorg ervoor dat u de exacte revisienummers uit CVS
+	specificeert van de bestanden die u heeft gewijzigd zodat de
 	ontwikkelaars die uw rapport lezen ze gemakkelijk kunnen
 	toepassen.  Voor problemen met de kernel of de
 	basisgereedschappen is een patch tegen &os.current; (de CVS-tak
 	HEAD) geprefereerd aangezien alle nieuwe code eerst daar
-	toegepast en getest dient te worden.  Nadat het juist of
-	substanti&euml;le is getest, wordt de code samengevoegd of
-	gemigreerd naar de tak &os.stable;.</para>
+	toegepast en getest dient te worden.  Nadat het voldoende of
+	substantieel is getest, wordt de code samengevoegd of gemigreerd
+	naar de tak &os.stable;.</para>
 
       <para>Als u een patch inline in plaats van als bijlage bijvoegt,
 	merk dan op dat het meest voorkomende probleem de neiging is van
-	sommige emailprogramma's om tabs als spaties weer te geven, wat
+	sommige email-programma's om tabs als spaties weer te geven, wat
 	alles dat bedoeld was als deel van een Makefile volledig
 	ruineert.</para>
 
@@ -620,41 +620,41 @@
 	patches en in het bijzonder nieuwe code waarvoor
 	substanti&euml;le review nodig kan zijn voordat het gecommit
 	wordt op een web- of FTP-server geplaatst dient te worden, en de
-	URL in plaats van de patch dient bij het PR gevoegd te worden.
+	URL in plaats van de patch bij het PR gevoegd dient te worden.
 	Patches in email hebben de neiging om gemangeld te worden, in
-	het bijzonder wanneer GNATS er betrokken in is, en hoe groter
-	de patch, des te moeilijker het is voor ge&iuml;nteresseerde
+	het bijzonder wanneer GNATS erbij betrokken is, en hoe groter de
+	patch, des te moeilijker het is voor ge&iuml;nteresseerde
 	partijen om het te ontrafelen.  Ook stelt het posten van een
-	patch op het web u in staat om het te wijzigen zonder dat nodig
-	is om de gehele patch opnieuw in te zenden als een opvolgbericht
-	op het originele PR.  Ten slotte vergroten grote patches
-	simpelweg de omvang van de database, aangezien gesloten PR's
-	niet worden verwijderd maar in plaats daarvan worden bewaard en
-	simpelweg als <literal>closed</literal> worden
+	patch op het web u in staat om het te wijzigen zonder dat het
+	nodig is om de gehele patch opnieuw in te zenden als een
+	vervolgbericht op het originele PR.  Ten slotte vergroten grote
+	patches simpelweg de omvang van de database, aangezien gesloten
+	PR's niet worden verwijderd maar in plaats daarvan worden
+	bewaard en simpelweg als <literal>closed</literal> worden
 	gemarkeerd.</para>
 
-      <para>U dient ook te weten dat tenzij u het expliciet vermeld in
-	uw PR of in de patch zelf, dat van alle patches die u instuurt
+      <para>U dient ook te weten dat tenzij u het expliciet in uw PR of
+	in de patch zelf vermeld, dat van alle patches die u instuurt
 	wordt aangenomen dat ze onder dezelfde licentietermen vallen als
-	het origninele bestand dat u heeft gewijzigd.</para>
+	het originele bestand dat u heeft gewijzigd.</para>
     </section>
 
     <section>
       <title>Het sjabloon invullen</title>
 
       <para>De volgende sectie heeft alleen betrekking op de
-	emailmethode:</para>
+	email-methode:</para>
 
       <para>Wanneer u &man.send-pr.1; draait, wordt er een sjabloon aan
 	u gepresenteerd.  Het sjabloon bestaat uit een lijst met velden,
 	waarvan sommige al zijn ingevuld, en waarvan bij anderen staat
 	uitgelegd wat de bedoeling is of wat acceptabele waarden zijn.
-	Maakt u zich geeen zorgen over het commentaar, deze worden
-	automatisch verwijderds wanneer u ze niet wijzigt of ze zelf
+	Maakt u zich geen zorgen over het commentaar, deze worden
+	automatisch verwijderd wanneer u ze niet wijzigt of ze zelf
 	verwijdert.</para>
 
       <para>Bovenaan het sjabloon, onder de regels met
-	<literal>SEND-PR:</literal>, staan de emailkoppen.  U hoeft
+	<literal>SEND-PR:</literal>, staan de email-koppen.  U hoeft
 	deze normaalgesproken niet te wijzigen, tenzij u het
 	probleemrapport vanaf een machine of account verstuurt die wel
 	mail kan versturen maar niet kan ontvangen; in dat geval wilt u
@@ -665,7 +665,7 @@
 	emailadressen aan de kop <literal>Cc:</literal> toe te
 	voegen.</para>
 
-      <para>In het emailsjabloon vindt u de volgende twee velden van
+      <para>In het email-sjabloon vindt u de volgende twee velden van
 	&eacute;&eacute;n regel:</para>
 
       <itemizedlist>
@@ -679,14 +679,14 @@
 	  <para><emphasis>Confidential:</emphasis> Dit is vooraf
 	    ingevuld met <literal>no</literal>.  Het heeft geen zin om
 	    dit te veranderen aangezien er geen vertrouwelijk &os;
-	    probleemrapport bestaat&mdash; de PR-database wordt
+	    probleemrapport bestaat&mdash;de PR-database wordt
 	    wereldwijd gedistribueerd door
 	    <application>CVSup</application>.</para>
 	</listitem>
       </itemizedlist>
 
       <para>De volgende sectie beschrijft velden die zowel in de
-	emailinterface als in de <ulink
+	email-interface als in de <ulink
 	  url="&url.base;/send-pr.html">webinterface</ulink>
 	voorkomen:</para>
 
@@ -695,34 +695,35 @@
 	  <para><emphasis>Originator:</emphasis>
 	    Specificeer hier alstublieft uw echte naam, eventueel
 	    gevolgd door uw emailadres in punthaken.  In de
-	    emailinterface wordt dit normaalgesproken vooraf ingevuld
+	    email-interface wordt dit normaalgesproken vooraf ingevuld
 	    met het <literal>gecos</literal>-veld van de huidige
 	    aangemelde gebruiker.</para>
 
 	  <note>
 	    <para>Het emailadres dat u gebruikt wordt publieke
 	      informatie en kan in de handen van spammers vallen.  U
-	      dient ofwel maatregelen te treffen om spam af te handelen,
-	      of een tijdelijk emailaccount te gebruiken.  Merk op dat
-	      als u een in het geheel ongeldig emailaccount gebruikt,
-	      wij u geen vragen over uw PR kunnen stellen.</para>
+	      dient &ograve;fwel maatregelen te treffen om spam af te
+	      handelen, &ograve;f een tijdelijk emailaccount te
+	      gebruiken.  Merk op dat als u een in het geheel ongeldig
+	      emailaccount gebruikt, wij u geen vragen over uw PR kunnen
+	      stellen.</para>
 	  </note>
 
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Organization:</emphasis>  Alles waarvan u
+	  <para><emphasis>Organization:</emphasis> Alles waarvan u
 	    vrolijk wordt.  Dit veld wordt niet voor iets significants
 	    gebruikt.</para>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Synopsis:</emphasis>  Vul hier een korte en
+	  <para><emphasis>Synopsis:</emphasis> Vul hier een korte en
 	    accurate beschrijving van het probleem in.  De samenvatting
 	    wordt gebruikt als het onderwerp van de email van het
 	    probleemrapport, en wordt gebruikt in lijsten en
 	    samenvattingen van probleemrapporten; probleemrapporten met
-	    een vage samenvatting hebben de neiging om genegeerd te
+	    een obscure samenvatting hebben de neiging om genegeerd te
 	    worden.</para>
 
 	  <para>Zoals hierboven vermeld, als uw probleemrapport een
@@ -735,7 +736,7 @@
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Severity:</emphasis>  E&eacute;n van
+	  <para><emphasis>Severity:</emphasis> E&eacute;n van
 	    <literal>non-critical</literal>,
 	    <literal>serious</literal> of
 	    <literal>critical</literal>.  Overdrijf niet, bestempel uw
@@ -748,21 +749,22 @@
 	      apparaatstuurprogramma's of systeemgereedschappen).
 	      &os;-ontwikkelaars zullen niet noodzakelijk sneller aan uw
 	      probleem werken als u de belangrijkheid ervan opblaast
-	      aangezien er vele anderen zijn die hetzelfde gedaan hebben
-	      &mdash; in feite schenken sommige ontwikkelaars weinig
-	      aandacht aan dit veld vanwege deze redenen.</para>
+	      aangezien er vele anderen zijn die precies hetzelfde
+	      gedaan hebben &mdash; in feite schenken sommige
+	      ontwikkelaars weinig aandacht aan dit veld vanwege deze
+	      redenen.</para>
 
 	  <note>
 	    <para>Grote beveiligingsproblemen dienen
 	      <emphasis>niet</emphasis> naar GNATS gestuurd te worden,
 	      omdat alle GNATS-informatie publieke kennis is.  Stuur
-	      zulke problemen alstublieft als priv&eacute;-mail naar
+	      zulke problemen alstublieft per priv&eacute;-mail naar
 	      &a.security-officer;.</para>
 	  </note>
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Priority:</emphasis>  E&eacute;n van
+	  <para><emphasis>Priority:</emphasis> E&eacute;n van
 	    <literal>low</literal>, <literal>medium</literal> of
 	    <literal>high</literal>.  <literal>high</literal> dient te
 	    worden gereserveerd voor problemen die bijna iedere
@@ -776,7 +778,7 @@
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Category:</emphasis>  Kies een geschikte
+	  <para><emphasis>Category:</emphasis> Kies een geschikte
 	    categorie.</para>
 
 	  <para>Het eerste wat u moet doen is beslissen in welk gebied
@@ -797,8 +799,8 @@
 	    <listitem>
 	      <para>Als er een probleem met de kernel, de bibliotheken
 		(zoals de standaard C-bibliotheek
-		<literal>libc</literal>), of met een hulpstuurprogramma
-		is, gebruikt u in het algemeen de categorie
+		<literal>libc</literal>), of een hulpstuurprogramma is,
+		gebruikt u in het algemeen de categorie
 		<literal>kern</literal>.  (Er zijn enkele uitzonderingen
 		die hieronder vermeld staan).  In het algemeen zijn dat
 		dingen die in sectie 2, 3, of 4 van de
@@ -806,19 +808,19 @@
 	    </listitem>
 
 	    <listitem>
-	      <para>Als er een probleem is met een binair programma
-		zoals &man.sh.1; of &man.mount.8;, dient u eerst te
-		bepalen of deze programma's deel zijn van het
-		basissysteem of dat ze via de Portscollectie zijn
-		toegevoegd.  Als u het niet zeker weet, kunt u
-		<command>whereis <replaceable>programmanaam</replaceable></command>
+	      <para>Als er een probleem met een binair programma zoals
+		&man.sh.1; of &man.mount.8; is, dient u eerst te bepalen
+		of deze programma's deel zijn van het basissysteem of
+		dat ze via de Portscollectie zijn toegevoegd.  Als u het
+		niet zeker weet, kunt u <command>whereis
+		  <replaceable>programmanaam</replaceable></command>
 		uitvoeren.  De conventie van &os; voor de Portscollectie
 		is om alles onder <filename
 		  class="directory">/usr/local</filename> te
 		installeren, alhoewel dit door een systeembeheerder
 		veranderd kan worden.  Voor dezen gebruikt u de
 		categorie <literal>ports</literal> (zelfs als de
-		categorie van de port <literal>www</literal> is, zie
+		categorie van de port <literal>www</literal> is; zie
 		hieronder).  Als de locatie
 		<filename class="directory">/bin</filename>,
 		<filename class="directory">/usr/bin</filename>,
@@ -836,7 +838,7 @@
 	    <listitem>
 	      <para>Als u denkt dat de fout in de opstartscripts
 		<literal>(rc)</literal> zit, of in een ander type
-		niet-uitvoerbaar configuratiebestand, dan is de juiste
+		onuitvoerbaar configuratiebestand, dan is de juiste
 		categorie <literal>conf</literal> (configuratie).  Deze
 		dingen worden in sectie 5 van de handleidingpagina's
 		beschreven.</para>
@@ -943,7 +945,7 @@
 	    </listitem>
 
 	    <listitem>
-	      <para>Als u echt niet weet waar het problem zich bevindt
+	      <para>Als u echt niet weet waar het probleem zich bevindt
 		(of als de uitleg niet bij een van de bovenstaanden
 		lijkt te passen), gebruik dan de categorie
 		<literal>misc</literal>.  Voordat u dit doet, kunt u
@@ -1016,7 +1018,7 @@
 
 	    <listitem>
 	      <para><literal>kern:</literal> problemen met de kernel,
-		(niet-platformspecifieke) apparaatstuurprogramma's, of
+		(platforminspecifieke) apparaatstuurprogramma's, of
 		de basisbibliotheken.</para>
 	    </listitem>
 
@@ -1104,12 +1106,12 @@
 	  <para><emphasis>Release:</emphasis> De versie van &os; die u
 	    draait.  Dit wordt automatisch ingevuld als u
 	    &man.send-pr.1; gebruikt en hoeft alleen veranderd te worden
-	    als u een probleemrapport verstuurt van een ander systeem
+	    als u een probleemrapport verstuurt vanaf een ander systeem
 	    dan van hetgene waarop het probleem zich voordoet.</para>
 	</listitem>
       </itemizedlist>
 
-      <para>Tenslote zijn er een aantal meerregelige velden:</para>
+      <para>Ten slotte zijn er een aantal meerregelige velden:</para>
 
       <itemizedlist>
 	<listitem>
@@ -1119,7 +1121,7 @@
 	    besturingssysteem, de versie van het specifieke programma of
 	    bestand dat het probleem bevat, en alle andere relevante
 	    zaken zoals systeemconfiguratie, andere ge&iuml;nstalleerde
-	    software dat het probleem be&iuml;nvloed, enzovoorts&mdash;
+	    software dat het probleem be&iuml;nvloedt, enzovoorts&mdash;
 	    eigenlijk alles wat een ontwikkelaar moet weten om de
 	    omgeving te reconstrueren waarin het probleem
 	    optreedt.</para>
@@ -1128,15 +1130,15 @@
 	<listitem>
 	  <para><emphasis>Description:</emphasis> Een complete en
 	    nauwkeurige beschrijving van het probleem dat u ondervindt.
-	    Probeer te speculaties over de oorzaken van het probleem te
-	    vermijden tenzij u zeker dat u op het juiste spoor zit,
-	    aangezien het een ontwikkelaar kan misleiden om onjuiste
-	    aannames over het probleem te maken.</para>
+	    Probeer speculaties over de oorzaken van het probleem te
+	    vermijden tenzij u zeker weet dat u op het juiste spoor zit,
+	    aangezien een ontwikkelaar hierdoor onjuiste aannames over
+	    het probleem kan maken.</para>
 	</listitem>
 
 	<listitem>
 	  <para><emphasis>How-To-Repeat:</emphasis> Een samenvatting van
-	    de acties die voor u nodig waren om het probleem te
+	    de acties die nodig waren om het probleem te
 	    reproduceren.</para>
 	</listitem>
 
@@ -1160,12 +1162,12 @@
       <para>Als u klaar bent met het invullen van het sjabloon, het
 	heeft opgeslagen, en uw tekstverwerker verlaten heeft, zal
 	&man.send-pr.1; u de prompt <prompt>s)end, e)dit or
-	  a)bort?</prompt> geven.  U kunt dan <userinput>s</userinput>
+	  a)bort?</prompt> tonen.  U kunt dan <userinput>s</userinput>
 	aanslaan om het probleemrapport in te sturen,
 	<userinput>e</userinput> aanslaan om de tekstverwerker te
 	herstarten en verdere wijzigingen te maken, of
 	<userinput>a</userinput> aanslaan om te stoppen.  Als u het
-	laatste keist, blijft uw probleemrapport bewaard op schijf
+	laatste kiest, blijft uw probleemrapport bewaard op schijf
 	(&man.send-pr.1; vertelt u de bestandsnaam voordat het eindigt),
 	zodat u het rustig kunt bewerken, of het misschien over kunt
 	plaatsen naar een systeem met een betere netverbinding, voordat
@@ -1175,7 +1177,7 @@
 <screen>&prompt.user; <userinput>send-pr -f ~/mijn-probleemrapport</userinput></screen>
 
       <para>Dit leest het gespecificeerde bestand, controleert de
-	geldigheid van de inhoud, verwijderd commentaar en verstuurt
+	geldigheid van de inhoud, verwijdert commentaar en verstuurt
 	het.</para>
 
       <para>Als u het <ulink
@@ -1186,19 +1188,19 @@
 	veld invullen waarin tekst staat dat als afbeelding op de pagina
 	wordt weergegeven.  Deze ongelukkige maatregel moest worden
 	genomen vanwege het misbruik door geautomatiseerde systemen en
-	enkele kwaadwillende gebruikers.  Het is noodzakelijk kwaad dat
-	niemand wil; vraag ons alstublieft niet om het te
+	enkele kwaadwillige gebruikers.  Het is noodzakelijk kwaad dat
+	niemand leuk vindt; vraag ons alstublieft niet om het te
 	verwijderen.</para>
 
       <para>Merk op dat u <literal>ten zeerste wordt
 	  aangeraden</literal> om uw werk ergens op te slaan voordat u
-	op <literal>submit</literal> drukt.  Een veelvoorkomed probleem
+	op <literal>submit</literal> drukt.  Een veelvoorkomend probleem
 	voor gebruikers is dat hun webbrowser een verouderde afbeelding
 	uit de cache laat zien.  Als u dit overkomt, wordt uw inzending
 	geweigerd en kan u uw werk verliezen.</para>
 
       <para>Als u om een bepaalde reden geen afbeeldingen kunt bekijken,
-	en u ook &man.send-pr.1; niet kan gebruiken, accepteer dan
+	en u ook &man.send-pr.1; niet kunt gebruiken, accepteer dan
 	alstublieft onze verontschuldigingen voor het ongemak en email
 	uw probleemrapport naar het bugbuster-team op
 	<email>freebsd-bugbusters@FreeBSD.org</email>.</para>
@@ -1208,7 +1210,7 @@
   <section id="pr-followup">
     <title>Vervolg</title>
 
-    <para>Als uw probleemprapport eenmaal is ingestuurd, ontvangt u een
+    <para>Als uw probleemrapport eenmaal is ingestuurd, ontvangt u een
       bevestiging per email waarin het volgnummer dat aan uw
       probleemrapport was toegewezen en een URL dat u kunt gebruiken om
       de status te controleren zijn opgenomen.  Met een beetje geluk zal
@@ -1221,8 +1223,8 @@
 
     <para>Als iemand aanvullende informatie van u vraagt, of als u zich
       iets herinnert of iets ontdekt dat u niet in het initi&euml;le
-      rapport noemde, gebruik dan alstublieft een van de twee methoden
-      om uw vervolg in te sturen:</para>
+      rapport noemde, gebruik dan alstublieft &eacute;&eacute;n van de
+      twee methoden om uw vervolg in te sturen:</para>
 
     <itemizedlist>
       <listitem>
@@ -1231,31 +1233,31 @@
 	  bereiken vanuit de <ulink
 	    url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">;
 	  PR-zoekpagina</ulink>.  Het klikken op deze koppeling brengt
-	  een emailvenster naar voren met daarin de juiste regels voor
+	  een email-venster naar voren met daarin de juiste regels voor
 	  Aan: en Onderwerp: ingevuld (als uw browser is ingesteld om
 	  dit te doen).</para>
       </listitem>
 
       <listitem>
 	<para>Als alternatief kunt u het naar &a.bugfollowup; mailen,
-	  waar het volgnummer in het onderwerp is opgenomen zodat het
+	  waarbij het volgnummer in het onderwerp is opgenomen zodat het
 	  foutenvolgsysteem weet aan welk probleemrapport het het moet
 	  koppelen.</para>
 
 	<note>
-	  <para>Als u <emphasis>niet</emphasis> het volgnummer opgeeft,
+	  <para>Als u het volgnummer <emphasis>niet</emphasis> opgeeft,
 	    raakt GNATS in de war en maakt het een geheel nieuw PR aan
-	    welke het dan aan de GNATS-beheerder toekent, en vervolgens
-	    raakt uw PR kwijt totdat iemand de rommel opruimt, wat dagen
-	    of weken later kan zijn.</para>
+	    welke het vervolgens aan de GNATS-beheerder toekent, en
+	    vervolgens raakt uw PR kwijt totdat iemand de rommel
+	    opruimt, wat dagen of weken later kan zijn.</para>
 
 	  <para>Verkeerde manier:</para>
 
-	  <programlisting>Onderwerp: dat PR dat ik stuurde</programlisting>
+	  <programlisting>Onderwerp: that PR I sent</programlisting>
 
 	  <para>Juiste manier:</para>
 
-	  <programlisting>Onderwerp: Re: ports/12345: compilatieprobleem met foo/bar</programlisting>
+	  <programlisting>Onderwerp: Re: ports/12345: compilation problem with foo/bar</programlisting>
 	</note>
       </listitem>
     </itemizedlist>
@@ -1270,48 +1272,48 @@
     <title>Als u problemen heeft</title>
 
     <para>De meeste PR's gaan door het systeem en worden snel
-      geaccepteerd, soms loopt GNATS echter achter en kan het zijn dat u
-      uw emailbevestiging pas na 10 minuten of zelfs later ontvangt.
+      geaccepteerd; soms loopt GNATS echter achter en kan het zijn dat u
+      uw email-bevestiging pas na 10 minuten of zelfs later ontvangt.
       Wees alstublieft geduldig.</para>
 
     <para>Tevens geldt, omdat GNATS alle invoer via email ontvangt, dat
       het absoluut noodzakelijk is dat &os; alle inzendingen door
-      spamfilters haalt. Als u binnen een uur of twee geen antwoord
-      krijgt, kan uw PR misschien zijn opeslokt; als dit zo is, neem dan
-      alstublieft contact op met de GNATS-beheerders op
+      spam-filters haalt. Als u binnen een uur of twee geen antwoord
+      krijgt, kan uw PR misschien zijn opgeslokt; als dit zo is, neem
+      dan alstublieft contact op met de GNATS-beheerders op
       <email>bugmeister@FreeBSD.org</email> en vraag om hulp.</para>
 
     <note>
       <para>Een veelvoorkomende anti-spam-maatregel is het vergelijken
 	met vele vormen van misbruik die in HTML-gebaseerde email
-	voorkomt (alhoewel niet slechts het opnemen van HTML in een PR).
-	We raden het gebruik van HTML-gebaseerde email voor het
-	versturen van PR's sterk af: niet alleen is het waarschijnlijker
-	dat het niet door de filters komt, het heeft ook de neiging om
-	de database te verstoppen.  Oude platte email wordt sterk
-	geprefereerd.</para>
+	voorkomen (alhoewel niet noodzakelijk het slechts opnemen van
+	HTML in een PR).  We raden het gebruik van HTML-gebaseerde email
+	voor het versturen van PR's sterk af: niet alleen is het
+	waarschijnlijker dat het niet door de filters komt, het heeft
+	ook de neiging om de database te verstoppen.  Oude platte email
+	wordt sterk geprefereerd.</para>
     </note>
 
     <para>In zeldzame gevallen zult een bug in GNATS tegenkomen waarbij
-      een PR geaccepteerd is een een volgnummer toegewezen heeft
-      gekregen maar waar het niet op de lijst van PR's van een van de
+      een PR geaccepteerd is en een volgnummer toegewezen heeft gekregen
+      maar waarbij het niet op de lijst van PR's van een van de
       opvraag-webpagina's staat.  Het kan zijn gebeurd dat de index van
-      database niet meer met de databsae zelf is gesynchroniseerd.  De
-      manier waarop u dit kunt testen is door de <ulink
+      database niet meer met de database zelf is gesynchroniseerd.  De
+      manier waarop u dit kunt testen is door de webpagina <ulink
 	url="http://www.FreeBSD.org/cgi/query-pr.cgi">bekijk een enkel
-	PR</ulink> webpagina op te roepen en te kijken of de PR wordt
-      vermeld.  Als dat zo is, stel dan alstublieft de GNATS-beheerders
-      op <email>bugmeister@FreeBSD.org</email> op de hoogte.  Merk op
-      dat er een <literal>cron</literal>-taak is die de database
-      periodiek herbouwt, dus u hoeft geen actie te ondernemen tenzij u
-      haast heeft.</para>
+	PR</ulink> op te roepen en te kijken of het PR wordt vermeld.
+      Als dat zo is, stel dan alstublieft de GNATS-beheerders op
+      <email>bugmeister@FreeBSD.org</email> op de hoogte.  Merk op dat
+      er een <literal>cron</literal>-taak is die de database periodiek
+      herbouwt, dus u hoeft geen actie te ondernemen tenzij u haast
+      heeft.</para>
   </section>
 
   <section id="pr-further">
     <title>Verdere literatuur</title>
 
     <para>Er is een lijst met bronnen die relevant is voor het juist
-      scrhijven en verwerken van probleemrapporten.  Het is in geen
+      schrijven en verwerken van probleemrapporten.  Het is in geen
       geval compleet.</para>
 
     <itemizedlist>
@@ -1319,7 +1321,7 @@
 	<para><ulink
 	    url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">;
 	    How to Report Bugs Effectively</ulink>&mdash;een uitstekend
-	    essay door Simon G. Tatham over het samenstellen van

>>> TRUNCATED FOR MAIL (1000 lines) <<<



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812241406.mBOE63hN005951>