#1
| ||||
| ||||
Internationalisierung in PHP-SkriptenIch bin bei der Programmierung einer PHP-Software kurz vor dem Punkt, an dem ich Unterstüzung für Mehrsprachigkeit einfügen will. Nun stellt sich für mich die Frage, wie ich das am besten um setzen kann. PHP bietet ja bereits von Haus aus eine Erweiterung für sowas, diese ist allerdings nicht auf jedem Webserver verfügbar. Erfahrungen habe ich mit dieser Erweiterung nur durch Wordpress, dort habe ich bei einer lokalen Installation die deutsche Sprachdatei installiert und musste feststellen, dass WP um einiges langsamer wurde. Allerdings verwendet WP auch nciht die gettext-Funktionen des Servers, sondern eine in PHP geschriebene Klasse dafür. Ein weiteres Minus ist, dass man extra mit zwei speziellen Dateiformaten zu kämpfen hat, um Übersetzungen zu schaffen (.po und .mo). po-Dateien müssen erst mit einem speziellen Programm zu mo-Dateien kompiliert werden. Dann gibt es noch die Möglichkeit, es so zu machen, wie z.B. das vBulletin, welches die einzelnen Sätze in PHP-Variablennamenkonventionen umwandelt und diese in der Datenbank speichert. 'A very cool hat, Mr. Brown!' würde dann beispielsweise per $phrase[a_very_cool_hat_mr_brown] im Template landen. Ich verwende Smarty, daher würde ich statt einer Variable lieber eine kleine Erweiterung zum einfügen des Textbausteins verwenden. Ich habe das Gefühl, dass diese Methode schneller ist, Nachteil ist allerdings, dass man vorher deklarieren muss, welche Phrasen man braucht, um nciht unzählige Datenbankabfragen zu bekommen. Dies im Quelltext des PHP-Skriptes zu machen, halte ich persönlich für unsauber, schließlich sollen Ausgabe und Programmlogik möglichst getrennt sein, das ließe sich allerdings auch mit einer weiteren Template-Erweiterung lösen. Größtzes Problem ist allerdings, dass das Skript ohne Sprachdateit keine allzugut lesbare Sprachausgabe erzeugen kann, außerdem gerät diese Methode bei manchen exotischen Sprachen vielleicht an ihre Grenzen. Wer hat Erfahrungen damit und kann mir Empfehlungen geben? Wäre es ein großer Nachteil, die Phrasen in den Templates selbst in Deutsch zu deklarieren und per Sprachdatei ins Englische zu übersetzen? Ich berfürchte, dass man hiermit viele englischsprachige Nutzer abschrecken könnte. __________________ Fabian Michael "Ein Tag, an dem du nicht lächelst, ist ein verlorener Tag." - Charlie Chaplin Wiki |
#3
| |||
| |||
Ich hab hier vielleicht einen Denkanstoss für dich, die Logik von diesem System finde ich eigentlich sogar sehr gut, vor allem aber auch Resourcen schonend, denn das ganze wird ja komplett abgespeichert.. http://www.php-resource.de/forum/sho...threadid=46917 |
#4
| |||
| |||
Hallo, also das phpBB macht es so, dass es zwei komplett verschiedene Templates dafür gibt. Das vb/wBB machen es dies mit den Variablen. Sprich: <b>$lng['hello']</b> $username Dabei ist $lng['hello'] die Begrüßung, z.B. "Hallo", oder "Moin". Dann wird dieses Template gecachte, sprich die Sprachvariablen werden übersetzt, in z.B.: <b>Tag</b> $username Dieses Template wird dann, wenn es benötigt wird, an den Compiler gesendet, und dieser speichert das Ergebnis im Cache Ordner. Aus dem Cache-Ordner wird es einfach per include() geladen. Im Cache könnte es so aussehen: <b>Tag</b> <?php echo $this->variable['username']; ?> Wenn man jetzt für $lng jetzt ein anderes Sprachpaket wählt, so wird wieder auf das Ur-Template zugegriffen: <b>$lng['hello']</b> $username Dies wird wieder gecacht, und dann wird daraus evt: <b>Hello</b> $username Das wird wenn es benötigt wird an den Complier gesendet... Ich hoffe man kanns verstehen |
#5
| ||||
| ||||
Danke für eure Inspirationen. Meine Lösung sieht nun folgendermaßen aus: Alle Phrasen werden in Sprachdateien gespeichert, die nach folgendem Schema aufgebaut sind: PHP-Code: Code: {phrase id="tidbits_administration"} Code: <div id="welcomebox">{phrase id="welcome_x" username=$tb_user->username|htmlspecialchars}</div> Die Sprachdatei muss also nur geladen werden, wenn Templates kompiliert werden. Durch setzen der Smaty-Variable $compile_id bekommt jede Sprache ihr eigenes kompiliertes Template. Einziges Problem für meine Software ist bislang, dass es Meldungen gibt, welche z.B. bei Formularüberprüfungen aus PHP heraus generiert werden. Diese Meldungen würden es doch ziemlich oft nötig machen, die Sprachdatei zu laden, um diese Meldungen zu übersetzen, da es aus dem Template heraus kaum möglich ist, diese Meldungen vorhersehen zu können. Vielleicht wäre es sinnvoll, für jede Sprache zwei Dateien zu benutzen, eine für statische und eine für dynamische Sprach-Variablen oder beides in eine Datei zu schreiben und einfach in zwei Arrays zu speichern, von denen das mit den dynamischen Variablen beim Kompilieren in den Template-Header geschrieben wird. Damit spart man sich ein weiteres include() und benötigt trotzdem nur eine Datei pro Sprache. __________________ Fabian Michael "Ein Tag, an dem du nicht lächelst, ist ein verlorener Tag." - Charlie Chaplin Wiki |
#6
| ||||
| ||||
Hm, die Idee, Templates sprachabhängig zu cachen und die Übersetzung dann zur Compile-Zeit zu verlagern, find ich interessant. Könnte nochmal schneller werden und so groß sind die Dateien ja auch nicht. Sprachdateien würd ich auf jeden Fall in mind. eine Datei pro Sprache aufteilen. So braucht nur die Sprache eingelesen zu werden, die grade aktiv ist. PHP braucht schon auch ne ganze Weile, um eine Quelldatei zu parsen und zu übersetzen. Am besten ist es wohl, die Texte in Kategorien aufzuteilen, und nur die zu laden, die in diesem Programmteil benötigt werden. Fabian, du verwendest Smarty? Doch nix mehr mit deinem eigenen Template-System? __________________ Yves Goergen Softwareentwicklung, Fotografie, Webhosting, UNB Components (in Arbeit) |
#7
| ||||
| ||||
@Lonely-Pixel: Ja, ich habe zum rechten Weg zurückgefunde. Erst als ich selbst ein Template-System programmiert habe, ist mir aufgefallen, was da alles dahinter steckt und wieviele gute Anwendungen mit Smarty es gibt. Außerdem könnte man damit rechnen, dass mein Projekt doch noch um einiges umfangreicher wird und dann spare ich viel Zeit, wenn ich Smarty verwende. Und so langsam scheint es auch nicht zu sein. Klar, mein Template-System ist schneller gewesen, war aber von der Funktionalität Smarty's weit entfernt. Auch wenn ich die längst nciht ganz ausnutze, so muss ich doch sagen, dass das System doch recht ausgereift ist. Eine Datei pro Sprache auf jeden Fall, sonst könnten Übersetzer auch gar nicht effektiv arbeiten. Aber ich plane sowieso, zwei Dateien pro Sprache einzuführen, eine für statische und eine für dynamische Inhalte oder irgendwas in der Richtung. Eigentlich ist es auch nicht verkehrt, sowas inner Datenbank zu speichern, dann hat man es um einiges einfacher mit den Kategorien, denn so Sachen wie FAQ oder Nutzungsbedingungen lassen die SPrachdatei sonst doch recht gewaltig anwachsen. __________________ Fabian Michael "Ein Tag, an dem du nicht lächelst, ist ein verlorener Tag." - Charlie Chaplin Wiki |
#8
| ||||
| ||||
Ich habe bei meiner Forensoftware folgendes System benutzt: Die Templates stehen in einer SQL-Tabelle, welches unter anderem ein Feld für das Template selber und eins für Sprachvariablen besitzt. Lädt man nun am Anfang des Scripts alle benötigten Templates wird jeweils das Feld für die Langvars ausgelesen und alle insgesamt benötigten Sprachvariablen werden aus der Datenbank geholt und in den Templates ersetzt. Das System kostet letztendlich 2 Queries (1 für Templates + 1 für Langvars) + Ersetzungen, jedoch sind die Queries etwas umfangreicher wegen des großen WHERE-Teils. Ich frage mich, in wie weit sich das auf die Performance ausschlägt? Vielleicht hat ja auch jemand von euch eine Idee zur Verbesserung? codethief. |
Stichworte |
- |
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Linktausch / Webring PHP Script | Metro Man | Web Design und Grafik | 0 | 17.08.2005 15:39 |
SMARTY variable im {php} Bereich | Dr.Schmidt | Programmierung und Datenbanken | 6 | 25.07.2005 10:47 |
Leseempfehlung: PHP Magazin | MrNase | Boardunity-Talk | 14 | 23.07.2005 21:40 |
Das PHP Forum 4 all | ShadowByte | Projektvorstellung und Bewertung | 4 | 22.06.2003 21:12 |