Wikipedia:Umfragen/Technische Wünsche 2017/Bearbeiten

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Umfrage Technische Wünsche 2017

Rubrik „Bearbeiten“

Lesen  •   Suchen  •   Bearbeiten  •   Wartung  •   Beobachten & Benachrichtigen  •   Soziales  •   Schwesterprojekte  •   Mediendateien  •   Projekte ehrenamtlicher Entwickler  •   Sonstiges

Bitte nicht mehr abstimmen - diese Umfrage ist abgeschlossen. Herzlichen Dank an alle, die Vorschläge eingereicht, abgestimmt und die Umfrage mit fachlichem Rat begleitet haben.

Geschützte Leerzeichen automatisch einsetzen

[Quelltext bearbeiten]
Was ist das Problem?

In einigen Zusammenhängen ist die Verwendung geschützter Leerzeichen gewünscht, um einen Zeilenumbruch zu verhindern. Ein Beispiel (unter anderen) ist das Leerzeichen zwischen einer Maßzahl und der Maßeinheit, also etwa „5 m“. Hier soll kein Umbruch erfolgen, sodass ein geschütztes Leerzeichen gesetzt wird. Problematisch in diesem Zusammenhang sind die folgenden Punkte:

  • Man muss daran denken, dieses geschützte Leerzeichen einzufügen. Neue Benutzer wissen das nicht (und können es auch nicht „einfach so“ wissen), aber auch erfahrene Benutzer vergessen das leicht.
  • Ein geschütztes Leerzeichen einzufügen ist relativ kompliziert. Wenn man es von Hand eintippen will, muss man sich eine kryptische Buchstabenkombination merken (für erfahrene Benutzer kein Problem, aber für Neulinge ein Hindernis), man kann es aus der Sonderzeichenleiste unter dem Bearbeitungsfeld einfügen, was aber den Schreibfluss unterbricht. Im VisualEditor besteht im Augenblick gar keine offensichtliche Möglichkeit, ein geschütztes Leerzeichen einzufügen.
  • Geschützte Leerzeichen machen den Quelltext unübersichtlich. Da stehen dann irgendwelche komischen Buchstaben, Satz- und Sonderzeichen, wo eigentlich nur ein Leerzeichen erwartet wird. Das geschützte Leerzeichen direkt einzugeben, würde das zwar lösen, aber verursacht selbst deutlich mehr Probleme.
  • In vielen Fällen wäre ein geschütztes schmales Leerzeichen besser als ein normalbreites. Das einzugeben ist noch schlimmer.
Wen betrifft das Problem besonders?
  • Neue Benutzer, die nichts über geschützte Leerzeichen wissen
  • Benutzer des VisualEditors, die keine geschützten Leerzeichen eingeben können
Lösungsvorschlag
  • Für das Prozentzeichen (und einige weitere Fälle, die aber nur in französischer Typografie eine Rolle spielen), wird das normale Leerzeichen vom Parser in ein geschütztes umgewandelt. Dieses Verfahren ließe sich prinzipiell erweitern, ist aber auch nicht unproblematisch.
  • Wikipedia:Typografie/Automatische Leerzeichen für einen Überblick
Anmerkungen

Besonders in der deutschsprachigen Wikipedia wird auf saubere Typografie Wert gelegt, sodass WMDE prädestiniert ist dafür, dieses Problem anzugehen.

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch werden künftig hier dokumentiert.

Vorschlagende Person

Schnark 10:27, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Schnark (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 22:10, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro -- Barnos (Post) 08:15, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Z thomas Thomas 11:22, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Gnom (Diskussion) 13:11, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Blik (Diskussion) 16:04, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Andropov (Diskussion) 16:20, 20. Jun. 2017 (CEST) Halte ich für eine wesentliche Erleichterung, weil die händische Eingabe von geschützten Leerzeichen mit kryptischen Zeichenfolgen den Quelltext unlesbar machen können.[Beantworten]
  9. Pro --Abubiju (Diskussion) 17:01, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Urdenbacher (Diskussion) 17:43, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --  Sir Gawain Disk. 18:30, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro Kontrollstelle Kundl 18:32, 20. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Claell (Diskussion) 18:59, 20. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Gelber kaktus (Diskussion) 21:37, 20. Jun. 2017 (CEST)[Beantworten]
  15. Pro Conny 22:16, 20. Jun. 2017 (CEST).[Beantworten]
  16. Pro Hermannh (Diskussion) 22:45, 20. Jun. 2017 (CEST)[Beantworten]
  17. Pro // Martin K. (Diskussion) 22:48, 20. Jun. 2017 (CEST)[Beantworten]
  18. Pro GodeNehler (Diskussion) 05:59, 21. Jun. 2017 (CEST)[Beantworten]
  19. Pro --HerrAdams (D) 09:50, 21. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Orgelputzer (Diskussion) 12:43, 21. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Aarakast (Diskussion) 12:58, 21. Jun. 2017 (CEST)[Beantworten]
  22. Pro --MGChecker – (📞| 📝| Bewertung) 20:02, 21. Jun. 2017 (CEST)[Beantworten]
  23. Pro-- (Diskussion) 06:55, 22. Jun. 2017 (CEST)[Beantworten]
  24. Pro--mauriceKA (Diskussion) 10:45, 22. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Jossi (Diskussion) 12:33, 22. Jun. 2017 (CEST)[Beantworten]
  26. Pro --KorrekTOM (Diskussion) 13:06, 22. Jun. 2017 (CEST)[Beantworten]
  27. Kontra --Boehm (Diskussion) 21:46, 22. Jun. 2017 (CEST) „Geschützte Leerzeichen machen den Quelltext unübersichtlich“. Und automatisch gesetzte unsichtbare Zeichen machen den Quelltext noch unübersichtlicher. Der arme neue Nutzer guckt sich den Quellcode an und weiss nicht, warum an der von ihm angestrebten Stelle der Zeilenumbruch nicht funktioniert.[Beantworten]
  28. Pro --Atamari (Diskussion) 14:20, 23. Jun. 2017 (CEST)[Beantworten]
  29. Pro --ChrissyPlayzZz (Diskussion) 15:24, 23. Jun. 2017 (CEST)[Beantworten]
  30. Pro --Daniel749 Disk. (STWPST) 21:20, 23. Jun. 2017 (CEST)[Beantworten]
  31. Pro --Christian (Diskussion) 19:54, 24. Jun. 2017 (CEST)[Beantworten]
  32. Pro --Mushushu (Diskussion) 16:17, 25. Jun. 2017 (CEST)[Beantworten]
  33. Pro --DomenikaBo (Diskussion) 21:44, 25. Jun. 2017 (CEST)[Beantworten]
  34. Pro --Wrev (Diskussion) 22:58, 25. Jun. 2017 (CEST)[Beantworten]
  35. Pro --Ak ccm (Diskussion) 14:10, 28. Jun. 2017 (CEST)[Beantworten]
  36. Pro --Thomas Obermair 4 (Diskussion) 16:01, 28. Jun. 2017 (CEST)[Beantworten]
  37. Pro --Matthiasb – (CallMyCenter) 23:20, 28. Jun. 2017 (CEST) (Warum eigentlich werden Ziffern nicht generell mit den umgebenden Zeichenketten zusammengehalten; spontan kann ich mir kein Szenario vorstellen, bei dem false positves unerwünschte Ergebnisse lieern würde.)[Beantworten]
  38. Pro Andim (Diskussion) 10:10, 29. Jun. 2017 (CEST)[Beantworten]
  39. Pro bitte, diese nbsp-Flut nervt... -- hgzh 19:24, 29. Jun. 2017 (CEST)[Beantworten]
  40. ProDerHexer (Disk.Bew.) 21:35, 29. Jun. 2017 (CEST)[Beantworten]
  41. ProSDKmac (Disk., Bew.) 02:33, 30. Jun. 2017 (CEST)[Beantworten]
  42. Kontra -gpf- (Diskussion) 09:46, 30. Jun. 2017 (CEST)[Beantworten]
  43. Pro --Anima (Diskussion) 13:56, 30. Jun. 2017 (CEST)[Beantworten]
  44. Pro --Maimaid Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)[Beantworten]
  45. Abwartend --ProloSozz (Diskussion) 23:25, 1. Jul. 2017 (CEST) Muß ein- und ausschaltbar sein resp. eine Ersetzung muß bestätigt werden. Andere Variante wäre eine Art "Text abgrasen"; auch da nur mit jeweiliger Bestätigung.[Beantworten]
  46. Pro --Andrea014 (Diskussion) 17:51, 2. Jul. 2017 (CEST)[Beantworten]
  47. Pro --PAB (Diskussion) 20:37, 2. Jul. 2017 (CEST)[Beantworten]
  48. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.[Beantworten]

Formatierung von Vorlagen im VisualEditor (beispielsweise Vorlage:Personendaten den üblichen Konventionen entsprechend ohne Leerzeichen)

[Quelltext bearbeiten]
Was ist das Problem?

Der VisualEditor kennt im Augenblick zwei verschiedene Formatierungen für Vorlagen: Inline-Vorlagen werden ohne Leerzeichen und Zeilenumbrüche gesetzt, Block-Vorlagen mit einem Parameter pro Zeile und je einem Leerzeichen vor und nach der Gleichheitszeichen.

Das Problem ist, dass in der Praxis weitere Formate gewünscht sind, etwa mit Leerzeichen ausgerichtete Gleichheitszeichen in Infoboxen oder gar keine Leerzeichen in Personendaten.

Dies ist im VisualEditor im Augenblick nicht möglich, sodass eingefügte Vorlagen nicht in allen Fällen wie gewünscht formatiert werden und damit entweder zu Unmut oder zu Mehrarbeit bei nachfolgenden Quelltext-Bearbeitern führen.

Wen betrifft das Problem besonders?
  • Benutzer, die Artikel im Quelltext bearbeiten, und dabei Vorlagen in üblicher Formatierung vorfinden möchten
  • Benutzer, die den VisualEditor verwenden, und Vorlagen in üblicher Formatierung einfügen möchten
Lösungsvorschlag

Mit phab:T138492 existiert der Wunsch bereits in Phabricator, und ist sogar schon zur Hälfte umgesetzt. Aber die andere Hälfte steht noch aus, und die Entwicklung scheint gerade zu stagnieren. Es wäre schön, wenn die Implementierung diese Funktion erfolgreich abgeschlossen werden könnte.

Vorschlagende Person

Schnark 10:41, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Schnark (Einreichende Person)
  2. Pro --HerrAdams (D) 09:51, 21. Jun. 2017 (CEST)[Beantworten]
  3. Pro --MGChecker – (📞| 📝| Bewertung) 20:18, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:02, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro Caution: MMn ist das Verhalten des VE bei Inline-Vorlagen generell falsch. Er entfernt Leerzeichen auch vor der Pipe. Aus Gründen der Lesbarkeit und der Ansteuerung mit CTRL + Pfeil wäre es besser daß vor einer Pipe IMMMER ein Leerzeichen steht. In tabellenenähnlichen Vorlagen, z.B. Vorlage:Infobox Ort im Vereinigten Königreich sollten Leerzeichen aber gar nicht entfernt werden. --Matthiasb – (CallMyCenter) 23:28, 28. Jun. 2017 (CEST)[Beantworten]
  6. Pro Andim (Diskussion) 10:09, 29. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.[Beantworten]

Unterschrift bei Bausteinen

[Quelltext bearbeiten]
Was ist das Problem?

Früher konnte man beim Setzen des Inuse-Bausteines ein Icon für die Unterschrift anklicken. Das Icon wurde entfernt, so dass mehrere Eingaben notwendig geworden sind. https://phabricator.wikimedia.org/T145619 Ich meine den Unterschrifts- und Zeitstempel in der Bearbeitenleiste.

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Das Icon wieder in die Bearbeitungsleiste setzen

Vorschlagende Person

Karl-Heinz (Diskussion) 13:19, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Papa1234 (Einreichende Person)
  2. Pro --FNDE 16:01, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Zabia (Diskussion) 17:03, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Claell (Diskussion) 19:01, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:02, 28. Jun. 2017 (CEST)[Beantworten]
  6. Pro--DaubiKo (Diskussion) 17:53, 30. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Maimaid Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --ProloSozz (Diskussion) 23:27, 1. Jul. 2017 (CEST)[Beantworten]

Automatische Umwandlung eingegebener geschützter Leerzeichen und bedingter Trennstriche in HTML-Entities

[Quelltext bearbeiten]
Was ist das Problem?

Laut Konvention sind geschützte Leerzeichen und bedingte Trennstriche im Wikipedia-Quelltext durch die HTML-Entities   bzw. ­ darzustellen. Die entsprechenden Unicode-Zeichen U+00A0 no-break space bzw. U+00AD soft hyphen sollen nicht verwendet werden: Sie funktionieren zwar in deletztendlichen Textdarstellung genauso, sind aber im Quelltext unsichtbar bzw. nicht zu identifizieren.

Die deutsche T2-Standardtastatur hat die genannten Unicode-Zeichen U+00A0 und U+00AD als Eingabezeichen. Es ist möglich, dass im Rahmen der aktuellen Fortschreibung der Standards DIN 5008 und DIN 2137 diese Eingabemöglichkeiten weitverbreitet in Gebrauch kommen werden.

Anwender, die diesen Standards folgen, werden somit „unsichtbare“ Zeichen in den Quelltext einfügen – es ist ja standardkonform und funktioniert auch wie gewünscht. Stattdessen daran zu denken, statt dieser Zeichen die HTML-Entities einzufügen, erscheint dann als unnützes Hindernis zum flüssigen Arbeiten.

Ergänzt 1. Juni 2017 nach Hinweisen in der Diskussion: Die neueren deutschen Standards beschreiben auch die direkte Eingabe des schmalen geschützten Leerzeichens U+202F narrow no-break space, für das sich das Problem in gleicher Weise stellt.

Wen betrifft das Problem besonders?

Jeden, der mit Tastaturen gemäß neueren deutschen Standards arbeitet.

Lösungsvorschlag

Beim Abspeichern eines Quelltextes werden alle enthaltenen U+00A0 und U+00AD automatisch in die HTML-Entities   bzw. ­ umgewandelt, sodass sie beim nächsten Aufruf des Quelltextes als solche sichtbar sind. Damit ist das Unsichtbarkeitsproblem gelöst, und nach außen erscheint der Text unverändert.

Ergänzt 1. Juni 2017 nach Hinweisen in der Diskussion: Für das schmale geschützte Leerzeichen U+202F narrow no-break space gibt es standardmäßig keine benannte HTML-Entity, standardmäßig wäre   oder   zu schreiben. Es ist jedoch möglich (siehe Beitrag von Schnark vom 30. Mai 10:47 in der Diskussion), eine nur in MediaWiki funktionierende benannte Entität &nnbsp; zu definieren (Benennung konform zur in der Unicode-Dokumentation verwendeten Abkürzung NNBSP) und beim Abspeichern des Quelltextes enthaltene schmale geschützte Leerzeichen durch diese zu ersetzen.

Anmerkungen

Überarbeitet 1. Juni 2017 nach Hinweisen in der Diskussion: Hier wird als technischer Wunsch die Behandlung tatsächlich eingegebener Zeichen vorgeschlagen. Inwieweit und wo die Eingabe solcher Zeichen sinnvoll, erforderlich, erwünscht, zweckmäßig, tolerierbar oder unerwünscht ist, kann Gegenstand einer anderswo geführten Diskussion (z.B. einer Richtlinienfestlegung) sein.

Vorschlagende Person

Karl432 (Diskussion) 15:22, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Karl432 (einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:02, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro // Martin K. (Diskussion) 19:41, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Michi 18:59, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Jossi (Diskussion) 12:35, 22. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Dominic Z. (Diskussion) 18:01, 22. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Atamari (Diskussion) 14:28, 23. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Wrev (Diskussion) 23:02, 25. Jun. 2017 (CEST) Bin dafür, obwohl ungeübte Quelltext-Bearbeiter von   etc. durchaus abgeschreckt werden könnten[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 16:03, 28. Jun. 2017 (CEST)[Beantworten]
  10. Pro -gpf- (Diskussion) 09:51, 30. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Hört sich sinnig an.[Beantworten]

Einfache Tabellenerstellung

[Quelltext bearbeiten]
Was ist das Problem?

Die bisherige Tabellenerstellung ist für mich einfach zu kompliziert (keine Programmiererfahrungen) Ich möchte eine Excel Tabelle einfach durch einen Kopierbefehl in den Wiki-Text einfügen können --Elcap (Diskussion) 18:49, 29. Mai 2017 (CEST)[Beantworten]

Wen betrifft das Problem besonders?
Vorschlagende Person

Elcap (Diskussion) 18:49, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Elcap (Einreichende Person)
  2. Pro --Z thomas Thomas 11:23, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Conny 22:18, 20. Jun. 2017 (CEST).[Beantworten]
  4. Pro (einschließlich Tabellennachbearbeitung) Mike Krüger, ?! 15:32, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- (Diskussion) 06:57, 22. Jun. 2017 (CEST)[Beantworten]
  6. Pro --mauriceKA (Diskussion) 10:47, 22. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Konfressor (Diskussion) 22:12, 22. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Kiste11 (Disk.Bew.), AW 15:07, 23. Jun. 2017 (CEST)[Beantworten]
  9. Pro obwohl die Festlegung auf Excel vielleicht zu restriktiv ist Divof (Diskussion) 20:16, 24. Jun. 2017 (CEST)[Beantworten]
  10. Pro -- - Majo Senf - Mitteilungen an mich 23:50, 24. Jun. 2017 (CEST)[Beantworten]
  11. Pro GodeNehler (Diskussion) 14:39, 25. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Thomas Obermair 4 (Diskussion) 16:03, 28. Jun. 2017 (CEST)[Beantworten]
  13. Kontra im VE gelöst --Ailura (Diskussion) 12:06, 29. Jun. 2017 (CEST)[Beantworten]
  14. Kontra Per Ailura. Allerdings sollte der VE diesbezüglich verbessert werden (angefangen mit Bugfixes). Pro dafür. --Fixuture (Diskussion) 18:51, 1. Jul. 2017 (CEST)[Beantworten]
  15. Pro --ProloSozz (Diskussion) 23:33, 1. Jul. 2017 (CEST) Ein Text-Tab-Delimited-to Wikitable oder csv-to-wikitable o.ä. wäre allenfalls eine Variante.[Beantworten]
  16. Pro --Ghilt (Diskussion) 09:35, 4. Jul. 2017 (CEST)[Beantworten]

Wikidata-Items aus Wikipedia-Artikel bearbeitbar machen

[Quelltext bearbeiten]
Was ist das Problem?

Wenn die Wikipedia-Artikel mit einem Wikidata-Item verbunden sind sollte es in Wikipedia eine Möglichkeit geben, schnell Eigenschaften in Wikidata hinzuzufügen, ohne explizit nach Wikidata zu müssen.

  • Ich möchte Wikidata-Item auf Vollständigkeit prüfen bzw. erweitern bzw. Eigenschaften belegen.
  • Die Schritte sind dann immer folgende:
    • Aufruf Wikipedia-Artikel, schauen welche Informationen zu Wikidata könnten
    • Aufruf Wikidata-Item schauen welche Informationen vorhanden sind, welche aus dem Wikipedia-Artikel übernommen werden können
    • Item und Artikel in jeweils eine Browser-Registerkarte
    • via Copy und Paste die benötigten Informationen jeweils übertragen.
  • Problem ist nicht die Art und Weise, sondern das viele hin und her klicken.
Wen betrifft das Problem besonders?

Betroffen sind die Personen, welche gerne Wikidata mit mehr Leben füllen wollen oder via englischer Wikipedia die Personendaten verändern möchten.

Lösungsvorschlag

Es gibt ein Helferlein in Wikidata "Drag'n'drop", welches man in umgedrehter Sicht in Wikipedia zur Verfügung stellen könnte. Außerdem müsste man dort eine Möglichkeit schaffen, nach Eigenschaften zu suchen und natürlich in der jeweiligen Landessprache zur Verfügung stellen, da "Drag'n'drop" starr englischt ist.

Vorschlagende Person

Crazy1880 19:32, 29. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Crazy1880 (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:22, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro Iva 20:20, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Gelber kaktus (Diskussion) 21:40, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Kurt Jansson (Diskussion) 10:17, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro Michi 19:00, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro --MGChecker – (📞| 📝| Bewertung) 20:04, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Pearli (Diskussion) 20:45, 21. Jun. 2017 (CEST)[Beantworten]
  9. Pro --ArchibaldWagner (Diskussion) 20:07, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Daniel749 Disk. (STWPST) 21:22, 23. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Nichtich (Diskussion) 22:41, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Chiborg (Diskussion) 23:07, 23. Jun. 2017 (CEST)[Beantworten]
  13. Pro -- Freddy2001 DISK 11:50, 24. Jun. 2017 (CEST)[Beantworten]
  14. Pro Das tolle wäre auch das (nennenswert?) gesteigerte Wachstumspotential für Wikidata; am Anfang ist die Nutzung dessen nämlich etwas befremdlich. Das könnte da helfen. Divof (Diskussion) 19:55, 24. Jun. 2017 (CEST)[Beantworten]
  15. Pro --DomenikaBo (Diskussion) 21:46, 25. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Incabell (Diskussion) 17:34, 27. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Thomas Obermair 4 (Diskussion) 16:04, 28. Jun. 2017 (CEST)[Beantworten]
  18. ProDerHexer (Disk.Bew.) 21:37, 29. Jun. 2017 (CEST)[Beantworten]
  19. Pro Außerdem sollte es automatische bzw semi-automatische Imports geben. Also beispielsweise sollten Infoboxen entsprechend ausgelesen werden und/oder Wikidata-Editierungs-Vorschläge generiert werden. --Fixuture (Diskussion) 18:53, 1. Jul. 2017 (CEST)[Beantworten]
  20. Pro --Maimaid Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)[Beantworten]
  21. Pro Ich finde die Idee sehr gut, bestimmte Daten direkt an der eingebundenen Stelle ändern zu können – unabhängig davon, wie das letztlich umgesetzt wird. Auch weniger technikaffine Benutzer könnten so leichter einen Zugang finden und Daten pflegen, die allen Sprachversionen zugute kommen. --Zaccarias (Diskussion) 12:36, 2. Jul. 2017 (CEST)[Beantworten]
  22. Pro --Mr N (Diskussion) 21:34, 2. Jul. 2017 (CEST)[Beantworten]

Daten für automatische Beleg-Erzeugung im VE lokal ergänzbar machen

[Quelltext bearbeiten]
Was ist das Problem?

Der VisualEditor hat über Citoid die Funktion, Belege anhand einer eindeutigen ID zu erzeugen. Das heißt, man fügt im Belege-Dialog eine ISBN ein und bekommt eine ausgefüllte Literatur-Vorlage. Das funktioniert erstaunlich gut, aber (was auch nicht anders zu erwarten ist) nicht perfekt. Bisher wurden immer wieder zitierte Werke über Wikipedia:BibRecord verwaltet. Es wäre schön, wenn sich diese beiden Systeme verbinden ließen, dass also Citoid auch von dort (oder einer ähnlichen, von Wikipedianern verwalteten Quelle) Daten beziehen könnte.

Lässt man sich beispielsweise einen Beleg zur ISBN 3170032631 im VisualEditor erzeugen, dann kommt das dem Inhalt von Vorlage:BibISBN/3170032631 bereits ziemlich nahe, aber da sich mit dieser Vorlage schon jemand die Mühe gemacht hat, die Daten zu optimieren, wäre es schön, wenn Citoid sie auch nutzen würde.

Wen betrifft das Problem besonders?

Nutzer des VisualEditors (oder Benutzerskripte, die auf Citoid zurückgreifen)

Lösungsvorschlag

Neben den im Augenblick abgefragten Datenbanken müsste Citoid auch in solch lokalen Datenbeständen nachschlagen (und sie, wenn vorhanden, höher priorisieren). Bonuspunkte, wenn der Dialog im VisualEditor auch in der Lage ist, solche lokalen Datensätze zu erzeugen oder zu ergänzen. Also wenn ich in einem automatisch erzeugten Beleg einen fehlenden Verfasser ergänze, werde ich gefragt, ob ich dies für alle späteren Nutzer auch zur Verfügung stellen möchte, woraufhin im Hintergrund ein entsprechender Datensatz angelegt wird.

Vorschlagende Person

Schnark 10:26, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Schnark (Einreichende Person)
  2. Kontra Gute Idee, unpassender Lösungsvorschlag angesichts von WikiCite.--Nichtich (Diskussion) 22:44, 23. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Thomas Obermair 4 (Diskussion) 16:04, 28. Jun. 2017 (CEST)[Beantworten]

Sicherheitsabfrage bei Funktion kommentarlos zurücksetzen

[Quelltext bearbeiten]
Was ist das Problem?

Oft habe ich mich schon verklickt und in der Ansicht Versionsunterschied statt dem Link (Schaltfläche) „danken,“ den Link kommentarlos zurücksetzen erwischt, was oft zu peinlichen Situationen mit dem vorher bearbeitenden Autor führte, da diese Funktion sofort, ohne Nachfrage ausgeführt wird. Diese beiden Links liegen zudem unmittelbar übereinander...

Wen betrifft das Problem besonders?

Betrifft prinzipiell alle User.

Lösungsvorschlag

Eine kleine, stets vorgelagerte Sicherheitsabfrage wie z.B. Wirklich kommentarlos zurücksetzen? würde diese Situation verhindern. Ein Klick mehr bei einem gewollten Rücksetzen halte ich für jeden zumutbar. Speravir testete c:User:Whym/lockrollback.js erfolgreich und schlug vor, eine deutsche Anpassung (deutsche Übersetzung) vorzunehmen und als Helferlein verfügbar zu machen.

Anmerkungen

Freundliche Hilfen von Birgit Müller führten nicht zum Ziel und ich wurde dann auf die jetzt laufende Aktion hingewiesen.

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch werden künftig hier dokumentiert.

Vorschlagende Person

Orgelputzer (Diskussion) 12:44, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Orgelputzer (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:04, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Tkkrd (Diskussion) (Neulingshilfe)
  4. Pro -- Karl432 (Diskussion) 15:09, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Zellmer (Diskussion) 15:29, 20. Jun. 2017 (CEST) 14:49, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro Jordi (Diskussion) 15:33, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Cοlin (Diskussion) 17:08, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Gnom (Diskussion) 17:26, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Frank Schulenburg (Diskussion) 18:31, 20. Jun. 2017 (CEST) P.S. Für mich persönlich würde es schon genügen, wenn die idiotische Sicherheitsabfrage für die "Danken"-Funktion abgeschaltet würde. Oder weiß hier jemand, welchen Zweck die erfüllen soll? P.P.S. Und schon allein die Tatsache, dass das Zurücksetzen einen Klick benötigt, während für das Danken umständlich nachgefragt wird, mutet surreal an.[Beantworten]
    @Frank Schulenburg: Man kann ein Danke meines Wissens nach niemals nicht mehr zurückziehen. Da ist eine Sicherheitsabfrage sinnvoll. Jede zurückgesetzte Version kann genauso einfach wieder eingefügt werden. Mal ganz abgesehen davon, dass für die Vandalenbekämpfung eine Sicherheitsabfrage extrem unpraktisch wäre. Grüße, —DerHexer (Disk.Bew.) 21:40, 29. Jun. 2017 (CEST)[Beantworten]
    Man kann ein Danke meines Wissens nach niemals nicht mehr zurückziehen. – ja, warum eigentlich nicht? Ich kann ja auch eine Seite auf Beobachtung nehmen und dies jederzeit wieder rückgängig machen. Ein solches Feature technisch umzusetzen sollte uns ja nicht annähernd in den Bereich der „Rocket technology“ bringen… Ich bleibe dabei: die Sicherheitsabfrage beim Danken ist kontraproduktiv und sollte schnellstmöglich abgeschaltet werden. --Frank Schulenburg (Diskussion) 21:51, 29. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Claell (Diskussion) 19:03, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro Gelber kaktus (Diskussion) 21:41, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Universal-InteressierterDisk.Arbeit 23:32, 20. Jun. 2017 (CEST)[Beantworten]
  13. Pro --HerrAdams (D) 09:52, 21. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Taigatrommel (Diskussion) 00:26, 22. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Jossi (Diskussion) 12:38, 22. Jun. 2017 (CEST)[Beantworten]
  16. Pro --mauriceKA (Diskussion) 15:05, 22. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Daniel749 Disk. (STWPST) 21:23, 23. Jun. 2017 (CEST)[Beantworten]
  18. Pro Warum beim Danken, aber nicht beim kommentarlosen Zurücksetzten? -- Freddy2001 DISK 11:51, 24. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Martin Luck (Diskussion) 15:14, 24. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Christian (Diskussion) 19:56, 24. Jun. 2017 (CEST)[Beantworten]
  21. Pro -- - Majo Senf - Mitteilungen an mich 23:51, 24. Jun. 2017 (CEST)[Beantworten]
  22. Pro Es gibt viele Möglichkeiten, sich zu verklicken, aber dies ist die peinlichste, und ausgerechnet da passiert es sofort. --Mushushu (Diskussion) 16:18, 25. Jun. 2017 (CEST)[Beantworten]
  23. Pro --DomenikaBo (Diskussion) 21:47, 25. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Wrev (Diskussion) 23:03, 25. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Sophiston (Diskussion) 00:37, 27. Jun. 2017 (CEST)[Beantworten]
  26. Pro --Incabell (Diskussion) 17:35, 27. Jun. 2017 (CEST)[Beantworten]
  27. Pro -- Simulo (Diskussion) 20:03, 27. Jun. 2017 (CEST)[Beantworten]
  28. Pro -- Density Disk. 20:34, 27. Jun. 2017 (CEST)[Beantworten]
  29. Pro --W!B: (Diskussion) 20:56, 27. Jun. 2017 (CEST)[Beantworten]
  30. Pro --Gr1 (Diskussion) 10:40, 28. Jun. 2017 (CEST)[Beantworten]
  31. Pro --Ak ccm (Diskussion) 14:14, 28. Jun. 2017 (CEST)[Beantworten]
  32. Pro --Thomas Obermair 4 (Diskussion) 16:05, 28. Jun. 2017 (CEST)[Beantworten]
  33. Pro --@Sebastian Wallroth: (unvollständig signierter Beitrag von Sebastian_Wallroth (Diskussion | Beiträge) 21:56, 29. Jun. 2017 (CEST)) Sebastian Wallroth 21:56, 29. Jun. 2017 (CEST)[Beantworten]
  34. ProSDKmac (Disk., Bew.) 02:33, 30. Jun. 2017 (CEST)[Beantworten]
  35. Pro Diese Sicherheitsabfrage könnte man dann auch gleich mit dem Hinweis verbinden, dass kommentralos nur bei eigenen Edits oder offensichtlichen Vandalismus zulässig ist und alle andere Reverts begründet werden sollten. // Martin K. (Diskussion) 12:57, 30. Jun. 2017 (CEST)[Beantworten]
  36. Neutral, Pro nur wenn die Sicherheitsabfrage abschaltbar ist, sodass massierter Vandalismus weiterhin rasch korrigiert werden kann. --Sitacuisses (Diskussion) 13:21, 30. Jun. 2017 (CEST)[Beantworten]
  37. Pro Per Sitacuisses. --Fixuture (Diskussion) 18:59, 1. Jul. 2017 (CEST)[Beantworten]
  38. ProDoc TaxonDisk.WikiMUCWikiliebe?! 20:49, 1. Jul. 2017 (CEST)[Beantworten]
  39. Pro --Maimaid Wikiliebe?! 20:51, 1. Jul. 2017 (CEST)[Beantworten]
  40. Pro --Drahreg01 (Diskussion) 22:42, 1. Jul. 2017 (CEST)[Beantworten]
  41. Pro --ProloSozz (Diskussion) 23:36, 1. Jul. 2017 (CEST) kann zwar abgeschaltet werden; Sicherheits- resp. Bestätigungsabfrage wäre aber sehr sinnvoll[Beantworten]
  42. Pro --Neigschmeckter (Diskussion) 13:04, 2. Jul. 2017 (CEST)[Beantworten]
  43. Pro -- X:: black ::X (Diskussion) 15:22, 2. Jul. 2017 (CEST)[Beantworten]
  44. Pro --PAB (Diskussion) 20:37, 2. Jul. 2017 (CEST)[Beantworten]
  45. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) ich würde es hilfreich finden, am besten, so wie bei der Dankesfunktion, z. B. "Vandalismus wirklich kommentarlos zurücksetzen? (Ja / Nein)". Es sollte aber abschaltbar sein, für die, die es nicht wollen.[Beantworten]
  46. ProGhilt (Diskussion) 09:35, 4. Jul. 2017 (CEST)[Beantworten]

Ladezeit & Ressourcen des visuellen Editors reduzieren

[Quelltext bearbeiten]
Was ist das Problem?

Der visuelle Editor braucht, gerade auf ressourcenarmen Systemen, unglaublich lange zum starten und ist sehr langsam.

Wen betrifft das Problem besonders?

Nutzer mit langsamer Verbindung, alten PCs.

Lösungsvorschlag

Abspecken und optimieren. Ggf. Wikisyntax insgesamt vereinfachen, so dass der Parser etc. einfacher und effizienter wird; der Wildwuchs der letzten Jahre (templates und lua und ...) sollte deutlich reduziert werden.

Vorschlagende Person

Chire (Diskussion) 14:29, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Chire (Einreichende Person)
  2. Pro --Gnom (Diskussion) 14:58, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Zellmer (Diskussion) 15:29, 20. Jun. 2017 (CEST) ‖ auch bei schlechtem Internet dauert es oft lange ...[Beantworten]
  4. Pro Thoken (Diskussion) 17:43, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro // Martin K. (Diskussion) 19:43, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro Gubeko (Diskussion) 20:40, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Conny 22:19, 20. Jun. 2017 (CEST).[Beantworten]
  8. Pro Michi 19:01, 21. Jun. 2017 (CEST)[Beantworten]
  9. Pro mauriceKA (Diskussion) 10:49, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro --HHill (Diskussion) 13:06, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Minihaa (Diskussion) 12:33, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Würfel (Diskussion) 12:47, 23. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Daniel749 Disk. (STWPST) 21:23, 23. Jun. 2017 (CEST)[Beantworten]
  14. Pro -- Freddy2001 DISK 11:52, 24. Jun. 2017 (CEST)[Beantworten]
  15. Abwartend mit Tendenz zu Pro Fände das sehr wünschenswert, kann aber nicht überblicken, ob es ungewünschte Folgen haben könnte. --Mushushu (Diskussion) 16:23, 25. Jun. 2017 (CEST)[Beantworten]
  16. Pro --RookJameson (Diskussion) 19:49, 27. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Thomas Obermair 4 (Diskussion) 16:05, 28. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Sebastian Wallroth 21:58, 29. Jun. 2017 (CEST)[Beantworten]
  19. Pro -- Shoeper 18:06, 30. Jun. 2017 (CEST)[Beantworten]
  20. Pro Generell Weiterentwicklung des VisualEditors. --Fixuture (Diskussion) 19:01, 1. Jul. 2017 (CEST)[Beantworten]
  21. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.[Beantworten]

Mehr interaktive Inhalte für die Online-Enzyklopädie: Integration von uMap in die Wikipedia

[Quelltext bearbeiten]
Was ist das Problem?

Das Internet hat sich im letzten Jahrzehnt sehr gewandelt. Interaktive Elemente bereichern inzwischen nahezu alle aktuellen Internetseiten. Wikipedia hingegen sieht immer noch so aus, wie vor mindestens zehn Jahren und unterscheidet sich in seiner Darstellung abgesehen von den Links nicht wirklich von gedruckten Werken. Dabei gibt es im Netz eine Fülle von kostenlosen Tools, mit denen auch Laien interaktiven Elemente wie klickbare Karten, Diagramme, Slider, Zeitleisten etc. gestalten und in ihre Webseite/ihren Blog etc. einbauen können. Manche davon wurden sogar von Projekten aus dem Wikiversum entwickelt oder sind Open Source. Eines davon ist uMap, das die Kollegen von OpenStreetMap aus Frankreich gebastelt haben. Mit dem Tool lassen sich OSM-Karten (oder eigene Hintergründe wie historische Karten wie z. B. auf [1] dieser von mir erstellten Karte) innerhalb von Minuten mit Markern, Linien, Flächen… versehen. Diese können dann mit Anmerkungen, Bildern, Videos etc verknüpft werden. Anwender können so selbst entscheiden, was sie wann ansehen und der gemeine Wikipedia-Autor hat es viel leichter, Karten zu bearbeiten. So ließe sich beispielweise das nervige Arbeiten mit der Koordinatenvorlage ersparen (die wiederum sicherlich auch aus händisch gesetzten Markern per Script für Wikidata o.Ä. leicht ausgelesen werden könnte. Probleme sehe ich erst einmal nicht. Eher ganz großes Potential.

Wen betrifft das Problem besonders?

Autoren, die sich mit Geokordinaten herumschlagen müssen, ohne sich wirklich technisch dafür zu interessieren. Menschen, die eher visuell arbeiten wollen. Menschen, die (wie ich) faul sind und lieber auf eine App zurückgreifen als alles per Hand zu coden. Mit uMap ist es zudem endlich relativ leicht möglich, auch historische Karten mit Markern etc. zu versehen. Auch das ist sicherlich für viele Anwender interessant.

Lösungsvorschlag

uMap ist Open Source. Eine Anpassung an die Bedürfnisse der WP sollte also möglich sein.

Vorschlagende Person

Matthias Süßen ?! 17:48, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Matthias Süßen (Einreichende Person)
  2. Pro --Andropov (Diskussion) 16:27, 20. Jun. 2017 (CEST) Tolle Sache, danke für den Hinweis.[Beantworten]
  3. Pro --Claell (Diskussion) 19:05, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Conny 22:20, 20. Jun. 2017 (CEST).[Beantworten]
  5. Neutral --Wikifreund (Diskussion) 23:41, 20. Jun. 2017 (CEST) Sicherlich eine gute Idee bspw. auch zu HotSpots bei Ereignissen etc. Allerdings sind bei uMap die Marker/Bildzeichensymbole mit Copyright versehen? Soll ein Import über iFrame in die Wikipedia ermöglicht werden? Kann auch ein andares Dateiformat außer .umap dann verwendet werden bspw. für Uploads zu den Commons? Sind alle Lizenzfragen geklärt?[Beantworten]
    Die Antwort findet sich im ausklappbaren Diskussionsbereich. --Matthias Süßen ?! 12:57, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro --jcornelius Benutzer Diskussion:Jcornelius 11:39, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro Michi 19:04, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Andi D (Diskussion) 00:02, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro --mauriceKA (Diskussion) 13:05, 23. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 16:06, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Sebastian Wallroth 21:59, 29. Jun. 2017 (CEST)[Beantworten]
  12. Neutral Ich befürworte derartiges zwar, denke aber, dass es zu ressourcenaufwändig sein könnte und dass wir stattdessen lieber Initiative für Zusammenarbeit mit solchen Projekten entwickeln sollten, die darauf ausgerichtet ist, dass diese Projekte sich selbst in Wikipedia integrieren. Also dass sie mit Hilfe von erfahrenen Programmierern den Wikimedia Code schreiben und ihre eigenen Projekte entsprechend anpassen. Als Ergebnis werden sie dann Wikipedia-weit verwendet. --Fixuture (Diskussion) 19:06, 1. Jul. 2017 (CEST)[Beantworten]

Verbesserung der Belegseinfügung unter Bearbeitung (Visual Editor)

[Quelltext bearbeiten]
Was ist das Problem?

Im Visual Editor gibt es den Button 'Belegen' -> 'Manuell' -> 'Webseite' bei dem ein Template aufgeht. Dort müssen u.a. URL, Titel usw. eingegeben werden, unter anderem das Datum und das Zugriffsdatum.

Dort muß immer aufwendig manuell das Datum per Hand eingetragen werden.

Wen betrifft das Problem besonders?

Jeden, der am selben Tag des Editieren auf die Quelle zugreift, ich denke es ist ein Großteil der Leute die den Visual Editor benutzen.

Lösungsvorschlag

Ist es möglich dort standardmäßig das Aktuelle Datum zu hinterlegen oder stattdessen ein Zusatzknopf einzufügen mit dem man automatisch das Aktuelle Datum setzen kann? Es würde die Tipparbeit verringern, und ich denke dass die Meisten Leute am selben Tag auf die Quelle zugreifen, wenn sie auch den Beleg einfügen. Dasselbe gilt beim datum, wenn es aktuelle Ereignisse sind.

Ein Lösungsansatz von PerfektesChaos:

  • In der Tat könnte das mit wenig Aufwand eingearbeitet werden.
  • Der Quellcode dafür lautet: "autovalue": "{{subst:#time:Y-m-d}}"
    • Das kann allerdings nicht im „Template“ definiert werden, sondern müsste in TemplateData vereinbart werden.
  • Das Problem ist ein ganz anderes:
    • Diese Angaben werden meist innerhalb von <ref>-Konstrukten gemacht.
    • Dort wird nicht „substituiert“; das heißt, das Datum zum Zeitpunkt der Abspeicherung übernommen.
    • Damit bleibt das auf ewig so stehen, oder zeigt das Datum zur Zeit des Lesens an.
  • Du kannst Vorlagenmeister verwenden; der schreibt direkt den gewünschten Datumsstempel fix.

LG --PerfektesChaos 18:28, 7. Jun. 2017 (CEST)[Beantworten]

Kommentar von GodeNehler:
Ich bin nicht ganz sicher ob ich den Technischen Teil richtig verstanden habe. Mein Ziel ist eigentlich nicht, den Inhalt des Quelltextes der Wikipedia zu ändern. Nur der Editor um den Quelltext zu erstellen sollte sich ändern. --GodeNehler (Diskussion) 22:26, 10. Jun. 2017 (CEST)[Beantworten]
Anmerkungen

Ich vermute, dass die Lösung mit wenig aufwand in das vorhandene Template eingearbeitet werden kann.

Vorschlagende Person

GodeNehler (Diskussion) 18:03, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro GodeNehler (Einreichende Person)
  2. Pro --Gnom (Diskussion) 17:26, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Conny 22:21, 20. Jun. 2017 (CEST).[Beantworten]
  4. Pro --Gr1 (Diskussion) 10:42, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:06, 28. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Sebastian Wallroth 22:08, 29. Jun. 2017 (CEST)[Beantworten]
  7. Pro Und zwar nicht nur für den VisualEditor. Benutzt denn hier keiner das Englische Wikipedia? Dort gibt es ein sehr, sehr nützliches Autofill-Feature. Das Hinzufügen detailierter Referenzen sind für mich dort genau 4 Klicks, die etwa 2 Sekunden benötigen. Im Deutschen Wikipedia brauch ich etwa 10 mal so lange für undetailierte Referenzen. Für mich wäre das Priorität #1. Keine Ahnung wieso das Feature noch nicht eingebaut wurde? --Fixuture (Diskussion) 19:10, 1. Jul. 2017 (CEST)[Beantworten]
  8. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Existiert im Quelltexteditor schon, man muss nur die Vorlage von Vorlage:Internetquelle kopieren. Da spart man sich dann auch die halbe Minute Ladezeit.[Beantworten]


Vorlage:IPA mit Einzellauten (Anker) statt gesamter Seite einbinden

[Quelltext bearbeiten]
Was ist das Problem?

Ich weiß nicht, ob es anderen hier ähnlich geht, aber ich erlebe es jedes Mal als recht lästig, mir die in einem Artikel benutzten Zeichen aus dieser ellenlangen Liste erst einmal mühsam heraussuchen zu müssen, und bei manchen Buchstaben könnte der Laie aus meiner Sicht auch schnell überfordert sein, was die Zuordnung angeht. Warum ist man denn nicht längst schon zu einer Verlinkung konkret der Einzellaute (z. B. mithilfe von Ankern) übergegangen, wie bspw. bereits hier von Chricho vorgeschlagen? Entschuldigt bitte, falls ich bei meinen Überlegungen hier doch etwas Naheliegendes übersehen haben sollte.

Wen betrifft das Problem besonders?
Lösungsvorschlag

Vorlage_Diskussion:IPA#Verlinkung_von_einzelnen_Lauten (idealiter global wirksam)

Vorschlagende Person

Erdic (Diskussion) 21:33, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Erdic (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:12, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro  hugarheimur 09:24, 20. Jun. 2017 (CEST) Sehr sinnvolle Idee![Beantworten]
  4. Pro --Andropov (Diskussion) 16:29, 20. Jun. 2017 (CEST) Bin ich auch schon häufiger drüber gestolpert.[Beantworten]
  5. Pro --Mushushu (Diskussion) 16:28, 25. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Matthiasb – (CallMyCenter) 23:38, 28. Jun. 2017 (CEST) Vielleicht kann man bei der Lösung abkucken, wie das in EN funktioniert; dort zeigt ein Mouseover zeichensozifisch die Bedeutung des IPA-Zeichens an. Optional würde ich mir das auch für andere nichtlateinische Schriften wünschen, Kyrillisch, Arabisch, you name it.[Beantworten]
  8. ProDerHexer (Disk.Bew.) 21:42, 29. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Sebastian Wallroth 22:11, 29. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Maimaid Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)[Beantworten]
  11. Pro --Hanekomi (Diskussion) 01:37, 2. Jul. 2017 (CEST)[Beantworten]
  12. Pro -- X:: black ::X (Diskussion) 15:47, 2. Jul. 2017 (CEST)[Beantworten]
  13. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) verkürzt die Zeit, die der Leser benötigt.[Beantworten]
  14. Kontra --PerfektesChaos 23:57, 2. Jul. 2017 (CEST) Weder könnten Mobilbenutzer das wahrnehmen, noch käme da was anderes raus als ein endloser Bandwurm von Stimmloser glottaler Plosiv Stimmhafter Frikativ Stimmloses Bla Bla bla Plosiv Bla bla bla Frikativ Bla bla bla Stimmloses Bla bla bla – für keinen Fall hatten die Vorschlagenden ein Beispiel angegeben, was dann in diesen Toltips drinstehen würde, und was Normalsterbliche mit der Erläuterung anfangen könnten.[Beantworten]

[Quelltext bearbeiten]
Was ist das Problem?

Zwei Probleme:

  1. Derzeit können die URLs von Wikiseiten mit Umlauten und sonstigen Sonderzeichen in der Überschrift mit dem Linktool in der Quelltext-Toolbar (Wikieditor) nicht umgewandelt werden. Es erscheint dann eine Fehlermeldung.
  2. Zudem werden Leerzeichen stets mit Unterstrichen versehen. Muss das so sein?
Wen betrifft das Problem besonders?
Lösungsvorschlag

Wikipedia:Fragen zur Wikipedia#Automatische Linkumwandlung (idealiter global wirksam)

Vorschlagende Person

Erdic (Diskussion) 21:41, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Erdic (Einreichende Person)
  2. Pro @IvaBerlin: (nicht signierter Beitrag von IvaBerlin (Diskussion | Beiträge) Uhrzeit, 22. Juni 2017, 10:37 Uhr) Das habe ich mich auch schon sehr oft gefragt, ob das wirklich so sein muss, vor allem mit der unvollkommen erscheinenden Umlaut-Umwandlung, die dann prompt vom System beklagt wird. Sehr nervig, dass dann jedes Mal händisch korrigieren zu müssen.
  3. Pro Divof (Diskussion) 20:18, 24. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Atamari (Diskussion) 14:34, 23. Jun. 2017 (CEST)[Beantworten]
  5. Pro --DomenikaBo (Diskussion) 21:48, 25. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Sebastian Wallroth 22:12, 29. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Maimaid Wikiliebe?! 21:13, 1. Jul. 2017 (CEST)[Beantworten]
  9. Abwartend. Siehe meinen Diskussionsbeitrag (auf „Ausklappen“ klicken). --X:: black ::X (Diskussion) 16:50, 2. Jul. 2017 (CEST)[Beantworten]

Auf fehlende schließende HTML-Tags überprüfen

[Quelltext bearbeiten]
Was ist das Problem?

In Wiki-Quelltext können HTML-Tags verwendet werden. Die meisten davon schließen den betreffenden Text zwischen einem öffnenen und einem schließenden Tag ein, zum Beispiel für einen HTML-Kommentar: <!--Kommentartext-->. Wenn das fehlende Tag fehlt, nimmt MediaWiki an, dass der gesamte weitere Text bis zum Ende des Artikels geht. Bei einem fehlenden schließenden Kommentartag wird dementsprechend der gesamte weitere Seiteninhalt als Kommentar verstanden, sodass dieser Text dann nicht mehr sichtbar ist. Das Problem wird dadurch forciert, dass in manchen Seitenvorlagen HTML-Tags schon enthalten sind, sodass auch Nutzer ohne HTML-Kenntnisse genötigt werden, diese Tags zu verwenden.

Es ist bereits mehrfach vorgekommen, dass in der Auskunft, wo HTML-Kommentartags ebenfalls zur Abschnittsvorlage gehören, große Teile der Seite unsichtbar geworden sind, weil ein öffnendes Kommentartag ohne zugehöriges schließendes Kommentartag verwendet wurden.

Wen betrifft das Problem besonders?

Alle Benutzer, die Seitenvorlagen mit HTML-Tags verwenden (zum Beispiel in der Auskunft oder hier), aber keine HTML-Kenntnisse besitzen.

Lösungsvorschlag

Mehrere Lösungen bei fehlendem schließendem Tag sind möglich (nach meinem Dafürhalten in aufsteigender Eignung):

  • Warnen.
  • Das Speichern der Seite verhindern.
  • Das fehlende Tag automatisch am Ende des bearbeiteten Abschnitts einfügen.

Im Übrigen halte ich es für angebracht, auf HTML-Tags in Seitenvorlagen zu verzichten.

Anmerkungen

Siehe auch Wikipedia:Verbesserungsvorschläge#Warnung bei fehlendem schließendem HTML-Kommentartag

Vorschlagende Person

BlackEyedLion 23:22 Uhr, 30. Mai 2017

Unterstützung
  1. Pro BlackEyedLion (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:14, 19. Jun. 2017 (CEST) Auf HTML verzichten möchte ich nicht, aber eine Warnung wäre ganz gut.[Beantworten]
  3. Pro -- Karl432 (Diskussion) 15:12, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Andropov (Diskussion) 16:31, 20. Jun. 2017 (CEST) WArnhinweis ist ohne Aufwand umsetzbar und hilfreich.[Beantworten]
  5. Pro --mauriceKA (Diskussion) 13:07, 23. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Atamari (Diskussion) 14:35, 23. Jun. 2017 (CEST)[Beantworten]
  7. Pro --DomenikaBo (Diskussion) 21:48, 25. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Wrev (Diskussion) 23:05, 25. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)[Beantworten]
  10. Pro. Auf jeden Fall erst mal warnen (kann ja sein, dass es nur ein Versehen und keine völlige Unwissenheit ist) und dann – für diejenigen, die den Fehler nicht beheben können,– anbieten den fehlenden Tag automatisch an einer möglichst wahrscheinlich richtigen Stelle einzufügen. -- X:: black ::X (Diskussion) 17:04, 2. Jul. 2017 (CEST)[Beantworten]
  11. Pro --PAB (Diskussion) 20:38, 2. Jul. 2017 (CEST)[Beantworten]
  12. Kontra, falls es um den Quelltexteditor geht, weil Quelltextbearbeiter idR auf "Vorschau" klicken können. Pro falls es um den VE geht, weil der hauptsächlich von unerfahrenen Neulingen benutzt wird, welche das nicht können. --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017‎

VisualEditor auf Diskussionsseiten

[Quelltext bearbeiten]
Was ist das Problem?

Kein Visualeditor auf Diskussionsseiten.

Wen betrifft das Problem besonders?

Kommunikative Nutzer.

Lösungsvorschlag

VisualEditor auf Diskussionsseiten einführen.

Anmerkungen

Wenn man gute Diskussionsbeiträge erstellen will, dann muss man auch Referenzen einfügen. Ohne VisualEditor muss man entweder alles per Hand machen (<ref>[LINK TITEL] MEHR INFO</ref>) oder eben Yadkard verwenden.

Vorschlagende Person

Rævhuld (Diskussion) 23:51, 30. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Rævhuld (Einreichende Person)
  2. Pro -- Barnos (Post) 08:49, 20. Jun. 2017 (CEST) Ohne hürdenfreie Anwendung auf Diskussionsseiten scheidet der VE für mich bei der Einsteigereinführung in die Wikipedia aus.[Beantworten]
  3. Pro --Gnom (Diskussion) 17:31, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Gubeko (Diskussion) 20:46, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Conny 22:22, 20. Jun. 2017 (CEST).[Beantworten]
  6. Pro --GodeNehler (Diskussion) 05:50, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro mauriceKA (Diskussion) 10:50, 22. Jun. 2017 (CEST)[Beantworten]
  8. Pro --KorrekTOM (Diskussion) 13:16, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Daniel749 Disk. (STWPST) 21:26, 23. Jun. 2017 (CEST)[Beantworten]
  10. Kontra Nutzer sollten Feedback ohne Erlernen der Wikisytnax abgeben können. Was ist mit Flow? --Nichtich (Diskussion) 22:48, 23. Jun. 2017 (CEST)[Beantworten]
  11. Pro -- Freddy2001 DISK 11:53, 24. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Skrippek (Diskussion) 16:26, 24. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Thomas Obermair 4 (Diskussion) 16:08, 28. Jun. 2017 (CEST)[Beantworten]
  14. Kontra Ich habe noch nie erlebt, dass ein schlecht formatierter Diskussionsbeitrag ein unlösbares Problem war, und die Frage ob man oben oder unten anfügt löst der VE auch nicht. --Ailura (Diskussion) 12:08, 29. Jun. 2017 (CEST)[Beantworten]
  15. Pro -- Per Barnos. --Fixuture (Diskussion) 19:12, 1. Jul. 2017 (CEST)[Beantworten]
  16. ProDoc TaxonDisk.WikiMUCWikiliebe?! 20:58, 1. Jul. 2017 (CEST)[Beantworten]
  17. Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Frankfurt am Main (Größe 243 KB) benötigt bei mir eine VE-Ladezeit von ca. 37 Sekunden. Wie soll das dann auf WD:SG werden, welches mal knapp 1GB hatte? Sollen Benutzer, welche ausversehen draufkommen ewig warten?[Beantworten]

Einfache Kalkulationsfunktionen für Tabellen/Berechnen der Summe

[Quelltext bearbeiten]
Was ist das Problem?

In Listenartikeln werden Tabelleninhalte zusammengefasst und ausgewertet. Die einfachste und häufigste Möglichkeit ist die Ausgabe der Anzahl der Einträge einer Tabelle. Wenn aufgrund von Aktualisierungen Einträge hinzukommen, wegfallen oder angepasst werden, müssen die Auswertungen ebenfalls angepasst werden. Dies wird oft vergessen bzw. ist bei großen Tabellen unübersichtlich. Automatische Erstellung der Summe in Tabellen, wenn sich die Tabelleninhalte ändern.

Wen betrifft das Problem besonders?

Autoren, die Listenartikel bzw. Tabellen erstellen und bearbeiten, insbesondere deren Inhalte öfter aktualisiert werden. Vermeidet auch Additionsfehler.

Lösungsvorschlag

Kalkulationsfunktionen zum Auswerten von Tabellen, deren Ergebnis an jeder beliebigen Stelle im Artikel (ggf. auch in anderen Artikeln, Diskussionsseite...) ausgegeben werden kann (z. B. Zähle Einträge, Zähle bestimmte Einträge, Grundrechenarten von Einträgen um aufgeteilte Tabellen zu addieren), Tabellentauglicher Befehl, der eine Spalte addiert.

Bsp.:

(Zusammenführung zweier ähnlicher Wünsche - vormals auch in Wikipedia:Umfragen/Technische Wünsche 2017/Lesen)

Vorschlagende Person

Z thomas Thomas 10:15, 31. Mai 2017 (CEST) /Partynia RM 10:38, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro Partynia (Einreichende Person)
  3. Pro -- Marcus Cyron Reden 10:22, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro DCB (DiskussionBewertung) 22:12, 19. Jun. 2017 (CEST)[Beantworten]
  5. Pro Mike Krüger, ?! 13:33, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro Jordi (Diskussion) 15:19, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Kontrollstelle Kundl 18:34, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Claell (Diskussion) 19:06, 20. Jun. 2017 (CEST)[Beantworten]
  9. Pro Conny 22:23, 20. Jun. 2017 (CEST).[Beantworten]
  10. Pro GodeNehler (Diskussion) 05:51, 21. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Matthias Süßen ?! 12:59, 21. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Jossi (Diskussion) 12:53, 22. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Louis ♫ BafranceSchwätz halt mit m'r, wenn da ebbes saga witt 22:03, 22. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Konfressor (Diskussion) 22:13, 22. Jun. 2017 (CEST)[Beantworten]
  15. Pro mauriceKA (Diskussion) 13:08, 23. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Daniel749 Disk. (STWPST) 21:27, 23. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Christian (Diskussion) 19:57, 24. Jun. 2017 (CEST)[Beantworten]
  18. Pro --AdAstraPerScientiam (Diskussion) 10:09, 25. Jun. 2017 (CEST)[Beantworten]
  19. Pro --Sophiston (Diskussion) 00:41, 27. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Gr1 (Diskussion) 10:43, 28. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Ak ccm (Diskussion) 14:18, 28. Jun. 2017 (CEST)[Beantworten]
  22. Pro --Thomas Obermair 4 (Diskussion) 16:08, 28. Jun. 2017 (CEST)[Beantworten]
  23. ProDerHexer (Disk.Bew.) 21:46, 29. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Drahreg01 (Diskussion) 22:46, 1. Jul. 2017 (CEST)[Beantworten]
  25. Kontra -- Σ? Wo soll das enden? Ø? Median? σ? Am Ende wird die WP zur Tabellenkalkulation. Wen eine Tabelle zu Überarbeitung interessiert, sollte diese aber einfach in eine TK kopieren und nach Überarbeitung genauso einfach wieder hier einsetzen können. Fände ich aber wesentlich datensparsamer! Horst Emscher (Diskussion) 17:35, 2. Jul. 2017 (CEST)[Beantworten]
  26. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) very hilfreich.[Beantworten]

Assistent zum Einfügen von Referenzen und Vorlagen im Quelltexteditor

[Quelltext bearbeiten]
Was ist das Problem?

Ich muss jedes mal in anderen Artikeln nachsehen, wie das syntaktisch geht mit dem Wiki-Quelltext für Referenzen oder welche Vorlagen es überhaupt gibt.

Wen betrifft das Problem besonders?

Alle Autoren, die die Wiki-Syntax nicht immer aus dem FF kennen :-)

Lösungsvorschlag

So, wie man auch einen Wikilink mit einem Assistenten erzeugen kann, der einem beim Tippen schon Vorschlagsseiten bringt, so ein Assistent wäre für Referenzen auch sinnvoll. Etwa so:

Art: (X) Webseite ( ) Buch
Autor:    ________
Verlag:   ________
ISBN/URL: ________
Datum:    ________

Ebenso wäre es bei Vorlagen sinnvoll, wenn man diese nach Kategorien "on-typing" suchen kann, wie das auch bei den Wikilinks der Fall ist. Es gibt anscheinend den "Vorlagenmanager", allerdings verstehe ich bnicht auf Anhieb, wie man diesen benutzen soll. Intuitiv ist er jedenfalls nicht, denn wenn ich nicht weiß, wie eine Vorlage heißt, bringt der relativ wenig.

Vorschlagende Person

Pietz (Diskussion) 22:54, 31. Mai 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Pietz (Einreichende Person)
  2. Pro --KorrekTOM (Diskussion) 13:11, 22. Jun. 2017 (CEST)[Beantworten]
  3. Pro --DomenikaBo (Diskussion) 21:49, 25. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Jaquento (Diskussion) 02:34, 30. Jun. 2017 (CEST)[Beantworten]
  6. Pro Per obrigem Vorschlag: Benutzt denn hier keiner das Englische Wikipedia? Dort gibt es ein sehr, sehr nützliches Referenzhinzufüg & Autofill-Feature. Das Hinzufügen detailierter Referenzen sind für mich dort genau 4 Klicks, die etwa 2 Sekunden benötigen. Im Deutschen Wikipedia brauch ich etwa 10 mal so lange für undetailierte Referenzen. Für mich wäre das Priorität #1. Keine Ahnung wieso das Feature noch nicht eingebaut wurde? (nicht signierter Beitrag von Fixuture (Diskussion | Beiträge) 19:15, 1. Jul. 2017‎)
  7. Pro --Hanekomi (Diskussion) 01:37, 2. Jul. 2017 (CEST)[Beantworten]
  8. Pro --Sitacuisses (Diskussion) 11:36, 2. Jul. 2017 (CEST)[Beantworten]
  9. Pro -- Mr N (Diskussion) 21:52, 2. Jul. 2017 (CEST)[Beantworten]

Ganze Kapitel verschieben

[Quelltext bearbeiten]
Was ist das Problem?

Will man ein Kapitel oder Unterkapitel einer längeren Seite an eine andere Stelle verschieben, hat man diese aufzurufen, zu markieren, auszuschneiden, den leeren Inhalt zu speichern, an die gewünschte Stelle zu gehen, diese zum Editieren aufzurufen, den Cursor an die gewünschte Stelle zu setzen und dann einzufügen.

Programme wie "OpenOffice" besitzen hierfür im Navigator die Möglichkeit, (Unter)Kapitel mit ihren Unterkapiteln einfach an eine andere Stelle zu verschieben.

Wen betrifft das Problem besonders?

Es betrifft alle Autoren, insbesondere die ältere Bestände pflegen (ergänzen, umbauen).

Lösungsvorschlag

Es sollte ein Tool geben, ähnlich dem "Navigator" bei OpenOffice, mit dem (Unter)Kapitel auf einer Seite einfach zu verschieben sind.

Anmerkungen

keine

Vorschlagende Person

Br. Klaus (Diskussion) 06:48, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Br. Klaus (Einreichende Person)
  2. Pro --Z thomas Thomas 11:27, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 00:55, 22. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Freddy2001 DISK 11:54, 24. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)[Beantworten]
  6. ProDoc TaxonDisk.WikiMUCWikiliebe?! 21:01, 1. Jul. 2017 (CEST)[Beantworten]
  7. Pro --ProloSozz (Diskussion) 23:39, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --PAB (Diskussion) 20:39, 2. Jul. 2017 (CEST)[Beantworten]
  9. Pro --Devotus (Diskussion) 20:44, 2. Jul. 2017 (CEST)[Beantworten]

Kapitel hoch- und runterstufen

[Quelltext bearbeiten]
Was ist das Problem?

Beim Überarbeiten (Ergänzen, Korrigieren, Aktualisieren) von Seiten macht es mitunter Sinn, (Unter)Kapitel mitsamt allen seinen Unterkapiteln hoch- bzw. runterzustufen. Hierbei hat man an allen entsprechenden Stellen ein oder mehrere "=" einzusetzen oder zu löschen. Dies kann bei einem (Unter)Kapitel mit zahlreichen Unterkapiteln sehr zeitraubend sein.

Wen betrifft das Problem besonders?

Es betrifft alle Autoren, die bestehende Seiten überarbeiten.

Lösungsvorschlag

Programme wie OpenOffice besitzen im "Navigator" die Möglichkeit, mit einem Mausklick (Unter-)Kapitel mit allen seinen Unterkapiteln um eine Ebene hoch- oder runterzustufen. Es sollte ein Tool geben, das dies bei Texten von MediaWiki auch mit Mausklick ermöglicht.

Anmerkungen

keine

Vorschlagende Person

Br. Klaus (Diskussion) 06:56, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Br. Klaus (Einreichende Person)
  2. Pro --Z thomas Thomas 11:27, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Gubeko (Diskussion) 20:47, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 00:55, 22. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- Freddy2001 DISK 11:54, 24. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Gr1 (Diskussion) 10:44, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)[Beantworten]
  8. ProDoc TaxonDisk.WikiMUCWikiliebe?! 21:02, 1. Jul. 2017 (CEST)[Beantworten]
  9. Pro --ProloSozz (Diskussion) 23:41, 1. Jul. 2017 (CEST)[Beantworten]
  10. Pro -- X:: black ::X (Diskussion) 17:18, 2. Jul. 2017 (CEST)[Beantworten]
  11. Pro --PAB (Diskussion) 20:40, 2. Jul. 2017 (CEST)[Beantworten]

Shortcut für Benutzer-Ping im Quelltexteditor

[Quelltext bearbeiten]
Was ist das Problem?

Es ist aktuell etwas umständlich, einen Benutzer mit der Vorlage {{ping}} oder in Klammern zu erwähnen. Unnötige Tipp-Arbeit, die man mit einer cleveren Lösung bestimmt elegant umgehen könnte.

Wen betrifft das Problem besonders?

Autoren, die häufiger in Diskussionen unterwegs sind.

Lösungsvorschlag

Es wäre wünschenswert, entweder ein eigenes Icon in der Tool-Leiste bereit zu stellen, oder noch besser direkt im Quelltext eine entsprechende Funktion bereit zustellen. Somit könnte die Ping-Vorlage bereits fertig ausgefüllt in den Quelltext eingefügt werden, analog dazu die Klammer-Variante. Denkbar wäre es, die Funktionen nur optional anzubieten.

Vorschlagende Person

FNDE 13:40, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro FNDE (Einreichende Person)
  2. Pro GodeNehler (Diskussion) 05:52, 21. Jun. 2017 (CEST)[Beantworten]
  3. Pro Michi 19:04, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro Iva 10:46, 22. Jun. 2017 (CEST) ich muss das auch praktisch jedes Mal nachschauen, wenn ich eine Benutzerin anpingen will. Ob die in der Diskussion erwähnte Lösung zum Ziel führt, wurde leider nicht beantwortet.[Beantworten]
  5. Pro -- Freddy2001 DISK 11:55, 24. Jun. 2017 (CEST)[Beantworten]
  6. Pro --DomenikaBo (Diskussion) 21:52, 25. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:10, 28. Jun. 2017 (CEST)[Beantworten]

Abschnittsweises Editieren mit dem Visual Editor ermöglichen

[Quelltext bearbeiten]
Was ist das Problem?

Neben jedem Abschnitt gibt es die Auswahl: Bearbeiten / Quelltext bearbeiten. Beim Klicken auf Bearbeiteen startet der Visual Editor, lädt und editiert aber den gesamten Text, nicht nur den Abschnitt.

Wen betrifft das Problem besonders?

Jeden, der nur einen Abschnitt editieren will, relevant vor allem bei langen Texten.

Lösungsvorschlag

Auch der Visual Editor soll, wie es der Quelltexteditor macht, nur den Abschnitt editieren, neben dessen Überschrift man auf Bearbeiten geklickt hat.

Vorschlagende Person

bjs Diskussionsseite 21:46, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Bjs (Einreichende Person)
  2. Pro GodeNehler (Diskussion) 05:53, 21. Jun. 2017 (CEST)[Beantworten]
  3. Pro sk (Diskussion) 16:51, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro Michi 19:04, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro Martin K. (Diskussion) 11:27, 22. Jun. 2017 (CEST)[Beantworten]
  6. Pro --KorrekTOM (Diskussion) 13:12, 22. Jun. 2017 (CEST)[Beantworten]
  7. Pro mauriceKA (Diskussion) 13:10, 23. Jun. 2017 (CEST)[Beantworten]
  8. Pro -- Nichtich (Diskussion) 22:50, 23. Jun. 2017 (CEST)[Beantworten]
  9. Pro -- Freddy2001 DISK 11:56, 24. Jun. 2017 (CEST)[Beantworten]
  10. Pro --  Sir Gawain Disk. 15:17, 25. Jun. 2017 (CEST)[Beantworten]
  11. Pro Versat (Diskussion) 13:17, 26. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Incabell (Diskussion) 17:38, 27. Jun. 2017 (CEST)[Beantworten]
  13. Pro --RookJameson (Diskussion) 19:50, 27. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Thomas Obermair 4 (Diskussion) 16:10, 28. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Ailura (Diskussion) 12:10, 29. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Wingsofcourage (Diskussion) 14:38, 30. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Fixuture (Diskussion) 19:17, 1. Jul. 2017 (CEST)[Beantworten]
  18. Pro --Kritzolina (Diskussion) 20:39, 1. Jul. 2017 (CEST)[Beantworten]
  19. ProDoc TaxonDisk.WikiMUCWikiliebe?! 21:03, 1. Jul. 2017 (CEST)[Beantworten]
  20. Pro --Maimaid Wikiliebe?! 21:10, 1. Jul. 2017 (CEST)[Beantworten]
  21. ProDerHexer (Disk.Bew.) 21:19, 1. Jul. 2017 (CEST)[Beantworten]
  22. Pro -- Mr N (Diskussion) 22:17, 2. Jul. 2017 (CEST) Allerdings sollten dann die (andernorts bereits geführten) Überlegungen zu abschnittsweisen Editieren berücksichtigt werden.[Beantworten]

Der Wechsel vom Quelltext-Editor zum Visual Editor soll ohne Datenverlust möglich sein

[Quelltext bearbeiten]
Was ist das Problem?

Normalerweise benutze ich den Quelltext-Editor, weil der schneller lädt und ich ihn gewohnt bin. Manche Funktionen des Visual Editors finde ich aber sehr nütlich, z.B. die Funktionen "Belegen" oder "Vorlage einfügen". Wenn ich nun aus dem Quelltext-Editor zum Visual Editor wechseln will, muss ich bestätigen, dass meine Änderungen verworfen werden. Ich kann das bestätigen und meine Änderungen erneut eingeben oder erst einmal speichern und dann den Quelltext-Editor aufrufen.

Wen betrifft das Problem besonders?

Jeden, der gerne beide Editoren verwendet.

Lösungsvorschlag

Es sollte möglich sein, vom Quelltext-Editor zum Visual Editor zu wechseln, ohne dass die eingegebenen Änderungen verloren gehen und oohne dass man erst einmal zwischenspeichern muss. In BVerbindung mit dem obigen Wunsch sollte dann auch nur der Abschnitt im Visual Editor angezeigt werden, mit dem man im Quelltext-Editor die Bearbeitung begonnen hat.

Vorschlagende Person

bjs Diskussionsseite 22:07, 1. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Bjs (Einreichende Person)
  2. Pro Gubeko (Diskussion) 20:49, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro GodeNehler (Diskussion) 05:54, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro Michi 19:07, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro --MGChecker – (📞| 📝| Bewertung) 20:06, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro mauriceKA (Diskussion) 13:10, 23. Jun. 2017 (CEST)[Beantworten]
  7. Pro Divof (Diskussion) 20:20, 24. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Sophiston (Diskussion) 00:43, 27. Jun. 2017 (CEST)[Beantworten]
  9. Pro --W!B: (Diskussion) 21:04, 27. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Thomas Obermair 4 (Diskussion) 16:17, 28. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Fixuture (Diskussion) 19:17, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro --PAB (Diskussion) 20:41, 2. Jul. 2017 (CEST)[Beantworten]
  13. Pro --MannMaus (Diskussion) 20:44, 2. Jul. 2017 (CEST) Das war mir so nicht bewusst, aber wenn es denn so ist und verbessert werden kann...[Beantworten]

Erweiterung des Funktionsumfangs von {{SEITENTITEL:}} bzw. {{DISPLAYTITLE:}}

[Quelltext bearbeiten]

Was ist das Problem?

Die Funktion {{SEITENTITEL:}} ermöglicht die Änderung des dargestellten Seitentitels gegenüber dem tatsächlichen Lemma. Der Umfang der erlaubten Abweichungen ist aus guten Gründen stark reglementiert, kann aber noch sinnvoll erweitert werden. So sollten idealerweise alle der in Wikipedia:Liste der Artikel, deren korrekter Titel von MediaWiki nicht erlaubt wird gelisteten „unmöglichen“ Lemmata über einen erweiterten Funktionsumfang von {{SEITENTITEL:}} adressierbar sein.

Wen betrifft das Problem besonders?

Alle Leser, die von unterschiedlich angezeigten Seitentiteln verwirrt sein können und alle Autoren, die einen korrekten Seitentitel nur an einem einzigen Ort festlegen möchten

Lösungsvorschlag

Das Ersetzen bestimmter im Lemma „verbotener“ Zeichen durch andere Zeichen soll erlaubt werden. Eine entsprechende Tabelle kann WP-weit definiert werden. Beispielsweise wäre zu erlauben:

  • ([ oder <
  • )] oder >
  • /|
  • ggf. weitere nach Abstimmung und technischer Prüfung

Ziel wäre es, die Vorlage:Korrekter Titel überflüssig zu machen.

Gleichzeitig sollte der korrekte Titel gem. Angabe in {{SEITENTITEL:}} wo immer möglich auch angezeigt werden, insbesondere

  • als Titel der Artikeldiskussionsseite (ohne, dass dort die Angabe erneut im Quelltext eingetragen werden müsste) und deren Unterseiten
  • in Kategorien
  • als Titel auf Wikidata
  • in der Liste der Interwiki-Links
  • auf Spezialseiten
  • Seitentitel in der Versionsgeschichte, Bearbeiten u. a.
  • (weitere?)
    Vorschlagende Person

Mabschaaf 14:34, 4. Jun. 2017 (CEST), ergänzt von --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 20:39, 10. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Mabschaaf (Einreichende Person)
  2. Pro Morten Haan (Einreichende Person)
  3. Pro DCB (DiskussionBewertung) 22:13, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro --MGChecker – (📞| 📝| Bewertung) 20:07, 21. Jun. 2017 (CEST)[Beantworten]
  5. Abwartend --W!B: (Diskussion) 21:19, 27. Jun. 2017 (CEST) bisserl sehr viel aufwand für die paar artikel: ich sähe hier viel mehr zukunft in ersatzzeichen im lemma, für spitze klammer gibts in unicode was, für eckige zur not auch, cf. http://xahlee.info/comp/unicode_matching_brackets.html, #e gibts etlich, für die pipe sowieso (rahmenelemente uam.); cf. dazu auch klammerlemma, das ist zwar NK-syntax, nicht wikimedia-syntax, aber verwandt.[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:17, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro --alexscho (Diskussion) 00:30, 2. Jul. 2017 (CEST)[Beantworten]
  8. Abwartend -- X:: black ::X (Diskussion) 17:33, 2. Jul. 2017 (CEST)[Beantworten]
  9. Kontra --PerfektesChaos 23:53, 2. Jul. 2017 (CEST) Es betrifft weniger als 100 Artikel, die zurzeit per Vorlage gemanaged werden; davon könnte maximal die Hälfte ersetzt werden. Es muss aber dann genauso zu jedem betroffenen Artikel die verlinkbare und kopierbare Zweitversion angegeben werden, und damit ist nach Riesen-Aufwand genau nichts gewonnen und sieht genauso aus wie vorher.[Beantworten]

Abspeichern von Inhalt ohne zu veröffentlichen

[Quelltext bearbeiten]
Was ist das Problem?

Ich arbeite manchmal länger an einem Artikel oder einer neuen Artikelversion, vielleicht über Tage und Wochen. Ich möchte den Quelltext abspeichern zur Sicherung, aber noch nicht als neue Artikelversion (möchte nicht veröffentlichen). Bislang muss ich dazu den Quelltext stets per Copy&Paste außerhalb der Wikipedia abspeichern, zum Beispiel mit einem Textverarbeitungsprogramm. Da ich manchmal mit dem VisualEditor schreibe, muss ich dazu immer wieder in den WikiEditor wechseln, und zurück.

Manchmal schreibe ich auch gleichzeitig an mehreren Artikelentwürfen. Dazu muss ich mir außerhalb der Wikipedia einen Ort aufbauen. Beim Hin- und Her-Kopieren besteht das Risiko, dass Fehler eintreten und Text verloren geht.

Wen betrifft das Problem besonders?

Die fehlende Möglichkeit des Abspeicherns im Wiki sorgt dafür, dass die Autoren seltener zur Sicherheit abspeichern. Außerdem verzögert es den Arbeitsfluss.

Lösungsvorschlag

Eine Lösung für das Abspeichern im Wiki - ohne zu Veröffentlichen - ist mir nicht bekannt. Ich möchte gern in meinem Benutzerkonto einen (nichtöffentlichen) Ort haben, an dem ich Inhalt abspeichern kann. Der Inhalt soll bereits in Seiten organisiert sein, bei denen ich einen Bezug zu den anvisierten Artikeln setzen kann. Wenn ich also den Artikel X rundumerneuern oder neu schreiben möchte, soll mein Entwurf einer neuen Seitenversion schon mit dem bestehenden Artikel X verknüpft sein. Änderungen am bestehenden Artikel X sollen mir auch angezeigt werden.

Vorschlagende Person

Ziko (Diskussion) 15:40, 4. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Ziko (Einreichende Person)
  2. Pro -- Marcus Cyron Reden 10:23, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro Schnark 11:30, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Jordi (Diskussion) 15:29, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro--grim (Diskussion) 15:56, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro--Orgelputzer (Diskussion) 16:01, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro Zabia (Diskussion) 17:08, 20. Jun. 2017 (CEST) Das wäre toll, ich könnte da alle meine Dateien sichern, die ich für Wikipedia oder Wikisource langfristig unbedingt benötige![Beantworten]
  9. Pro --Frank Schulenburg (Diskussion) 18:33, 20. Jun. 2017 (CEST)[Beantworten]
  10. Pro --  Sir Gawain Disk. 18:58, 20. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Holder (Diskussion) 20:03, 20. Jun. 2017 (CEST)[Beantworten]
  12. Pro Gubeko (Diskussion) 20:50, 20. Jun. 2017 (CEST)[Beantworten]
  13. Pro --SkiFreak99 (Diskussion) 00:26, 21. Jun. 2017 (CEST)[Beantworten]
  14. Pro --MGChecker – (📞| 📝| Bewertung) 20:17, 21. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Pelz (Diskussion) 22:38, 21. Jun. 2017 (CEST)[Beantworten]
  16. Pro --HHill (Diskussion) 13:08, 22. Jun. 2017 (CEST)[Beantworten]
  17. Pro --ArchibaldWagner (Diskussion) 20:01, 22. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Daniel749 Disk. (STWPST) 21:29, 23. Jun. 2017 (CEST)[Beantworten]
  19. Pro Ich finde die Implementation dieser Funktion im Phabricator gut. Warum auch nicht für MediaWiki? -- Freddy2001 DISK 11:57, 24. Jun. 2017 (CEST)[Beantworten]
  20. Pro --RotWeisserHai (Diskussion) 13:55, 24. Jun. 2017 (CEST)[Beantworten]
  21. Pro --Christian (Diskussion) 19:58, 24. Jun. 2017 (CEST)[Beantworten]
  22. Pro ----wollewoox (Diskussion) 15:32, 25. Jun. 2017 (CEST)[Beantworten]
  23. Pro --DomenikaBo (Diskussion) 21:54, 25. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Z thomas Thomas 08:11, 26. Jun. 2017 (CEST)[Beantworten]
  25. Pro --Sophiston (Diskussion) 00:45, 27. Jun. 2017 (CEST) Visual SourceSafe für die Wiki :-)[Beantworten]
  26. Pro --Thomas Obermair 4 (Diskussion) 16:18, 28. Jun. 2017 (CEST)[Beantworten]
  27. Pro -- hgzh 19:26, 29. Jun. 2017 (CEST)[Beantworten]
  28. Pro --Sebastian Wallroth 22:20, 29. Jun. 2017 (CEST)[Beantworten]
  29. Pro -- Mboesch (Diskussion) 11:24, 1. Jul. 2017 (CEST)[Beantworten]
  30. Kontra Das bringt diverse Probleme mit sich. Außerdem ist Wikipedia nicht für derartiges gedacht. Stattdessen soll man häufiger Zwischenstände abspeichern. Zum Beispiel weil es in der Zwischenzeit Änderungen anderer Nutzer geben könnte. Außerdem gibt es zwei Alternativlösungen: 1) in einem Textdokument oder einem Pastebin oÄ abspeichern 2) den Inhalt (bzw Teile davon) bloß als Kommentar (<!--Kommentar--->) hinzufügen. --Fixuture (Diskussion) 19:21, 1. Jul. 2017 (CEST)[Beantworten]
  31. ProDerHexer (Disk.Bew.) 21:22, 1. Jul. 2017 (CEST)[Beantworten]
  32. Pro --Drahreg01 (Diskussion) 22:48, 1. Jul. 2017 (CEST)[Beantworten]
  33. Kontra Das verleitet zu einem nicht-kooperativen Arbeitsstil und ist nicht wiki-gemäß. Bitte den Artikel- oder Benutzerdiskussionsnamensraum für Entwürfe nutzen, auch damit andere mit dem Angefangenen weitermachenkönnen, wenn der Originalautor mal keine Lust oder Zeit mehr zum Weiterarbeiten hat. --dealerofsalvation 10:07, 2. Jul. 2017 (CEST)[Beantworten]
  34. Pro "Als Entwurf nichtöffentlich speichern" in eine Mini-Cloud. Sofern Bearbeitungskonflikte wie üblich abgefangen werden können, gerne mit späterer Veröffentlichung im Ursprungsartikel per Knopf. Ansonsten nur als Textablage für evtl. Veröffentlichung per Copy & Paste. Nicht jedes Gedankenfragment möchte man öffentlich notieren. --Sitacuisses (Diskussion) 10:59, 2. Jul. 2017 (CEST)[Beantworten]
  35. Kontra -- Zustimmung zu dealer. PAB (Diskussion) 20:42, 2. Jul. 2017 (CEST)[Beantworten]
  36. Pro --Devotus (Diskussion) 20:48, 2. Jul. 2017 (CEST)[Beantworten]
  37. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Denkbar wäre z.B. ein offline-Programm, welches Quelltext richtig anzeigen kann. So könnte man den Quelltext in einem .txt-Dokument speichern und ändern und zwischendurch überprüfen, wie er online aussehen würde. Andere Möglichkeiten gehen natürlich auch.[Beantworten]
  38. Kontra --PerfektesChaos 23:49, 2. Jul. 2017 (CEST) BNR-Inhalte müssen weltweit öffentlich sein; was nicht einsehbar sein soll, gehört auf die private Festplatte. BNR-Seiten dürfen nur mit dem Endzweck der Verbesserung der Enzyklopädie angelegt werden, und dass dies eingehalten wird, gewährleistet die soziale Kontrolle der gesamten Community. Geheime Wikiseiten gibt es nur für Schiedsgerichte, WMF&Co. usw. Auf nicht öffentlich einsehbaren Seiten kann auf WMF-Servern megabyteweise Privatkram bis hin zur Vorbereitung von Straftaten deponiert werden; da macht schon WikiMediaLegal nicht mit, von MB mal ganz zu schweigen.[Beantworten]
  39. Pro --Gruß Michael Hoefler50 Diskussion 21:09, 4. Jul. 2017 (CEST)[Beantworten]

Auch nur Teile von Quellcode im MediaViewer kopierbar machen

[Quelltext bearbeiten]
Was ist das Problem?

Wenn ich Artikel, Infoboxen oder Wikidata-Objekte bebildere, brauche ich den Dateinamen des Bildes, wie ich es auf Wikimedia Commons finde. Den Dateinamen gebe ich dann direkt ein, oder mit etwas Quellcode, den ich schnell eintippe. Den MediaViewer habe ich abgeschaltet, weil ich mehrere Klicks brauche, um "Einbetten" zu erreichen. Außerdem wird mir dort ein Quellcode angeboten, in dem viel zu viel Code steht, zum Beispiel: [[File:201610 bingen rhein vom niederwald.jpg|thumb|201610 bingen rhein vom niederwald]] Das Dumme ist: Der MediaViewer erlaubt mir nur, den gesamten Quellcode zu kopieren (oder auch nur zu markieren).

In den meisten Fällen müsste ich, wenn ich diesen Code verwenden würde, ganz viel Code wieder per Hand löschen, weil ich ihn nicht brauche oder so nicht haben will. Ich will nicht "File", sondern "Datei" oder das entsprechende Wort in einer anderen Sprache; ich will keine Bildunterschirft mitkopiert haben, weil ich so etwas meist selbst schreibe. Oft will ich ganz einfach nur den Dateinamen, oft sogar ohne "Datei:" davor.

Wen betrifft das Problem besonders?

Daher ist für mich als aktiver Bildverwender der MediaViewer ziemlich unbrauchbar.

Lösungsvorschlag

Es müsste möglich sein, einfach nur einen Teil des Quellcodes zu markieren und zu kopieren.

Vorschlagende Person

Ziko (Diskussion) 21:12, 4. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Ziko (Einreichende Person)
  2. Pro Michi 18:59, 21. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Thomas Obermair 4 (Diskussion) 16:18, 28. Jun. 2017 (CEST)[Beantworten]

Neuer Bearbeitungsmodus bei der Vorlagenprogrammierung

[Quelltext bearbeiten]
Was ist das Problem?

Bei der Hilfe:Vorlagen/Programmierung also das Editieren im Namensraum "Vorlage:" werden viele Funktionen und Variablen genutzt. Schaut man sich den Code einer häufig verwendeten Vorlage (Vorlage:Denkmalliste1 Tabellenzeile siehe Beispiel) an, wird der Laie kaum etwas verstehen. Selbst für den Fortgeschrittenen ist das nicht immer einfach. Die Fehlersuche ist schwierig.

Beispiel:

<includeonly>|- id="{{anchorencode:{{{Nummer|}}}}}" style="vertical-align:top"
| style="background:#eee;text-align:center" | {{#if: {{{Bild|}}} | [[Datei:{{{Bild}}}|{{#if: {{{Abmessungen|}}} | {{{Abmessungen}}} | 120x120px }}|{{{Bezeichnung|}}}]]{{#if: {{{Commonscat|}}} | <br /><small>[[commons:Category:{{{Commonscat}}}|weitere Bilder]]</small> }} | {{#if: {{{NS|}}} | {{#if: {{NAMESPACE}} | <!-- nur im ANR --> | {{Bilderwunsch/encode |KoordLat={{{NS|}}} |KoordLon={{{EW|}}} |Name={{{Bezeichnung|}}}, {{{Adresse|}}} }} }} }} }}
| {{{Bezeichnung|}}}
| data-sort-value="{{#invoke: AdressenSort | convert |1={{{Stadtbezirk|}}}{{{Ortsteil|}}}{{{Adresse|0}}}}}" | {{#if: {{{Stadtbezirk|}}} | {{{Stadtbezirk}}}– }}{{#if: {{{Ortsteil|}}} | {{{Ortsteil}}}<br /> }}{{{Adresse|}}}{{#if: {{{NS|}}}{{{EW|}}} | <br />{{Coordinate |simple=y |NS={{{NS|}}} |EW={{{EW|}}} |type=landmark |region={{{Region|}}} |name={{#invoke: WLink | getPlain |1={{#if: {{{Beschriftung|}}} | {{{Beschriftung}}} | {{#if: {{{Bezeichnung|}}} | {{{Bezeichnung}}} | {{{Adresse|}}} }} }} }}|text=Karte }} }}
| {{{Beschreibung|}}}
| {{{Bauzeit|}}}
| style="text-align:right;white-space:nowrap" | {{#if: {{{Eintragung|}}} | {{{Eintragung}}} }}
| style="text-align:right" | {{#if: {{{Nummer|}}}{{{Wikidata|}}}{{{DDB|}}} | {{#if:{{{Nummer|}}}| {{{Nummer|}}} <br />}}{{#if:{{{DDB|}}}|<small>[https://www.deutsche-digitale-bibliothek.de/item/{{{DDB|}}} DDB]</small><br />}}{{#if:{{{Wikidata|}}}|<small>[[:d:{{{Wikidata|}}}|Wikidata]]</small>}}}}</includeonly><noinclude>
{{Dokumentation}}

[[Kategorie:Vorlage:Denkmaltabelle]]
</noinclude>
Wen betrifft das Problem besonders?

Über die Jahre habe ich die eine oder andere Vorlage verbessert oder geschrieben. Ich habe festgestellt, die allermeiste Fehlersuche ging in Richtung über die Suche der richtigen Anzahl der öffnenden und schließenden geschweiften Klammern.

Lösungsvorschlag

Ein zusätzlicher Bearbeitungsmodus, neben dem reinen Quelltext-Editor soll ein Editor für die Programmierung zur Verfügung stehen. Dieser soll:

  1. Die Zeilensprünge und Leezeichen nicht beachten (aber auch nicht löschen), dafür
  2. Die strukturierte Ansicht anhand der öffnenden und schließenden Klammer ermöglichen.
  3. Eine farbliche Struktur des Codes ermöglichen
  4. Anzeigen wenn "|" erlaubt ist oder nicht (innerhalb einer Funktion ist die Tabellenstruktur nicht möglich und muss über eine Vorlage maskiert werden); gegebenfalls kann dies auch intelligent übersetzt werden.
  5. Eingebaute Funktionen erwarten Parameter
  6. Meldung, wenn die Anzahl der öffnenden und schließenden Klammer nicht stimmt (evtl. ist das gewollt aber das soll vor dem Speichern explizit bestätigt werden). Die Stelle an der mutmaßlich eine schließende Klammer fehlt soll markiert sein.
  7. Das Umschalten zwischen dem der reinen Quell-Code-Bearbeitung und der erweiterten Vorlagen-Programmierung sollte verlustfrei möglich sein.

Dieser Bearbeitungsmodus könnte ähnlich so aussehen:

Vorschlagende Person

Atamari (Diskussion) 00:59, 5. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Atamari (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:19, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro Michi 19:07, 21. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Nichtich (Diskussion) 23:00, 23. Jun. 2017 (CEST)[Beantworten]
  5. Pro --DomenikaBo (Diskussion) 21:55, 25. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Sophiston (Diskussion) 00:46, 27. Jun. 2017 (CEST) Wiki Syntax Editor ist gut[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:19, 28. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Sebastian Wallroth 22:22, 29. Jun. 2017 (CEST)[Beantworten]
  9. Pro -- X:: black ::X (Diskussion) 17:45, 2. Jul. 2017 (CEST)[Beantworten]
  10. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Auch, wenn einfache Editoren, wie Notepad++ bereits erkennen, welche Klammern zusammengehören, so halte ich es für besser, wenn es einen extra-Editor geben würde.[Beantworten]
  11. Pro --PerfektesChaos 23:45, 2. Jul. 2017 (CEST) (wobei es syntaxmäßig nur in Trivialfällen normalen Editoren möglich ist, das zu erkennen, weil die verzweigten Konstrukte der Vorlagenprogrammierung nicht notwendigerweise ausgeglichen sind).[Beantworten]

Nicht-darstellbare Zeichen sollen auch nicht gespeichert werden

[Quelltext bearbeiten]
Was ist das Problem?

Zeichen, die auch nicht dargestellt werden, sollen auch nicht gespeichert werden. Es gehen einige Bots durch den ganzen Datenbestand und „jagen“ diesen Zeichen hinterher, Beispiel. Solche Edits müssen nicht sein.

Wen betrifft das Problem besonders?
Lösungsvorschlag

Direkt beim Speichern soll die Eingabe durch solche Zeichen bereinigt werden. Es kann jedoch eine White-List existieren, in der beispielsweise das Weiches Trennzeichen eingetragen ist. Vielleicht ist es auch besser das weiche Trennzeichen und andere erlaubten nicht-darstellbare Zeichen umzuwandeln (Beispiel in: &shy;)

Vorschlagende Person

Atamari (Diskussion) 01:53, 5. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Atamari (Einreichende Person)
  2. Pro Jordi (Diskussion) 15:20, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Wikifreund (Diskussion) 23:49, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --MGChecker – (📞| 📝| Bewertung) 20:11, 21. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Furfur Diskussion 23:06, 21. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:19, 28. Jun. 2017 (CEST)[Beantworten]
  7. Abwartend resp. Kontra --ProloSozz (Diskussion) 23:50, 1. Jul. 2017 (CEST) Unsichtbare Zeichen sollten sichtbar gemacht werden und nicht "nicht gespeichert".[Beantworten]
  8. Pro Bei bestimmten Vorkommen (Links, Kategorien, Lemmata) sollen bestimmte unpassende Zeichen nicht ohne Weiteres gespeichert werden. Da es möglich ist, sie per Bot nachträglich zu entfernen, sollte auch ein Abfangen vor dem Speichern möglich sein. --Sitacuisses (Diskussion) 11:10, 2. Jul. 2017 (CEST)[Beantworten]
  9. Pro, siehe Vorredner --Zaccarias (Diskussion) 12:13, 2. Jul. 2017 (CEST)[Beantworten]
  10. Pro --PAB (Diskussion) 20:43, 2. Jul. 2017 (CEST)[Beantworten]
  11. Kontra --PerfektesChaos 23:50, 2. Jul. 2017 (CEST) Nicht-darstellbare Zeichen sind vielleicht nicht sichtbar; sie sind aber bedeutungstragend, inhaltlich erforderlich weil Inhalte ändernd und können somit nicht pauschal unterdrückt werden.[Beantworten]

Artikel mit Versionsgeschichte kopieren

[Quelltext bearbeiten]
Was ist das Problem?

Es ist gelegentlich sinnvoll, Inhalte aus einem zu gross werdenden Artikel in einen neuen "Hauptartikel" zum Teilaspekt auszulagern. Wenn man dabei die Versionsgeschichte erhalten möchte, was von vielen Benutzern als die beste oder sogar einzig akzeptable lizenzkonforme Vorgehensweise angesehen wird, geht das nur umständlich über einen Importupload-Wunsch, siehe Hilfe:Artikelinhalte auslagern. Es gibt nur wenige Importeure, die solche Wünsche bearbeiten können, und von diesen sind nicht alle aktiv. Das Verfahren funktioniert zwar, hängt aber damit an wenigen aktiven Nutzern.

Wen betrifft das Problem besonders?

Alle Benutzer, die Artikelinhalte in einen neuen Artikel auslagern möchten.

Lösungsvorschlag

Angepasst, siehe Beitrag von Johanna Strodt (WMDE) in der Diskussion. Wie ich aus der Diskussion erfahren habe, gibt es bereits eine Mediawiki-Extension, mit der dieser Wunsch erfüllt werden könnte: mw:Extension:Duplicator. Diese ist aber in der Wikipedia nicht aktiv und hat zudem einen Bug, der wohl noch behoben werden sollte. Der technische Wunsch würde also dahingehen, den Bug in der Extension zu beheben und die technischen Anpassungen vorzunehmen, um die Extension für einen Einsatz in der Wikipedia geeignet zu machen. Richtigerweise wurde auch angemerkt, dass die Community ein solches Feature begrüssen und dessen Einsatz regeln müsste. Sollte der Wunsch unter "ferner liefen" landen, wäre das dann wohl nicht wahrscheinlich. - Schön wäre eine einfache zusätzliche Funktion "Kopieren" neben dem Reiter "Verschieben". Damit würde eine Kopie des Artikels samt Versionsgeschichte erzeugt, die anschliessend auf die auszulagernden Inhalte reduziert werden könnte. Das ist zwar keine Lösung für Fälle, in denen Inhalte in einen anderen, bereits bestehenden Artikel ausgelagert werden sollen, wäre aber sicher schon oft eine Erleichterung.

Anmerkungen

Dass das umfassende Importeur-Recht nur restriktiv an wenige Benutzer vergeben wird, ist im Grunde in Ordnung, da man mit dem Recht bei falscher Anwendung auch ziemliches Chaos verursachen könnte. Eine einfache Funktion "Artikel kopieren" wäre aber relativ risikolos und sollte m.E. allen Benutzern zur Verfügung stehen, die auch Artikel verschieben können (will man sie sicherheitshalber nur Admins geben, soll mir das aber auch recht sein).

Vorschlagende Person

Gestumblindi 21:46, 7. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Gestumblindi (Einreichende Person)
  2. Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Jordi (Diskussion) 15:27, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --  Sir Gawain Disk. 19:00, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Conny 22:24, 20. Jun. 2017 (CEST).[Beantworten]
  6. Pro --Wikifreund (Diskussion) 23:50, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Michi 19:07, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --MGChecker – (📞| 📝| Bewertung) 20:16, 21. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 00:55, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Jossi (Diskussion) 12:56, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Daniel749 Disk. (STWPST) 21:34, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Gr1 (Diskussion) 10:47, 28. Jun. 2017 (CEST)[Beantworten]
  13. Pro --Kein Einstein (Diskussion) 15:58, 28. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Thomas Obermair 4 (Diskussion) 16:20, 28. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Sebastian Wallroth 22:24, 29. Jun. 2017 (CEST)[Beantworten]
  16. Pro Brackenheim 19:10, 1. Jul. 2017 (CEST) noch immer dafür, vielleicht klappt es endlich mal in dieser Runde ...[Beantworten]
  17. ProDoc TaxonDisk.WikiMUCWikiliebe?! 19:28, 1. Jul. 2017 (CEST)[Beantworten]
  18. Pro --DomenikaBo (Diskussion) 19:37, 1. Jul. 2017 (CEST)[Beantworten]
  19. Pro --Luke081515 20:01, 1. Jul. 2017 (CEST)[Beantworten]
  20. Pro -- Marcus Cyron Reden 20:18, 1. Jul. 2017 (CEST)[Beantworten]
  21. Pro --Kritzolina (Diskussion) 20:38, 1. Jul. 2017 (CEST)[Beantworten]
  22. Pro --Maimaid Wikiliebe?! 21:07, 1. Jul. 2017 (CEST)[Beantworten]
  23. ProDerHexer (Disk.Bew.) 21:26, 1. Jul. 2017 (CEST)[Beantworten]
  24. Pro --Partynia RM 23:09, 1. Jul. 2017 (CEST)[Beantworten]
  25. Pro resp. Abwartend --ProloSozz (Diskussion) 00:14, 2. Jul. 2017 (CEST) ggf. müßte vor Freischaltung (irgend) ein Admin "genehmigen" (das sollte irgendeiner sein können, nicht nur spezielle).[Beantworten]
  26. Pro --Flominator 10:27, 2. Jul. 2017 (CEST)[Beantworten]
  27. Pro --PAB (Diskussion) 20:44, 2. Jul. 2017 (CEST)[Beantworten]
  28. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Da jeder verschieben darf, sollte auch jeder kopieren dürfen. Nicht nur Admins.[Beantworten]
  29. Pro -- Mr N (Diskussion) 22:08, 2. Jul. 2017 (CEST)[Beantworten]
  30. Pro --PerfektesChaos 23:47, 2. Jul. 2017 (CEST) Pro zur Reparatur der Extension, sofern erforerlich. Contra zu allem, was Normalbenutzern das Duplizieren Tausender von Versionen mit eine Klick ermöglichen würde; das liegt weder in der Kompetenz dieser Umfrage, noch wäre das Rechte-Manangement trivial zu programmieren, zu konfigurieren oder irgendwas mal eben für irgendwen freizugeben. Benutzerrechte sind zuallererst Community-Angelegenheit.[Beantworten]

Spaltenweise Ausrichtung in Tabellen

[Quelltext bearbeiten]
Was ist das Problem?

Es können die ganzen Tabellen linksbündig, rechtsbündig oder zentriert formatiert werden. Will man jedoch nur eine Spalte rechtsbündig (z.B. für Zahlen), alle übrigen Spalten jedoch linksbündig haben, muss für jede Zelle die Rechtsbündigkeit eingegeben werden.

Wen betrifft das Problem besonders?

Bei langen Tabellen oder/und Tabellen mit zahlreichen Spalten mit verschiedener Formatierung (links, rechts, zentriert) ist das sehr lästig.

Lösungsvorschlag

Es sollte eine Möglichkeit geben, im Header der Tabelle die Formatierung (links, rechts, zentriert) jeder einzelnen Spalte anzugeben. - Optimal finde ich eine 3-stufige Hierarchie der Formatierung:

  1. die Formatierung der einzelnen Zelle = höchste Priorität
  2. die Formatierung der einzelnen Spalte = mittlere Priorität
  3. die Formatierung der ganzen Tabelle = niedrigste Priorität

Damit wären alle Möglichkeit offen, mit möglichst wenig Anweisungen die gewünschte Formatierung zu erreichen.

Vorschlagende Person

Br. Klaus (Diskussion) 15:00, 10. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Br. Klaus (Einreichende Person)
  2. Pro Jordi (Diskussion) 15:25, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Rjh (Diskussion) 16:25, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro Kontrollstelle Kundl 18:37, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Wikifreund (Diskussion) 23:51, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro GodeNehler (Diskussion) 05:55, 21. Jun. 2017 (CEST)[Beantworten]
  7. Pro --MGChecker – (📞| 📝| Bewertung) 20:18, 21. Jun. 2017 (CEST)[Beantworten]
  8. Pro --KorrekTOM (Diskussion) 13:14, 22. Jun. 2017 (CEST)[Beantworten]
  9. Pro --ArchibaldWagner (Diskussion) 20:10, 22. Jun. 2017 (CEST)[Beantworten]
  10. Pro mauriceKA (Diskussion) 13:13, 23. Jun. 2017 (CEST)[Beantworten]
  11. Pro --Atamari (Diskussion) 14:39, 23. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Daniel749 Disk. (STWPST) 21:35, 23. Jun. 2017 (CEST)[Beantworten]
  13. Pro --DomenikaBo (Diskussion) 21:58, 25. Jun. 2017 (CEST)[Beantworten]
  14. Pro --Z thomas Thomas 08:14, 26. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Ak ccm (Diskussion) 14:36, 28. Jun. 2017 (CEST)[Beantworten]
  16. Pro --Thomas Obermair 4 (Diskussion) 16:20, 28. Jun. 2017 (CEST)[Beantworten]
  17. Pro --Sebastian Wallroth 22:25, 29. Jun. 2017 (CEST)[Beantworten]
  18. ProDoc TaxonDisk.WikiMUCWikiliebe?! 21:11, 1. Jul. 2017 (CEST)[Beantworten]
  19. Pro --Drahreg01 (Diskussion) 22:49, 1. Jul. 2017 (CEST)[Beantworten]
  20. Pro --ProloSozz (Diskussion) 00:15, 2. Jul. 2017 (CEST)[Beantworten]
  21. Pro --PAB (Diskussion) 20:44, 2. Jul. 2017 (CEST)[Beantworten]

Antworten auf Diskussionsseiten vereinfachen

[Quelltext bearbeiten]
Was ist das Problem?

Die Diskussionsseiten sind insbesondere für Neulinge eine echte Herausforderung, die viel nicht meistern. Insbesondere das Einrücken und Signieren wird immer wieder falsch gemacht.

Während man von anderen Plattformen gewohnt ist, einfach in einem Antwort-Feld unter den bisherigen Diskussionsbeiträgen zu antworten, muss man in der Wikipedia...

  • (auch bei langen Diskussionen) erst bis zum Anfang des Abschnitts hochscrollen.
  • dort auf "Abschnitt bearbeiten" klicken.
  • im sich dann öffnenden (kryptischen Quelltext) wieder ganz nach unten Scrollen.
  • mit der richten Anzahl von Doppelpunkten einrücken.
  • dann den Text eingeben
  • diesen mit -- ~~~~ signieren.
  • und abschließend noch "veröffentlichen"

Das ist wahnsinnig kompliziert und wiederspricht so dem von anderen Webseiten gewohnten verhalten, dass Neulinge häufig daran scheitern. Wodurch uns nicht nur wertvolle Beiträge verloren gehen, sondern auch etliche Folgeprobleme entstehen.

Die WMF versucht diesem Problem seit Jahren mit Neuentwicklungen wie mw:Extension:LiquidThreadsLiquidThreads und Flow zu begegnen. Da es dabei zu etlichen Problemen kam und diese einen harten Schnitt erfordern, ist es noch nicht absehbar ob und wann diese jemals in der de.Wikipedia eingesetzt werden. Es erscheint daher notwendig, eine Lösung zu implementieren, die die bestehenden WikiText-basierenden Diskussionsseiten so zu verbessern, dass sie auch für WikiText-unerfahrene Nutzer bedienbar werden.

Wen betrifft das Problem besonders?

Alle Nutzer, die die Diskussionseiten nutzen

Lösungsvorschlag

Progressive Verbesserung der bestehenden Diskussionsseiten durch Einbau einer nutzerfreundlichen Antwortfunktion ohne dabei die bestehende Funktionalität zu beeinträchtigen.

Mittels JavaScript° liese sich unter jedem Abschnitt* ein "Antworten"-Button integrieren, der bei Click an dieser Stelle ein Eingabefeld öffnet. In dieses kann man dann wie von anderen Seiten gewohnt den eigenen Beitrag eintragen. Beim Abspeichern wird dieser Text dann automatisch an der richtigen Stelle in den WikiText eingefügt, entsprechend eingerückt und falls nötig signiert. Die Eingabe von WikiText wäre möglich aber nicht notwendig. Etwaige Eingaben (von Signaturen oder Einrückungen) würden die Standardfunktionen überschreiben.

Die eigentliche Implentierung sollte kein großes Problem sein. Die größte Schwierigkeit wäre der Umgang mit Bearbeitungskonflikten - aber selbst wenn die Seite dabei in das bisherige Standardverhalten zurückfallen würde, wäre man noch besser als der Status quo.

° Wenn kein JS aktiviert ist oder irgendwas schiefläuft, funktionieren die Diskussionseiten einfach weiter wie bisher.

Anmerkungen

Ich plane im Rahmen des Wikimania-Hackathons einen Prototypen anzugehen, der dann weiter entwickelt werden könnte. Martin K. (Diskussion) 17:40, 10. Jun. 2017 (CEST)[Beantworten]

Hinweise von Johanna Strodt (WMDE) (Diskussion) 14:17, 15. Jun. 2017 (CEST):[Beantworten]

  • Ein solcher “Hack” wäre im Rahmen des Projekts Technische Wünsche nicht unmöglich – aber es wäre eben ein Hack, der uns vielleicht auch wieder um die Ohren fliegen kann. Ein Grund ist, dass Diskussionsseiten vor allem auf Konventionen basieren und darauf wäre diese Lösung auch angewiesen. Wenn die Konventionen auf einzelnen Diskussionsseiten nicht eingehalten werden, kann diese Lösung das nicht auffangen.
  • Ein Hack kann keine globale Lösung sein. Wir könnten maximal eine Lösung für die deutsche Wikipedia anbieten, müssten aber auch dies im Detail in einer ausführlichen Analyse besprechen, falls es der Wunsch in die Topliste schafft.
    Vorschlagende Person

Martin K. (Diskussion) 17:40, 10. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Martin Kraft (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:24, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Z thomas Thomas 10:57, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro -- Karl432 (Diskussion) 15:14, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Gnom (Diskussion) 17:37, 20. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Claell (Diskussion) 19:10, 20. Jun. 2017 (CEST)[Beantworten]
  7. Pro Gubeko (Diskussion) 20:53, 20. Jun. 2017 (CEST)[Beantworten]
  8. Pro Conny 22:25, 20. Jun. 2017 (CEST).[Beantworten]
  9. Pro GodeNehler (Diskussion) 05:55, 21. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Morten Haan 🎲 Wikipedia ist für Leser daSkin-Entwurf 00:55, 22. Jun. 2017 (CEST)[Beantworten]
  11. Pro Iva 10:44, 22. Jun. 2017 (CEST)[Beantworten]
  12. Pro --Minihaa (Diskussion) 12:36, 23. Jun. 2017 (CEST)[Beantworten]
  13. Pro mauriceKA (Diskussion) 13:15, 23. Jun. 2017 (CEST)[Beantworten]
  14. Pro -- ShWh3F (Diskussion) 21:15, 23. Jun. 2017 (CEST)[Beantworten]
  15. Pro --Daniel749 Disk. (STWPST) 21:42, 23. Jun. 2017 (CEST)[Beantworten]
  16. Kontra Notwendig ist Wechsel zu einem benutzerfreundlichen System wie Flow. -- Nichtich (Diskussion) 22:57, 23. Jun. 2017 (CEST)[Beantworten]
  17. Pro --DomenikaBo (Diskussion) 21:58, 25. Jun. 2017 (CEST)[Beantworten]
  18. Pro --Incabell (Diskussion) 17:39, 27. Jun. 2017 (CEST)[Beantworten]
  19. Kontra Plädiere ebenfalls für einen Wechsel zu einem benutzerfreundlichen System; Flow bietet sich an. --Ak ccm (Diskussion) 15:02, 28. Jun. 2017 (CEST)[Beantworten]
  20. Pro --Thomas Obermair 4 (Diskussion) 16:21, 28. Jun. 2017 (CEST)[Beantworten]
  21. Pro für Lösung des Problems --Sophiston (Diskussion) 12:54, 29. Jun. 2017 (CEST)[Beantworten]
  22. Kontra für Lösungsvorschlag --Sophiston (Diskussion) 12:54, 29. Jun. 2017 (CEST)[Beantworten]
  23. Pro Für eine Lösung des Problems. --Sebastian Wallroth 22:26, 29. Jun. 2017 (CEST)[Beantworten]
  24. Pro --Häuslebauer (Diskussion) 17:43, 30. Jun. 2017 (CEST)[Beantworten]
  25. Pro -- Mboesch (Diskussion) 11:26, 1. Jul. 2017 (CEST)[Beantworten]
  26. Pro --Drahreg01 (Diskussion) 22:52, 1. Jul. 2017 (CEST)[Beantworten]
  27. Pro --PAB (Diskussion) 20:45, 2. Jul. 2017 (CEST)[Beantworten]
  28. Pro --Devotus (Diskussion) 20:46, 2. Jul. 2017 (CEST)[Beantworten]

[Quelltext bearbeiten]
Was ist das Problem?
  • Derzeit wird bei Verwendung des Tools „Link [einfügen]“ () in der Quelltext-Toolbar lediglich beim Verlinken einer Begriffsklärungsseite entsprechend darauf hingewiesen, nicht jedoch bei Weiterleitungen und selbstreferenziellen Links („Selbst- / Rückverlinkungen“).
  • Darüber hinaus fehlt es bislang an der Möglichkeit, hierüber auch explizit Artikelabschnittslinks zu verlinken.
  • Zudem werden bei diesem Tool sowohl interne [Wiki-]Links als auch externe [Web]Links nicht synchronisiert, nachdem sich das Linkziel geändert hat.
Wen betrifft das Problem besonders?

Alle aktiven Nutzer

Lösungsvorschlag

Das Tool könnte dahingehend optimiert werden, dass

  • nicht nur wie bisher bei BKL-Links, sondern auch bei Eingabe von Weiterleitungen und selbstreferenziellen Links („Selbst- / Rückverlinkungen“) ein entsprechender Warnhinweis eingeblendet wird.

Ergänzend dazu folgender Vorschlag: Wäre es global sinnvoll und machbar,

  • bei Verwendung von auch Abschnittsüberschriften angezeigt zu bekommen (bspw. durch Drücken der Raute nach Eingabe des Lemmas) und
  • sowohl eingebundene interne Wiki-Links als auch externe Weblinks so zu synchronisieren, dass
    • bei Eingabe von Wiki-Links in – auch für einzelne Abschnitte – stets die aktuelle Überschrift in der Autovervollständigung angezeigt wird und
    • Wikilinks bei Änderungen von Artikel- (Lemmata) und Abschnittsüberschriften in den Wiki-Projekten bzw. Weblinks bei Verschiebungen auf externen Websites automatisch angepasst werden?
      Vorschlagende Person

Erdic (Diskussion) 01:22, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Erdic (Einreichende Person)
  2. Pro --Dominic Z. (Diskussion) 18:10, 22. Jun. 2017 (CEST)[Beantworten]
  3. Pro --DomenikaBo (Diskussion) 21:59, 25. Jun. 2017 (CEST)[Beantworten]
    Pro --Curc (Diskussion) 20:52, 27. Jun. 2017 (CEST) Stimme gestrichen, Benutzer ist nach eigener Angabe identisch mit Benutzer:Erdic [3] --Superbass (Diskussion) 20:33, 29. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Thomas Obermair 4 (Diskussion) 16:21, 28. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Sophiston (Diskussion) 12:58, 29. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Sebastian Wallroth 22:27, 29. Jun. 2017 (CEST)[Beantworten]
  7. Pro -- Mr N (Diskussion) 22:30, 2. Jul. 2017 (CEST) Wie Praktisch.[Beantworten]

Visual Editor: Verlinkungen und weitere Formatierungsmöglichkeiten in Vorlagen

[Quelltext bearbeiten]
Was ist das Problem?

Vorlagen im Visual Editor erlauben in Eingabefeldern nicht immer das interne Verlinken. Beispiel: Ich klicke im VE auf Einfügen > Vorlage, tippe "Literatur" ein und wähle "Vorlage hinzufügen". Ich gebe dann die bibliografischen Daten dort ein, also Autor/in, Titel usw. Manchmal ist es sinnvoll, innerhalb dieser Daten auf Artikel zu verlinken, z. B. den Namen einer Autorin mit einem zu Wikilink versehen, wenn es über sie bereits einen Artikel gibt. Das kann ich in gewohnter Weise machen, indem ich vor und hinter dem Namen je zwei eckige Klammern tippe. Dass ich das kann, liegt aber daran, dass ich noch gelernt habe, Wikitext zu schreiben. Wer von Anfang an nur den VE benutzt hat, kennt das Klammernsystem gar nicht mehr. Es braucht deshalb innerhalb des Formulars jeder Vorlage den Kettenglied-Button zum Verlinken. Auch andere Formatierungen wie Kursivschreibung und Sonderzeichen innerhalb von Formularfeldern sollten möglich sein.

Wen betrifft das Problem besonders?

Alle, die den Visual Editor benutzen.

Vorschlagende Person

Mushushu (Diskussion) 14:10, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Mushushu (Einreichende Person)
  2. Pro --Thomas Obermair 4 (Diskussion) 16:21, 28. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Sophiston (Diskussion) 13:04, 29. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Sebastian Wallroth 22:29, 29. Jun. 2017 (CEST)[Beantworten]

Android-App: Bearbeitungskonflikte erkennen statt stillschweigend andere Bearbeitung überschreiben

[Quelltext bearbeiten]
Was ist das Problem?

Wenn man mit der Android-App einen Abschnitt bearbeitet, dann werden etwaige Bearbeitungskonflikte nicht erkannt, sondern etwaige zwischenzeitliche Bearbeitungen anderer stillschweigend überschrieben Beispiel. Nicht nur, dass dadurch Bearbeitungen verloren gehen, man kann dadurch auch zu Unrecht der absichtlichen Löschung fremder Beiträge beschuldigt werden. Dies ist für mich ein Grund, den Mobil-Editor nicht zu benutzen.

Wen betrifft das Problem besonders?

Alle, die gerne die Android-App benutzen und z. B. mal schnell etwas verbessern wollen. Und letztlich alle, denn alle Beiträge laufen Gefahr, nichtsahnend von Benutzern der Android-App zurückgesetzt werden.

Lösungsvorschlag

Eigentlich müsste man das Bearbeiten in der Android-App solange sperren, bis dieser Mangel behoben ist. Ansonsten, minimale Lösung: Einen Hinweis einblenden, dass jemand anderes den Abschnitt bearbeitet hat und man es nochmal probieren soll. Optimale Lösung: Konfliktbehandlung wie mit der Web-Version

Anmerkungen

Dieses Problem ist auf Phabricator seit langem bekannt, es scheint aber keine Priorität zu genießen.

Vorschlagende Person

dealerofsalvation 15:20, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Dealerofsalvation (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 22:15, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Claell (Diskussion) 19:12, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Taigatrommel (Diskussion) 00:29, 22. Jun. 2017 (CEST)[Beantworten]
  5. Pro mauriceKA (Diskussion) 13:16, 23. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Freddy2001 DISK 11:58, 24. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:22, 28. Jun. 2017 (CEST)[Beantworten]
  8. Pro -- Shoeper 18:09, 30. Jun. 2017 (CEST)[Beantworten]
  9. Pro Schaut aus wie ein Bug. --Fixuture (Diskussion) 19:27, 1. Jul. 2017 (CEST)[Beantworten]
  10. Pro ist auch ein Bug – Doc TaxonDisk.WikiMUCWikiliebe?! 21:13, 1. Jul. 2017 (CEST)[Beantworten]
  11. ProDerHexer (Disk.Bew.) 21:31, 1. Jul. 2017 (CEST)[Beantworten]
  12. Pro -- X:: black ::X (Diskussion) 19:59, 2. Jul. 2017 (CEST)[Beantworten]
  13. Pro --PAB (Diskussion) 20:45, 2. Jul. 2017 (CEST)[Beantworten]
  14. Pro -- Mr N (Diskussion) 22:33, 2. Jul. 2017 (CEST)[Beantworten]

[Quelltext bearbeiten]
Was ist das Problem?

Es gibt Weiterleitungen, die nicht auf einen Artikel sondern auf ein Kapitel in einem Artikel verlinken. Wenn die Kapitelüberschrift verändert wird, landet der Link nicht im Kapitel, sondern "nur" im Artikel.

Wen betrifft das Problem besonders?

Autoren

Lösungsvorschlag

Automatisches Anpassen des Weiterleitungslinks auf Kapitel, wenn das Kapitel angepasst wird.

Vorschlagende Person

Z thomas Thomas 19:33, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Z thomas (Einreichende Person)
  2. Pro --C21H22N2O2 (V • T • E) 14:25, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro DCB (DiskussionBewertung) 22:15, 19. Jun. 2017 (CEST)[Beantworten]
  4. Pro mauriceKA (Diskussion) 13:17, 23. Jun. 2017 (CEST)[Beantworten]
  5. Pro --Curc (Diskussion) 20:53, 27. Jun. 2017 (CEST)[Beantworten]
  6. Pro --Thomas Obermair 4 (Diskussion) 16:22, 28. Jun. 2017 (CEST)[Beantworten]
  7. Pro Siehe dazu bitte den Vorschlag "Beim Werkzeug "Links auf diese Seite" für alle Artikel auf einmal das vollständige Sprungziel ausgeben." und meinen Kommentar dort. --Fixuture (Diskussion) 19:34, 1. Jul. 2017 (CEST)[Beantworten]
  8. Pro --PAB (Diskussion) 20:46, 2. Jul. 2017 (CEST)[Beantworten]
  9. Pro -- Mr N (Diskussion) 22:38, 2. Jul. 2017 (CEST)[Beantworten]

Leerzeichen bei der Überschrift im VE

[Quelltext bearbeiten]
Was ist das Problem?

Wenn ich mit dem Visual Editor einen Artikel schreibe, wird die Überschrift mit

===Überschrift===

eingegeben. Laut deutscher Konvention sollte es

=== Überschrift ===

also mit einem Leerzeichen vor und hinter dem Überschriftentext sein.

Benutzer, die später den Quelltext überprüfen, haben damit dann viel Aufwand, die Leerzeichen zu setzen. Das Gleiche ist auch mit Defaultsort (Visualeditor) und mit Sortierung deutscher Standard. Bei Einfügen von Bildern wird mini in VE verwendet und miniatur wird immer ausgebessert.

Wen betrifft das Problem besonders?

Leute, die mit dem Visualeditor schreiben.

Lösungsvorschlag

Unbekannt.

Vorschlagende Person

Gruß Michael Hoefler50 Diskussion 21:29, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Hoefler50 (Einreichende Person)
  2. Pro DCB (DiskussionBewertung) 22:19, 19. Jun. 2017 (CEST)[Beantworten]
  3. Pro --Z thomas Thomas 10:59, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro --Blik (Diskussion) 16:09, 20. Jun. 2017 (CEST)[Beantworten]
  5. Pro Conny 22:44, 20. Jun. 2017 (CEST).[Beantworten]
  6. Pro Iva 10:49, 22. Jun. 2017 (CEST) war mir bisher gar nicht bewusst, dass es dafür eine Konvention gibt[Beantworten]
  7. Pro mauriceKA (Diskussion) 13:18, 23. Jun. 2017 (CEST)[Beantworten]
  8. Pro --DomenikaBo (Diskussion) 22:02, 25. Jun. 2017 (CEST)[Beantworten]
  9. Pro --Thomas Obermair 4 (Diskussion) 16:23, 28. Jun. 2017 (CEST)[Beantworten]
  10. Pro Und bitte auch generell ein Leerzeichen von Pipes innerhalb von Inline-Vorlagen. --Matthiasb – (CallMyCenter) 01:10, 29. Jun. 2017 (CEST)[Beantworten]
  11. Pro Andim (Diskussion) 10:16, 29. Jun. 2017 (CEST)[Beantworten]
  12. ProDoc TaxonDisk.WikiMUCWikiliebe?! 21:14, 1. Jul. 2017 (CEST)[Beantworten]
  13. Pro -- Das ist eigentlich ein Bug-Report... PAB (Diskussion) 20:47, 2. Jul. 2017 (CEST)[Beantworten]
  14. Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.[Beantworten]

[Quelltext bearbeiten]
Was ist das Problem?

Weblinks veralten heute leider schnell. Da wäre es sicherlich sinnvoll, wenn veraltete Weblinks, die beim Anklicken sonst zu einer Fehlermeldung führen würden, automatisch durch einen geeigneten Archivlink ersetzt würden.

Wen betrifft das Problem besonders?

Die Glaubwürdigkeit von Wikipediaartikeln generell.

Vorschlagende Person

Curc (Diskussion) 23:52, 11. Jun. 2017 (CEST)[Beantworten]

Unterstützung
  1. Pro Curc (Einreichende Person)
  2. Pro Zabia (Diskussion) 17:11, 20. Jun. 2017 (CEST)[Beantworten]
  3. Pro Gelber kaktus (Diskussion) 21:47, 20. Jun. 2017 (CEST)[Beantworten]
  4. Pro mauriceKA (Diskussion) 13:18, 23. Jun. 2017 (CEST)[Beantworten]
  5. Pro -- Nichtich (Diskussion) 23:00, 23. Jun. 2017 (CEST)[Beantworten]
  6. Pro -- Chstdu (Diskussion) 15:16, 26. Jun. 2017 (CEST)[Beantworten]
  7. Pro --Thomas Obermair 4 (Diskussion) 16:23, 28. Jun. 2017 (CEST)[Beantworten]
  8. Pro --Sophiston (Diskussion) 13:25, 29. Jun. 2017 (CEST) Lösungs muss mehr als nur eine deutsche Lösung sein können.[Beantworten]
  9. Pro --Sebastian Wallroth 22:38, 29. Jun. 2017 (CEST)[Beantworten]
  10. Pro --Häuslebauer (Diskussion) 17:47, 30. Jun. 2017 (CEST) Ebenfalls eruieren, ob Wikimedia nicht auch selbst ein Archiv verlinkter Webseiten pflegen kann und automatisch auf dieses bei Belegen verwiesen wird. Es geht ja nicht nur um veraltete Weblinks, sondern auch um mögliche Änderungen an der Seite zwischen Einfügung als Beleg und Aufruf durch den Nutzer. Aber so oder so ist jeder Schritt zu begrüßen, der das manuelle Fixen von 404-Links überflüssig macht.[Beantworten]
  11. Pro -- Shoeper 18:03, 30. Jun. 2017 (CEST)[Beantworten]
  12. Pro Es gibt da allerdings schon diverse Umsetzungen bzw laufende Projekte. Im Englischen Wikipedia gibt es Bots, die Links checken etc. Dort gibt es auch viele Einträge für diesen Vorschlag. Derartige Projekte sollten aber weiterentwickelt und verbessert werden. --Fixuture (Diskussion) 19:31, 1. Jul. 2017 (CEST)[Beantworten]
  13. Pro --PAB (Diskussion) 20:47, 2. Jul. 2017 (CEST)[Beantworten]