japanische contenido seiten

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Di 1. Mär 2005, 16:44

sweet as... laeuft auch! man dankt!

bleibt nur die frage ob man auch mit nem snapshot nen kommerzielles projekt schon abwickeln sollte :roll:

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

Beitrag von HerrB » Di 1. Mär 2005, 16:50

Wunderbar. Tja, die Frage wird Dir wohl niemand beantworten...

@timo: Bugfix:
In der Datei includes\functions.con.php die Zeile 1114 von

Code: Alles auswählen

      $name       = $db->f("name");
in

Code: Alles auswählen

      $name       = htmldecode($db->f("name"));
ändern (ist in der Funktion conCreateLocationString).
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

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Di 1. Mär 2005, 19:31

grossy hat geschrieben:bleibt nur die frage ob man auch mit nem snapshot nen kommerzielles projekt schon abwickeln sollte :roll:
sollte ist ein schlechtes wort...
niemand kann garantieren das die stable releases fehlerfrei sind...
ergo meiner meinung nach -> ja kann man...

aber ein bugreport in der richtung -> ich hab ein update von einer cvs snapshot version auf einen stable release gemacht und nun geht nichts mehr... -> da wird dir niemand ausser du selbst helfen können... (php und interne contenido kenntnisse vorrausgesetzt)
*** make your own tools (wishlist :: thx)

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Di 1. Mär 2005, 23:49

oki. thx anyway - ich glaub ich lass es mal drauf ankommen :lol:

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Sa 5. Mär 2005, 03:19

so noch was wegen japanisch beim snapshot vom 25.02.

navigation ist jetzt ja fein. da ist mir aber noch was beim text/html feld aufgefallen.

wenn ich japanische kanjis eingeb, sieht erst alles wunderbar aus. wenn ich das speicher auch noch. aber geh ich dann in den editor zurueck oder den htmleditor - alles komische zeichen, funktioniert zwar alles aber es ist schwer genug das richitge japanisch fett oder kursiv zu machen. mit den anderen zeichen wirds unmoeglich...

:cry:

anbei nochmal screens, vilelciht helfen die ja weiter...

Bild
Bild
Bild

hab grad bemerkt, das ganze kann ich nur auf IE produzieren. auf mozilla funzt alles. liegt wohl am HTMLeditor oder???

so und nochmal - auf mozilla gibts den fehler sobald man <> htmltags drin hat auch. nur bei reinem text funktioniert die darstellung...

grossy
Beiträge: 57
Registriert: Mi 28. Apr 2004, 12:56
Wohnort: downunder
Kontaktdaten:

Beitrag von grossy » Sa 12. Mär 2005, 01:36

:roll:

hat noch jemand ne ahnung wegen der komischen darstellung im html editor? ansonsten sieht der snapshot vom 11.03. sehr sehr gut aus im hinblick auf japanische schrift darstellung...

Roberto
Beiträge: 7
Registriert: Mi 16. Okt 2002, 10:33
Kontaktdaten:

Beitrag von Roberto » Mo 14. Mär 2005, 12:12

Genau wegen der mangelnden Sprachunterstützung (und weil sich keiner dafür interessiert hat) bin ich damals zu "Der Dirigent" gewechselt ...
In dem Punkt scheint sich seit damals - nach zwei Jahren - nicht wirklich viel verbessert zu haben?
Dass da HTML-Entities ausgegeben werden und das durch ein htmldecode gelöst wird, lässt mich vermuten, dass in der DB als HTML-Entities gespeichert wird? Das wäre, falls es wirklich so ist, unsinnig.
Das Problem mit dem Editor: Das hört sich so an, als ob an irgendeiner Stelle der Zeichensatz nicht bekannt ist. Vermutlich versucht der Editor die in shift_jis kodierten Zeichen in einem anderen Zeichensatz (vermutlich iso-8859-1) darzustellen, weil dort entweder kein Zeichensatz bekannt ist oder explizit der falsche angegeben ist.

Nachtrag: Meine Vermutung scheint zu stimmen. Das erste Zeichen ist Zeichen ボ(&#x30DC;)?

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

Beitrag von timo » Mo 14. Mär 2005, 15:24

Roberto hat geschrieben:Genau wegen der mangelnden Sprachunterstützung (und weil sich keiner dafür interessiert hat) bin ich damals zu "Der Dirigent" gewechselt ...
Bitte erst informieren, dann posten, danke.

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

Beitrag von timo » Di 24. Mai 2005, 11:30

Ich habe das ganze jetzt nocheinmal getestet, bei mir funktioniert es. Die Zeichen sehen im Insite-Editing genauso aus wie im WYSIWYG.

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 08:53

habs gerade mit dem contenido-cvs-2005-05-20.tar getestet...
sieht gut aus...

ne kleinigkeit ist mir da bei der subnavigation im backend aufgefallen

Übersicht -> das Ü wird im falschen encoding angezeigt...

die andere sache die ich nicht ganz verstehe ist folgende

main.php ->

Code: Alles auswählen

if (array_key_exists("use_encoding", $_GET))
{
	$use_encoding = $_GET["use_encoding"];
}

if (array_key_exists("use_encoding", $_POST))
{
	$use_encoding = $_POST["use_encoding"];
}

if (!isset($use_encoding))
{
	$use_encoding = true;
}

if (is_string($use_encoding))
{
	if ($use_encoding == "false")
	{
		$use_encoding = false;
	} else {
		$use_encoding = true;
	}
}

if ($use_encoding != false)
{
	$sql = "SELECT idlang, encoding FROM ".$cfg["tab"]["lang"];
	$db->query($sql);

	while ($db->next_record())
	{
		$aLanguageEncodings[$db->f("idlang")] = $db->f("encoding");
	}

	if (array_key_exists($lang, $aLanguageEncodings))
	{
		if (!in_array($aLanguageEncodings[$lang], $cfg['AvailableCharsets']))
		{
			header("Content-Type: text/html; charset=ISO-8859-1");
		} else {
			header("Content-Type: text/html; charset={$aLanguageEncodings[$lang]}");
		}
	} else {
		header("Content-Type: text/html; charset=ISO-8859-1");
	}

}
ähm macht was genau ? bzw. wo wird use_encoding gesetzt ? ich hab das nirgendwo gefunden...
*** make your own tools (wishlist :: thx)

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

Beitrag von timo » Mi 25. Mai 2005, 09:03

emergence hat geschrieben:Übersicht -> das Ü wird im falschen encoding angezeigt...
Ist logisch, denn es gibt keine Möglichkeit, 2 Encodings auf einer Seite darzustellen. Man könnte zwar als "Workaround" &uuml; verwenden und bei der Subnavigation ein anderes Encoding verwenden, ist aber nicht Sinn der Sache.
die andere sache die ich nicht ganz verstehe ist folgende

main.php ->
Das Ding sieht seltsam aus -> ich würde es aber drinlassen...

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 09:16

hmm...

das mit den zwei encodings ist mir klar...

die idee ist ja sehr gut jedem frame das encoding der sprache automatisch zu verpassen...
nur müsste man da aufpassen ob das backend encoding oder das client[$lang] encoding verwendet...
soweit ich das verstanden habe, wird das encoding des mandanten in jedem bereich gesetzt... also zb auch bei module, layout...
na wie auch immer, so einfach ist das natürlich nicht, wo jetzt was genau gesetzt werden soll...
bei der subnav -> frame 3 sollte aber immer das backend encoding des xml-files verwendet werden...
*** make your own tools (wishlist :: thx)

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Beitrag von emergence » Mi 25. Mai 2005, 09:23

ach ja das mit dem javascript fehler in der include.con_editcontent.php

Code: Alles auswählen

//aContent = aContent.replace(/\|/,"§%%§");
wurde ja auskommentiert...

ähm

eine änderung von

Code: Alles auswählen

§%%§
in sollte in keinem encoding einen fehler verursachen...
*** make your own tools (wishlist :: thx)

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

Beitrag von timo » Mi 25. Mai 2005, 09:24

ja deshalb war unsere Idee: Überall das Encoding der Sprache setzen. Wenn es seltsame Zeichen gibt, muß der Benutzer als Backendsprache entsprechend wählen - anders geht es leider nicht, zumindest nicht, solange nicht alles auf UTF-8 funktioniert.

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

Beitrag von timo » Mi 25. Mai 2005, 09:24

emergence hat geschrieben:ach ja das mit dem javascript fehler in der include.con_editcontent.php

Code: Alles auswählen

//aContent = aContent.replace(/\|/,"§%%§");
wurde ja auskommentiert...

ähm

eine änderung von

Code: Alles auswählen

§%%§
in sollte in keinem encoding einen fehler verursachen...
für was ist das eigentlich da?

Gesperrt