[php] Mehrsprachigkeit mit Smarty

[Lutz Zetzsche]

Hi Andreas,

Am Mittwoch, 21. Dezember 2005 22:41 schrieb Andreas Brandl:
> Lutz Zetzsche schrieb:
> > also meiner Meinung nach hat Mehrsprachigkeit in dem Sinne eigentlich
> > nichts mit den Templates zu tun, sofern man davon ausgeht, daß es um eine
> > 1:1-Übersetzung ohne Spezifika bei einzelnen Sprachen geht.
> >
> > Von daher ist hier sicherlich nicht beim Template-System - in Deinem Fall
> > Smarty - anzusetzen, sondern bereits vorher in der Programmlogik. Hier
> > müssen an Hand der übergebenen Sprache schon die richtigen Texte gezogen
> > werden.
>
> OK - setzt du dann im Template Variablen für jeden einzelnen Text (bzw.
> Textbaustein)? Machts im Template schon verdammt unübersichtlich, oder?

nein, überhaupt nicht. Die Templates wissen gar nichts von den Sprachen. Sie 
sehen genauso aus, als ob sie nur eine Sprache behandeln würden. Schon in der 
Programmlogik werden die richtigen Texte mittels des übergebenen 
Sprachparameters gezogen.

Du mußt Dir das so vorstellen, daß die Texte z.B. in der Datenbank oder 
einzubindenen Textdateien so abgelegt sind:

a) Datenbank-Tabelle:
    ID, Sprache, Text
    1, "de", "Ich bin ein toller Text"
    1, "en", "I am a great text"

b) Textdateien:
    texte_de.inc: $text_inc = "Ich bin auch ein toller Text";
    texte_en.inc: $text_inc = "I am a great text also";

Dann gehst Du in der Programmlogik hin und holst die Texte so:

a) $text_db = $oTabelleText->holeText(1, $sprache);
b) require_once('texte_'.$language.'.inc');

Bei den Texten kannst Du natürlich auch so vorgehen, daß Du mit einer 
Übersetzungstabelle arbeitest:

Tabelle TextQuellsprache:
     ID, Sprache, Text
     1, de, "Ich bin ein toller Text"

Tabelle TextUebersetzungen:
     ID, Sprache, Text, Uebersetzung
     1, en, "Ich bin ein toller Text", "I am a great text also"

Diese Lösung ist weniger abstrakt und lesbarer, dafür produziert sie aber 
größere Datenmengen und verkompliziert andere Dinge (Pflegbarkeit, 
Sprachwechsel).

Welche Lösung Du brauchst, hängt auch davon ab, wie Du die Daten ziehen 
kannst. Wenn Du im Skript sagst, ich habe den und den Text und hierzu brauche 
ich die und die Übersetzung, arbeitest Du besser mit der Übersetzungstabelle. 
Holt das Skript die Daten generisch, ohne den Inhalt der Texte näher zu 
kennen und kennen zu müssen, dann wählst Du besser die erste Variante.

Die erste Variante - also nicht der Weg über im Skript hartkodierte Texte mit 
einer Übersetzungstabelle - ist programmiertechnisch und pflegemäßig deutlich 
eleganter. Stell Dir mal vor, Du hast einen Text an vielen Stellen Deiner 
Anwendung drin, à la $text_db = $oTabelleUebersetzung->holeUebersetzung('Ich 
bin ein toller Text', $sprache);, und Du änderst mal diesen Text. Dann mußt 
Du ihn überall und in der Datenbank ändern. Auch Sprachwechsel direkt auf 
Seitenebene arbeiten deutlich besser, wenn man IDs verwendet!

Ich denke, es wird deutlich, daß das Template auf diese Weise auf jeden Fall 
überhaupt nichts von den Sprachen mitbekommt. Es kriegt in dem Beispiel mit 
den Variablen $text_db und $text_inc direkt die passenden, sprachspezifischen 
Inhalte serviert. Das man dem Template auch das Sprachkürzel übergibt, damit 
es z.B. die aktuell ausgewählte Sprache hervorheben kann, bleibt dabei 
unbenommen. Das gehört ja dann wieder zur Ausgabe-/Präsentationslogik.


> Ich ziehe momentan überhaupt keine Texte aus der Programmlogik in die
> Ausgabe. Hab wie gesagt alle Texte (/Ausgabe) in den Templates drin...

Das ist aus meiner Sicht ein Designfehler. :-) Texte gehören nicht ins 
Template, allenfalls mit Ausnahme von sprachneutralen Elementen wie "(c) 
2005, Fred Mustermann". Die Mehrsprachigkeit gehört schon vor dem Template 
geregelt. Das Templatesystem sollte ausschließlich für die Präsentation, 
inklusive Ausgabelogik, zuständig sein. Hierzu zählt die Mehrsprachigkeit 
nach meiner Meinung nicht. Selbst die Formatierung von Zahlen- und 
Datumsangaben würde ich schon vorher regeln. :-)

Ich weiß, daß Smarty hierfür Formatierungsunktionen anbietet, aber aus meiner 
Sicht ist da in der Anwendung etwas vom Ansatz her falsch, wenn man im 
Template auf solche Funktionen zurücgreifen muß. :-) Wenn das nötig ist, dann 
ist die Anwendung nicht richtig internationalisiert.


Viele Grüße
Lutz