Hallo zusammen, nach dem Kauf des des französischen Sprachpakets übersetzte ich derzeit fleißig die Artikelstammdaten im shop-backend. Leider gibt es immer wieder folgende Probleme: - Beim Eintragen der französischen Artikel-Texte (Beschreibung, Kurzbeschreibung, Keywords, etc.) über das zugehörige zugehörige Shopware-Translation-Fenster (öffnet sich ja bei klick auf das Flaggen-Icon neben dem Textfeld) werden Sonderzeichen beim Eingeben korrekt dargestellt, das Abspeichern scheint diese Sonderzeichen aber zu korrumpieren. Aus einem é oder à werden dann komische Zeichenketten wie é oder é. Teilweise sind die auch unterschiedlich lang. Also wird ein französisches Zeichen nicht immer in die gleiche komische Zeichenkette “übersetzt”. Sofern man dann anschließend nochmal das Translation-Fenster öffnet und den text wieder speichert, werden die komischen Zeichenketten noch “verlänger” oder verdopplet. Dann wird aus einem “â á é è a Ô ein "â á é è a à" uns so weiter… Selbst beim manuellen Einfügen von Sonderzeichen über den kleinen Editor im Translation-Fenster werden diese beim Speichern falsch konvertiert und bei jedem weiteren Speichervorgang verlängert/verdoppelt. Gleiches negatives Resultat erlangt man, wenn man den Artikel dupliziert oder die Texte per Copy&Paste aus der Zwischenablage in das Translation-Fenster einfügt. Gibt es hierzu Ideen, was ich ändern oder überprüfen kann? Vielen Dank für helfende Anregungen. Carsten
Hi Carsten, das kann ich nicht bestätigen. Das kann eigentlich nur mit deinem Server zusammenhängen. Ein Shopware Problem ist das nicht. Habe es gerade noch einmal in verschiedenen Shop-Umgebungen getestet inkl. vieler Sonderzeichen. Das Abspeichern, sowie öffnen und wieder bearbeiten verlief immer korrekt. Es gab hier im Forum schon einmal einen ähnlichen Fall - Siehe hier: installation-einstieg-f9/kyrillische-umlaute-in-artikelbeschreibung-t4000.html?hilit=%C3%BCbersetzung#p21804 Vielleicht ist das auch bei dir die Lösung!
Hallo, ich habe auch einen ähnlichen Forum-Eintrag gefunden. Der weisst ziemlich genau auf den gleichen Effekt hin (auch wenn es bei der Übersetzung von E-Mail-Vorlagen geht). administration-f11/ubersetzung-fur-subshop-fehler-bei-umlauten-t1048.html?hilit=%C3%BCbersetzung#p5895 ich habe aber 3.5.5 installiert und dort ist der besagte eintrag in der .htaccess nicht mehr vorhanden. Mit Server meinst Du den DB-Server oder den Web-Server? Danke + VG, Carsten
Hallo Sebastian, hinsichtlich multibyte sagt meine phpinfo: Multibyte Support enabled Multibyte string engine libmbfl Multibyte (japanese) regex support enabled Multibyte regex (oniguruma) version 4.4.4 Multibyte regex (oniguruma) backtrack check On mbstring extension makes use of “streamable kanji code filter and converter”, which is distributed under the GNU Lesser General Public License version 2.1. Directive Local Value Master Value mbstring.detect_order no value no value mbstring.encoding_translation Off Off mbstring.func_overload 0 0 mbstring.http_input pass pass mbstring.http_output pass pass mbstring.internal_encoding no value no value mbstring.language neutral neutral mbstring.strict_detection Off Off mbstring.substitute_character no value no value allzu viel kann ihc nicht damit anfangen, aber es sieht zumindest so aus als wäre diese Option aktiviert. VG, Carsten
Hallo, noch ein paar Infos. Mittlerweile habe ich herausgefunden, dass diese “komischen” Zeichen es bis in die DB-Tabelle s_articles_translations schaffen und dort abglegt sind (name, keyword, description, description_long). Zumindest sehen die Zeichen gleich aus, wenn ich die Einträge per phpmyadmin ansehe. In der tabelle s_core_multilanguage steht bei allen 3 vorhandenen Sprachen (DE, EN, FR) kein wert in der Spalte “encoding”. Kann das irgendwie damit zusammenhängen? Ich habe das Plugin Subshop-lite im Einsatz. VG, Carsten
Hallo, noch etwas mehr Verständnis gewonnen: sofern man eine Übersetzung erstellt (welche Sonderzeichen/Umlaute enthält) und diese zum ersten mal abspeichert, werden diese zeichen korrekt im entsprechenden Eintrag in der Tabelle s_core_translations abgelegt (also korrekt mit ü, Ü, ä, Ä, á ,è oder ähnlich). Öffnet man dann diese Übersetzung erneut im Backand werden dann schon im Translation-fenster die komisch übersetzten Zeichenketten (z.B. ö á È) angezeigt. Speichert man erneut, werden die flaschen Zeichenketten auch in den Eintrag der Datenbanktabelle abgelegt. Wiederholtes öffnen und speichern, macht die Sache nur noch schlimmer, denn die seltsamen Zeichenketten werden noch verlängert/dupliziert. Andere Frage, was ist der genaue Unterschied (in der Nutzung) zwischen den DB Tabellen s_core_translations und s_articles_translations? Vielen Dank, Carsten
Passen in deinem Shop denn alle Systemvoraussetzungen? Kannst du mal in der Systeminfo prüfen ob dort ggf. eine Einstellung nicht passt? s_article_translations ist für die Suche zuständig. Diese wird vom System dynamisch angelegt. Die eigentlichen gepflegten Übersetzungen werden in der s_core_translations gespeichert. Ich vergleiche noch deine Einstellungen mit meiner phpinfo, evtl. kann ich da schon einen Unterschied erkennen.
Hi, in Systeminfo->Serverkonfiguration gibt es drei Einträge, welche mit dem roten X gekennzeichnet sind: register_globals benötigt:0 vorhanden:1 Status:X allow_url_fopen benötigt:1 vorhanden:0 Status:X safe_mode benötigt:0 vorhanden:1 Status:X alle anderen Einträge sind auf grün. Die Zugriffsrechte auf den Verzeichnissen sind auch alle grün und die aufgeführten Shopware-Datein sind alle in der Version 3.5.5 vorhanden und grün markiert. VG, CArsten
Das sind schon sehr wichtige Punkte die unbedingt passen müssen für den Einsatz von Shopware! Die solltest du bzw. dein Hoster auf jeden Fall im Vorfeld korrigieren.
Hallo , allerdings sehe ich da noch keinen direkten Zusammenhang mit dem beschrieben Effekten… Kann das überhaupt damit zusammenhängen? VG, Carsten
Ich habe das problem lösen können. Der Hinweis auf die Systemeinstellung hat zwar nichts dirket geholfen, denn auch nach deren Anpassungen auf register_globals benötigt:1 vorhanden:1 Status: grün allow_url_fopen benötigt:1 vorhanden:1 Status:grün safe_mode benötigt:0 vorhanden:0 Status:grün war der effekt noch nicht verschwunden. Allerdings ist mir dabei noch einen Konfigurationsparameter vom Webhoster mit der bezeichnung “add_default_charset” welcher aktiv war. Dieser scheint zu bewirken (zu erzwingen), dass immer der default character set des Webservers verwendet wird. Hier die Beschreibung vom hoster: “Damit können Sie bestimmen, ob ihr Webspace unter dem Standardzeichensatz des Servers (ISO-8859-1) läuft.” So ganz verstehe ich das noch nicht den der ISO-8859-1 oder Latin-1, Westeuropäisch enthält ja eigentlich die deutschhen Umlaute und die französischen Sonderzeichen… Naja, wie auch immer jetzt klappt es zumindest bei neuen Einträgen. Die bereits übersetzten Texte muss ich jetzt aber korrigieren. Wenn es dazu vielleicht Ideen gibt? Vielen Dank, Carsten