• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Webseite mehrsprachig gestalten

nietaL

NGBler

Registriert
8 Sep. 2013
Beiträge
231
Ort
Exilgullianer
Hey Leute,

ich habe eine recht umfangreiche Webseite, auf der Textausgaben sowohl über HTML als auch über PHP getätigt werden. Zur Zeit ist alles auf Deutsch. Ich möchte die Möglichkeit bieten, weitere Sprachen (naja, erst einmal nur Englisch) auswählen zu können.

Ich habe Bauchschmerzen, den ganzen übersichtlichen Code (ich gebe mir dabei immer sehr viel Mühe :coffee:) durch sowas wie $txt_submit['en'] zu zerschießen. Ebenfalls ungünstig finde ich, den ganzen Haufen zu kopieren und zu übersetzen, da man dann Änderungen ja pro Sprache wiederholen muss, obwohl mir das noch am besten vorkommt.

Gibt es irgendwas Elegantes, um das Problem zu lösen?
 

nietaL

NGBler

Registriert
8 Sep. 2013
Beiträge
231
Ort
Exilgullianer
  • Thread Starter Thread Starter
  • #3
mhh, vielen Dank für den Hinweis. Das scheint recht Umfangreich zu sein. Es kommt mir vor, als schieße ich da mit Kanonen auf Spatzen. Es widerspricht zwar meinem eingangs erwähnten Prämissen, aber spräche etwas gegen folgendes?

lang.jpg
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Zum Beispiel:
1. Die mangelnde Möglichkeit einfach und schnell den Code zu erweitern.
2. Der Aufwand alles selbst von Grund auf zu programmieren.
3. Die Übersichtlichkeit des Codes.
 

nietaL

NGBler

Registriert
8 Sep. 2013
Beiträge
231
Ort
Exilgullianer
  • Thread Starter Thread Starter
  • #5
Mhh. Irgendwie verstehe ich das nicht. Ich wüsste nicht, warum es schwerer sein sollte, den Code zu erweitern. Du meinst, wenn es eine neue Textausgabe gibt, dass ich die Arrays erweitern muss usw?
Was wäre denn jetzt weniger Aufwand. Die Seite steht ja nun leider schon. Also von Grund auf muss ich doch sowieso etwas programmieren.
Bei 3. gebe ich dir Recht und entspricht schon meinem eigenen Einwand gegen diese Methode.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Eines der wichtigsten Konzepte in der Programmierung nennt sich MVC. MVC steht für: Model, View, Controller
Gemeint ist die Auftrennung einer Anwendung in diese drei Bestandteile.

Du solltest deine Webseite eben jene drei Bestandteile aufgliedern.
Model: Das Datenmodell. In Webanwendungen werden die Daten gewöhnlich in einer Datenbank gelagert.
View: Die Präsentation der Daten. Bei Webanwendungen verwendest du HTML und CSS um deine Daten zu darzustellen.
Controller: Die Anwendungslogik. Diese wird häufig in client- und serverseitigen Programmiersprachen umgesetzt. (PHP, JavaScript etc)

In deinem Fall sollten HTML und CSS also rein die Struktur und das Aussehen der Webseite definieren.
Deine Sprachfiles werden in der Datenbank ausgelagert und PHP und JavaScript kümmern sich um die Logik der Webseite.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Gettext ist doch wahnsinnig einfach, mir stellt sich die Frage einer Eigenimplementierung gar nicht.

MO- und PO-Dateien erlauben es auch Leuten oder Diensten, die nicht programmieren, das Zeug zu übersetzen. Ist weitaus angenehmer, damit zu arbeiten.

Warum etwas anders machen als der Standard, nur um dann festzustellen, dass der Standard eine Daseinsberechtigung hat? ;)
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Ich kenne die genaue Implementierung von gettext nicht, aber File-Zugriffe auf der Festplatte sind niemals so schnell, wie eine Datenbank, die im Wesentlichen Inhalte direkt im RAM hält. Besonders wenn die Sprachfiles größer und ggf. aufwändiger werden können Datenbanken Strukturvorteile ausnutzen, um wesentliche Geschwindigkeitsvorteile gegenüber der Suche in einem reinen Textdokument zu gewinnen. ;)
Natürlich ist die Implementierung zunächst "komplexer", dafür skaliert sie deutlich besser, als die Alternative.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
@virtus: Flat-Files sind seit RAM-Cache und SSDs für viele Anwendungen vernachlässigbar langsamer als Datenbanken, in manchen Anwendungen (viele statische Inhalte, bspw. die hier angeführten Übersetzungen) bei entsprechender Optimierung sogar schneller.
 

nietaL

NGBler

Registriert
8 Sep. 2013
Beiträge
231
Ort
Exilgullianer
  • Thread Starter Thread Starter
  • #10
ich habe mir das doch noch einmal richtig angeschaut und erkenne immernoch keinen WESENTLICHEN Vorteil. Dass unerfahrene Leute einfacher übersetzen können, mag einer sein, tangiert mich aber hier nicht, weil ich das ganz sowieso alleine durchziehe. Wobei ich finde, dass meine Arrays auch jeder Progammier-Neuling verstehen dürfte... Eine schnellere Berechnung wurde hier ja auch schon dementiert bzw. nicht ausnahmslos bestätigt. Übersichtlicher scheint mit der Code teilweise. Die Standardsprache steht textgetreu im Code, z.B. echo _("Hallo Welt");
Ich kann hingegen nur kurze Variablennamen verwenden, z.B. echo $hallowelt;
Kritisch wird es, wenn es längere Texte werden. Dann muss ich eine aussagekräftige Variable finden - sonst wird es natürlich unübersichtlich.
Tippfehler müssen bei meiner Variante etwas umständlicher in der Sprach-Array-Datei gesucht werden. Wobei das, wenn ich gettext richtig verstanden habe, auch dort der Fall wäre, wenn der Text nicht in der Standardsprache korrigiert werden soll, nämlich in diesen Sprachdateien (PO).
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Am Ende hast du halt eine Variablensuppe mehrerer Hundert Variablen, bei Gettext ist das Ganze etwas lesbarer, imo.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.507
ImHo spricht nichts gegen eine eigene Implementierung in diesem Fall. Skalierungsfragen u.ä. muss man sich in jedem Fall stellen und beantworten.
Wenn die simple Lösung für dich funktioniert, go for it. Wobei ich deine Lösung jetzt auch nicht so übersichtlich finde.
Hab mir letztens für eine mini Seite auch genau sowas selber geschrieben (in js) und das ist für dieses Projekt genau richtig.
 

nietaL

NGBler

Registriert
8 Sep. 2013
Beiträge
231
Ort
Exilgullianer
  • Thread Starter Thread Starter
  • #13
Hab das ganze jetzt mal bei zwei Seiten durchgezogen. Es funktioniert wie erwartet einwandfrei. Die Sprachdatei habe ich mit Tabulatoren optisch gegliedert, sodass die einzelnen Sprachen genau untereinander stehen - ist wie eine Tabelle. Die Variablensuppe habe ich etwas sortieren können, indem ich sie nach ihrem Auftreten auf der jeweiligen php-Seite sortiert habe. Die Suche per Strg+F tut ihr übriges. Die habe ich auch zuvor genutzt.

Lediglich im Quellcode sehe ich den gewissen Nachteil ein, dass echo $helloworld[$L]; nicht so schön ist wie echo _('hello world');. Dies jedoch auch nur bei längeren Strings, wie ganzen Sätzen.

Ich danke euch für die abwägende Diskussion.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
@phre4k: Nicht jeder konfiguriert RAM Disks oder SSDs in seinem Server. ;)
Abgesehen davon wird das bei großen Dateien oder umfangreichen Datensätzen weiterhin Datenbanken unterlegen sein.
Datenbanken erlauben eine Optimierung, die sich vor allem in der Skalierung nach oben hin bemerkbar macht. Die kannst du nicht durch SSDs oder RAM Disks ersetzen.

Wenn es sowieso nur statische Inhalte sind, kannst du auch gleich die Webseite in den verschiedenen Sprachen ablegen.
[src=text]de-de/template
de-ch/template
en-us/template
en-uk/template
fr-fr/template[/src]

Für rein statische Inhalte wäre das wiederum auch einer Datenbanklösung überlegen.



[src=php]echo("Statischer Text")[/src]
macht überhaupt keinen Sinn. Eine statische Textausgabe durch den PHP-Interpreter zu jagen ist so ziemlich das ineffektivste, was du konstruieren kannst.
Erst mal ist PHP mit Standardinterpretern eine verhältnismäßig langsame Sprache, wenn du nicht gerade die HHVM verwendest.
Textausgabe ist grundsätzlich in JEDER Programmiersprache langsam. Daher solltest du den Aufruft von echo bzw. print (auch println etc) soweit es geht vermeiden.


Als einfaches Benchmark:
[src=php]<?php
// wrappers for echo, print, printf
function useEcho($text){
echo($text);
}
function usePrint($text){
print($text);
}
function usePrintf($text){
printf($text);
}

// wrappers for single output and multi output
function multiPrint($method, $max) {
for($i=0; $i<$max; $i++){
$method("A");
}
}
function singlePrint($method, $max) {
$output = "";
for($i=0; $i<$max; $i++){
$output .= "A";
}
$method($output);
}

// initiates output<single|multi> using method<echo|print|printf> for trials letters
function test($variant, $method, $trials){
echo '<div style="height: 150px; width: 400px; overflow: scroll; float: left;"><h1>'.$method.' '.$variant.'</h1>';
$s = microtime();
$variant($method, $trials);
$e = microtime();
echo '</div>';
return round($e - $s, 6);
}

function benchmark(){
$trials = 5000;
$results = array();

// benchmark echo single output vs multi outputs
$outputMethod = 'useEcho';
$timeS = test('singlePrint', $outputMethod, $trials);
$timeM = test('multiPrint', $outputMethod, $trials);
$results['echo'] = array('single' => $timeS, 'multi' => $timeM);

// benchmark print single output vs multi outputs
$outputMethod = 'usePrint';
$timeS = test('singlePrint', $outputMethod, $trials);
$timeM = test('multiPrint', $outputMethod, $trials);
$results['print'] = array('single' => $timeS, 'multi' => $timeM);

// benchmark printf single output vs multi outputs
$outputMethod = 'usePrintf';
$timeS = test('singlePrint', $outputMethod, $trials);
$timeM = test('multiPrint', $outputMethod, $trials);
$results['printf'] = array('single' => $timeS, 'multi' => $timeM);

return $results;
}

function displayResults($results){
$output = '<table>';
$output .= '<tr>';
$output .= '<td></td>';
$output .= '<td>echo</td>';
$output .= '<td>print</td>';
$output .= '<td>printf</td>';
$output .= '</tr>';
$output .= '<tr>';
$output .= '<td>single</td>';
$output .= '<td>'.$results['echo']['single'].'</td>';
$output .= '<td>'.$results['print']['single'].'</td>';
$output .= '<td>'.$results['printf']['single'].'</td>';
$output .= '</tr>';
$output .= '<tr>';
$output .= '<td>multi</td>';
$output .= '<td>'.$results['echo']['multi'].'</td>';
$output .= '<td>'.$results['print']['multi'].'</td>';
$output .= '<td>'.$results['printf']['multi'].'</td>';
$output .= '</tr>';
$output .= '</table>';
print($output);
}

displayResults(benchmark());[/src]

Anstelle von microtime kannst du auch time verwenden, wenn du dir wegen overflows Gedanken machst.
Dann solltest du jedoch die Menge des Outputs (trials) stark erhöhen.

Im Ergebnis sollte der Test zeigen, dass du mit mehreren Ausgaben (mehrere Schreibaufrufe) stets langsamer bist, als mit wenigen, unabhängig davon welche Ausgabe-Methode (echo, print, printf) du verwendest.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.454
Ort
/dev/null
virtus: Irgendwie glaub ich, du schießt am Ziel vorbei. Webseiten werden langsam durch haufenweise Javascript-Einbettungen.

Vor 10 Jahren hab ich mal in einer kleinen Webklitsche gearbeitet. Die Seiten, die ich damals selbst oder umgebastelt hatte, verwendeten die verschiedensten Methoden zur Textausgabe. Bei einer Seite hatte ich ein reines Texttemplate, was ich dann durch ein preg_replace gejagt hab, und damit Placeholder durch Text ersetzt hab. Ist alles nicht wirklich spürbar.

Aber sobald ich damals das Javascript-Fragment zum Aufruf von Google Analytics eingebettet hatte, ging die Performance in die Knie. Und die meisten Seiten leiden wohl an den Einbettungen von Werbung oder Spionage-Javascript.

phre4k: Danke für die Erklärung mit poedit. Ich kannte den Namen, hab mich aber nie damit beschäftigt. Wieder was gelernt (auch wenn ich's vermutlich nicht mehr brauchen werde.)

Ach ja, ist zwar fast 10 Jahre alt, sollte aber noch immer gültig und von der Performance her das Nonplusultra sein: LAMP ohne AMP
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
virtus: Irgendwie glaub ich, du schießt am Ziel vorbei.
Ich glaub du solltest den Beitrag noch mal genauer lesen.

Webseiten werden langsam durch haufenweise Javascript-Einbettungen.
Ich stimme da vollkommen mit dir überein. Die Aussage ist durchaus korrekt. Besonders wenn die Webseite schlecht programmiert ist, können Script-Einbettungen extreme Ladezeiten verursachen. Das hat aber mit dem Thema und besonders dem von mir erwähnten Punkt circa genau nichts zu tun.

Vor 10 Jahren hab ich mal in einer kleinen Webklitsche gearbeitet.
Auch vor 10 Jahren war es schon teurer 10x print aufzurufen, als 1x print mit dem 10-fachen Inhalt. :rolleyes: Wenn du mir nicht glaubst, kannst du gerne das obige Script einfach mal in einer PHP Sandbox ausprobieren. Zusätzlich solltest du bedenken, dass JavaScript vor 10 Jahren nicht unbedingt mit JavaScript von heute vergleichbar ist. Allgemein hat sich in der Welt des WWW seit 10 Jahren viel getan. ;)

Die Seiten, die ich damals selbst oder umgebastelt hatte, verwendeten die verschiedensten Methoden zur Textausgabe. Bei einer Seite hatte ich ein reines Texttemplate, was ich dann durch ein preg_replace gejagt hab, und damit Placeholder durch Text ersetzt hab. Ist alles nicht wirklich spürbar.
preg_replace macht was genau? Richtig, es erzeugt keine Ausgabe. preg_replace führt Operationen auf Strings durch. RegExp ist zwar nicht unbedingt die Krönung der Performanz, aber erst mal unproblematisch. Wie ich bereits sagte ist der Kostenpunkt die Anzahl der Ausgaben, die ausgeführt werden, bzw. die Anzahl der Aufrufe von Funktionen wie print.
"nicht wirklich spürbar" ist übrigens eine nette Formulierung für "rein subjektiv, ohne wissenschaftliche Grundlage", damit leider nicht wirklich brauchbar. Meine Ausführung hat sich um messbare Unterschiede gedreht, nicht darum, ob der Endbenutzer diese Unterschiede in jedem Fall merkt: 1x 1000 "A" ausgeben dauert nicht ansatzweise so lange, wie 1000x 1 "A" auszugeben. Schlicht weil Operationen wie print verdammt langsam sind. Das gilt unabhängig von der Programmiersprache und der Historie.

Aber sobald ich damals das Javascript-Fragment zum Aufruf von Google Analytics eingebettet hatte, ging die Performance in die Knie. Und die meisten Seiten leiden wohl an den Einbettungen von Werbung oder Spionage-Javascript.
Das ist eine ganz andere Baustelle. Ich spreche hier von der Zeit, die der Server benötigt um von Anfrage bis zur Ausgabe des Dokuments zu gelangen. Hier spielt JavaScript überhaupt keine Rolle. Dem Server ist es egal, ob er da HTML, CSS oder JavaScript ausliefert. Es ist ihm sogar egal, ob es sich um ein HTML-Dokument, ein Bild oder eine Executable handelt. Nur bei Dokumenten, die zuerst an ein Modul oder eine externe Anwendung übergeben werden müssen (z.B. PHP), kann der Server nicht direkt ausliefern, sondern muss warten, bis die Anwendung/ das Modul mit der Bearbeitung des Dokuments fertig ist.
Um diese Zeit zu minimieren, gilt es teure Operationen zu vermeiden. Wie oben gezeigt sind unter Anderem print-Ausgaben genau solche teuren Operationen, die vermieden werden sollten.

Ach ja, ist zwar fast 10 Jahre alt, sollte aber noch immer gültig und von der Performance her das Nonplusultra sein: LAMP ohne AMP
Ich habe mir mal die erste Seite des Artikels durchgelesen und finde die Idee schon interessant.
Je nach Zielsetzung mag der Ansatz ganz interessant sein und findet ja auch in der Praxis Verwendung.
Allerdings betrachten wir mal folgendes:
Deine C++ Applikation muss:
  1. Einen Webserver implementieren, um auf Nutzeranfragen reagieren zu können.
  2. Die Anwendungslogik deiner Webseite implementieren, etwa das, was PHP tun würde.
  3. Die Anwendungsdaten deiner Webseite verwalten, in einer Art und Weise, wie es auch von Datenbanken getan wird.

Was genau hast du jetzt gewonnen, außer dass du für jede Webanwendung zusätzlich von der Seiten-Logik auch noch von neuem Web- und Datenbankserver implementieren musst?

Die Daten im RAM zu halten ist übrigens eine Idee, die genauso von Datenbankservern realisiert wird. Auch Datenbankserver halten - übrigens optimiert - Daten im RAM. Wir sind uns aber wohl einig, dass regelmäßig Daten auf die Festplatte geschrieben werden müssen, denn der RAM dient eben gerade nicht als persistenter Speicher. Das macht ein DBMS genauso wie es deine C++ Anwendung tun muss, wenn sie nicht mit Datenverlust leben kann. [Ein Neustart des Servers würde 100%igen Datenverlust bedeuten!]

Zusätzlich solltest du bedenken, dass du dir einige Probleme ins Haus holst:
  • Redundanz wird schwerer. Wird die Anwendung auf mehreren Systemen betrieben, beispielsweise um load balancing zu betreiben, dann müssen sich die einzelnen Instanzen abstimmen (stell dir mal Ebay vor). Deiner C++ Anwendung musst du das natürlich beibringen. DBMS können mit diesem Problem umgehen. Du als Entwickler einer Webapplikation musst dich nicht mehr zusätzlich darum kümmern, wenn du ein fertiges DBMS verwendest. Bei deiner C++ Anwendung musst du diese Aufgabe natürlich selbst erledigen.
  • Änderungen an der Anwendungslogik erfordern zwangsweise, dass du den vollständigen Server umprogrammierst, neu kompilierst und neu startest. Bei einer "klassischen" Webseite kannst du einzelne Anwendungsdateien austauschen, ohne dabei den Betrieb der Website zu unterbrechen.
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.507
Wenn es sowieso nur statische Inhalte sind, kannst du auch gleich die Webseite in den verschiedenen Sprachen ablegen.
Davon kann ich allerdings nur abraten, da es fehleranfällig, unflexibel und wartungsintensiv ist.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.454
Ort
/dev/null
virtus: Ist alles korrekt, was du sagst.

Trotzalledem ist wohl die Verwendung von "print" in PHP auf dem Webserver das kleinere Übel von den ganzen Performancefressern. Das wollte ich als Konsens vermitteln.
 

virtus

Gehasst

Registriert
24 Apr. 2015
Beiträge
1.689
Ort
AUF DEM MOND
Davon kann ich allerdings nur abraten, da es fehleranfällig, unflexibel und wartungsintensiv ist.
Das kommt auf den generellen Aufbau an. Verwaltest du die statischen Seiten manuell, kann das schnell unübersichtlich werden.
Allerdings liegt das dann an dem Mangel einer Verwaltungssoftware.
Viele CMS gehen den Weg, dass sie zunächst einmal die Daten bspw. in einer Datenbank liegen haben und dann automatisiert einen Cache für statische Inhalte generieren.
Dann wird beim Abruf die gecachte Datei geliefert. In der Administration arbeitest du auf den Rohdaten. Nach einer Bearbeitung kümmert sich das CMS dann automatisiert darum betroffene Dateien im Cache zu erneuern.
Der Vorteil ist, dass du dir einerseits die Flexibilität bewahrst, die eine strikte Trennung von statischen Inhalten und Layout ermöglicht, gleichzeitig jedoch Performanz-Vorteile erhältst, die vorgenerierte Dateien erlauben und wenn dein CMS dich hinreichend unterstützt, musst du dich auch nicht um die Verwaltung kümmern.
Dabei gilt zu Beachten, dass das einmalige (bzw. generell sehr seltene) Erzeugen des Caches zwar Leistung und Zeit in Anspruch nimmt, jedoch auf die Betriebszeit der Webseite ganz klar dem ständigen Neu-Generieren der Site deutlich überlegen ist.


Trotzalledem ist wohl die Verwendung von "print" in PHP auf dem Webserver das kleinere Übel von den ganzen Performancefressern. Das wollte ich als Konsens vermitteln.
Das Stimmt natürlich. Nur sollte dies trotzdem auch beim Entwurf einer Webseite beachtet werden.
 
Oben