LangMan_XH (Languages Manager XH)

[olape]

So ist es gedacht. Steht auch so im TinyMCE-Plugin und so habe ich das auch beim CKeditor in der admin.php stehen:

Danke

LangMan_XH 1.0 beta3
enthält Ludwigs Sprachmenü.

Entweder im Template

Code: Select all

languagemenu()

durch

Code: Select all

langman_languagemenu()

ersetzen,
oder mal den Vorschlage auf GitHub testen.

https://github.com/cmsimple-xh/cmsimple ... e-template
Ist etwas unübersichtlich geworden, weil ich noch nachträglich Holgers Hinweis

BTW: den Typ würde ich, angelehnt an die TOC TPL-Funktion, besser "languagemenu" (also Einzahl, ohne "s") nennen.

nachgegangen bin. Ist alles nur per Browser gemacht, ich hoffe ich habe nix vergessen.

Ich habe mal Polyglott eine kleine Anpassunge spendiert, damit auch das per XH Konfiguration wählbar ist.

polyglott_with_patch.zip

[frase]

LangMan_XH 1.0 beta3
enthält Ludwigs Sprachmenü.

oder mal den Vorschlage auf GitHub testen.
https://github.com/olape-git/cmsimple-x ... e-template

Was soll man jetzt dazu sagen?

Nur das Plugin mit Aufruf-Änderung im Template:
Funktioniert und finde ich auch gut. Die Aufruf-Änderung wäre ein echter Bruch, unkomfortabel für "einfache" User - aber vielleicht gar nicht so schlimm?

https://github.com/olape-git/cmsimple-x ... e-template
Auch das scheint mir ganz gut.
Allerdings gibt es hier wieder zwei verschiedene Stellen für die Sprachverwaltung: CMS-Config und Plugin.
Und wenn LangMan nicht installiert ist, steht unter Sprache -> Menü nur -LEER- ein Dropdown ohne Optionen.

Ganz ehrlich:
Ich weiß nicht, was ich nun besser finden soll. Beide haben Vor- und Nachteile.

[olape]

Und wenn LangMan nicht installiert ist, steht unter Sprache -> Menü nur -LEER- ein Dropdown ohne Optionen.

Hm, das könnte man vielleicht noch öndern, so dass es wirklich nur ein leeres Eingabefeld wäre (wenn kein entsprechendes Plugin installiert ist).

Allerdings gibt es hier wieder zwei verschiedene Stellen für die Sprachverwaltung: CMS-Config und Plugin.

Man müsste es einmalig in der Konfiguration aktivieren, ja.

Die Aufruf-Änderung wäre ein echter Bruch, unkomfortabel für "einfache" User - aber vielleicht gar nicht so schlimm?

Aber genau das wolltest du ja mit allen Mitteln verhindern.

Ganz ehrlich:
Ich weiß nicht, was ich nun besser finden soll. Beide haben Vor- und Nachteile.

Eine andere Möglichkeit gibt es nicht.

Ich finde es gut so. Man installiert das Plugin, legt in der Konfiguration von XH fest, dass das Plugin für das Sprachmenü zuständig ist.
Alles andere läuft dann zukünftig über das Plugin.
Editor, Dateibrowser oder Pagemanager machen es doch auch nicht anders.

---------------------------------------------------------------------------------

Man könnte es automatisieren, aber dazu muss man erstens vorher wissen, welche Plugins es gibt (ein weiteres hinzufügen würde wieder eines CMS Updates bedürfen). Und zweitens Prioritäten festlegen.

Alternativ könnte man hier vielleicht auch XH_registerPluginType() einbeziehen.
Allerdings wird es dann problematisch, wenn mehere Plugins dafür installiert sind. Da man ja theoretisch vorher nicht weiß welche, könnte man nur das erste gewinnen lassen. Im Regelfall wird das alphabetisch sortiert ankommen.
Heißt, für die jetzige Situation mit LangMan und Polyglott würde sehr wahrscheinlich immer LangMan gewinnen, wenn beide installiert sind.

Ich weiß nicht. Ich denke darüber nach und mache einen Entwurf.

Mit dir hat man es aber auch nicht leicht.

[frase]

Mit dir hat man es aber auch nicht leicht.

Ja, das merke ich jeden Tag auf's Neue selbst.

Ich finde es gut so. Man installiert das Plugin, legt in der Konfiguration von XH fest, dass das Plugin für das Sprachmenü zuständig ist.
Alles andere läuft dann zukünftig über das Plugin.
Editor, Dateibrowser oder Pagemanager machen es doch auch nicht anders.

ja, das klingt gut.
Jetzt müsste sich das nochmal jemand anderes genauer anschauen und ein Urteil abgeben. Meine Erfahrung sagt: Die damit Befassten leiden oft unter einer gewissen Betriebsblindheit. Deshalb auch meine Unentschlossenheit.

[Holger]

Allerdings gibt es hier wieder zwei verschiedene Stellen für die Sprachverwaltung: CMS-Config und Plugin.
Und wenn LangMan nicht installiert ist, steht unter Sprache -> Menü nur -LEER- ein Dropdown ohne Optionen.

CMS-Config: Eintrag ausblenden, wenn ein passendes Plugin aktiv (also nicht nur installiert) ist. Das Plugin muss das selbst initiieren, denn die Option muss ja nicht in jeder Alternative enthalten sein. Und hier geht es dann wieder los: weil jeder Plugin-Autor machen kann was er will ist es die Frage, ob man wirklich die bisherigen Konfigurationspukte, auch noch abhängig von installierten Plugins, verschieben sollte.
Die Erklärungen zur Einstellung der Standardsprache werden dann wohl allgemeiner verfasst werden müssen:
"Das geht unter "Einstellungen -> Konfiguration -> Sprache". Aber wenn Du X installiert hast, dann dort... Oder, falls Y installiert ist, dann da..."

"Sprache -> Menü" könnte so bleiben. Müsste beim Editor auch so sein. Man könnte es aber auch mit "Standard", oder einem ähnlichen Eintrag vorbelegen.

Die Aufruf-Änderung wäre ein echter Bruch

Bruch? Na ja, eher übliche Vorgehensweise. Aber nicht komfortabel, das stimmt.

Ganz ehrlich:
Ich weiß nicht, was ich nun besser finden soll. Beide haben Vor- und Nachteile.

Die Antwort hast du doch schon gegeben:

Nach meiner Meinung sollten wir uns nichts ersparen, was es dem XH-User einfacher und übersichtlicher macht.

Jetzt auch von mir mal zusammengefasst:
ich finde es grundsätzlich gut, wenn möglichst viele Optionen als Plugin realisiert werden. Ich finde es auch gut, wenn alle zusammen gehörende Settings an einem Platz sind. Ich finde es aber nicht so gut, wenn Core-Einstellungen, abhängig von installierten Plugins, auf einmal an anderer Stelle zu finden sind.
Also warum nicht die erweiterten Einstellungen des Plugins in den Core-Dialog an der richtigen Stelle bei "Einstellungen -> Konfiguration -> Sprache" einschleusen?

Bei hi_Admin ist das zum Beispiel so, siehe "Templates" und "Stylesheet". Da war es aber auch relativ einfach den Aufruf abzufangen und eine andere Funktion auszuführen.

[Holger]

Ich finde es gut so. Man installiert das Plugin, legt in der Konfiguration von XH fest, dass das Plugin für das Sprachmenü zuständig ist.
Alles andere läuft dann zukünftig über das Plugin.
Editor, Dateibrowser oder Pagemanager machen es doch auch nicht anders.

Das ist nicht vergleichbar, denn Editor, Filebrowser und Pagemanager ändern keine Systemeinstellungen.

Und der nächste Kandidat wird dann vielleicht ein Mailform-Plugin, welches den Standard-Template-Tag verwenden möchte und dann wieder erweiterte Einstellungen mitbringt.

Denkt mal drüber nach. Wenn es um Dinge geht, die bisher in der Core-Konfiguration zu finden sind, wären alle Einstellungen an der Stelle schon klasse.

Alternative Idee für die Default-Sparache für LangMan: den Eintrag in der CMS-Konfiguration ausblenden und dafür einen Link zu LangMan ausgeben. Mit etwas JS sollte das machbar sein. Eine Krücke zwar, aber wenigstens keine zwei Stellen mehr...

[olape]

Alternativ könnte man hier vielleicht auch XH_registerPluginType() einbeziehen.
Allerdings wird es dann problematisch, wenn mehere Plugins dafür installiert sind. Da man ja theoretisch vorher nicht weiß welche, könnte man nur das erste gewinnen lassen. Im Regelfall wird das alphabetisch sortiert ankommen.
Heißt, für die jetzige Situation mit LangMan und Polyglott würde sehr wahrscheinlich immer LangMan gewinnen, wenn beide installiert sind.

Ich weiß nicht. Ich denke darüber nach und mache einen Entwurf.

https://github.com/olape-git/cmsimple-x ... 6b5b3103ad
Dazu müssen sich die Plugins wieder als languagemenu registrieren. LangMan tut es, Polyglott mit dem kleinen Patch (oben) auch.
Es gewinnt halt das erste. Ist LangMan installiert, kann man nicht das Sprachmenü von Polyglott nutzen, bzw. will man das, kann man LangMan nicht installieren.
Dafür braucht man nun aber sonst nichts mehr tun, ausser installieren.

[olape]

Also warum nicht die erweiterten Einstellungen des Plugins in den Core-Dialog an der richtigen Stelle bei "Einstellungen -> Konfiguration -> Sprache" einschleusen?

Es sind 4 einzelne Formulare. Extra so und gewollt, weil sich für nachfolgende die Ausgangslage ändert, wenn man bei vorhergehenden Änderungen macht. Ich glaube das lässt sich so in der Konfiguration von XH nicht umsetzen.

Alternative Idee für die Default-Sparache für LangMan: den Eintrag in der CMS-Konfiguration ausblenden und dafür einen Link zu LangMan ausgeben. Mit etwas JS sollte das machbar sein. Eine Krücke zwar, aber wenigstens keine zwei Stellen mehr...

Das scheint mir dagegen ein gute und zielführende Idee.

Und der nächste Kandidat wird dann vielleicht ein Mailform-Plugin, welches den Standard-Template-Tag verwenden möchte

Und ich fände das eigentlich sogar gut.
Aber du hast Recht, es darf kein Einstellungswirrwarr daraus entstehen.

[Holger]

Dazu müssen sich die Plugins wieder als languagemenu registrieren. LangMan tut es, Polyglott mit dem kleinen Patch (oben) auch.
Es gewinnt halt das erste. Ist LangMan installiert, kann man nicht das Sprachmenü von Polyglott nutzen, bzw. will man das, kann man LangMan nicht installieren.
Dafür braucht man nun aber sonst nichts mehr tun, ausser installieren.

Ungetestet, nur Code angeschaut: Das würde ich auf keinen Fall so machen. Das gibt nur Durcheinander. Belass' es besser bei der manuellen Auswahl im Core-Konfig-Dialog.

Es sind 4 einzelne Formulare. Extra so und gewollt, weil sich für nachfolgende die Ausgangslage ändert, wenn man bei vorhergehenden Änderungen macht. Ich glaube das lässt sich so in der Konfiguration von XH nicht umsetzen.

Das ginge schon. Irgendwie. Aber richtig, ohne explizite Core-Unterstützung für so etwas, bleibt es immer irgendwie ein "Hack".

Das scheint mir dagegen ein gute und zielführende Idee.

Nach Auswahl von LangMan und speichern würde dann der Konfigurationspunkt für die Auswahl der Standard-Sprache unsichtbar. Auch irgendwie "hackish", aber zumindest keine 2 Stellen für die gleiche Einstellung. Und außerdem wird durch den Link zur LangMan - Konfigurationsseite alles wieder etwas "durchgängiger" bedienbar. Langman könnte sich (vielleicht) dann sogar selbst im Plugin-Dropdown verstecken.

Und ich fände das eigentlich sogar gut.

Ja. Nichts dagegen. Im Gegenteil.

[olape]

Nach Auswahl von LangMan und speichern würde dann der Konfigurationspunkt für die Auswahl der Standard-Sprache unsichtbar.

Nicht ganz. Das muss eigentlich passieren, sobald LangMan installiert ist.
Die Auswahl in der Konfiguration betrifft ja nur das Sprachmenü, nicht die gesamte Funktion des Plugins.

Aber im Moment hänge ich schon beim Ansprechen der Einstellung per JS.
Ich hatte da <select name="PL3bbeec384_language_default"> im Auge.
Wobei ich noch nicht mal sicher bin, dass PL3bbeec384 immer und überall gleich ist.
Aber bei JS muss ich mir immer alles zusammensuchen. Dazu habe ich keinen Plan.