Sven Rautenberg: Mehrsprachigkeit

Beitrag lesen

Moin!

Alle Texte in den Seiten werden in Variablen abgelegt.
Es existiert für jede Sprache eine Datei, wo diese Variablen vorhanden sind (Vorzugsweise sind die Vars in einem array gekapselt, wegen der Übergabe an Funkionen)

Nachteil. Es muss wirklich alles generiert werden.

Ideal ist diese Vorgehensweise bei weitem nicht.

Mal so grundsätzlich überlegt: Wenn man eine zweisprachige Website anbietet, dann gibt es zwei Möglichkeiten.

1. Die Site wird nur teilweise übersetzt. Dann existieren nicht für alle Seiten der einen Sprache äquivalente Seiten der anderen Sprache - folglich ist es mit dem Umschalten auch blöd. Einfachste Methode hier: Zwei unabhängige Sites in zwei Verzeichnissen, mit Link auf die Startseite der jeweils anderen Sprache.

2. Die Site wird komplett 1:1 übersetzt.

In diesem zweiten Fall bleibt die Struktur der Site in jeder Sprache identisch. Das bedeutet, dass sich auf einer Seite zwei Klassen von Dingen ändern: 1. Die Navigationselemente, die auf jeder Seite der Sprache identisch auftreten und 2. der eigentliche Content.

Es spricht in meinen Augen absolut nichts dagegen, den Content _nicht_ in solche Sprachdateien zu würgen. :) Content ist in der Regel umfangreich, es wäre recht sinnlos, ihn in einer einzigen, umfangreichen Datei zu verwalten. Viel besser geeignet ist da der Ansatz, ihn in jeweils separaten Dateien zu halten, oder in einer Datenbank.

Was die Navigationselemente angeht: Die sind eigentlich ja Bestandteil des den Content umgebenden Templates. Es spricht in meinen Augen auch hier nichts dagegen, ein Template je Sprache anzulegen, welches dann spezifische Sprachinhalte enthält. Ein dahinterliegendes Framework fasst dann Template und Content zusammen und gibt die Seite aus.

Man _kann_ an dieser Stelle vieles vereinfachen, wenn man die zur Verfügung stehenden Optionen sinnvoll einsetzt. Beispielsweise wäre es möglich, mit mod_rewrite das gesamte URL-Gebilde, welches der Client hinter /de/ oder /en/ (oder /fr/) sieht, auf / zu mappen. Weiter könnte statt / auch /index.php angesprochen werden und entsprechend der gewünschten URL aus einem Verzeichnisbaum die gewünschte Sprachdatei für den Content holen, sie mit dem passenden Sprachtemplate zusammenwürfeln und dann ausliefern, ohne dass die beteiligten Dateien auch nur irgendetwas mit den in der URL genannten Ressourcen zu tun gehabt hätten. Selbstverständlich ließe sich das auch mit einer Datenbank regeln.

- Sven Rautenberg

--
ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:|