WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Zum Thema..
Falls es weitere Möglichkeiten gibt: Bitte her damit. Niemand ist allwissend.
Mein persönlicher Senf:
Vorab: Ich habe nur Word 2007, mag sein, dass es in neueren Version andere Möglichkeiten gibt. Ich hatte aber bisher nicht den Eindruck, dass meine Version dramatisch veraltet ist, was so Basics betrifft)
Man kann Word-Dokumente
a) direkt per Copy/Paste in den Editor einsetzen
b) Als HTML exportieren und dann als solches in den Editor einsetzen.
Nachtrag: Die beste Möglichkeit ist c) Als Plain Text (Strg-Shift V) einsetzen und dann erst strukturieren.
Der wesentliche Unterschied ist der Umgang mit Bildern:
bei a) werden Bilder als data-elemente mitkopiert, was sehr problematisch ist (Editor wird unendlich langsam, Browser kann abstürzen, insgesamt kaum mehr zu händeln)
Das erzeugte HTML ist formal relativ valid, enthält aber Unmengen an sinnlosen Styles, Classes und verschachtelten Tags.
bei b) werden Bilder exportiert und verknüpft. Das ist nicht ideal (so wie das gemacht wird), aber weit besser als a)
Das erzeugte HTML ist ähnlich dem von a), enthält aber endlose <style>-Definitionen, die man so keinesfalls verwenden sollte. Das muss weg, dann bleibt aber zunächst nichts mehr vom ursprünglichen Aussehen über.
Die gute Nachricht:
Wenn man das etwas durchputzt (das geht halbautomatisch mit diversen Tools), wird wieder etwas draus, was man per CSS auf Vordermann bringen kann.
Eine wesentliche Voraussetzung ist, dass mit Absatzformaten gearbeitet wurde. Wenn das nicht der Fall ist, muss man kreativ werden.
Eine für alle brauchbare Lösung gibt es aber leider nicht, bzw habe ich noch keine gefunden. Deswegen lohnt sich ein Nachdenken darüber erst, wenn man sehr viel auf einmal machen kann = die Word-Datei groß und zusammenhängend ist.
Beitrag geändert von boeseroeser (02.08.2019 14:05:16)
DIe fehlenden Absatzformate - das ist hier ein wesentlicher Stolperstein.
Die mit "MyInfo" erzeugte Datenbank - ist die strukturierter als die Word-Dateien? Oder ist das im Kern das gleiche?
Wie MyInfo das intern strukturiert, weiß ich natürlich nicht (das ist eine ca. 112 MB große Datei mit der Endung .mio). Aber "nach außen hin" ist das Resultat bei MyInfo insofern das Gleiche, als ich einfach die Word-Texte per copy and paste eingefügt habe (wird von MyInfo 1:1 zu übernommen, nur Links und Anker müssen neu gesetzt werden). Der wesentliche Unterschied besteht für den Nutzer darin, dass bei Word alles in einer Einheit drinnensteckt (dem Word-Dokument bzw. den beiden Word-Dokumenten, während es bei MyInfo pro Stichwort eine eigene Einheit gibt (dort genannt "document" oder eben Seite oder sonstwie) und alle Stichworte in einem Tree aufgelistet sind.
Ich nehme jetzt mal nicht an, dass du (mit vertretbarem Aufwand) sauberes, strukturiertes, valides XML beistellen kannst und willst. DAS ist es nämlich, was man braucht, nicht ein irgendwas mit Extension xml.
Nach dem derzeitigen Stand scheitert es am "können". Die Frage des Wollens stellt sich daher im Moment gar nicht.
An Ende willst du wohl einzelne Web-Seiten haben, die deinen Word-Dateien möglichst ähnlich sind, wo die Links funktionieren und die in einer Gesamtstruktur auffindbar sind.
Prinzipiell ja (kleine Ergänzung folgt unten). Im Wesentlichen so, wie das bei Wikipedia (oder auch anderen Wikis) läuft.
Ist das so?
Wenn ja: Warum machst du das nicht einfach so?
Ich dachte, es geht in diesem Thread gerade darum. Wenn ich wüsste, wie man das "einfach so macht", hätte ich ja nicht nachfragen müssen. Die einzige Methode, mit der ich es bisher gemacht habe, ist das copy/paste aus Word in einen Editor (zB. bei PBworks bzw. testweise hier bei WBCE) plus nachträglicher Vornahme von Formatierungsanpassungen. Ich hätte auch nichts dagegen, mit dieser Methode weiterzuarbeiten - nur müsste es ein "Ort" sein, an dem gesichert ist, dass es bei 24.000 oder 25.000 Seiten zu keinen Kapazitätsproblemen kommt.
Die Schlussfolgerung habe ich allerdings nicht verstanden:
Also: Es ist nicht nötig, jede Tabellenspalte, jede Anmerkung einzeln in der DB zu speichern, es reicht ein gesamter WYSIWYG-Block.
Ist das so?
Ich weiß nicht, was du mit einem gesamten WYSIWYG-Block meinst. Alles, was inhaltlich zu einem Eintrag/Stichwort gehört (Tabellen, Anmerkungen usw.), kann und sollte eine Einheit bilden.
Als Alternative zur Variante "Einzelne Webseiten" ist mir noch Folgendes eingefallen: Wenn man den gesamten Inhalt des Word-Dokuments (von A bis Z) auf eine einzige Webseite bekäme (auf der sich der Nutzer dann gleichsam durch das ganze Wörterbuch scrollen kann), so wäre das eventuell auch eine Lösung (wenn auch optisch keine sehr elegante). Eine schnelle Ladezeit dieser Seite müsste natürlich trotz ihrer Größe gesichert sein, ebenso eine gute Suchmöglichkeit zum direkten Ansteuern eines gewünschten Stichworts. Denkbar wäre dann noch eine Aufteilung auf mehrere Webseiten nach Buchstabengruppen (zB. A - B / C - E / G - H usw.). (Noch weniger elegant ...). Technisch wird sich so etwas wahrscheinlich sowieso nicht realisieren lassen, aber ich erwähne es für den Fall, dass jemand eine Idee in diese Richtung hat.
Man kann Word-Dokumente
a) direkt per Copy/Paste in den Editor einsetzen
b) Als HTML exportieren und dann als solches in den Editor einsetzen.Nachtrag: Die beste Möglichkeit ist c) Als Plain Text (Strg-Shift V) einsetzen und dann erst strukturieren.
Nach Methode a) bin ich eben bisher vorgegangen (siehe oben). Methode c) wäre - wenn ich das richtig verstehe - mit einem enormen Arbeitsaufand verbunden. Ich müsste dann ja die gesamte Formatierung wiederholen.
Der wesentliche Unterschied ist der Umgang mit Bildern:
Bilder sollte es in den Wörterbuch-Dokumenten keine geben. (Obwohl HH ja eine Meldung betreffend embedded grafic entdeckt hat.)
Deswegen lohnt sich ein Nachdenken darüber erst, wenn man sehr viel auf einmal machen kann = die Word-Datei groß und zusammenhängend ist.
Groß wäre sie ja mit 43,7 MB. 
Beitrag geändert von michael-neu (02.08.2019 16:50:22)
Offline
Die MyInfo Datei können wir also vergessen, das bringt nichts.
Du redest von 24.000 Seiten (!)
Wie viele hast du jetzt? - nur um mal ein realistisches Bild zu bekommen.
Grundsätzlich läuft das so: Das CMS lässt sich von der Datenbank 1 Ding liefern und stellt das dar. Es ist dem CMS an sich egal, wieviele Dinger da in der Datenbank sind. Das ist bei jedem CMS so, es kommt nur auf die Leistung der Datenbank an.
Zwar gibt es da Feinheiten, aber die kann man lösen.
Ich habe aus einem der Begriffe in deiner Word-Datei eine Test- und Spielseite gemacht:
(Nicht erschrecken)
https://wbce.at/de/leere-seite.php
Wenn ich das wieder wegtun soll, sags einfach, aber es redet sich leichter, wenn man was vor Augen hat.
Was ist das:
Ich habe einen Teil der Word-Datei einfach per Copy/Paste in den Editor kopiert und nicht weiter verändert.
Dann habe ich ein Script gemacht, dass das alles bereinigt - im technischen Sinne. Die Elemente sind einfach "irgendwie" eingefärbt, haben die Standardschrift des Templates usw. Es ist mir nur um die technische Machbarkeit gegangen. Da kann man natürlich noch lange feinjustieren.
Erst wenn es technisch sauber und strukturiert ist, kann man mit CSS die tatsächliche Gestaltung machen, auch Handy-tauglich machen.
Das also wäre inhaltlich EINE der 24.000 Seiten - oder? Das meinst du mit "Seite"?
Die Tabellen sind Bestandteil dieser Seite, sie werden nicht extra gespeichert und dann eingefügt.
Beitrag geändert von boeseroeser (02.08.2019 17:27:54)
Noch kurz eine Sache, die dich vielleicht sehr irritiert, die für alle hier aber so klar ist, dass es gar nicht erwähnt wird.
Das Aussehen aller Elemente auf einer Website wird durch zentrale "Style Sheets" definiert, also per CSS. Das ist üblicherweise das letzte, was man in Angriff nimmt.
Wenn du in Word eine Tabellenzelle hellgelb einfärbst, schreibt Word unsichtbar hin: DIESE Tabellenzelle hat die Hintergrundfarbe #ffffdc
Das passiert bei jeder Tabellenzelle, die du eingefärbt hast.
Wenn du jetzt deine Word-Datei per Copy/Paste in den Editor einsetzt, wird das (und allerhand anderer Kram) mitübernommen.
Ergo: Deine Tabellenzelle ist ebenfalls hellgelb, und das erscheint dir als gewünschtes Verhalten.
Für mich als Designer ist das aber absolut UNerwünscht, weil diese Farbangabe als wichtiger angesehen wird als das, was im Style Sheet angegeben ist. Wenn dort steht, dass jede 2. Reihe in rosa sein soll, sind deine eingefärbten Zellen immer noch hellgelb.
Das wirst du jetzt vielleicht nicht als Problem sehen, aber:
Du wirst zB. Wert darauf legen, dass deine Website auch am Handy gut funktioniert.
Damit das geht, müssen die Zellen untereinander rutschen, und damit man sieht, was zusammengehört, wird eine Trennlinie eingezogen. Nur als Beispiel.
Das geht aber nicht, weil das zentrale Style Sheet nicht greift.
Genauso wäre es, wenn du mittendrin eine Reihe einfügst. Dann hast du 2 weiße (oder hellgelbe) Reihen untereinander, es ist nicht mehr jede 2. eingefärbt. Es ist ein einfacher Automatismus, jede 2. Reihe einzufärben, aber der geht nicht so einfach, wenn sie bereits eingefärbt sind.
Ähnliches gilt für Schriften, Zeilenabstände, Tabellenränder,....
Das ist der Grund, warum ich es als Ziel ansehe, dass ich da die Standardschrift des Templates sehe und nicht 12pt Arial, Farbe #000 (wie in deiner Word-Datei angegeben)
Dann erst kann man nämlich sagen: Ich stelle Schriftfarbe, Schriftgröße,..sonstwas ein wie in Wikipedia oder Spiegel.de oder was auch immer.
Beitrag geändert von boeseroeser (02.08.2019 19:28:41)
florian, stefanek
Danke, boeseroeser.
Gleich zum zweiten Posting. Das habe ich technisch (noch) nicht so ganz verstanden (ich lese es mir dann nochmals in Ruhe durch [PS: Ich habe es jetzt gemacht und ich denke, jetzt ist es mir klar]); aber trotzdem gut, dass du mir den Hintergrund (eigentlich im wahrsten Sinne des Wortes
) erläutert hast. Da bin ich jetzt nicht mehr beunruhigt, wenn ich das knallige Gelb etc. sehe. Ich vertraue einfach mal auf das, was du am Schluss schreibst:
Dann erst kann man nämlich sagen: Ich stelle Schriftfarbe, Schriftgröße,..sonstwas ein wie in Wikipedia oder Spiegel.de oder was auch immer.
Wenn das so machbar ist: sehr gut.
Ein Wort noch zum farbigen Hintergrund in Tabellenzellen. Der soll in Tabellen mit vielen Zeilen (also mit vielen Beispielen) dem Betrachter die Übersicht erleichtern. Sozusagen zusätzlich zur Umrandung der Zelle habe ich in größeren Tabellen jede zweite Tabellenzeile farblich (dezent) unterlegt, weil so das Auge noch besser erkennen kann, dass hier das nächste Beispiel steht. Wenn die Beibehaltung technisch einen großen Aufwand bedeuten würde, könnte man diesen farbigen Hintergrund auch durchaus weglassen. Aber an sich würde ich ihn ganz gern behalten (natürlich nicht in knallgelb
).
Und jetzt zu der Beispielsseite, die du angefertigt hast:
Ich habe aus einem der Begriffe in deiner Word-Datei eine Test- und Spielseite gemacht:
[...]
Wenn ich das wieder wegtun soll, sags einfach, aber es redet sich leichter, wenn man was vor Augen hat.
Klar. Du kannst es ruhig stehen lassen.
Dann habe ich ein Script gemacht, dass das alles bereinigt - im technischen Sinne.
Das also wäre inhaltlich EINE der 24.000 Seiten - oder? Das meinst du mit "Seite"?
Ganz genau. (Du kannst es dir auch bei PBWorks ansehen: http://enalexiko.pbworks.com/w/page/62557628/%3AAUCH )
Sie gefällt mir vom Aufbau her nach der technischen Bereinigung immer noch recht gut. Die Tabellen sind jetzt zwar beträchtlich breiter (als bei Word sowieso, und auch etwas breiter als bei PBWorks), aber das ist Gewöhnungssache. Nur gibt es damit klarerweise auch mehr Zellen, in denen allenfalls nur eine Zeile steht. Und wenn das mehrmals hintereinander vorkommt (zB. in der Tabelle von Ziffer 8 ), dann bewährt sich schon die zusätzliche Hintergrundfarbe zwecks besserer Unterscheidbarkeit.
Noch ein Detail: Zwischen den einzelnen Ziffern sollte es (gleichfalls aus Gründen der Übersichtlichkeit) immer eine Leerzeile geben. Aber wenn das technisch nicht oder nur kompliziert machbar ist, muss das nicht sein (sofern ich das nach und nach manuell hinzufügen könnte).
Und noch eine Kleinigkeit: Hin und wieder habe ich Tabellen eingerückt (wenn sie keine Beispiele beinhalten, sondern so eine Art Anmerkungstext). Das wäre z.B. in der Tabelle gleich unter Ziffer 8 (jene mit den drei Textzeilen) der Fall. Dürfte man da einfach den linken Tabellenrand nachträglich mit der Maus ein Stück nach innen ziehen, ohne etwas an der Struktur zu zerstören? Also dass es ungefähr so aussehen würde:

Was die Seitenanzahl betrifft:
Du redest von 24.000 Seiten (!)
Wie viele hast du jetzt? - nur um mal ein realistisches Bild zu bekommen.
"MyInfo" weist im Moment ca. 23.600 Seiten/"Documents" aus (deswegen kann ich die Zahl auch so genau benennen). Das entspricht damit der Zahl der Stichwörter in den beiden Word-Dokumenten insgesamt. ("MyInfo" umfasst beide Wörterbuchteile: Deutsch - Griechisch und Griechisch - Deutsch.)
Beitrag geändert von michael-neu (02.08.2019 23:57:12)
Offline
Du kannst MyInfo als Website exportieren.
Mach das mal. Schau rein ob alles beisammen ist, zippe das ganze Verzeichnis und maile mir das an media[ät]beesign.com
Und maile mir bitte auch die Word-Dateien von deutsch-griechisch, wie du sie hast, aber alle.
Ich schaue mal, was man da draus machen kann.
Und maile mir bitte auch die Word-Dateien von deutsch-griechisch, wie du sie hast, aber alle.
Ich habe die zwei Dateien direkt hochgeladen (jeweils eine zip-Datei), falls HH oder andere Interessierte sie auch anschauen wollen:
Deutsch - Griechisch:
--- [bei Interesse bitte über PN nachfragen]
Griechisch - Deutsch:
--- [bei Interesse bitte über PN nachfragen]
Du kannst MyInfo als Website exportieren.
Mach das mal. Schau rein ob alles beisammen ist, zippe das ganze Verzeichnis und maile mir das an ...
Das kommt dann später.
Hier ist der Website-Export von MyInfo (kompletter Ordner [benannt "Test"] als zip-Datei):
--- [bei Interesse bitte über PN nachfragen]
Nur zur Information (falls das von Bedeutung ist):
In der MyInfo-Version des Wörterbuchs gibt es auch ein paar Unterseiten, z.b. beim Stichwort ":GRAMMATIK": Dort sind Inhalte eingearbeitet, die unter Word nicht in den Wörterbuch-Dateien stehen. Die Grammatik-Inhalte befinden sich unter Word in einem eigenen Dokument. Bei MyInfo habe ich einige wenige Kapitel davon als Unterseiten beim erwähnten Stichwort hinzugefügt.)
Danke. 
Edit (14.8.2019):
Links zu den Dateien entfernt.
Beitrag geändert von michael-neu (14.08.2019 18:48:06)
Offline
Yepp, ist angekommen.
Das Problem momentan ist die schiere Größe dieser Sache. Über 700000 (!) Zeilen Quellcode; da gehen alle meine Helferlein in die Knie, außer blauem Kringel sehe ich da nichts mehr.
Aber mit den 25000 html-Dateien aus MyInfo, da denke ich kommen wir weiter, da sind die Häppchen kleiner ;-)
Ist das "Endstand" oder eher nur Testdaten?
Eine eher grundsätzliche Frage:
Dein Plan war (wie ich am Word-Dokument sehe), dass die Seiten nach Anfangsbuchstaben zusammengefasst werden. Das geht nie und nimmer, das kann kein Mensch laden, geschweige denn etwas finden darin.
Manche der Begriffe sind recht ausführlich, andere genau nur Wort - Übersetzung.
Intern muss es aber in jedem Fall so gehandhabt werden, dass jedes Wort eine Seite ist.
Der Zugang wäre dann praktisch NUR über eine Suchfunktion, eventuell mit Vorschägen nach 2-3 Buchstaben.
Im Endeffekt sind dann manche Seiten fast leer (eben nur Wort - Übersetzung).
Ich bin morgen und wahrscheinlich auch übermorgen unterwegs und schau nur sporadisch am Handy hier rein. Also keine Angst, weil ich mich nicht mehr melde. So schnell gebe ich nicht auf. ;-)
Beitrag geändert von boeseroeser (03.08.2019 20:46:14)
Das Problem momentan ist die schiere Größe dieser Sache. Über 700000 (!) Zeilen Quellcode; da gehen alle meine Helferlein in die Knie, außer blauem Kringel sehe ich da nichts mehr.
Es soll ja auch mehr geboten werden, als in herkömmlichen Wörterbüchern drinnensteht.
Aber mit den 25000 html-Dateien aus MyInfo, da denke ich kommen wir weiter, da sind die Häppchen kleiner ;-)
Ist das "Endstand" oder eher nur Testdaten?
Das ist für den Moment das komplette Wörterbuch. Also sozusagen der aktuelle Endstand. Aber wie schon früher erwähnt: Neue Stichwörter und Änderungen/Ergänzungen kommen immer wieder dazu.
Eine eher grundsätzliche Frage:
Dein Plan war (wie ich am Word-Dokument sehe), dass die Seiten nach Anfangsbuchstaben zusammengefasst werden. Das geht nie und nimmer, das kann kein Mensch laden, geschweige denn etwas finden darin.
Kein Problem. Das mit der Zusammenfassung auf Seiten nach Anfangsbuchstaben war nur eine Alternativüberlegung zweiter Wahl von mir - für den Fall, dass damit die Sache technisch erleichert würde. (Es hat auch nichts mit dem Word-Dokument zu tun. Dass ich dort am Dokumentbeginn zu den Anfangsbuchstaben verlinke, hat eher historische Gründe: Ursprünglich hatte ich für jeden Anfangsbuchstaben ein eigenes Word-Dokument.)
Intern muss es aber in jedem Fall so gehandhabt werden, dass jedes Wort eine Seite ist.
Sehr gut. Ist mir nur recht so.
Der Zugang wäre dann praktisch NUR über eine Suchfunktion, eventuell mit Vorschägen nach 2-3 Buchstaben.
Ja, passt perfekt. Die Suchvorschläge (Filter) wären schon eine feine Sache - also so, wie es zB. bei PBworks funktioniert oder hier beim Template "Hortal (WBCE)".
Noch eine Anmerkung zum Thema Stichworte und Suche:
In der Word-Version ist jedem Stichwort ein Doppelpunkt vorangestellt (um eine treffsichere Suche zu gewährleisten). Bei den Stichwörtern in der MyInfo-Version gibt es diese Doppelpunkte nicht (nämlich deshalb nicht, weil eine problemlose Suche dort auch so funktioniert). Ich vermute, für eine Suche auf einer Website wären die Doppelpunkte doch wieder sinnvoll und wichtig.
Zum Beispiel:
Die Eingabe von "Zeit" als Suchbegriff führt bei MyInfo direkt zu diesem Stichwort. (So sollte es sein.) Bei einer Suche im Word-Dokument oder bei PBWorks wird hingegen angezeigt: Arbeitszeit, Besuchszeit, derzeit, Freizeit, Mahlzeit usw. - Das soll vermieden werden. Dazu dient der Doppelpunkt vor den Stichwörtern (also zB. :Zeit).
Ich bin morgen und wahrscheinlich auch übermorgen unterwegs und schau nur sporadisch am Handy hier rein. Also keine Angst, weil ich mich nicht mehr melde. So schnell gebe ich nicht auf. ;-)
Das ist beruhigend.
Danke und ein schönes Wochenende.
Beitrag geändert von michael-neu (03.08.2019 21:55:34)
Offline
Guten Abend.
Die einzelnen html-Seiten aus MyInfo zu nutzen war ja schon eine vorgetragene Alternative zu XML. Der Haken war eine nicht gerade klein zu bezeichnende Index-Datei, wo die Navigation in Dateiform nicht akzeptabel daherkommt.. Da "boeseroeser" die Idee wieder aufgegriffen hat
, dachte ich mir etwas beitragen zu können. Die index-Datei beträgt im Original ca. 11,7Mb. Die Inhalte der index-Datei gehören in die DB (z.B. über CSV... usw.), für die Anzeige und Suche. Dazu muß diese Datei, ganz unabhägig von den Stichwortseiten, die noch ganz alt (HTML 4.01 Transitional) auftreten, valide sein - ich dachte mir xhtml5.
Von den ursprünglichen 11,7Mb sind nun 4MB verblieben, und die Datei ist xhtml5-valide. Das ist wichtig, da eine Konvertierung sehr oft wegen nicht valider Vorlage abbricht.
Für NeuMeikel gäbe es noch etwas zu tun. Die Stichwörter haben an nicht wenigen Stellen Zeilenümbrüche, die für die Darstellung Gift sind. Ich habe die Gruppe A schon bearbeitet, also sollte es mit ? weitergehen. :-D
Stichwort xhtml5: Falls nur html5 gewünscht ist, sollte es kein Problem bereiten das im Kopf der Datei - eben nur dort - anzupassen.
Stichwort Unterseiten (Aufklappmenu): Hier wird man einen zusätzlichen Tabelleneintrag benötigen.
Gruß, HH.
Beitrag geändert von hamburgerhans (04.08.2019 23:56:51)
Offline
Freut mich, Hans, dass du in der Diskussion dabei ist.
Zunächst nur zwecks Klarstellung: Du hast dir ja viele Gedanken zu einer etwaigen Lösung mittels XML bzw. DocBook gemacht. Das soll nicht so sang- und klanglos von der Bildfläche verschwinden. Aber so, wie sich dein Beitrag liest, kannst du auch dem alternativen Ansatz boeseroesers etwas abgewinnen. Sollte man also den jetzt aus deiner Sicht weiterverfolgen, oder meinst du, dass ein XML/DocBook-Projekt aus technischer Sicht oder sonstwie zu bevorzugen wäre? (Mir persönlich ist der boeseroeser-Ansatz zumindest eine Spur vertrauter, während XML/DocBook völliges Neuland für mich wäre - aber darauf soll es nicht ankommen.)
Und jetzt zu den fachlichen Dingen - sofern ich dazu überhaupt etwas beitragen kann bzw. soll, wie z.B. hier:
Für NeuMeikel gäbe es noch etwas zu tun. Die Stichwörter haben an nicht wenigen Stellen Zeilenumbrüche, die für die Darstellung Gift sind. Ich habe die Gruppe A schon bearbeitet, also sollte es mit ? weitergehen. :-D
Zeilenumbrüche gibt es in meinem Dokument in der Tat viele. Wenn das Gift für die Darstellung bedeutet, ist das schlimm. Allerdings weiß ich nicht genau, worauf du dich beziehst: Meinst du mit "die Stichwörter" den Zeilenumbruch nach dem Stichwort selbst (also dem, was in blauer Blockschrift steht)? Oder beziehst du dich auf die Inhalte (den Text) zum jeweiligen Stichwort?
Und du müsstest mir bitte sagen, was genau ich in dem Zusammenhang tun soll. Im Moment ist mir das noch nicht klar.
Stichwort Unterseiten (Aufklappmenu): Hier wird man einen zusätzlichen Tabelleneintrag benötigen.
Diese Unterseiten müssen nicht sein. Die hatten damit zu tun, dass man mit dieser Version von MyInfo (6.35) nicht mehrere Themenbereiche "unter einem Dach" (= im selben "Topic") haben kann. (Das soll sich mit der neuen Version ändern.) Ich kann mit der derzeitigen Version also nicht einen Bereich "Wörterbuch" und daneben einen Bereich "Grammatik" (oder einen Bereich "Abkürzungen" usw.) erstellen. Deshalb habe ich versucht, die entsprechenden Inhalte in Unterseiten einzugliedern. Ich glaube, es gibt sie nur an zwei Stellen: beim Stichwort "GRAMMATIK" und bei der Startseite (für eine Liste der Abkürzungen und Kürzel).
Ich hätte es ohnehin lieber aus dem Wörterbuch ausgegliedert und zB. die Grammatik als eigenen Menüpunkt, so wie ich es zB. hier probeweise angelegt habe: http://kompakt.bplaced.net/index.html/n … ebook.html
(Was die Abkürzungen bzw. Kürzel betrifft, hängt es von der Gesamtlösung ab, wo man sie am besten hingibt.)
Beitrag geändert von michael-neu (05.08.2019 04:03:58)
Offline
ICh hab mir in der Zwischenzeit ein Plan wachsen lassen - und wenn der aufgeht, hab ich wohl bald einmal eine funktionierende Seite.
Sodanna, mein Plan ist bis jetzt mal aufgegangen (mit nur wenigen Flüchen ;-)
Alles noch ganz grob und ohne CSS und Feinheiten.
http://work.beesign.at/
Suchen (links im Menü) -> Vorschlag anklicken -> Seite
Immerhin: Die Links scheinen alle zu funktionieren (dass man wieder ein Stück raufscrollen muss, um den Anker zu sehen, liegt am Template, das kann man fixen)
Die Suche ist hinreichend flott, Umlaute scheinen alle zu stimmen.
Bei der Suche habe ich keinen Unterschied zwischen DE-GR und GR-DE gemacht, das ergibt sich ja ohnehin aus dem gesuchten Wort.
Editor gibt es noch keinen, es ist einfach mal der STatus Quo abgebildet.
Auch wenn boeseroeser schneller war, soll der Text noch rein.
@michael-neu
Zuerst sei mal gesagt, daß mit der aktuellen index-Datei - das beiliegende Zubehör, CSS usw. ist auch geändert, nicht vergessen - das Laden derselben ziemlich flott geht, wenn man kein Modem mit 9600 bit/s benutzt, weshalb die Arbeit daran nun auch etwas programmiererfreundlicher ist.
dem alternativen Ansatz boeseroesers etwas abgewinnen.
Eine Alternative hatten wir ja schon auf dem Tisch. Aber nicht nur deshalb kann ich einem neuen Ansatz nicht nur "etwas" abgewinnen. Wenn sich niemand für DocBook erwärmen kann, ist es eben die Alternative, die für alle "eher vertraut und überschaubar" ist. Somit ist boeseroeser m.E. zum richtigen Zeitpunkt aktiv geworden.
Kann sein, daß boeseroeser die index mit regex "rippt"
und so für die DB reifmachen, oder sogar direkt in die DB übertragen wird. Ich weiß nicht, kann also nichts weiter hierzu sagen.
Stichwort Zeilenumbrüche. Es betrifft das
<div class="tier1"><a class="document" href="5705.html">DONAU, die</a></div> 
<div class="tier1"><a class="document" href="23795.html">ERGIESSEN (ergießen)
(sich)</a></div> 
Es muß mit einem Editor auf Linie gebracht werden
<div class="tier1"><a class="document" href="23795.html">ERGIESSEN (ergießen)(sich)</a></div> 
Apropos "eher vertraut und überschaubar". Hier hat es jetzt den Vorteil, daß Du mit was auch immer für jeden Begriff eine html-Seite anlegen kannst, egal ob nun 4.01 Trans., xhtml oder html5: Du brauchst also kein spezielles Werkzeug mehr. Einzig der Index, der als MySQL-Datei/Dump bräuchte eines, das "vertraut und überschaubar"
erscheint, denn irgendwie mußt Du eine neue Seite in den Index bekommen.
Eine Alternative zum Index in der Datenbank gibt es ja auch noch - genauso leicht zu handhaben wie die Wort-Dateien, eben html - indem Du den Index in A-Z aufteilst, und auswählbar machst. Es hätte sogar noch einen kleinen Vorteil gegenüber einer Suchfunktion, da der Leser nicht erwarten kann, sämtliche Begriffe finden zu können.
ps. Bin noch eine Woche weg - so gut wie...
Gruß, HH.
Beitrag geändert von hamburgerhans (05.08.2019 12:45:15)
Offline
Jepp, zum Status:
Ich hab zuerst mal gesucht wo ich programm-generiertes HTML her bekomme - da bin ich beim HTML-Export von MyInfo fündig geworden.
Die dabei erzeugte index.html ist unhandlich, weil nicht für 25000 Einträge konzipiert.
Daher hab ich mit Suchen/Ersetzen aus
[== HTML ==]
<tr id="1459" class="a">
<td>
<div class="tier1">
<a href="#" class="doc">
</a>
<img src="images/item.gif">
</img>
<a href="2246.html" class="document">AUFSPANNEN</a>
</div>
</td>
</tr>gemacht:
INSERT INTO wbce_mod_woerterbuch SET o_id=1459, wid=2246, lang=1, title='AUFSPANNEN';so ca 25000 mal. RegEx Suchen-Ersetzen kann sehr zäh sein, ich konnte nebenher Fernsehen, auf ein Bier gehen, wieder Fernsehen...
Ein bissel fluchen - nochmal fluchen... und es war in der Datenbank.
Die Langtexte sind noch NICHT in der Datenbank, sondern einfach die html-Seiten aus dem Export hochgeladen, 25000 Files in einem Verzeichnis.
Beim Seitenaufruf werden die per $text = file_get_contents($file ); abgeholt, abgespeckt und etwas gefiltert.
Das muss man sich genauer ansehen, deswegen fehlt Teil 2 noch:
Geplant:
In einem weiteren Schritt sollen diese gefilterten Inhalte in eine weitere DB-Tabelle geschrieben werden. Ich habe 2 Tabellen vorgesehen, damit das Suchen schneller geht. Außerdem sind so MIschformen vorstellbar.
Nachteil dabei: Langtexte, die nicht in der DB stehen, können nicht durchsucht werden.
Man sieht: Denken ist das wichtigste ;-) Standardlösung für alles gibt es nicht.
Beitrag geändert von boeseroeser (05.08.2019 13:24:56)
Ich sags mal so: Du hättest nicht suchen müssen, wenn Du Dir den Index, den ich an einer Nachricht angehängt hatte, genommen hättest. Der ist schon "bereinigt". Aber mach' mal, wird schon werden.
Gruß, HH.
Offline
Großartig, boeseroeser! Vielen, vielen Dank!
Ich habe jetzt work.beesign.at gerade mal kurz ausprobiert. Die zwei für mich (und wahrscheinlich jeden Nutzer eines Online-Wörterbuchs, -Lexikons usw.) zentralen Dinge scheinen hervorragend zu funktionieren: die Suchfunktion und die Geschwindigkeit.
Das wollte ich jetzt gleich mal hocherfreut festhalten. Ich melde mich dann später mit ein paar Details.
Auch dir, HH, wieder danke. Ich nehme an, meine Hausaufgabe betreffend die Zeilenumbrüche hat sich durch boeseroesers Wunderwerk vorerst erübrigt.
Wenn nicht, bitte um "Ermahnung".
Was deine Überlegungen zum Index betrifft:
Einzig der Index, der als MySQL-Datei/Dump bräuchte eines, das "vertraut und überschaubar"
erscheint, denn irgendwie mußt Du eine neue Seite in den Index bekommen.
Eine Alternative zum Index in der Datenbank gibt es ja auch noch - genauso leicht zu handhaben wie die Wort-Dateien, eben html - indem Du den Index in A-Z aufteilst, und auswählbar machst. Es hätte sogar noch einen kleinen Vorteil gegenüber einer Suchfunktion, da der Leser nicht erwarten kann, sämtliche Begriffe finden zu können.
Also wenn gesichert ist, dass es ohne Geschwindigkeitseinbußen oder andere Probleme so funktioniert wie derzeit auf boeseroesers work.beesign.at, wäre ich damit völlig zufrieden. Ein sichtbarer Index A-Z ist damit meines Erachtens nicht erforderlich. Ich denke, wer ein (Online-)Wörterbuch benützt, möchte (im typischen Fall) einfach auf schnellstem Wege zum gesuchten Sichwort (bzw. seiner Übersetzung) kommen. Das (virtuelle) "Blättern" in einem Wörterbuch hat sicherlich auch seinen Reiz - aber wer das möchte, kann es sich ohnehin als pdf-Datei herunterladen und dann darin scrollen.
So viel für den Moment.
Offline
Nur mal eine Anmerkung. Ich bin in den Überlegungen zum Thema Wörterbuch nicht nur bei Deinem, sondern ich schaue immer auch auf die Integrierungsmöglichkeit in beliebiges CMS. Beispielsweise gäbe Index Aa-An,Ao-Az, B-Z die Möglichkeit mit "Hausmitteln" in jedem CMS zurechtzukommen, sogar bei ausschließlich statischen html-Seiten, also ganz ohne CMS.
Zu "Zeilenumbrüche": Ich weiß nicht, ob die beseitigt sind. Jedenfalls wären sie im responsiven Design nicht angebracht.
Zu "work.beesign.at".
Ist das Wörterbuch mit einem Smartphone "gescheit" zu lesen bzw. bedienen?
Habe mal reingeschaut. Die Wörterseiten passen sich sogar am Bildschirm an (responsiv), und können als barrierefrei betrachtet werden.
Index (Suche) funktioniert anscheinend nicht ohne Javascript. Ist das so? Irgendwas mit Ajax?
Gruß, HH.
Beitrag geändert von hamburgerhans (05.08.2019 15:03:33)
Offline
Ich bin in den Überlegungen zum Thema Wörterbuch nicht nur bei Deinem, sondern ich schaue immer auch auf die Integrierungsmöglichkeit in beliebiges CMS. Beispielsweise gäbe Index Aa-An,Ao-Az, B-Z die Möglichkeit mit "Hausmitteln" in jedem CMS zurechtzukommen, sogar bei ausschließlich statischen html-Seiten, also ganz ohne CMS.
Klar. Wenn ihr schon im Thema drinnen seid, beschäftigt euch mit allen Aspekten, die für euch von Interesse oder Nutzen sind.
Ist das Wörterbuch mit einem Smartphone "gescheit" zu lesen und zu bedienen?
Ja, das wäre gut zu wissen. Aus Eigenem kann ich nichts dazu sagen, weil ich kein Smartphone besitze. (Ich arbeite ausschließlich am Desktop.)
Zu "work.beesign.at".
Ist das Wörterbuch mit einem Smartphone "gescheit" zu lesen bzw. bedienen?Habe mal reingeschaut. Die Wörterseiten passen sich sogar am Bildschirm an (responsiv), und können als barrierefrei betrachtet werden.
Noch etwas dazu (um euch vielleicht einen Aufwand zu ersparen):
Nachteil dabei: Langtexte, die nicht in der DB stehen, können nicht durchsucht werden.
Wenn du damit so etwas wie eine Volltextsuche meinst: Die bräuchte es (jedenfalls nach meinen derzeitigen Überlegungen) gar nicht zu geben. Wichtig ist die Suchmöglichkeit im Stichwortindex.
Beitrag geändert von michael-neu (05.08.2019 15:20:04)
Offline
Sorry - ich hab den Großteil ja schon am Samstag gemacht, ich hab nix mitbekommen von bereinigten Indizes und Zeilenumbrüchen.
Was mir derzeit etwas Kopfzerbrechen macht, sind die generierten Klassen. Das ist irgendwie etwas "wirr", ich komme auf keinen grünen Zweig.
VIelleicht solltest du (Michael) mal definieren, was wie aussehen SOLL. Am besten so, dass ich es einem Computer erklären kann ;-)
zb:
-- Jede 2. Tabellenzellte soll (hellgelb) hinterlegt sein.
-- Eine Tabelle, die NICHT 2 Spalten hat, soll hellgrau hinterlegt sein.
-- Sprunganker (Ziele) sollten soundso sein.
...
Wegen responsiv braucht ihr euch keine Sorgen machen, da bin ich Weltmeister.
Vielleicht solltest du (Michael) mal definieren, was wie aussehen SOLL. Am besten so, dass ich es einem Computer erklären kann ;-)
Um dir das besser beantworten zu können, eine Frage vorweg:
Gibt es bei deinem Lösungskonzept die Möglichkeit, manche Details individuell zu gestalten - d.h. bei einem Stichwort so, und bei einem Stichwort anders?
1. Konkretes Beispiel:
zb:
-- Jede 2. Tabellenzelle soll (hellgelb) hinterlegt sein.
Das ist etwas, was ich bisher nur in größeren Tabellen (= solchen mit vielen Beispielen) gemacht habe. (Es in allen zu machen, führt nämlich vielleicht zu einem Übermaß an Kontrasten.)
Daher wäre meine Überlegung Folgende:
Könntest du das mal (nur) bei ein oder zwei einschlägigen Stichworten machen?
Also z.B. unser bekanntes Stichwort AUCH: In jeder Tabelle* sollte die zweite Tabellenzeile (linke+rechte Spalte) die Hintergrundfarbe 255,255,220 bzw. #ffffdc haben.
*(Anm.: Hier dann unabhängig von der Tabellengröße, also auch bei den kleineren. Ich denke, innerhalb eines Stichworts sollte es einheitlich sein: entweder überall oder nirgends der geänderte Hintergrund.)
Für andere Stichworte könnte ich mir das dann individuell überlegen und die Hintergrundänderung selbst manuell nachtragen, indem ich mir deinen Code aus dem Musterbeispiel (also etwa dem Stichwort AUCH) anschaue. Das erspart dir Arbeit und gibt mir den individuellen Gestaltungsspielraum. Falls das technisch so machbar ist.
2. Hier sieht es anders aus:
-- Eine Tabelle, die NICHT 2 Spalten hat, soll hellgrau hinterlegt sein.
Ja, ich glaube, das kann ich generell (für alle einschlägigen Tabellen) sagen (es betrifft ja primär die Übersichten vor umfangreicheren Stichworten):
Die sollten alle in dezentem hellgrau unterlegt sein, also z.B. 243,243,243 bzw. #f3f3f3.
3. Was die Sprunganker betrifft:
-- Sprunganker (Ziele) sollten soundso sein.
Meinst du deren Kennzeichnung beim Editieren? Wenn man bei ihrem Markieren den Ankernamen lesen kann (so, wie das bei Word ist), genügt mir das eigentlich. Oder eine dezente Kennzeichnung deiner Wahl (bei MyInfo ist es ein winziger Kreis + Strich am Beginn der betreffenden Zeile).
4. Hintergrundfarbe bei Gliederungsziffern plus Text daneben (bei größeren Stichwörtern):
Siehe oben 1.: Auch da wäre es praktisch, wenn ich das individuell (stichwortbezogen) machen könnte und du einfach ein Muster vorgibst, z.B. für die Ziffern beim Stichwort AUCH: der entsprechende Hintergrund in Gelb 255,255,153 bzw. #ffff99 (wenn möglich: nicht überall für dir komplette Zeile, sondern manchmal nur für einen Teil davon, s. etwa die Z 6, 7 und 8 ).
Wenn es am einfachsten ist, das überhaupt nicht zu automatisieren, sondern es bei jedem Stichwort durch Markieren im Editor manuell vorzunehmen, mache ich das gern so. (Dann wäre der Standard: keine Hintergrundfarbe.)
5. Die Gliederungsziffern selbst:
Fettdruck wäre wichtig (und ist ja schon da). Unterstreichung könnte noch dazukommen (muss aber nicht sein, wenn das technisch Umstände macht).
6. Linkfarbe:
nach Möglichkeit dunkelgrün 0,128,0 bzw. #008000
7. Zu den griechischen Stichwörtern:
Unmittelbar unter ihrer Nennung in Blockbuchstaben stehen sie nochmals in Kleinbuchstaben. Das ist vor allem deshalb wichtig, weil Wörter mit Kleinbuchstaben praktischerweise fast immer ein Betonungszeichen tragen, was das Lesen und die Aussprache sehr erleichtert. Dieses Wort in Kleinbuchstaben war bisher hervorgehoben (in Word durch dunkelblaue Farbe, in MyInfo durch dunkelblaue Farbe und etwas größere Schrift). Vielleicht könnte man in deinem Modell die Schrift gleichfalls etwas vergößern? Und (wenn möglich) dafür die gleiche Farbe verwenden wie in der Blockschrift-Version darüber? (Welche immer man dann nimmt - aber das ist ja dann der Feinschliff, wenn ich das richtig verstanden habe.)
8. Umgekehrt bei den deutschen Stichwörtern:
Die stehen unterhalb der "Überschrift" noch einmal (gleichfalls in Blockschift). Das ist auch logisch, weil es ja so aus MyInfo kommt. Wenn ich mir das in der Web-Version ansehe, könnte man das eigentlich weglassen, weil es keinen Informationsgewinn gibt. (Von Ausnahmen möglicherweise abgesehen - das müsste ich mir noch ansehen.) Aber prinzipiell: Wenn das technisch leicht machbar ist, könnte man es weglassen (also die Wiederholung des Stichworts). Wenn nicht: auch kein Problem.
Das wäre ein "Wunschzettel" (weil du danach gefragt hast
) :
Beitrag geändert von michael-neu (05.08.2019 17:43:08)
Offline
Gibt es bei deinem Lösungskonzept die Möglichkeit, manche Details individuell zu gestalten - d.h. bei einem Stichwort so, und bei einem Stichwort anders?
Grundsätzliches zum Verständnis:
Dass derzeit die HTML-Dateien aus MyInfo geladen und dargestellt werden, ist ein Zwischenschritt, der in diesem Fall quasi auf dem Weg lag und mir nützlich erschien. Ich erspare mir damit den Massen-Import in die DB, sondern kann das stückweise später machen.
Ich werde natürlich noch den Editor einbauen, damit kannst du - wie in jedem WYSIWYG-Abschnitt - die Inhalte ändern, wie du willst.
Das wird dann in die Datenbank gespeichert, die entsprechende HTML-Datei ist dann obsolet.
Also: Bei jedem Seitenaufruf wird zuerst geschaut, ob etwas dazu in der Datenbank gespeichert ist - wenn nicht, wird die HTML Datei verwendet.
Dabei wäre es natürlich gut, wenn du sowenig Änderungen wie möglich machen MUSST. Weil: Alles, was mal gespeichert wurde, wird nicht mehr per Script verändert. Überlege dir daher gut, was vorher automatisch erledigt werden kann.
Und ja: Dass die Titel 2x stehen, kommt aus MyInfo. Den ersten (groß) kann ich leicht entfernen, der 2. ist nur dadurch greifbar, dass er der Erste im eigentlichen Inhalt ist.
Ich hab den ersten mal entfernt. Der 2. Titel sieht ziemlich mickrig aus und ist keine echte Überschrift.
Edit: Hab ein wenig gebastelt.
Beitrag geändert von boeseroeser (05.08.2019 20:14:13)
Zunächst mal: Die Suche funktioniert einfach exzellent.
So hatte ich mir das als Idealfall immer vorgestellt.
(Zu einem kleinen Detail melde ich mich dann noch später.)
Und ja: Dass die Titel 2x stehen, kommt aus MyInfo. Den ersten (groß) kann ich leicht entfernen, der 2. ist nur dadurch greifbar, dass er der Erste im eigentlichen Inhalt ist.
Ich hab den ersten mal entfernt. Der 2. Titel sieht ziemlich mickrig aus und ist keine echte Überschrift.
Ich "sehe" das (im wahrsten Sinne des Wortes) so: Bei den deutschen Stichwörtern würde es für meinen Geschmack so passen. Mickrig finde ich da nichts. (Du inzwischen ja auch nicht mehr, wie ich sehe.
) Es gefiele mir sogar recht gut. Aber bei den griechischen Stichwörtern geht mit der Überschrift auch die Darstellung des Wortes in Blockbuchstaben verloren. Und das ist doch ein Informationsverlust. Wenn ich dich daher bitten dürfte, doch wieder zur vorigen Variante zurückzukehren? (Es sei denn, du hast noch eine andere Idee.) Lieber etwas Redundanz bei den deutschen Stichwörtern, aber dafür alles komplett bei den griechischen. (Eine Möglichkeit wäre noch: Es vorerst so belassen, wie es jetzt ist - und ich trage schrittweise bei den griechischen Stichwörtern die Schreibweise in Blockschrift nach.)
[Nachtrag: Ich sehe gerade noch etwas:
So, wie jetzt ist, sieht man in der Stichwortzeile zuerst für einen Moment das Stichwort in "normaler" (kleiner) Schrift - erst dann springt es auf die große Version. Das ist - rein visuell - auch nicht so günstig.]
Und zu dem Grundsätzlichen:
Ich werde natürlich noch den Editor einbauen, damit kannst du - wie in jedem WYSIWYG-Abschnitt - die Inhalte ändern, wie du willst.
Das wird dann in die Datenbank gespeichert, die entsprechende HTML-Datei ist dann obsolet.Also: Bei jedem Seitenaufruf wird zuerst geschaut, ob etwas dazu in der Datenbank gespeichert ist - wenn nicht, wird die HTML Datei verwendet.
Dabei wäre es natürlich gut, wenn du sowenig Änderungen wie möglich machen MUSST. Weil: Alles, was mal gespeichert wurde, wird nicht mehr per Script verändert. Überlege dir daher gut, was vorher automatisch erledigt werden kann.
Ich habe es teilweise, aber noch nicht ganz verstanden. (Spielt denn die css-Datei bzw. deren Inhalt nicht auch herein? Oder ist das ohnehin gemeint mit "HTML-Datei"?)
Anders gesagt: Du schriebst ja weiter oben:
Das Aussehen aller Elemente auf einer Website wird durch zentrale "Style Sheets" definiert, also per CSS. Das ist üblicherweise das letzte, was man in Angriff nimmt.
[....]
Das ist der Grund, warum ich es als Ziel ansehe, dass ich da die Standardschrift des Templates sehe und nicht 12pt Arial, Farbe #000 (wie in deiner Word-Datei angegeben)
Dann erst kann man nämlich sagen: Ich stelle Schriftfarbe, Schriftgröße,..sonstwas ein wie in Wikipedia oder Spiegel.de oder was auch immer.
Wenn du jetzt empfiehlst: "Überlege dir daher gut, was vorher automatisch erledigt werden kann." Beziehst dich damit schon auf diese Details der letzten Phase?
Nochmals anders formuliert: Ist jetzt der geeignete Moment, um meine Anregungen zu Details wie folgenden zu äußern: Schriftfarbe, -art und -größe, Zeilenabstand (keine Sorge, so wie er derzeit ist, gefällt er mir ohnehin
), bestimmte Unterstreichungen, Hintergrundfarben (wie ohnedies schon oben erwähnt), Tabellenbreite usw.?
Wenn ja, dann könnte ich ja mal meine diesbezüglichen Vorstellungen nennen und du könntest mir dann sagen, was davon sinnvollerweise automatisiert erledigt werden kann. Aber ich warte jetzt noch deine Bestätigung ab, ob ich das richtig verstanden habe.
Beitrag geändert von michael-neu (05.08.2019 21:11:11)
Offline
Die Sache mit dem CSS ;-)
Damit ich etwas Fett, Uppercase, gelb hinterlegt...usw machen kann, muss ich es "selektieren" können. Nicht mit der Maus ;-) sondern: (äh, wie sag ichs..)
Äh - nein, das erkläre ich jetzt nicht. Da gibt es dicke Bücher.
Da du keine Absatzformate verwendet hast, kann ich mich fast nur an den "classes" anhalten.
(Info: Klassennamen sind immer willkürlich gewählt, sie selbst bedeuten nichts, sondern "zeigen" auf eine Definition)
Derzeit gibt es in den HTML-Dateien zwar "classes", aber sie sind irgendwie "wirr". Ich kann nicht sicher sagen: die class="rvps3" bezeichnet immer einen Sprung-Anker und soll daher den Text Grün machen - nein (leider): Sie scheint willkürlich mal da mal dort aufzutauchen.
also etwas technischer:
.rvps3 {color:green;}
Macht da die Sprunganker (richtigerweise) grün, aber woanders sind die Sprunganker class="rvps13" und class="rvps3" markiert stattdessen irgendeinen Text irgendwo grün.
Ich bringe das nicht auf die Reihe.
Ich schätze, du wirst das jetzt nicht verstehen. Aber vielleicht kann es dir wer anderer erklären..
Die Suche:
Die muss noch besser rein ins Modul. Das ist nicht ganz ideal derzeit.
Ich schätze, du wirst das jetzt nicht verstehen.
Richtig.
Aber das macht nichts. Ich muss nicht alles verstehen. Du sagst es mir einfach, wenn ich etwas tun soll.
Aber vielleicht dazu:
Derzeit gibt es in den HTML-Dateien zwar "classes", aber sie sind irgendwie "wirr".
[...]
Ich bringe das nicht auf die Reihe.
Ich habe auch mit "RightNote" testweise ein paar Webseiten erstellt (ist ein Programm ähnlich wie "MyInfo"). Würde es etwas bringen, dir auch diese HTML-Dateien zu schicken? Es wären aber nur einige wenige, weil ich das mit RightNote nicht weiterverfolgt habe.
Und die HTML-Dateien jener Seiten, die ich auf PBWorks habe, könnte ich auch noch anbieten.
Die Suche:
Die muss noch besser rein ins Modul. Das ist nicht ganz ideal derzeit.
Ich finde sie jetzt schon toll (von der Funktionsweise her).
Ein Detail möchte ich nur bescheiden anmerken:
Zum gewünschten Stichwort kommt man derzeit, wenn man es in der Ergebnisliste anklickt. Das ist sehr gut so (und sollte jedenfalls so bleiben).
Es gibt aber Menschen (unter ihnen manchmal auch ich) - die tippen ein (typischerweise kurzes) Suchwort in das Fenster ein - zB. "AN" - sehen, dass es tatsächlich in der Liste steht und drücken voller Vorfreude und Eifer sofort die Enter-Taste (statt auf das Stichwort in der Liste). Wenn man das macht, landet man aber auf dieser allgemeinen Suchseite, auf der dann noch dazu (unzutreffenderweise) steht: "Keine Ergebnisse.":

Gleiches passiert, wenn man auf die Lupe rechts neben dem Suchfenster klickt.
Also wenn man das so machen könnte, dass auch Klick auf "Enter" (bzw. Klick auf Lupe) den gleichen Effekt haben wie Klick auf das erste Stichwort in der Liste (nämlich dass sich die betreffende Seite öffnet), dann wäre das zusätzlich eine Vereinfachung bei der Suche. Das ist aber eine Luxuswunsch von mir. Daher sei es eben nur ganz bescheiden angemerkt. 
Beitrag geändert von michael-neu (05.08.2019 21:58:22)
Offline