Date: Tue, 23 Dec 2008 00:03:39 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 155136 for review Message-ID: <200812230003.mBN03dmb060738@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=155136 Change 155136 by rene@rene_self on 2008/12/23 00:03:22 Translated 53% of problem-reports. Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#6 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/articles/problem-reports/article.sgml#6 (text+ko) ==== @@ -259,12 +259,12 @@ url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">mailinglijsten</ulink> —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 proberen - om er een bericht over te posten en enkele dagen wachten om te - zien of iemand iets kan zien wat u misschien over het hoofd - heeft gezien.</para> + 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 + proberen om er een bericht over te posten en enkele dagen + wachten om te zien of iemand iets kan zien wat u misschien + over het hoofd heeft gezien.</para> </listitem> <listitem> @@ -464,9 +464,6 @@ </listitem> <listitem> - <para>any environment variables that override the - defaults in <filename>bsd.port.mk</filename>, such - as <makevar>PORTSDIR</makevar></para> <para>alle omgevingsvariabelen die de standaardwaarden in <filename>bsd.port.mk</filename> overschrijven, zoals <makevar>PORTSDIR</makevar></para> @@ -574,114 +571,126 @@ </section> <section> - <title>Attaching patches or files</title> + <title>Patches of bestanden bijvoegen</title> - <para>The following applies to submitting PRs via email:</para> + <para>Het volgende geldt voor het versturen van PR's via + email:</para> - <para>The &man.send-pr.1; program has provisions for attaching - files to a problem report. You can attach as many files as - you want provided that each has a unique base name (i.e. the - name of the file proper, without the path). Just use the - <option>-a</option> command-line option to specify the names - of the files you wish to attach:</para> + <para>Het programma &man.send-pr.1; heeft voorzieningen voor het + bijvoegen van bestanden aan een probleemrapport. U kunt zoveel + bestanden bijvoegen als u wilt op voorwaarde dat elk bestand een + unieke basisnaam (i.e. de naam van het bestand zelf, zonder het + pad) heeft. Gebruik de opdrachtregeloptie <option>-a</option> + 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> - <para>Do not worry about binary files, they will be automatically - encoded so as not to upset your mail agent.</para> + <para>Maakt u zich geen zorgen over binaire bestanden, deze worden + automatisch gecodeerd zodat ze de mailagent niet + verontrusten.</para> - <para>If you attach a patch, make sure you use the - <option>-c</option> or <option>-u</option> option to - &man.diff.1; to create a context or unified diff (unified is - preferred), and make - sure to specify the exact CVS revision numbers of the files - you modified so the developers who read your report will be - able to apply them easily. For problems with the kernel or the - base utilities, a patch against &os.current; (the HEAD - CVS branch) is preferred since all new code should be applied - and tested there first. After appropriate or substantial testing - has been done, the code will be merged/migrated to the &os.stable; - branch.</para> + <para>Als u een patch bijvoegt, gebruik dan de optie + <option>-c</option> of <option>-u</option> met &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 + 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ële is getest, wordt de code samengevoegd of + gemigreerd naar de tak &os.stable;.</para> - <para>If you attach a patch inline, instead of as an attachment, - note that the most common problem by far is the tendency of some - email programs to render tabs as spaces, which will completely - ruin anything intended to be part of a Makefile.</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 + alles dat bedoeld was als deel van een Makefile volledig + ruineert.</para> - <para>Do not send patches as attachments using + <para>Stuur geen patches als bijlagen door gebruik te maken van <command>Content-Transfer-Encoding: quoted-printable</command>. - These will perform character escaping and the entire patch - will be useless.</para> + Dit zal karakter-escaping uitvoeren en de gehele patch + waardeloos maken.</para> - <para>Also note that while including small patches in a PR is - generally all right—particularly when they fix the problem - described in the PR—large patches and especially new code - which may require substantial review before committing should - be placed on a web or ftp server, and the URL should be - included in the PR instead of the patch. Patches in email - tend to get mangled, especially when GNATS is involved, and - the larger the patch, the harder it will be for interested - parties to unmangle it. Also, posting a patch on the web - allows you to modify it without having to resubmit the entire - patch in a followup to the original PR. Finally, large - patches simply increase the size of the database, since - closed PRs are not actually deleted but instead kept and - simply marked as <literal>closed</literal>.</para> + <para>Merk ook op dat hoewel het over het algemeen goed is om + kleine patches in een PR op te nemen—in het bijzonder als + ze het probleem dat in het PR beschreven is oplossen—grote + patches en in het bijzonder nieuwe code waarvoor + substantië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. + 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ï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 + gemarkeerd.</para> - <para>You should also take note that unless you explicitly - specify otherwise in your PR or in the patch itself, any - patches you submit will be assumed to be licensed under the - same terms as the original file you modified.</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 + wordt aangenomen dat ze onder dezelfde licentietermen vallen als + het origninele bestand dat u heeft gewijzigd.</para> </section> <section> - <title>Filling out the template</title> + <title>Het sjabloon invullen</title> - <para>The next section applies to the email method only:</para> + <para>De volgende sectie heeft alleen betrekking op de + emailmethode:</para> - <para>When you run &man.send-pr.1;, you are presented with a - template. The template consists of a list of fields, some of - which are pre-filled, and some of which have comments explaining - their purpose or listing acceptable values. Do not worry - about the comments; they will be removed automatically if you - do not modify them or remove them yourself.</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 + verwijdert.</para> - <para>At the top of the template, below the - <literal>SEND-PR:</literal> lines, are the email headers. You - do not normally need to modify these, unless you are sending - the problem report from a machine or account that can send but - not receive mail, in which case you will want to set the - <literal>From:</literal> and <literal>Reply-To:</literal> to - your real email address. You may also want to send yourself - (or someone else) a carbon copy of the problem report by - adding one or more email addresses to the - <literal>Cc:</literal> header.</para> + <para>Bovenaan het sjabloon, onder de regels met + <literal>SEND-PR:</literal>, staan de emailkoppen. 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 + waarschijnlijk de velden <literal>From:</literal> en + <literal>Reply-To:</literal> op uw echte emailadres instellen. + U kunt uzelf (of iemand anders) een carbonkopie van het + probleemrapport versturen door één of meer + emailadressen aan de kop <literal>Cc:</literal> toe te + voegen.</para> - <para>In the email template you will find the following two - single-line fields:</para> + <para>In het emailsjabloon vindt u de volgende twee velden van + één regel:</para> <itemizedlist> <listitem> - <para><emphasis>Submitter-Id:</emphasis> Do not change this. - The default value of <literal>current-users</literal> is - correct, even if you run &os.stable;.</para> + <para><emphasis>Submitter-Id:</emphasis> Verander dit niet. + De standaardwaarde <literal>current-users</literal> is + juist, zelfs als u &os.stable; draait.</para> </listitem> <listitem> - <para><emphasis>Confidential:</emphasis> This is prefilled - to <literal>no</literal>. Changing it makes no sense as - there is no such thing as a confidential &os; problem - report—the PR database is distributed worldwide by + <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— de PR-database wordt + wereldwijd gedistribueerd door <application>CVSup</application>.</para> </listitem> - </itemizedlist> - <para>The next section describes fields that are common to both - the email interface and the <ulink url="&url.base;/send-pr.html">web interface</ulink>:</para> + <para>De volgende sectie beschrijft velden die zowel in de + emailinterface als in de <ulink + url="&url.base;/send-pr.html">webinterface</ulink> + voorkomen:</para> <itemizedlist> - <listitem> <para><emphasis>Originator:</emphasis> Please specify your real name, optionally followed @@ -1167,7 +1176,6 @@ the inconvenience and email your problem report to the bugbuster team at <email>freebsd-bugbusters@FreeBSD.org</email>.</para> </section> - </section> <section id="pr-followup"> @@ -1221,7 +1229,6 @@ <programlisting>Subject: Re: ports/12345: compilation problem with foo/bar</programlisting> </note> </listitem> - </itemizedlist> <para>If the problem report remains open after the problem has
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812230003.mBN03dmb060738>