Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- dev:284:translate [19.07.2018 12:10] – [Wie wird Translate benutzt?] Manuela v.d.Decken
+++ dev:284:translate [31.08.2023 08:22] (aktuell) – [Wie wird Translate benutzt?] Manuela v.d.Decken
@@ Zeile 9: / Zeile 9: @@
 Dies ist die bevorzugte und auch dringend empfohlene Art:\\
 //(übersichtlich und schon im Texteditor einfach zu sortieren)//
-<PHP>
+<code php>
 //Modul Description
 $module_description = 'Enter here a really short description of your module. About 200-250 characters should suffice.';
@@ Zeile 19: / Zeile 19: @@
 $MOD_MyModule['MESSAGE_ARCHIVE_DELETED']     = 'Zip(s) deleted successfully.';
 $MOD_MyModule['MESSAGE_ARCHIVE_NOT_DELETED'] = 'Cannot delete the selected Zip(s).';
-</PHP>
+</code>
 manche schreiben die Einträge auch auf diese Art:\\
 //(deutlich schwieriger zu lesen und nicht exakt sortierbar)//
-<PHP>
+<code php>
 $MOD_MyModule['PRINT']                       = 'Please print this page, if a copy is desired for your records.';
 $MOD_MyModule['LOAD_LAYOUT']                 = 'Load Default Layout';
@@ Zeile 29: / Zeile 29: @@
 $MOD_MyModule_MESSAGE['ARCHIVE_DELETED']     = 'Zip(s) deleted successfully.';
 $MOD_MyModule_MESSAGE['ARCHIVE_NOT_DELETED'] = 'Cannot delete the selected Zip(s).';
-</PHP>
+</code>
 Das sieht nicht soo gut aus, aber es funktioniert. Beide Schreibweisen erzeugen jedenfalls die selben Translate-Schlüsselwörter.
-<PHP>
+<code php>
 echo $oTrans->MOD_MyModule_PRINT;
 echo $oTrans->MOD_MyModule_LOAD_LAYOUT;
@@ Zeile 38: / Zeile 38: @@
 echo $oTrans->MOD_MyModule_MESSAGE_ARCHIVE_DELETED;
 echo $oTrans->MOD_MyModule_MESSAGE_ARCHIVE_NOT_DELETED;
-</PHP>
+</code>
 Zwingend ist derzeit jedoch noch der Präfix "$MOD_MyModule_" bzw."$MOD_MyModule[".
 Nur so lassen sich ungewollte Überschneidungen der Schlüsselwörter verhindern.
@@ Zeile 49: / Zeile 49: @@
 Die Sprachdateien sowohl im Core als auch in Modulen mussten mit solchen und ähnlichen, abenteuerlichen Konstrukten 'eingebaut' werden:
-<PHP>
+<code php>
 // Load Language file
 if(is_readable(WB_PATH.'/modules/MyModule/languages/EN.php')) {
@@ Zeile 63: / Zeile 63: @@
     require_once(WB_PATH.'/modules/MyModule/languages/'.LANGUAGE.'.php');
 }
-</PHP>
+</code>
 Die Ausgabe erfolgte nach dem rudimentären Muster:
-<PHP>
+<code php>
 // Syntax Typ 1
 global $MOD_MyModule;
@@ Zeile 76: / Zeile 76: @@
 echo $MOD_MyModule_TEXT['GUEST'];
 echo $MOD_MyModule_MESSAGE['ARCHIVE_DELETED'];
-</PHP>
+</code>
 Nach dieser alten Prä-Translate-Methode sind leider noch die teils ellenlangen Präfixes notwendig.
 <div important>Die Benutzung der alten Sprachvariablen ist deprecatet!\\ Die alten Sprachvariablen werden mit Abschluss der Umstellung auf **Translate** ohne extra Ankündigung aus dem System entfernt, was auch die obigen Ausgabemethoden entfernt.</div>
@@ Zeile 121: / Zeile 121: @@
 Für Addon-Entwickler ist Translate sehr einfach einzusetzen. Die Grundinitialisierung wird **immer** automatisch vom Core vorgenommen und Addons haben damit überhaupt nichts zu schaffen. Bei älteren Addons, die noch PHP-Dateien enthalten, die direkt von außen aufgerufen werden müssen, sind 2 bis maximal 4 Translate-Methoden erforderlich (alle Kommandos werden in der Standalone-Form angegeben). Bedingung für den Einsatz von Translate ist, dass die Datei ''framework/initialize.php'' bereits geladen (included) ist:
-  * <php>Translate::getInstance()->enableAddon('modules\\MeinAddon');</php> Dieser Befehl wird gleich zu Beginn einer aufgerufenen Datei eingesetzt. Dadurch werden eventuell vorhandene Sprachdateien dieses Addons aktiviert. Sollte noch ein anderes Addon aktiviert sein, wird dieses zuerst deaktiviert.
+  * ''Translate::getInstance()->enableAddon('modules\\MeinAddon');'' Dieser Befehl wird gleich zu Beginn einer aufgerufenen Datei eingesetzt. Dadurch werden eventuell vorhandene Sprachdateien dieses Addons aktiviert. Sollte noch ein anderes Addon aktiviert sein, wird dieses zuerst deaktiviert.
-  * <php>Translate::getInstance()->disableAddon();</php> Mit diesem Kommando wird das aktive Addon mitsamt seinem Theme und/oder Template wieder von Translate getrennt.
+  * ''Translate::getInstance()->disableAddon();'' Mit diesem Kommando wird das aktive Addon mitsamt seinem Theme und/oder Template wieder von Translate getrennt.
 <div info>Die folgenden Methoden stehen erst ab Template Version 1.0.0 zur Verfügung!</div>
-  * <php>Translate::getInstance()->enableAddonTemplate('NameDesTemplates');</php> Dieser Befehl aktiviert bei Bedarf vorhandene Sprachdateien eines zugehörigen Templates. Wird kein 'NameDesTemplates' angegeben, wird nach dem allgemein eingestellten Template gesucht. Wird das nicht gefunden, erfolgt ein Fallback auf das Default-Template.
+  * ''Translate::getInstance()->enableAddonTemplate('NameDesTemplates');'' Dieser Befehl aktiviert bei Bedarf vorhandene Sprachdateien eines zugehörigen Templates. Wird kein 'NameDesTemplates' angegeben, wird nach dem allgemein eingestellten Template gesucht. Wird das nicht gefunden, erfolgt ein Fallback auf das Default-Template.
-  * <php>Translate::getInstance()->enableAddonTheme('NameDesThemes');</php> Dieser Befehl aktiviert bei Bedarf vorhandene Sprachdateien eines zugehörigen Themes. Wird kein 'NameDesThemes' angegeben, wird nach dem allgemein eingestellten Theme gesucht. Wird das nicht gefunden, erfolgt ein Fallback auf das Default-Theme.
+  * ''Translate::getInstance()->enableAddonTheme('NameDesThemes');'' Dieser Befehl aktiviert bei Bedarf vorhandene Sprachdateien eines zugehörigen Themes. Wird kein 'NameDesThemes' angegeben, wird nach dem allgemein eingestellten Theme gesucht. Wird das nicht gefunden, erfolgt ein Fallback auf das Default-Theme.
 Einfacher noch geht es bei Addon-Dateien, die Core-gesteuert aufgerufen werden: Hier wird das Addon bereits vom Core aktiviert. Einzig das Template und/oder das Theme müssen derzeit noch vom Addon selbst aktiviert werden. Auch die Deaktivierung erfolgt automatisch durch den Core.
 Jetzt müssen eigentlich nur noch die Übersetzungstexte von Translate abgerufen werden. Der einfachste Weg ist:\\
-<php> $oTrans = Translate::getInstance();</php>\\
+<code php>$oTrans = Translate::getInstance();
-<php> $sText = $oTrans->TEXT_CANCEL; </php>\\
+$sText = $oTrans->TEXT_CANCEL;
-entspricht dem früheren\\
+// oder auch
-<php> globals $TEXT; </php>\\
+$sText = Translate::getInstance()->TEXT_CANCEL;
-<php> $sText = $TEXT['CANCEL']; </php>
+</code>
+entspricht dem früheren
+<code php>$sText = $GLOBALS['TEXT']['CANCEL'];</code>
 Für ältere Addons existiert vorübergehend eine Methode, sämtliche Übersetzungstexte in einem Zug an die //**phplib**// Templateengine zu übergeben:\\
-<php> $template->set_var(Translate::getInstance()->getLangArray()); </php> eingebunden werden die Texte im Template mit ''{TEXT_CANCEL}''.
+<code php> $template->set_var(Translate::getInstance()->getLangArray()); </code> eingebunden werden die Texte im Template mit ''{TEXT_CANCEL}''.
 Das Problem bei dieser Methode ist, dass immer eine komplette Kopie der Übersetzungstabelle an die Templateengine übergeben wird.
-Wesentlich einfacher und platzsparender ist die Verwendung in Verbindung mit Twig, da hier nur eine speichersparende Referenz auf das Translateobjekt übergeben wird:\\
+Wesentlich einfacher und platzsparender ist die Verwendung in Verbindung mit Twig, da hier im Php-Code nur eine speichersparende Referenz auf das Translateobjekt übergeben wird:
-<php> $aTwigData['Trans'] = Translate::getInstance(); </php> die Anzeige im Template erfolgt durch ''%%{{ Trans.TEXT_CANCEL }}%%''
+<code php>$aTwigData['Trans'] = Translate::getInstance();</code>
+die Anzeige im Twig-Template erfolgt dann durch
+<code twig>{{ Trans.TEXT_CANCEL }}</code>

WebsiteBaker Documentation

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge