Hallo, wie kann es eigentlich sein, dass angepasste Texte (entweder im Admin über Texte anpassen) oder in Dateien zunächst übernommen werden, aber beim nächsten Update dann wieder weg sind? Spannend wird es ja auch bei solchen Texten, die rechtlich heikel sind - z.B. dass bei Streichpreisen der alte Preis plötzlich wieder wie in Englisch RRP (= UVP) heißt, obwohl es keine UVP ist. Ich habe das schon gefühlt 10x korrigiert, jetzt ist es wieder da....
Hallo, mir sind keine Bugs bekannt und an dem System dazu haben wir in den letzten Jahren nichts verändert. Es gilt die Priorität Änderung über Texte anpassen überschreibt Text aus user_sections Datei die Text aus original_sections überschreibt. Wenn du also deine Änderungen über Texte anpassen machst, gehen sie nie verloren. Machst du sie in einer user_sections-Datei geht sie verloren, wenn du die Datei überschreibst, weil sie z. B. Teil eines Drittanbieter-Moduls ist (Gambio selbst nutzt die Dateien nicht) und wenn du in original_sections was veränderst geht es verloren, wenn z B. ein Service Pack die Datei überschreibt. Texte anpassen ist also der sichere Ort für Änderungen.
Es geht hier z.B. um die price.lang.inc.php also um eine Shop-eigene Datei, die ich für Französisch so gemacht habe im Jahre 2015. Code: <?php $t_language_text_section_content_array = array( 'old_special_price' => 'Notre ancien prix ', 'new_special_price' => 'Nouveau prix ', 'old_discount_price' => 'notre prix standard ', 'new_discount_price' => ' votre prix ', 'old_group_price' => 'notre prix standard ', 'new_group_price' => 'votre prix ', 'you_save' => 'vous économisez ' ); Die Datei ist auch so noch seit dem 9.5.2015 unverändert auf dem Server unter /lang/french/original_sections/ Die Datei existiert nicht in lang/french/user_sections/ old_special_price ist offenbar in die Datenbank geschrieben worden damals, weil ich sie sonst unter "Texte anpassen" nicht finden würde, richtig? Es gibt aber nur den Original-Text (der jetzt falsch ist), aber keinen angepassten Text. Da es keinen angepassten Text in der Datenbank gibt und keine Datei in user_sections, dürfte doch eigentlich nichts überschrieben oder überladen werden, und vor allem kann daraus niemals "RRP" werden, weil das offenbar aus dem englischen Sprachpaket kommt. Aber vor allen Dingen: Wenn es schonmal richtig in der Datenbank stand, dann dürfte doch in gar keinem Fall was anderes daraus werden. Jedenfalls ist jetzt z.B. old_special_price wieder RRP statt Notre ancien prix. Ich kann es gar nicht erklären, es sei denn Französisch wird gar nicht als Sprache erkannt und als Fallback wird auf Englisch zurückgegriffen. Oder es gibt einen Bug mit der language_id? Das selbe übrigens auch mit Niederländisch.
Ist es jetzt in diesem Moment noch falsch? Falls ja, kannst du einmal einen Screenshot von der Texte anpassen Seite schicken, nachdem du nach "old_special_price" gesucht hast?
Ja, habe ich extra so gelassen. Hier auch noch ein Screenshot von den FTP-Ordnern. Und noch ein Screenshot, auf dem nur angepasste Texte aufgelistet werden und wo das nicht dabei ist. Ich verstehe nicht, warum sich das auf RRP geändert hat. Und selbst wenn es nicht neu wäre, könnte ich auch nicht erklären, warum es überhaupt jemals RRP geworden ist beim Einrichten der Sprache. Betrifft nicht alle Sprachvariablen keine deutschen und keine englischen Texte, soweit ich es sehe.
Habe gerade auf archive.org nachgesehen: Im Oktober 2020 hieß es auch RRP. Also vielleicht doch kein neues Problem, aber seltsam trotzdem wo das RRP herkommt, wenn doch die Textdateien passen und es keine Anpassungen in der Datenbank gab? Soll man denn dann überhaupt bei Übersetzungen noch mit Dateien arbeiten, oder lieber gleich in die Datenbank hochladen?
Das sieht so wirklich nach einem Bug aus. Heute komme ich nicht mehr dazu mir das anzusehen, aber ich habe es mir mal notiert und melde mich wieder, sobald ich mehr weiß.
Wenn ich jetzt ein paar Tausend Sprachvariablen in den Dateien habe und nicht von Hand überprüfen möchte, ob die falsch in die Datenbank übernommen wurde oder nicht - kann ich dann auch einfach von language_id 2 alle language_sections neu anlegen für jede andere language_id (insert ignore, so dass es keine Dopplungen gibt) und dann die language_section_phrases für eine Sprache alle updaten mit den Daten aus den Sprachdateien? Dann würde ich mir dafür ein kleines Script basteln. Oder fehlt dann was? *_cache und *_edited muss ich ja nicht befüllen, oder?
Hallo, ich glaub wir haben das gleiche Problem, da verschiebt oder verschwindet auch immer irgendwas an übersetzten Sachen, es ist elemtar wichtig, das man nicht eine Mischmasch-Rechnung hat, irgendwo hakt es. Der Shop muss mit mehreren Sprachen updatesicher bleiben, funktioniert das ?
Achso. Bin mir nicht sicher was du meinst - Ist das hier nicht das was du wissen möchtest? (Link nur für registrierte Nutzer sichtbar.) Oder wo muss ich schauen?
Entscheidend ist das, was da steht, wenn du den Section-Namen mit der Maus hoverst. Da steht nämlich die Datenquelle, so dass wir wissen, woher das falsche RRP kommt.
Achso, du meinst in der Datei oder? <?php $t_language_text_section_content_array = array( 'old_special_price' => 'Notre ancien prix ', 'new_special_price' => 'Nouveau prix ', 'old_discount_price' => 'notre prix standard ', 'new_discount_price' => ' votre prix ', 'old_group_price' => 'notre prix standard ', 'new_group_price' => 'votre prix ', 'you_save' => 'you save ' );
Nein, wie auf meinem Bild zu sehen ist! Der Mauszeiger ist im Bild nicht zu sehen, ist aber über "price".
Bitte sehr. Auch direkt geprüft: An der Stelle steht tatsächlich RRP Was bedeutet das? Die Datei ist versehentlich doppelt drin und die /product/ wird vorrangig behandelt? Oder ist die andere an der falschen Stelle und greift deshalb nicht? Oder wurde das alles mal bei irgendeinem Update verschoben, aber nur für die Standard-Sprachen?
Müssen denn die Dateien in user_sections auch alle in Unterordner gelegt werden? Oder kann ich die da einfach alle in den Hauptordner legen, und dann werden ohnehin immer die user_sections Dateien prioritär verwendet? Oder ist das alles ohnehin hinfällig, weil die ganzen falschen Texte schon 1x in die Datenbank gezogen wurden und daher auf die Dateien nie mehr zurückgegriffen wird?
Bei mir (nur DE-Texte) werden die Dateien in user_section mal direkt genommen und mal müssen sie im Unterordner stehen. mit Unterordner ist es aber übersichtlicher als ohne, finde ich.
Updates verschieben nichts in Nicht-Standard-Sprachen. Jedenfalls solltest du dann doppelte Dateien weglöschen, wenn sie dieselben Section-Namen enthalten. Gibt es mehrere Sections, ergänzen sie sich bzw. überschreiben sie sich. Alles in die user_sections zu packen macht nicht wirklich Sinn oder bringt keinen wirklichen Vorteil. Die beste Lösung ist für einen korrekten Stand im original_sections-Ordner zu sorgen. Die Datenbank (Cache) ist da irrelevant, da das neu geschrieben wird, wenn man den Text-Cache leert.
Also ums nochmal alles so klarzukriegen: In der Datenbank ist die Tabelle language_phrases_cache egal, weil sie ohnehin bei jedem Texte-Cache-Leeren weg ist In der Datenbank bleibt language_phrases_edited immer bestehen, das sind die von Hand angepassten Texte. Das ist Prio 1 und übergeht alle Texte aus den Dateien, abgesehen vom Cache. language_section_phrases ist dann in der Datenbank... ? Einfach nochmal das aus den Dateien gespiegelt? Wenn ja, geht das vor oder nach den Dateien? Oder ist das für ganz andere Zwecke? Da steht viel Admin-Krams drin. Priorität ist immer: Datenbank-Cache (falls vorhanden), dann in language_phrases_edited, falls vorhanden, dann user_classes Ordner und Unterordner, wobei jede Datei nur 1x vorkommmen soll/darf, dann original_sections. Und wenn das da auch nicht drin steht, dann wird die Konstante verwendet und das Ganze gar nicht aufgelöst? Wenn man eigene Sprachen führt und man spielt ein Update-Paket ein - muss man dann jede Sprachdatei aus dem Update-Paket einzeln in die Hand nehmen und schauen, was darin neu ist? Ich hatte immer gehofft, dass nur neue Phrases aus den Dateien in die Datenbank gezogen werden und der Rest so bleibt wie er ist. Spricht was dagegen, neue Nicht-Standard-Sprachen gleich alle in angepassten Texten in der Datenbank zu pflegen? Ist die Datenbank schneller oder sind die Dateien schneller?