mmofacts.com

Sprachtemplate Realisierung

gepostet vor 12 Jahre, 9 Monate von barkeltheboon

Moin,

Ich überlege gerade wie ich Mehrsprachigkeit implementieren soll. Ich habe jetzt verschiedene Ideen gehabt, weiss aber nicht welche die sinnvollste für mein Anliegen ist bzw. welche die geringsten Anforderungen an einen Webserver stellt.

1.) Für jede Sprache Einträge in MySQL-Tabelle. Zum Beispiel nach folgendem Muster:

news_menu1, news_menu2, news_text1,....forschung_text93,.....

Beim Aufruf der Seiten wird dann nach den entsprechenden Einträgen in der Datenbank gesucht und der Text über das Designtemplate miteingefügt.

2.) Externe Files

   a) mit einfachen Variablen und Arrays um Texte und Bezeichnungen einzufügen.

   b) mit Konstanten über Define

   c) mit ini Files (siehe http://dev-tips.com/featured/how-to-use-custom-ini-files-with-php)

Von 2b,c habe ich halt etwas gelesen. Möglich ist alles. Aber was macht eventuell am meisten Sinn um quasi statische Daten am bequemsten und / oder am schnellsten zu nutzen.

MfG barkel

gepostet vor 12 Jahre, 9 Monate von BlackScorp

Vor dieser Frage stand ich damals auch. Hatte bei 2 noch eine d) möglichkeit .mo bzw .po Dateien und GetText funktion von PHP. Ich erzähle dir mal meine Überlegung von Damals.

Mysql tabelle mit Text, dafür müsste ich mir einen Editor erstellen um Texte zu editieren bzw herausfinden welche schlüsselwörter für welchen Text stehen oder ich müsste PHPMyAdmin nutzen.. wäre mir zu umständlich.

Konstanten über DEFINE fand ich nicht schön und am ende hätte man ja millionen von Defines

Ini Files, joa das war eine überlegung wert aber wenn man die .htaccess datei mal vergisst, konnten andere in die ini reinschauen.

Am ende nahm ich normale php Dateien mit arrays drin, vorher hatte ihc eine große datei für jede sprache und dies war irgendwann unübersichtlich, also habe ich mir eine Language klasse gebaut, die mir bei jedem View die lang datei zum view lädt.

Ich habe mir dabei gedacht, dass die include funktion von php am schnellsten gehen sollte, und es werden immer kleinere Dateien included, außerdem durch die aufspaltung der Dateien auf Views ist alles noch übersichtlicher geworden. Der Nachteil ist jedoch dass man mache Texte mehrfach generieren muss oder diese Texte in eine Globale sprachdatei einbinden muss, und diese wird am ende doch sehr unübersichtlich:D

Ich würde gerne mit getText arbeiten, aber ich bin mit dem Editor PoEdit nicht klargekommen:D irgendwann werde ich aber es noch einsetzen, weil du da eben einfach ein text eintippen kannst und es wird dir dann übersetzt, dann musst du keine "variablen" für bestimmte sätze ausdenken und der code ist kurz _('Hallo Welt');

Hoffe ich konnte dir weiterhelfen

MFG

gepostet vor 12 Jahre, 9 Monate von barkeltheboon

Vielen Dank für deine lange Antwort. Damit hilfst du mir sehr weiter.

  • Mit der MySQL Tabelle hast du Recht. Habe gelesen, dass das jemand folgendermaßen realisiert hat: Texte und so weiter in MySQL Tabellen gespeichert. Mit Webeditor darauf zugegriffen und geändert und dann Erzeugung einer Datei zum inkludieren. Ist aber wohl eher unnötig. Zur Not kann ich auchn Skript schreiben das die Dateien ausliehst und direkt neuschreibt. Also wozu der Umweg?! ^^
  • Wäre es ein Problem "Millionen von Defines" zu haben?
  • Ist es tragisch wenn jemand in meine Sprach-ini-File reinschaut? Die Frage wäre dann eher, habe ich irgendeinen Vorteil von der Verwendung dieser Variante oder der Define Variante?

Ich denke ich werde auch normale Dateien nehmen. Für jede Seite und Sprache eine Eigene. Das ist wohl die sinnvollste Lösung, aus den von dir benannten Gründen. Allerdings teile ich nicht ganz das Verständnis, oder die Ansicht mit einer globalen Sprachdatei. Was soll das für ein Konstrukt sein / werden? Das verstehe ich nicht ganz wozu das nötig ist.

Mit getText habe ich mich nur ganz kurz auseinandergesetzt und kann dazu ehrlich gesagt noch nichts fundiertes sagen.

gepostet vor 12 Jahre, 9 Monate von BlackScorp

Wegen der Globalen datei.

Es gibt meldungen bzw texte die auf jeder Seite vorkommen könnten, ein beispiel dafür ist "Sie werden weitergeleite, falls die weiterleitung nicht funktioniert klicken sie bitter hier" , wenn du für jede seite und sprache eine lang datei erstellst, musst du diesen string jedesmal in die datei mit rüberkopieren. da mir das zu umständlich wurde, habe ich eine Allgemeine globale sprachdatei erstellt. so dass in dieser datei , texte drin stehen , die überall erscheinen könnten. Diese Globale datei ist bei mir mittlerweile doch etwas größer geworden.

Zur MYSQL, du musst dir ja vorstellen wieviel Texte * Anzahl an Sprachen drin stehen werden. und jedesmal ein SQL Befehl an Datenbank zu schicken müsste doch viel Traffic verusachen. Außerdem sagen meine Arbeitskollegen immer:"Wenn du Performance Probleme hast, dann liegt es in den meisten Fällen an der Datenbank".

Wegen der Ini, ich denke nicht dass es Tragisch ist, wenn jemand die Sprachdateien sich ansehen kann(fand die vorstellung einfach unschön dass jemand was ansehen konnte was ich nicht nach außen zeigen wollte), zudem bin ich da einfach von ausgegangen dass parse_ini_file langsamer ist als include.

Wegen den Defines, da dachte ich mir folgendes: Defines sind ja superglobal also müssen die irgendwo abgespeichert werden und verbrauchen dadurch platz und KÖNNTEN ja die Perfomance stören. genau weis ich es nicht, verwende diese auch nicht und kenne keine Projekte die Defines als language variablen einsetzen.

getText hat für mich ein nachteil, dass ich mehr quellcode tippen kann. der Editor von gettext parst alle PHP Dateien und sucht nach _('text') aus diesen sätzen baut er satzbausteine in einer .mo bzw .po datei und mit dem editor kann man dann einzelne sätze in andere sprache übersetzen und neue .mo und .po dateien generieren. Das problem dabei ist. Dass deine Meldungen aufjedenfall dann im Quellcode stehen müssten. also sowas wie

if($account->register()){

echo $text['registerSuccess'];

}else{

foreach($account->getError() as $error){

echo $text[$error];

könnte man bei gettext nicht verwenden sondern müsste man da ein switch case einbauen und je nach fehlermeldung dann jedesmal ein echo _('fehler1') ; echo _('fehler2') und so weiter ausgeben.

hoffe es ist nun etwas verständlicher;)

MFG

gepostet vor 12 Jahre, 9 Monate von tector
kurz meine Meinung dazu: - Datenbank halte ich für nicht so sinnvoll... ist aber eher eine subjektive Meinung.. ich denke aber es ist ganz gut Sprachdateien auch unabhängig von der DB verfügbar zu haben - PHP-Arrays sind für den Anfang ganz nett.. je nachdem wie umfangreich die Sprachdateien werden kann es sich perfomancemäßig negativ auswirken.. (außerdem glaube ich mal gehört zu haben dass PHP eine Obergrenze von 5000 Array-Einträgen hat!?!?) - define() für Sprachdateien zu missbrauchen halte ich für eine ganz, ganz dumme Idee.. ist einfach schlechter Stil - Ini-Dateien sind mein absoluter Favourit.. sie sind leicht editierbar und allein der Dateityp grenzt Sie schon von anderen Programmteilen gut ab (bei phpArrays weiß man u.U. nicht gleich auf den 1. Blick dass es eine Sprachdatei ist) - Profilösung ist dann mit gettext mit den .po und .mo-Dateien.. kenn ich mich nicht mit aus - ist glaub ich nicht so einfach..
gepostet vor 12 Jahre, 9 Monate von BlackScorp

hm.. kennst du eine seite die 5000 textelemente gleichzeitig darstellt? mich würde das mal interessieren was wohl schneller angezeigt wird. wenn man eine ini datei hat mit 10 wörtern oder eine php datei mit einem array mit 10 elementen, was wird schneller ausgeführt parse_ini_file oder include.. müsste ich mal ausprobieren:D

gepostet vor 12 Jahre, 9 Monate von MrMaxx

Das was du machen wilslt nennt sich "Internationalisierung"...also deine Applikation dafür vorzubereiten Lokalisiert zu werden.

Google ist dein Freund, z.B. mit dem Suchbegriff "Internationalisierung PHP"...da findest du genügend Ansätze und detaillierte HowTos. Ich habe keine Ahnung, welche Frameworks du benutzt.

Es sollte auf jedenfall egal sein, wie und wo du deine Lokalisierten Texte ablegst, denn unabhängig davon, ob du sie aus einer Date liest, oder aus der Datenbank...es ist langsam und du solltest überlegen, ob du sie nicht cachen willst (bei PHP vermutlich mittels memcached).

So long...

Maxx

gepostet vor 12 Jahre, 8 Monate von Sarge

das die Datenbank geschwindigkeitstechnisch keine sinnvolle idee ist denk ich steht außer frage, dass du mit einem memcached schneller sein willst als includes von dateien mit php arrays (apc o.ä. opcode cache!) halte ich doch für eine sehr gewagte theorie. Der geneigte Leser mag an dieser Stelle ein entsprechenden Performance Test machen.

gepostet vor 12 Jahre, 8 Monate von Phoscur

Wäre auch nicht aufwendig das auf Clientseite in JavaScript zu implementieren und spart sogar das Seite neuladen beim Sprachwechsel. Performat wäre da wohl dann einfach JavaScript Dateien mit Sprachvariabelnarrays, lässt sich aber auch leicht kurz irgendwas per Regex parsen. Gibts auch bestimmt schon als jQuery Modul oder sowas..

gepostet vor 12 Jahre, 8 Monate von buhrmi

Juhu ich mag auch meinen Senf zu dieser Wurst geben und meine Lieblingslösung vorschlagen.

Texte die lokalisiert werden müssen befinden sich bekanntermaßen an drei Orten:

  • Verwurschtelt in serverseitigem Code: Templates, Fehlermeldungen, E-Mails, etc...
  • Verwurschtelt in clientseitigem Code: Dynamische Texte, Javascript Akrobatik, etc...
  • Gespeichert in der Datenbank: Newseinträge, Beschreibungstexte, etc...

Je nachdem, wo der Text lebt, wird ein anderer Ansatz herangezogen. Sämtliche Texte, die in der Codebasis enthalten sind, werden in eine Sprachdatei herausextrahiert und durch Platzhalterfunktionen ersetzt. Beispiel:

Code:

Template:

<% t 'userstats.money', 20, 5 %>

Sprachdatei:
userstats.money: Du hast %d Gold und %d Rubine

Nun hat man für jede Sprache eine andere Sprachdatei. Eine Sprachversion des Spiels kann man nun entweder einfach durch Austausch der Sprachdatei erstellen, oder man betreibt etwas mehr Aufwand und kompiliert die Sprachdatei in den Quelltext hinein. Dann hat man einen produktiv einsetzbaren lokalisierten Quelltext, der um ein Vielfaches effizienter ist.

Falls man Fixtures benutzt, um eine Datenbank zu popularisieren, könnte man den kompilierten Ansatz möglicherweise auch auf Texte übertragen, die in der Datenbank gespeichert werden. Doch dies geht natürlich nicht, wenn sich mehrere Sprachversionen eines Spieles die selbe Datenbank teilen. Dann muss man die Datenbank ebenfalls auf Mehrsprachigkeit hin strukturieren. Bei einem Weltraumspiel hat man dann womöglich eine Schiffstypentabelle shiptypes mit den Feldern id, cost, buildtime und eine zugehörige Lokalisierungstabelle shiptypes_locale mit den Feldern shiptype_id, locale_id, name, description

Jetzt stellt sich die Frage, warum man den Namen und die Beschreibung der Schiffstypen nicht auch in einer Sprachdatei speichern kann? Man KANN schon.... Aber das macht die Contentpflege sehr viel aufwändiger.

Auf diese Diskussion antworten