CMS Made Simple Forums

Wie schon mal an anderer Stelle bemerkt ist CMSMS so frei, alle Sprachdateien zu laden, die es gibt, obwohl - man braucht ja wohl nur eine.
Das ist ein richtiger Bär, ich schätze, dass da 1 MB oder gar mehr flöten geht, abgesehen von der Zeit.
Und das ist ganz einfach zu lösen , im Prinzip mit wenigen Zeilen Code.

Und etwas anderes ist ein dicker Dorn im Auge - die Hilfedateien von Plugins und Modulen - die werden auch komplett geladen, obwohl ein Besucher die nun garnicht benötigt.
Da gibt es Developer, die argumentieren damit, man sollte aus Plugins Module machen, wegen der Hilfedateien.

Das ist aber noch einfacher zu lösen.

Statt eine Hilfe im Code zu hinterlegen, hinterlegt man einen Link z.B. auf eine kleine PDF Datei.

Eine solche  Methode bietet mehr für den Anwender und ist insgesamt einfacher zu handeln.


Setzt man sich nun Regeln in der Namensvergabe dann kann folgendes passieren:

Link auf module_kalender_1.6_de_de.pdf  oder
Link auf module_kalender_1.6_en_US.pdf

Das gleiche für Plugins  Kennung_Name_Version_Sprache.pdf - das war's.
Das hat nicht nur Vorteile, was RAM betrifft, sondern erhebliche Vorteile insgesamt.

Der Admin erhält immer eine Hilfe in seine Sprache und zwar ausführlicher und evtl. bebildert, was ansonsten nicht möglich ist.
Existiert keine Hilfe in seiner Sprache gibt es halt die Hilfe in der Defaultsprache.

Es ist 0 Coder erforderlich um diese Hilfe zu warten.

Diese beiden Dinge bringen insgesamt eine Eintlastung - ich schätze zusammen bestimmt auf 1,2 .. 1,5 MB und angenehme Vorteile für den Nutzer.

Ich bin gespannt ob die "Hunde" den Bären auch fassen werden.

Hattest Du diesbezüglich schon Kontakt mit Ted?

Piratos wrote: Das gleiche für Plugins  Kennung_Name_Version_Sprache.pdf - das war's.

Da gibts aber Probleme mit dem Translation Center - gerade die Hilfe ist ein
wichtiger Teil, der mit übersetzt werden sollte.

Das bleibt doch unverändert so - die Hilfe wird nun nicht mehr in den Code angelegt sondern z.B. in eine exterene PDF Datei, d.h. im Code selbst ist nur noch ein Link auf diese Datei, Sprach - und Versionsgesteuert, wenn man sich Namensregeln zulegt.

Der Coder ist von der Hilfe sozusagen befreit, der Code aber auch und die Hilfe kann in allen Sprachen so ausführlich angelegt werden wie man will.

IMHO würde es ausreichen, nur die Sprachdateien des aktuellen Systemstandards zu laden - die dickste de_DE.php, die ich beim Übersetzen hatte, war gerade mal 21 k (FrontendUsers). Nach dem Löschen der Hilfe waren es gerade mal 5 k weniger - und das macht das Kraut nun wahrlich nicht fett ...

Und mir ist es lieber, wenn die Hilfe im System integriert ist. Wenn erst der Adobe Reader hochgezogen werden muss, nur um schnell mal die Parameter eines Tags anzuschauen, heißt das für, mich mit Kanonen auf Spatzen zu schießen  .

Es muss ja nicht PDF , es kann ja auch html sein.

Die Sprachdateien mit der Hilfe sind z.Z.  echte PHP Files.
Nun ist ein Übersetzer kein Coder und da genügt also das setzen eines falschen Zeichens und ein Abbruch droht.
Einfaches Beispiel - ich habe eine Zeile aus der englischen Hilfedatei zum Menumanager  so verändert:

$lang['deletetemplate'] = 'Delete Template";

Und dann die Seite Home aufgerufen - das Ergebnis ist:

Parse error: syntax error, unexpected T_STRING in I:\xampp\htdocs\test\modules\MenuManager\lang\en_US.php on line 14

Mit einem kleinen Fehler kann ich also das ganze Web lahm legen.
Und solche Fehler sind in der Vergangenheit schon mehr als einmal vorgekommen !

Das Beispiel beweist zudem, dass ALLE Hilfedateien eines Modules beim Aufruf einer Seite geladen werden, die eigentlich nur für den Admin bestimmt sind.

Das bedeutet  X KB mal Anzahl der aktiven Module und da kommen wir schon auf andere Ergebnisse.
Und das in einer Situation wo der Speicherverbrauch völlig ohne Nutzen ist.

Wer meint z.B. beim Menumanager eine wirklich ausführliche Hilfe gegeben zu haben der irrt sich.
Mit einer externen Datei ist es kein Thema diese Hilfe wirklich ausführlich gestalten zu können inkl Bilder etc. .
Unverhoffte Eingriffe in den Code sind nicht möglich.

Piratos wrote: Nun ist ein Übersetzer kein Coder und da genügt also das setzen eines falschen Zeichens und ein Abbruch droht.

Dies ist kein Thema mehr, seit die Übersetzungen über das Translation Center laufen - dort komme ich als Übersetzer gar nicht mehr an den PHP-Code ran - ich sehe nur ein Formular mit 'ner Menge Textfeldern  ...

Und solche Fehler sind in der Vergangenheit schon mehr als einmal vorgekommen !

IMHO ist es Sache des Hilfeschreibers bzw. Übersetzers, dies vor Beendigung des Jobs zu testen. Trotz Translation Center mach ich das zumindest so. Falls es doch mal ein Problem geben sollte, so wäre es ein einfaches gewesen, mal Bescheid zu geben - Irren ist menschlich.

Das Beispiel beweist zudem, dass ALLE Hilfedateien eines Modules beim Aufruf einer Seite geladen werden, die eigentlich nur für den Admin bestimmt sind.

Das bedeutet  X KB mal Anzahl der aktiven Module und da kommen wir schon auf andere Ergebnisse.

Nix anderes hab ich gesagt - Standard-Sprache ist vollkommen ausreichend ...

Wer meint z.B. beim Menumanager eine wirklich ausführliche Hilfe gegeben zu haben der irrt sich.
Mit einer externen Datei ist es kein Thema diese Hilfe wirklich ausführlich gestalten zu können inkl Bilder etc. .

Die Möglichkeit hab ich in der Tat schon lange vermisst - Bilder sagen manchmal mehr als Worte.

Translationcenter hin und her - es gibt in Sprachen Sonderzeichen, die man gesondert behandeln müsste, weil sie ansonsten PHP mässig interpretiert werden könnten.

Bei den Sprachdateien sollte man unterscheiden

Für Besucher sichtbar - diese laden

Nur für den Admin - diese nur im Adminbereich laden

Die notwendigen Änderungen, wenn man dabei bleibt, Sprachdateien komplett laden, mit Ausnahme der Hilfe, die sind wirklich minimal.
Die Hilfen selbst sind ja im Prinzip HTML, man müsste sich da nur auf eine Namensregelung verständigen und dann kann es gemacht werden.

Piratos wrote: Translationcenter hin und her - es gibt in Sprachen Sonderzeichen, die man gesondert behandeln müsste, weil sie ansonsten PHP mässig interpretiert werden könnten.

Fällt Dir da ein bestimmtes Sonderzeichen ein? Im Normalfall werden die Sonderzeichen vom TC in Entitäten umgewandelt.

Bei den Sprachdateien sollte man unterscheiden

Für Besucher sichtbar - diese laden

Nur für den Admin - diese nur im Adminbereich laden

... was wahrscheinlich mit erheblichen Veränderungen im System einhergehen müsste. Oder sehe ich das falsch?

Die notwendigen Änderungen, wenn man dabei bleibt, Sprachdateien komplett laden, mit Ausnahme der Hilfe, die sind wirklich minimal.
Die Hilfen selbst sind ja im Prinzip HTML, man müsste sich da nur auf eine Namensregelung verständigen und dann kann es gemacht werden.

Ich wäre hier für ein moduleigenes help-Verzeichnis - da kann dann der ganze Kram rein (html, Bilder etc.) ... und meinetwegen die about-Info auch gleich noch mit.

erheblichen Veränderungen

Nein, man müsste die Teile nur in getrennte Dateien speichern und über Moduleinterface das steuern.
Das ist genua die richtige Lösung und wenn man dann noch ein grundsätzliches Template hat, das zu verwenden ist, dann sieht das alles auch recht ordentlich aus und HTML dürfte doch wirklich kein Problem sein (vielleicht noch eine kleine Suchfunktion z.B. die aus Selfhtml ?).

Also wenn schon sachen auslagern, dann würde ich eher vorschlagen, eine moduleversion.php (ala xoops) anzulegen. Diese sollte dann nur Daten zur Modulverwaltung enthalten und wenn etwas über langfile geregelt werden muss, wäre wohl ein eigener admin-lang Ordner am einfachsten. Hilfen als PDFs oder HTML halte ich bei weitem für zu aufwendig und vor allem für zu flexibel (alle Anzeigen würden nicht mehr in einen einheitlichen Rahmen gezwängt).

einen einheitlichen Rahmen

Den haben wir doch jetzt bei der Hilfe auch schon nicht, jeder Autor schreibt seine "Ersthilfe" so wie er denkt und die Übersetzer halten sich mehr oder weniger 1:1 dran.  **

Deswegen ja PDF über Openoffice, da man dafür schöne Vorlagen machen kann, die dann zu verwenden wären.

HTML ist da natürlich insgesamt einfacher -  aber auch da lässt sich ja ein Template machen.

Die Auslagerung hätte zudem den Vorteil, dass man die Hilfe vor der Nase hat - bislang musste man dazu immer 2 Tabs aufmachen, einen um die Hilfe zu sehen, den anderen um sie anzuwenden.

Ich halte die Auslagerung und ihre sich dann bietende Möglichkeiten für extrem feundlich für die CMS - Benutzer.

**Und man muss auch ma sehen, dass ein Moduleschreiber sein Module völlig anders gestalten kann als andere, denn die Rahmenbedingungen sind eigentlich sehr freizügig.

Ehrlich gesagt, wenn ich erst OpenOffice öffnen müsste, um was zu dokumentieren baaah. Dann würde ich eher gar nicht mehr dokumentieren. Viel zu viel Aufwand. Außerdem wäre, da das Problem, wie will jemand die Dokumentation bearbeiten, wenn kleinere Korrekturen nötig sind und der Original Autor nicht mehr zur Verfügung steht.

Original Autor nicht mehr zur Verfügung steht.

Na das ist dopch einfachst zu lösen (seihe dev) der Autor liefert sein OpenOffice original mit.

HTML ist da einfacher  - welche Lösung da genommen wird ist doch eigentlich egal.