cvs: smarty /docs/de language-snippets.ent preface.xml

http://cvs.php.net/diff.php/smarty/docs/de/language-snippets.ent?r1=1.2&r2=1.3&ty=u
Index: smarty/docs/de/language-snippets.ent
diff -u smarty/docs/de/language-snippets.ent:1.2 smarty/docs/de/language-snippets.ent:1.3
--- smarty/docs/de/language-snippets.ent:1.2	Fri Jul 16 10:32:27 2004
+++ smarty/docs/de/language-snippets.ent	Fri Jun 10 05:32:59 2005
@@ -1,11 +1,29 @@
-<!-- EN-Revision: 1.2 Maintainer: andreas Status: ready -->
+<!-- $Revision: 1.3 $ -->
+<!-- EN-Revision: 1.5 Maintainer: andreas Status: ready -->
+
 <!ENTITY note.parameter.merge '<note>
  <title>Technische Bemerkung</title>
  <para>
-  Der <parameter>merge</parameter> Parameter ber&uuml;ksichtigt Array Keys. Das bedeutet, dass numerisch indizierte Arrays sich gegenseitig &uuml;berschreiben k&ouml;nnen, oder die Keys nicht sequentiell ausgegeben werden. Dies, im Gegensatz zur PHP Funktion array_merge(), die numerische Keys neu sortiert.
+  Der <parameter>merge</parameter> Parameter ber&uuml;ksichtigt Array
+  Keys. Das bedeutet, dass numerisch indizierte Arrays sich
+  gegenseitig &uuml;berschreiben k&ouml;nnen, oder die Keys nicht
+  sequentiell ausgegeben werden. Dies, im Gegensatz zur PHP Funktion
+  <ulink url="&url.php-manual;array_merge">array_merge()</ulink>, die
+  numerische Keys neu sortiert.
  </para>
 </note>'>
 
 <!ENTITY parameter.compileid '<para>
- Als optionaler dritter Parameter, k&ouml;nnen sie die <parameter>compile_id</parameter> angeben. Dies ist sinnvoll, wenn Sie verschiedene Versionen der komipilerten Templates f&uuml;r verschiedene Sprachen unterhalten wollen. Weiter ist dieser Parameter n&uuml;tzlich, wenn Sie mehrere $template_dir Verzeichnisse, aber nur ein $compile_dir nutzen. Setzen Sie <parameter>compile_id</parameter> f&uuml;r jedes Template Verzeichnis, da gleichnamige Templates sich sonst &uuml;berschreiben. Sie k&ouml;nnen die <link linkend="variable.compile.id">$compile_id</link> auch nur einmal, global setzen.
+ Als optionaler dritter Parameter, k&ouml;nnen sie die
+ <parameter>$compile_id</parameter> angeben. Dies ist sinnvoll, wenn
+ Sie verschiedene Versionen der komipilerten Templates f&uuml;r
+ verschiedene Sprachen unterhalten wollen. Weiter ist dieser Parameter
+ n&uuml;tzlich, wenn Sie mehrere
+ <link linkend="variable.template.dir">$template_dir</link> Verzeichnisse,
+ aber nur ein <link linkend="variable.compile.dir">$compile_dir</link>
+ nutzen. Setzen Sie <parameter>$compile_id</parameter>  f&uuml;r jedes
+ Template Verzeichnis, da gleichnamige Templates sich sonst
+ &uuml;berschreiben. Sie k&ouml;nnen die
+ <link linkend="variable.compile.id">$compile_id</link> auch nur einmal,
+ global setzen.
 </para>'>
http://cvs.php.net/diff.php/smarty/docs/de/preface.xml?r1=1.2&r2=1.3&ty=u
Index: smarty/docs/de/preface.xml
diff -u smarty/docs/de/preface.xml:1.2 smarty/docs/de/preface.xml:1.3
--- smarty/docs/de/preface.xml:1.2	Fri Jul 16 10:32:27 2004
+++ smarty/docs/de/preface.xml	Fri Jun 10 05:32:59 2005
@@ -1,64 +1,79 @@
 <?xml version="1.0" encoding="iso-8859-1"?>
 <!-- EN-Revision: 1.2 Maintainer: andreas Status: ready -->
-<!-- $Revision: 1.2 $ -->
+<!-- $Revision: 1.3 $ -->
  <preface id="preface">
   <title>Vorwort</title>
   <para>
-   Die Frage, wie man die Applikations-Logik eines PHP-Scriptes vom Layout trennt, ist unzweifelhaft
-   eines der am h&auml;figsten diskutierten Themen. Da PHP als
-   "in HTML eingebettete Scripting-Sprache" angepriesen wird, ergibt sich
-   nach einigen Projekten in denen man HTML und PHP gemischt hat schnell die Idee,
-   Funktionalit&auml;t und Darstellung zu trennen. Dazu kommt, dass in vielen Firmen Applikationsentwickler
-   und Designer nicht die selbe Person sind. In Konsequenz beginnt die Suche nach einer Template-Lösung.
+   Die Frage, wie man die Applikations-Logik eines PHP-Scriptes vom
+   Layout trennt, ist unzweifelhaft eines der am h&auml;figsten
+   diskutierten Themen. Da PHP als "in HTML eingebettete
+   Scripting-Sprache" angepriesen wird, ergibt sich nach einigen
+   Projekten in denen man HTML und PHP gemischt hat schnell die Idee,
+   Funktionalit&auml;t und Darstellung zu trennen. Dazu kommt, dass in
+   vielen Firmen Applikationsentwickler und Designer nicht die selbe
+   Person sind. In Konsequenz beginnt die Suche nach einer
+   Template-Lösung.
   </para>
   <para>
-   Als Beispiel: In unserer Firma funktioniert die Entwicklung einer Applikation
-   wie folgt: Nachdem die Spezifikationen erstellt sind, entwickelt der
-   Interface Designer einen Prototypen des Interfaces und &uuml;bergibt dieses
-   dem Programmierer. Der Programmierer implementiert die Gesch&auml;ftslogik
-   in PHP und verwendet den Interface-Prototypen zur Erstellung eines Template-Skeletts.
-   Danach &uuml;bergibt der Programmierer die Templates dem HTML/Webseiten-Designer
-   welcher ihnen den letzten Schliff verleiht. Das Projekt kann mehrfach zwischen
-   dem Programmieren und dem Designer ausgetauscht werden. Deshalb ist es wichtig,
-   dass die Trennung von Logik und Design klar stattfindet. Der Programmierer will
-   sich normalerweise nicht mit HTML herumschlagen m&uuml;ssen und m&ouml;chte auch
-   nicht, dass der Designer seinen PHP-Code ver&auml;ndert. Designer selbst
-   ben&ouml;tigen Konfigurationsdateien, dynamische Bl&ouml;cke und andere Interface spezifische
-   Eigenheiten, m&ouml;chten aber auch nicht direkt mit PHP in Ber&uuml;hrung kommen.
+   Als Beispiel: In unserer Firma funktioniert die Entwicklung einer
+   Applikation wie folgt: Nachdem die Spezifikationen erstellt sind,
+   entwickelt der Interface Designer einen Prototypen des Interfaces
+   und &uuml;bergibt dieses dem Programmierer. Der Programmierer
+   implementiert die Gesch&auml;ftslogik in PHP und verwendet den
+   Interface-Prototypen zur Erstellung eines Template-Skeletts.
+   Danach &uuml;bergibt der Programmierer die Templates dem
+   HTML/Webseiten-Designer welcher ihnen den letzten Schliff
+   verleiht. Das Projekt kann mehrfach zwischen dem Programmieren und
+   dem Designer ausgetauscht werden. Deshalb ist es wichtig, dass die
+   Trennung von Logik und Design klar stattfindet. Der Programmierer
+   will sich normalerweise nicht mit HTML herumschlagen m&uuml;ssen
+   und m&ouml;chte auch nicht, dass der Designer seinen PHP-Code
+   ver&auml;ndert. Designer selbst ben&ouml;tigen
+   Konfigurationsdateien, dynamische Bl&ouml;cke und andere Interface
+   spezifische Eigenheiten, m&ouml;chten aber auch nicht direkt mit
+   PHP in Ber&uuml;hrung kommen.
   </para>
   <para>
-   Die meisten Template-Engines die heutzutage angeboten werden, bieten eine
-   rudiment&auml;re M&ouml;glichkeit Variablen in einem Template zu ersetzen
-   und beherschen eine eingeschr&auml;nkte Funktionalit&auml;t f&uuml;r dynamische
-   Bl&ouml;cke. Unsere Anforderungen forderten jedoch ein wenig mehr. Wir wollten
-   erreichen, dass sich Programmierer &uuml;berhaupt nicht um HTML Layouts
-   k&uuml;mmern m&uuml;ssen. Dies war aber fast unumg&auml;nglich. Wenn ein
-   Designer zum Beispiel alternierende Farben in einer Tabelle einsetzen wollte,
-   musste dies vorhergehend mit dem Programmierer abgesprochen werden. Wir wollten
-   weiter, dass dem Designer Konfigurationsdateien zur Verf&uuml;gung st&uuml;nden,
-   aus denen er Variablen f&uuml;r seine Templates extrahieren kann. Die Liste ist endlos.
+   Die meisten Template-Engines die heutzutage angeboten werden,
+   bieten eine rudiment&auml;re M&ouml;glichkeit Variablen in einem
+   Template zu ersetzen und beherschen eine eingeschr&auml;nkte
+   Funktionalit&auml;t f&uuml;r dynamische Bl&ouml;cke. Unsere
+   Anforderungen forderten jedoch ein wenig mehr. Wir wollten
+   erreichen, dass sich Programmierer &uuml;berhaupt nicht um HTML
+   Layouts k&uuml;mmern m&uuml;ssen. Dies war aber fast
+   unumg&auml;nglich. Wenn ein Designer zum Beispiel alternierende
+   Farben in einer Tabelle einsetzen wollte, musste dies vorhergehend
+   mit dem Programmierer abgesprochen werden. Wir wollten weiter, dass
+   dem Designer Konfigurationsdateien zur Verf&uuml;gung st&uuml;nden,
+   aus denen er Variablen f&uuml;r seine Templates extrahieren
+   kann. Die Liste ist endlos.
   </para>
   <para>
-   Wir begannen 1999 mit der Spezifikation der Template Engine. Nachdem dies
-   erledigt war, fingen wir an eine Engine in C zu schreiben, die - so hofften
-   wir - in PHP eingebaut w&uuml;rde. Nach einer hitzigen Debatte dar&uuml;ber
-   was eine Template Engine k&ouml;nnen sollte und was nicht, und nachdem wir feststellen
-   mussten, dass ein paar komplizierte technische Probleme auf uns zukommen
-   w&uuml;rden, entschlossen wir uns die Template Engine in PHP als Klasse
-   zu realisieren, damit sie von jederman verwendet und angepasst werden kann.
-   So schrieben wir also eine Engine, die wir <productname>SmartTemplate</productname>
-   nannten (anm: diese Klasse wurde nie ver&ouml;ffentlicht). SmartTemplate
-   erlaubte uns praktisch alles zu tun was wir uns vorgenommen hatten: normale
-   Variablen-Ersetzung, M&ouml;glichkeiten weitere Templates einzubinden,
-   Integration von Konfigurationsdateien, Einbetten von PHP-Code, limitierte 'if'-Funktionalit&auml;t
-   und eine sehr robuste Implementation von dynamischen Bl&ouml;cken die
-   mehrfach verschachtelt werden konnten. All dies wurde mit Regul&auml;ren Ausdr&uuml;cken
-   erledigt und der Sourcecode wurde ziemlich un&uuml;bersichtlich. F&uuml;r gr&ouml;ssere
-   Applikationen war die Klasse auch bemerkenswert langsam, da das Parsing bei jedem
-   Aufruf einer Seite durchlaufen werden musste. Das gr&ouml;sste Problem aber war,
-   dass der Programmierer das Setup, die Templates und dynamische Bl&ouml;cke in seinem
-   PHP-Skript definieren musste. Die n&auml;chste Frage war: wie k&ouml;nnen wir dies
-   weiter vereinfachen?
+   Wir begannen 1999 mit der Spezifikation der Template
+   Engine. Nachdem dies erledigt war, fingen wir an eine Engine in C
+   zu schreiben, die - so hofften wir - in PHP eingebaut
+   w&uuml;rde. Nach einer hitzigen Debatte dar&uuml;ber was eine
+   Template Engine k&ouml;nnen sollte und was nicht, und nachdem wir
+   feststellen mussten, dass ein paar komplizierte technische Probleme
+   auf uns zukommen w&uuml;rden, entschlossen wir uns die Template
+   Engine in PHP als Klasse zu realisieren, damit sie von jederman
+   verwendet und angepasst werden kann.  So schrieben wir also eine
+   Engine, die wir <productname>SmartTemplate</productname> nannten
+   (anm: diese Klasse wurde nie ver&ouml;ffentlicht). SmartTemplate
+   erlaubte uns praktisch alles zu tun was wir uns vorgenommen hatten:
+   normale Variablen-Ersetzung, M&ouml;glichkeiten weitere Templates
+   einzubinden, Integration von Konfigurationsdateien, Einbetten von
+   PHP-Code, limitierte 'if'-Funktionalit&auml;t und eine sehr robuste
+   Implementation von dynamischen Bl&ouml;cken die mehrfach
+   verschachtelt werden konnten. All dies wurde mit Regul&auml;ren
+   Ausdr&uuml;cken erledigt und der Sourcecode wurde ziemlich
+   un&uuml;bersichtlich. F&uuml;r gr&ouml;ssere Applikationen war die
+   Klasse auch bemerkenswert langsam, da das Parsing bei jedem Aufruf
+   einer Seite durchlaufen werden musste. Das gr&ouml;sste Problem
+   aber war, dass der Programmierer das Setup, die Templates und
+   dynamische Bl&ouml;cke in seinem PHP-Skript definieren musste. Die
+   n&auml;chste Frage war: wie k&ouml;nnen wir dies weiter
+   vereinfachen?
   </para>
   <para>
    Dann kam uns die Idee, aus der schließlich Smarty wurde. Wir wussten