Author: mbarkhau
Date: Thu Feb 28 09:48:53 2008
New Revision: 1419
Log:
Finished editing ch03
Modified:
trunk/de/ch03.xml
Modified: trunk/de/ch03.xml
==============================================================================
--- trunk/de/ch03.xml (original)
+++ trunk/de/ch03.xml Thu Feb 28 09:48:53 2008
@@ -2686,12 +2686,7 @@
<para>Ein nicht zwangsläufig auf Seiten die Hosting-Bündel benutzen
beschränktes Problem, dort aber am häufigsten anzutreffen, ist der
-<sect3 id="anonymity">
-<title>Anonymität und Beteiligung</title>
-
-<para>Ein nicht zwangsläufig auf Seiten die Hosting-Bündel benutzen
-beschränktes Problem, dort aber am häufigsten anzutreffen, ist der
-Missbrauch der Login Funktion. Die Funktion selber ist relativ Einfach:
+Missbrauch der Login Funktion. Die Funktion selbst ist relativ Einfach:
Die Seite erlabt jedem Benutzer sich mit Name und Passwort zu
registrieren. Von da an speichert es ein Profil für diesen Nutzer und
die Administratoren der Projekte können dem Nutzer bestimmte Rechte
@@ -2700,25 +2695,25 @@
<para>Das kann äußerst nützlich sein und es ist tatsächlich eines der
wesentlichen Argument für gebündeltes Hosting. Das Problem ist, dass
Nutzer sich manchmal für Aufgaben anmelden müssen, die eigentlich auch
-für nicht registrierte Nutzer erlaubt sein sollte, insbesondere um
-Tickets im Bug-Tracker aufzumachen. Indem man eine Anmeldung für solche
-Aufgaben voraussetzt, hebt das Projekt die Grenze für die Teilnahme für
-Aufgaben an, die schnell und bequem sein sollten. Natürlich möchte man
-jemand erreichen können, der Daten in den Bug-Tracker eingeträgt, es
-reicht aber ein Feld zu haben, indem sie ihre E-Mail Adresse eingeben
-kann (wenn sie es möchte). Wenn ein neuer Nutzer einen Bug findet und
-ihn melden möchte, wird er durch die Anforderung verärgert sein, ein
+ohne möglich sein sollten, insbesondere um Tickets im Bug-Tracker
+zu erstellen. Indem man eine Anmeldung für solche Aufgaben voraussetzt,
+hebt das Projekt die Grenze für die Teilnahme für Aufgaben an, die
+möglichst schnell und einfach sein sollten. Natürlich möchte man
+jemand erreichen können, der Daten in den Bug-Tracker eingetragen hat,
+dazu reicht aber ein Feld, indem sie ihre E-Mail Adresse eingeben kann
+(wenn sie es möchte). Wenn ein neuer Nutzer einen Bug findet und ihn
+melden möchte, wird er durch die Anforderung verärgert sein, ein
Konto erstellen zu müssen, nur um einen Eintrag in den Tracker zu
machen. Er wird sich vielleicht einfach entscheiden den Bug garnicht zu
melden.</para>
<para>Die Vorteile einer Nutzerverwaltung wiegen im Allgemeinen
-schwerer als die Nachteile. Wenn Sie es sich aber aussuchen können,
-welche Aufgaben anonym gemacht werden können, sollten Sie nicht nur
-<emphasis>alle</emphasis> Abläufe ohne schreibzugriff für nicht
-angemeldete Besucher erlauben, sonder auch manche Abläufe um Daten
-einzugeben, insbesondere im Bug-Tracker sowie, falls vorhanden, auf den
-Seiten der Wiki.</para>
+schwerer als die Nachteile. Wenn Sie es sich aussuchen können, welche
+Aufgaben anonym gemacht werden können, sollten Sie aber nicht nur
+<emphasis>alle</emphasis> Abläufe die keinen Schreibzugriff erfordern,
+für nicht angemeldete Besucher erlauben, sonder auch manche Abläufe um
+Daten einzugeben, insbesondere im Bug-Tracker sowie, falls vorhanden,
+auf den Seiten der Wiki.</para>
</sect3>
@@ -2729,14 +2724,4 @@
<!-- ======================== SECTION ============================== -->
-
</chapter>
-
-<!--
-vim: tw=72 ft=docbook
-
-local variables:
-sgml-parent-document: ("book.xml" "chapter")
-end:
--->
-
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
