Wikipedia:Umfragen/Technische Wünsche 2015/Artikel

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Bitte nicht mehr abstimmen!

Diese Umfrage ist zeitlich beschränkt: vom 19. September 2015 bis zum 19. Oktober 2015. Die Umfrage startete mit einer Live-Veranstaltung am Samstag, den 19. September 2015 auf der WikiCon 2015 und geht im Anschluss in der Wikipedia weiter.

  • Phase 1: Wünsche sammeln bis zum 5. Oktober 2015
  • Phase 1.5: Sichtung und Strukturierung durch Wikimedia Deutschland bis zum 12. Oktober 2015 – Krankheitsbedingte Verzögerung, wir bitten um Verständnis. -- Daniel Kinzler (WMDE) (Diskussion) 19:54, 5. Okt. 2015 (CEST)
  • Phase 2: Wünsche priorisieren/bewerten durch Pro und Unterschrift bis zum 19. Oktober 2015 vom 13. Oktober bis zum 26. Oktober 2015.
  • Phase 3: Sichtung und erste Abschätzung der Topwünsche durch Wikimedia Deutschland ab dem 28. Oktober 2015
  • Phase 4: Vorstellung der Auswertung und Rückfragen zu den Wünschen auf der Topliste ab Mitte November 2015
  • Phase 5: Bearbeitung der Topwünsche durch Wikimedia Deutschland ab Januar 2016

Problemstellung[Quelltext bearbeiten]

Konzept „Technische Wünsche“

Vor genau zwei Jahren hatte der Autor dieser Umfrage (Raymond) zum ersten Mal die Community gefragt: Was für technische Wünsche habt ihr? Wo klemmt es, was wird dringend an technischer Unterstützung benötigt? Der Hintergrund war damals Widerstand „der Community“ gegen „von oben“ verordnete neue Features, weil manches im Betastadium als Standard aktiviert oder einfach als unnötig erachtet wird.

In den vergangenen zwei Jahren hat sich vieles getan. Aus der Top-20-Wunschliste wurden folgende Wünsche erfüllt:

  • Warnhinweis oder automatisches Einfügen von fehlendem <references />-Tag
  • Wikisyntax, um Permalinks und Difflinks als Wikilink angeben zu können
  • Verbesserung der Verschlüsselung von https-Verbindungen mittels Perfect Forward Secrecy
  • eine Spezialseite, die die von einem Benutzer neu angelegten Seiten ausgibt
  • Möglichkeit zur Suche im Quelltext
  • Tabellen in einer Form bearbeiten können, wie man es seit einigen Jahrzehnten aus Office-Programmen kennt

In den Zielgerade befinden sich die Wünsche:

  • „CatScan-Funktionalität“ in die Software integrieren
  • Möglichkeit, eine Kategorie auf neue Artikel hin zu beobachten

An der Realisierung weiterer Wünsche wird aktuell gearbeitet.

Mein (Raymonds) Dank geht dafür an die Softwareabteilung von Wikimedia Deutschland, die seit zwei Jahren sowohl unsere Wünsche, so gut es geht, realisiert, aber auch das Konzept der technischen Wünsche nach San Francisco transportiert hat. Im August 2015 wurde bei der WMF das WMF Community Tech team gegründet, das auf internationaler Ebene die technischen Wünsche der Autoren sammeln und realisieren will (Projektseite).

Ziel[Quelltext bearbeiten]

Ziel dieser Umfrage soll eine (priorisierte!) Liste von technischen Wünschen sein. Die Topwünsche werden vom Bereich Software-Entwicklung bei Wikimedia Deutschland gesichtet und angegangen. WMF-Entwicklungsteams, andere Chapter und freiwillige Entwicklerinnen und Entwickler sind herzlich eingeladen, sich an der Umsetzung einzelner Wünsche zu beteiligen.

Was und für wen?[Quelltext bearbeiten]

Ausdrücklich erwünscht sind hier auch die Wünsche aller Schwesterprojekte. Falls ein Wunsch sehr projektspezifisch ist, bitte mit dem Projektnamen kennzeichnen. Hier können genannt werden (bitte jeweils mit kurzer(!) Erklärung, für welchen Autorenkreis der Bug / das Feature von Bedeutung ist):

  • offene Bugs/Featurewünsche im Phabricator (ehemals Bugzilla).
  • Tools vom ToolLabs, die in MediaWiki integriert werden sollten, damit Abhängigkeiten von externen Servern gelöst werden
  • Gadgets/Helferlein/Tools, die aktuell defekt sind oder dringend modernisiert werden müssen
  • frei formulierte Wünsche

Das Team von Wikimedia Deutschland wird während des Sammelns von Wünschen für Rückfragen und Formulierungshilfen zur Verfügung stehen.


Abstimmung[Quelltext bearbeiten]

Artikelanzeige[Quelltext bearbeiten]

Sortierung mehrerer Spalten in Tabellen[Quelltext bearbeiten]

Beschreibung

In Tabellen soll die Sortierung der Spalten nach mehr als einem Kriterium ermöglicht werden.

Diskussion
  • Mehrfache Sortierung für die selbe Spalte in der Tabelle. Bspw. würde ich gerne in der Liste der Mitglieder in der Pro Football Hall of Fame neben der Sortierung nach Namen auch die Sortierung nach der Hintergrundfarbe haben, ohne auf das andere verzichten zu müssen.--JTCEPB (Diskussion) 21:31, 18. Sep. 2015 (CEST)
    • Kannst du das genauer erklären? Meinst du eine Sekundäre Sortierung? -- Michi 15:13, 21. Sep. 2015 (CEST)
Gibts doch schon!? Einfach nacheinander auf die Spalten klicken. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 10:16, 14. Okt. 2015 (CEST)
Nein, für jede Spalte kann man nur einen Sortierwert angeben.--JTCEPB (Diskussion) 22:31, 15. Okt. 2015 (CEST)
Workaround --Herzi Pinki (Diskussion) 01:22, 16. Okt. 2015 (CEST)
Unterstützung
  1. Pro ireas (Diskussion) 00:31, 13. Okt. 2015 (CEST)
  2. Pro --Orci Disk 13:08, 13. Okt. 2015 (CEST)
  3. Pro -- ɦeph 21:37, 13. Okt. 2015 (CEST)
  4. Pro --Geolina mente et malleo 21:39, 13. Okt. 2015 (CEST)
  5. Pro -- Achim Raschka (Diskussion) 22:48, 13. Okt. 2015 (CEST)
  6. Pro --Cirdan ± 01:08, 14. Okt. 2015 (CEST)
  7. Pro --Toru10 (DiskussionWPCS) 10:00, 14. Okt. 2015 (CEST)
  8. Pro -- hgzh 15:05, 16. Okt. 2015 (CEST)
  9. Pro --Aineias © 20:42, 17. Okt. 2015 (CEST)
  10. Pro --DVvD |D̲̅| 09:38, 19. Okt. 2015 (CEST)
  11. Pro -- Generator (Diskussion) 14:35, 19. Okt. 2015 (CEST)
  12. Pro --Pelz (Diskussion) 21:39, 22. Okt. 2015 (CEST)
  13. -- Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  14. Pro --Frank C. Müller (Diskussion) 15:41, 23. Okt. 2015 (CEST)
  15. Pro --  TRN 3.svg hugarheimur 19:36, 23. Okt. 2015 (CEST)
  16. ProDerHexer (Disk.Bew.) 20:43, 23. Okt. 2015 (CEST)
  17. Pro --BHC 🐈 (Disk.) 23:23, 23. Okt. 2015 (CEST)
  18. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  19. Pro --Chewbacca2205 (D) 22:07, 24. Okt. 2015 (CEST)

Bessere Bedienbarkeit von Tabellen im WikiEditor[Quelltext bearbeiten]

Beschreibung

Bessere Bedienbarkeit von Tabellen nicht nur im VisualEditor, sondern auch im WikiEditor.

Diskussion
  • Die Bearbeitung von Tabellen soll vereinfacht werden. Einzelne Zeilen und Spalten sollen mit wenigen Handgriffen gelöscht, hinzugefügt, in ihrer Reihenfolge verändert oder kopiert werden können. --217.227.71.63 06:36, 20. Sep. 2015 (CEST)
Unterstützung
  1. Pro --Morten Haan 🐝 Wikipedia ist für Leser da 22:58, 13. Okt. 2015 (CEST)
  2. Pro Der wikieditor ist der ganz normale Editor? Dann ja. Sonst ist es mir wurscht. -- Generator (Diskussion) 14:36, 19. Okt. 2015 (CEST)
  3. Pro --DerPetzi (Diskussion) 12:30, 22. Okt. 2015 (CEST)
  4. Pro -<)kmk(>- (Diskussion) 04:24, 23. Okt. 2015 (CEST)
  5. Pro --Furfur Diskussion 21:08, 24. Okt. 2015 (CEST)
  6. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:16, 26. Okt. 2015 (CET)

Identische Formatierung mehrerer Zeilen oder Spalten vereinfachen[Quelltext bearbeiten]

Beschreibung

Sollten mehrere Zeilen oder Spalten identisch formatiert werden, soll dies durch einen einmaligen Befehl realisiert werden.

Diskussion
  • Es sollte möglich sein, die Ausrichtung und weitere Stilangaben für eine Tabellenspalte einfach festzulegen, ohne für jede Zelle der Spalte die Angabe einzeln einzufügen. Ich könnte mir ein neues Attribut colstyle vorstellen, dessen Inhalt der Parser dann als Stilangabe für alle Zellen in der entsprechenden Spalte interpretiert und im HTML-Code einfügt. --Schnark 09:23, 24. Sep. 2015 (CEST)
Unterstützung
  1. Pro ireas (Diskussion) 00:31, 13. Okt. 2015 (CEST)
  2. Pro Gute Idee. Yellowcard (D.) 21:37, 13. Okt. 2015 (CEST)
  3. Pro -- ɦeph 21:37, 13. Okt. 2015 (CEST)
  4. Pro --K@rl 14:22, 14. Okt. 2015 (CEST)
  5. Pro --MGChecker – (📞| 📝| Bewertung) 15:32, 14. Okt. 2015 (CEST)
  6. Pro hätte ich letztens sehr gut gebrauchen können – Giftpflanze 17:24, 14. Okt. 2015 (CEST)
  7. Pro --Rainald62 (Diskussion) 23:29, 15. Okt. 2015 (CEST)
  8. Pro --Dogbert66 (Diskussion) 20:06, 16. Okt. 2015 (CEST)
  9. Pro --Daniel749 Disk. (STWPST) 12:51, 17. Okt. 2015 (CEST)
  10. Pro --DVvD |D̲̅| 09:40, 19. Okt. 2015 (CEST)
  11. Pro --Morten Haan 🎃 Wikipedia ist für Leser da 23:30, 19. Okt. 2015 (CEST)
  12. Pro --DerPetzi (Diskussion) 12:31, 22. Okt. 2015 (CEST)
  13. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  14. Pro --Frank C. Müller (Diskussion) 15:46, 23. Okt. 2015 (CEST)
  15. ProDerHexer (Disk.Bew.) 20:43, 23. Okt. 2015 (CEST)
  16. Pro --Schnark 09:15, 24. Okt. 2015 (CEST)
  17. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  18. Pro --Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  19. Pro --Chewbacca2205 (D) 22:08, 24. Okt. 2015 (CEST)
  20. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:16, 26. Okt. 2015 (CET)
  21. Pro -- Freddy2001 DISK 15:07, 26. Okt. 2015 (CET)
  22. Pro --Euku: 19:31, 26. Okt. 2015 (CET)
  23. Pro Formatierung und Daten trennen, mit CSS: th:nth-child() --MatthiasDD (Diskussion) 16:21, 27. Okt. 2019 (CET)

Direkte Links zu Schwesterprojektseiten in Navigationsleiste übernehmen[Quelltext bearbeiten]

Beschreibung

Direkte Links zu Seiten in den Schwesterprojekten wie bspw. zu Wiktionary-Einträgen oder Wikimedia-Commons-Kategorien sollen in die Navigationsleiste integriert werden, dieses Beta-Feature somit erweitert und freigeschaltet werden.

Diskussion
  • Umstellung der Verlinkung auf andere Wikimedia-Projekte (in erster Linie Commons-Kategorien) auf Darstellung in der interwiki-Link-Spalte. Es handelt sich um Links, die ohne Rücksicht auf den Inhalt nahezu standardmäßig (wenn auch ohne expliziten Konsens) eingefügt werden. Solche Links sind interwiki-Links gleichrangig und bei ihnen besser aufgehoben. Das ist technisch bisher nicht möglich. Die an sich denkbare und vielleicht auch wünschenswerte Einbindung über Wikidata könnte die Sache verkomplizieren und bräuchte einen internationalen Konsens. Daher erst mal nur lokal umzusetzen. MBxd1 (Diskussion) 11:31, 19. Sep. 2015 (CEST)
    • Ist technisch über Wikidata bereits möglich, würde aber einen Community-Konsens benötigen. -- Michi 15:25, 21. Sep. 2015 (CEST)
      • Der Weg über einen internationalen Konsens wäre zu umständlich. Aus lokalem Interesse dort was abzuladen, was dann nur lokal genutzt wird, wäre wohl nicht akzeptabel. Daher sollte die Möglichkeit der direkten Einbindung wie bei den früheren interwiki-Links geschaffen werden. Die technische Möglichkeit ist Voraussetzung für einen Konsens zur dezenteren Einbindung. MBxd1 (Diskussion) 20:57, 21. Sep. 2015 (CEST)
        • Die Commons-Seiten/Kats werden bereits jetzt (auch) auf Wikidata gespeichert. Und die Software um diese Daten hier unter den Interwikilinks anzuzeigen, hat das Wikidata-Team auch schon geschrieben, wurde nur wegen mangelnder Community-Unterstützung nicht aktiviert. Es brauch also keinen internationalen Konsens sondern nur einen lokalen und nur geringe Entwicklungsarbeit (welche meiner Meinung nach erst geschehen sollte wenn/falls die de-Wiki-Community dieser Änderung zustimmt). -- Michi 23:27, 21. Sep. 2015 (CEST)
          • Die Beta-Funktion „Seitenleiste anderer Projekte“ leistet das im Prinzip bereits. --Schnark 09:37, 22. Sep. 2015 (CEST)
            • Ist Wikidata denn hinsichtlich der Commons-Kategorien zuverlässig komplett? Wo kommt die Einfügung her? Gibt es vielleicht schon eine Wikipedia, die das nutzt? Es war mir dort noch nicht aufgefallen, war wohl auch nicht von Anfang an drin. Da nie ein Konsens zur Einfügung der Commons-Werbelinks abgefragt wurde und die Commons-Links die Anforderungen an externe Links in aller Regel nicht erfüllen, sehe ich eigentlich schon eine recht klare Begründung für die Umstellung. Jedenfalls müssen die technischen Voraussetzungen da sein, bevor abgestimmt wird; unklare technische Voraussetzungen verringern die Zustimmung erfahrungsgemäß ganz erheblich. Wobei allerdings noch die Frage wäre, ob überhaupt eine Abstimmung nötig ist - zur Einfügung der Links gab es ja auch keine. MBxd1 (Diskussion) 19:44, 22. Sep. 2015 (CEST)
              • Komplett bestimmt nicht. Genommen wird das, was ganz unten neben den Links zu anderen Sprachen steht (Beispiel), was sowohl eine Galerie-Seite als auch eine Kategorie sein kann. --Schnark 09:27, 23. Sep. 2015 (CEST)
Unterstützung
  1. Pro --Arnd (Diskussion) 17:07, 14. Okt. 2015 (CEST)

Markierung exzellenter und lesenswerter Artikel[Quelltext bearbeiten]

Beschreibung

Reparatur des Werkzeuges zur Markierung von exzellenten und lesenswerten Artikeln.

Diskussion
@NaturalBornKieler: Diese Änderung von PerfektesChaos war nicht ausreichend? —Martin (WMDE) (Disk.) 17:17, 9. Okt. 2015 (CEST)
Nein, das JS-Helferlein war zuvor schon deaktiviert worden, ohne dass ich das mitbekam; jetzt bkl-check@Schnark, siehe Helferlein für die AdT-Suche. Mit solchen Problemen aber vorher in die WP:TWS kommen und nicht erst auf eine Umfrage warten. Das BKL-Helferlein funktioniert auf Schmalspur (CSS) weiterhin. --PerfektesChaos 22:47, 13. Okt. 2015 (CEST)
Unterstützung
  1. Pro --NaturalBornKieler (Diskussion) 00:25, 14. Okt. 2015 (CEST)

Hovercards auch für Leserinnen und Leser[Quelltext bearbeiten]

Beschreibung

Hovercards sollen auch für nicht angemeldete Benutzerinnen und Benutzer angeschaltet werden.

Diskussion
  • Hovercarrds auch für nicht angemeldete Benutzer. --Bellini 15:29, 19. Sep. 2015 (CEST)
    • Sollen die Hovercards für nicht angemeldete Benutzer standardmäßig aktiviert werden? Das ist technisch "trivial", braucht aber einen Community-Konsens aka Meinungsbild. Oder sollen sie durch IPs aktivierbar sein? -- Michi 15:25, 21. Sep. 2015 (CEST)
      • Standardmäßig wäre mein Wunsch, aber warum brauchen wir daür ein Meinungsbild? Grüße, --Bellini 05:25, 23. Sep. 2015 (CEST)
        • Weil es möglicherweise Leute gibt, die keine Hovercards mögen und sie störend und nicht hilfreich finden? Und es geht nicht darum, dass man selbst das nicht will – man könnte es ja deaktivieren – man will es den unangemedeten Benutzern nicht zumuten. --MGChecker – (📞| 📝| Bewertung) 17:34, 24. Sep. 2015 (CEST)
Unterstützung
  1. Kontra No way. ich hasse die Dinger. Braucht kein Mensch. -- Generator (Diskussion) 14:38, 19. Okt. 2015 (CEST)
  2. Neutral Muss nicht unbedingt sein, zum einen fände ich es lästig, wenn bei jedem Link (auch wenn man nur versehentlich drauf geht) auf einmal so ein Kasten aufplopt, und zum anderen setzt das ja voraus, dass man eine Maus o.ä verwendet. Bei Touch-screens würde das sowieso nicht funktionieren. --Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  3. Kontra Den IP sowas nicht aufzwingen, die können dem nicht entkommen. Wer sich sowas aktiv auswählt, möge damit glücklich werden. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)

Erweiterte Informationen zu Interwikilinks[Quelltext bearbeiten]

Beschreibung

Bei den Interwikilinks soll bspw. per Drüberfahren der Maus nicht nur der Exzellent-/Lesenswertstatus, sondern auch weitere Informationen wie Artikelgröße oder Anzahl der Einzelnachweise angegeben.

Diskussion
  • Anzeige der Artikelgröße der Interwikis, entweder in Worten, Zeichen oder Bytes (oder auch Anzahl der Einzelnachweise), würde die Suche nach erfolgversprechenden umfangreicheren Quellen für den hiesigen Artikel erleichtern, Auszeichnungen für Exzellente und Lesenswerte sind oft nur ein rudimentärer Hinweis (ein Zeichen halt, wie lang oder bequellt der Artikel ist, geht daraus nicht hervor), Anzeige sollte für Benutzer steuerbar sein und/oder ggf. per Mouseover erfolgen. Datenhaltung in Wikidata wäre vllt. möglich, --MachtaUnix (Diskussion) 01:55, 23. Sep. 2015 (CEST)
    Standardmäßig in jedem betrachteten Artikel jederzeit diese Infos mitzuliefern, würde alle etwas ausbremsen. Aber vielleicht findet sich ein Skriptbastler, der auf Extraklick hin alle diese Infos einsammelt. Wobei die Zahl der Bytes noch trivial ist, Anzahl der Abschnitte und refs schon mühsamer und antwortzeitaufwendiger. Vielleicht global bei Wikidata zu betreuen, von wo aus es jedesWiki nutzen kann. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
    Ein einfacher Anfang mit der Zahl der Bytes wäre schon besser als nix, Anzahl der Einzelnachweise (als Indiz für die Stichhaltigkeit eines Textes) halte ich auch für machbar, falls nicht online verfügbar, könnte man die Information auch in seltener (wöchentlich ?) aktualierten Tabellen halten. Bei Online-Generierung dürfte sich die Last reduzieren, wenn die Anzeige benutzerabhängig wäre. --MachtaUnix (Diskussion) 23:08, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro wäre auf jeden fall ne Idee. --Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  2. Pro --MachtaUnix (Diskussion) 23:08, 25. Okt. 2015 (CET)

Weblinks mit Klammern korrekt darstellen[Quelltext bearbeiten]

Beschreibung

Weblinks mit Klammern sollen, bspw. mittels automatischer Encodierung, korrekt dargestellt werden.

Diskussion
  • Links wie [http://test.xyz?test[a]=s] korrekt darstellen. -- hgzh 14:46, 19. Sep. 2015 (CEST)
    • Das wird nicht möglich sein, das eine URL ja auch eine eckige Klammer öffnen kann, ohne sie wieder zu schließen. --MGChecker – (📞| 📝| Bewertung) 17:13, 24. Sep. 2015 (CEST)
      • Man könnte aber durchaus ein Skript entwickeln, das erkennt, wenn Links eingefügt wurden, bei denen zwischen den Klammern nochmal [ und/oder ] auftauchen. Dann sollte eine Box erscheinen, die anbietet, den Link automatisch richtig zu enkodieren (inklusive Testlink zum Überprüfen, dass es geklappt hat) oder zum Bearbeitungsmodus zurückzukehren und den Syntaxfehler zu beheben. Denn korrekt (im Sinne des MediaWiki-Parsers) können solche Links niemals sein.--Cirdan ± 18:53, 27. Sep. 2015 (CEST)
        Das wurde auch im Zusammenhang mit Bearbeitungsfiltern bereits vielfach erörtert; regelmäßiges Ergebnis: Nicht wünschenswert. Grund: Benutzer, die das mit den eckigen Klammern und ggf. weiterer problematischer Zeichen nicht wissen, sind oft neu und wissen mit den Erläuterungen, Warnungen oder gar automatisierten Korrekturen nichts anzufangen. Wer sich noch nie in Ruhe mit URL-Encoding beschäftigt hatte, ist von solchen Texten schlicht überfordert. Ergebnis: Man traut sich nicht, die Bearbeitung abzuspeichern; sie geht verloren. Deshalb: Mutmaßlich falsche Syntax akzeptieren, Text abspeichern; anschließend durch Routiniers nacharbeiten. --PerfektesChaos 11:44, 4. Okt. 2015 (CEST)
        • Das halte ich für nicht zutreffend, es ist alles eine Frage der Benutzerführung. Wenn ich auf "Speichern" klicke und dann ein Pop-Up erscheint das sagt „Wir haben aus technischen Gründen eine automatische Linkanpassung durchgeführt. Überprüfe bitte, dass die folgenden Links richtig funktionieren: http://... Falls du mehr über die Hintergründe erfahren möchtest: Hilfeseite“ ist das überhaupt nicht verwirrend und hält auch niemandem vom Speichern ab. Das Pop-Up hat zwei Knöpfe: Alles in Ordnung und Mindestens ein Link funktioniert nicht, der zweite macht die Anpassung rückgängig, speichert trotzdem und trägt eine Wartungskategorie ein. Wenn man der automatischen Anpassung vertraut, könnte man auch einfach nur im Hintergrund den enkodierten Link anfragen und schauen, ob ein 404 zurückkommt oder nicht. Das wäre generell auch hilfreich, wenn beim Speichern im Hintergrund alle neuen Links gecheckt würden.--Cirdan ± 12:27, 9. Okt. 2015 (CEST)
    • Wieso nicht? Ein Link (wird am Protokoll erkannt), nicht von eckigen Klammern umschlossen, ist bis zum nächsten Leerzeichen gültig. Was dazwischen steht, ist eigentlich egal. Ein Link, der von eckigen Klammern umschlossen ist, ist natürlich etwas schwieriger, könnte aber noch richtig dargestellt werden, solange die Anzahl der öffnenden und schließenden eckigen Klammern vom Linkbeginn (Protokoll) bis zum Auftreten des ersten Leerzeichens danach gleich ist. Der Umschluss mit eckigen Klammern dient bei diesen externen Links ja nur der Kennzeichnung eines Linktextes, nicht dem Link an sich. -- hgzh 23:20, 5. Okt. 2015 (CEST)
    Das ist eben nicht so trivial. Ich mache genau sowas mit WSTM seit fünf Jahren, und musste einiges an Lehrgeld bezahlen. Es setzt schonmal voraus, dass alle sonstigen Klammern perfekt gesetzt sind, ansonsten gibt es ein Gemetzel. Und innerhalb von nowiki, syntaxhighlight oder Kommentaren usw. will man auch keine Veränderung. Und wenn URL als Vorlagenparameter auftreten, womöglich an Lua oder ein Webarchiv übergeben werden, will man auch keine Änderung. Und URL enden mitnichten am nächsten Leerzeichen, sondern auch an Tags oder doppeltem Apostroph; es würden auch noch Satzzeichen hinzugehören, was hier keine Rolle spielt. Alles unter der Voraussetzung ansonsten perfekter Syntax; wurde eine Klammer vergessen oder ist zuviel, vandaliert der Automatismus. WSTM weiß all dies und korrigiert zweifelsfreie Fälle automatisch, gibt jedoch immer eine Warnmeldung aus zwecks menschlicher Kontrolle durch die bereits fortgeschrittenen WSTM-Anwender. --PerfektesChaos 11:45, 14. Okt. 2015 (CEST)
    Ok, da gebe ich dir Recht. Für die eindeutigen Fälle wäre es dennoch ganz nett zu haben. -- hgzh 15:07, 16. Okt. 2015 (CEST)
Unterstützung
  1. Pro wäre schon ganz praktisch. --K@rl 08:26, 16. Okt. 2015 (CEST)
  2. Pro -- hgzh 15:07, 16. Okt. 2015 (CEST) zumindest in den eindeutigen Fällen
  3. Pro -- Generator (Diskussion) 14:39, 19. Okt. 2015 (CEST)
  4. Pro -- Wenn man es zunächst optional einführt, bis es wirklich bugfrei läuft. -- Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  5. Kontra Nicht sinnvoll automatisierbar; Denken und Gucken statt Bruch produzieren. Es wird niemals „wirklich bugfrei“ laufen, weil syntaktische Probleme der menschlichen Interpretation bedürfen und fehlerhafte Syntax sich nicht zweifelsfrei sebst reparieren kann. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
  6. Kontra --Euku: 21:14, 26. Okt. 2015 (CET) siehe über mir

Pfeil-hoch-Helferlein für alle aktivieren[Quelltext bearbeiten]

Beschreibung

Das Pfeil-hoch-Helferlein für alle Personen aktivieren.

Diskussion
  • Auf jede Seite ganz nach unten einen Button/Knopf/Pfeil zum ganz nach oben springen, so daß man auch ohne das Pfeil-hoch-Helferlein bzw. auf Seiten, die nicht so bequem in Abschnitte unterteilt sind von ganz unten nach ganz oben springen kann, ohne scrollen zu müssen.--Emergency doc (D) 00:56, 2. Okt. 2015 (CEST)
Ist doch eigentlich kein technischer Wunsch, sondern wie oben mit den Hovercards? Normal gibt's dafür Pos1 und auf Touch-only-Geräten blenden die meisten Browser sowas ein. --nenntmichruhigip (Diskussion) 13:17, 14. Okt. 2015 (CEST)
Wow, danke, hab was gelernt, funktioniert super... :-)--Emergency doc (D) 22:49, 15. Okt. 2015 (CEST)
Unterstützung
  1. Kontra Habe ich in einem Jahrzehnt nicht gebraucht, dann muss man auch nicht jeder IP Extra-Software aufzwingen. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
  2. Hier mit Pro abstimmen!

Schriftgröße mathematischer Formeln vereinheitlichen[Quelltext bearbeiten]

Beschreibung

Die Schriftgröße mathematischer Formeln soll in den Projekten selbst und global vereinheitlich werden.

Diskussion
  • Schriftgröße und Baseline von mathematischen Formeln an Text anpassen: , , , und ähnliches. --Boehm (Diskussion) 18:10, 2. Okt. 2015 (CEST)
    Das geht bereits mit dem TeX-Tag \textstyle, bspw. --Morten Haan א Wikipedia ist für Leser da 18:32, 2. Okt. 2015 (CEST)
    Mehr schlecht als recht. Die Baseline ist mit textstyle immer noch falsch. Vergleiche mit , , . Ich habe in vielen WPs (deutsch, englisch, französisch, etc.) die vermeindliche „Lösung“ gesehen: mit \scriptstyle. Mehrere Diskutanten haben das als „Lösung“ vorgeschlagen und bestehen auf dessen Verwendung. Ich halte das für ungeschickt und möchte lieber eine globale Textgrößenanpassung als ein lokales (falsches) Tag, also scriptstyle. Mit einem funktionierenden \textstyle könnte ich leben. --Boehm (Diskussion) 21:09, 2. Okt. 2015 (CEST)
  • Gibt es hierzu bereits ein Feature-Request auf https://phabricator.wikimedia.org/ ? -- Stephan Kulla (Diskussion) 19:45, 26. Okt. 2015 (CET)
Unterstützung
  1. Pro --DWI (Diskussion) 21:12, 13. Okt. 2015 (CEST)
  2. Pro -- Michi 21:30, 13. Okt. 2015 (CEST)
  3. Pro«« Man77 »» Ḏū hāḏā t-tawfīʿ 22:32, 13. Okt. 2015 (CEST)
  4. Pro --Morten Haan 🐝 Wikipedia ist für Leser da 22:58, 13. Okt. 2015 (CEST)
  5. Pro --Boehm (Diskussion) 23:12, 13. Okt. 2015 (CEST)
  6. Pro --Cirdan ± 01:09, 14. Okt. 2015 (CEST)
  7. Pro --Distelfinck (Diskussion) 14:11, 14. Okt. 2015 (CEST)
  8. Pro -- Peter 16:54, 14. Okt. 2015 (CEST)
  9. Pro --Debenben (Diskussion) 08:47, 15. Okt. 2015 (CEST)
  10. Pro --Rainald62 (Diskussion) 23:45, 15. Okt. 2015 (CEST)
  11. Pro --Daniel749 Disk. (STWPST) 12:53, 17. Okt. 2015 (CEST)
  12. Pro --Kein Einstein (Diskussion) 16:20, 17. Okt. 2015 (CEST)
  13. Pro --Aineias © 20:45, 17. Okt. 2015 (CEST)
  14. Pro --dcb 15:11, 19. Okt. 2015 (CEST)
  15. Pro --DerPetzi (Diskussion) 12:33, 22. Okt. 2015 (CEST)
  16. Pro -<)kmk(>- (Diskussion) 04:26, 23. Okt. 2015 (CEST)
  17. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  18. Pro --Frank C. Müller (Diskussion) 15:48, 23. Okt. 2015 (CEST)
  19. Pro --  TRN 3.svg hugarheimur 19:37, 23. Okt. 2015 (CEST)
  20. ProDerHexer (Disk.Bew.) 20:46, 23. Okt. 2015 (CEST)
  21. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  22. Pro Gute Idee. --Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  23. Pro --Furfur Diskussion 21:11, 24. Okt. 2015 (CEST)
  24. Pro --Chewbacca2205 (D) 22:11, 24. Okt. 2015 (CEST)
  25. Pro --Stephan Kulla (Diskussion) 19:45, 26. Okt. 2015 (CET)

Barrierefreie Darstellung von mathematischen Formeln[Quelltext bearbeiten]

Beschreibung

Mithilfe von Erweiterungen wie MathJax eine barrierefreie Darstellung mathematischer Formeln ermöglichen.

Diskussion
  • Realisierung von MathJax oder ähnlich für die math-Umgebung und dadurch vielleicht irgendwann eine barrierefreie Darstellung von mathematischen Formeln. -- E (D) 11:23, 6. Okt. 2015 (CEST)
  • Hatten wir schon im jahrelangen Probebetrieb und konnte in den Benutzereinstellungen freigeschaltet werden. Zumindest für mich hat das gut funktioniert -- besser jedenfalls als PNG. Diese Möglichkeit wurde aber im letzten Frühjahr ohne große Diskussion gestrichen. -<)kmk(>- (Diskussion) 04:31, 23. Okt. 2015 (CEST)
  • Siehe dieses Feature-Request und deren abhängige Features. Alternativ können wir auf Phabricator auch einen Award für dieses Feature vergeben, um unsere Unterstützung zu zeigen. -- Stephan Kulla (Diskussion) 19:40, 26. Okt. 2015 (CET)
Unterstützung
  1. Pro -- Michi 21:30, 13. Okt. 2015 (CEST)
  2. Pro --Morten Haan 🐝 Wikipedia ist für Leser da 22:58, 13. Okt. 2015 (CEST)
  3. Pro -- E (D) 16:16, 14. Okt. 2015 (CEST)
  4. Pro -- Generator (Diskussion) 14:40, 19. Okt. 2015 (CEST)
  5. Pro -<)kmk(>- (Diskussion) 04:31, 23. Okt. 2015 (CEST)
  6. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  7. Pro --Boehm (Diskussion) 10:14, 23. Okt. 2015 (CEST)
  8. Pro --  TRN 3.svg hugarheimur 19:39, 23. Okt. 2015 (CEST)
  9. Pro würde aber eher MathML nehmen, da das wie svg teil von HTML5 ist. --Patrick Stützel (Diskussion) 11:57, 24. Okt. 2015 (CEST)
  10. Pro --Gamma γ 19:26, 25. Okt. 2015 (CET)
  11. Pro -- Stephan Kulla (Diskussion) 19:40, 26. Okt. 2015 (CET)

Korrekte Abschnittsbearbeitungslinks bei ungesichteten Seiten[Quelltext bearbeiten]

Beschreibung

(phab:T47603) Die ungesichtete Anzeige soll auf die korrekten Links zur Bearbeitung eines Abschnittes verweisen.

Diskussion
  • (Task 47603) Möchte man einen Abschnitt in einer gesichteten Version eines Artikels bearbeiten, von dem in einer ungesichteten Version neue Überschriften (= Abschnitte) eingefügt worden sind, landet man beim Klick auf "Bearbeiten" in einem falschen Abschnitt. Man muss dann erst die ungesichtete Version aufrufen, um Abschnitte bearbeiten können. Auch beim Bearbeiten der gesichteten Version soll im Editierfenster der korrekte, ausgewählte Abschnitt erscheinen. --217.227.71.63 06:36, 20. Sep. 2015 (CEST)
Unterstützung
  1. ProDerHexer (Disk.Bew.) 20:48, 23. Okt. 2015 (CEST)
  2. Pro --BHC 🐈 (Disk.) 23:25, 23. Okt. 2015 (CEST)
  3. Pro --Chewbacca2205 (D) 22:12, 24. Okt. 2015 (CEST)

Einzelne Abschnitte kopieren[Quelltext bearbeiten]

Beschreibung

Mit einem Klick einzelne Abschnitte in die Zwischenablage oder direkt auf bestimmte Seiten kopieren, aufgrund von Lizenzbestimmungen erstmal nur Diskussionsnamensräume.

Diskussion
  • Ich wünsche mir eine Funktion für Meta-Seiten (wie z.B. Löschdiskussionen), mit der man einen einzelnen Abschnitt einer Seite mit einem Klick auf eine Unterseite verschieben kann. Diese Funktion soll ein spezielles Recht benötigen, welchen (erstmal) nur Administratoren besitzen sollen. Details siehe Disk --FeddaHeiko 15:46, 19. Sep. 2015 (CEST)

Details zur Funktionsweise

  • Der Abschnitt wird komplett (also Überschrift und alle Absätze bis zur nächsten, gleichwertigen Überschrift) auf eine neu angelegte Unterseite verschoben
  • An der Stelle, an der der Abschnitt vorher war, wird die Unterseite so eingebunden, dass ein Klick auf "Abschnitt bearbeiten" direkt zur Unterseite führt
  • noch zu klären: Umgang mit der Versionshistorie
Beispiel 

Wikipedia:Löschkandidaten/heute (vorher)

== Überschrift 1 ==
Text Text Text
== Überschrift 2 ==
Text Text Text
:Text Text Text
=== Überschrift 2b ===
Text Text Text
:Text Text Text
== Überschrift 3 ==
Text Text Text



   -> *Magie* ->   

Wikipedia:Löschkandidaten/heute (hinterher)

== Überschrift 1 ==
Text Text Text
{{Wikipedia:Löschkandidaten/heute/Überschrift 2}}
== Überschrift 3 ==
Text Text Text

Wikipedia:Löschkandidaten/heute/Überschrift 2 (neu angelegt)

== Überschrift 2 ==
Text Text Text
:Text Text Text
=== Überschrift 2b ===
Text Text Text
:Text Text Text

Begründung

Dies soll in erster Linie eine Alternative für den Wunsch "Die Möglichkeit, einzelne Abschnitte von Seiten beobachten zu können" aus dem Top 20 der Umfrage von 2013 sein, der leider aufgrund zu hohen technischen Aufwands abgelehnt wurde. (Die neuen Unterseiten kann man dann ja problemlos beobachten.) Daher soll diese Funktion (vorerst) nur für bestimmte Meta-Seiten (z.B. Löschdiskussion) zur Verfügung stehen bzw. erlaubt sein.

Um Mißbrauch vorzubeugen, soll diese Funktion zunächst nur Administratoren zur Verfügung stehen. Eine Ausweitung auf andere Benutzergruppen und/oder den Artikel-Namensraum wäre vorstellbar, müsste jedoch vor Einführung zunächst breiter diskutiert werden.

Diskussion dazu Anmerkungen, Ergänzungen und konstruktive Kritik bitte hierher --FeddaHeiko 15:46, 19. Sep. 2015 (CEST)

Du hast es dezent mit dem Hinweis auf den unklaren Umgang mit der Versionshistorie erwähnt: Das ist nämlich das KO-Kriterium. Das Problem ist nicht das Duplizieren der Versionshistorie, das würde man wohl noch hinbekommen, mit ganz viel Aufwand auch selektiv für den ausgelagerten Abschnitt (damit er seine eigene Versionshistorie bekommt). Was Du nicht hinbekommst, sind die späteren Bearbeitungen der eingebundenen Seite. Man findet es leider kaum mal als klare Aussage, aber Abschnitte mit Schöpfungshöhe dürfen prinzipiell nicht eingebunden werden. Das kannst Du auch technisch nicht lösen. MBxd1 (Diskussion) 15:53, 19. Sep. 2015 (CEST)
Die Signaturen in der Diskussion kennzeichen den Autoren des Textes und den Zeitpunkt der Erstellung des Beitrags genau wie in der Versionsgeschichte. Wo ist das Problem? -- hgzh 16:15, 19. Sep. 2015 (CEST)
In der Annahme, dass es um den Artikelnamensraum geht. Ansonsten geht es. MBxd1 (Diskussion) 16:29, 19. Sep. 2015 (CEST)
Wie oben geschrieben: es geht erstmal nur um den Meta-Namensraum. Und da auch nicht alles, sondern nur bestimmte Seiten (wie z.B. Löschdiskussionen). Ausweitungen auf den Artikel-Namensraum müsste man sowieso noch genauer diskutieren. --FeddaHeiko 22:07, 19. Sep. 2015 (CEST)
Ja stimmt, irgendwo da oben dazwischengeklemmt steht das. Umseitig habe ich nichts von dieser Einschränkung gefunden. Für den Artikelnamensraum müsste man das nicht noch genauer diskutieren, da ist es prinzipiell unmöglich, weil die Autoren der eingebundenen Teile nicht in der Versionshistorie des einbindenden Artikels auftauchen. MBxd1 (Diskussion) 22:13, 19. Sep. 2015 (CEST)
Der Einwand ist korrekt: Im Artikelnamensraum dürfte die (Pseudo-)Unterseite dann nicht einfach eingebunden werden, sondern eher mit Haupartikel verlinkt werden. Um Missverständnissen vorzubeugen, habe ich meinen Wunsch dahingehend präzisiert. --FeddaHeiko 16:38, 20. Sep. 2015 (CEST)
Bei Beiträgen mit Signaturen muss die History nicht dupliziert werden, auch ein Eindingen ist kein Problem. Das Ganze lässt sich ganz einfach per Bot lösen, dieser kann dann auch prüfen, ob der Antragsteller Admin ist. --Morten Haan 🏡 Wikipedia ist für Leser da 14:24, 21. Sep. 2015 (CEST)
Unterstützung
  1. Hier mit Pro abstimmen!

Bearbeiten[Quelltext bearbeiten]

Verlinkungsvorschläge zu markierten Wörtern[Quelltext bearbeiten]

Beschreibung

Beim Markieren von Wörtern sollen im WikiEditor Vorschläge angezeigt werden, wohin sinnvollerweise verlinkt werden könnte.

Diskussion
  • Beim Anlegen eines Wikilinks eine Möglichkeit, ähnlich wie bei Hotcat für Kategorien, bereits beim Editieren mögliche Linkziele angezeigt zu bekommen, damit man z.B. Klammerlemmas, Lemmas mit Sonderzeichen o.ä. nicht erst aufwändig in einem zweiten Tab oder Fenster suchen muss.--Emergency doc (D) 10:51, 6. Okt. 2015 (CEST)
    @Emergency doc: Sowas kann der schnöde Wikitext-Editor nicht leisten, er ist ja bloß ein Textfeld. Hier müsste man also den VisualEditor heranziehen – und den habe ich schon lange nicht mehr genutzt, meine aber, dass der diese Funktion ziemlich gut beherrscht hat, oder? Grüße, Yellowcard (D.) 11:18, 6. Okt. 2015 (CEST)
    Guck ich gleich mal, aber ich meine ausdrücklich nicht den Wikieditor, der ja wirklich nur ein reines Textfeld ist, sondern eine Möglichkeit nur Wikilinks zu editieren, z.B. indem man ein Wort mar54kiert und mit Rechtsklick eine kleine Editzeile öffnet, in der man nach einem passenden Wikilinkziel suchen kann.--Emergency doc (D) 13:14, 6. Okt. 2015 (CEST)
    Ah, verstehe, dann hatte ich den Vorschlag ohnehin falsch verstanden. Das hört sich nach einem netten JavaScript-Gadget an. Grüße, Yellowcard (D.) 13:21, 6. Okt. 2015 (CEST)
    @Emergency doc, Yellowcard: Mir erschließt sich leider nicht, inwiefern sich das von der Suche im VisualEditor unterscheidet, bei dem man ja Vorschläge zum Wort bekommt, inklusive Klammerlemmata, Sonderzeichen usw. —Martin (WMDE) (Disk.) 17:10, 12. Okt. 2015 (CEST)
    @Martin: Sorry, der Ping war nicht angekommen. Von der Funktion im VE unterscheidet sich das nach meinem Verständnis gar nicht, Emergency doc wünscht sich diese Funktion aber auch für den Wikitext-Editor. Grüße, Yellowcard (D.) 21:43, 13. Okt. 2015 (CEST)
    Völlig egal, ob VE, Bearbeitungsmodus oder normale Ansicht irgendeiner Wiki-Seite: Den momentan selektierten Text ermitteln, falls etwas selektiert ist, und dann einen Button/Link anklicken (Tastaturkombinationen sind browserspezifisch und oft schon für etwas anderes vergeben, bei jedem Benutzer anders), woraufhin in einem anderen Browser-Tab (aber möglichst immer in demselben) die Artikelsuche öffnet und mit dem markierten Text vorbelegt ist (nicht zu speziell mit prefix, weil sonst keine Treffer mehr) – das ist für einen fortgeschrittenen Anfänger in der Gadget-Programmierung hinzubekommen; hoffentlich nach modernsten Standards und sauber dokumentiert, und robust bei unbeabsichtigt vielzeiliger Selektion. LG --PerfektesChaos 13:57, 14. Okt. 2015 (CEST)
    Hallo, leider hat irgendwie keiner der Pings/Pinge/wieauchimmer mich erreicht. Ich glaube, daß das was ich meine tatsächlich eher ein kleines Gadget wäre. Also im Artikel einfach einen Begriff markieren und mit Rechtsklick ein Minieditfenster öffnet, in dem man einen Link angeben kann. Folgende Anwendung sehe ich dafür: Ich habe einen Artikel geschrieben, den ich jetzt aus anderen Artikeln verlinken möchte. In einer 50kb-Liste finde ich jetzt ein mögliches Stichwort, von dem aus ich auf meinen Zielartikel verlinken kann. Jetzt muss ich aber aufwändig suchen, wo genau sich das Wort befindet, den entsprechenden Abschnitt dann im Editor öffnen und mit der Browsersuchfunktion im Quelltext nach meinem Wort suchen, bevor ich dann erst den Link eingeben kann. Mit so einem Gadget wäre es um ein vielfaches einfacher, da mir etliche Arbeitsschritte entfallen würden. Gruß--Emergency doc (D) 22:15, 15. Okt. 2015 (CEST)
    Die Suchergebnisse sind nicht so zielführend, dass du mit einem Mini-Fenster auskommen würdest. Du brauchst schon eine richtige Seite in einem anderen Browser-Tab, in der du auch den thematischen Kontext, BKS usw. abschätzen kannst. Alternativ kann dir jemand per Gadget den momentan selektierten Text auf Knopfdruck in das Suchfeld (meist rechts oben) eintragen, wo du dann konventionell glücklich werden magst; das sind dann aber nicht weniger Mausklicks als normales C&P, nur kompliziertere. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro--Emergency doc (D) 22:15, 15. Okt. 2015 (CEST)
  2. Kontra gegen eine Standardmäßige aktivierung. Neutral als Helferlein. -- Generator (Diskussion) 14:42, 19. Okt. 2015 (CEST)
  3. Pro --DerPetzi (Diskussion) 12:34, 22. Okt. 2015 (CEST)
  4. Pro --Chewbacca2205 (D) 22:15, 24. Okt. 2015 (CEST)

Steuerzeichen beim Bearbeiten anzeigen[Quelltext bearbeiten]

Beschreibung

Funktion entwickeln, die beim Bearbeiten Steuerzeichen anzeigt.

Diskussion
  • Ich würde es gut finden, wenn es ähnlich wie bei Office-Programmen einen Schalter gibt, mit dem man "unsichtbare Zeichen" einblenden kann. Doppelte Leerzeichen und fehlende Absatzumbrüche würden dann schneller auffallen. --Aineias © 23:09, 3. Okt. 2015 (CEST)
    Und man würde die „falschen“ Steuerzeichen einfacher beseitigen können, als mit einem externen Editor: [1]. --Boehm (Diskussion) 00:49, 4. Okt. 2015 (CEST)
    Benutzer:Schnark/js/antispoof macht genau das. WSTM schmeißt zweifelsfrei als Schrott erkannte Codes auch gleich automatisch raus. --PerfektesChaos 13:25, 4. Okt. 2015 (CEST)
    Sonderzeichen/Steuerzeichen können auch sinnvoll sein. Ein Automatismus der diese beseitigt ist nicht das was man will. Eine simple Anzeige der Steuerzeichen ist doch viel einfacher und man hat mehr Kontrolle über das was passiert. --Boehm (Diskussion) 15:03, 4. Okt. 2015 (CEST)
    Also, wenn ich „zweifelsfrei als Schrott erkannt“ schreibe, dann meine ich das auch so. Hinzu kommt, dass viele in Frage kommenden Zeichen unsichtbar sind und sich nicht so leicht manuell entfernen lassen. --PerfektesChaos 16:08, 4. Okt. 2015 (CEST)
    Genau das ist ja das Problem welches hier technisch gelöst werden soll. Die Zeichen sind unsichtbar. Und deswegen die Bitte eine Möglichkeit einzubauen, dass man die Zeichen sehen kann. Und schon kann man das leicht manuell bearbeiten. Und selbstverständlich möchte man alle Fälle abdecken und nicht nur die zweifelsfreien. --Boehm (Diskussion) 22:08, 4. Okt. 2015 (CEST)
    Manchmal setzt man auch versehntlich Absätzte, wo keine hinsollen. Das wird nie automatisch als fehlerhaft erkannt, und von mir zunächst auch nicht. Darüberhinaus geht es hierbei auch um eine Bearbeitungshilfe, bei manchen Zeichen kann ich nicht so leicht erkennen, ob die Lücke davor oder danach dazu gehört oder durch ein Leerzeichen entstand. --Aineias © 15:27, 6. Okt. 2015 (CEST)
    Das von PerfektesChaos vorgeschlagene Script antispoof macht nur bedingt das was sich Aineias wünscht. Witziger Weise hat der Wikipedia-interne Javascript Editor, mit dem man das Script bearbeiten kann, genau solch einen Knopf eingebaut den sich Aineias wünscht. --Boehm (Diskussion) 15:33, 6. Okt. 2015 (CEST)
    wikEd macht genau das schon seit vielen Jahren und zeigt orange Quadrate mit Tooltip; anderen über das Bearbeitungsfeld gelegten Syntaxhighlightern mag man es beibringen, oder sie können es bereits. Im normalen Textarea eines Browsers hat der Browser das Sagen, und da sind unsichtbare Zechen eben erstmal unsichtbar. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro --тнояsтеn 22:03, 13. Okt. 2015 (CEST)
  2. Pro --Boehm (Diskussion) 23:22, 13. Okt. 2015 (CEST)
  3. Pro --Toru10 (DiskussionWPCS) 10:09, 14. Okt. 2015 (CEST)
  4. Pro --nenntmichruhigip (Diskussion) 13:17, 14. Okt. 2015 (CEST)
  5. Pro --MGChecker – (📞| 📝| Bewertung) 15:42, 14. Okt. 2015 (CEST)
  6. Pro --Aineias © 20:40, 17. Okt. 2015 (CEST)
  7. Pro -- Generator (Diskussion) 14:42, 19. Okt. 2015 (CEST)
  8. Pro --Frank C. Müller (Diskussion) 15:49, 23. Okt. 2015 (CEST)
  9. ProDerHexer (Disk.Bew.) 20:52, 23. Okt. 2015 (CEST)
  10. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  11. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:21, 26. Okt. 2015 (CET)

Beim Speichern Warnhinweis bei falsch eingegebener mathematischer Formel[Quelltext bearbeiten]

Beschreibung

Beim Speichern sollen Benutzerinnen und Benutzer darauf hingewiesen werden, falls die von ihnen hinzugefügte mathematische Formel fehlerhaft ist.

Diskussion
  • Eine Wartungskategorie analog Kategorie:Wikipedia:Syntaxfehler durch MediaWiki-Komponente erkannt für mathematische Formeln mit fehlerhaftem TeX. Außerdem einen Warnhinweis beim speichern einer Seite, wenn der Code zum Beispiel mit MathML, aber nicht in PNG-Darstellung funktioniert. Sonst bekommt man als Autor, wenn man eine andere Darstellung aktiviert hat, nichts davon mit, wenn für andere Benutzer die ganze Seite voll roter Fehlermeldungen ist.--Debenben (Diskussion) 22:01, 28. Sep. 2015 (CEST)
Unterstützung
  1. Pro --DWI (Diskussion) 21:13, 13. Okt. 2015 (CEST)
  2. Pro --тнояsтеn 22:04, 13. Okt. 2015 (CEST)
  3. Pro --Rainald62 (Diskussion) 23:52, 15. Okt. 2015 (CEST)
  4. Pro --Boehm (Diskussion) 01:10, 16. Okt. 2015 (CEST)
  5. Pro --Kein Einstein (Diskussion) 16:21, 17. Okt. 2015 (CEST)
  6. Pro --dcb 15:13, 19. Okt. 2015 (CEST)
  7. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  8. Pro --Chewbacca2205 (D) 22:16, 24. Okt. 2015 (CEST)
  9. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:21, 26. Okt. 2015 (CET)

Hervorheben von Wikisyntax[Quelltext bearbeiten]

Beschreibung

Die Wikisyntax soll wie andere Syntagmen ebenfalls verschiedenfarbig hervorgehoben werden. Top-20-Wunsch 2013.

Diskussion
  • Dem Tag <syntaxhighlight> sollte Unterstützung für Wikitext hinzugefügt werden. --Morten Haan א Wikipedia ist für Leser da 14:52, 26. Sep. 2015 (CEST)
    Wikitext hat keine formale Syntax; ist deshalb für syntaxhighlight kaum zu erfassen, und formal Unausgewogenes kann trotzdem richtig sein. Aber eine Minimalversorgung mit Klammern usw. wäre auf http://pygments.org/docs/lexers/ möglich. Siehe auch Hilfe:Wikisyntax/Hintergrund. Weltweit in jedem Wki die Lokalisierung aller Syntaxelemente permanent zu tracken und daraus sprach- und projektspezifische Syntaxregeln zu generieren, die eine Parserfunktion von einer Vorlageneinbindung unterscheiden können, dürfte scheitern. --PerfektesChaos 11:57, 4. Okt. 2015 (CEST)
Unterstützung
  1. Pro --Morten Haan 🐝 Wikipedia ist für Leser da 23:18, 13. Okt. 2015 (CEST)
  2. Pro Ohne Syntaxhighlighting könnte ich nicht arbeiten. Am besten wikEd standardmäßig einbauen. --Trustable (Diskussion) 14:58, 14. Okt. 2015 (CEST)
  3. Pro --Arnd (Diskussion) 17:10, 14. Okt. 2015 (CEST)
  4. Pro nette sache – Giftpflanze 17:26, 14. Okt. 2015 (CEST)
  5. Pro Finde ich sehr nützlich, besonders für Neulinge --Atlasowa (Diskussion) 13:30, 15. Okt. 2015 (CEST)
  6. Pro --Daniel749 Disk. (STWPST) 12:57, 17. Okt. 2015 (CEST)
  7. Pro --Aineias © 20:41, 17. Okt. 2015 (CEST), mit würde die minimalversion schon reichen
  8. Pro -- Generator (Diskussion) 14:44, 19. Okt. 2015 (CEST)
  9. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  10. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  11. Pro --Chewbacca2205 (D) 22:16, 24. Okt. 2015 (CEST)

Bestätigung vor Abspeichern[Quelltext bearbeiten]

Beschreibung

Zusätzliche Bestätigung vor Abspeichern ergänzen.

Diskussion
  • Kein großes Problem, aber störend: Bisher wird bei Bearbeitungen an Lemmata und Diskussion zu einem Lemmata bei Anwahl des Link „Seite speichern“ dieser Befehl sofort durchgeführt. Bei Bearbeitungen im ANR kommt jedoch wenn unter Zusammenfassung kein Eintrag vorhanden ist „ein Hinweis“ und erst bei Wiederholung der Anwahl wird der Link „Seite speichern“ ausgeführt. Dieser Hinweis vor Ausführung „Seite speichern“ würde das Abspeichern ohne vorherige Anwahl „Signieren“ / oder Zusammenfassung ohne Eintrag vermeiden helfen. Nachsignieren wäre zum Beispiel weniger oft erforderlich. --Urdenbacher (Diskussion) 17:43, 19. Sep. 2015 (CEST)
    @Urdenbacher: Der Hinweis auf eine leere Zusammenfassungszeile ist, soweit ich mich erinnere, aber auch nur eine eigene zusätzliche Einstellung. Das Abspeichern zu verhindern, wenn nicht signiert wurde, habe ich verstanden, das „Zusammenfassung ohne Eintrag“ jedoch leider nicht. —Martin (WMDE) (Disk.) 17:10, 12. Okt. 2015 (CEST)
    @Martin: Bei Ende der Bearbeitung auf der "Spielwiese" sind vor "Speichern" in dem Zeilenkästchen unter dem Wort "Zusammenfassung" Informationen für die vorgenommen Änderungen/Ergänzungen einzutragen. Erfolgt kein Eintrag, dann kommt nach "Speichern" der angeführte Hinweis und erst beim erneuten "Speichern" erfolgt die Speicherung. --Urdenbacher (Diskussion) 11:42, 18. Okt. 2015 (CEST)
    mehr Infos/Disk; ansonsten persönlich wählbare Konfiguration. Speicherungswarnung ohne Signatur ist auch gelegentlich im Gespräch, aber nicht jeder Tippfehleredit auf Disk erhält eigene Sig. --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Hier mit Pro abstimmen!

Kurzzeitig nachträglich bearbeitbare Zusammenfassungszeile[Quelltext bearbeiten]

Beschreibung

Zur Korrektur von Fehler soll die Zusammenfassungszeile auch kurze Zeit nach dem Speichern noch bearbeitet werden können.

Diskussion
  • Die Zusammenfassungszeile sollte (ggf. für einen kurzen Zeitraum) nach dem Abspeichern noch editierbar sein. Oft schleichen sich Tippfehler ein, oder man sendet versehentlich zu früh ab. --AchimP (Diskussion) 11:24, 21. Sep. 2015 (CEST)
  • Die Zus.Zeile ist aber integraler Bestandteil der Artikelversion, ähnlich wie Datum und Bearbeiter. Z. (Diskussion) 23:03, 13. Okt. 2015 (CEST)
  • Kann allenfalls in den ersten 60 Sekunden nach Speichern noch eröffnet werden.
    Zu der Zeit haben es aber die RCler schon gesehen, und jemandem kann es in der Beo aufgetaucht sein.
    Der geänderte BK braucht einen erneuten Eintrag in RC/Beo, und er muss auch in der VG gesondert nachvollziehbar sein. Sonst speichere ich meinen großen Edit mit „kl.“ ab, mache das auf den Beos sichtbar, und ändere das hinterher in einen ausführlichen Hinweis. Anschließend ätschi-bätschi: „Tja, das habe ich ja alles in den BK geschrieben, du beobachtest die Seite ja, hättest reagieren können.“ Wenn aber ein neuer Eintrag in der VG, dann kann man auch mit einem hinzugefügten Leerzeichen und verbessertem Kommentar erneut abspeichern.
    --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro -- Michi 21:32, 13. Okt. 2015 (CEST)
  2. Kontra Missbrauchsgefahr. -- Generator (Diskussion) 14:45, 19. Okt. 2015 (CEST)
  3. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  4. Kontra Manipulationsanfällig oder kein Vorteil --PerfektesChaos 11:19, 25. Okt. 2015 (CET)

Bessere Lösung von Bearbeitungskonflikten[Quelltext bearbeiten]

Beschreibung

Die Auflösung von Bearbeitungskonflikten soll verbessert werden.

Diskussion
  • Neuer Anwendungsfall für den einfacheren Umgang bei Bearbeitungskonflikten. Vorschlag hier. --Micha 17:40, 22. Sep. 2015 (CEST) - Wenn nicht dieser Anwendungsfall, dann soll wenigstens nach dem Serverrountrip der Text mit der jeweiligen Änderung des Users im Textfeld angezeigt bleiben. Für c&p. Jetzt muss man ja "back" klicken und den Text aus dem Browsercache holen und das ist umständlich und unnötig. Das wäre eine Kleinere Änderung. Also nach edit conflict nicht den vom anderen user geänderten Text anzeigen, sondern den vom eigenen user. --Micha 18:54, 22. Sep. 2015 (CEST)
    • Dürfte schon funktionieren: Im Falle eines Bearbeitungskonfliktes gibt es zwei Textfelder. Das normale zum bearbeiten oben mit dem neuen Text (wo man seinen einfügen muss), dann ein Versionsunterschied und dadrunter ein zweites (schreibgeschütztes) Textfeld mit den eigenen Bearbeitungen, wo man sie her kopieren kann. Der Umherirrende 19:21, 22. Sep. 2015 (CEST)
      • Was Mcha vorstellt, ist genau das, was ich mir wünsche. Grüße, --Bellini 05:29, 23. Sep. 2015 (CEST)
  • Besseres Tool für die Auflösung von Bearbeitungskonflikten (Idee von der WikiCon, siehe auch phab:T108664) -- Daniel Kinzler (WMDE) (Diskussion) 23:23, 3. Okt. 2015 (CEST)
  • Leichtere Möglichkeit nach Bearbeitungskonflikten den eigenen Text zu kopieren --Carlos-X 11:15, 19. Sep. 2015 (CEST)
  • In manchen anderen Wikis (jedenfalls Klexikon) kann man eine Seite nicht bearbeiten, wenn jemand anders das Fenster offen hat (man erfährt auch, wer es offen hat). Würde das das Problem nicht lösen? Z. (Diskussion) 23:05, 13. Okt. 2015 (CEST)
Unterstützung
  1. Pro --Kurt Jansson (Diskussion) 00:56, 13. Okt. 2015 (CEST)
  2. Pro --Geolina mente et malleo 21:33, 13. Okt. 2015 (CEST)
  3. Pro -- Michi 21:33, 13. Okt. 2015 (CEST)
  4. Pro -- ɦeph 21:39, 13. Okt. 2015 (CEST)
  5. Pro Yellowcard (D.) 21:57, 13. Okt. 2015 (CEST)
  6. Pro -- Achim Raschka (Diskussion) 22:50, 13. Okt. 2015 (CEST)
  7. Pro --Cirdan ± 01:09, 14. Okt. 2015 (CEST)
  8. Pro--Toru10 (DiskussionWPCS) 10:10, 14. Okt. 2015 (CEST)
  9. ProQueryzo ?! Red-WikiPill.png Blue-WikiPill.png 10:18, 14. Okt. 2015 (CEST)
  10. Pro --Distelfinck (Diskussion) 14:19, 14. Okt. 2015 (CEST)
  11. Pro --MGChecker – (📞| 📝| Bewertung) 15:45, 14. Okt. 2015 (CEST)
  12. Pro--all apatcha msg 15:56, 14. Okt. 2015 (CEST)
  13. Pro --Arnd (Diskussion) 17:12, 14. Okt. 2015 (CEST)
  14. Pro --Hareinhardt (Diskussion) 22:56, 14. Okt. 2015 (CEST)
  15. Pro --Emergency doc (D) 22:19, 15. Okt. 2015 (CEST)
  16. Pro --FeddaHeiko 23:47, 15. Okt. 2015 (CEST)
  17. Pro -- hgzh 15:09, 16. Okt. 2015 (CEST)
  18. Pro --RookJameson (Diskussion) 00:09, 17. Okt. 2015 (CEST)
  19. Pro --Holmium (d) 09:07, 17. Okt. 2015 (CEST)
  20. Pro --Daniel749 Disk. (STWPST) 12:58, 17. Okt. 2015 (CEST)
  21. Pro --S. F. B. Morseditditdadaditdit 06:17, 18. Okt. 2015 (CEST)
  22. Pro --Mattes (Diskussion) 09:20, 19. Okt. 2015 (CEST)
  23. Pro Zumindest den eigenen Text sollte man einfach mit c&p kopieren können. Das funktioniert derzeit überhaupt nicht ordentlich. -- Generator (Diskussion) 14:46, 19. Okt. 2015 (CEST)
  24. Pro --dcb 15:15, 19. Okt. 2015 (CEST)
  25. Pro --CENNOXX 15:43, 21. Okt. 2015 (CEST)
  26. Pro --WolfgangLiebig • Disk. 19:00, 21. Okt. 2015 (CEST)
  27. Pro --DerPetzi (Diskussion) 12:35, 22. Okt. 2015 (CEST)
  28. Pro --jcornelius Benutzer Diskussion:Jcornelius 08:58, 23. Okt. 2015 (CEST)
  29. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  30. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  31. Pro --Frank C. Müller (Diskussion) 15:50, 23. Okt. 2015 (CEST)
  32. Pro --  TRN 3.svg hugarheimur 19:40, 23. Okt. 2015 (CEST)
  33. ProDerHexer (Disk.Bew.) 20:53, 23. Okt. 2015 (CEST)
  34. Pro --BHC 🐈 (Disk.) 23:27, 23. Okt. 2015 (CEST)
  35. Pro --Chewbacca2205 (D) 22:17, 24. Okt. 2015 (CEST)
  36. Pro --Gamma γ 19:20, 25. Okt. 2015 (CET)
  37. Pro derzeitiger Zustand hat mich schon häufiger hinter's Licht geführt, unbedarfte Neulinge dürfte das auch abschrecken. Eigene Änderung sollte leicht (auch ohne Umweg über Back) kopierbar sein. --MachtaUnix (Diskussion) 21:21, 25. Okt. 2015 (CET)
  38. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:24, 26. Okt. 2015 (CET) (siehe 23.; am besten Bearbeitungskonflikt wie Versionsunterschied(e) darstellen, C&P vereinfachen)
  39. Pro -- Freddy2001 DISK 15:19, 26. Okt. 2015 (CET)

Automatisches Einfügen geschützter Leerzeichen[Quelltext bearbeiten]

Beschreibung

Automatisches Einfügen geschützter Leerzeichen (Wikipedia:Typografie/Automatische Leerzeichen) ist gewünscht.

Diskussion
  • automatisches Einfügen geschützter Leerzeichen (Wikipedia:Typografie/Automatische Leerzeichen) --Schnark 11:41, 19. Sep. 2015 (CEST)
    • dann bitte auch als Unicode-Zeichen und nicht als &nbsp;! -- Michi 15:25, 21. Sep. 2015 (CEST)
      • Da es nur im erzeugten HTML, nicht aber im Wikitext eingefügt werden soll, ist das relativ egal. --Schnark 09:37, 22. Sep. 2015 (CEST)
        • Bei % funktioniert das schon. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 16:15, 25. Sep. 2015 (CEST)
          Die neue Technologie sieht vor, dass nur Weißraum, nicht aber Unicode-Zeichen eingefügt werden soll (auch anders als zurzeit bei % und Guillemets, wo echte geschützte Leerzeichen eingefügt werden). Das heißt: Beim C&P aus dem angezeigten HTML-Dokument erhält der Leser auf Wunsch normale Leerzeichen, geschützte Leerzeichen oder überhaupt kein Zeichen an dieser Stelle; die Breite des Weißraums wird je nach Situation auf Schmales Leerzeichen, Geschütztes Leerzeichen (breiter) oder was auch immer visualisiert. --PerfektesChaos 11:57, 4. Okt. 2015 (CEST)
          • Brauchen wir auch für §. Gruß, --Gnom (Diskussion) 11:02, 14. Okt. 2015 (CEST)
Unterstützung
  1. ProQueryzo ?! Red-WikiPill.png Blue-WikiPill.png 10:19, 14. Okt. 2015 (CEST)
  2. Pro --Gnom (Diskussion) 11:02, 14. Okt. 2015 (CEST)
  3. Pro --Trustable (Diskussion) 14:53, 14. Okt. 2015 (CEST)
  4. Pro --Hareinhardt (Diskussion) 22:56, 14. Okt. 2015 (CEST)
  5. Pro -- hgzh 15:10, 16. Okt. 2015 (CEST)
  6. Pro --Kein Einstein (Diskussion) 16:21, 17. Okt. 2015 (CEST)
  7. Pro --dcb 15:16, 19. Okt. 2015 (CEST)
  8. Pro --DerPetzi (Diskussion) 12:35, 22. Okt. 2015 (CEST)
  9. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  10. Pro --  TRN 3.svg hugarheimur 19:40, 23. Okt. 2015 (CEST)
  11. ProDerHexer (Disk.Bew.) 20:54, 23. Okt. 2015 (CEST)
  12. Pro --Schnark 09:16, 24. Okt. 2015 (CEST)
  13. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  14. Pro --PerfektesChaos 11:19, 25. Okt. 2015 (CET)

Paralleles Schreiben[Quelltext bearbeiten]

Beschreibung

(phab:T3898, phab:T76548)Paralleles Schreiben ermöglichen.

Diskussion
  • kollaboratives Schreiben ermöglichen (analog zu Etherpad) anstatt Bearbeitungskonflikten - besonders wichtig für zeitkritische Veröffentlichungen wie Wikinews-Artikel (phab:T3898, phab:T76548) (nicht signierter Beitrag von 89.207.252.198 (Diskussion) 19. September 2015, 11:31 Uhr)
    • jep, stelle ich mir spannend vor! Würde dem stillen Kämmerlein entgegenwirken ... –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 16:13, 25. Sep. 2015 (CEST)
Unterstützung
  1. Pro -- Achim Raschka (Diskussion) 22:46, 13. Okt. 2015 (CEST)
  2. ProQueryzo ?! Red-WikiPill.png Blue-WikiPill.png 10:19, 14. Okt. 2015 (CEST)
  3. Pro Yellowcard (D.) 12:33, 14. Okt. 2015 (CEST)
  4. Pro --Daniel749 Disk. (STWPST) 12:59, 17. Okt. 2015 (CEST)
  5. Pro --dcb 15:17, 19. Okt. 2015 (CEST)
  6. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  7. ProDerHexer (Disk.Bew.) 20:54, 23. Okt. 2015 (CEST)
  8. Pro --Schnark 09:19, 24. Okt. 2015 (CEST)
  9. Pro --Stephan Kulla (Diskussion) 19:47, 26. Okt. 2015 (CET) Wow, das wäre ein Traum! :-) 

Automatische Rechtschreibkorrektur[Quelltext bearbeiten]

Beschreibung

Automatische Korrektur von Rechtschreibfehlern, bspw. basierend auf Helferlein.

Diskussion
Unterstützung
  1. Hier mit Pro abstimmen!

Schnittstelle zwischen Tabellenkalkulationen und Wikimedia-Projekten[Quelltext bearbeiten]

Beschreibung

Schnittstelle zwischen Tabellenkalkulationen und Wikimedia-Projekten ähnlich EXCEL-Tabellenumwandlung und Excel2Wiki entwickeln.

Diskussion
  • Einfaches Einfügen von Tabellen aus MS Excel/MS Word bzw. LibreOffice in Wikipedia (oder gibt es das feature schon ?) --Furfur Diskussion 23:54, 19. Sep. 2015 (CEST)
    • bitte auch umgekehrt. --MGChecker – (📞| 📝| Bewertung) 22:20, 20. Sep. 2015 (CEST)
    • Der VE kann inziwschen gut mit Tabellen umgehen. Zumindest unter Linux ist es kein Problem eine Tabelle aus LibreOffice per Copy-n-Paste in den VE zu kopieren (andere Systeme und Programme hab ich nicht getestet). Daher ist das meiner Meinung wohl erledigt. -- Michi 01:39, 21. Sep. 2015 (CEST)
      • @MichaelSchoenitzer: Hmm, da bin ich vielleicht technisch nicht auf dem neuesten Stand, was meinst Du mit „VE“? --Furfur Diskussion 22:10, 26. Sep. 2015 (CEST)
        • Den Visual Editor. -- Michi 22:18, 26. Sep. 2015 (CEST)
    @Furfur, MGChecker, MichaelSchoenitzer: Den einen Weg gibt es schon so halb, siehe die Links oben. —Martin (WMDE) (Disk.) 17:10, 12. Okt. 2015 (CEST)
Unterstützung
  1. ProDerHexer (Disk.Bew.) 20:54, 23. Okt. 2015 (CEST)
  2. Pro (bitte auch ohne VE) --MachtaUnix (Diskussion) 21:25, 25. Okt. 2015 (CET)

Erweiterung der Einzelnachweise, so dass bei verschiedenen Seiten desselben Werks nicht immer das gesamte Werk angegeben werden muss[Quelltext bearbeiten]

Beschreibung

Aufwand und Realisierungsmöglichkeiten

  • Use Case 1: Referenzierung verschiedener Seiten eines Werkes in einem Artikel
    • Erweiterung der <ref>-Extension um einen „page“-Parameter
    • 3 Sprints 100 %
  • Use Case 2: Referenzierung des selben Werkes in vielen Artikeln
    • Einbindung von Informationen über Werke, die als Wikidata-Items verwaltet werden.
    • Wird möglich, sobald beliebige Wikidata-Items auf beliebigen Seiten zugänglich sind.
    • Infos – PerfektesChaos 10:28, 5. Mär. 2014 (CET):
      1. Vorlage:BibRecord usw. machen dies bereits seit langer Zeit – eine Liste der verfügbaren Titel.
      2. Wikidata gilt als weniger geeignet, weil Details zu den Datenelementen sprachbezogen sind – unsere WP:ZR sind nicht kompatibel zu den angloamerikanischen Formaten; etwa Personennamen, deren Aufzählung, Verlagsangabe, komplexere Seitenzahlen, Kapitel.
  • Grundlagen werden im Rahmen von Wikidata in jedem Fall geschaffen; zusätzliche Lua-Integration denkbar
  • Gibt es schon als Vorlage: Vorlage:rp
Diskussion
  • Da arbeitet die WMDE eh schon dran, siehe letzte Umfrage, ist dort unter nächste Aufgaben gelistet. Ob das hier in die Top-Wünsche kommt oder nicht ist egal, es wird ohnehin umgesetzt. --MGChecker – (📞| 📝| Bewertung) 15:44, 14. Okt. 2015 (CEST)
  • Aber nicht vergessen, dass man auch leicht unbrauchbare Quellen komplett entfernen können muss - egal wie viele Einzelnachweise daran hängen. --Gamma γ 19:22, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro -- Michi 21:34, 13. Okt. 2015 (CEST)
  2. Pro --Gnom (Diskussion) 11:05, 14. Okt. 2015 (CEST)
  3. Pro Yellowcard (D.) 12:34, 14. Okt. 2015 (CEST)
  4. Pro --nenntmichruhigip (Diskussion) 13:13, 14. Okt. 2015 (CEST)
  5. Pro --Meloe (Diskussion) 14:07, 14. Okt. 2015 (CEST)
  6. Pro --Distelfinck (Diskussion) 14:29, 14. Okt. 2015 (CEST)
  7. Pro kann nicht schaden, nochmal daran zu erinnern – Giftpflanze 17:28, 14. Okt. 2015 (CEST)
  8. Pro -- Icone chateau renaissance 02.svg Sir Gawain Disk. 23:34, 14. Okt. 2015 (CEST)
  9. Pro klingt praktisch. -- Generator (Diskussion) 14:47, 19. Okt. 2015 (CEST)
  10. Pro --jcornelius Benutzer Diskussion:Jcornelius 08:58, 23. Okt. 2015 (CEST)
  11. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  12. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  13. Pro --  TRN 3.svg hugarheimur 19:41, 23. Okt. 2015 (CEST)
  14. ProDerHexer (Disk.Bew.) 20:57, 23. Okt. 2015 (CEST)
  15. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  16. Pro --Chewbacca2205 (D) 22:19, 24. Okt. 2015 (CEST)
  17. Pro --Avron (Diskussion) 19:22, 25. Okt. 2015 (CET)

Zwischenspeichern von Änderungen[Quelltext bearbeiten]

Beschreibung

Die Möglichkeit, Artikelentwürfe ohne Abspeichern als neue Version zwischenspeichern zu können, ist gewünscht.

Diskussion
  • Möglichkeit Artikelbearbeitungen zwischenzuspeichern (mw:Extension:Drafts) --Schnark 11:41, 19. Sep. 2015 (CEST)
    • Ich glaube da hat jemand was missverstanden. Das hat nichts mit einem Namensraum zu tun,. Und da ich mutig bin… --MGChecker – (📞| 📝| Bewertung) 20:13, 13. Okt. 2015 (CEST)

Gegenvorschlag: Das Bearbeitungsfeld sollte, solange der Tab offen ist, den Text behalten. Dann könnte man einen Entwurf aufbewahren indem man den Tab offenlässt. --Distelfinck (Diskussion) 14:27, 14. Okt. 2015 (CEST)

Es gibt AddOns wie Lazarus, mit dem man Formulardaten automatisch zwischenspeichern kann. —DerHexer (Disk.Bew.) 23:06, 23. Okt. 2015 (CEST)
  • Eigenreklame: autoBackup@PerfektesChaos merkt sich konfigurierbar zu den zehn letzten bearbeiteten Seiten die jeweils letzten zehn wesentlichen Zwischenstände; auch manuell auszulösen.
    Ansonsten fehlt dem Wunsch die Spezifikation, was wo für welche anderen Benutzer sichtbar oder nicht zu welchem Zweck auf wie lange Zeit gespeichert werden soll. Ich kann mir jederzeit auf meiner Festplatte Textversionen in kleine Textdateien ablegen und mache das auch regelmäßig, und man kann Benutzerunterseiten anlegen.
    --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro --Z. (Diskussion) 09:23, 14. Okt. 2015 (CEST)
  2. Pro --Arnd (Diskussion) 17:13, 14. Okt. 2015 (CEST)
  3. Pro -- Icone chateau renaissance 02.svg Sir Gawain Disk. 23:39, 14. Okt. 2015 (CEST)
  4. Pro --Emergency doc (D) 22:20, 15. Okt. 2015 (CEST)

Versionsgeschichte und Diffs[Quelltext bearbeiten]

Änderungen im Text bei Abschnittsverschiebung anzeigen[Quelltext bearbeiten]

Beschreibung

Beim Verschieben einzelner Abschnitte sollen ähnlich wie in mw:User:PerfektesChaos/WikidiffLX die darin gegenüber der Ausgangsversion geänderten Zeichen farblich vom Hinweis auf die Verschiebung des gesamten Absatzes getrennt werden.

Diskussion
  • Besserer Versionsvergleich: Wurden Abschnitte nur vertauscht, ohne dass sich ein Zeichen geändert hat, sollte man dies erkennen können. Bei Änderungen die nur ein Zeichen betreffen könnte man die 3 Zeichen rechts und links davon auch anders einfärben, damit man die Änderung schneller findet. --Carlos-X 11:54, 19. Sep. 2015 (CEST)
  • Besserer Versionsvergleich: Wenn ein Absatz gelöscht wird und gleichzeitig Änderungen am Text vorgenommen werden, kann man diese nicht mehr erkennen. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 16:18, 25. Sep. 2015 (CEST)
    @Queryzo: Ich verstehe nicht genau, was du meinst. Kannst du ein Beispiel-Diff verlinken?--Cirdan ± 12:01, 3. Okt. 2015 (CEST)
    @Cirdan: Link – Durch Einfügen einer neuen Zeile erkennt er nicht, dass in den anderen Zeilen nur geringfügige Änderungen vorgenommen wurden. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 11:26, 14. Okt. 2015 (CEST)
    Klingt nach Umsetzung von WikidiffLX und der vorhandenen Implementierung. --PerfektesChaos 13:32, 4. Okt. 2015 (CEST)
Unterstützung
  1. Pro --Kurt Jansson (Diskussion) 01:03, 13. Okt. 2015 (CEST)
  2. Pro --DWI (Diskussion) 21:16, 13. Okt. 2015 (CEST)
  3. Pro«« Man77 »» Ḏū hāḏā t-tawfīʿ 22:36, 13. Okt. 2015 (CEST)
  4. Pro --Gnom (Diskussion) 11:02, 14. Okt. 2015 (CEST)
  5. Pro --Distelfinck (Diskussion) 13:47, 14. Okt. 2015 (CEST)
  6. Pro --nenntmichruhigip (Diskussion) 14:37, 14. Okt. 2015 (CEST)
  7. Pro --Trustable (Diskussion) 14:51, 14. Okt. 2015 (CEST)
  8. Pro --MGChecker – (📞| 📝| Bewertung) 15:48, 14. Okt. 2015 (CEST)
  9. Pro dringend notwendig – Giftpflanze 17:21, 14. Okt. 2015 (CEST)
  10. Pro -- Icone chateau renaissance 02.svg Sir Gawain Disk. 23:39, 14. Okt. 2015 (CEST)
  11. Pro Diffs lesen ist... da verbesserungsfähig --Atlasowa (Diskussion) 13:34, 15. Okt. 2015 (CEST)
  12. Pro --Carlos-X 15:45, 15. Okt. 2015 (CEST)
  13. Pro --FeddaHeiko 23:50, 15. Okt. 2015 (CEST)
  14. Pro --Rainald62 (Diskussion) 00:25, 16. Okt. 2015 (CEST)
  15. Pro -- hgzh 15:11, 16. Okt. 2015 (CEST)
  16. Pro --RookJameson (Diskussion) 00:09, 17. Okt. 2015 (CEST)
  17. Pro --Daniel749 Disk. (STWPST) 13:02, 17. Okt. 2015 (CEST)
  18. Pro --Aineias © 21:10, 17. Okt. 2015 (CEST)
  19. Pro -- Generator (Diskussion) 14:48, 19. Okt. 2015 (CEST)
  20. Pro --dcb 11:27, 20. Okt. 2015 (CEST)
  21. Pro -- Density Disk. 17:40, 20. Okt. 2015 (CEST)
  22. Pro --WolfgangLiebig • Disk. 20:05, 21. Okt. 2015 (CEST)
  23. Pro --DerPetzi (Diskussion) 12:37, 22. Okt. 2015 (CEST)
  24. Pro --Varina (Diskussion) 09:34, 23. Okt. 2015 (CEST)
  25. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  26. Pro --Frank C. Müller (Diskussion) 15:52, 23. Okt. 2015 (CEST)
  27. ProDerHexer (Disk.Bew.) 23:54, 23. Okt. 2015 (CEST)
  28. Pro --Furfur Diskussion 21:24, 24. Okt. 2015 (CEST)
  29. Pro--Avron (Diskussion) 19:23, 25. Okt. 2015 (CET)
  30. Pro sollte ein- und ausschaltbar werden, --MachtaUnix (Diskussion) 21:34, 25. Okt. 2015 (CET)

Zusammenklappen mehrerer Änderungen eines Benutzers hintereinander[Quelltext bearbeiten]

Beschreibung

Mehrere direkt aufeinanderfolgende Änderungen einer Benutzerin oder eines Benutzers zusammenklappbar machen und die Byteanzeige dementsprechend anpassen.

Diskussion
  • Zusammengeklappte Versionsgeschichten. Wenn ein Benutzer diverse Edits durchführte, werden die zusammengeklappt dargestellt. Das bedeutet, wenn ich 10 mal nacheinander editiere, erscheine ich da nur einmal so " Micha 10 Bearbeitungen 10:40, 23. Sep. 2015 - 12:56, 23. Sep. 2015 [+]". Durch klick auf [+] erscheinen dann alle Versionen. Das würde die Übersichtlichkeit der Versionsgeschichte stark erhöhen. --Micha 14:15, 23. Sep. 2015 (CEST)
    Könnte man dadurch nicht Vandalismus leichter übersehen? Bzw. Das Byte-Delta müsste dann doch zumindest aufsummiert werden über alle 10 Bearbeitungen... --FeddaHeiko 22:06, 28. Sep. 2015 (CEST)
    Diese Funktion gibt es bereits für die Beobachtungsliste und Letzte Änderungen. Dort ist meiner Meinung nach der entscheidende Vorteil, dass es die Möglichkeit gibt, direkt den Diff aller Änderungen zusammengefasst aufzurufen. Wenn es „zwischendurch“ Vandalismus gibt, ist das meiner Meinung nach kein Problem. Auch jetzt wird einfach nur zurückgesetzt (der Vandalismus bleibt also als Altversion erhalten) und nur in seltenen Fällen eine Version gelöscht, wobei diese Fälle in erster Linie über Beboachtungslisten und Letzte Änderungen erkannt werden und nicht durch Studium der Versionsgeschichte. Demnach scheint die Zusammenklapp-Funktion kein Hindernis bei der Vandalismusbekämpfung zu sein. Ich würde annehmen, dass es technisch nicht allzu viel Aufwand ist, diese Funktionalität als optionale Einstellung auch für Versionsgeschichten anzubieten.--Cirdan ± 11:58, 3. Okt. 2015 (CEST)
    Das ist nicht ganz richtig. In diesem Fall werden nämlich die Bearbeitungen eines Tages zusammengefasst, uns nicht die eines Nutzers. Das dürfte aber auf ähnliche Art und Weise realisierbar sein. --MGChecker – (📞| 📝| Bewertung) 21:57, 3. Okt. 2015 (CEST)
    In der VG muss jeder Edit mit eigenem BK einzeln nachvollziehbar sein; siehe #Kurzzeitig nachträglich bearbeitbare Zusammenfassungszeile. .
    Man wird um das Aufsuchen der normalen VG nicht herumkommen, wenn an der Seite mehrere Benutzer dran waren.
    Die oben genannte „Seitenbezogene Gruppierung“ fasst bereits heute die Gesamtänderung zusammen und lässt sich aufklappen. Wenn an dem Tag mehrere Benutzer dran waren, werden deren Namen aufgezählt. Das könnte man innrhalb dieser Liste durch mehrere Unterklappebenen erweitern, wenn die Abfolge war: Benutzer A, B, A, A, B, A, A, B, B, C, A – ob das dann aber so viel durchschaubarer wird? In anderen Fällen ärgerst du dich dann, dass du die Z+Q zwischendurch nicht mitbekommen hattest.
    resultListSort@PerfektesChaos sortiert innerhalb von einzelnen Tagen nach Seitentitel oder Benutzername oder Z+Q.
    Im Zweifelsfall das aufeinanderfolgende-Benutzer-Zusammenfass-Feature besser in die VG einbauen als in die Beo, dann haben alle was davon.
    --PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro --Arnd (Diskussion) 17:15, 14. Okt. 2015 (CEST)
  2. Pro -- MetroBus.svgetrophil44 15:27, 23. Okt. 2015 (CEST)
  3. ProDerHexer (Disk.Bew.) 23:54, 23. Okt. 2015 (CEST)

Differenzierung, ob im Diff alle oder nur die aktuelle Version gesichtet werden soll[Quelltext bearbeiten]

Beschreibung

In einem Diff über mehrere Versionen soll es zwei Sichten-Buttons geben, einen für die Sichtung nur der aktuellen, einen für alle Versionen.

Diskussion
  • Möglichkeit eine Folgeänderung (zB Typo) zu sichten, ohne dabei ältere Änderungen (zB inhaltliche Änderungen) mitsichten zu müssen … «« Man77 »» Ḏū hāḏā t-tawfīʿ 11:46, 25. Sep. 2015 (CEST)
    • Das widerspricht dem Prinzip der gesichteten Versionen. Bei den gesichteten Versionen wird immer eine Version für Vandalismusfrei gehalten, nicht einzelne Änderungen. Nur weil man die Version von C sichtet, heißt es nicht, das A und B schlechte Änderungen vorher gemacht haben. Anders gesagt: Die gesichteten Versionen stehten für einen "guten" Zeitpunkt in der Vergangenheit. Dieser Zeitpunkt wird mit jeder Sichtung auf die neuste Version "angehoben". Der Umherirrende 17:08, 25. Sep. 2015 (CEST)
      • Nicht unbedingt: Wenn es drei ungesichtete Versionen A, B, und C gibt, und jemand schaut den Edit B->C and und markiert den Edit als gesichtet, dann ist es eigentlich Falsch, dass A und B dadurch auch "sichtbar" werden. Man dürfte anhand eines Diffs nie sichten, bzw muss immer ein Diff sichen, das alle ungesichteten Versionen abdeckt. Sinnvoller wäre es, wenn C erst "sichtbar" wird, wenn alls vorherigen Versionen gesichtet sind. Und wenn ich in deiner Diff-Ansicht auf "Sichten" klicke, sollte sich das auf alle Versionen beziehen, die im Diff angezeigt sind. Das ist anders, als das Sichten momentan funktioniert, widerspricht aber mMn nicht der Idee der gesichteten Versionen. -- Daniel Kinzler (WMDE) (Diskussion) 11:28, 30. Sep. 2015 (CEST)
        • In einem Versionsunterschied zwischen zwei Versionen die beide auf Sichtung warten (B -> C) gibt es kein Sichtungsbutton. Es gibt ein Hinweis, das man sich alle ausstehenden Bearbeitungen anschauen kann. Es ist also (über die GUI) nicht möglich, die Bearbeitung B->C zu sichten, solange N->A und A->B nicht gesichtet sind. Die Sichtung auf einen Stapel zu legen und automatisch C sichtbar machen, wenn N->B gesichtet wurde, dürfte technisch schwierig sein und die Sache auch für den Benutzern nicht umbedingt einfacher verständlich machen. Daher widerspricht es dem aktuellen Konzept der Gesichteten Versionen (Es heißt ja nicht gesichtete Bearbeitungen, sondern Versionen). Der Umherirrende 18:16, 30. Sep. 2015 (CEST)
          • Schon klar, dass das Momentan nicht geht. Ich hab nur laut gedacht, dass es eigentlich sinnvoller wäre, Bearbeitungen zu sichen, statt Versionen. Aber das wäre schon ein recht großer Umbau.... -- Daniel Kinzler (WMDE) (Diskussion) 22:55, 3. Okt. 2015 (CEST)
  • @Man77, Umherirrender, Daniel Kinzler (WMDE): So in Ordnung für euch? Wobei auch ich mich eher für die Überprüfung jeder einzelnen ungesichteten Version aussprechen möchte. —Martin (WMDE) (Disk.) 16:16, 9. Okt. 2015 (CEST)
  • Nach der Sichtung ist die jüngste gesichtete Version diejenige, die angezeigt werden soll, und fertig. Was mit allen Änderungen davor war und ob diese einzeln gesichtet wurden oder nicht, ist Banane.
  • Ungesichtetlassen von vorherigen Versionen und die spätere zu sichten wäre wirkungslos, weil es um die Anzeige für die normalen Leser geht, und die sollen dem Vorschlag gemäß die noch fraglichen früheren inhaltlichen Änderungen nicht zu sehen bekommen, und damit ist es auch völlig egal, ob im noch unbewerteten inhaltlichen Text später mal ein Tippfehler korrekt beseitigt wurde.
  • Der Vorschlag liefe darauf hinaus, dass es neben der Sichtung mit dem Ziel der jüngsten vorzeigbaren Version eine parallele und davon unabhängige Bewertung jedes Edits (von Unbekannten) geben solle, was aber auf die Sichtung und die angezeigte Version erstmal keinen Einfluss hätte; es sei denn, alle Edits seit der letzten gesichteten Version wären positiv bewertet worden. Das ließe sich aber pfiffig zur Manipulation durch Vorwärts- und Rückwärtsbearbeitungen ausnutzen, so dass zum Schluss die Gesamtaussage falsch wird, während jeder einzelne Edit in seinem Kontext als richtig erschien, und mit dem nachträglichen Abhaken der früheren offenen Version die späteren Änderungen ohne erneute Prüfung im Zusammenhang sichtbar werden.
--PerfektesChaos 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Hier mit Pro abstimmen!

Anzeige aller Bearbeitungskommentare im Diff[Quelltext bearbeiten]

Beschreibung

Beim Sichten im Diff einen Ausschnitt der Versionsgeschichte, insbesondere die Bearbeitungskommentare, anzeigen.

Diskussion
  • Beim Sichten sollten die Bearbeitungskommentare der dazwischenliegenden Versionen angezeigt werden, am besten in Form eines Mini-Versionshistorie-Ausschnitts (jeweils mit Benutzername + Byte-Delta + Edit-Kommentar); ggf. optional einstellbar --FeddaHeiko 22:06, 28. Sep. 2015 (CEST)
  • Kann alternativ durch ein routinemäßig programmiertes Gadget gelöst werden; nichts Aufregendes.
    Anfangs- und Endnummer der Versionen sind bekannt; damit kann auf Sonderwunsch und Buttonklick nachträglich per API eine Mini-Versionsgeschichte abgerufen und als sortierbare Tabelle in den Seitenkopf eingefügt werden; mit benutzerkonfiguriert formatiertem Zeitstempel, einzelnen Difflinks, Direktversionslinks, Benutzername verlinkt, Bearbeitungskommentar, verlinktem Abschnitt.
    Es könnte aber ein Difflink über Hunderte oder Tausende von Versionen sein; irgendwo bei 20–50 müsste ein Limit eingebaut sein; zeige nur die ersten paar Dutzend.
    Ob es eine oder mehrere Versionen dazwischen gibt, ist bereits in der Seite bekannt.
    Der Weg über eine weltweite Änderung im PHP-Bereich stünde auch offen; ist aber mühsamer durchzusetzen. Dann würde die Tabelle immer auf jeder Diffpage geliefert werden und Netzwerktraffic und Aufbauzeit verursachen. Soll sie aber nur in Einzelfällen nachgefordert werden, ist JS besser geeignet.
    --PerfektesChaos 13:27, 22. Okt. 2015 (CEST)
Unterstützung
  1. Pro --Kurt Jansson (Diskussion) 01:03, 13. Okt. 2015 (CEST)
  2. Pro MisterSynergy (Diskussion) 10:05, 13. Okt. 2015 (CEST)
  3. Pro -- ɦeph 21:40, 13. Okt. 2015 (CEST)
  4. Pro --Orci Disk 09:39, 14. Okt. 2015 (CEST)
  5. Pro --Trustable (Diskussion) 14:51, 14. Okt. 2015 (CEST)
  6. Pro --Hareinhardt (Diskussion) 22:58, 14. Okt. 2015 (CEST)
  7. Pro --Leyo 00:13, 15. Okt. 2015 (CEST)
  8. Pro --FeddaHeiko 23:51, 15. Okt. 2015 (CEST)
  9. Pro --RookJameson (Diskussion) 00:09, 17. Okt. 2015 (CEST)
  10. Pro --Daniel749 Disk. (STWPST) 13:02, 17. Okt. 2015 (CEST)
  11. Pro --Aineias © 21:11, 17. Okt. 2015 (CEST)
  12. Pro --dcb 15:20, 19. Okt. 2015 (CEST)
  13. Pro --WolfgangLiebig • Disk. 20:07, 21. Okt. 2015 (CEST)
  14. Pro --DerPetzi (Diskussion) 12:38, 22. Okt. 2015 (CEST)
  15. Pro --Pelz (Diskussion) 21:45, 22. Okt. 2015 (CEST)
  16. ProDerHexer (Disk.Bew.) 23:55, 23. Okt. 2015 (CEST)
  17. Pro --Mabschaaf 11:29, 24. Okt. 2015 (CEST)
  18. Pro --MachtaUnix (Diskussion) 21:41, 25. Okt. 2015 (CET)

Blame[Quelltext bearbeiten]

Beschreibung

Es gibt in TortoiseSVN ein Tool das nennt sich "Blame". Siehe hier Damit kann man sich anzeigen lassen wer der letzte Bearbeiter eines Textteils war. Man sieht den Text wie er im Artikel aussieht und mittels Mouseover kann man sich Infos anzeigen lassen (letzter Bearbeiter, Versionskommentar, Uhrzeit usw.) Sehr Praktisch wenn man wissen will wer was verbrochen hat (deshalb heißt das Ding auch "Blame").

Diskussion


Unterstützung
  1. Pro -- Generator (Diskussion) 14:56, 19. Okt. 2015 (CEST)
  2. --

Artikel: Sonstiges[Quelltext bearbeiten]

Automatisches Erstellen von Begriffsklärungsseiten[Quelltext bearbeiten]

Beschreibung

Entwicklung eines Systems von Metadaten, mit dem Begriffsklärungsseiten automatisch erstellt werden könnten.

Diskussion
  • Automatisiertes anlegen von BKLs: Ähnlich wie bei Wikidata oder sogar mit Hilfe von Wikidata könnte man weitere Metainformationen zu Artikeln speichern. Diese weiteren Informationen würden Alternativnamen und eine Kurzbeschreibung des Artikels umfassen, aus diesen würde die Wiki-Software dann automatisch BKLs generieren. Dies würde meiner Auffassung nach viel Pflegearbeit und Streit bei den BKLs reduzieren. Sind nicht 10% aller Artikel BKLs?--Christian1985 (Disk) 15:57, 29. Sep. 2015 (CEST)
    • Oh ja, einen (besser halbautomatischen) BKL-Assistenten. Der sollte nicht-verBKLte Klammerlemmas sammeln, BKL-Baustein setzen, und ähnlich der Verlinkungsfunktion im VE eine anpassbare Kurzbeschreibung liefern.--Hareinhardt (Diskussion) 00:11, 30. Sep. 2015 (CEST)
    • @Hareinhardt: Es sollte leicht sein, einen Bot zu schreiben, der basierend auf den Informationen in Wikidata BKLs anlegt und pflegt. Wäre das eine Lösung? Das direkt in mediaWiki zu implementieren würde es schwer machen, die BKLs je nach Wiki anzupassen (Vorlagen, Überschriften, Kategorien, etc). Alternativ könnte man eine Spezialseite machen, die alle Seiten auflistet, die den Suchbegriff als Namen (Label) oder Alternativnamen (Alias) auf Wikidata haben. -- Daniel Kinzler (WMDE) (Diskussion) 10:39, 30. Sep. 2015 (CEST)
      • Also mir wäre es am liebsten, wenn man nur Wikidata pflegen müsste und der Rest automatisch verliefe. Dein Vorschlag Daniel Kinzler (WMDE), finde ich, geht aber in die richtige Richtung und wäre eine deutliche Verbesserung. Viele Grüße--Christian1985 (Disk) 11:39, 30. Sep. 2015 (CEST)
    BKS sind hochgradig sprachabhängig, hängen von der Artikelstruktur des Projektes ab, und die Interpretation, welche Bedeutung in welchem Kontext gemeint ist, kann nur im Einzelfall geklärt werden. Damit hätte jede Sprachversion nur ihre eigene BKS nach Wikidata ausgelagert, die aber nicht mehrsprachig kompatibel sind, weil Begriffe in unterschiedlichen Sprachen halt unterschiedliche Bedeutungsfelder haben, und die Zielartikel in jedem Projekt anders strukturiert sind. „Streitigkeiten“ werden dann von internationalen statt lokalen Admins auf Englisch entschieden. Mit riesigem Aufwand die Seitenpflege extrem verkompliziert, keinerlei Nutzen, und vor Automatismen und Bots in diesem Bereich kann ich nur warnen. Die Vorstellung, man könnte enzyklopädischen Gehirnschmalz durch die extrem schlicht strukturierten Bot-Algorithmen ersetzen, ist freundlich gesagt naiv. --PerfektesChaos 14:05, 4. Okt. 2015 (CEST)
Unterstützung
  1. Hier mit Pro abstimmen!

Seiteninformation um verwendete URLs ergänzen[Quelltext bearbeiten]

Beschreibung

Die Seite „Informationen zu Seite X“ soll um eine Auflistung aller auf der Seite verwendeter URLs ergänzt werden.

Diskussion
  • Einfügen eines Felds el_from_rev_id in die Tabelle externallinks. Danach könnte man auf "Seiten­informationen" die auf der Seite verwendeten URLs samt Zeitstempel der Einfügung und einfügenden Benutzer anzeigen. Mit Hilfe von Diffs kann man dann auch erkennen, was mit der URL belegt werden sollte. Äußerst hilfreich wäre so eine Funktion um Spammer schneller aufzudecken. Frohes Schaffen — Boshomi ☕⌨☺ Defekte URLs - Hilfe gesucht  14:01, 21. Sep. 2015 (CEST)
    • Könnte problematisch werden, wenn Links durch Vandalismus entfernt und anschließend eingefügt wurden, weil dann die rev_id zwischenzeitlich gelöscht und die vom Rollback wieder eingefügt wird. Der Umherirrende 17:08, 25. Sep. 2015 (CEST)
      • Mir wäre es schon recht, wenn da vorläufig eine einfache Lösung umgesetzt wird. Perfekte Lösungen, die etwa alle gelöschten Einträge der Tabelle durch Trigger in "gelöscht-"Tabellen oder Tabellenpartitionen eintragen, kann man später immer noch angehen. Aber es ist schon recht nützlich, wenn man solche Problemstellen kennt, um keine Pfuschlösung zu bauen, die sich später nicht gut reparieren lässt. Frohes Schaffen — Boshomi ☕⌨☺ Defekte URLs - Hilfe gesucht  09:45, 3. Okt. 2015 (CEST)
  • Eine weltweite serverseitige Lösung für alle Benutzer wird es absehbar nicht geben. Nur ein begrenzter Personenkreis interessiert sich gelegentlich bei einzelnen Seiten für diese Liste. Das Datenvolumen und die dargestellte Tabelle kann immens werden; Hunderte von URL, jede 1000 Zeichen lang …
  • Ein JS-Gadget ist routinemäßig ohne Gehirnschmalz für eingearbeitete Programmierer produzierbar. Interessierte können es sich dann aktivieren.
  • Es würden zunächst nur ein Button (oder mehrere; weitere Funktionen wie etwa die Überprüfung der zugeordneten Seite auf Vorhandensein aller Anker für jedes seitenrelative Link mögen hinzukommen) auf jeder Info-Seite angezeigt. Nach Klick werden dann alle URL per API abgerufen. Darstellung in einer ul-Liste, statt der ganzen URL nur die Domain sichtbar; Pfad&query visibility-unsichtbar, einzelne URL über Tooltip sichtbar, mit C&P usw. kopierbar.
    • Code-Service:
<li><a href="http://example.org/very/long/path">example.org</a> <div style="height: 0; overflow:hidden; width:0;">http://example.org/very/long/path</div></li>
--PerfektesChaos 21:55, 24. Okt. 2015 (CEST) erg. 11:19, 25. Okt. 2015 (CET)
Unterstützung
  1. Pro -- hgzh 15:12, 16. Okt. 2015 (CEST)
  2. ProDerHexer (Disk.Bew.) 23:55, 23. Okt. 2015 (CEST)
  3. Pro --Bwbuz (Diskussion) 17:17, 24. Okt. 2015 (CEST)

Rechtschreib-Helferlein auch für den BNR[Quelltext bearbeiten]

Beschreibung

Das Rechtschreib-Helferlein für den Benutzernamensraum freischalten.

Diskussion
  • In den Lemmata werden Schreibfehler rot unterlegt angezeigt. Diese hilfreiche Fehleranzeige fehlt bei Bearbeitung von Texten im ANR. Schreibfehler werden damit bisher erst nach Übertragung in AR angezeigt und können erst dann berichtigt werden. --Urdenbacher (Diskussion) 15:57, 4. Okt. 2015 (CEST)
    Es geht wahrscheinich um das Rechtschreib-Helferlein. Das muss für jede Seite erstmal den Server kontaktieren. Das macht es standardmäßig nur im ANR. Hier richtet sich wohl die Frage auf die Entwurfsfassung im BNR. Die hat das Problem, dass auf dem Werkzeug-Server zurzeit nur vorgeprüfte Seiten aus dem ANR liegen, deren Analyse auf Rechtschreibfehler schon zuvor auf Vorrat erfolgte und deren Ergebnis nur noch abgerufen werden muss. Das müsste auf Benutzerseiten ausgedehnt werden. --PerfektesChaos 16:08, 4. Okt. 2015 (CEST)
    Die Prüfung auf Tool Labs erfolgt Live. Eine Änderung ist dort nicht nötig (?page=Benutzer:ABC) sollte jetzt schon funktionieren. Nur das Script hier müsste entsprechend angepasst werden. --APPER\☺☹ 23:02, 13. Okt. 2015 (CEST)
Wie nun angeführt war die fehlende Fehleranzeige im BNR gemeint. --Urdenbacher (Diskussion) 16:51, 4. Okt. 2015 (CEST)
Unterstützung
  1. Pro Geolina mente et malleo 21:38, 13. Okt. 2015 (CEST)
  2. Pro --Emergency doc (D) 22:21, 15. Okt. 2015 (CEST)
  3. Pro --Chewbacca2205 (D) 22:21, 24. Okt. 2015 (CEST)
  4. Pro --Avron (Diskussion) 19:24, 25. Okt. 2015 (CET)
  5. Pro -- Astronaut.svgcommander-pirx (disk beiträge) 11:28, 26. Okt. 2015 (CET)