german/Bugs/Developer.wml:

  * Synced from english rev. 1.82 to 1.83
  * Several changes to improve speaking, fix typos + commas

CVS version numbers

german/Bugs/Developer.wml: 1.84 -> 1.85

1 files changed, 56 insertions, 41 deletions

diff --git a/german/Bugs/Developer.wml b/german/Bugs/Developer.wml
index 15a6016f7ab..284a94e5f27 100644
--- a/german/Bugs/Developer.wml
+++ b/german/Bugs/Developer.wml
@@ -1,5 +1,5 @@
 #use wml::debian::template title="Debian BTS – Entwicklerinformationen" NOHEADER=yes NOCOPYRIGHT=true
-#use wml::debian::translation-check translation="1.82"
+#use wml::debian::translation-check translation="1.83"
 # $Id$
 # Translator: Igor Stroh <jenner@wohnheim.uni-ulm.de>
 
@@ -23,7 +23,7 @@ wird so geändert, dass es beide, den Absender des Fehlerberichts und
 <ul class="toc">
   <li><a href="#closing">Fehlerberichte schließen</a></li>
   <li><a href="#followup">Followup-Nachrichten</a></li>
-  <li><a href="#severities">Schwere</a></li>
+  <li><a href="#severities">Schweregrad</a></li>
   <li><a href="#tags">Markierungen für Fehlerberichte</a></li>
   <li><a href="#forward">Aufzeichnen, dass Sie den Fehlerbericht
     weitergeleitet haben</a></li>
@@ -63,8 +63,8 @@ das <code>To</code>-Feld auf
 (statt <var>nnn</var><code>-done</code> kann man auch
 <var>nnn</var><code>-close</code> verwenden).</p>
 
-<p>Wo anwendbar, geben Sie eine <code>Version</code>-Zeile im <a
-href="Reporting#pseudoheader">pseudo-header</a> Ihrer Nachricht ein, wenn
+<p>Wo anwendbar, geben Sie eine <code>Version</code>-Zeile in den <a
+href="Reporting#pseudoheader">Pseudo-Kopfzeilen</a> Ihrer Nachricht ein, wenn
 Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher 
 Veröffentlichung des Paketes die Korrektur enthalten ist.
 </p>
@@ -79,11 +79,11 @@ die an <var>nnn</var><code>-done</code> geschickt wurde.</p>
 <h2><a name="followup">Followup-Nachrichten</a></h2>
 
 <p>Die Fehlerdatenbank wird die Einsenderadresse und die Fehleradresse
-(<var>nnn</var><code>@bugs.debian.org</code>) in der <code>Reply-To</code>-Kopfzeile
+(<var>nnn</var><code>@bugs.debian.org</code>) in die <code>Reply-To</code>-Kopfzeile
 nach dem Weiterleiten des Fehlerberichts aufnehmen. Bitte beachten Sie,
 dass dies zwei unterschiedliche Adressen sind.</p>
 
-<p>Wenn ein Entwickler auf einen Fehlerbericht antworten möchte, sollten Sie
+<p>Wenn ein Entwickler auf einen Fehlerbericht antworten möchte, sollte dieser
 einfach auf die Nachricht antworten und die <code>Reply-To</code>-Kopfzeile
 respektieren. Das wird den Fehlerbericht <strong>nicht</strong>
 schließen.</p>
@@ -102,8 +102,8 @@ geschickt.
 </p>
 
 
-<p>Wenn Sie eine Followup-Nachricht schicken möchten, die nicht in
-<code>debian-bugs-dist</code> passt, dann können Sie es tun, indem Sie
+<p>Wenn Sie eine Followup-Nachricht schicken möchten, die nicht für
+<code>debian-bugs-dist</code> passend ist, dann können Sie dies tun, indem Sie
 diese Nachricht an <var>nnn</var><code>-quiet@bugs.debian.org</code> oder an
 <var>nnn</var><code>-maintonly@bugs.debian.org</code> schicken.
 E-Mails an <var>nnn</var><code>-quiet@bugs.debian.org</code> werden in der
@@ -114,7 +114,7 @@ Fehlerdatenbank gespeichert und nur an den Betreuer des betroffenen
 Pakets weitergeleitet.</p>
 
 
-<p>Benutzen Sie <em>auf keinen Fall</em> die <q>an alle Empfänger
+<p>Benutzen Sie <em>auf keinen Fall</em> die <q>Allen
 antworten</q>- oder die <q>followup</q>-Funktion Ihres E-Mail-Programms, es sei
 denn, Sie möchten die Liste der Empfänger grundsätzlich selbst überarbeiten.
 Achten Sie insbesondere darauf, dass Sie keine Followup-Nachrichten an
@@ -131,12 +131,12 @@ Sie in die
 <h2><a name="severities">Schweregrad</a></h2>
 
 <p>Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen
-Schweregrad. Diese wird standardmäßig auf <code>normal</code>
+Schweregrad. Dieser wird standardmäßig auf <code>normal</code>
 gesetzt, was jedoch entweder durch das Hinzufügen einer
 <code>Severity</code>-Zeile im Pseudo-Header beim Verfassen des
 Fehlerberichts (siehe <a href="Reporting#pseudoheader">Anweisungen für
 Fehlerberichte</a>) oder durch das Benutzen des <code>severity</code>
-Kommandos mit dem <a href="#requestserv">control request server</a>
+Kommandos mit dem <a href="#requestserv">Control Request Server</a>
 geändert werden kann.</p>
 
 
@@ -185,9 +185,9 @@ Einfluss auf die Veröffentlichung des Paketes mit dem stabilen Release von
 Debian hat. Im Augenblick sind das <strong>critical</strong>,
 <strong>grave</strong> und <strong>serious</strong>. Die vollständigen
 und kanonischen Regeln, welche Probleme diese Schweregrade
-rechtfertigen, sehen Sie in der Liste der
-<a href="http://release.debian.org/lenny/rc_policy.txt">veröffentlichungskritischen
-Probleme für Lenny</a>.</p>
+rechtfertigen, finden Sie in der Liste der
+<a href="http://release.debian.org/squeeze/rc_policy.txt">veröffentlichungskritischen
+Probleme für die stabile Veröffentlichung</a>.</p>
 
 
 <h2><a name="tags">Markierungen für Fehlerberichte</a></h2>
@@ -202,7 +202,7 @@ Probleme für Lenny</a>.</p>
 Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts
 (siehe <a href="Reporting#pseudoheader">Anweisungen für Fehlerberichte</a>),
 oder durch das Benutzen des <code>tags</code>-Kommandos mit dem
-<a href="#requestserv">control request server</a> gesetzt werden.
+<a href="#requestserv">Control Request Server</a> gesetzt werden.
 Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides 
 trennen.</p>
 
@@ -216,25 +216,26 @@ trennen.</p>
   verursacht, dann sollte diese Markierung nicht verwendet werden.</dd>
 
 <dt><code>wontfix</code></dt>
-  <dd>Dieser Fehler wird nicht behoben. Möglicherweise weil es eine Wahl
-  zwischen zwei beliebigen Arten Dinge zu erledigen gibt und der
-  Paketbetreuer und der Absender des Fehlerberichts es vorziehen, Dinge
-  auf ihre eigene Weise zu regeln, möglicherweise auch, weil die Änderung
+  <dd>Dieser Fehler wird nicht behoben. Möglicherweise weil hier eine Wahl
+  getroffen wurde zwischen zwei beliebigen Wegen, um bestimmte Dinge zu 
+  erledigen und dabei stimmen der Paketbetreuer und der Absender des 
+  Fehlerberichts in ihrer Meinung, wie diese Dinge erledigt werden sollten, 
+  nicht überein, möglicherweise auch, weil die Änderung
   des Verhaltens andere, schlimmere Probleme nach sich ziehen würde
-  oder aber auch wegen anderen Problemen.</dd>
+  oder aber auch aus anderen Gründen.</dd>
 
 <dt><code>moreinfo</code></dt>
   <dd>Dieser Fehler kann nicht bearbeitet werden, bevor der Absender des
   Fehlerberichts mehr Informationen zur Verfügung stellt. Der Fehler
   wird für geschlossen erklärt, falls der Absender keine weiteren
   Informationen innerhalb eines angemessenen Zeitraumes (ein paar
-  Monate) liefert. Das ist für Fehler der Art <q>Das geht nicht</q>. Was geht
+  Monate) liefert. Das ist für Fehler der Art: <q>Das geht nicht</q>. Was geht
   nicht?</dd>
 
 <dt><code>unreproducible</code></dt>
   <dd>Dieser Fehler kann nicht auf dem System des Paketbetreuers
   reproduziert werden. In diesem Fall wird die Hilfe einer Drittpartei
-  in der Diagnose der Ursachen des Problems benötigt.</dd>
+  bei der Diagnose der Ursachen des Problems benötigt.</dd>
 
 <dt><code>help</code></dt>
   <dd>Der Paketbetreuer ersucht um Hilfe beim Beheben des Fehlers.</dd>
@@ -253,10 +254,10 @@ trennen.</p>
   <dd>Dieser Fehler beschreibt ein Sicherheitsproblem in einem Paket
   (z.B. falsch gesetzte Rechte, die Zugriff auf Daten erlauben, auf die
   nicht zugegriffen werden sollte; Pufferüberlauf, der es den Leuten
-  erlaubt, das System so zu kontrollieren wie sie es eigentlich nicht
+  erlaubt, das System so zu kontrollieren, wie sie es eigentlich nicht
   dürften; Diensteverweigerungs-Angriffe, die behoben werden sollten, usw.).
   Die meisten sicherheitsrelevanten Fehler sollten außerdem auch auf
-  die <q>critical</q>- oder <q>grave</q>-Schwere gesetzt
+  den Schweregrad <q>critical</q> oder <q>grave</q> gesetzt
   werden.</dd>
 
 <dt><code>upstream</code></dt>
@@ -265,10 +266,10 @@ trennen.</p>
 
 <dt><code>confirmed</code></dt>
   <dd>Der Paketbetreuer hat den Fehlerbericht gelesen, verstanden und
-  sieht ihn als korrekt an, hat den Fehler aber noch nicht behoben
+  sieht ihn als korrekt an, hat den Fehler aber noch nicht behoben.
   (Die Benutzung dieser Markierung ist optional; sie ist hauptsächlich für
   Betreuer gedacht, die eine große Anzahl offener Fehler verwalten
-  müssen.).</dd>
+  müssen.)</dd>
 
 <dt><code>fixed-upstream</code></dt>
   <dd>Der Fehler wurde vom Upstream-Betreuer behoben, ist aber noch nicht im
@@ -282,7 +283,7 @@ trennen.</p>
   Unstable-Distribution.</dd>
 
 <dt><code>d-i</code></dt>
-  <dd>Dieser Fehler ist für die Entwicklung des debian-installer
+  <dd>Dieser Fehler ist für die Entwicklung des debian-installers
   relevant. Diese Markierung sollte verwendet werden, wenn der Fehler die
   Entwicklung des Debian-Installers beeinflusst, das Paket, das davon
   betroffen ist, aber kein direkter Teil des Installers selbst ist.</dd>
@@ -363,6 +364,20 @@ trennen.</p>
   nur vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst 
   ohne ausdrückliche Berechtigung von diesen.</strong></dd>
 
+<dt><code>wheezy</code></dt>
+  <dd>Dies ist eine Veröffentlichungs-Markierung, die zwei Effekte hat. Wenn sie
+      für einen Fehler gesetzt wird, kann dieser Fehler nur Wheezy betreffen 
+      (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, 
+      wenn deren Markierungen gesetzt sind), aber ansonsten gelten die normalen
+      fehlerhaft/behoben/nicht-zutreffend-Regeln. Auch sollte dieser Fehler
+      nicht archiviert werden, bis er in Wheezy behoben ist.</dd>
+
+<dt><code>wheezy-ignore</code></dt>
+  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
+  Veröffentlichung von Wheezy ignoriert werden. <strong>Diese Markierung sollte
+  nur vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst 
+  ohne ausdrückliche Berechtigung von diesen.</strong></dd>
+
 <dt><code>sid</code></dt>
   <dd>Dies ist eine Veröffentlichungs-Markierung, die zwei Effekte hat. Wenn sie
       für einen Fehler gesetzt wird, kann dieser Fehler nur Sid betreffen 
@@ -421,7 +436,7 @@ Person, die den Fehler gemeldet hat,
 <var>nnn</var><code>@bugs.debian.org</code> in das
 <code>CC</code>-Feld ein.</p>
 
-<p>Bitten Sie den Autor das <code>CC</code> an
+<p>Bitten Sie den Autor, das <code>CC</code> an
 <var>nnn</var><code>-forwarded@bugs.debian.org</code> beim Antworten stehen zu
 lassen, so dass die Fehlerdatenbank die Antwort des Autors mit dem
 Originalfehlerbericht zusammen protokollieren kann. Diese Nachrichten werden
@@ -431,13 +446,13 @@ schicken Sie sie auch an <var>nnn</var><code>@bugs.debian.org</code>.</p>
 <p>Wenn die Fehlerdatenbank eine Nachricht an
 <var>nnn</var><code>-forwarded</code> erhält, dann wird der
 relevante Fehler als weitergeleitet markiert, die Weiterleitungsadresse
-ist dann die Adresse aus dem <code>To</code>-Feld der Originalnachricht
+ist dann die Adresse aus dem <code>To</code>-Feld der Originalnachricht,
 die die Datenbank bekommt, falls der Fehler nicht bereits als weitergeleitet
 markiert ist.</p>
 
 <p>Sie können auch die <q>forwarded to</q>-Information manipulieren, indem
 Sie eine Nachricht an <a href="server-control">\
-<code>control@bugs.debian.org</code></a> abschicken.</p>
+<code>control@bugs.debian.org</code></a> schicken.</p>
 
 
 <h2><a name="owner">Besitzer eines Fehlers ändern</a></h2>
@@ -453,7 +468,7 @@ zu helfen, kann jeder Fehler wahlweise einen Besitzer haben.</p>
 (siehe die <a href="Reporting#pseudoheader">Anweisungen, wie Fehler
 berichtet werden</a>) oder durch die Verwendung der Befehle
 <code>owner</code> und <code>noowner</code> im Zusammenhang mit dem
-<a href="#requestserv">control request server</a>.</p>
+<a href="#requestserv">Control Request Server</a>.</p>
 
 
 <h2><a name="maintincorrect">Falsch angezeigte Paketbetreuer</a></h2>
@@ -462,10 +477,10 @@ berichtet werden</a>) oder durch die Verwendung der Befehle
 daran, dass sich der Paketbetreuer vor kurzem geändert hat und der neue
 Betreuer es versäumt hat, eine neue Version des Pakets mit einem
 abgeänderten <code>Maintainer</code>-Feld in der Kontrolldatei
-hochzuladen. Das wird behoben sobald das Paket hochgeladen wird;
+hochzuladen. Das wird behoben, sobald das Paket hochgeladen wird;
 als Alternative können die Archivbetreuer den Betreuereintrag per Hand
 ändern, zum Beispiel wenn ein neues Build oder ein erneutes Hochladen
-des Paket nicht in nächster Zukunft zu erwarten ist. Setzen Sie sich
+des Pakets in nächster Zukunft nicht zu erwarten ist. Setzen Sie sich
 mit <code>override-change@debian.org</code> in Verbindung, um
 Änderungen an der override-Datei zu veranlassen.</p>
 
@@ -486,15 +501,15 @@ festzuhalten. Das können Sie machen, indem Sie eine Nachricht an
 <p>Das <a href="server-control">Format dieser Nachrichten</a> ist in einem
 anderen Dokument, das entweder im WWW oder in der Datei
 <code>bug-maint-mailcontrol.txt</code> verfügbar ist, beschrieben. Eine
-Volltextversion kann auch durch das Senden des Wortes
-<code>help</code> an den oben genannten Server erhalten werden.</p>
+Volltextversion können Sie auch durch das Senden des Wortes
+<code>help</code> an den oben genannten Server erhalten.</p>
 
 <h2><a name="subscribe">Fehler abonnieren</a></h2>
 
 <p>Die Fehlerdatenbank erlaubt den Fehler-Berichtern, Entwicklern und anderen
-   interessierten dritten Parteien individuelle Fehler zu abonnieren. Diese
-   Fähigkeit kann von denen verwendet werden, die ein Auge auf einem Fehler
-   haben wollen ohne das gesamte Paket über das
+   interessierten dritten Parteien, individuelle Fehler zu abonnieren. Diese
+   Fähigkeit kann von denen verwendet werden, die ein Auge auf einen Fehler
+   halten wollen, ohne das gesamte Paket über das
    <a href="http://packages.qa.debian.org">PTS</a> zu abonnieren. Alle
    Nachrichten, die bei <var>nnn</var><code>@bugs.debian.org</code> empfangen werden,
    werden an die Abonnenten geschickt.</p>
@@ -503,14 +518,14 @@ Volltextversion kann auch durch das Senden des Wortes
    <var>nnn</var><code>-subscribe@bugs.debian.org</code> abonniert werden. Der
    Betreff und der Textkörper der E-Mail werden vom BTS ignoriert. Sobald diese
    Nachricht verarbeitet wurde, werden den Benutzern eine Bestätigung-E-Mail
-   zugestellt, auf die sie antworten müssen bevor ihnen die Nachrichten, die 
+   zugestellt, auf die sie antworten müssen, bevor ihnen die Nachrichten, die 
    den Fehler betreffen, zugeschickt werden.</p>
 
 <p>Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über
    eine E-Mail an <var>nnn</var><code>-unsubscribe@bugs.debian.org</code> 
    erfolgen. Der Betreff und der Textkörper der E-Mail werden wieder vom BTS
    ignoriert. Den Benutzern wird eine Bestätigungsnachricht übersandt, die sie
-   beantworten müssen, falls sie das Abonnement des Fehlers beenden wollen.</p>
+   beantworten müssen, falls Sie das Abonnement des Fehlers beenden wollen.</p>
 
 <p>Standardmäßig wird die Adresse abonniert, die in der <code>From</code>-\
    Kopfzeile gefunden wird. Falls Sie für eine andere Adresse den Fehler
@@ -537,7 +552,7 @@ anfängt, werden so behandelt, als wären sie an
 Abwärtskompatibilität zu den Nachrichten, die von alten Adressen
 weitergeleitet wurden, zu erhalten, sowie dazu, Nachrichten abzufangen,
 die irrtümlich an <code>submit</code> geschickt wurden (z.B. durch das
-Benutzen der <q>an alle Empfänger antworten</q>-Funktion des jeweiligen
+Benutzen der <q>Allen antworten</q>-Funktion des jeweiligen
 E-Mailprogramms).</p>
 
 <p>Ein ähnliches Schema gilt auch für <code>maintonly</code>,