neue Translate Modul is fehlerhaft

[weiricth1]

Das neue übersetzungs modul ist

 

1. von der performence her grausam 

2. übernimmt er nicht alle felder sonder speichert nur das feld (über dem wo der button) gedrückt wurde

 

kann man des irgendwie zurückstellen auf das "alte" von 1.6

 

Grüße

 

Tom

[eleazar]

  On 4/12/2017 at 8:43 AM, weiricth1 said:

und zwar speichert er jetzt die übersetzungen nicht mehr als File sondern also SQL. deshalb auch das einzelne speichern. aber für massen übersetzungen halt echt nervig.

 

Zwar ist das neue Übersetzungssystem auch aus meiner Sicht ein Desaster, aber die Übersetzungen werden keineswegs in der Datenbank gespeichert, also zumindest nicht sofort (s. unten). Das war bisher so für die Übersetzungen der Menüpunkten, aber auch das ist mit 1.7.1 anders. Sie sind nur nicht mehr da, wo sie früher waren, seit man auf Twig und damit auf XLF-Dateien (XML-Format) umgestiegen ist. Wie das im einzelnen aussieht, habe ich hier näher erläutert:

https://www.prestashop.com/forums/topic/537550-prestashop-17-deutsche-übersetzung/#entry2350973

https://www.prestashop.com/forums/topic/537550-prestashop-17-deutsche-übersetzung/#entry2353215

 

Die deutschen Übersetzungen von 1.7 sind abgespeichert in:

/app/Resources/translations/de-DE

Hinzu kommen dann natürlich noch die Modulübersetzungen, die aktuell noch weiterhin als php-Dateien abgespeichert sind.

 

Die Vorauswahl auf der Übersetzungsseite von PrestaShop, die aus dem früheren Programm übernommen wurde, täuscht darüber hinweg, dass die Übersetzungen jetzt ganz anders gruppiert worden sind. Da die neuen Übersetzungsdateien rein nach programmiertechnischen Überlegungen angelegt wurden und nicht mehr wie zuvor auf Bereiche wie Back Office, Front Office etc., ist die Konsequenz tatsächlich, dass jede Variable einzeln gespeichert werden muss. Denn was bei der Suche angezeigt wird (längst nicht alles wird auch gefunden), kann ja aus unterschiedlichen Dateien stammen. Gut, das war vorher auch der Fall, aber anschließend werden dann, wie weiricth1 richtig bemerkt hat, die Änderungen - und zwar nur die Änderungen! - in der Datenbanktabelle ps_translation abgespeichert. Für jede Änderung muss ein eigener Datensatz geschrieben werden.

 

Das gilt allerdings auch dann, wenn man sich schlicht vertan hat und den Reset-Button drückt. Dann wird eben die ursprüngliche Formulierung auch noch mal zusätzlich in der Datenbank abgelegt. Spätestens hier wird's dann vollends absurd!

 

Natürlich kann man diese Datenbankablage jederzeit umgehen, indem man manuell den Eintrag direkt in der jeweiligen XLF-Datei ändert.

Aber für alle diejenigen, die sich nicht sehr gut mit der Programmlogik von PrestaShop auskennen, gilt dann:

Viel Spaß beim Suchen! 

[rictools]

Soweit ich das mitbekommen habe, hat sich das Übersetzungskonzept in 1.7 komplett geändert. Also am besten Hände weg von 1.7, wie hier immer wieder empfohlen wird ...

[weiricth1]

ganz ehrlich die antwort hilft mir ned wirklich weiter. wenn ich jetzt schon 1.7.1 installiert habe und fast fertig bin

[rictools]

  On 4/11/2017 at 7:10 AM, weiricth1 said:

ganz ehrlich die antwort hilft mir ned wirklich weiter. wenn ich jetzt schon 1.7.1 installiert habe und fast fertig bin

Das Leben ist kein Wunschkonzert. Und wir können ja auch nur Ratschläge geben, nicht die Gegebenheiten ändern ...

[Shad86]

Also es lässt sich nicht "zurückstellen" da 1.7 von Grund auf anders aufgebaut ist als 1.6.

Musst du denn so viele Änderungen vor nehmen das einzeln speichern drücken so ins Gewicht fällt?

Du kannst ja alle kurz hintereinander drücken, wartest kurz und alle werden kurz hintereinander gespeichert.

 

Und "fast fertig" ist natürlich so eine Sache. Kannst dir ja den Spaß gönnen und dem Link in meiner Signatur folgen. In Post #8 habe ich eine Auflistung der Probleme die mir an 1.7 aufgefallen sind. Manche mehr oder weniger schlimm. Hast du die gravierenden beseitigt bekommen? Oder bisher nicht aufgefallen?

[weiricth1]

700 für das themplate + alle module also in summe ca. 3000

 

wobei die module noch das alte benutzen. 

[Shad86]

Ärgerlich. Aber ändert ja nichts an der Tatsache. Solltest du Lösungen zu einem der Probleme haben, gern her damit. Möchte auch mit dem Shop raus, kann aber wegen der Bugs nicht.

Vielleicht sind die Probleme bei dir auch nicht oder für dich sind sie nicht so entscheidend. Kann dir nur wünschen (und mir natürlich auch) das Presta etwas hin macht.

[weiricth1]

also ich hab sonst keine bugs mit dem shop. bei mir hat der 1.6 mehr probleme gemacht. naja liegt auch daran das ich den shop eher fernsteuere mit perl scripten auf dem server und das kann der 1.7 besser ab als der 1.6. bei mir is nur die performance der übersetzung echt nerfig. aber ich weiß schon warum er das macht. und zwar speichert er jetzt die übersetzungen nicht mehr als File sondern also SQL. deshalb auch das einzelne speichern. aber für massen übersetzungen halt echt nerfig.

[Lausli]

Schade ist es, aber da hättest du wohl den grundsätzlichen Ratschlag befolgen sollen, der immer und überall in der IT gilt: Fragen vor dem Kauf!

 

  Quote

 

kann man des irgendwie zurückstellen auf das "alte" von 1.6

Nein, das geht nicht. Thema erledigt.

 

 

  Quote

 

naja liegt auch daran das ich den shop eher fernsteuere mit perl scripten auf dem server und das kann der 1.7 besser ab als der 1.6. bei mir is nur die performance der übersetzung echt nerfig

Dann mach das doch auch bei den Übersetzungen. Ob nun pearl oder Bash oder PHP oder JS oder oder oder

Edited April 12, 2017 by Lausli (see edit history)

[Shad86]

  On 4/12/2017 at 8:43 AM, weiricth1 said:

also ich hab sonst keine bugs mit dem shop.

 

Wie gesagt, nur aus eigeninteresse: Wie sieht denn deine Bestellbestätigung aus? Also der letzte Schritt wo nochmal alle Kosten angezeigt werden und der Kunde auf Bestellen klicken soll. Ich weiß ja nicht ob du in DE sitzt aber so wie die Übersicht bei mir aussieht bin ich mir nichtmal sicher ob es im B2B Geschäft Rechtssicher ist.

[weiricth1]

oh man, ich hasse immer diese unterstellungen. natürlich hab ich mich erkundigt etc. und mich aktiv für 1.7 entschieden. und es gibt immer workarounds oder sonstiges mit denem man arbeiten kann. und nach so einer such ich grad. 

[weiricth1]

  On 4/12/2017 at 8:57 AM, Shad86 said:

Wie gesagt, nur aus eigeninteresse: Wie sieht denn deine Bestellbestätigung aus? Also der letzte Schritt wo nochmal alle Kosten angezeigt werden und der Kunde auf Bestellen klicken soll. Ich weiß ja nicht ob du in DE sitzt aber so wie die Übersicht bei mir aussieht bin ich mir nichtmal sicher ob es im B2B Geschäft Rechtssicher ist.

 

habs dir als pm geschickt. 

[rictools]

  On 4/12/2017 at 8:35 AM, weiricth1 said:

700 für das themplate + alle module also in summe ca. 3000

Dann hat dein 1.7er Shop mit dem Originalshop wohl nicht mehr so viel zu tun, das ist ja keine normales Template, das normalerweise um die 100 Euro kostet, sondern wohl ein speziell angepaßtes (und um mit Standardmodulen auf über 2.000 Euro zu kommen, muß man auch schon viel kaufen).

 

Bei 1.6 hat man für die Übersetzungen am einfachsten und schnellsten die Dateien direkt bearbeitet. Wenn die Übersetzungen jetzt in der Datenbank gespeichert werden, würde ich mir die Datenbank mal anschauen, ob man die Bearbeitung nicht in dieser direkt machen kann (evtl. auch die Tabelle exportieren, in Tabellenkalkulation bearbeiten und wieder importieren).

[weiricth1]

ne nicht euro sondern Anzahl an übersetzungen. und ne is eines von hier aus dem shop, ist halt nur nicht übersetzt ins deutsche. und in summe 3000 inputs für die übersetzung is ned viel.

 

das mit der DB is das problem momentan das ich da noch nicht so ganz durchschau

Edited April 12, 2017 by weiricth1 (see edit history)

[rictools]

  On 4/12/2017 at 9:59 AM, weiricth1 said:

ne nicht euro sondern Anzahl an übersetzungen. und ne is eines von hier aus dem shop, ist halt nur nicht übersetzt ins deutsche. und in summe 3000 inputs für die übersetzung is ned viel.

 

das mit der DB is das problem momentan das ich da noch nicht so ganz durchschau

Sorry, das hatte ich jetzt falsch verstanden ... Zur Datenbank kann ich nicht helfen, weil ich 1.7 nicht habe.

[Shad86]

Ich bin aber auch von Euro ausgegangen :-)

 

Und von den Datenbanken habe ich bisher auch die Finger gelassen. Möchte ich auch nicht unbedingt dran wenn es nicht sein muss.

 

Aber bisher waren die tabellen doch recht eindeutig benannt.

[rictools]

Ist aber auch kein Hexenwerk (sichern natürlich obligatorisch!), solange man nur Texte oder Werte ändert und nicht an der Struktur rumbastelt.

[Shad86]

Nein, das ist richtig und habe ich im 1.5er auch gemacht. Aber spätestens wenn die Kunden eingespielt sind bin ich da extrem vorsichtig.

[rictools]

Die Übersetzungen werden ja nicht mit Kundendaten verknüpft sein ...

[weiricth1]

das problem ist das die tabelle mit garnix verknüpft ist :-)

 

id_translation;id_lang;key;translation;domain;theme

 

und (was ja mal gut ist) es wird nur das geschrieben was übersetzt wurde also in meinem fall sind da jetzt 33 stück drin (fehlen noch 677) die nirgends in der DB stehen. 

[Shad86]

Mit anderen Worten müsste man es erstmal im Backend machen damit du die ID der Übersetzung usw bekommst und könntest dann weiter Änderungen direkt in der Datenbank machen?

 

Und ja ich hoffe mal das es eine eigene Tabelle ist aber ich geh erstmal vom schlimmsten aus, da ich da noch nicht rein geguckt habe.

[weiricth1]

ja das mit den XML datein hab ich auch schon raus :-) schöner wäre zwar (das was ja XML vorsieht) das man nur eine XML datei hätte, dann wäre das ganze echt einfach. Warum die haupt entwickler das geändert haben ist mir auch klar. das problem ist das php value "input vars" das wenn du jetzt wie ich 7000 datensätze hättest, dann geht das bei den meisten nicht weil die nur 1000 oder so und das "händische" verbiegen der .htaccess datei oder php.ini nicht wirklich sinnig ist.

 

ein vorteil (den ich aktuell noch habe) ist das die Module noch das "alte" verwenden. dadurch kann man des echt schnell übersetzen. 

 

und für die XML hab ich mir nen kleines Script geschrieben und lass des gegen google laufen und "berichtige" nur noch was weniger aufwand ist. 

 

Danke für die hilfe

[eleazar]

Nein, die max_input_vars waren noch nie ein drängendes Problem für das PrestaShop-Team.   Die Entscheidung für Twig hatte wohl andere Gründe.

Ganz sicher wird jedenfalls die Kompatibilitätseinstellung für die Module bald wegfallen, denn auch die Core-Module sind inzwischen alle "umgerüstet" worden.

Es war ja auch nie die Rede davon, dass PrestaShop 1.7 in Sachen Templates und Module abwärtskompatibel sein sollte.

 

Vielleicht könntest du ja dein Skript mal zur Verfügung stellen, damit auch andere User etwas davon haben. Wie wär's?