Jump to content
comfuse

Übersetzung "Installierte Module" nicht aufrufbar

Recommended Posts

Posted (edited)

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)

Share this post


Link to post
Share on other sites

Wie ich gelesen habe, bleibt laut Chefentwickler das Bugfixing im Übersetzungsteil von 1.7 einem späteren Upgrade vorbehalten. Dieser Bereich funktioniert derzeit nur korrekt in Versionen kleiner 1.7.

Share this post


Link to post
Share on other sites

Wie macht man denn dann in der 1.7 manuell Übersetzungen, wenn noch zudem die Übersetzungsdateien im Modulordner (z.b. translations/de.php) selbst leer sind. Gar nicht? ;)

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Wann wird endlich der französische Forenadmin rausgeworfen? So kann man doch keine effektive Hilfe geben, wenn jedesmal der Post erst freigeschaltet werden muss, weil ihn nur ein Moderator freigeben kann.

Share this post


Link to post
Share on other sites

Tut mir leid, aber hier regiert seit Monaten das Chaos. Meine Antwort harrt der Freigabe durch einen Moderator.

Share this post


Link to post
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...

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
Posted (edited)

Auf meine Antwort musst du noch warten. Da hat wohl wieder des großen @ttoines Blacklist zugeschlagen. Allmählich ist es wohl an der Zeit, dass der Forenadmin eine Liste standardisierter erlaubter Ausdrücke für Posts herausgibt. 

Edited by Wuschel (see edit history)

Share this post


Link to post
Share on other sites

Wie heißt das bei Facebook im Besziehungsstatus? "Es ist kompliziert" :)

Ich danke trotzdem im Voraus und wünsche ein schönes Wochenende!

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More