kyrillisch in der Navigation

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

kyrillisch in der Navigation

Beitrag von JSommer » Do 24. Feb 2005, 23:21

...so, mal nachgedacht: Wenn ich in der Navigation kyrillisch brauche, sollte ich doch wenisgtens auf den Iso-Zeichensatz ISO 8859-5 stellen (oder?). Hm, jetzt hab ich noch die Templates für die Navigation... muss ich denen nochmal explizit den ISO-Zeichensatz zuweisen - also hier mein Template für die Hauptnavi:

Code: Alles auswählen

<!-- BEGIN:BLOCK -->
      <tr><td width="165" colspan="2" height="22" style="border: 0px; border-bottom:1px; border-color: #737373; border-style: dashed; padding-left:10px" background="images/mainarray/nav_backdots.gif">
      <a target="{TARGET}" href="{HREF}">{NAME}</a></td></tr>
<!-- END:BLOCK -->
Muss ich da nochmal den ISO-Zeichensatz reinschreiben, damit der auch kyrillisch in der Navigation darstellen kann? Oder vielleicht im Navigationsmodul? Wenn ja, wo muss ich das reinpacken? Freue mich auf Feedback - weil - ich habe da noch immer das Problem (trotz der CVS Version vom 18ten Februar) dass er zwar im Backend bei der Kategorienverwaltung den richtigen kyrillischen Begriff anzeigt - der sieht so aus:
Яю№ђєхыќ
aber im Frontend in der Navigation das hier ausgibt:
Ïîðòôåëü
- wie mach ich das nun, dass das gut tut?! :)

See: http://www.walterco.de/so/cms/front_con ... angelang=5

Halchteranerin
Beiträge: 5478
Registriert: Di 2. Mär 2004, 21:11
Wohnort: Halchter, wo sonst? ;-)
Kontaktdaten:

Beitrag von Halchteranerin » Do 24. Feb 2005, 23:33

Ich wuerde mal so rein vom Logischen her sagen, dass du deine ISO-Angabe im Layout machen musst, weil die Navigation doch innerhalb der HTML-Seite dargestellt wird, und du gibst doch nicht in jeder Tabellenzeile den Zeichensatz an ... die Templates werden im Layout eingebunden.

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Do 24. Feb 2005, 23:41

Wenn ich in den Head des Templates reinschreibe

Code: Alles auswählen

<meta http-equiv="content-type" content="text/html; charset=iso-8859-5" />
gibt er aber immernoch seltsame Zeichen aus :(

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Fr 25. Feb 2005, 00:10

Weiterhin muß das im Backend berücksichtigt werden - andere ISO-Encodings gehen derzeit nur mit den Entwicklerversionen.

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Fr 25. Feb 2005, 00:40

ich hab doch die cvs version vom 18ten februar, dachte, mit der gehts?

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Fr 25. Feb 2005, 09:07

Entwicklerversionen = CVS Versionen

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Fr 25. Feb 2005, 09:41

na, dann bin ich ja aktuell - aber wie gesagt, das backend stellt es richtig dar, das frontend nicht ... :-)

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Mo 28. Feb 2005, 17:16

Also ich bin da echt viel am rätseln... Hab immernoch keine Lösung gefunden, damit die Navigation auch kyrillisch im Frontend erscheint - wie gesagt, im Backend wirds als Kategorie richtig angezeigt...

timo
Beiträge: 6284
Registriert: Do 15. Mai 2003, 18:32
Wohnort: Da findet ihr mich nie!
Kontaktdaten:

Beitrag von timo » Mo 28. Feb 2005, 17:26

stimmen die Encodings im Front- und im Backend überein? Wichtig ist das, was z.b. beim Firefox unter "View Page Info" steht.

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Mo 28. Feb 2005, 17:50

Das Problem liegt tiefer. Contenido codiert hier IMHO einmal zuviel.

Damit russich angezeigt wird, muss Ïîðòôåëü im HTML-Code ausgegeben werde. Die Kodierung <meta http-equiv="content-type" content="text/html; charset=iso-8859-5" /> führt dann dazu, dass die Browser russisch anzeigen.

Die Angabe Ïîðòôåëü steht so auch im Namen der Kategorie (und wird - aufgrund des korrekten Encodings - im Backend russisch angezeigt). Über das Modul Hauptnavigation wird Ïîðòôåëü als echo db->f(Kategoriename); ausgegeben (vereinfacht ausgedrückt).

Leider kommt diese Ausgabe so nicht im fertigen HTML-Code an, sondern so:
&Iuml;&icirc;&eth;&ograve;&ocirc;&aring;&euml;&uuml;
Und diese "Umschreibung" der Zeichen versteht kein Browser mehr als Zeichen, die für russisch verwendet werden sollen.

Wird Ïîðòôåëü direkt im Modul (zu Testzwecken) ausgegeben, (e.g. echo "Ïîðòôåëü") wird aus den Zeichen beim Abspeichern Unicode, der so auch im HTML-Code ankommt und auch nicht mehr verstanden wird (na ja, er wird als Ïîðòôåëü angezeigt, gleiches Ergebnis).

Dass das Encoding stimmt, kann man sehr schön an
http://www.walterco.de/so/cms/front_con ... angelang=4
sehen. Dort habe ich nämlich (um das Problem auszuschließen) russichen Text im Text(HTML)-Bereich eingegeben (ich weiss gar nicht, was da steht, aber halt rechts von "Homepage cyrillian version").

In HTML sieht das so aus: Çàðåãèñòðèðîâàòüñÿ - hier wird auch nicht nochmal codiert, die Zeichen kommen so im Browser an. Sie werden offensichtlich nur nochmal codiert, wenn sie im Modul ausgegeben werden.

Ich habe versucht rauszubekommen, wie man Zeichen in Unicode oder als & verwenden müsste, um mit korrektem Encoding russisch zu erhalten, habe aber nix gefunden. Ich hoffe, die Information hilft.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Mo 28. Feb 2005, 18:16

Mir fällt da gerade noch was ein.

Wenn man Ïîðòôåëü im Modul Hauptnavigation mit echo "Ïîðòôåëü"; ausgibt, wird daraus beim Speichern Unicode. Wenn man nun das Seitenencoding auf UTF-8 stellt..., nein wird auch nicht gehen, da bei Ausgabe via db->f bei der Anzeige dann mit & codiert wird, argh...

Aber ich probiere es trotzdem mal, mal sehen.

Nachtrag: Nein, gleiches Ergebnis. Bei UTF-8 wird Ïîðòôåëü nicht codiert gespeichert und dann nicht von UTF-8 erkannt.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Mo 28. Feb 2005, 20:58

Stimmt, deswegen hab ich von einem Kollegen, der ähnliches Problem hat (Falsche Ausgabe obwohl die Kodierung auf ISO-8859-1 steht) folgende Funktion bekommen mit dem Tipp, diese mit einzubauen. - Fragt sich nur wo, weil im Text geht es ja, aber in der Navi nicht ... guckt mal hier drauf:

Code: Alles auswählen

function toRU( $str )
 {
   $n = "";
   for($i=0;$i<strlen($str);$i++)
   {
     if (ord($str[$i])>160)
     {
     	$n = $n."&#".(ord($str[$i])+848).";";
     }
     else
     {
        $n = $n . $str[$i];
     }    
   }  
   $t = strip_tags($str);
   $t = str_replace(" ","",$t); 
   $t = str_replace("&nbsp","",$t); 
   $t = ereg_replace("/[, !\n?,:-@<>;1234567890]{1}/"," ",$t);  
   return $t;
}
Die Funktion verwandelt komische Zeichen wieder in kyrillisch ... aber wo ich die genau hinpacke ist mir noch ein Rätsel :-/ Zumal, wie Herr B schon anmerkte, der Code eigentlich korrekt hinterlegt ist, eben nur als &XXX von der Datenbank an den Parser kommt... Nicht ganz einfach

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Di 1. Mär 2005, 10:00

Fragt sich nur wo, weil im Text geht es ja, aber in der Navi nicht
Och, das ist nicht schwer, in der Ausgabe des Hauptnavi-Moduls z.B.. Ich habe es mal eingesetzt und getestet, ändert nichts. Die Funktion erzeugt per se Unicode, wenn ich das richtig verstanden habe (und löscht übrigens Leerzeichen aus dem übergebenen String, wozu auch immer).
eben nur als &XXX von der Datenbank an den Parser kommt
DAS war eine gute Anmerkung (erst wollte ich ja schreiben, dass das Murx ist, ist es aber nicht). Contenido codiert nicht, ich nehme zunächst alles zurück. Das muss ich überprüfen. Melde mich wieder.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Di 1. Mär 2005, 12:03

Yep, das wars. Aus der Datenbank kommen bei Direktzugriff (db->f()) die für die russische Darstellung benötigten Zeichen als &-codiert heraus.

Nun müssen die wieder in die fertigen Zeichen codiert werden. Für diese Aufgabe steht in functions.general.php die Funktion htmldecode() zur Verfügung.

Bei der Hauptnavigation genügt also ein htmldecode($data['name']), um die benötigten Zeichen zu erhalten.

Bei walterco ist die Hauptnavigation nun angepasst (alle Ebenen) und funzt:
http://www.walterco.de/so/cms/front_con ... angelang=4

Ich nehme alles (ähm, zumindest für den Modul-Bereich), was ich zu "Contenido codiert einmal zuviel" gesagt habe, zurück und klopfe timo bzw. 4fb die Schulter.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

JSommer
Beiträge: 324
Registriert: Fr 5. Sep 2003, 12:32
Wohnort: 192.168.0.11
Kontaktdaten:

Beitrag von JSommer » Di 1. Mär 2005, 18:05

Wow, das zieht mir jetzt die Beine weg ... wo ... nochmal zum Nachvollziehen - hast Du das reingeworfen ??? Dann könnten wir ja auch ein kyrillisches Textmodul machen, denn wir hatten ja das Thema http://contenido.org/forum/viewtopic.php?t=7336 und ich hab noch nicht gecheckt, ob der Fehler in der aktuellen CVS Version nun so noch existiert ?! ...

Gesperrt