Multilingual... Welcher Weg führt ins www?
Posted: Tue 13. Dec 2011, 22:18
Da das Thema im Moment an jeder Ecke hier im Forum auftaucht, und ich mich auch grad intensiv in eine Variante einarbeite, würde mich mal eure Meinung / Erfahrung zu den zwei Möglichkeiten interessieren.
Variante 1: Je Sprache ein eigenes Template / eigene Navi / eigener Kategorienbaum / duplizierter Content
Diese Art der Mehrsprachigkeit habe ich in der Vergangenheit benutzt. Bei sehr komplexen Seiten, bzw. Inhalt der in vielen einzelnen Contentparts aufgeteilt ist, ist die Pflege der Seite recht Mühsam und erfordert viel Genauigkeit, da man jede Änderung immer für jede Sprache erledigen muss. Auch leidet etwas die Übersichtlichkeit in der Kategorieansicht usw.
Vorteile: Zumindest habe ich recht einfach die Möglichkeit die Sprachversionen aufgrund der eigenen Kategorien und Templates individuell anzupassen.
Variante 2: Sprach-Tags + lang_replace.php in Frontend-Render
Die Variante baue ich grade in den Neuaufbau einer bestehenden Seite ein, die vorher mit Variante 1 programmiert war. Bis jetzt bin ich sehr begeistert wie simpel diese Variante zu handhaben ist. Ich nutze die NAV_HORIZ_DD in der die Sprach-Tags ebenfalls ohne Probleme funktionieren. (Ok, wenn man weiß, das die Reihenfolge der Abarbeitung der frontend-render scripts wichtig ist). Ein paar Baustellen wie Teaser & Suche sind leider noch im Core anzupassen damit das funzt, aber ein bischen "basteln" gehört ja immer dazu.
Gut finde ich auch, das der Shop in gleicher Weise funktioniert, obwohl er als Modul läuft. Wenn man Grundsätzlich Variante 1 verwendet, ist man beim Shop dennoch gezwungen hier mit den Sprachtags zu arbeiten. Also im Prinzip doppelt gemoppelt.
Bei Dingen, die nicht als Seite, also als html gerendert werden, und bei denen die frontend-render scripts nicht greifen bin ich noch nicht so tief vorgedrungen. Hier seien Newsletter, Formular und E-mail etc. zu nennen. Da werde ich erst noch Erfahrungen sammeln müssen.
Alles in allem bin ich aber von Variante zwei, also den Sprach Tags bis jetzt sehr überzeugt.
Ein Nachteil ist, dass man nicht ganz so flexibel mit der Gestaltung (ggfs. andere Bilder in verschiedenen Sprachversionen, Textpassagen oder ganze Artikel weglassen ohne den Kontext zu zerstören etc.)
Ich habe mir zum Beispiel einen kleinen Ersetzer gebastelt {NO_ENGLISH}, der an dieser Stelle einen englischen Hinweistext einblendet, das der gewünschte Inhalt nicht in der aktuellen Sprache zur Verfügung steht. Man muss also vom Konzept etwas anders herangehen, als wenn man mit zwei Sprachbäumen arbeitet.
Wie sind denn Eure Erfahrungen, bzw. welche Variante würdet ihr bevorzugen? Evtl. gibt es ja Dinge die sich eher Negativ auswirken. Z.b. ist der Seitenaufbau bei variante 2 bei "langsamen" Providern doch merklich behäbiger.
Viele Grüße
der Cip
Variante 1: Je Sprache ein eigenes Template / eigene Navi / eigener Kategorienbaum / duplizierter Content
Diese Art der Mehrsprachigkeit habe ich in der Vergangenheit benutzt. Bei sehr komplexen Seiten, bzw. Inhalt der in vielen einzelnen Contentparts aufgeteilt ist, ist die Pflege der Seite recht Mühsam und erfordert viel Genauigkeit, da man jede Änderung immer für jede Sprache erledigen muss. Auch leidet etwas die Übersichtlichkeit in der Kategorieansicht usw.
Vorteile: Zumindest habe ich recht einfach die Möglichkeit die Sprachversionen aufgrund der eigenen Kategorien und Templates individuell anzupassen.
Variante 2: Sprach-Tags + lang_replace.php in Frontend-Render
Die Variante baue ich grade in den Neuaufbau einer bestehenden Seite ein, die vorher mit Variante 1 programmiert war. Bis jetzt bin ich sehr begeistert wie simpel diese Variante zu handhaben ist. Ich nutze die NAV_HORIZ_DD in der die Sprach-Tags ebenfalls ohne Probleme funktionieren. (Ok, wenn man weiß, das die Reihenfolge der Abarbeitung der frontend-render scripts wichtig ist). Ein paar Baustellen wie Teaser & Suche sind leider noch im Core anzupassen damit das funzt, aber ein bischen "basteln" gehört ja immer dazu.
Gut finde ich auch, das der Shop in gleicher Weise funktioniert, obwohl er als Modul läuft. Wenn man Grundsätzlich Variante 1 verwendet, ist man beim Shop dennoch gezwungen hier mit den Sprachtags zu arbeiten. Also im Prinzip doppelt gemoppelt.
Bei Dingen, die nicht als Seite, also als html gerendert werden, und bei denen die frontend-render scripts nicht greifen bin ich noch nicht so tief vorgedrungen. Hier seien Newsletter, Formular und E-mail etc. zu nennen. Da werde ich erst noch Erfahrungen sammeln müssen.
Alles in allem bin ich aber von Variante zwei, also den Sprach Tags bis jetzt sehr überzeugt.
Ein Nachteil ist, dass man nicht ganz so flexibel mit der Gestaltung (ggfs. andere Bilder in verschiedenen Sprachversionen, Textpassagen oder ganze Artikel weglassen ohne den Kontext zu zerstören etc.)
Ich habe mir zum Beispiel einen kleinen Ersetzer gebastelt {NO_ENGLISH}, der an dieser Stelle einen englischen Hinweistext einblendet, das der gewünschte Inhalt nicht in der aktuellen Sprache zur Verfügung steht. Man muss also vom Konzept etwas anders herangehen, als wenn man mit zwei Sprachbäumen arbeitet.
Wie sind denn Eure Erfahrungen, bzw. welche Variante würdet ihr bevorzugen? Evtl. gibt es ja Dinge die sich eher Negativ auswirken. Z.b. ist der Seitenaufbau bei variante 2 bei "langsamen" Providern doch merklich behäbiger.
Viele Grüße
der Cip
