Multilingual... Welcher Weg führt ins www?

[Cipolla]

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

[Oliver Georgi]

Ich empfehle 1 Template für alle Sprachen, separate Seitenbäume je Sprache und passende Scripte, die korrekt verteilen, Beispiele gefällig:
http://www.kellpax.ch/, http://www.tkd-kabel.de/

Hier kommt ein Script zum Einsatz, dass auch über _de/_fr/_en im Alias versucht, den passenden Part auf der anderssprachigen Seite zu finden. Verlangt bei der Inhaltspflege ein wenig Disziplin, lohnt sich aber, da dann Sprachwechsel auf gleicher struktureller Ebene möglich ist, ohne auf der Home zu landen.

Alles was nicht inhaltsbasiert ist, löse ich über den @@Tag@@. Der nimmt alles auf und die Sprachdateien landen in template/template_lang. So sind alle Templates nur 1-mal zu pflegen. Am Ende kümmert man sich nur um die Übersetzung in den Sprachdateien.

[pepe]

Jetzt frage ich mich, wieso hat noch niemand nach dem geheimnisvollen Skript gefragt, welches die Verteilung organisiert.

Deshalb von mir die freundliche Bitte:

Lieber Oliver, dieses "Verteiler-Script" würde vielen von uns helfen... kann man das ggf. irgendwo "einsehen"?

[Oliver Georgi]

Lieber Oliver, dieses "Verteiler-Script" würde vielen von uns helfen... kann man das ggf. irgendwo "einsehen"?

Nein, einsehbar ist nur das Ergebnis. Die Beschreibung, was es tut, habe ich ja geliefert. Das Script wird nur projektbezogen weitergegeben.

Bezüglich Deines Nachfolgebeitrags und Link: den habe ich aus dem Forum genommen, da ich diese Themen nur direkt bespreche.

[pepe]

OK, da habe ich volles Verständnis für... aber mit deiner "Antwort" wird für mich schon einiges wesentlich KLARER

Danke

Was das Script angeht:
Irgendwo hab ich so was auch schon mal umgesetzt, hatte aber gedacht, eine wirklich "perfekte" Lösung würde eines Tages in phpwcms erscheinen... muss ich also noch mal nachgraben.

[Oliver Georgi]

Die perfekte Lösung, das ist Geschmacksache. Meine Lösung ist existent und funktioniert. Leider kann ich nicht alles kostenfrei abgeben, wofür andere bezahlt haben. Ohne Kostendeckung geht es nicht.

[pepe]

...Meine Lösung ist existent und funktioniert. Leider kann ich nicht alles kostenfrei abgeben, wofür andere bezahlt haben. Ohne Kostendeckung geht es nicht.

100% meine Meinung! Kein Grund also zur Entschuldigung... von "Irgendwas" muss man ja leben

[update]

double post

[update]

Hab mir das eben mal angeschaut:
/index.php?produkte_en für die englischsprachige Variante, hmmm....
Wäre da nicht /index.php?products_en besser? Und dann könnte man ja gleich diesen Appendix _en weglassen?

@Manfred: Dein Ansatz ist hier

[juergen]

der @@clou@@ ist 1 Template claus

[Oliver Georgi]

Ich arbeite ausschließlich mit einem einzigen Template, solange es um mehrsprachige, aber ansonsten vorlagenseitig gleichartige Sachen geht. Menüs dann dynamisiert über Frontend-Render in Kombination mit einem Sprachwechsel und entsprechend definiertem Einstiegspunkt.

Und auf eines muss man sich festlegen – das Matching erfolgt über den Aliasnamen und die Differenzierung der Sprache en_alias/de_alias oder alias_en/alias_de.

[update]

1 Template, schon klar. Und wenn es keine Entsprechung bei der anderen Sprache gibt? Aus landesspezifischen Gründen kann es ja manchmal sein, dass es eben kein Pendant gibt (oder eine dritte oder vierte usw. adäquate Entsprechung). Was dann?

[update]

Differenzierung der Sprache en_alias/de_alias oder alias_en/alias_de.

Eben das gefällt mir nicht.
Die Aliase sollten schon in der jeweiligen Sprache daherkommen

[update]

äääh - was ist denn eigentlich [siehe] ??

[pepe]