LangMan_XH (Languages Manager XH)

[frase]

Allerdings gibt es mit der aktuellen Beta ein CSS-Problem mit dem Pagemanager. Der schaut jetzt etwas durcheinander aus

Schande über mich !

Da kann Olaf nichts dafür! Das ist meine Schuld.
Bei den @media-Anweisungen im Plugin-Stylesheet fehlen 3 schließende Klammern.
Es muss also heißen:

Code: Select all

@media only screen and (max-width: 980px) {
.lmxh_admin_logo {
    width: 150px;
    height: 150px;
}
}
@media only screen and (max-width: 640px) {
.lmxh_admin_logo {
    width: 100px;
    height: 100px;
}
}
@media only screen and (max-width: 380px) {
.lmxh_admin_logo {
    float: none;
    margin: 0;
    width: 100px;
    height: 100px;
}
}

[frase]

Auf jeden Fall eine wichtige Erweiterung IMHO.

Und ich finde dieses Plugin sogar so wichtig, dass es ab "sofort, unverzüglich" als Standard-Plugin zu XH gehören sollte.

Irgendwie ist Olaf zu bescheiden. Es fehlt mir noch irgendwo eine Beschreibung dessen, was LangMan_XH eigentlich alles kann.
Ich persönlich finde das "translate me!" und die automatische Anpassung der Bildpfade einfach super!
Vielleicht doch noch eine Hilfe-Seite?
Oder unter "Info"?

[frase]

Natürlich habe ich auch noch eine Kritik bzw. einen Gegenvorschlag zur Version 1.0 beta1 dev_f

"Noch mögliche Sprache(n)" → Hauptsprache setzen
Ich denke, dass das hier nicht hinpasst und auch etwas verwirrend ist.
Wählt man hier eine Sprache mit "Hauptsprache setzen", dann passiert nichts anderes, als dass die Hauptsprache in der CMS-Config geändert wird. Es wird kein Besipielcontent und auch keie Kopie eines anderen Contents angelegt. Das kann man auch nicht später nachholen.
Vielleicht wäre es besser diese Option als eigenständige Funktion ganz oben zu platzieren.
CMS-Hauptsprache setzen → Auswahlfeld aller verfügbaren Sprachen.
Dan wird es allerdings auch wieder komplizierter, weil man da auch Kopieren anbieten müsste. Und man müsste auch dafür sorgen, dass diese Sprache nicht gelöscht werden kann, solange sie Hauptsprache ist.
Vielleicht hat da jemand noch eine Idee?

Oder:
"Hauptsprache setzen" erscheint nur unter "Weitere eingerichtete Sprache(n)" als dritte Option im Auswahlfeld?
Damit gäbe es diese Sprache schon (mit Content) und man könnte sie als Hauptsprache aktivieren.

[lck]

LangMan_XH 1.0. beta1

Plugin Punkt "Sprachen verwalten"

Die Hauptsprache der Website
[...] (Ändern unter Einstellungen → Sprache → Voreinstellung)

Das ist nicht ganz richtig, sollte lauten

(Ändern unter Einstellungen → Konfiguration → Sprache → Voreinstellung)

BTW: Verschreiber bei eingestellet ... aktiverten ... deaktiverten

[olape]

Vielleicht doch noch eine Hilfe-Seite?
Oder unter "Info"?

Eigentlich wollte ich keine Hilfe dazu erstellen.
Aber die ganze Beschreibung in der Sprachdatei macht sich auch irgendwie bescheiden.

Bei den @media-Anweisungen im Plugin-Stylesheet fehlen 3 schließende Klammern.

Das ist nicht ganz richtig, sollte lauten

(Ändern unter Einstellungen → Konfiguration → Sprache → Voreinstellung)

BTW: Verschreiber bei eingestellet ... aktiverten ... deaktiverten

Es ist ja eine beta1. Also keine Panik.
Ich setze es auf todo.

Noch mögliche Sprache(n)" → Hauptsprache setzen
Ich denke, dass das hier nicht hinpasst und auch etwas verwirrend ist.

Ja, ich hätte es auch lieber gleich ganz oben positioniert. Aber da liegt der Hase im Pfeffer.
Positioniert. Ansonsten ist es da wo es ist genau richtig. Stand jetzt kann ich nur zulassen eine Sprache als default zu setzen, die es noch nirgendwo gibt. Ich weiss gar nicht, ob es unter den Systemeinstellungen funktioniert, eine bereits als Zweitsprache geführte Sprache trotzdem als Default zu setzen. Es wäre aber falsch. Ganz unten ist aber nun genau die Stelle, wo klar ist, welche Sprachen noch zur Verfügung stehen. Es sei denn, mal will das alles mehrfach abarbeiten.

Wählt man hier eine Sprache mit "Hauptsprache setzen", dann passiert nichts anderes, als dass die Hauptsprache in der CMS-Config geändert wird. Es wird kein Besipielcontent und auch keie Kopie eines anderen Contents angelegt. Das kann man auch nicht später nachholen.
Vielleicht wäre es besser diese Option als eigenständige Funktion ganz oben zu platzieren.
CMS-Hauptsprache setzen → Auswahlfeld aller verfügbaren Sprachen.
Dan wird es allerdings auch wieder komplizierter, weil man da auch Kopieren anbieten müsste. Und man müsste auch dafür sorgen, dass diese Sprache nicht gelöscht werden kann, solange sie Hauptsprache ist.
Vielleicht hat da jemand noch eine Idee?

Und ganz verrückt: Die Auswahl der Hauptsprache könnte/sollte das Plugin auch gleich noch mit übernehmen.

Zu diesem Punkt hatte ich eine Idee, die ich aber wieder verworfen habe.

Ich wollte eigentlich beim Wechsel der Defaultsprache die aktuelle Defaultsprache als Zweitsprache verschieben.
Aber, da ja auch Plugins ihre Daten in /content ablegen, und zwar einige sprachunabhängig direkt in /content/,
andere dagegen sprachabhängig in /content/ bzw. /content/xx/ und es gibt keine Möglichkeit sicher festzustellen, welche Plugindaten mit nach /content/xx/ verschoben werden müssten und welche weiterhin in /content/ verbleiben müssen,
--> verworfen.
Also keine wirkliche Möglichkeit außer eine Liste zu führen. und das macht eben keinen Sinn.

Es bleibt also die Idee einfach "hart" die Defaultsprache umzustellen wie es bisher auch in der CMS-Konfiguration ist.

Kleiner Nachtrag dazu
Hier wäre es tatsächlich ideal, wie letztens schon mal diskutiert, alle Sprachen in einem Unterordner von content zu haben. auch die Defaultsprache. Dann wäre das Problem mit einem Schlag gelöst.

[cmb]

Tut mir leid, ich habe es mehrfach gelesen, aber ich weiß nicht, wie ich damit umgehen soll, wenn ich doch nur die eine Position ändern will.
Ich habe mir eine Lösung von Holgers hi_admin "geklaut".

Das passt natürlich; v.a. das Speichern erzeugt die gewohnte Struktur. XH_includeVar() hatte ich übrigens ganz vergessen (wirklich viel Sinn macht diese Funktion aber nicht; das Locking sollte eigentlich vor dem Lesen beginnen, und erst nach dem Schreiben enden; aber das wird an anderen Stellen auch nicht gemacht).

Kleiner Vereinfachungsvorschlag: in op_lm_removeKeyFromArray() und op_lm_removeValueFromArray() musst du eigentlich nicht prüfen, ob das Array-Element existiert; unset() beschwert sich nicht, wenn man ein nicht existierendes Element angibt.

[olape]

Kleiner Vereinfachungsvorschlag: in op_lm_removeKeyFromArray() und op_lm_removeValueFromArray() musst du eigentlich nicht prüfen, ob das Array-Element existiert; unset() beschwert sich nicht, wenn man ein nicht existierendes Element angibt.

Ich merke es vor.

Nachtrag

Allerdings sehe ich gerade, bei op_lm_removeValueFromArray() habe ich array_search drin und das brauche ich, weil ich brauche die Rückgabe als Position im Array.

[olape]

LangMan_XH 1.0 beta2

[frase]

Der XH-Hosenband-Orden Erster Klasse für dich.

[olape]

Der XH-Hosenband-Orden Erster Klasse für dich.

schon angesteckt