anmerkung: contenido-cvs-2005-03-04.tar

[HerrB]

Der Bug ist schon lange drin, aber jetzt hat er mich genervt:

In contenido\classes\class.xmlparser.php muss es in der Funktion parseFile (ganz unten)

Code: Alles auswählen

				$this->_error();

statt

Code: Alles auswählen

				$this->error();

heißen (Unterstrich).

Der Fehler tritt z.B. auf, wenn das Importieren einer XML-Übersetzungs-Datei für ein Modul scheitert. In diesem Zusammenhang ergibt sich, dass es in
contenido\classes\contenido\class.module.php in der Funktion import

Code: Alles auswählen

    	if ($parser->parseFile($file)) {
    	
		foreach ($_mImport["items"] as $key => $value)
		{
			$this->create ($idmod, $idlang, $key, $value);
		}
        } else {
		echo $parser->error;
        }

statt

Code: Alles auswählen

    	$parser->parseFile($file)
    	
		foreach ($_mImport["items"] as $key => $value)
		{
			$this->create ($idmod, $idlang, $key, $value);
		}

heißen sollte: Tritt ein Fehler auf, versucht er sonst, die Fehlermeldung zu importieren. echo $parser->error; ist vielleicht nicht elegant - aber man erfährt endlich das Problem:

XML error: not well-formed (invalid token) at line 3

Diese Fehlermeldung basiert wiederum auf einem anderen Fehler: Man kann kein ä in XML-Übersetzungs-Dateien verwenden. Da suche ich noch.

Gruß
HerrB

[HerrB]

Bei Modul-Übersetzungen gibt es noch ein paar kleinere Probleme.

"Prüngen" werden beim ersten Speichern auch entsprechend gespeichert. Jedoch wird nun "Prüfungen" angezeigt - wird dieser Eintrag erneut gespeichert, steht "Prüfungen" auch in der DB. Mit der Eingabe "Prüngen" kann man das Sterben hinauszögern: Beim ersten Speichern landet "Prüngen" in der DB (was dann natürlich bei Ausgabe auf der Webseite zu "Prüngen" wird, also nützt das wenig), beim zweiten "Prüngen", beim dritten "Prüfungen".

Vorgeschlagene Lösung: In der Datei include.mod_translate.php

Code: Alles auswählen

$translated = new cHTMLTextarea("t_trans",$mtrans->get("translation"));

durch

Code: Alles auswählen

$translated = new cHTMLTextarea("t_trans",str_replace("&","&",$mtrans->get("translation")));

ersetzen. Dies codiert & wieder mit &, so dass & auch in der Textarea der Übersetzung angezeigt wird.

Die exportierte XML-Datei ist unter Windows nach wie vor net richtig formatiert (Zeilenende-Zeichen-Problem).

Ansonsten sind die Übersetzungs-XML-Dateien tricky: Der Eintrag "Prüfungen" muss (um HTML zu erhalten) z.B. so codiert werden: "Pr&uuml;ngen" (aber nur in der XML-Datei!). Bleibt die Codierung des & aus, kommt es zur Fehlermeldung "Undefined entity". Dazu im Gegensatz muss <br> als <br> in der XML-Datei angegeben sein (ohne Codierung des &, sonst wird das später nicht als HTML-Tag erkannt).

Gruß
HerrB

[HerrB]

Weiße Fläche bei Extras -> Newsletter ist noch drin. Siehe http://www.contenido.org/forum/viewtopi ... 8999#38999

Übersetzung im Input-Bereich bei Modulen funktioniert nicht, Lösung siehe http://www.contenido.org/forum/viewtopi ... 0448#40448

Gruß
HerrB

[timo]

"Pr&uuml;ngen" werden beim ersten Speichern auch entsprechend gespeichert. Jedoch wird nun "Prüfungen" angezeigt - wird dieser Eintrag erneut gespeichert, steht "Prüfungen" auch in der DB. Mit der Eingabe "Pr&uuml;ngen" kann man das Sterben hinauszögern: Beim ersten Speichern landet "Pr&uuml;ngen" in der DB (was dann natürlich bei Ausgabe auf der Webseite zu "Pr&uuml;ngen" wird, also nützt das wenig), beim zweiten "Pr&uuml;ngen", beim dritten "Prüfungen".

Das ist ein guter Punkt, aber ich weiß nicht wie er "gut" gelöst werden kann. Beispiel: Der Entwickler schreibt in seinen Code

"Pr&uuml;fungen".

Daher die Grundsatzfrage: Soll der Übersetzer "Prüfungen" oder "Pr&uuml;fungen" angezeigt bekommen? Soll der Übersetzer dann auch die HTML-Entities mit eingeben oder nicht? Ich bin eher der Meinung, daß der Übersetzer sowohl "Pr&uuml;fungen" angezeigt bekommen als auch eintragen soll.

Ich habe das daher so eingebaut, daß er dann bei einem Eintrag "Prüfungen" in der DB "Pr&uuml;fungen" einträgt (htmlspecialchars). Beim Auslesen wird daraus wieder "Prüfungen" (liegt an dem internen Encoding der GenericDB). Bei einem XML-Export wird daher "Pr&uuml;fungen" in "Pr&&uuml;fungen" umgewandelt, was auch vollkommen richtig ist. Oder anders gesprochen:

Das, was bei mi18n("") eingetragen wird, wird genauso sowohl in der Stringliste als auch bei den Feldern eingetragen und auch zurückgeliefert. Damit ist zwar der "Komfort" des Editierens nicht mehr vorhanden, aber die Funktionsweise ist stringent und nachvollziehbar.

Die exportierte XML-Datei ist unter Windows nach wie vor net richtig formatiert (Zeilenende-Zeichen-Problem).

Hast du einen Lösungsvorschlag? Ich nicht...

Ansonsten sind die Übersetzungs-XML-Dateien tricky: Der Eintrag "Prüfungen" muss (um HTML zu erhalten) z.B. so codiert werden: "Pr&uuml;ngen" (aber nur in der XML-Datei!). Bleibt die Codierung des & aus, kommt es zur Fehlermeldung "Undefined entity". Dazu im Gegensatz muss <br> als <br> in der XML-Datei angegeben sein (ohne Codierung des &, sonst wird das später nicht als HTML-Tag erkannt).

Ähm nein....<br> muß im XML auch als <br> encodiert sein, da das <br> nicht im XML-Namespace vorhanden sein darf...es ist also richtig, daß es encodiert ist. Es muß nur beim erneuten Einlesen wieder dekodiert werden. Wobei wir hier ja von Übersetzungen sprechen, d.h. wenn ein Übersetzer z.b. <br> eingibt, wird daraus <br> schon in der DB, und im XML dann &lt;br&gt; -> was dann auch funktioniert. In Übersetzungen gehören ja auch schließlich keine HTML-Tags, mit Ausnahme der Umlaute...

So wie ich das sehe funktioniert das jetzt -> wird dann im nächsten Snapshot vorhanden sein.

[HerrB]

Ich habe das daher so eingebaut, daß er dann bei einem Eintrag "Prüfungen" in der DB "Pr&uuml;fungen" einträgt (htmlspecialchars). Beim Auslesen wird daraus wieder "Prüfungen" (liegt an dem internen Encoding der GenericDB). Bei einem XML-Export wird daher "Pr&uuml;fungen" in "Pr&&uuml;fungen" umgewandelt, was auch vollkommen richtig ist

Schon ein bisschen her ... Wenn es so eingebaut wird, wie ich es vorgeschlagen hatte, trägt man "Pr&uuml;fungen" ein und bekommt auch "Pr&uuml;fungen" wieder raus (als Coder macht es ja Sinn, auch den Text in mi18n bereits zu ummeln, d.h. mi18n("Pr&uuml;fungen")...). Ich werde es testen, ob es jetzt das tut, was ich denke...

Hast du einen Lösungsvorschlag? Ich nicht...

Zum einen erinnere ich mich an etwas von emergence, eine /f-Option oder so, die das automatisch beim ausgeben berücksichtigt. Finde es gerade nicht. Zum anderen könnte man (so ganz auf die blöde) noch eine Option ergänzen: *nix-Style oder Windows-Style. Bei der Ausgabe wird dann bei Windows-Style das Zeilenendezeichen (ich glaube, Chr(10) durch Chr(10) + Chr(13) ersetzt...). Ich suche mal nach dem Post.

wird daraus <br> schon in der DB, und im XML dann &lt;br&gt;

Ja ... damals war es nur so, dass die XML-Datei <br> enthalten musste - &lt;br&gt; produzierte Murks bzw. wurde nicht importiert. Das war der lustige Effekt, dass man eine exportierte Datei nicht importieren konnte. Ich sehe es mir an.

Gruß
HerrB

P.S.: timo is back ...

[HerrB]

Geht alles so, wie es soll... Post von emergence zur Zeilenendezeichen-Problematik habe ich noch nicht gefunden.

Kann geschlossen werden.

Gruß
HerrB