japanische contenido seiten

[grossy]

sweet as... laeuft auch! man dankt!

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

[HerrB]

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

[emergence]

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

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)

[grossy]

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

[grossy]

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...



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





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]

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]

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]

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]

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

[emergence]

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...

[timo]

Ü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]

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...

[emergence]

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

Code: Alles auswählen

$%%$

sollte in keinem encoding einen fehler verursachen...

[timo]

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]

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

Code: Alles auswählen

$%%$

sollte in keinem encoding einen fehler verursachen...

für was ist das eigentlich da?