> <p>Das <code>if</code>-Element funktioniert wie die <code>if</code>- > Anweisung einer Programmiersprache. Die Testbedingung wird ausgewertet und > ist das Ergebnis wahr, wird der Text bis zum nächsten <code>elif</code>-, > <code>else</code>- oder <code>endif</code>-Element in den Ausgabestrom > eingebaut.</p> This is the place where omitting the "wenn" and "dann" from these German sentences does the biggest damage, because leaving them in place would implicitly explain the use of the "if" and "else" keywords (like it did in the English version). > Reguläre Ausdrücke werden mit der > <a href="http://www.pcre.org";>PCRE</a>-Engine implementiert I would like to have "Engine" translated here. [NOTE] But I would like the English version to use "library" instead of "engine" as well, which would make translation easier here. > bindet am stärksten. Die folgenden Aneisungen sind gleichbedeutend:</p> Typo: "Aneisungen" => "Anweisungen" > dann darf sie keine Leerzeichen oder Tabulatoren enthalten, I would like to have the original notion "whitespace" in this line (untranslated), and the explanation in round brackets like in the English original: "dann darf sie kein whitespace (Leerzeichen bzw. Tabulator) enthalten, > <li>Ausdrücke werden von links nach rechts ausgewertet.</li> > <li>Binäre Boole'sche Operatoren (<code>&&</code> > und <code>||</code>) werden, falls möglich, verkürzt. "short circuited" is not the same as "shortened". "verk�rzt" sounds as if the semantics of the expression will be changed during evaluation, which is not the case, as the description below explains correctly. > einmal kompilieren. Für jeden untersuchten Ausdruck erhalten Sie dann > Informationen zu den Elementen, der Reihenfolge und das Resultat der > Auswertung, das mit der Ausgabe an den Client gesendet wird.</p> Small deviation, big difference: "das" => "die" and "wird" => "werden". This debug information is sent to the client as well, so it will be part of the output; this isn't a thing you would want to do in a productive environment. [NOTE] This is noteworthy because normally Apache would write debugging log informations like these into some log files and not display them to some visitor... so beware! This might even be a security issue, as it could make server paths and other secret informations accessible to the user. > <description>Die Zeichenfolge, die angezeigt wird, wenn eine nicht > gesetzte Variable signalisiert wird.</description> Where does the "signalisiert" come from? I would write "wenn der Inhalt einer nicht gesetzten Variablen mit der Anweisung 'echo' ausgegeben werden soll". > <p>Mit dieser Anweisung wird die Zeichenfolge geändert, die > <module>mod_include</module> anzeigt, wenn eine Variable nicht gesetzt wurde.</p> Nope. It doesn't matter whether a variable is set or not in other situations (you may compare an undefined variable and not raise this exception!); only if an undefined variable is _displayed using the 'echo' command_, then this definition is used. So: "wenn der Inhalt einer nicht gesetzten Variable mit 'echo' ausgegeben werden soll". > Für den praktischen Einsatz Nope, but "f�r den produktiven Einsatz". Using the standard error behaviour isn't uncommon, but you might not want to show your errors to your customers, and in this case you can 'hide' the error message by making it an HTML comment. (Note that this won't 'hide' the error to someone who is able to use the "view source" feature of his/her browser...) > kann die Standardfehlermeldung beispielsweise in > <code>"<!-- Error -->"</code> > geändert werden, damit die Meldung dem Benutzer nicht angezeigt wird.</p> I would prefer to translate "Error" to "Fehler" here, to make clear that this is not a syntax element of the SSI language but just an arbitrary HTML comment. > <p>Mit dieser Anweisung wird die Zeichenfolge geändert, die > <module>mod_include</module> ein zu verarbeitendes > Include-Element signalisiert.</p> I would prefer to replace "signalisiert" by "an dem mod_include ein ... Element erkennt". ("signal" sounds like event handling, but we are talking about parsing here.) > <p>In Verbindung mit einem übereinstimmenden > <directive module="mod_include">SSIEndTag</directive> können auch > SSI-Anweisungen benutzt werden:</p> Nope, but "k�nnen SSI-Anweisungen so verwendet werden, wie das in dem nachfolgenden Beispiel der Fall ist". Actually, you may use this to redefine the complete SSI syntax and make SSI directives look like directives of another language. The example made them look like PHP directives (which isn't really made clear by the English text, but PHP users would know that). > <example><title>SSI-Anweisungen mit wechselnden Start- und End-Tags</title> Nope, but "mit alternativen Start- und End-Tags" (those that have been specified by the appropriate directives and now differ from the Apache default values). > <description>Konfiguration des Datumsformats</description> More precisely: "Konfiguration des Formats zur _Anzeige_ von Datumswerten". > Der <var>Format-String</var> entspricht der Funktion <code>strftime(3)</code> > der C-Standardbibliothek.</p> Nope. The string cannot "correspond" to a function - it has to be specified according to the requirements of this function: "Der Format-String mu� so angegeben werden, wie dies f�r einen Parameterwert der strftime(3)-Funktion der C-Standardbibliothek der Fall w�re." [NOTE] I would love to see a hyperlink pointing to the corresponding man page here; not all Apache admins are C hackers. > <p>Diese Anweisung liefert das gleiche Ergebnis, wie What would this comma be good for? > <description>SSI-Direktiven in Dateien mit gesetztem Execute-Bit werden > untersucht.</description> "untersucht" => "ausgewertet". > Folgende Werte können übergeben werden:</p> "�bergeben" => "angegeben". (this is a directive, not a function.) > User-Execute-Bit werden als vom Server untersuchtes HTML-Dokument behandelt.</dd> "untersuchtes" => "auszuwertendes". (future tense as well.) > Ist es gesetzt, wird das <code>Last-modified</code>-Datum der > zurückgesenden Datei als Datum der letzten Änderung gesetzt. Typo: "gesenden" => "gesendeten" > <note><title>Note</title> > <p>Die Option <code>full</code> sollte nur gesetzt werden, wenn das > Group-Execute-Bit für alle SSI-Skripte nicht gesetzt ist, die > eine <code>#include</code>-Anweisung für CGI enthalten oder auf > andere Weise bei jeder Anfrage unterschiedliche Ausgaben liefern > (oder die sich möglicherweise nach Anfragen ändern > können).</p> The English version is more explicit: "Die Verwendung der Option "full" ist nicht ratsam, es sei denn, Sie sind in der Lage, sicherzustellen (!), da� das group-execute Bits f�r alle SSI-Skripte, welche CGI-Skripte einbinden oder auf andere Weise bei jedem Zugriff wechselnde Ausgaben liefern, nicht gesetzt ist." This option turns on a dangerous mechanism that might cause _lots_ of your dynamic content to be sent with HTTP headers that indicate this content to be cacheable; you should be very cautious and know exactly what you are doing here. [NOTE] This might even be worth a "warning" instead of a "note". Regards, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
