Ich habe letztens nochmal einen alten Thread von mir ausgekramt und durchgelesen - schön ist anders.
Hier sieht man nochmal den < > Bug:
Und dieser Beitrag ist ein Beispiel für eine ganze Reihe von Übernahmefehlern:
Inline-Tags wurden nicht in Festbreitenschriftart übernommen, die bbcodes stehen noch darin
Die Listenpunkte ([li]-Tags) wurden nicht korrekt übernommen
Die Codeblöcke wurden falsch übernommen (nicht alle Codezeilen wurden als Code erkannt, scheinbar sind die Backticks in der falschen Zeile / falschen Anzahl)
Bei Zitaten steht oben der Namen und die Post-ID vom zitierten Beitrag, was unschön aussieht (wenig problematisch, die anderen Punkte wiegen deutlich schwerer, weil sie den Lesefluss arg hemmen)
Es ist schwierig, bei einem „kaputten“ Beitrag „die“ Ursache zu erkennen. Ich denke, dass es immer Beiträge geben wird, die kaputt sind - nicht zuletzt weil einzelne vielleicht schon im Original kaputt waren (aber man es einfach nicht gesehen hat). Der Klassiker wären da „doppelte schließende Tags“, die IIRC oft ignoriert wurden, aber einen „Parser/Konverter“ leicht aus dem Konzept bringen können.
Besonders problematisch finde ich deswegen forenweite Fehler am Code, wie eben gerade die <>-Sache…
Aber nochmal: Man kann das ja nicht einfach ersetzen. Bei
#include <html_parser>
void main() {
std::string tagStart = "<" // Das < steht für die <
}
rauszupfriemeln, welche$lt; ersetzt werden müssen, ist schwierig (bis „praktisch fast unmöglich“). Aaaaber: Ich gehe davon aus, dass in der „raw“ (ungerenderten) Variante die richtigen Informationen stehen! In der Vorschau in Generics gehen bei "Fix formatting post-migration: Javas, rmCRs" kaputt werden die <> ja richtig angezeigt!
Falls hier nichts weiter kommt, frage ich mal im discourse-Forum nach. Es kann ja nicht sein, dass wir die ersten sind, die vor diesem Problem stehen
Allgemein stimme ich dir zu. Da ich den Beitrag aber selbst verfasst habe, kann ich das in diesem Fall ausschließen. Mangels URL im alten Format kann ich leider auch kein Belegexemplar aus der waybackmachine herzaubern.
Allerdings sieht man auch ganz klar, dass der letzte Listenpunkt der einzige ist, der nicht richtig übernommen wurde.
Dass der Code nur teilweise als Code erkannt wird und die ersten bzw. letzten Zeilen nicht im Codeblock sind, ist auch ganz klar ein Formatierungsfehler, der im Ursprungsbeitrag nicht vorhanden war. Das Problem dabei ist übrigens, dass nach den drei ````` zu Beginn des Quellcodes und vor den Backticks am Ende des Codes kein Zeilenumbruch steht.
Wenn der Code semantisch verfälscht wird, wiegt das natürlich deutlich schwerer, als offensichtliche Fehlformatierungen.
man warum bekomme ich keine Mails wenn was geschrieben wurde, da muss ich auch noch einmal gucken
Was meinst du mit newlines, ich hab gerade mal die History angesehen und außer dass es dort noch zerpflückter ist sehen die gleich aus
und ja ich hab das SQL Statement noch nicht los geschickt gehabt weil die Diskussion für mich noch nicht fertig war und ich die DB nicht schon wieder “kaputt” machen wollte
ich hab den Code mal gefixt ich hab nur java durch ``` ersetzt ohne davor oder danach Leerzeilen einzufügen aber einige Leute haben ihre java tags immer direkt an den Code geklebt damit kommt der Parser nicht klar
Bei den anderen müssen wir mal gucken wie wir das beheben können
Mit den newlines meinte ich, dass im Code in Proof of Concept Multi-Part Formdata Parser in C++ Leerzeilen vorkommen, die vermutlich (!) im Original nicht dort waren, sondern vermutlich (!) dort noch \n oder waren …
EDIT: Aha: Leere backticks ` zeigt er gar nicht an, nur wenn was dazwischen steht.
Ja, ich habe die Java-Tags direkt an den Code gepackt, weil die alte Software sonst zusätzliche Leerzeilen eingefügt hat.
In Discourse muss nach den drei Backticks zwingend ein Zeilenumbruch folgen, was in diesem Fall wohl nicht berücksichtigt ist.
Das größte Problem ist ja, dass dieses “Fixen” SEHR schwierig ist, weil es fast unmöglich ist, das zu fixen, OHNE woanders wieder was kaputt zu machen.
Ich denke, dass man das, wenn überhaupt, nur fixen könnte, wenn man auf den Originaldaten arbeiten würde, und erkennen könnte, dass das in Code-Tags steht. Aber [java] dieser Code steht auch in Code-Tags[/java], nur sind die halt noch mit backticks eingeklammert.
Am “sichersten” wäre vermutlich: Den raw-post und den HTML-Output aus dem alten Forum getrennt ins neue übertragen - aber das ist technisch wohl kaum möglich…
ja ich hab mal nachgesehen das original importscript muss den Blödsinn angestellt haben. Also im Forum sind schon die Zeilenumbrüche ersetzt angekommen.
ich habe gerade mal die <> ersetzt sowie äüö die Posts werden gerade neu erstellt
Solltet ihr Posts haben wo ÄÖÜ drin ist gebt sie mir bitte mal weil dann kann ich die Umlaute auch dort ganz machen.
wegen den \r\n bzw \n muss ich womöglich eh alle Posts neu importieren daher hab ich das mit <> mal angestoßen
ist schon bekannt, schwer vorzustellen dass nicht, dass außerhalb von Code-Blocks in normalen Text alles zwischen <> schlicht verschluckt wird, vielleicht weil als komischer Formatierungs-Tag angenommen?
das hier:
List list = new ArrayList();
sollte eigentlich eine generisch auf String eingeschränkte Liste sein, bei Edit oder Zitat vielleicht nachzuprüfen,
wird so aber zu einer schnöden raw List angezeigt…
für ein Programmierforum ein ziemlich kapitaler Fehler, der meiste Code kann zwar in Code-Blocks,
aber auch in beschreibenden Text kann man mal von ‘nimm die List{String} und …’ schreiben
Das ist “normal”, das ist ja HTML und das kann nicht pauschal so angezeigt werden. Es könnte ja sein, dass es ein Tag sein soll. Für Inline-Code verwendet man dann einfach backticks, also
`List<String>`
dann klappt’s auch mit der List<String>.
(Wobei ich gerade beim Schreiben gemerkt habe, dass es schwierig ist, einen einzelnen backtick in inline-Code unterzubringen, aber … irgendwo beißt sich die Katze in den Schwanz…)
Wie fügt man diesen Link: http://www.wolframalpha.com/input/?i=sqrt(1234+%2F+(422+*+251)) (aus dem Firefox kopiert) korrekt hier im Forum ein (s. d. anklickbar)?
Na gut, vor einiger Zeit war das noch nicht so, dass, wenn man eine URL aus dem Firefox kopiert hatte, die ( )-Klammern nicht encodiert wurden! Normalerweise sollte durch %28%29 ersetzt werden… Wieso?
Einzelne Klammern kriegt er wohl noch hin, aber das, was bei WolframAlpha übergeben werden kann, kann schon hart an der Grenze dessen sein, was er noch vernünftig parsen kann…
Das kann das Forum noch parsen, ansonsten (bei zwei oder mehr aufeinander folgende Klammern): http://www.wolframalpha.com/input/?i=solve+a%2A%28y2-y1%29%2By1+%3D+%28%28a%2A%28x2-x1%29%2Bx1-x3%29%2F%28x4-x3%29%29%2A%28y4-y3%29%2By3+for+a
Mir ist bewusst, dass Gefahren für den Firefox, den Benutzer, das Forum und WolframAlpha damit verbunden sind(!), allerdings frage ich mich, warum man das bei dem Firefox geändert hatte, und diesen Weg gegangen ist.
für Zerstörung von List< String>, Leerzeichen hilft übrigens auch, gibt es schon ziemlich wenig Grund, hab noch kein Posting gesehen bei dem jemand ein Tag mit eckigen Klammer manuell eintippt,
nur z.B. ** für fett-Druck,
das hatte ich mir zuletzt als Antwort noch gespart, aber jetzt fällt mir dann auch als Konsequenz auf, dass man nichtmal mehr einfache mathematische Rechnungen posten kann? a*b*c wird zu abc mit den Sternen als Kursiv-Anweisung…
wer kommt auf solch einen Schrott als Standardeditor?
in dem man auch nicht eigene Anzahl Punkte posten kann, sondern
.
..
...
....
zu
.
…
…
…
wird, auch mitten im Text: …?
wo simple Angaben wie
1
2
3
> 4
zu
1
2
3
4
umgewandelt werden?
tolle neue Welt…
vielleicht sollte man das ganze Posting standardmäßig in Code-Block setzen, den wenigen normalen Text gesondert markieren
