Convert from ISO-8859-1 to UTF-8

CVS version numbers

german/contact.wml: 1.46 -> 1.47 
german/donations.wml: 1.38 -> 1.39 
german/index.wml: 1.58 -> 1.59 
german/license.wml: 1.25 -> 1.26 
german/opl.wml: 1.5 -> 1.6 
german/social_contract.1.0.wml: 1.7 -> 1.8 
german/social_contract.wml: 1.36 -> 1.37 
german/support.wml: 1.60 -> 1.61 
german/trademark.wml: 1.3 -> 1.4 
german/Bugs/Access.wml: 1.14 -> 1.15 
german/Bugs/Developer.wml: 1.81 -> 1.82 
german/Bugs/Reporting.wml: 1.69 -> 1.70 
german/Bugs/index.wml: 1.47 -> 1.48 
german/Bugs/otherpages.inc: 1.4 -> 1.5 
german/Bugs/pseudo-packages.translated-description: 1.8 -> 1.9 
german/Bugs/pseudo-packages.wml: 1.8 -> 1.9 
german/Bugs/server-control.wml: 1.67 -> 1.68 
german/Bugs/server-refcard.wml: 1.25 -> 1.26 
german/Bugs/server-request.wml: 1.20 -> 1.21 
german/CD/free-linux-cd.wml: 1.2 -> 1.3 
german/CD/index.wml: 1.31 -> 1.32 
german/CD/misc.wml: 1.4 -> 1.5 
german/CD/artwork/index.wml: 1.31 -> 1.32 
german/CD/faq/index.wml: 1.92 -> 1.93 
german/CD/http-ftp/index.wml: 1.42 -> 1.43 
german/CD/jigdo-cd/index.wml: 1.77 -> 1.78

1 files changed, 172 insertions, 172 deletions

diff --git a/german/Bugs/Developer.wml b/german/Bugs/Developer.wml
index 03d3ef14078..ce515877733 100644
--- a/german/Bugs/Developer.wml
+++ b/german/Bugs/Developer.wml
@@ -3,34 +3,34 @@
 # $Id$
 # Translator: Igor Stroh <jenner@wohnheim.uni-ulm.de>
 
-<h1>Informationen für Entwickler, die das Fehlerverwaltungssystem betreffen</h1>
+<h1>Informationen für Entwickler, die das Fehlerverwaltungssystem betreffen</h1>
 
-<p>Zunächst wird ein Fehlerbericht von einem Benutzer als eine
+<p>Zunächst wird ein Fehlerbericht von einem Benutzer als eine
 normale E-Mail-Nachricht an <code>submit@bugs.debian.org</code>
 verschickt. Diese E-Mail bekommt dann eine Nummer, der Benutzer
-erhält eine Empfangsbestätigung und die Nachricht wird an
+erhält eine Empfangsbestätigung und die Nachricht wird an
 <code>debian-bugs-dist</code> weitergeleitet. Wenn der Absender
-zusätzlich eine <code>Paket</code>-Zeile einfügt, die
-den Paketnamen und den Namen des Paketbetreuers enthält,
-dann erhält auch der Betreuer eine Kopie des Fehlerberichts.</p>
+zusätzlich eine <code>Paket</code>-Zeile einfügt, die
+den Paketnamen und den Namen des Paketbetreuers enthält,
+dann erhält auch der Betreuer eine Kopie des Fehlerberichts.</p>
 
 <p>Zu der <code>Subject</code>-Zeile wird noch <code>Bug#</code>
-<var>nnn</var><code>:</code> hinzugefügt und das <code>Reply-To</code>
-wird so geändert, dass es beide, den Absender des Fehlerberichts und
-<var>nnn</var><code>@bugs.debian.org</code>, enthält.</p>
+<var>nnn</var><code>:</code> hinzugefügt und das <code>Reply-To</code>
+wird so geändert, dass es beide, den Absender des Fehlerberichts und
+<var>nnn</var><code>@bugs.debian.org</code>, enthält.</p>
 
 <hrline />
 
 <ul>
-  <li><a href="#closing">Fehlerberichte schließen</a></li>
+  <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="#tags">Markierungen für Fehlerberichte</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>
-  <li><a href="#owner">Besitzer eines Fehlers ändern</a></li>
+  <li><a href="#owner">Besitzer eines Fehlers ändern</a></li>
   <li><a href="#maintincorrect">Falsch angezeigte Paketbetreuer</a></li>
-  <li><a href="#requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
+  <li><a href="#requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
     Fehlerberichten</a></li>
   <li><a href="#subscribe">Fehler abonnieren</a></li>
   <li><a href="#subjectscan">Das mehr oder weniger veraltete
@@ -41,40 +41,40 @@ wird so geändert, dass es beide, den Absender des Fehlerberichts und
 <hrline />
 
 
-<h2><a name="closing">Fehlerberichte schließen</a></h2>
+<h2><a name="closing">Fehlerberichte schließen</a></h2>
 
 <p>Fehlerberichte von Debian sollten geschlossen werden, wenn das Problem
-behoben ist. Probleme in Paketen können nur für behoben erachtet werden, wenn
-das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.</p>
+behoben ist. Probleme in Paketen können nur für behoben erachtet werden, wenn
+das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.</p>
 
-<p>Üblicherweise sind die einzigen Personen, die einen Fehlerbericht
-schließen sollten, der Einreicher des Fehlerberichts und der/die Betreuer des
+<p>Ãœblicherweise sind die einzigen Personen, die einen Fehlerbericht
+schließen sollten, der Einreicher des Fehlerberichts und der/die Betreuer des
 Paketes, gegen das der Fehler berichtet wurde. Es gibt Ausnahmen von dieser
 Regel, zum Beispiel, wenn der Fehler gegen unbekannte Pakete oder gewisse
-generelle Pseudo-Pakete berichtet wurde. Falls Sie Zweifel haben, schließen
+generelle Pseudo-Pakete berichtet wurde. Falls Sie Zweifel haben, schließen
 Sie den Fehler nicht, sondern fragen Sie zuerst auf der Mailingliste
 debian-devel um Rat.</p>
 
 <p>Fehlerberichte sollten geschlossen werden, indem man eine E-Mail an
 <var>nnn</var><code>-done@bugs.debian.org</code> schickt. Der Inhalt der E-Mail
-muss die Erklärung enthalten, wie der Fehler behoben wurde.</p>
+muss die Erklärung enthalten, wie der Fehler behoben wurde.</p>
 
-<p>Alles, was Sie zum Schließen des Berichts tun müssen, ist eine Antwort auf
+<p>Alles, was Sie zum Schließen des Berichts tun müssen, ist eine Antwort auf
 die E-Mail zu schreiben, die Sie von der Fehlerdatenbank erhalten haben, und
 das <code>To</code>-Feld auf
-<var>nnn</var><code>-done@bugs.debian.org</code> zu ändern
+<var>nnn</var><code>-done@bugs.debian.org</code> zu ändern
 (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
-Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher 
-Veröffentlichung des Paketes die Korrektur enthalten ist.
+Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher 
+Veröffentlichung des Paketes die Korrektur enthalten ist.
 </p>
 
-<p>Die Person, die den Fehler schließt, die Person, die den Fehlerbericht
+<p>Die Person, die den Fehler schließt, die Person, die den Fehlerbericht
 verfasst hat und die <code>debian-bugs-closed</code> Mailingliste bekommen
-alle eine Hinweis-E-Mail über die Änderungen im Status des Berichts. Der
+alle eine Hinweis-E-Mail über die Änderungen im Status des Berichts. Der
 Einsender und die Mailingliste erhalten ebenfalls den Inhalt der Nachricht,
 die an <var>nnn</var><code>-done</code> geschickt wurde.</p>
 
@@ -86,13 +86,13 @@ die an <var>nnn</var><code>-done</code> geschickt wurde.</p>
 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, sollten Sie
 einfach auf die Nachricht antworten und die <code>Reply-To</code>-Kopfzeile
 respektieren. Das wird den Fehlerbericht <strong>nicht</strong>
-schließen.</p>
+schließen.</p>
 
 <p>Die Fehlerdatenbank
-bekommt den Bericht über <var>nnn</var><code>@bugs.debian.org</code>, stellt ihn
+bekommt den Bericht über <var>nnn</var><code>@bugs.debian.org</code>, stellt ihn
 dem Paketbetreuer zu, speichert die Antwort sowie den Rest des
 Fehlerprotokolls und leitet sie an <code>debian-bugs-dist</code>
 weiter.</p>
@@ -105,8 +105,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 in
+<code>debian-bugs-dist</code> passt, dann können Sie es 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
@@ -117,99 +117,99 @@ 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>an alle Empfänger
 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.
+denn, Sie möchten die Liste der Empfänger grundsätzlich selbst überarbeiten.
 Achten Sie insbesondere darauf, dass Sie keine Followup-Nachrichten an
 <code>submit@bugs.debian.org</code> verschicken.</p>
 
 
-<p>Hinsichtlich weiterer Informationen über Kopfzeilen, mittels denen
-ACK-Benachrichtigungen unterdrückt werden können, und darüber, wie mit
-Hilfe des Fehlerverwaltungssystems Kopien verschickt werden können, schauen
+<p>Hinsichtlich weiterer Informationen über Kopfzeilen, mittels denen
+ACK-Benachrichtigungen unterdrückt werden können, und darüber, wie mit
+Hilfe des Fehlerverwaltungssystems Kopien verschickt werden können, schauen
 Sie in die
 <a href="Reporting">Anleitung zum Fehlereinreichen</a>.</p>
 
 
 <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>
-gesetzt, was jedoch entweder durch das Hinzufügen einer
+<p>Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen
+Schweregrad. Diese 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
+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>
-geändert werden kann.</p>
+geändert werden kann.</p>
 
 
 <p>Die Schweregrade:</p>
 
 <dl>
 <dt><code>critical</code></dt>
-<dd>Beschädigt Software im System, die in keinem Bezug zum fehlerhaften
+<dd>Beschädigt Software im System, die in keinem Bezug zum fehlerhaften
 Paket steht, (oder sogar das ganze System) oder verursacht einen
-ernsthaften Datenverlust oder öffnet eine neue Sicherheitslücke auf dem
+ernsthaften Datenverlust oder öffnet eine neue Sicherheitslücke auf dem
 System, auf dem Sie das Paket installieren.</dd>
 
 <dt><code>grave</code></dt>
 <dd>Macht das betreffende Paket (fast) unbrauchbar oder verursacht
-einen Datenverlust oder öffnet eine Sicherheitslücke, die es erlaubt, auf
+einen Datenverlust oder öffnet eine Sicherheitslücke, die es erlaubt, auf
 die Benutzerkonten derjenigen Benutzer zuzugreifen, die das Paket
 verwenden.</dd>
 
 <dt><code>serious</code></dt>
 <dd>Ist eine <a href="$(DOC)/debian-policy/">\
-ernsthafte Verletzung der Debian Policy</a> (bedeutet ungefähr, dass
+ernsthafte Verletzung der Debian Policy</a> (bedeutet ungefähr, dass
 es eine <q>muss</q>- oder <q>erfordert</q>-Klausel verletzt) oder macht das Paket
-nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung.</dd>
+nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung.</dd>
 
 <dt><code>important</code></dt>
 <dd>Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des
-Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.</dd>
+Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.</dd>
 
 <dt><code>normal</code></dt>
 <dd>Standardwert, anwendbar auf die meisten Fehler.</dd>
 
 <dt><code>minor</code></dt>
-<dd>Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das
+<dd>Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das
 vermutlich sehr leicht zu beheben ist.</dd>
 
 <dt><code>wishlist</code></dt>
-<dd>Für beliebige Feature-Requests, aber auch für beliebige Fehler, die
-aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben
+<dd>Für beliebige Feature-Requests, aber auch für beliebige Fehler, die
+aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben
 sind.</dd>
 </dl>
 
 <p>Bestimmte Schweregrade werden als
 <em><a href="http://bugs.debian.org/release-critical/">\
-veröffentlichungskritisch</a></em> erachtet, was bedeutet, dass der Fehler einen
-Einfluss auf die Veröffentlichung des Paketes mit dem stabilen Release von
+veröffentlichungskritisch</a></em> erachtet, was bedeutet, dass der Fehler einen
+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
+<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>
+<a href="http://release.debian.org/lenny/rc_policy.txt">veröffentlichungskritischen
+Probleme für Lenny</a>.</p>
 
 
-<h2><a name="tags">Markierungen für Fehlerberichte</a></h2>
+<h2><a name="tags">Markierungen für Fehlerberichte</a></h2>
 
 <p>Jeder Fehler kann eine oder mehrere Markierungen (engl. Tags) aus einer
    gegebenen Menge haben. Diese Markierungen werden in der Liste der Fehler
-   angezeigt, wenn Sie auf der Paket-Seite oder im vollständigen 
+   angezeigt, wenn Sie auf der Paket-Seite oder im vollständigen 
    Fehlerprotokoll nachschauen.</p>
 
-<p>Die Markierungen können durch das Einfügen einer <code>Tags</code>-Zeile in
+<p>Die Markierungen können durch das Einfügen einer <code>Tags</code>-Zeile in
    den
 Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts
-(siehe <a href="Reporting#pseudoheader">Anweisungen für Fehlerberichte</a>),
+(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.
-Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides 
+Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides 
 trennen.</p>
 
-<p>Die zurzeit verfügbaren Fehler-Markierungen:</p>
+<p>Die zurzeit verfügbaren Fehler-Markierungen:</p>
 
 <dl>
 <dt><code>patch</code></dt>
@@ -219,31 +219,31 @@ 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
+  <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
-  des Verhaltens andere, schlimmere Probleme nach sich ziehen würde
+  auf ihre eigene Weise zu regeln, möglicherweise auch, weil die Änderung
+  des Verhaltens andere, schlimmere Probleme nach sich ziehen würde
   oder aber auch wegen anderen Problemen.</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
+  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>
+  in 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>
 
 <dt><code>pending</code></dt>
-  <dd>Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket
+  <dd>Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket
   wird bald hochgeladen.</dd>
 
 <dt><code>fixed</code></dt>
@@ -255,29 +255,29 @@ trennen.</p>
 <dt><code>security</code></dt>
   <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
+  nicht zugegriffen werden sollte; Pufferüberlauf, der es den Leuten
   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
+  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
   werden.</dd>
 
 <dt><code>upstream</code></dt>
-  <dd>Dieser Fehler bezieht sich auf den Code-Teil des ursprünglichen
+  <dd>Dieser Fehler bezieht sich auf den Code-Teil des ursprünglichen
   Autors.</dd>
 
 <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
-  (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>
+  (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>
 
 <dt><code>fixed-upstream</code></dt>
   <dd>Der Fehler wurde vom Upstream-Betreuer behoben, ist aber noch nicht im
-  Paket enthalten (aus welchem Grund auch immer: möglicherweise ist es zu
-  kompliziert, die Änderungen zurückzuportieren, oder der Fehler ist zu
-  gering, um sich darüber den Kopf zu zerbrechen).</dd>
+  Paket enthalten (aus welchem Grund auch immer: möglicherweise ist es zu
+  kompliziert, die Änderungen zurückzuportieren, oder der Fehler ist zu
+  gering, um sich darüber den Kopf zu zerbrechen).</dd>
 
 <dt><code>fixed-in-experimental</code></dt>
   <dd>Der Fehler wurde in dem Paket behoben, das in der
@@ -285,110 +285,110 @@ 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-installer
   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>
 
 <dt><code>ipv6</code></dt>
-  <dd>Dieser Fehler beeinträchtigt die Unterstützung für das
+  <dd>Dieser Fehler beeinträchtigt die Unterstützung für das
   Internet-Protokoll Version 6.</dd>
 
 <dt><code>lfs</code></dt>
-  <dd>Dieser Fehler beeinträchtigt die Unterstützung großer Dateien
-  (über 2 Gigabyte).</dd>
+  <dd>Dieser Fehler beeinträchtigt die Unterstützung großer Dateien
+  (über 2 Gigabyte).</dd>
 
 <dt><code>l10n</code></dt>
-  <dd>Dieser Fehler ist für die Lokalisierung des Pakets relevant.</dd>
+  <dd>Dieser Fehler ist für die Lokalisierung des Pakets relevant.</dd>
 
 <dt><code>potato</code></dt>
-  <dd>Dieser Fehler gilt insbesondere für die Potato-Veröffentlichung des
+  <dd>Dieser Fehler gilt insbesondere für die Potato-Veröffentlichung des
   Debian-Systems.</dd>
 
 <dt><code>woody</code></dt>
-  <dd>Dieser Fehler gilt insbesondere für die
+  <dd>Dieser Fehler gilt insbesondere für die
   Woody-Distribution.</dd>
 
 <dt><code>sarge</code></dt>
-  <dd>Dies ist eine Distributions-Markierung, die zwei Effekte hat. Wenn sie für
+  <dd>Dies ist eine Distributions-Markierung, die zwei Effekte hat. Wenn sie für
       einen Fehler gesetzt wird, kann dieser Fehler nur Sarge betreffen (obwohl
-      es möglich ist, dass er auch andere Distributionen betrifft, wenn deren
+      es möglich ist, dass er auch andere Distributionen 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 Sarge behoben ist.</dd>
 
 <dt><code>sarge-ignore</code></dt>
-  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
-  Veröffentlichung von Sarge ignoriert werden. <strong>Diese Markierung sollte
+  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
+  Veröffentlichung von Sarge 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>
+  vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst ohne
+  ausdrückliche Berechtigung von diesen.</strong></dd>
 
 <dt><code>etch</code></dt>
-  <dd>Dies ist eine Distributions-Markierung, die zwei Effekte hat. Wenn sie für
+  <dd>Dies ist eine Distributions-Markierung, die zwei Effekte hat. Wenn sie für
       einen Fehler gesetzt wird, kann dieser Fehler nur Etch betreffen (obwohl
-      es möglich ist, dass er auch andere Distributionen betrifft, wenn deren
+      es möglich ist, dass er auch andere Distributionen 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 Etch behoben ist.</dd>
 
 <dt><code>etch-ignore</code>
-  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
-  Veröffentlichung von Etch 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>
+  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
+  Veröffentlichung von Etch 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>lenny</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 Lenny betreffen 
-      (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, 
+  <dd>Dies ist eine Veröffentlichungs-Markierung, die zwei Effekte hat. Wenn sie
+      für einen Fehler gesetzt wird, kann dieser Fehler nur Lenny 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 Lenny behoben ist.</dd>
 
 <dt><code>lenny-ignore</code></dt>
-  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
-  Veröffentlichung von Lenny 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>
+  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
+  Veröffentlichung von Lenny 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>squeeze</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 Squeeze betreffen 
-      (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, 
+  <dd>Dies ist eine Veröffentlichungs-Markierung, die zwei Effekte hat. Wenn sie
+      für einen Fehler gesetzt wird, kann dieser Fehler nur Squeeze 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 Squeeze behoben ist.</dd>
 
 <dt><code>squeeze-ignore</code></dt>
-  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
-  Veröffentlichung von Squeeze 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>
+  <dd>Dieser veröffentlichungskritische Fehler soll zum Zwecke der
+  Veröffentlichung von Squeeze 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 
-      (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, 
+  <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 
+      (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 Sid behoben ist.</dd>
 
 <dt><code>experimental</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 Experimental 
-      betreffen (obwohl es möglich ist, dass er auch andere Veröffentlichungen 
+  <dd>Dies ist eine Veröffentlichungs-Markierung, die zwei Effekte hat. Wenn sie
+      für einen Fehler gesetzt wird, kann dieser Fehler nur Experimental 
+      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 Experimental behoben ist.</dd>
 
 </dl>
 
-<p>Die Bedeutung der letzten acht Markierungen haben sich kürzlich geändert;
-   die <q>ignore</q>-Markierungen ignorieren Fehler zum Zweck des Übergangs
-   nach Testing. Die Veröffentlichungs-Markierungen, die bisher nur anzeigten,
-   welche Fehler eine bestimmte Veröffentlichung betrafen, zeigen jetzt an,
-   wann ein Fehler archiviert werden kann und den Satz an Veröffentlichungen,
+<p>Die Bedeutung der letzten acht Markierungen haben sich kürzlich geändert;
+   die <q>ignore</q>-Markierungen ignorieren Fehler zum Zweck des Ãœbergangs
+   nach Testing. Die Veröffentlichungs-Markierungen, die bisher nur anzeigten,
+   welche Fehler eine bestimmte Veröffentlichung betrafen, zeigen jetzt an,
+   wann ein Fehler archiviert werden kann und den Satz an Veröffentlichungen,
    in denen der Fehler als gefunden oder behoben betrachtet werden kann.
 </p>
 
@@ -401,7 +401,7 @@ Upstream-Quellpakets, von dem das Debian-Paket abstammt, weiterleitet,
 dann sollte er das in der Fehlerdatenbank wie folgt vermerken:</p>
 
 <p>Stellen Sie sicher, dass das <code>To</code>-Feld Ihrer Nachricht zum
-Autor nur die Adresse(n) des Autors/der Autoren enthält; fügen Sie die
+Autor nur die Adresse(n) des Autors/der Autoren enthält; fügen Sie die
 Person, die den Fehler gemeldet hat,
 <var>nnn</var><code>-forwarded@bugs.debian.org</code> und 
 <var>nnn</var><code>@bugs.debian.org</code> in das
@@ -415,22 +415,22 @@ nur abgelegt und nicht weitergeleitet; um eine Nachricht normal zu senden,
 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
+<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
 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
+<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>
 
 
-<h2><a name="owner">Besitzer eines Fehlers ändern</a></h2>
+<h2><a name="owner">Besitzer eines Fehlers ändern</a></h2>
 
-<p>Wenn die Person, die für die Fehlerbehebung verantwortlich ist,
+<p>Wenn die Person, die für die Fehlerbehebung verantwortlich ist,
 nicht der zugewiesene Betreuer des Pakets ist (zum Beispiel, wenn
-das Paket von einer Gruppe betreut wird), kann es nützlich sein,
+das Paket von einer Gruppe betreut wird), kann es nützlich sein,
 diese Tatsache im Fehlerverwaltungssystem festzuhalten. Um dabei
 zu helfen, kann jeder Fehler wahlweise einen Besitzer haben.</p>
 
@@ -445,33 +445,33 @@ berichtet werden</a>) oder durch die Verwendung der Befehle
 <h2><a name="maintincorrect">Falsch angezeigte Paketbetreuer</a></h2>
 
 <p>Wenn ein Paketbetreuer falsch angezeigt wird, dann liegt es meistens
-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
+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;
-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
+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
 mit <code>override-change@debian.org</code> in Verbindung, um
-Änderungen an der override-Datei zu veranlassen.</p>
+Änderungen an der override-Datei zu veranlassen.</p>
 
 
-<h2><a name="requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
+<h2><a name="requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
   Fehlerberichten</a></h2>
 
-<p>Es ist möglich, Fehlerberichte anderen Paketen zuzuweisen,
-fälschlicherweise für geschlossen erklärte Fehler neu zu eröffnen, die
-Information über das Ziel der Weiterleitung (falls eine existiert) eines
+<p>Es ist möglich, Fehlerberichte anderen Paketen zuzuweisen,
+fälschlicherweise für geschlossen erklärte Fehler neu zu eröffnen, die
+Information über das Ziel der Weiterleitung (falls eine existiert) eines
 Fehlerberichts zu modifizieren, Schweregrade und Titel der
-Berichte zu ändern, den Besitzer eines Fehlers festzulegen,
+Berichte zu ändern, den Besitzer eines Fehlers festzulegen,
 Fehlerberichte zu verschmelzen bzw. wieder auseinander zu ziehen und die
 Versionen des Paketes, in der der Fehler gefunden und in der er behoben wurde, 
-festzuhalten. Das können Sie machen, indem Sie eine Nachricht an
+festzuhalten. Das können Sie machen, indem Sie eine Nachricht an
 <code>control@bugs.debian.org</code> senden.</p>
 
 <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
+<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>
 
@@ -479,38 +479,38 @@ Volltextversion kann auch durch das Senden des Wortes
 
 <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
+   Fähigkeit kann von denen verwendet werden, die ein Auge auf einem Fehler
+   haben 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>
 
 <p>Ein Fehler kann durch Versand einer E-Mail an 
    <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 
+   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 
    den Fehler betreffen, zugeschickt werden.</p>
 
-<p>Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über
+<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>
+   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>
 
-<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
-   abonnieren wollen, müssen Sie die Adresse, auf die der Fehler abonniert 
+<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
+   abonnieren wollen, müssen Sie die Adresse, auf die der Fehler abonniert 
    werden soll, in die Abonnier-Nachricht kodieren. Dies erfolgt in der Form:
    <var>nnn</var><code>-subscribe-</code><var>Lokalteil</var><code>=</code><var>beispiel.com</var><code>@bugs.debian.org</code>.
-   Dieses Beispiel würde <code>Lokalteil@beispiel.com</code> eine 
-   Abonniermeldung für Fehler <var>nnn</var> schicken. Das 
-   <code>@</code>-Zeichen muss durch Änderung in ein <code>=</code>-Zeichen 
-   kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form 
+   Dieses Beispiel würde <code>Lokalteil@beispiel.com</code> eine 
+   Abonniermeldung für Fehler <var>nnn</var> schicken. Das 
+   <code>@</code>-Zeichen muss durch Änderung in ein <code>=</code>-Zeichen 
+   kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form 
    <var>nnn</var><code>-unsubscribe-</code><var>Lokalteil</var><code>=</code><var>beispiel.com</var><code>@bugs.debian.org</code> an.
-   In beiden Fällen werden der Betreff und der Textkörper der E-Mail an die 
+   In beiden Fällen werden der Betreff und der Textkörper der E-Mail an die 
    E-Mail-Adresse, die in der Anforderung einkodiert ist, im Rahmen der
-   Bestätigungsanfrage weitergeleitet.</p>
+   Bestätigungsanfrage weitergeleitet.</p>
 
 
 <h2><a name="subjectscan">Das mehr oder weniger veraltete
@@ -518,36 +518,36 @@ subject-scanning-Feature</a></h2>
 
 <p>Nachrichten, die beim <code>submit</code> oder bei <code>bugs</code>
 ankommen und deren Betreffzeile mit <code>Bug#</code><var>nnn</var>
-anfängt, werden so behandelt, als wären sie an
+anfängt, werden so behandelt, als wären sie an
 <var>nnn</var><code>@bugs.debian.org</code> geschickt worden. Das passiert, um
-Abwärtskompatibilität zu den Nachrichten, die von alten Adressen
+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
+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
 E-Mailprogramms).</p>
 
-<p>Ein ähnliches Schema gilt auch für <code>maintonly</code>,
+<p>Ein ähnliches Schema gilt auch für <code>maintonly</code>,
 <code>done</code>, <code>quiet</code> und
 <code>forwarded</code>, die ankommende E-Mails mit einer Betreff-Markierung so
-behandeln, als wären sie zu der entsprechenden
+behandeln, als wären sie zu der entsprechenden
 <var>nnn-wasauchimmer</var><code>@bugs.debian.org</code>-Adresse geschickt worden.</p>
 
 <p>Nachrichten, die nur mit <code>forwarded</code> und <code>done</code>
-&ndash; das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne
+&ndash; das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne
 Fehlernummer in der Betreffzeile &ndash; verschickt werden, werden unter
 <q>junk</q> einsortiert und
-für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.</p>
+für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.</p>
 
 
 <h2><a name="x-debian-pr">Veraltetes <code>X-Debian-PR: quiet</code>
   Feature</a></h2>
 
-<p>Früher war es möglich, die Fehlerdatenbank davon abzuhalten, die
+<p>Früher war es möglich, die Fehlerdatenbank davon abzuhalten, die
 Nachrichten, die es an die <code>debian-bugs</code> Adresse bekam,
 irgendwohin weiterzuleiten, indem man die Zeile <code>X-Debian-PR:
-quiet</code> in die eigentlichen E-Mail-Kopfzeilen einfügte.</p>
+quiet</code> in die eigentlichen E-Mail-Kopfzeilen einfügte.</p>
 
-<p>Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre
+<p>Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre
 Nachricht an <code>quiet</code> oder <var>nnn</var><code>-quiet</code>
 (oder <code>maintonly</code> bzw. <var>nnn</var><code>-maintonly</code>)
 schicken.</p>