Jump to content

Übersetzung "Installierte Module" nicht aufrufbar


comfuse

Recommended Posts

Hallo, ich werde beim Aufruf der Übersetzungen "Installierte Module" - egal bei welcher Modulauswahl - mit einem Fehler 500 geschmissen. Wenn ich debugge, heißt es:
 

Symfony\Component\Debug\Exception\ FatalThrowableError

in src/Adapter/Translations/TranslationRouteFinder.php (line 208)

     */

    private function isModuleUsingNewTranslationSystem($moduleName)

    {

        $module = $this->moduleRepository->getInstanceByName($moduleName);

        return $module->isUsingNewTranslationSystem();

    }

}

Aber: Wenn ich irgendeinen anderen Bereich der Übersetzungen aufrufe, geht alles. NUR bei "Installierte Module" ist der Ofen aus.

Schon mal gehabt? Das nervt...

Carsten

Edited by comFUSE (see edit history)
Link to comment
Share on other sites

Sofern es kein natives Modul ist, kannst du einfach die en.php in eine de.php kopieren, die Datei öffnen und die Items übersetzen. Bei mitgelieferten Standardmodulen (aktuell zumindest diejenigen, deren Name mit ps_ beginnt, z.B.  ps_legalcompliance) geht das nicht mehr, weil sich die Übersetzung auf verschiedene Ressource-Dateien verteilt.

Link to comment
Share on other sites

Meine Antwort wird leider nicht angezeigt, weil man in diesem Forum wohl neuerdings Dateinamen, die irgendwie mit dem Shopsystem zu tun haben oder vielleicht auch den Namen der Programmiersprache nicht mehr nennen darf. Hier wütet nämlich seit einiger Zeit ein nscheinend völlig unterbelichteter Forenadmin.

Link to comment
Share on other sites

Quote

Sofern es kein natives Modul ist, kannst du einfach die en.php in eine de.php kopieren, die Datei öffnen und die Items übersetzen. Bei mitgelieferten Standardmodulen (aktuell zumindest diejenigen, deren Name mit ps_ beginnt, z.B.  ps_legalcompliance) geht das nicht mehr, weil sich die Übersetzung auf verschiedene Ressource-Dateien verteilt.

 

Link to comment
Share on other sites

Sofern es kein natives Modul ist, kannst du einfach die en.php in eine de.php kopieren, die Datei öffnen und die Items übersetzen. Bei mitgelieferten Standardmodulen (aktuell zumindest diejenigen, deren Name mit ps_ beginnt, z.B.  ps_legalcompliance) geht das nicht mehr, weil sich die Übersetzung auf verschiedene Ressource-Dateien verteilt.

Link to comment
Share on other sites

Sofern es kein natives Modul ist, kannst du einfach die en.php in eine de.php kopieren, die Datei öffnen und die Items übersetzen. Bei mitgelieferten Standardmodulen (aktuell zumindest diejenigen, deren Name mit ps_ beginnt, z.B.  ps_legalcompliance) geht das nicht mehr, weil sich die Übersetzung auf verschiedene Ressource-Dateien verteilt.

Link to comment
Share on other sites

Am Ende sind Deine Antworten gleich mehrfach freigeschaltet worden :)Danke, den Tipp mit dem Kopieren kannte ich noch nicht! Leider geht es unter anderem um native Module...

Aber ich habe inzwischen noch etwas merkwürdiges gesehen. Die URL, wenn ich die Übersetzungen aufrufe, sieht so aus:

/index.php/improve/international/translations/modify?form[modify_translations][translation_type]=modules&form[modify_translations][module]=41&form[modify_translations][language]=de

Was sollen denn diese Klammerausdrücke in der Adresse? Wird da was nicht richtig aufgelöst? In einer Standard-Installation der gleichen PS-Version sieht das so aus:

/index.php/improve/international/translations/?lang=de&type=modules&locale=de-DE&selected=ps_wirepayment&_token=s68Y8ukK6CldtVc2vji6RO562rMCv6GaKaaYyS9usNk

Nicht enden wollendes Mysterium...

Link to comment
Share on other sites

Hm,

inzwischen bekommen wir vereinzelt Rückmeldungen, dass die Leute bereits beim Einloggen mit Fehler 500 geschmissen werden, sich dann ein neues Passwort machen müssen und dann ihre Bestellungen platzieren können. Bekannter Fehler?

Backend-Fehler lass ich mir ja noch gefallen, aber jetzt geht das auch im Frontend los. Gibt es Erfahrungswerte, was dem PS gar nicht schmeckt hinsichtlich Serverconfig?  Da wir den nicht verwalten, tappen wir im Dunkeln. Kann das ein Cache Problem sein? Einfach mal alle Cache Module ausschalten? Als wir das das letzte mal probiert haben, ist der Server-Cache komplett vollgelaufen und es ging gar nichts mehr :(

Irgendeine Idee?

Carsten

Link to comment
Share on other sites

Hallo Carsten,

dann sind es aber wohl nicht nur die Übersetzungen. Ich hatte sowieso von Anfang an die Vermutung, dass eure Serverkonfiguration vielleicht nicht so ganz für 1.7 geeignet ist. Vielleicht kannst du ja mal einige Eckdaten posten (siehe Forenregeln für nähere Infos).

Was die Übersetzungen nativer Moduld anbelangt - die sind ebenso wie die Core-Übersetzungen im Verzeichnis app/Ressources/translations...

Das ist aber jetzt nicht mehr Legacy, sondern Twig, d.h. ein ganz anderes Übersetzungssystem. Die xlf-Dateien hier sind viel umfangreicher, ganz anders aufgebaut und folgen einer anderen Logik. Deshalb sind sie auch viel aufwendiger zu pflegen. Kopieren wie bei den php-Dateien ist hier nicht möglich, und wenn es über das Backend nicht geht, so bist du erstmal mattgesetzt.

Link to comment
Share on other sites

Guten Morgen,

die Befürchtung steht im Raum, ja. Blöderweise ist das nicht unser Server, er wird von einem zweiten Dienstleister bereitgestellt. Das hier kann ich im Backend sehen:

Serverdaten: Linux #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64
Version der Server-Software: Apache/2.4.29 (Ubuntu)
PHP-Version: 7.2.19-0ubuntu0.18.04.1
Speichergrenze: 2048M
max_execution_time: 300
Upload (max. Dateigröße): 64M
Datenbank: MySQL-Version 5.7.26-0ubuntu0.18.04.1
PrestaShop-Version: 1.7.5.0

Müsste man für eine Einschätzung noch andere Daten haben? Die müsste ich anfragen.

Was Serverkonfiguration angeht, haben wir uns bislang immer auf die Hoster verlassen und solange im Backend grüne Haken waren, war alles okay ;)

Der Shop an sich rennt jetzt nicht unbedingt, aber es ist erträglich.

Die Übersetzungspakete haben wir shcon ein paar Mal von Crowdin runtergeladen und selber auch ein paar Eingaben dort gemacht. Aber die Übersetzungen gelten ja nur für den Core, richtig?

Dieser Mischmasch aus verschiedenen Systemen nervt...

Danke für Deine Hilfe.

Carsten

Link to comment
Share on other sites

Mir ist gerade noch was eingefallen:

Wir haben im Laufe des Aufbaus erst den APC Cache aktiviert, später dann aber auf MEMCache umgeschwenkt. In der PHP.ini sehe ich gerade, dass beide Module noch aktiv sind. Wir nutzen MEMCache, bekommen im Bakcend aber zudem eine eher seltsame Liste verfügbarer Cache-Arten angezeigt (Screenshot, 2x MEMCached ???). Sollte man das vielleicht mal "entschlacken"? Und welcher Cache ist überhaupt empfehlenswert?

Carsten

screenshot_20190705_094821.png

Link to comment
Share on other sites

Bei Memcache und APC muss ich leider passen, aber ich glaube nicht, dass die Verwendung konkurrierender Cache-Systeme einem ordentlichen  Funktionieren des Shops zuträglich ist. Ist denn auch noch der Prestashop-eigene Cache aktiviert (weiter oben auf der selben Seite)?

Ansonsten scheint mir die Serverkonfiguration ok. Du solltest aber die max_input_vars prüfen. Der Standard von PHP 7 (1000) reicht hier nicht aus. Meines Wissens ist Prestashop 1.7.5.0 auch noch nicht 100%ig an PHP 7.1 angepasst. Da wäre vielleicht doch ein Upgrade fällig, wenn es denn schon unbedingt diese Entwicklungdlinie sein muss.

1 hour ago, comfuse said:

Die Übersetzungspakete haben wir shcon ein paar Mal von Crowdin runtergeladen und selber auch ein paar Eingaben dort gemacht. Aber die Übersetzungen gelten ja nur für den Core, richtig?

Ja, habe ich gesehen: Vor ca. 2 Jahren 35 items mit 254 Worten. (In Statistik sind die bei Crowdin ganz groß 😁). Und nein, die Übersetzungen beinhalten auch die Standard-Module. Falls ihr übrigens in jüngster Zeit, d.h. nach eleazars Rückzug von Crowdin die deutsche Übersetzung importiert habt, war das nicht unbedingt von Vorteil. Erstens ist sie jetzt nicht mehr ganz vollständig und zweitens haben sich beim Upload Fehler eingeschlichen. Da es aktuell keinen aktiven Proof Reader für Deutsch gibt, wird das wohl auch  noch eine Weile so bleiben.

Link to comment
Share on other sites

Nein, die Übersetzungen von Crowdin nutze ich schon einige Zeit nicht mehr.

Die max_input_vars hatten wir vorsorglich (und weil der Attribute Wizard in dieser Hinsicht ja königliche Anforderungen hat) auf einen absurd hohen Wert gestellt (10.000?), damit da nichts anbrennt. Das ist aber auch nicht gerade die feine Art, hat der Webhoster gesagt. Ich wüsste nicht warum, aber kann das die Installation unsicher machen?

Den APC würdest Du also wieder deinstallieren?

Wir haben den Smarty-Cache ausgeschaltet, aber CCC aktiv.

Carsten

Link to comment
Share on other sites

4 hours ago, comfuse said:

Nein, die Übersetzungen von Crowdin nutze ich schon einige Zeit nicht mehr.

Äh, das meinst du aber jetzt nicht ernst? Jeder nutzt sie, auch du. Denn man lädt sie bei Aktualisierung/Import einer Sprache via Prestashop-Server auf den eigenen Webspace. Prestashop beschäftigt keine eigenen Übersetzer.

Link to comment
Share on other sites

Ach so, das wird direkt von Crowdin als Übersetzungspaket geladen? Ich dachte, das müsse man immer proaktiv machen, also die xlf runterladen, in DE umbenennen und dieser ganze Zipp und Zapp. War das nicht mal so?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...