Übersetzungsfunktion

[MarkusR]

Nachdem ich beim Einsatz von Latest-News aufgrund der Laufzeiten bald dem Heulen nahe war, habe ich mal intensiver geforscht...

... und nach mehreren Runden durch den ConPresso-Code folgenden Bug gefunden:

in _include/translation.inc.php benutzt die Funktion loadTranslations() die Zeile (71):

Code: Alles auswählen

include($v['dir'].$l.'/'.$v['file'].'.inc.php');

Wird nun mittels getDateTranslation() ein Datumsplatzhalter in einem Template übersetzt, dann wird obenstehende Sprachdatei immer wieder statt nur einmal eingebunden und das ressourcenhungrige array_merge() rauscht jedesmal tausendfach durch's Array, um die Arrays korrekt miteinander zu verschmelzen...

Ändert man obenstehende Zeile in

Code: Alles auswählen

include_once($v['dir'].$l.'/'.$v['file'].'.inc.php');

dann machen formatierte Datumswerte plötzlich wieder Spaß!

[lube8t]

Hallo Markus,
ich war nicht nur am Heulen, ich war schon kurz vorm Herzinfarkt. Eigentlich müsstes du dafür die STRATO-Ehrenmedaille bekommen. Aber egal, da zeigt es sich wieder einmal das Hartnäckigkeit doch zun Erfolg führt. Ich habe sofort meine 2 Sites mit co404 geändert und der Erfolg ist sofort erkennbar, lange nicht so 'Glücklich gewesen ..!!!'.
Allerbesten Dank
Peter

[MarkusR]

Hm... da ist wohl auch der Wurm drin.

Leider weiß der Übersetzer einfach nicht welche Sprache er gerade geladen hat und wirft für jeden einzelnen Platzhalter alle bereits geladenen Übersetzungen über Bord und lädt nochmal alles.

Da ist grundsätzlich eine Überarbeitung notwendig.

Hier aber nochmal ein Workaround:

Erst mal das include_once wieder zurück auf include

Dann bringen wir dem System bei, welche Sprache gerade geladen ist.
Dazu öffnen wir im entsprechenden Sprachverzeichnis die common.php und suchen

Code: Alles auswählen

$GLOBALS['translationDates'] = array(

Danach fügen wir folgendes ein

Code: Alles auswählen

'language' => 'deutsch',

eben für deutsch... analog für englisch verfahren.

Dann suchen wir in translation.inc.php folgendes

Code: Alles auswählen

    function getDateTranslation($date, $lang='')
    {
        if ($lang!='') {
            $GLOBALS['translationDates']=array();
            $this->loadTranslations($lang);
        }
        if (!is_array($GLOBALS['translationDates'])) $GLOBALS['translationDates']=array();
        foreach ($GLOBALS['translationDates'] as $k => $v) {
            $date = preg_replace('/\b'.preg_quote($k, '/').'\b/', $v, $date);
        }
        if ($lang!='') {
            $GLOBALS['translationDates']=array();
            $this->loadTranslations($this->getLanguage());
        }

        return $date;
    }

und ersetzen es durch

Code: Alles auswählen

    function getDateTranslation($date, $lang='')
    {
        if ($lang!='' && $lang!=$GLOBALS['translationDates']['language']) {
            $GLOBALS['translationDates']=array();
            $this->loadTranslations($lang);
        }
        if (!is_array($GLOBALS['translationDates'])) $GLOBALS['translationDates']=array();
        foreach ($GLOBALS['translationDates'] as $k => $v) {
            $date = preg_replace('/\b'.preg_quote($k, '/').'\b/', $v, $date);
        }
        if ($lang!='' && $lang!=$GLOBALS['translationDates']['language']) {
            $GLOBALS['translationDates']=array();
            $this->loadTranslations($this->getLanguage());
        }

        return $date;
    }

Das ist ganz sicher nicht optimal und auch nicht im Sinne von Balu, aber so läuft es so wie gewünscht.

Was ich nicht verstehe ist, daß alle Überstzungen sogar zweimal geladen werden. Zuerst in der angegebenen Sprache und danach erneut die Standardsprache, auch wenn diese identisch sind und sowieso schon geladen sind...

[MarkusR]

Ach, ja... wer seine Seite eh nur einsprachig betreibt, der kann einfach in parser_r_value.inc.php alle Vorkommen von

Code: Alles auswählen

, $cpoRubrics[$db_rubric_id]['settings']['language']

(inkl. dem Komma davor!) löschen. Der Effekt ist der gleiche...

[m-grueger]

Hallo MarkusR,

vielleicht stehe ich gerade auf dem Schlauch, aber ich finde keine common.php auf meinem Webserver. Lediglich eine common.inc.php und dort keinen Code, wie Du Ihn beschreibst.

Gib mir doch bitte mal einen Tip,
Gruß,
m-grueger

[MarkusR]

Ja, sie heißt common.inc.php... mein Fehler... und liegt im Sprachverzeichnis.
Nicht zu verwechseln mit der common.inc.php im Verzeichnis _include (in dem auch das Sprachverzeichnis liegt).

Warum allerdings in Deiner _include/lang/deutsch/common.inc.php die Datumsnamen fehlen kann ich nicht beantworten. Man findet sie am Ende der Datei...

[m-grueger]

Ah jetzt ja... jetzt klappts.
Danke.

[balu]

Hallo,

nachdem Marky mich in diesem Beitrag an dieses Problem erinnert hat (das immerhin schon zwei Jahre hier schlummert), habe ich es mir nochmal genauer angeschaut.

Irgendwie ist mir das vom Radar gerutscht, weil wir diese Probleme nie so krass zu spüren bekommen haben. Flaschenhals sind bei uns üblicherweise eher die Datenbank-Abfragen...

Ein Problem beim Übersetzer ist, dass Module und ggfs. sogar Platzhalter zu jeder Zeit neue Sprachdateien ergänzen können (mit addTranslation()). Darum ist es nicht möglich, die fertig geladenen Übersetzungen in einer Art Cache zwischenzuspeichern. Es könnte halt nachträglich noch eine Datei mit Übersetzungen ergänzt werden müssen.

Also habe ich einen Übersetzungs-Cache ergänzt, der die fertigen Übersetzungen beinhaltet, aber gelöscht wird, sobald eine zusätzliche Sprachdatei geladen wird.

Die Generierung eines Artikels, in dem 100 mal das Publikationsdatum dargestellt wird, konnte ich so von 1,2 auf 0,2 Sekunden beschleunigen.

Angehängt findet Ihr die angepasste _include/translation.inc.php (als .txt-File zum runterladen).

Probiert diese bitte einmal aus und gebt mir hierzu Feedback.

Balu

[MarkusR]

Ich habe es jetzt mal eingesetzt und den Messwerten von mod_cache gegenübergestellt:

Originalversion: Running time: 17.5230s Used database queries: 150
Ohne Datumsbug: Running time: 1.4478s Used database queries: 150
Mit mod_cache: Running time: 0.7062s Used database queries: 57

mit der neuen translation.inc.php

Running time: 1.5636s Used database queries: 150

[balu]

Das sieht ja schon mal ganz gut aus.

Ich hoffe, ich habe bald mal ein wenig Zeit, mir Dein mod_cache genauer anzuschauen...

Balu

[semf]

Hallo zusammen,

ich mach hier jetzt mal den Volldeppen: Ist das hier beschriebene Problem der "sagenumwobene" Datumsbug?

Und gehe ich recht in der Annahme, dass beim Laden der Artikel über das Latest-News-Modul eben dieser zu Laufzeiten führt, die hier wohl bei dem ein oder anderen koronare Herzbeschwerden verursacht haben?

Wäre für ein kurzes Update von einem Fachmann / einer Fachfrau sehr dankbar! Und ja, ich weiß - wer lesen kann ist klar im Vorteil. Ich kann lesen, habe aber wenig Zeit - Punkt!

[MarkusR]

Nachdem ich beim Einsatz von Latest-News aufgrund der Laufzeiten bald dem Heulen nahe war...

... folgenden Bug gefunden:

... getDateTranslation() ...

Jepp, inzwischen als "Datumsbug" bekannt.