nicht angemeldet
moin tom,
da du hier nach programmiertechnik fragst, hoffe ich halbwegs nach deinem interesse zu antworten.
Es gibt ein Mastertemplate, in dem das ganze HTML-Geraffel und das CSS steht. An geeineten Stellen stehen Platzhalter, die dann je nach Sprache ersetzt werden müssen.
für den fall, dass du mit klassen arbeitest, würde ich einfach eine dataWrapper klasse schreiben. diese bildet intern eine instanz von languageChooser, woraufhin *in* dataAccess automatisch auf die passende datenhaltung zugegriffen wird. wo ist der gag:
- languageChooser durchsucht (nach prioritäten geordnet) SESSION, GET, COOKIE nach bestimmten feldern. wenn es dort einen verwertbaren hinweis findet, stellt es die sprache entsprechend ein, sonst gibt es die standardsprache zurück.
- dataWrapper stellt eine einheitliche schnittstelle für alle lese/schreib-operationen bereit. ausser dass es sich im aktuellen fall um die spracherkenung und folglich um die auswahl der richtigen tabelle/datei kümmert, kann es später auch mal temporär aus der session lesen, statt gleich immer aus einer datei oder ähnliche gimmicks. wichtig ist die einheitliche schnittstelle und dass du an den stellen, wo du liesst wirklich nur lesen musst - nichts entscheiden.
- generell erkennt man hier eine klare aufgabenteilung, welche sich in einer sehr komfortabem handhabung des leseobjektes darstellen sollte
Die Spracherkennung ist abgestuft:
Es gibt eine "Not"-Sprache für den absoluten Ausnahmefall, wahrscheinlich EN
Die aktuelle Sprache wird über $_SERVER["HTTP_ACCEPT_LANGUAGE"] vorausgewählt.
das pssiert bei meinem modell in languageChooser. was diese klasse evt. sonst noch durchsucht, sagst du dort.
Über die Session kann der Besucher aber trotzdem auf alle verfügbaren Versionen umschalten und diese dann für seinen Besuch beibehalten, oder sollte ich das in der URL als Paramter kennzeichnen?
finde auch url besser; ansonsten - egal. wird alles on languageChooser geregelt ;)
beste grüsse,
andi
Gunnar Bittersmann