Forum

[iceman-fx]

Hallo Leute,

ich würde gern einen kleines Sammelthema zur Umsetzung einer Mehrsprachigkeit hier eröffnen, da ich denke, dass es viele Einsteiger und vielleicht auch Fortgeschrittene interessant finden könnten.

Ich hoffe auf eine rege Teilnahme, vorallem auch von anderen Praxisleuten, die Ihre Erfahrungen hier mit einstellen.

Aus meiner Sicht habe ich bisher die folgenden Vor- und Nachteile bzgl. der Umsetzung einer Mehrsprachigkeit wie folgt aufgestellt:

Variante 1: Nutzung der internen Sprachfunktionalität mit gleicher Struktur in allen Sprachen

Vorteile:

Jeder Artikel kann sofort in allen verfügbaren Sprachen gepflegt werden.

Direktes Umschalten zwischen den Sprachen im Backend möglich.

Sprachbegrenzung möglich, wenn Rechte der Nutzer entsprechend gesetzt sind.

Direktes Umschalten auf Präsenz durch einfaches Hinzufügen des Attribute &clang=1 möglich.

Nachteile:

Struktur nicht separat pflegbar, weshalb alle Sprachen auch alle Kategorien und Artikel enthalten müssen.

Verlinkungen auf Seiten müssen zwingend das clang-Attribut enthalten, da ansonsten die default-Sprache angezeigt wird (gewählte Sprache wird nicht Systemweit gespeichert!!!)

Variante 2: Nutzung einer internen Sprache und Anlegen separater Strukturen je Sprache /de; /eng;…

Vorteile:

Struktur übersichtlicher, da nach Sprachen sortiert.

Individuelle Strukturen je Sprache möglich.

Verlinkungen müssen clang-Attribut nicht enthalten, da alles über Unterkategorien und Artikel-IDs läuft.

Jeder Artikel kann separat gelöscht werden je Sprache.

Googlemaps über alle Sprachen einfach machbar, da alles in Unterkategorien und Artikel-IDs angelegt ist.

Nachteile:

Pflege etwas aufwändiger, da keine direkte Umschaltung zwischen den Sprachen möglich ist.

Sprachbegrenzung nur über Kategorie möglich.

Innerhalb der Präsenz ist ein direktes Umschalten zwar möglich, aber nur sehr schwer bei Frame-basierten Präsenzen.

Mögliche Probleme mit der Ausgabe von Sitemaps, da diese die Root-Kategorie als Referenz benötigen (Start-Kategorie).

Suchmodul muss angepasst werden, um eine Beschränkung der Startebene (Kategorie) einfügen zu können.

Viele Grüße
iceman

[Merchenman]

Da kann ich mich mal schnell einschalten, da ich gerade eine 3-sprachige Seite bastel.

1. Das mit dem clang-Attribut sehe ich nicht wirklich als Problem, da es sehr einfach in die gesamten Module zu integrieren ist, und meistens schon vorhanden ist.

2. In Variante 2 ist ein Umschalten zwischen den Sprachen so gut wie unmöglich, man müsste immer die ArticleID der anderen Sprache suchen und separat einpflegen. Das sehe ich als absoluten Nachteil und klares Argument dafür, Variante 2 nicht zu benutzen. Bei Variante 1 muss hierfür nichts gemacht werden.

3. Die Struktur ist auch in Variante 1 einfach zu ändern in den unterschiedlichen Sprachen. Wenn eine Kategorie in einer Sprache nicht existiert kann man sie offline schalten, und die Sortieung der Kategorie oder Artikel ist in allen Sprachen separat. Daher sind auch in Variante 1 individuelle Strukturen möglich.

4. Artikel können zwar in Variante 1 nicht separat gelöscht werden, aber deaktiviert, das reicht im Normalfall auch.

5. Viele Module müssen mehrfach geschrieben werden um sie auf die spezielle Sprache zu begrenzen.


Im Endeffekt sind damit alle Nachteile von Variante 1 für mich erledigt genauso wie dir Vorteile von Variante 2 nicht wirklich Vorteile sind. Für mich kommt nur die Variante 1 in Frage, da das der Sinn eines CMS ist, das man eben nicht alles doppelt und dreifach machen muss, und dass normalerweise die Inhalte oder Strukturen in unterschiedlichen Sprachen gleich sein sollten.

Auf meiner Seite gibt es beispielsweise ein paar Artikel oder Kategorien die nicht in allen Sprachen verfügbar sind, aber sonst ist fast alles synchron.

[iceman-fx]

1. Das mit dem clang-Attribut sehe ich nicht wirklich als Problem, da es sehr einfach in die gesamten Module zu integrieren ist, und meistens schon vorhanden ist.

5. Viele Module müssen mehrfach geschrieben werden um sie auf die spezielle Sprache zu begrenzen.

Danke für deine schnelle und umfassende Antowrt aus der Praxis.
Könntest Du mir bitte die beiden obigen Punkte noch etwa genauer beschreiben?

zu1) Wie verhält es sich im Wysiwyg -> siehe dieses Thema: http://forum.redaxo.de/ftopic4951.html&highlight=

zu2) Wieso muss man die dann doppelt schreiben?

Gruß iceman

[Merchenman]

1. Ich benutzte kein Wysiwyg, sondern nur "Text und/oder Bild" also ein einfaches Textmodul. Bei mir sind alle Module und das gesamte CSS so eingestellt, dass ich nur noch den Text eingeben muss, so dass ich den Wysiwyg nicht benötige. Ausserdem erzeugen solche Wysiwyg-Editoren meistens irgendwelche Fehler. Sorry, also dazu kann ich nichts sagen. In meinem Modul funktioniert das ganze allerdings automatisch. Und ich habe das Modul dafür nicht speziell angepasst.

2. z.B. für die Sitemap musst du einen Startpunkt festlegen, der ist normalerweise in der Sitemap fest eingestellt als "RootCategorie". In deinem Fall brauchst du aber für jede Sprache eine andere ID. Also musst du entweder mehrere Module schreiben, wo du jeweils die StartID einträgst, was natürlich Quatsch ist, oder du ergänzt das Modul, dass du in jeder Sprache die StartID eintragen kannst.

Ich würde das ganz einfach mit der Sprachfunktion von Redaxo machen. Das ist definitiv das einfachste.

[redaxoist]

Also ich finde es auch genau so gut wie es jetzt ist - also Variante 1.
Ich habe in der Praxis bei einigen mehrsprachigen Webangeboten nie den Fall 2 gehabt.

Soll die Struktur einer anderen Sprachpräsenz tatsächlich extrem anders sein können ja zwei Redaxoinstallationen eingerichtet werden, was dann wirklich sinnvoller wäre.
Inhalte können dann mit eigenen Modulen od. Addons übertragen werden - also einfach eine SQL-Abfrage in die Datenbank des andersprachigen Redaxo.