Wikiup:Verbesserungsvorschläge/Archiv/2009/Dezember

aus Wikipedia, der freien Enzyklopädie

Verbesserung der PDF Versionen

Gerade bei längeren Artikeln fehlt mir in der jeweiligen PDF-Version das Inhaltsverzeichnis. Es wäre wirklich sehr hilfreich, wenn dieses auch in den PDF-Fassungen mit angedruckt würde, wie es ja schon bei der normalen Druckversion geschieht. Zusätzlich würde ich mir wünschen, dass die Nummerierung der Überschriften dann auch in der PDF-Version erzeugt wird. Ganz optimal wäre es, wenn im Inhaltsverzeichnis dann sogar die Seitenzahlen auftauchen würden. Ein zweiter Vorschlag ist der Andruck „aus Wikipedia + „Datum der letzten Änderung“ in der Fußzeile unter dem Strich auf jeder Seite. Da in der Kopfzeile der Artikelname mit Seitenzahl angegeben wird, gehe ich davon aus, dass dies nicht so schwierig ist. Derzeit enthalten die PDF-Versionen im Gegensatz zu den Druckversionen überhaupt keine Datumsangabe. Anhand der Datumsangabe kann man sich dann mit Hilfe der Versionsgeschichte ansehen, was inzwischen im Artikel passiert ist. Gruß --Lutz Hartmann 14:06, 2. Dez. 2009 (CET)

Ich glaube auf Hilfe:Buchfunktion/Feedback ist dies besser aufgehoben. Der Umherirrende 16:10, 2. Dez. 2009 (CET)
Danke für den Hinweis. --Lutz Hartmann 16:15, 2. Dez. 2009 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Lutz Hartmann 16:15, 2. Dez. 2009 (CET)

Editorwerkzeuge selbst erzeugen

Hallo,
da ich häufig in der Eingangskontrolle unterwegs bin und es auf Dauer ziemlich mühsam ist, jeden Schnelllöschantrag selbst einzutippen, schlage ich hiermit vor, dass man seine Editorwerkzeuge individuell selbst erstellen kann (Natürlich mit kleinem Bildchen, was ebenfalls selbst ausgesucht werden kann). Das kann man ja nicht nur für so etwas gebrauchen, sondern auch für andere Vorlagen oder Werkzeuge wie zum Beispiel <onlyinclude>TEXT</onlyinclude>. Das würde ich mir wirklich SEHR wünschen. Ansonsten habe ich nix zu beanstanden ^^.
Gruß -- Niemot | Diskussion Bewerte mich! 19:33, 12. Dez. 2009 (CET)

Die Idee hatten auch schon andere: Wikipedia:Helferlein/Extra-Editbuttons --Der Umherirrende 19:48, 12. Dez. 2009 (CET)
Bzw. Wikipedia:Skin, dort besonders die Tools/Werkzeuge von Benutzer:PDD, siehe Benutzer:PDD/monobook FAQ. --91.64.184.243 21:38, 13. Dez. 2009 (CET)

Klappleiste für Einzelnachweise

Die Zunahme von Einzelnachweisen/Fußnoten führt inzwischen dazu, dass dieser Abschnitt oft sehr umfangreich wird und öfters sogar den eigentlichen Artikeltext an Länge übetrifft. Aus der Sicht der Qualitätssicherung und der Überprüfbarkeit sind viele Einzelnachweise durchaus erwünscht und wenn sie am Artikelende untergebracht werden, stören sie auch nicht besonders beim Lesen, auch wenn es vielleicht nicht immer schön aussieht. Möchte man Artikel jedoch ausdrucken, dann stören einen exzessive Fußnoten vielleicht schon eher. Eine Möglichkeit, das zu beheben, wäre eventuell die Einzelnachweise in einer Klappleiste am Ende des Artikels unterzubringen, so dass die Einzelnachweise nur sichtbar sind, wenn man sie gezielt anschauen will bzw. anspringt.--Kmhkmh 19:59, 12. Dez. 2009 (CET)

Eher auf FzW ansprechen oder auf der Diskussionsseite zu den Einzelnachweisen oder WP:BLG. --91.64.184.243 21:34, 13. Dez. 2009 (CET)
Unter Benutzer:Malte Schierholz/Einzelnachweise findest du ein Skript, das die Einzelnachweise ein- und ausklappen kann. --Schnark 09:27, 15. Dez. 2009 (CET)

Entschärfung des Relevanzproblems (Deletionism and Inclusionism)

Ich schlage vor allen Wikipediaartikeln ein ordinales Attribut: "Relevanz" (oder auch "Enzyklopedische Qualität") zuzuordnen. Eine einfache dreistufige Skala könnte durchaus genügen:

  1. niedrig - neu eingestelle Artikel ohne Peer-Review
  2. mittel - Artikel mit Peer-Review aber fragwürdiger Relevanz (nach aktuellen Kriterien)
  3. hoch - Artikel mit Peer-Review und gesicherter Relevanz

Wenn es weiterhin möglich gemacht würde bei der Artikelsuche die gewünschte Mindestrelevanz angzugeben, ĸönnte man allen Beteiligten gerecht werden:

  • Wer gerne in einer klassischen Enzyklopedie blättern will muss keine irrelevanten Informationen betrachten
  • Der redaktionelle Aufwand kann auf die Verbesserung von Artikeln statt auf Löschdebatten gelenkt werden
  • jeder der beitragen möchte kann das erstmal tun ohne eine Löschung zu befürchten (nicht signierter Beitrag von 92.206.71.195 (Diskussion | Beiträge) 17:00, 1. Dez. 2009 (CET))
Im Prinzip eine gute Idee, aber: Verwaltungskram, Verwaltungskram, Verwaltungskram - Wikipedia darf darin nicht erstarren. Und genau da liegt meiner Ansicht nach das Problem bei diesem Vorschlag. --91.64.184.243 21:40, 13. Dez. 2009 (CET)
In der Wikipedia wird nicht „geblättert“ – die Kennzeichnung also nur marginale Vorteile:
  • „Zufälliger Artikel“
  • Auswahl für Wikipedia-Ausgaben auf Papier, DVDs, …
Für ersteres könnte man die Zugriffszahlen verwenden – häufig nachgefragte Artikel tauchen auch häufiger zufällig auf – und für letzteres genügt eine manuelle Einteilung sowieso nicht. — 3247 ✐ 12:55, 15. Dez. 2009 (CET)

Ungültiges HTML bei bestimmten Zwischenüberschriften

Es entsteht ungültiges HTML, wenn die Zwischenüberschriften nicht mit den Zeichen [A-Za-z] beginnt, also bei beispielsweise Umlauten oder Ziffern. Fiktive Beispiele für solche Überschriften:

  • Überblick
  • Österreich
  • 2. Wikipediawettbewerb

Dies passiert, weil in einem ID-Attribut dann ein Punkt oder eine Ziffer am Anfang steht. Dies ist gemäß Standard nicht erlaubt.

Ich hoffe, dass dafür eine Lösung gefunden werden kann. -- Tofra Diskussion Beiträge 18:48, 5. Dez. 2009 (CET)

Das soll sich mit HTML 5 ändern: http://www.w3.org/TR/html5/dom.html#the-id-attribute — 3247 ✐ 12:59, 15. Dez. 2009 (CET)
WP benutzt aber XHTML 1.0 und ich glaube nicht, dass sie da in nächster Zeit auf HTML5 umsteigen werden. -- chatter™ 01:25, 16. Dez. 2009 (CET)
Was nicht als text/xml+html, text/xml, application/xml+html oder application/xml, sondern als text/html ausgeliefert wird, ist ohnehin Tagsuppe. — 3247 ✐ 22:43, 19. Dez. 2009 (CET)
Bug 9530 --Der Umherirrende 23:49, 19. Dez. 2009 (CET)

Links auf einen Artikel

Es wäre in vielen Fällen ganz hilfreich, wenn statt den Gliederungspunkten (*) eine Nummerierung bei den Links auf einen Artikel (#) stehen würde. So weiß man jederzeit die Anzahl der Verlinkungen. Außerdem wäre eine alphabetische Sortierung der Links auch ganz hilfreich. --K@rl (Verbessern ist besser als löschen) 09:14, 18. Dez. 2009 (CET)

Die Liste ist derzeit nach dem Alter der betreffenden Artikel (ihrer internen Nummerierung) sortiert. Das hat Vorteile gegenüber dem Alphabet. --h-stt !? 12:42, 18. Dez. 2009 (CET)
Zum Counter: Bug 4394. Zur Sortierung Bug 13614 --Der Umherirrende 23:52, 19. Dez. 2009 (CET)

Wikipedia:AZ

Bei leergelassener Kommentarzeile die ersten Charaktere des geschriebenen Textes automatisch in die Kommentarzeile pasten. Fossa?! ± 20:50, 12. Dez. 2009 (CET)

Dann müssen die Admins dauernd ran, weil dort persönlichkeitsrechtlich Bedenkliches steht. Im Artikel ist es ja schnell revertiert, aber aus der Versionsgeschichte bekommt man diesbezüglichen Unfug nicht so schnell weg. --91.64.184.243 21:33, 13. Dez. 2009 (CET)
Wenn es "nur" revertiert wird, dann ist über die Versionshistory der gesamte (Rechtsverletzende) Artikeltext aufzufinden - nicht nur in der Zusammenfassung, auch der Volltext. Wenn "ein Admin ran muss", dann muss er ohnehin gleich die gesamte Version löschen, also Artikel inklusive (Auto-)Zusammenfassung. Insofern wäre das kein Problem. --Wirthi ÆÐÞ 08:19, 21. Dez. 2009 (CET)
nicht zwingend (die löschung); sagte das AG Berlin zum thema porno und ME ...Sicherlich Post 09:41, 21. Dez. 2009 (CET)

Nach dem Anmelden

Aus Wikipedia:FZW

Nach dem Anmelden erscheint immer eine Spezialseite mit den Hinweisen
  • Anmeldung erfolgreich
  • Du bist jetzt als „.....“ bei Wikipedia angemeldet.
  • Automatisch wurdest du auch an folgenden Projekten der Wikimedia Foundation angemeldet:
[mehrere SpecialAutoLogin-Logos] wie books news commons source etc.
  • Zurück zur Seite xyz
Die Logos sind mit kurzen Texten unterlegt. Viel besser fände ich, wenn bei Anklicken eines Logos gleich auf das Projekt verlinkt würde.
Am besten, wenn sich einstellen ließe, ob auf Hauptseite, Benutzerseite oder sonstwohin, aber es wäre schon ganz toll, wenn man irgendwohin auf diese direkte Art käme. Leider kann ich das nicht einbauen, weil ich da keine Zugang habe.
Das läßt sich doch sicher problemlos machen? Oder bin ich der einzige, der es gerne bequem hätte und keinen einfacheren Weg kennt, aus der Anmeldung direkt in ein anderes Projekt zu kommen. Gruß -- sarang♥사랑 09:38, 21. Dez. 2009 (CET)

Ende der Kopie --MannMaus 09:51, 21. Dez. 2009 (CET)

Wurde beantwortet. --MannMaus 11:18, 21. Dez. 2009 (CET)

Checkliste und Glossar für neue Autoren

Ich habe einen Vorschlag in Kombination von zwei Dingen.

  • Möchte hiermit anregen, für neue Autoren eine Checkliste zur Artikelerstellung verfügbar zu machen. Damit könnten sie die wichtigsten Punkte bei der Neuerstellung eines Artikels auf einem Blick erkennen. Sie müsste wie ein kleiner Ablaufplan gestaltet sein. Ich stelle mir dabei vor, daß dabei Links zu wichtigen WP:Seiten und einige Programmierhinweise eingearbeitet sind. Es sollte mM auch auf die erweiterte Werkzeugleiste hingewiesen werden.
Begründung: eine Checkliste regt zum systematischen Abarbeiten an und fördert die Eigenkontrolle am eigenen Werk. Sie erspart dem trotzdem sinnvollen Mentorenprogramm möglicherweise etwas Arbeit und fördert selbständiges Handeln.
  • Ein Glossar verbessert mM die Verständlichkeit von vielen WP-internen Begriffen für viele Änfänger. Inzwischen weiß ich, daß es Wikipedia:Glossar gibt. Obwohl ich bei meiner Anfangszeit danach fragte, hatte es mir keiner genannt. Ich schließe heute daraus, daß es nicht sehr bekannt zu sein scheint. Eingearbeitete Autoren brauchen es auch kaum. Man sollte WP:Glossar mit der Checkliste über einen Link verknüpfen.
Begründung: Personen, die vor ihrer WP-Arbeit nicht programmiert haben oder einschlägige HTML-Praxis hatten, tun sich mit zahlreichen Begriffen und notwendigen Tastaturhandgriffen sehr schwer. Solche Leute soll es tatsächlich geben :-).

Ganz praktisch fände ich, wenn man die Checkliste in Miniform (auf eigene Aktivierung hin) ständig im Bildfeld (z.B. rechter Bildrand) hätte und die Erweiterung mit den nützlichen Links bedarfsweise aus- und eingeklappt werden kann.

Ich habe hier schon mehrere Begrüßungsbausteine gesehen, manche finde ich exzellent gestaltet. Aus eigener Erfahrung muß ich aber sagen, daß mich die darin verlinkten Seiten durch ihre enorme Textmenge anfangs "erschlagen" haben und es kam hinzu, daß man sich als Neuling unter manchen Begriffen nichts vorstellen kann. Dadurch wird der eigentlich beabsichtigte Informationsprozeß wieder stark eingeschränkt. Viele Aussagen erscheinen verwirrend und man kann manche gute Hinweise von Anderen nicht ausreichend einordnen bzw. sinnvoll anwenden. Obwohl ich anfangs viel gelesen hatte, empfand ich es oft nicht als besonders hilfreich. Das lag weniger an den Textaussagen sondern an der empfundenen Unübersichtlichkeit. grüße --Lysippos 22:18, 28. Dez. 2009 (CET)

Gute Ideen, ein Glossar haben wir aber ja schon: Wikipedia:Glossar. Und diese Checkliste ist in der Planung, das Mentorenprogramm hat damit begonnen, freut sich aber natürlich, wenn andere Benutzer mitmachen. Du findest den Entwurf unter Benutzer:Carschten/Artikel-Zauberer. Grüße, -- XenonX3 - (☎:±) 22:23, 28. Dez. 2009 (CET)
Ups, das ging schnell. Danke für Deinen Hinweis. Werde dort mal vorbeischauen. Grüße --Lysippos 22:25, 28. Dez. 2009 (CET)
Hab's gesehen. Auch eine interessante Gestaltung und schon viel Mühe reingeflossen. So könnte ich mir unterlegte Erläuterungen vorstellen und man könnte es vielleicht miteinander verbinden. Was mir mit dem Vorschlag gedanklich vorschwebt ist eine Checkliste, die man beim geöffneten Editor parallel sieht (deshalb zwangsläufig mit Ausklappfunktion). Dadurch müsste man nicht hin und her switchen. Grüße --Lysippos 22:35, 28. Dez. 2009 (CET)

Syntaxfehler im Legendentext der Versionsgeschichte

Hi there,

ein bug für bugzilla ist es nicht, was ich zu berichten hätte, und eine bessere Meldungsseite als diese hier habe ich nicht gefunden. Jemand Zuständiges mit vielen Erlaubnissen könnte gelegentlich die entsprechende Schnipsel-Definition berichtigen, oder ein geneigter Leser es angemessen weiterleiten.

Auf der generierten Versionsgeschichte wird oben eine Legende angezeigt. Der XHTML-code hat offenbar einen Syntaxfehler: 

<div class="mw-history-legend">
<p>Alte Versionen des Artikels ... Hilfe</a>):
</p>
<ul><li> (Aktuell) =
</li><li> Uhrzeit und Datum =
</li><li> Um die Unterschiede zwischen ...
           ... und klicke auf ... vergleichen"</div>
</li></ul>
(Neueste | ...

Gemeint ist ganz offensichtlich, dass dieses </div< hinter dem </ul> stehen soll.

Den Bock habe allerdings nicht ich gefunden, sondern mein DOM-Parser, der an dieser Stelle aussteigt (illegal nesting).

Guten Rutsch --PerfektesChaos 15:02, 29. Dez. 2009 (CET)

Scheint wohl doch etwas für Bugzilla zu sein. Der Text kommt aus MediaWiki:Histlegend, dort ist das div aber nicht enthalten. Der php-Quelltext der HistoryPage (einfach nach 'histlegend' suchen) schaut auch sauber aus. Da wird der Parser wohl etwas falsch interpretieren. Aber warum versucht du die Versionsgeschichte mit einem DOM zu lesen? Vermutlich suchst du mw:API --80.143.63.127 19:09, 29. Dez. 2009 (CET)
Auf HistoryPage steht
wrapWikiMsg( "<div class='mw-history-legend'>\n$1</div>", 'histlegend' )
Ich hab noch nicht die Definition von wrapWikiMsg() gefunden, aber soviel verstanden, dass dies einen Wikisyntax-Quelltext in HTML umzuwandeln scheint. 'histlegend' ist der Identifizierer dieses Wikisyntax-Quelltextes im zuständigen MediaWiki, der an Stelle von $1 eingefügt werden soll. Dort befindet sich eine aus drei *-Zeilen bestehende Aufzählung. An die hängen wir erst </div> an und lassen danach den kombinierten Wikisyntax-Quelltext in HTML umwandeln. Dabei wird hinter unseren letzten *-Aufzählungspunkt das </li></ul> angehängt. Also müsste der PHP-code richtig lauten
"<div class='mw-history-legend'>\n" . wrapWikiMsg( "$1", 'histlegend' ) . "</div>"
und der Fall ist erledigt.
So, und wer hat jetzt Routine und ID unter bugzilla und macht das dort klar?
@mw:API: Danke schön fürs Mitdenken; hat man nicht immer – aber ich beabsichtige keine Abfrage, sondern komponiere über die Zwischenjahrestage ClicksDivertimento (zurzeit noch redlink, weil wegen des o.a. Problemchens volles Austesten noch nicht möglich; vielleicht mache ich noch dieses Jahr die Doku fertig) – ein JavaScript für die aktuelle Benutzer-Session.
--PerfektesChaos 22:57, 29. Dez. 2009 (CET)
... (cont'd) ... Der bugfix oben ist die philosophisch edlere Variante, die nachfolgende Programmierer an das Problem erinnert. In der Wirkung identisch für Schreibfaulere wäre das Einfügen eines weiteren Zeilenumbruchs hinter dem $1 (aus dem nämlichen Grund steht einer vor dem $1):
"<div class='mw-history-legend'>\n$1\n</div>"
Was mich auf die Idee eines work around auf deutschsprachiger Ebene brachte:
  • Könnte wohl jemand auf de/MediaWiki:Histlegend einmal kurz die Return-Taste drücken?
Wenn danach das XHTML valide ausgeliefert wird, ist die bislang von mir bloß vermutete Ursache auch zweifelsfrei nachgewiesen.
Gleichwohl sollte dann der o.a. bugfix auf dem Server vorgenommen werden: Es wird bei 300 Sprachversionen immer wieder die gleiche Situation auftreten, und das im Skript abzufangen ist wohl einfacher, als jedem griechischen und japanischen Text-Übersetzer klarzumachen, die Legendentexte immer mit einem für ihn gar nicht unmittelbar sichtbaren Zeilenumbruch zu beenden.
Als ich jetzt erstmalig durch den PHP-code blätterte, hatte ich das identische Konstrukt noch mehrfach gesehen, so z.B. bei mw-rc-label-legend und mw-specialpage-summary. Das bedürfte dann wohl einer allgemeinen Notiz im erlauchten Zirkel der Entwickler (vor denen ich größten Respekt habe), bei derartigen Mischkonstruktionen den wikitext immer vorsorglich in Zeilenumbrüche einzuschließen.
  • Vorerst aber: Wer hätte eine bugzilla-ID und meldet?
--PerfektesChaos 14:13, 30. Dez. 2009 (CET)
(BK) Das mit dem Zeilenumbruch wollte ich grade anmerken ;). Ein guter Ansprechpartner für die Änderung im Code wäre Raymond. Gruß --P.Copp 14:16, 30. Dez. 2009 (CET)
Ein zusätzliches \n vor dem schließenden div behebt das Problem in meiner lokalen MW-Installation. Den Fix könnte ich sofort, auch ohne Bugzilla, ins SVN einspielen. Nur ehrlich gesagt, verstehe ich es nicht. — Raymond Disk. 17:58, 30. Dez. 2009 (CET)
Danke für die schnelle Antwort.
@Verständnis: Oben schonmal länger ausgeführt, jetzt kurz und knapp: Das Problem ist, dass erst das div an den wikitext angehängt wird, also unmittelbar an den letzten *-Aufzählungspunkt (ohne Zeilenumbruch). Danach wird der gesamte legend-wikitext in HTML umgewandelt. Dabei hängt das div unmittelbar an diesem letzten Punkt, und hinter diesem letzten Punkt mitsamt div wird das </li></ul> angefügt.
--PerfektesChaos 18:15, 30. Dez. 2009 (CET)
Deine Analyse ist korrekt. Die Frage ist: Warum macht der Parser das? Innerhalb einer Artikelseite konnte ich das Verhalten nicht reproduzieren: Benutzer:Raymond/histlegend. Hingegen, wenn ich in OutputPage::wrapWikiMsg() Debuggingcode einbaue. Sobald das schließende div am Ende einer * oder # Zeile steht, gibt der Parser den Fehler aus. — Raymond Disk. 18:30, 30. Dez. 2009 (CET)
Der Parser baut jede Menge solcher Fehler ein. Der Grund, dass sie in Artikeln nicht sichtbar werden ist, dass Tidy sie ausbügelt. :) Gruß --P.Copp
Man sollte aber dann alle Stellen anschauen und entsprechend nacharbeiten, wo wrapWikiMsg genutzt wird, da es dort auch immer auftreten könnte. Der Parser arbeitet ja richtig, da das </div> in gleicher Zeile wie das Aufzählungszeichen steht, und es somit ein geschlossenden Absatz darstellt, der entsprechend geparst wird. HTMLtidy für Systemnachrichten wird die Performance sicher nicht hergeben. --80.143.67.191 20:17, 30. Dez. 2009 (CET)
Ohne auf die vorstehenden Beiträge geschmult zu haben, reiche ich ehrenhalber noch mein selbst erschuftetes Ergebnis auf Raymonds Frage von 18:30 nach: Weil in Article::getParserOptions() drinsteht setTidy( true ); und bei OutputPage::wrapWikiMsg() bzw. OutputPage::parse() nicht, so dass in Parser::parse() das if ( ( $wgUseTidy && $this->mOptions->mTidy ) || $wgAlwaysUseTidy ) nicht anspringt und die $tidyregs nicht befüllt werden.
Hat ein bissel gedauert bei mir, aber bei einem Code, den ich gestern Abend zum ersten Mal gesehen habe, war keine schnellere Antwort drin.
Ich entnehme der Disk, dass die Angelegenheit bei euch in besten Händen ist, war spannend und interessant, empfehle auch die Korrektur des Anwendungsbeispiels in wrapWikiMsg, darf mich an dieser Stelle ausklinken und einen Guten Rutsch wünschen. --PerfektesChaos 20:35, 30. Dez. 2009 (CET)
Einen habe ich doch noch:
In wrapWikiMsg im str_replace den '\n' anhängen an wfMsgExt(), und das ganze restliche PHP in Ruhe lassen? Stört das irgendwo?
Jetzt aber Schluss, das macht süchtig --PerfektesChaos 20:45, 30. Dez. 2009 (CET)
Klar macht das süchtig :) Deinen letzten Vorschlag werde ich nächstes Jahr (haha) ausprobieren. Nebenwirkungen sollte er eigentlich nicht haben. — Raymond Disk. 09:39, 31. Dez. 2009 (CET)

Kapitel- und Diskussionsgliederung

Um die Beziehung von Hauptartikel-Inhalten und zugehörigen Diskussionen zu verbessern, sollten nur Diskussionsbeiträge zugelassen (anderesfalls gelöscht) werden, die unter derselben Überschrift wie der Abschnitts eines Lemmas stehen, auf den sie sich beziehen. Dies würde dem neu eintretenden Diskutanten die Übersicht einschließlich Sichtung und Wichtung aller Argumente sehr erleichtern. Dabei sollte es sich vorrangig um die Abschnitts-Überschriften des Originalartikel (oder deren geänderte Versionen) oder um Überschriften neuer Einfügungen handeln, die aber in der Reihenfolge der Teilüberschriften stehen sollten. Manche Diskussionen verlaufen so chaotisch und gleichzeitig divergent und strittig, dass man es am Ende (nach Erfahrung unbegründeter Streichung eigener Beiträge) lieber unterlässt, zu einer Verbesserung des Textes beizutragen. Schade für WIKIPEDIA--Micha o.j. edob 21:04, 15. Dez. 2009 (CET)

Nach weiteren Erfahrungen mit WIKIPEDIA meine ich, dass mein Vorschlag sowohl durchführbar als auch für Diskutanten zumutbar wäre. --Micha o.j. edob 23:28, 5. Jan. 2010 (CET)

Langer Pre-Text

Ich glaube es wäre ganz praktisch wenn man der Common.css folgendes hinzufügen würde. 

pre {
    overflow: auto;
}

dann würde bei langem Text innerhalb des pre, der Text nicht aus der Seite und der Box herausfließen und der gesamten Seite einen horizontalen Scrollbalken verleihen. So wie in meinem Beispiel unten. 

das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla

Mit dem oben angebenen CSS-Einstellungen erscheint der Scrollbalken innerhalb der Box. Könnt ihr auch ausprobieren indem ihr das oben in eure monobook.css oder so einfügt.

--Finsterhell 17:53, 26. Dez. 2009 (CET)

Pro. Ich möchte den Vorschlag dringlichst unterstützen (Alarmstufe ROT), da ich dieses unvermeidliche horizontale Scrollen auch als äußerst ärgerlich empfinde. Anscheinend hat hier jemand bei der Gestaltung das pre-Element in HTML überhaupt nicht verstanden. Das sollte umgehend nachgebessert werden. -- pretobras 22:19, 2. Jan. 2010 (CET)
Pro. Ausgezeichnete idee. --helohe (talk) 21:11, 13. Jan. 2010 (CET)
Pro. --79.218.27.120 00:39, 12. Feb. 2010 (CET)
Pro. ...längst überfällig! --ulli purwin fragen? 20:21, 19. Feb. 2010 (CET)

Gute Idee, ich habe es umgesetzt, hoffen wir, dass es keine Nebeneffekte gibt. Könnte jemand die IEs durchtesten? Chrome, Opera10, Safari4, FF3.5.7 funktioniert. --Euku:⇄ 10:29, 18. Feb. 2010 (CET)

Beim Internet Explorer 6 gibt es jetzt bei Hilfe:Tabellen das Problem, dass neben dem horizontalen auch noch ein hässlicher vertikaler Scrollbalken entsteht. --Fomafix 10:38, 18. Feb. 2010 (CET)
Bei Seiten, die ein pre-Element mit viel Inhalt enthalten, wie MediaWiki:Common.css, ist overflow:auto störend. --Fomafix 10:50, 18. Feb. 2010 (CET)
Sollte man hier eine Ausname für diesen NR machen? Wo anders kommt soviel Text kaum vor. --Euku:⇄ 20:16, 19. Feb. 2010 (CET)
gerne. --Atlan Disk. 23:11, 27. Feb. 2010 (CET)
bitte. (oder geht das kürzer?) --Euku:⇄ 16:07, 1. Mär. 2010 (CET)
Kürzer wäre 
pre { overflow:auto } .ns-5 pre { overflow:visible }
Auch das Problem beim Internet Explorer 6 lässt sich wahrscheinlich lösen. Allerdings gefallen mir die Scrollbalken generell nicht. Beim Ausdrucken können Scrollbalken eh nicht funktionieren. Hier würde aber 
pre { white-space:pre-wrap; }
helfen. --Fomafix 16:36, 1. Mär. 2010 (CET)
das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
Auch bei den Benutzer-Scripts und -Styles (Benutzer:*/*.{css,js}) ist der Scrollbalken extrem störend. Auch hier gibt es ein Gegenmittel: 
.source-css, .source-javascript { overflow:visible }
Allerdings deutet die Anzahl der Probleme und der notwendigen Workarounds auf eine ungetestete CSS-Erweiterung. Besser die Definition wieder entfernen und bei Bedarf style="overflow:auto" im Wikicode verwenden. --Fomafix 20:30, 1. Mär. 2010 (CET)
quetsch dazwischen: s. dazu Wikipedia:Fragen zur Wikipedia#Seit unlängst eingefügte Bildlaufleisten bei überbreiten Inhalten, hängt wohl damit zusammen. -jkb- 20:34, 1. Mär. 2010 (CET)
Ja. --Fomafix 20:39, 1. Mär. 2010 (CET)
Damit der überlange Text in einer Zeile nicht aus der gestrichelten Box rausläuft kann beim Firefox übrigens die Box automatisch vergrößert werden: 
pre { min-width:-moz-min-content; }
--Fomafix 20:39, 1. Mär. 2010 (CET)
das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
Als weitere Alternative für den Firefox bietet sich das Addon Toggle Word Wrap an. --Fomafix 20:45, 1. Mär. 2010 (CET)
Im Moment habe ich bei großen, langen js und css-Seiten ein Riesenproblem, weil der horizontale Scrollbalken nicht sichtbar ist, sondern sich erst drei Bildschirmseiten weiter unten versteckt. Merlissimo 03:03, 2. Mär. 2010 (CET)
Dann also erst mal wieder raus aus den zentralen CSS-Definitionen. Zu solchen Problemen sollte erst mal alle Lösungsvarianten aufgezeigt werden und diese intensiv getestet werden, bevor solche Änderungen durchgeführt werden. --Fomafix 09:07, 2. Mär. 2010 (CET)

Im IE7/8 kommt es auch zu vertikalen Scrollbalken, womit man dann die letzten Milimeter der Box scrollen kann, sieht unschön aus. Sollte daher als unausgereift wieder entfernt werden. Der Umherirrende 21:33, 6. Mär. 2010 (CET)

Naja, gut, ist wieder raus. --Euku:⇄ 23:12, 11. Mär. 2010 (CET)
Also hat sich insgesamt nichts geändert? -- 79.218.27.193 23:59, 10. Apr. 2010 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Verbesserungsvorschläge/Archiv/2009/Dezember&oldid=208812658“