[svnbook] r4308 committed - Corrected semantics by telling German "authentisieren" from "authentif...
svnbook at googlecode.com
svnbook at googlecode.com
Mon Sep 17 00:25:27 CDT 2012
Revision: 4308
Author: jmfelderhoff at gmx.eu
Date: Sun Sep 16 22:25:04 2012
Log: Corrected semantics by telling German "authentisieren"
from "authentifizieren".
http://code.google.com/p/svnbook/source/detail?r=4308
Modified:
/branches/1.5/de/book/ch02-basic-usage.xml
/branches/1.5/de/book/ch03-advanced-topics.xml
/branches/1.5/de/book/ch05-repository-admin.xml
/branches/1.5/de/book/ch06-server-configuration.xml
/branches/1.5/de/book/ch07-customizing-svn.xml
/branches/1.5/de/book/ch09-reference.xml
=======================================
--- /branches/1.5/de/book/ch02-basic-usage.xml Mon Aug 2 11:28:16 2010
+++ /branches/1.5/de/book/ch02-basic-usage.xml Sun Sep 16 22:25:04 2012
@@ -675,7 +675,7 @@
case-by-case basis.</para>
-->
<para>Wenn Sie eine Subversion-Operation ausführen, für die Sie
- sich authentifizieren müssen, speichert Subversion Ihre
+ sich authentisieren müssen, speichert Subversion Ihre
Zugangsdaten standardmäßig auf der Platte. Das geschieht zu
Ihrer Annehmlichkeit, damit Sie bei künftigen Operationen
nicht ständig Ihr Passwort eingeben müssen. Falls Sie wegen
@@ -715,7 +715,7 @@
<!--
<title>Authenticating As a Different User</title>
-->
- <title>Authentifizierung als ein anderer Anwender</title>
+ <title>Authentisierung als ein anderer Anwender</title>
<!--
<para>Since Subversion caches auth credentials by default (both
@@ -738,7 +738,7 @@
eines Webservers. In diesem Fall brauchen Sie nur die
<option>--username</option>-Option auf der Kommandozeile zu
übergeben und Subversion versucht, sich als dieser Benutzer zu
- authentifizieren und wird Sie, wenn nötig, zur Eingabe eines
+ authentisieren und wird Sie, wenn nötig, zur Eingabe eines
Passworts auffordern.</para>
</sect2>
=======================================
--- /branches/1.5/de/book/ch03-advanced-topics.xml Sat Mar 3 11:01:02 2012
+++ /branches/1.5/de/book/ch03-advanced-topics.xml Sun Sep 16 22:25:04 2012
@@ -4642,7 +4642,7 @@
ändern oder zu löschen (oder eins der Elternverzeichnisse der
Datei zu löschen), verlangt das Projektarchiv zweierlei
Informationen: dass der die Übertragung ausführende Client
- sich als der Eigner der Sperrmarke authentifiziert, und dass
+ sich als der Eigner der Sperrmarke authentisiert, und dass
die Sperrmarke im Zuge der Übertragung vorgelegt wird, um zu
beweisen, dass der Client weiß, welche Sperre verwendet
wird.</para>
@@ -4847,7 +4847,7 @@
dafür, dass die Sperre in dieser bestimmten Arbeitskopie
angelegt wurde und nicht irgendwo anders durch irgendeinen
anderen Client. Es reicht nicht, sich als Sperreigner zu
- authentifizieren, um Missgeschicke zu verhindern.</para>
+ authentisieren, um Missgeschicke zu verhindern.</para>
<!--
<para>For example, suppose you lock a file using a computer at
@@ -4867,7 +4867,7 @@
dieser Datei fertiggestellt haben. Es sollte nicht möglich
sein, später am Abend versehentlich Änderungen an derselben
Datei von Ihrem Rechner zu Hause aus zu machen, nur weil Sie
- sich als Sperreigner authentifiziert haben. Mit anderen
+ sich als Sperreigner authentisiert haben. Mit anderen
Worten verhindert die Sperrmarke, dass ein Teil von
Subversion-Software die Arbeit eines anderen Teils
unterminiert. (In unserem Beispiel hätten Sie eine
@@ -4912,7 +4912,7 @@
<para>Harry aber kann seine Änderungen an der Datei übertragen,
nachdem er das Gelb der Banane verbessert hat. Das
- funktioniert, da er sich als der Sperreigner authentifiziert
+ funktioniert, da er sich als der Sperreigner authentisiert
hat, und weil seine Arbeitskopie die korrekte Sperrmarke
beinhaltet:</para>
@@ -5315,10 +5315,10 @@
die Sperre direkt aus dem Projektarchiv zu entfernen, muss sie
<command>svn unlock</command> einen URL übergeben. Ihr erster
Versuch, den URL zu entsperren, schlägt fehl, da sie sich
- nicht als der Sperreigner authentifizieren kann (sie hat ja
+ nicht als der Sperreigner authentisieren kann (sie hat ja
auch nicht die Sperrmarke). Wenn sie jedoch
<option>--force</option> übergibt, werden die
- Authentifizierungs- und Autorisierungsanforderungen ignoriert
+ Authentisierungs- und Autorisierungsanforderungen ignoriert
und die entfernte Freigabe wird erzwungen.</para>
<!--
@@ -7786,7 +7786,7 @@
-->
<para>Wenn der Server-Prozess eine Anfrage eines Clients erhält,
verlangt er häufig, dass der Client sich identifiziert. Er
- sendet eine Authentifizierungsaufforderung an den Client und
+ sendet eine Authentisierungsaufforderung an den Client und
der Client antwortet, indem er
<firstterm>Zugangsdaten</firstterm> zurückschickt. Sobald die
Authentifizierung abgeschlossen ist, antwortet der Server mit
@@ -7801,7 +7801,7 @@
gewisse Operationen eleganter. Wenn ein Server beispielsweise
so konfiguriert ist, dass jedem auf der Welt erlaubt ist, ein
Projektarchiv zu lesen, wird der Server niemals eine
- Authentifizierungsaufforderung ausgeben, wenn ein Client
+ Authentisierungsaufforderung ausgeben, wenn ein Client
<command>svn checkout</command> versucht.</para>
<!--
@@ -7827,7 +7827,7 @@
<literal>svn:author</literal> der neuen Revision zugewiesen
wird (siehe <xref linkend="svn.ref.properties"/>). Falls der
Client nicht authentifiziert wurde (d.h., falls der Server
- niemals eine Authentifizierungsaufforderung ausgegeben hat),
+ niemals eine Authentisierungsaufforderung ausgegeben hat),
bleibt die Revisionseigenschaft <literal>svn:author</literal>
leer.</para>
@@ -7858,7 +7858,7 @@
server's hostname, port, and authentication realm.</para>
-->
<para>Viele Server sind so konfiguriert, dass sie vor jeder
- Anfrage eine Authentifizierung benötigen. Für Benutzer wäre es
+ Anfrage eine Authentisierung benötigen. Für Benutzer wäre es
sehr lästig, wenn sie jedes Mal das Passwort eingeben müssten.
Glücklicherweise hat der Subversion-Client hierfür eine Abhilfe:
ein eingebautes System zum Zwischenspeichern der Zugangsdaten
@@ -7869,7 +7869,7 @@
<filename>%APPDATA%/Subversion/auth/</filename> unter Windows;
siehe <xref linkend="svn.advanced.confarea" /> für Details zum
Laufzeitkonfigurationssystem), wenn er erfolgreich auf die
- Authentifizierungsanfrage des Servers antwortet. Die gültigen
+ Authentisierungsanfrage des Servers antwortet. Die gültigen
Zugangsdaten werden auf Platte zwischengespeichert und mit
einer Kombination aus dem Rechnernamen des Servers, dem Port
und dem Anmeldebereich referenziert.</para>
@@ -7882,12 +7882,12 @@
the client will, by default, fall back to prompting the
user for the necessary information.</para>
-->
- <para>Wenn der Client eine Authentifizierungsaufforderung
+ <para>Wenn der Client eine Authentisierungsaufforderung
empfängt, schaut er zunächst nach den passenden Zugangsdaten
im Cache des Benutzers auf Platte. Falls passend erscheinende
Zugangsdaten nicht verfügbar sind oder die
zwischengespeicherten Zugangsdaten letzlich nicht für eine
- Authentifizierung ausreichen sollten, wird der Client
+ Authentisierung ausreichen sollten, wird der Client
standardmäßig den Benutzer zur Eingabe der notwendigen
Informationen auffordern.</para>
@@ -8162,7 +8162,7 @@
Wurde ein Benutzername und/oder ein Passwort als Optionen
mitgegeben, werden sie dem Server nur auf Verlangen vorgelegt.
Üblicherweise werden diese Optionen verwendet, um sich als ein
- anderer Benutzer zu authentifizieren als derjenige, den
+ anderer Benutzer zu authentisieren als derjenige, den
Subversion standardmäßig gewählt hätte (etwa Ihr Anmeldename),
oder falls Sie die interaktive Abfrage vermeiden möchten (etwa
beim Aufruf von <command>svn</command> aus einem
@@ -8182,7 +8182,7 @@
<note>
<para>Ein verbreiteter Fehler ist die Fehlkonfigurierung eines
Servers, so dass er nie eine Aufforderung zur
- Authentifizierung ausgibt. Falls Benutzer dann die Optionen
+ Authentisierung ausgibt. Falls Benutzer dann die Optionen
<option>--username</option> und <option>--password</option>
an den Client übergeben, wundern sie sich, dass sie nie
verwendet werden, d.h., es sieht so aus, dass neue
@@ -8196,7 +8196,7 @@
-->
<para>An dieser Stelle sei abschließend zusammengefasst, wie
sich ein Subversion-Client bei Erhalt einer Aufforderung zur
- Authentifizierung verhält.</para>
+ Authentisierung verhält.</para>
<orderedlist>
<listitem>
@@ -8213,7 +8213,7 @@
(<option>--username</option> und/oder
<option>--password</option>) angegeben hat. Falls ja,
versucht der Client, diese Zugangsdaten zur
- Authentifizierung gegenüber dem Server zu
+ Authentisierung gegenüber dem Server zu
verwenden.</para>
</listitem>
<listitem>
@@ -8232,7 +8232,7 @@
Laufzeitkonfigurationsbereich <filename>auth/</filename>
nach passenden zwischengespeicherten Zugangsdaten zu
suchen. Falls solche vorhanden sind, probiert er, sich
- hiermit zu authentifizieren.</para>
+ hiermit zu authentisieren.</para>
</listitem>
<listitem>
<!--
@@ -8244,7 +8244,7 @@
client-specific equivalents).</para>
-->
<para>Falls letztendlich alle vorherigen Mechanismen keine
- erfolgreiche Authentifizietrung des Benutzers gegen den
+ erfolgreiche Authentisierung des Benutzers gegen den
Server bewirken, greift der Client auf eine interaktive
Abfrage der Zugangsdaten zurück (sofern ihm das nicht
durch die Option <option>--non-interactive</option> oder
@@ -8259,7 +8259,7 @@
earlier).</para>
-->
<para>Falls sich der Client durch irgendeine dieser Methoden
- erfolgreich authentifiziert, versucht er, die Zugangsdaten auf
+ erfolgreich authentisiert, versucht er, die Zugangsdaten auf
der Platte zwischenzuspeichern (sofern der Benutzer dieses
Verhalten nicht, wie oben beschrieben, unterbunden
hat).</para>
=======================================
--- /branches/1.5/de/book/ch05-repository-admin.xml Mon Aug 2 11:28:16 2010
+++ /branches/1.5/de/book/ch05-repository-admin.xml Sun Sep 16 22:25:04 2012
@@ -5227,7 +5227,7 @@
<para>In Subversion 1.4 wurden die an die
Kommandozeilenoptionen <option>--username</option> und
<option>--password</option> von <command>svnsync</command>
- übergebenen Werte sowohl für die Authentifizierung gegenüber
+ übergebenen Werte sowohl für die Authentisierung gegenüber
dem Quell-Projektarchiv als auch gegenüber dem Ziel-Projektarchiv
verwendet. Das führte zu Problemen, falls die Zugangsdaten
eines Benutzers nicht für beide Projektarchive identisch waren,
=======================================
--- /branches/1.5/de/book/ch06-server-configuration.xml Tue Sep 4 12:38:56
2012
+++ /branches/1.5/de/book/ch06-server-configuration.xml Sun Sep 16 22:25:04
2012
@@ -113,7 +113,7 @@
zustandsorientiert ist, bietet es einen deutlich schnelleren
Netzwerkzugriff – spart allerdings auch einige wichtige
Funktionen aus. So bietet er eine SASL-basierte Verschlüsselung
- und Authentifizierung, hat aber keine Protokollierungsfunktionen
+ und Authentisierung, hat aber keine Protokollierungsfunktionen
oder eingebauten Web-Browser-Zugriff. Wie auch immer, er ist
extrem einfach einzurichten und für kleinere Teams, welche
einfach nur schnell mit Subversion "loslegen" wollen, die beste
@@ -143,7 +143,7 @@
unterscheidet sich die Funktionalität ziemlich von der normalen
Nutzung von <command>svnserve</command>. SSH wird zur
Verschlüsselung der gesamten Kommunikation verwendet. Ebenso zur
- Authentifizierung, was die Verwendung von realen Nutzerkonten
+ Authentisierung, was die Verwendung von realen Nutzerkonten
auf dem Subversion-Server notwendig macht (anders als beim
einfachen <command>svnserve</command>, der seine eigene
Nutzerverwaltung hat). Des weiteren ist es notwendig – da
@@ -909,7 +909,7 @@
oder das <literal>svn+ssh://</literal>-Schema. In diesem
Abschnitt behandeln wir die unterschiedlichen Möglichkeiten,
<command>svnserve</command> einzusetzen, wie sich die Clients am
- Server authentifizieren und wie die passenden Zugangsrechte zum
+ Server authentisieren und wie die passenden Zugangsrechte zum
Projektarchiv korrekt eingerichtet werden.</para>
@@ -1221,7 +1221,7 @@
aufzurufen. Bei diesem Aufruf wird vorausgesetzt, dass ein
anderes Programm für den Remote-Zugriff – etwa
<command>rsh</command> oder <command>ssh</command> –
- den Nutzer bereits erfolgreich authentifiziert hat, um nun
+ den Nutzer bereits erfolgreich authentisiert hat, um nun
einen privaten
<command>svnserve</command>-Prozess als <emphasis>dieser
Nutzer</emphasis> zu starten. (Beachten Sie, dass für Sie
@@ -1541,7 +1541,7 @@
<itemizedlist>
<listitem><para>Der Client kann seine Anfragen anonym,
also ohne eine vorhergehende
- Authentifizierungsanfrage, senden.</para></listitem>
+ Authentisierungsanfrage, senden.</para></listitem>
<listitem><para>Der Client kann jederzeit eine
Anmeldeaufforderung erhalten.</para></listitem>
@@ -1983,9 +1983,9 @@
normalerweise eine Begrüßung, die eine Auflistung der von ihm
unterstützten Fähigkeiten umfasst, woraufhin der Client mit
einer ähnlichen Liste von Fähigkeiten antwortet. Falls der
- Server so konfiguriert wurde, dass er eine Authentifizierung
+ Server so konfiguriert wurde, dass er eine Authentisierung
benötigt, sendet er eine Aufforderung, die die verfügbaren
- Authentifizierungsmechanismen auflistet; der Client antwortet,
+ Authentisierungsmechanismen auflistet; der Client antwortet,
indem er einen der Mechanismen auswählt und die
Authentifizierung erfolgt dann mittels eines
Nachrichtenaustausches. Selbst falls keine SASL-Fähigkeiten
@@ -1993,7 +1993,7 @@
CRAM-MD5- und ANONYMOUS-Mechanismen (siehe <xref
linkend="svn.serverconfig.svnserve.auth"/>). Falls Client
und Server mit SASL gebaut wurden, könnten eine Anzahl
- weiterer Authentifizierungsmechanismen verfügbar sein.
+ weiterer Authentisierungsmechanismen verfügbar sein.
Trotzdem müssen Sie serverseitig ausdrücklich SASL
konfigurieren, um es anbieten zu können.</para>
@@ -2191,10 +2191,10 @@
Sie beachten, dass damit auch alle Clients gezwungen sind,
SASL zu unterstützen. Kein Subversion-Client ohne
SASL-Unterstützung (u.a. alle Clients vor Version 1.5) kann
- sich authentifizieren. Andererseits möchten Sie vielleicht
+ sich authentisieren. Andererseits möchten Sie vielleicht
gerade diese Einschränkung (<quote>Meine Clients müssen
sämtlich Kerberos verwenden!</quote>). Wenn Sie jedoch
- möchten, dass sich auch Nicht-SASL-Clients authentifizieren
+ möchten, dass sich auch Nicht-SASL-Clients authentisieren
können, stellen Sie sicher, dass optional der
CRAM-MD5-Mechanismus angeboten wird. Alle Clients können
CRAM-MD5 verwenden, egal, ob sie SASL verstehen oder
@@ -2335,7 +2335,7 @@
lokalen <command>ssh</command>-Prozess auf, der sich mit
<literal>host.example.com</literal> verbindet, sich (gemäß der
SSH-Benutzerkonfiguration) als Benutzer
- <literal>harryssh</literal> authentifiziert und dann auf dem
+ <literal>harryssh</literal> authentisiert und dann auf dem
entfernten Rechner einen privaten
<command>svnserve</command>-Prozess unter der Benutzerkennung
<literal>harryssh</literal> startet. Der Befehl
@@ -2611,8 +2611,8 @@
verwenden möchten. Stellen Sie sicher, dass für das Konto
ein Paar bestehend aus einem öffentlichen und einem privaten
SSH-Schlüssel installiert ist und dass sich der Benutzer
- über die Authentifizierung mit einem öffentlichen Schlüssel
- anmelden kann. Die Authentifizierung mit Passwort wird nicht
+ über die Authentisierung mit einem öffentlichen Schlüssel
+ anmelden kann. Die Authentisierung mit Passwort wird nicht
funktionieren, da sich alle folgenden SSH-Tricks um die
Verwendung der SSH-Datei
<filename>authorized_keys</filename> drehen.</para>
@@ -2758,7 +2758,7 @@
account.</para>
-->
<para>Dieses Beispiel erlaubt sowohl Harry als auch Sally,
- sich über die Authentifizierung durch einen öffentlichen
+ sich über die Authentisierung durch einen öffentlichen
Schlüssel mit demselben Konto zu verbinden. Beide verfügen
über einen angepassten Befehl, der ausgeführt wird. Die
Option <option>--tunnel-user</option> teilt
@@ -3386,7 +3386,7 @@
<!--
<title>Authentication Options</title>
-->
- <title>Authentifizierungsoptionen</title>
+ <title>Authentisierungsoptionen</title>
<!--
<para>At this point, if you configured
@@ -3413,7 +3413,7 @@
accessible to everyone. In other words:</para>
-->
<para>kann die Welt <quote>anonym</quote> auf Ihr Projektarchiv
- zugreifen. Bis Sie Authentifizierungs- und
+ zugreifen. Bis Sie Authentisierungs- und
Autorisierungsrichtlinien konfiguriert haben, sind die über
die Direktive <literal>Location</literal> zur Verfügung
gestellten Projektarchive allgemein für jedermann zugreifbar.
@@ -3597,7 +3597,7 @@
fehlt, sind Direktiven, die Apache sagen,
<emphasis>welche</emphasis> Arten von Client-Anfragen eine
Autorisierung erfordern. Überall dort wo eine Autorisierung
- verlangt wird, erwartet Apache auch eine Authentifizierung.
+ verlangt wird, erwartet Apache auch eine Authentisierung.
Das Einfachste ist es, alle Anfragen zu schützen. Durch
Hinzufügen von <literal>Require valid-user</literal> wird
Apache mitgeteilt, dass alle Anfragen einen
@@ -3708,7 +3708,7 @@
asymmetrisches Kryptosystem das Mittel der Wahl. Am besten
solte eine Art der SSL-Verschlüsselung eingesetzt werden, so
dass Clients sich über <literal>https://</literal> statt
- <literal>http://</literal> authentifizieren; als
+ <literal>http://</literal> authentisieren; als
Minimallösung können Sie Apache so einstellen, dass ein
selbstsigniertes Server-Zertifikat verwendet wird.
<footnote>
@@ -4150,7 +4150,7 @@
url="http://svn.collab.net/repos/svn"/> allen auf der Welt
lesende Operationen (wie etwa das Auschecken von
Arbeitskopien und das Stöbern mit einem Web-Browser),
- beschränkt jedoch Schreiboperationen auf authentifiziere
+ beschränkt jedoch Schreiboperationen auf authentifizierte
Nutzer. Um diese abgestufte Einschränkung einzurichten,
können Sie die Konfigurationsdirektiven
<literal>Limit</literal> und <literal>LimitExcept</literal>
@@ -4334,7 +4334,7 @@
-->
<para>Der einfachste Block besteht aus einem völlig offenen
Zugang. In diesem Szenario schickt Apache niemals
- Aufforderungen zur Authentifizierung, so dass alle Benutzer
+ Aufforderungen zur Authentisierung, so dass alle Benutzer
als <quote>anonymous</quote> behandelt werden. (Siehe <xref
linkend="svn.serverconfig.httpd.authz.perdir.ex-1"/>.)
</para>
@@ -4376,9 +4376,9 @@
<xref
linkend="svn.serverconfig.httpd.authz.perdir.ex-2"/>.)</para>
-->
<para>Am anderen Ende der Paranoia-Skala können Sie Ihren
- Block so konfigurieren, dass sich jedermann authentifizieren
+ Block so konfigurieren, dass sich jedermann authentisieren
muss. Alle Clients müssen sich ausweisen. Ihr Block verlangt
- eine unbedingte Authentifizierung mit der Direktive
+ eine unbedingte Authentisierung mit der Direktive
<literal>Require valid-user</literal>; diese Direktive
definiert auch, wie die Authentifizierung erfolgen soll.
(Siehe <xref
@@ -4451,7 +4451,7 @@
Benutzer zunächst anonym auf das Projektarchiv zu. Falls
Ihre Zugangsrichtlinien an einer Stelle einen echten
Benutzernamen erfordern sollte, fordert Apache den Client
- auf, sich zu authentifizieren. Eingestellt wird dieses
+ auf, sich zu authentisieren. Eingestellt wird dieses
Verhalten mit den gemeinsam verwendeten Direktiven
<literal>Satisfy Any</literal> sowie <literal>Require
valid-user</literal>. (Siehe <xref
=======================================
--- /branches/1.5/de/book/ch07-customizing-svn.xml Mon Aug 2 11:28:16 2010
+++ /branches/1.5/de/book/ch07-customizing-svn.xml Sun Sep 16 22:25:04 2012
@@ -223,7 +223,7 @@
contents.</para>
-->
<para>Der benutzereigene Konfigurationsbereich enthält auch
- einen Zwischenspeicher mit Authentifizierungsdaten. Das
+ einen Zwischenspeicher mit Authentisierungsdaten. Das
Verzeichnis <filename>auth</filename> beinhaltet eine Reihe
Unterverzeichnisse, die Teile zwischengespeicherter
Informationen enthalten, welche von den verschiedenen durch
@@ -885,7 +885,7 @@
linkend="svn.serverconfig.netmodel.credcache"/>.</para>
-->
<para>Ordnet an, ob Subversion vom Benutzer nach
- Authentifizierungsaufforderungen eingegebene
+ Authentisierungsaufforderungen eingegebene
Passwörter zwischenspeichern soll oder nicht. Der
Standardwert ist <literal>yes</literal>. Setzen Sie
den Wert auf <literal>no</literal>, um die
@@ -913,7 +913,7 @@
<para>Diese Einstellung ist die gleiche wie
<literal>store-passwords</literal>, außer dass sie die
Zwischenspeicherung <emphasis>aller</emphasis>
- Authentifizierungsinformationen erlaubt:
+ Authentisierungsinformationen erlaubt:
Benutzernamen, Passwörter, Server-Zertifikate und alle
möglichen anderen Typen speicherbarer
Berechtigungsnachweise.</para>
=======================================
--- /branches/1.5/de/book/ch09-reference.xml Mon Aug 2 11:28:16 2010
+++ /branches/1.5/de/book/ch09-reference.xml Sun Sep 16 22:25:04 2012
@@ -146,7 +146,7 @@
runtime configuration directories.</para>
-->
<para>Verhindert die Zwischenspeicherung von
- Authentifizierungsinformationen (z.B. Benutzername und
+ Authentisierungsinformationen (z.B. Benutzername und
Passwort) in den Laufzeitkonfigurationsverzeichnissen
von Subversion.</para>
</listitem>
@@ -184,7 +184,7 @@
incorrect, Subversion will prompt you for this
information as needed.</para>
-->
- <para>Gibt das Passwort zur Authentifizierung gegenüber
+ <para>Gibt das Passwort zur Authentisierung gegenüber
einem Subversion-Server an. Falls es nicht mitgegeben
wird oder falsch ist, fragt Subversion bei Bedarf
nach.</para>
@@ -201,7 +201,7 @@
incorrect, Subversion will prompt you for this
information as needed.</para>
-->
- <para>Gibt den Benutzernamen zur Authentifizierung gegenüber
+ <para>Gibt den Benutzernamen zur Authentisierung gegenüber
einem Subversion-Server an. Falls er nicht mitgegeben
wird oder falsch ist, fragt Subversion bei Bedarf
nach.</para>
@@ -13076,7 +13076,7 @@
runtime configuration directories.</para>
-->
<para>Verhindert die Zwischenspeicherung von
- Authentifizierungsinformationen (z.B. Benutzername und
+ Authentisierungsinformationen (z.B. Benutzername und
Passwort) in den Laufzeitkonfigurationsverzeichnissen
von Subversion.</para>
</listitem>
More information about the svnbook-dev
mailing list