Umlaute Alias in UTF-8 weg

[homtata]

Hallo Community,

ich finde für mein Problem keine Lösung, nur ähnliche, aber nicht wirkungsvolle Ansätze:
Mein Mandant (Contenido 4.8.15) läuft mehrsprachig, alle Sprachen in UTF-8, diverse XML und .po-Dateien sind angepasst.
Es läuft das AMR-Plugin von xmurrix in der neuesten Version.

Problem:
Sämtliche Aliase auf Kategorie- und Artikelebene verlieren die Umlaute, was den Kunden in den Suchmaschinenergebnissen bös nach hinten hat rutschen lassen, bis mir das auffiel.
Die functions.api.string.php ist in der neuesten Version online (die früher mal für fehlende Umlaute in der "normalen", nicht UTF-8 Version verantwortlich war).
Hat jemand eine Idee, wie ich die Umlaute wieder automatisiert in den Alias kriege? Ich will das nicht ständig händisch anpassen müssen...

LG

[Oldperl]

Hallo homtata,

beim Umschreiben der Aliase wird in der 4.8.15 das Encoding nicht berücksichtigt, soviel ich weiß wurden sie in 4.8 selbst sogar nur mit den entsprechenden Doppelbuchstaben ersetzt. Daher funktionieren auch keine Umlaute in den Alias-Namen.
Ich bin mir jetzt nicht sicher ob ich das in der CL-Edition schon gefixt habe, ich schreib es mal auf meine ToDo. Ansonsten mußt du auf die 4.9er warten, bzw. mit der erschienen Alpha mal lokal testen ob sie das Problem behebt.

Gruß aus Franken

Ortwin

[homtata]

Hallo Ortwin,

ich habe sowas befürchtet - ich hatte nur gehofft, dass es anders wäre, weil in der functions.api.string.php drin steht, dass sie auch UTF-8 berücksichtigen würde... und ich bin mir tatsächlich nicht mal sicher, ob das in einer früheren Version nicht geklappt hat (wir sind schon mindestens seit 4.8.6 damit online), denn ich denke, es wäre mir damals aufgefallen, wenn die Aliase nicht stimmen. Aber: ich kann mich auch täuschen..

LG
Viktor

[homtata]

okay, eine echte einfache Lösung habe ich nicht, aber ich weiß, wodurch der Fehler entsteht:
Ich habe Contenido auf utf-8 umgestellt, und alle 4 Sprachen des Mandanten auch auf utf-8 eingestellt.
Dies führt dazu, dass sämtliche Umlaute nicht wie bei iso-8559-1 als solche in der Datenbank landen (con_cat_lang usw.), sondern eben in der Form "Ãœ" für "Ü" usw.

Beim Einrichten der Datenbank habe ich abweichend von meiner sonstigen Gewohnheit die Einstellung "Zeichensatz / Kollation der MySQL-Verbindung" auf utf8_general_ci gesetzt.
Vielleicht war ja auch das schon ein Fehler? Führt DAS zu o.g. abweichenden Speicherung? Hätte ich das nicht tun sollen? Hm.
Könnte ich die Kollation denn im laufenden Betrieb gefahrlos ändern, oder wäre das der Tod?

Auf jeden Fall werden die Aliase dann konsequent falsch umgeschossen, weil die Autoersetzung der functions.api.string.php diese utf-8 Kombinationen nicht kennt und nicht ersetzt.
Entweder müsste man also die functions.api.string.php umbauen (habe ich noch nicht probiert, weil demnächst eh ein Relaunch ansteht), oder ich muss den Mandanten dann wieder auf iso-8559-1 umstellen, dafür dann aber alle Kategorienamen, Artikeleigenschaften usw. anpassen.
Ich bin nicht so tief in der Materie drin um beurteilen zu können, ob die Umlaute mit der utf-8-Einstellung wirklich so in der DB landen sollen, wie sie das im Moment tun ("Ãœ" usw.), oder ob sie dort in Reinform (ü ä ö usw.) landen müssten.

Andererseits ist es so, dass ich nicht gleichzeitig im gleichen Mandanten 1 Sprache in utf-8, die andere in iso-8559-1 laufen lassen kann, ohne dass das zu Darstellungsproblemen im Backend führt. Da jetzt alle xml- und poedit-Dateien auf utf-8 umgeschossen sind, müssten diese sprachabhängig zurückgestellt werden, damit das klappt.

Fazit: irgendwie wird denke ich im Moment in Contenido an zu vielen Stellen an den Sprachcodierungsvariablen rumgeschraubt und rumcodiert, so dass man ohne dauernde händische Anpassungen keine vernünftigen Umschaltungen machen kann. Das bloße Einstellen der Sprachcodierung im Menü Sprachen führt auf jeden Fall zu haufenweise Problemen.

Problem ist nicht wirklich dringend, aber vielleicht kann ja jemand meine Gedanken noch etwas ordnen und seinen Senf dazugeben, dann beachte ich das beim Relaunch, denn da muss ich eh alles nochmal anpacken

LG

[xmurrix]

Hallo homdata,

dass die Kategorie- und Artikelaliase keine Umlaute haben ist eigentlich in Ordnung. URLs sollten idealerweise rein aus ASCII Zeichen bestehen. Auch wenn du es hinbekommst, Aliase mit Umlauten zu generieren und mit solchen URLs umgehen kannst, wird es immer wieder Probleme geben, weil andere damit nicht klar kommen.

Dass sämtliche Umlaute in den Aliasen nicht korrekt umgewandelt werden (ä = ae, ü = ue, usw.) ist ärgerlich. Eine schnelle Lösung wäre das manuelle Anpassen aller Aliase, entweder über das Backend oder gleich auf DB-Ebene.

Gruß
xmurrix

[qualtext]

Gibt es bereits eine Lösung für diese Problem?

Ich habe eine Neu-Installation gemacht (4.8.15 - mit mysql 5.5.2) und hänge bereits einen Tag daran, dass contenido meine Sonderzeichen nicht aus den Kategorie-/Template-/Artikelnamen löscht. Je nach dem, wie ich die Datenbank und deren Tabellen ändere (latin1_...,utf8_...) werden manchmal aus Bezeichnungen wie "löffäl": 'lffl', 'l', 'lf'... die Aliase werden richtig konvertiert (loeffael). In der Sprache ist immer 'iso-8859-1' ausgwählt.

Stelle ich die Sprache in Contenido auf UTF8 um, bleiben die Sonderzeichen im Name, aber das Alias löscht diese raus, ohne sie zu konvertieren (bspw. ä in ae, Alias sieht dan so aus 'lffl').

Liegt es nun an der 5.5.25 Version von mysql oder an der falschen Kollation der Datenbank.

Bei allen anderen Installation hatte es bis jetzt immer geklappt. Nur auf diesem Server nicht.

Code: Alles auswählen

MySQL

    Server: Localhost via UNIX socket
    Server Version: 5.5.25-log
    Protokoll-Version: 10
    Benutzer: contenido@localhost
    MySQL-Zeichensatz: UTF-8 Unicode (utf8)

Webserver

    Apache/2.2.21 (Linux/SUSE)
    MySQL-Client-Version: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $
    PHP Erweiterung: mysqli

Es wäre sau cool, wenn mir jemand helfen könnte. Was könnte ich ändern, damit die Zeichen nicht gelöscht werden, aber dennoch das Alias abgeändert wird.

[qualtext]

@homdata

ich habe dein thread nochmal genau gelesen und da ist mir ne Idee gekommen. Bei mir werden die Aliase richtig geändert, aber aus den Titeln die Umlaute gelöscht. Bei dir ist es andersrum. Ich habe also bei mir auch die Sprache auf UTF8 umgestellt. Dann hatte ich das gleiche Problem wie du. Ich habe die functions.api.string.php mit ein paar prints versehen und mir ist aufgefallen, dass er die Umlaute in dem String gar nicht ersetzen kann, weil er keine findet. Jetzt habe ich über Dreamweaver die Titelkodierung der functions.api.string.php von transitional auf utf8 umgestellt. Er erkennt die Umlaute und ersetzt diese in den Aliasen korrekt!

Vieleicht hilft dir das auch weiter.

Ich muss bei mir jetzt noch die Sprachdateien anpassen, dann sollte alles funktionieren.
Denn bei mir werden im Backend die Umlaute ncoh bspw so ausgegeben: �bersicht

[Faar]

dass die Kategorie- und Artikelaliase keine Umlaute haben ist eigentlich in Ordnung. URLs sollten idealerweise rein aus ASCII Zeichen bestehen. Auch wenn du es hinbekommst, Aliase mit Umlauten zu generieren und mit solchen URLs umgehen kannst, wird es immer wieder Probleme geben, weil andere damit nicht klar kommen.

Umlaute und Sonderzeichen in Aliassen und somit auch URLs sind teilweise äusserst fatal.
Auch wenn es inzwischen Umlaut-Domains und URLs gibt, so ist das mit mehr als nur kleinen Problemen behaftet.
Das eine Programm macht beim Kopieren gleich die %-Codierung, das andere Programm nicht und lässt z.B. ein ä als ä in der URL und schon geht nichts mehr.
Der Tipp, URLs und die Aliasse nur mit ASCII zu machen ist mehr als Gold wert, wenn man nicht der einzige in seiner homogenen Umgebung sein will, der die Links aufrufen kann.