Sven Rautenberg: mehrsprachiges PHP Projekt

Beitrag lesen

Moin!

Ich habe schon div. Seite im Web abgeklappert und bin etwas unsicher, welches die optimale Lösung für mehrsprachige Projekte ist.

Ich denke nicht, dass es "DIE" optimale Lösung überhaupt gibt.

  • Sprachelemente in einer DB

Wäre ohne DB schwierig zu bewerkstelligen (um mal einen Grund zu nennen, warum das nicht alle so machen). :)

  • Sparchelemente per Variable und include einbinden

Wenn man 100 KB Sprachelemente einbinden muß, um ein 1KB-Skript starten zu können, ist irgendwas am Verhältnis Nutzen/Aufwand falsch.

  • Sprachelemente in einem Array

Wo kommt das her?

  • gettext

Wenn man das einsetzen kann, gehts vielleicht, aber es ist irgendwie für Webprojekte ein eher ungewöhnlicher Ansatz, würde ich meinen.

Was für Lösungsansätze oder Links könnt ihr mir emfpehlen.

Ich habe schon die eine oder andere mehrsprachige Website entwickeln dürfen - ich kann aber trotzdem noch immer nicht eindeutig sagen, was da jetzt tatsächlich am besten ist. Es hängt, würde ich meinen, von diversen Faktoren, und letztendlich auch von deiner Laune und Kenntnissen bezüglich der diversen Möglichkeiten ab.

Um dir mal Denkansätze zu geben: Geht's nur um eine mehrsprachige Website, oder auch um eine mehrsprachige PHP-Applikation? Welche Art von Templates verwendest du? Ist es mit denen aufwendiger, je Sprachversion einen kompletten Satz einsprachiger Templates zu verwenden, oder ist es schlauer, z.B. mit gettext alle Texte EINES Template-Satzes zu lokalisieren, und dann mit weiterem Inhalt aus der Datenbank aufzufüllen?

Wenn ich an die Aufgabenstellung "Eine mehrsprachige Website - Erstellungssoftware aber nur einsprachig" denke, dann halte ich es für wenig sinnvoll, den Content irgendwie kompliziert in Include-Files zu verpacken, welche immer den gesamten Site-Inhalt enthalten, von dem aber nur ein kleiner Ausschnitt jeweils benötigt wird. Content ist ja in der Regel auf jeder Seite komplett anders (es sei denn, man möchte sich immer wiederholen), also ergeben sich auch keinerlei Komprimierungseffekte, indem ein an mehreren Stellen auftretender Text durch genau EIN Arrayelement ausgegeben werden kann.

gettext hingegen kann ich mir irgendwie bei PHP-Applikationen wesentlich besser vorstellen. Denn sofern die nicht template-basiert sind (und gewisse Dinge wären für sowas einfach zu aufwendig), hat man das Problem, bei Sprachänderungen am Programmcode rumändern zu müssen. Da ist es wahrscheinlich schlauer, Button-, Menü- und Dialogtexte mit gettext verwalten zu lassen - wenn ich richtig informiert bin, unterstützt gettext dann die Extraktion und Übersetzung der auf diese Weise ausgegebenen Texte, und das ist ja auch nicht unbedingt schlecht. Ich denke nur, gettext ist für sich häufig ändernde Inhalte eher ungeeignet. Ich habe aber damit noch nie gearbeitet, kann also keine Praxiserfahrungen beisteuern.

Unter dem Strich würde ich sagen: Wenn's darum geht, Site-Inhalte, die von Redakteuren gepflegt und potentiell regelmäßig geändert werden, zu speichern, ist eine Datenbank oder auch ein Konstrukt aus Flatfiles (jeder Seiteninhalt in eine Datei) durchaus nicht falsch.

Die Texte der eigentlichen Applikation sind in der Regel eher kurz und lassen sich wahrscheinlich ganz gut mit gettext oder einer Arraylösung behandeln, wobei gettext vielleicht programmiererfreundlicher ist - das solltest du mal ausprobieren.

Der Einsatz von Templates ist in jedem Fall zu empfehlen. Damit kannst du dir eventuell die Geschichte mit den Arrays oder gettext sparen, indem du je Sprache ein eigenes Templateset anlegst, aber das erfordert von den Übersetzern (sofern du das nicht selbst machen mußt) natürlich Kenntnisse in der Templatesprache. Mit gettext werden sie aus diesen verwirrenden Konstrukten nämlich draußen gehalten.

Ach ja: Noch ein wichtiger Punkt, den du dir überlegen solltest: Zeichencodierung. Verschiedene Sprachen haben mitunter die unangenehme Eigenschaft, Zeichen zu verwenden, die im klassischen 7-Bit-ASCII nicht enthalten sind. In Europa dürfte das bekannteste Zeichen, was in diesem Zusammenhang Ärger verursachen dürfte, das Eurozeichen sein. Denn es kommt in der klassischen Zeichencodierung ISO-8859-1 nicht vor, kann dementsprechend auch nicht nativ in HTML eingebaut werden (das muß man dann als Entity lösen - aber das wäre vermutlich noch hinzukriegen) - es kann aber auch nicht von Formularen gesendet werden. Die Browser denken sich da die abenteuerlichsten Dinge aus.

Es ist also eventuell nicht verkehrt, wenn du dich mit UTF-8 bzw. Unicode im Allgemeinen beschäftigst. Ich habe dazu in diesem Jahr hier im Forum schon etliche Beiträge geschrieben, die, wenn ich die Rückmeldungen richtig interpretiere, offenbar schon bei einigen Leuten Licht in die Sache gebracht haben. So schrecklich ist UTF-8 nämlich gar nicht - man sollte nur ungefähr wissen, was man da tut. :) Die Archivsuche weiß mehr.

- Sven Rautenberg