Wikipedia:Verbesserungsvorschläge/Archiv/2017/April

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Es ist wohl nur beim Firefox so, dass Abschnittslinks nicht treffen, wenn weiter oben im Artikel etwas eingeklappt ist. Wenn der Browser aber vorher mal den Artikel geladen hatte, treffen die Abschnittslinks doch, wenn man sie in einem neuen Tab öffnet. Wäre es möglich dem Browser die nötigen Informationen vorab zukommen zu lassen? Notfalls durch zweifaches zeitversetztes Aufrufen des Linkziels, wenn es ein Abschnittslink auf einen Artikel mit eingeklappten Inhalten ist, bei Firefox-Lesern? --Diwas (Diskussion) 19:37, 2. Apr. 2017 (CEST)

Nein.
Browser springen zu einer vertikalen Pixelzahl (Linie).
Die Pixelzahl, in der die Oberkante des Sprungziel-Element sichtbar ist, wird beim Fertigstellen des übermittelten Dokuments, und vielleicht zwischenzeitlich bis zu einem gewissen Zeitpunkt eingetroffener Veränderungen vom Browser festgestellt.
Auf diese vertikale Pixelzahl, vielleicht 547, merkt sich der Browser, dass er springen will.
Wenn zwischendurch obendrüber weitere dynamische Ereignisse passieren, springt er auf 547, auch wenn das inzwischen eine andere Stelle im Dokument ist.
Dass das bei einem zweitem Tab funktionieren mag, ist nur ein zeitlicher Zufall, eine sogenannte race condition. Das ist nicht reproduzierbar.
An welcher vertikalen Pixelzahl das Element landen wird, hängt von der Schriftart des Lesers und der Bildschirmbreite ab. Das ist nicht vorhersagbar und kann dem Browser nicht mitgegeben werden.
Das einzige, was geht, und wozu ich auch eine Programmierungsskizze als Phab-Task zu laufen habe, ist ausschließlich unser Klapp-Element mw-collapsible und nur dieses. Das müsste sich vor dem Einklappen die vertikale Position merken, und ob oberhalb der Sprung-Position sich etwas eingeklappt hätte. Dann und nur dann kann man nach dem Einklappen ein erneutes Springen-auf-Anker auslösen.
LG --PerfektesChaos 23:21, 25. Apr. 2017 (CEST)

Löschkandidaten mit Interwiki

Letzter Kommentar: vor 7 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt

Zurzeit haben wir hier einen Fall, bei dem in 15 Sprachversionen Artikel zum selben Thema angelegt wurden (vom selben Autor) und zumindest die meisten einen Löschantrag erhalten haben. Es gibt leider keine automatische Benachrichtigung oder übergreifende Projektseite für solche Fälle wie von Benutzer:W!B: in der verlinkten Disk bemängelt. Vielleicht bekommt jemand einen Bot beigebracht, auf die Diskussionsseiten zu posten "Der Interwiki-Artikel in der [Sprachversion]-Wikipedia wurde zum löschen vorgeschlagen" --DWI (Diskussion) 20:47, 25. Apr. 2017 (CEST)

Wir haben ja das tolle Wikidata; dem müsste eine Eigenschaft beigebogen werden „Seite ist in Wiki xxwiki nominiert für Löschung“; dann kann unser hiesiger Löschantrag das abfragen und im Löschantrag aufzählen, wo es weitere LA gibt. VG --PerfektesChaos 21:01, 25. Apr. 2017 (CEST)
Das müsste doch mittels der Badges möglich sein. --FriedhelmW (Diskussion) 21:45, 25. Apr. 2017 (CEST)
Ob die nun sonderlich dafür geeignet wären, weiß ich nicht, aber so nach dem Prinzip.
Ich glaube trotzfem nicht an die ganze Chose, denn dazu müssten auf Hunderten von Wikis diszipliniert Bots jeden reinkommenden LA auch auf Wikidata eintragen, und nach Erledigung (Abweisung) des LA den Vorgang brav wieder löschen. Das kann aber nur eine Handvoll großer Wikis. Ohne aktuelle automatische Registrierung hat dieser eher seltene Fall aber überhaupt keine Aussichten. Das gilt auch für jeden Mechanismus, egal ob mittels Wikidata oder anders gelöst. Im Übrigen ist die Löschprozedur nicht Software-gestützt und nicht WMF-weit standardisiert und kann auf jedem Wiki anders organisiert sein. Dass wir daran bereits Bots beteiligen ist unsere Privatangelegenheit.
VG --PerfektesChaos 23:43, 25. Apr. 2017 (CEST)
zumindest würde es reichen, unter den sprachversionen einzutragen, auf welchem wiki er wegen löschen "gesperrt" ist: das würde alle unbedachten neuanlagen (also wiedergänger, auch unter anderem namen) unterbinden, und wenn sich die häufen, spricht das für ein prinzipielles problem. dazu müsste es einfach möglich sein, dass der sprachversionen-block auch rotlinks frisst – was auch sonst nicht patschert wäre, weil man (etwa laut lokaler NK) angesetzte lemmata ebenfalls vorab eintragen könnte, wie in unseren BKS: mir würde es reichen, wenn wikidata halt nachfrägt, ob ich den rotlink wirklich eintragen will, und vielleicht einen kommentar ermöglicht (hinweis auf löschung, oder BKS, usw) --W!B: (Diskussion) 08:34, 27. Apr. 2017 (CEST)

Facebook als Quelle?

Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo, ich habe gerade als Quelle einen Facebook-Kommentar entdeckt. Der ist aber nicht mehr im Netz verfügbar. Ich finde so was als Quelle unsinnig. Das ist nicht seriös. Außerdem war die Quelle in Klammern versteckt und nicht gleich erkennbar: [1] Gibt es eine Möglichkeit, das zu unterbinden? Schöne Grüße von --Hannover86 (Diskussion) 12:43, 28. Apr. 2017 (CEST)

Man könnte höchstens facebook generell auf die URL-Blacklist setzen, aber viele Links sind durchaus sinnvoll. Bleibt also nur gesunder Menschenverstand. --mfb (Diskussion) 15:21, 5. Mai 2017 (CEST)

Warnung bei fehlendem schließendem HTML-Kommentartag

Letzter Kommentar: vor 7 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt

Es ist wiederholt vorgekommen, dass Benutzer HTML-Kommentare in den Quelltext gesetzt haben und dabei das schließende Tag nicht oder nicht richtig gesetzt haben. Die Folge ist, dass der nachfolgende Inhalt bis zum Seitenende nicht mehr erscheint. Das Problem ist gravierend, fällt aber kaum auf. Bei diesem Auftreten [2] sind beispielsweise ganze 12 Abschnitte der Auskunft unsichtbar gemacht worden.

Ich halte es für einfach, beim Speichern einer Bearbeitung, bei der der Fehler gemacht wird, mindestens zu warnen oder besser die Speicherung gar nicht zuzulassen; ein fehlendes schließendes HTML-Tag ist schließlich überhaupt nicht zulässig. --BlackEyedLion (Diskussion) 13:21, 11. Apr. 2017 (CEST)

So etwas machen wir grundsätzlich nicht: Das Abspeichern eines neuen Textes zu verweigern, weil es damit irgendein Syntaxproblem geben würde.
  • Der betroffene Benutzer weiß in der Regel überhaupt nicht, warum es dazu kam.
  • Niemand versteht diese dämlichen Meldungen und Erklärungen.
  • Niemand begreift, an welcher Stelle man jetzt wonach suchen müsste und jetzt genau was zu reparieren wäre, damit das Speichern klappt.
Die Benutzer geben auf, schmeißen eine Viertelstunde Bearbeitung weg und verfluchen dieses dämliche Wiki und kommen nie wieder.
Wir speichern auch kaputte Syntax erstmal ab; dann können sich Fähigere hinterher um die Reparatur kümmern.
Nur bei mutmaßlich böswilligen Edits wie etwa Linkspam blockieren wir das Speichern.
Wer in der Auskunft was fragt, ist mutmaßlich kein Experte in Wikisyntax, sondern stellt oft zum ersten Mal im Leben eine Frage in dieser mysteriösen Wikisyntax statt einem normalen Dialogformular wie sonst überall.
VG --PerfektesChaos 23:34, 25. Apr. 2017 (CEST)
Widerspruch: Wenn ich nach einem <ref> kein </ref> setze, kommt ja auch ne Warnung. Das ließe sich auf weitere Tags erweitern. --Hannover86 (Diskussion) 12:47, 28. Apr. 2017 (CEST)
Wann können Syntaxfehler sonst auftreten, außer wenn jemand HTML-Tags verwendet? Zum Beispiel in der Auskunft trägt zum Problem bei, dass die HTML-Kommentar-Tags bereits in der Abschnittsvorlage beim Hinzufügen eines neuen Abschnitts stehen. Ein nicht-HTML-kundiger Benutzer wird so genötigt, diese HTML-Tags ohne Verständnis dafür zu verwenden. Ich halte es deshalb für geboten, die HTML-Tags aus der Vorlage zu entfernen. Außer bei diesen Abschnittsvorlagen können HTML-Tags nur vorkommen, wenn der Benutzer sie selbst eingibt; solche Benutzer werden verstehen, auf welchen Fehler sie hingewiesen werden.
Die Wiki-Syntax ist in dieser Hinsicht wesentlich robuster. Beispielsweise werden öffnende eckige Klammern [[ ohne zugehörige schließende Klammern gar nicht als Operator erkannt.
Eine Notlösung wäre, bei fehlendem schließendem Tag (nicht nur für Kommentare, zum Beispiel auch bei small) das schließende Tag am Ende der Bearbeitung automatisch einzufügen. So würde wenigstens nicht noch nachfolgender Text zerstört werden. Eine andere Lösung wäre, alleinstehende öffnende Tags als Text statt als Operator zu parsen.
Ich möchte noch einmal betonen, dass ich das beschriebene Problem für gravierend halte. Wie oben beschrieben können damit beliebig lange Textpassagen versehentlich unsichtbar gemacht werden, ohne dass es irgendjemandem auffallen müsste. Wenn es niemandem auffällt, der den Fehler beheben kann, ist der unsichtbare Text de facto zerstört. --BlackEyedLion (Diskussion) 12:58, 28. Apr. 2017 (CEST)
  • Der Anfragesteller hat leider nicht verlinkt, was mit der behaupteten „Vorlage“ gemeint sein soll, die in der Auskunft angeblich verwendet würde.
    • Um eine Vorlage im Sinne der Wikisyntax (Hilfe:Vorlagen) scheint es sich nicht zu handeln.
    • Vielleicht war Wikipedia:Auskunft/Intro/preload gemeint. Dies ist allerdings keine „Vorlage“.
    • Das ist natürlich ganz oberschlau, den wikifremden Fragestellern darin bereits einen HTML-Kommentar anzubieten. Hier muss nur jemand irrtümlich das schließende > irgendwie wegklicken oder ein Leerzeichen davor einfügen, und die Auskunft hat sich selbst den geöffneten unabgeschlossenen HTML-Kommentar geschaffen, den sie nunmehr bejammert.
    • Tipp: Statt HTML-Kommentar Vorlagentechnik zum Unsichtbarmachen verwenden. Da kann man zwar auch Syntaxmurks produzieren, aber eine lose geschweifte Klammer richtet erheblich geringere Kollateralschäden an, und macht nur örtlich eine Zeile sichtbar. Kryptischer als ein HTML-Kommentar ist etwas wie {{NULL|Blabla}} auch nicht.
      • Insbesondere: eine parameterlose Unterseiteneinbindung, deren Name die Botschaft ist, und die NULL produziert.
      • Beispiel: {{/!!! Lass die nachfolgende Zeile am ENDE deiner Frage stehen. Sie wird in deine Signatur umgewandelt. !!!}}
  • Wenn man es obendrein fertigbringt, jedem externen Fragesteller in der Auskunft unausgeblendete Expertenlinks zum Verändern der Konfiguration von Editnotice, Editintro, Preload anzubieten, dann darf man sich über Syntaxbruch und Irreleitung der Anfragenden nicht wundern. Auf einer Seite mit Publikumsverkehr wird sowas mindestens ausgeblendet, besser überhaupt nicht angeboten, sondern ist nur Insidern zugänglich.
VG --PerfektesChaos 22:47, 7. Jun. 2017 (CEST)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Verbesserungsvorschläge/Archiv/2017/April&oldid=169132325“