PERFORCE change 155136 for review
Rene Ladan
rene at FreeBSD.org
Mon Dec 22 16:03:40 PST 2008
http://perforce.freebsd.org/chv.cgi?CH=155136
Change 155136 by rene at 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 at 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
More information about the p4-projects
mailing list