
Möchte man eine mehrsprachige Website mit MODx (dem bekanntermaßen besten CMS der Welt) umsetzen, geht das ganz einfach mit mehreren Kontexten – das hatten wir schon mal besprochen. In jenem Artikel habe ich auch ein Snippet gezeigt, das Inhalt je nach gewähltem Kontext ausgibt. Das ist besonders praktisch, wenn man gewisse Chunks oder Snippets je nach Kontext unterschiedlich einbinden möchte, doch auch wenn man einfach nur eine kleine Zeichenkette in z.B. einem Template übersetzen möchte, kann man dieses Snippet verwenden. Im Sinne des Erfinders ist das freilich nicht, denn mit dem sogenannten Lexikon und einem entsprechenden Template-Tag hat MODx bereits ein sehr fähiges Übersetzungstool an Bord.
Legt man einen neuen Kontext an, so verpasst man diesem in seinen Einstellungen sinnvollerweise einen sogenannten Culture Key, der die Sprache des Kontexts festlegt; man legt zum Beispiel für den Kontext für die englische Seite eine neue Einstellung namens cultureKey
an, trägt als Wert en
ein und schon ist der Kontext als englischsprachig markiert. Das sollte man eigentlich immer machen, doch für die Verwendung des Lexikons und seiner Übersetzerfähigkeiten, ist ein ordnungsgemäßer Culture Key Voraussetzung. Die Kontext-Einstellungen findet man unter System → Kontexte.
Das Lexikon ist eine Sammlung von Zeichenketten, zu finden unter System → Lexikon-Verwaltung. Diese Zeichenketten sind Name-Wert-Paare und sind nach Namensräumen getrennt, damit es zum Beispiel keine Kollisionen zwischen den Zeichenketten für den MODx-Manager und denen für die verschiedenen Plugins und Snippets gibt. Außerdem gibt es noch als Unterscheidungsmerkmal ein Thema und – für uns interessant – Sprache! Es ist uns also möglich, unter dem gleiche Schlüssel im gleichen Namensraum mehrere Zeichenketten anzulegen und diese nur anhand der Sprache zu trennen. Möchte man zum Beispiel erreichen, dass im Template einer Seite ein Text im deutschen Kontext als „Allgemeine Geschäftsbedingungen“ und im englischen als „Terms & Conditions“ auftaucht, legt man einfach zwei entsprechende Zeichenketten unter dem gleichen Schlüssel an; einmal für deutsch, einmal für englisch.

Auf diesem Screenshot wird also gerade der der englische Text „Terms & Conditions“ unter dem Schlüssel agb_text
für die englische Sprache eingetragen. Es ist sinnvoll, vorher einen eigenen Namensraum anzulegen (System → Namensräume). Hat man den deutschen wie auch den englischen Text unter dem gleichen Schlüssel eingetragen, ist es ein leichtes diesem in einem Template oder Chunk zu verwenden:
<p>
Sonstiges HTML
<br>
agb_text
<br>
Sonstiges HTML
</p>
Der -Tag erlaubt den praktischen Direktzugriff auf das Lexikon, so dass man nur den Schlüssel unserer Einträge,
agb_text
anzugeben braucht und als Parameter den Namespace übergibt, aus dem die Zeichenketten zu beziehen sind. Falls man auch ein Thema verwendet, so kann man dieses über den Parameter &topic=`meinThema`
angeben und falls man es mal gezielt auf eine bestimmte Sprache abgesehen hat, geht dies mit &language=`en`
.
Der Schlüssel zur erfolgreichen Übersetzung ist, dass die vom Kontext vorgegebenen Standardwerte benutzt werden, wenn man Parameter auslässt! So erbt beim gezeigten Beispiel der language
-Parameter seinen Wert von der Culture-Key-Einstellung unseres Kontexts und für topic
gilt default
, was der systemweiten Standardeinstellung entspricht. Und wir haben uns eine bequeme Möglichkeit geschaffen, einzelne Zeichenketten in Templates und Chunks zu übersetzen. Culture Key für Kontexte eintragen, einen Namensraum anlegen, Lexikon-Einträge schreiben, -Tag verwenden, fertig! Auch in Snippet-Code kann man das Lexikon natürlich nutzen – wie das geht, erklärt die MODx-Dokumentation.
Kommentare (9)
Andi ¶
4. März 2011, 22:09 Uhr
Technisch mag es vielleicht das beste sein, aber die heiß erwartete Revolution-Version dümpelt nur so vor sich hin, eine große Community oder Entwicklergemeinde gibt es nicht.
Das CMS klingt wahnsinnig spannend, aber die o.g. Probleme halten mich davon ab, besonders viel Zeit in die Einarbeitung zu stecken.
Marc ¶
5. März 2011, 14:47 Uhr
Und du weißt wovon du redest... weil:
Peter ¶
6. März 2011, 10:17 Uhr
Wie kommst du auf die Idee, es gäbe keine Community? Und selbst wenn es so wäre, warum sollte dich das aufhalten?
Bubka ¶
6. März 2011, 10:27 Uhr
Das CMS ist der völlige Käse. Mir ist schleierhaft was jemandem passiert sein muss um zu so einer Aussage zu kommen. Vorher mit Frontpage gearbeitet oder Dreamweaver?
Florian ¶
6. März 2011, 11:47 Uhr
MODX ist ein gut skaliertes, funktionierendes System mit einer mutmaßlich existenten Community.
Es teilt sich aber mit den anderen großen (Open-Source-)Systemen - bspw. TYPO3, Joomla, Drupal - ein Problem: es ist so komplex, dass die Einarbeitung keinen Spaß macht.
Sowohl dem Entwickler - WTF? Was ist der Unterschied zwischen Chunk, Context und Culture Key? Gibt's da was von Ratiopharm?? Bzw. war das nicht ne Band in den 80ern?? - als auch dem Endbenutzer.
Eins von beiden - die Kenntnis durch den Entwickler oder den Endbenutzer - ist sicher entbehrlich, wenigstens eins wird aber schon benötigt.
Naja, das Argument für mich: ich komme immer eher zu der Erkenntnis, dass es dem Endbenutzer merkwürdig vorkommt, wenn ich ihm die Bedienung seines "neuen Bling-Bling-CMS" zeige und dabei 40% des Systems mit dem Satz "Das können Sie ignorieren, brauchen Sie nicht" erkläre.
Kurzum: Zu Komplex. Speziell MODX sogar so sehr, dass ich selbst keine Lust dazu hab'.
Peter ¶
6. März 2011, 12:41 Uhr
Zitat Florian:
Entwickler und Endbenutzer finden in der ziemlich guten (und ständig wachsenden) Dokumentation Antworten auf alle Fragen. Der große Pluspunkt von MODx ist eigentlich gerade, dass es relativ wenige Grundprinzipien (Templates, Chunks, Snippets) gibt, die man kennen muss um erfolgreich eine Seite in die Welt zu setzen. Kontexte, Module, xPDO und Konsorten sind auch da, aber die braucht man nur, wenn man komplexere Sachen anschieben will.
Warum schaltest du für den Benutzeraccount deines Endkunden nicht einfach all diese überflüssigen Funktionen aus? Guckst du hier und hier. Ich mache das eigentlich immer, auch bei anderen Content Management Systemen.
MODx ist komplex, aber da es einer klaren Struktur folgt, ist es für mich zum Beispiel einfacher zu durchschauen als WordPress.
Matthias Mees ¶
6. März 2011, 13:28 Uhr
Als noch recht frischgebackener MODx-Fan kann ich sagen: Der gesamte Bereich Security/ACLs ist schon etwas abschreckend, wenn man simpler gestrickte Systeme gewöhnt ist. Ebenso ist es naturgemäß auch etwas verwirrend, dass viele Dinge, die in nahezu jedem anderen CMS gleich bezeichnet sind, in MODx einfach anders heißen -- etwa Snippets oder Chunks.
Andererseits kann ich Peter nur beipflichten: Die einfache Durchschnittsseite hat man mit MODx flott aufgesetzt, wenn man die grundsätzliche Terminologie einmal kapiert hat, und zwar -- und das ist für mich ganz individuell der Riesenbonuspunkt dieses Systems -- von Anfang an mit den Werkzeugen und so, wie man es umsetzen möchte, ohne zunächst tagelang Default-Templates umzubiegen und ein vorgegebenes JS-Framework zu durchschauen. (Spätestens jetzt merkt man, dass ich nur Revo kenne.)
Die Dokumentation ist stellenweise so komplex wie das System, aber wenn ich so bedenke, dass ich in mehreren Wochen Beschäftigung und Rumspielen mit MODx bislang genau eine Frage in einem Forum stellen musste und ansonsten alles selbst herausfinden konnte (noch dazu als bekennender Nicht-Coder), dann kann sie so schlecht nicht sein. :-)
Florian ¶
6. März 2011, 13:52 Uhr
Dass der "ManagerManager" (lt. Google-Suche mit Revo) ins Standard-Repertoire von MODX gewandert ist, wusste ich nicht. Punkt pro MODX.
Dass ich mich nachwievor damit nicht auskenne und mich erstmal damit beschäftigen müsste und alles "ab der Installation" richtig langsam finde - andere CMS sind da durchaus noch langsamer, nichts für Ungut! :) - könnte dem Umstand geschuldet sein, dass ich im Grunde ausschließlich "Coder" bin.
Und da bin ich schon gleich beim nächsten Problem: die Dokumentation.
Auch das macht MODX - soweit ich das gesehen habe - durchaus besser als einige Mitbewerber. Das ändert aber nichts daran, dass die Dokumentation mich nicht anspricht (weil sie einerseits mit mir ungeläufigen Begriffen um sich wirft und ich sie andererseits als viel zu flach empfinde -- "Coder" halt) und auch für Endbenutzer tendenziell ungeeignet ist.
Benutzerfreundlichkeit muss, gerade beim Backend, oberstes Ziel sein.
Die Erwartung erfüllt MODX, wenn auch besser als andere Systeme, m.E. nicht.
Solange sich daran nichts ändert ist es für mich nur wenig sinnvoll, mich in dieser Richtung schlau zu machen.
Fazit: ich bin MODX gegenüber nicht negativ eingestellt, die Damen und Herren Entwickler, ..., leisten da gute Arbeit und ich meine ernsthaft, dass sich viele Webworker dorthin orientieren sollten. Trotzdem ist dieses System für mich nichts und ich halte mich lieber an - zugegebenermaßen für den Endbenutzer nicht gerade günstigere - individuelle Lösungen.
Ich möchte und kann nicht ausschließen, dass es vielleicht MODX ist, dass diese Erwartung eines Tages erfüllt. Bis dahin begnüge ich mich mit dem Mitlesen und der - bei mir regelmäßigen, ca. jährlichen - Probe-Installation.
Florian ¶
8. März 2011, 14:51 Uhr
Ich hab' zwei Tage drüber nachgedacht.
Ergebnis: den Satz "bestes CMS der Welt" kann ich so unterschreiben. Ich halte MODx nicht für herausragend und auch immernoch nicht für ein Allheilmittel - für meine Zwecke ist es nachwievor ungeeignet -, gegenüber anderen Systemen ist es aber relativ gut.
Die Typologie - "Template", "Chunk", "Snippet", ... - hab' ich jetzt mal nachgeschlagen. Find' ich in weiten Teilen einleuchtend und geb' mir Mühe, die Begriffe zukünftig in meinen Projekten zu verwenden.
Wenn das so weiter geht, wird MODx 3 "Insurrection" ;) ja interessant.