Wikipedia:Umfragen/Technische Wünsche 2017/Bearbeiten

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

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)

Diskussion

Dass alle Fälle, in denen ein geschütztes Leerzeichen sinnvoll ist, automatisch erkannt werden, dürfte kaum realisierbar sein. Man könnte aber die beim Prozentzeichen gefundene Lösung auf einige andere typische Fälle ausdehnen. Dabei denke ich etwa an das Leerzeichen zwischen einem Paragraphenzeichen und einer nachfolgenden Ziffer, oder – ein Fall, der regelmässig in Literaturangaben auftritt – bei Seitenangaben zwischen der Abkürzung „S.“ und einer nachfolgenden Ziffer. Die Seitenzahl steht meist am Ende einer Literaturangabe, und da sieht es ganz unmöglich aus, wenn die Abkürzung „S.“ am Ende einer Zeile steht und die folgende Zeile nur noch eine einzelne Zahl enthält. Da Einzelnachweise neuerdings oft zweispaltig erscheinen, werden Zeilenbrüche – und damit auch solche unschönen Zeilenbrüche – sehr viel häufiger als früher.

Zu erwägen wäre auch, dass die automatisch gesetzten geschützten Leerzeichen vor Prozentzeichen oder dann vielleicht auch nach Paragraphenzeichen besser geschützte schmale Leerzeichen sein sollten. --BurghardRichter (Diskussion) 11:48, 1. Jun. 2017 (CEST)

Das NNBSP („8239“) soll weiterhin Darstellungsprobleme bei einigen Lesern haben; also weltweit bei einem derart häufig auf praktisch allen Seiten vorkommenden Gebilde dann lieber ein ANSI-nbsp mit width:0.2em oder so und ggf. geeignetem display.

Nebenbei bemerkt erfordert eine solche Lösung eine PHP-Extension in Ablösung der momentan im core verankerten Prozentzeichen-Guillemets; und diese dann sprach- und schriftabhängig von der Sprache der momentanen Seite, und wenn man es ganz genau nähme und erst jenseits der HTML-Generierung ansetzen würde, dann die letzte Sprach- und Schriftspezifikation lang= berücksichtigend. Die Projektseite sieht übrigens ein banales ASCII-Leerzeichen mit nowrap und entsprechender Breite vor, was beim C&P zu einem 32er wird.

LG --PerfektesChaos 14:07, 1. Jun. 2017 (CEST)

Wenn gemäß meinem weiter unten stehenden Vorschlag Wikipedia:Umfragen/Technische Wünsche 2017/Bearbeiten#Automatische Umwandlung eingegebener geschützter Leerzeichen und bedingter Trennstriche in HTML-Entities eine nur in Wikimedia definierte Entität &nnbsp; geschaffen werden kann (und tatsächlich eingegebene NNBSPs automatisch in diese umgesetzt werden), dann würde (wenn ich es richtig verstehe) auch die Interpretation der Wikimedia-Software obliegen, die dann bei der Darstellung eine geeignete Codefolge generieren kann. Damit wäre man von Darstellungsproblemen des NNBSP selbst unabhängig. -- Karl432 (Diskussion) 16:18, 1. Jun. 2017 (CEST)

Ob das NNBSP heutzutage tatsächlich noch Probleme macht, müsste man erst nochmal evaluieren. Wenn ich mich recht erinnere, war die letzte Erkenntnis, dass Probleme nur in Windows XP (dort aber nicht mit Firefox) und uralten Konqueror-Versionen bestehen, und die Benutzer haben inzwischen ganz andere Probleme. Vorlage:Okina haben wir ja auch erfolgreich eliminiert.

Es ist natürlich immer möglich, Sätze zu konstruieren, in denen eine automatische Geschützte-Leerzeichen-Einfügung falsch ist, etwa „Bei den Olympischen Spielen 2008 erreichte Silke Spiegelburg im Stabhochsprung Platz 7. April Steiner kam auf Platz 8.“ Aber wie häufig kommt so etwas wirklich vor? Und was passiert schon Schlimmes, wenn die Zeile dort nicht umbrochen wird? –Schnark 09:36, 2. Jun. 2017 (CEST)

Unterstützung

1.  Pro Schnark (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 22:10, 19. Jun. 2017 (CEST)
3.  Pro -- Barnos (Post) 08:15, 20. Jun. 2017 (CEST)
4.  Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)
5.  Pro -- ^Thomas 11:22, 20. Jun. 2017 (CEST)
6.  Pro --Gnom (Diskussion) 13:11, 20. Jun. 2017 (CEST)
7.  Pro --Blik (Diskussion) 16:04, 20. Jun. 2017 (CEST)
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.
9.  Pro --Abubiju (Diskussion) 17:01, 20. Jun. 2017 (CEST)
10.  Pro --Urdenbacher (Diskussion) 17:43, 20. Jun. 2017 (CEST)
11.  Pro --  Sir Gawain Disk. 18:30, 20. Jun. 2017 (CEST)
12.  Pro Kontrollstelle Kundl 18:32, 20. Jun. 2017 (CEST)
13.  Pro --Claell (Diskussion) 18:59, 20. Jun. 2017 (CEST)
14.  Pro --Gelber kaktus (Diskussion) 21:37, 20. Jun. 2017 (CEST)
15.  Pro Conny 22:16, 20. Jun. 2017 (CEST).
16.  Pro Hermannh (Diskussion) 22:45, 20. Jun. 2017 (CEST)
17.  Pro // Martin K. (Diskussion) 22:48, 20. Jun. 2017 (CEST)
18.  Pro GodeNehler (Diskussion) 05:59, 21. Jun. 2017 (CEST)
19.  Pro --HerrAdams (D) 09:50, 21. Jun. 2017 (CEST)
20.  Pro --Orgelputzer (Diskussion) 12:43, 21. Jun. 2017 (CEST)
21.  Pro --Aarakast (Diskussion) 12:58, 21. Jun. 2017 (CEST)
22.  Pro --MGChecker – (📞| 📝| ) 20:02, 21. Jun. 2017 (CEST)
23.  Pro--Jü (Diskussion) 06:55, 22. Jun. 2017 (CEST)
24.  Pro--mauriceKA (Diskussion) 10:45, 22. Jun. 2017 (CEST)
25.  Pro --Jossi (Diskussion) 12:33, 22. Jun. 2017 (CEST)
26.  Pro --KorrekTOM (Diskussion) 13:06, 22. Jun. 2017 (CEST)
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.
28.  Pro --Atamari (Diskussion) 14:20, 23. Jun. 2017 (CEST)
29.  Pro --ChrissyPlayzZz (Diskussion) 15:24, 23. Jun. 2017 (CEST)
30.  Pro --Daniel749 Disk. (ST–WPST) 21:20, 23. Jun. 2017 (CEST)
31.  Pro --Christian (Diskussion) 19:54, 24. Jun. 2017 (CEST)
32.  Pro --Mushushu (Diskussion) 16:17, 25. Jun. 2017 (CEST)
33.  Pro --DomenikaBo (Diskussion) 21:44, 25. Jun. 2017 (CEST)
34.  Pro --Wrev (Diskussion) 22:58, 25. Jun. 2017 (CEST)
35.  Pro --Ak ccm (Diskussion) 14:10, 28. Jun. 2017 (CEST)
36.  Pro --Thomas Obermair 4 (Diskussion) 16:01, 28. Jun. 2017 (CEST)
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.)
38.  Pro Andim (Diskussion) 10:10, 29. Jun. 2017 (CEST)
39.  Pro bitte, diese nbsp-Flut nervt... -- hgzh 19:24, 29. Jun. 2017 (CEST)
40.  Pro —DerHexer (Disk., Bew.) 21:35, 29. Jun. 2017 (CEST)
41.  Pro —SDKmac (Disk., Bew.) 02:33, 30. Jun. 2017 (CEST)
42.  Kontra -gpf- (Diskussion) 09:46, 30. Jun. 2017 (CEST)
43.  Pro --Anima (Diskussion) 13:56, 30. Jun. 2017 (CEST)
44.  Pro --Maimaid ✉ • Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)
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.
46.  Pro --Andrea014 (Diskussion) 17:51, 2. Jul. 2017 (CEST)
47.  Pro --PAB (Diskussion) 20:37, 2. Jul. 2017 (CEST)
48.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.
    
    

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

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)

Diskussion

@Schnark: Interressant. Auf welche Vorlagen beziehst du dich? Meinst du nur die nur den Quelltext oder hat das auch Auswirkungen auf das Aussehen? Bei Formeln gibt es möglicherweise ein ähnliches Problem, vgl. Wikipedia:Umfragen/Math-Tags bzw. mw:User talk:Whatamidoing (WMF)#VE and math formulas.--Debenben (Diskussion) 13:34, 29. Mai 2017 (CEST)

Mir geht es um Vorlagen wie Vorlage:Personendaten, die in diesem Format eingefügt werden sollen:

{{Personendaten
|NAME=Mustermann, Maximilian
|ALTERNATIVNAMEN=Mustermann, Max
|KURZBESCHREIBUNG=Beispielsperson
|GEBURTSDATUM=1. Januar 2000
|GEBURTSORT=[[Musterstadt]]
|STERBEDATUM=31. Dezember 2000
|STERBEORT=[[Musterstadt]]
|Unterstützung=
# {{Pro}} [[User:Schnark|Schnark]] (Einreichende Person)
#
<!--Bitte hier abstimmen -->
}}

vom VE aber derzeit so eingefügt werden:

{{Personendaten
| NAME = Mustermann, Maximilian
| ALTERNATIVNAMEN = Mustermann, Max
| KURZBESCHREIBUNG = Beispielsperson
| GEBURTSDATUM = 1. Januar 2000
| GEBURTSORT = [[Musterstadt]]
| STERBEDATUM = 31. Dezember 2000
| STERBEORT = [[Musterstadt]]
|Unterstützung=
# {{Pro}} [[User:Schnark|Schnark]] (Einreichende Person)
#
<!--Bitte hier abstimmen -->
}}

–Schnark 09:12, 30. Mai 2017 (CEST)

Hallo Schnark, mit Beginn der Abstimmung werden die Diskussionen zu den einzelnen Wünschen in dieser Umfrage eingeklappt, damit klar ist, dass man seine Stimme für den Wunsch abgibt und nicht beispielsweise für Vorschläge in den Kommentaren. Wenn in den Kommentaren gute Ideen stehen, wäre es daher sinnvoll, sie in der Beschreibung des Wunsches zu ergänzen. Bei diesem Fall böte sich das Beispiel Vorlage:Personendaten an. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:36, 30. Mai 2017 (CEST)

Getan. –Schnark 10:48, 30. Mai 2017 (CEST)

Danke, Schnark! Das konkrete Beispiel, das du bringst („Mir geht es um Vorlagen wie Vorlage:Personendaten, die in diesem Format eingefügt werden sollen: ...“) würde sich unter „Was ist das Problem?“ auch noch sehr gut machen, finde ich. :) -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:32, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Schnark (Einreichende Person)
2.  Pro --HerrAdams (D) 09:51, 21. Jun. 2017 (CEST)
3.  Pro --MGChecker – (📞| 📝| ) 20:18, 21. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 16:02, 28. Jun. 2017 (CEST)
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)
6.  Pro Andim (Diskussion) 10:09, 29. Jun. 2017 (CEST)
7.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.
   
   

Unterschrift bei Bausteinen

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)

Diskussion

Hallo Karl-Heinz, danke für deinen Wunsch. Ich bin nicht sicher, ob ich das Problem komplett verstanden habe. Könntest du es vielleicht noch etwas ausführlicher beschreiben? Zum Beispiel: Beziehst du dich auf den VisualEditor? Wenn ich es richtig verstehe, würde man bei der Quelltextbearbeitung ja die Vorlage {{Inuse|--~~~~}} einfügen, in der die Signatur bereits enthalten ist. Oder ist etwas ganz anderes gemeint? Viele Grüße -- Johanna Strodt (WMDE) (Diskussion) 13:49, 29. Mai 2017 (CEST)

Es geht wohl um den „Signatur und Zeitstempel“-Button in der Werkzeugleiste der Quelltextbearbeitung, siehe dazu Wikipedia:Umfragen/Unterschriften-Icon in Bearbeiten-Werkzeugleiste. Gruß, -- hgzh 13:51, 29. Mai 2017 (CEST)

Aha, danke für den Hinweis, hgzh. Karl-Heinz, würdest du diese Präzisierung in deiner Beschreibung noch ergänzen, und am besten auch das Ticket auf Phabricator (T145619)? Danke und Grüße -- Johanna Strodt (WMDE) (Diskussion) 14:05, 29. Mai 2017 (CEST)

Danke! -- Johanna Strodt (WMDE) (Diskussion) 14:34, 8. Jun. 2017 (CEST)

Eine Idee wäre, den Button nur für angemeldete Benutzer freizuschalten, damit es weniger verwirrend ist. --FNDE 14:38, 8. Jun. 2017 (CEST)

Eine sehr gute Idee! --Karl-Heinz (Diskussion) 16:11, 8. Jun. 2017 (CEST)

Unterstützung

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

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

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)

Diskussion

Hallo Karl432, danke für den Wunsch und das damit verbundene Mitdenken, was die Texteingabe angeht. Mir war beim ersten Lesen nicht klar, was genau das Problem bzw. der Wunsch ist. Es könnte helfen, wenn du das im Titel des Wunsches herausstellst: Also statt "Eingabe geschützter Leerzeichen und bedingter Trennstriche", was ja eher das Meta-Thema ist, z. B. "Verhindern der Eingabe geschützter Leerzeichen und bedingter Trennstriche mit Unicode" oder sowas in der Richtung. Du könntest die beiden Absätze unter "Wen betrifft das Problem besonders?" auch noch mit unter "Was ist das Problem?" hochziehen, dann wird es auch noch mal schneller verständlich (meiner Meinung nach). Ich könnte das auch machen, möchte dir aber nicht in deinen Wunsch reingrätschen. Viele Grüße und besten Dank -- Johanna Strodt (WMDE) (Diskussion) 16:23, 29. Mai 2017 (CEST)

Danke für Deine Hinweise. Ich hoffe, meine jetzt geänderte Überschrift drückt es präziser aus. -- Karl432 (Diskussion) 16:43, 29. Mai 2017 (CEST)

Ich danke dir! Ja, jetzt ist es top. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:38, 30. Mai 2017 (CEST)

(BK) Beim bedingten Trennstrich ist das Problem, dass dieser im Fließtext (im Gegensatz zu Bildunterschriften, Tabellen, etc.) eher unerwünscht ist, sich aber auch dort Kopieren und Einfügen verbreiten kann, und daher dort eher nicht in eine Entität umgewandelt werden, sondern einfach gelöscht werden sollte. Wobei bei einer Umwandlung immerhin der nächste Bearbeiter den Strich sieht und ihn entfernen kann.

Das Problem mit dem NNBSP ließe sich prinzipiell lösen, wenn man eine nur in MediaWiki funktionierende benannte Entität erfindet (es gibt schon ein paar von der Sorte, damit Araber ihre RLMs mit arabischen Buchstaben eingeben können, etc.), das könnte aber mehr Verwirrung stiften als beheben. –Schnark 10:46, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Karl432 (einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:02, 19. Jun. 2017 (CEST)
3.  Pro // Martin K. (Diskussion) 19:41, 20. Jun. 2017 (CEST)
4.  Pro Michi 18:59, 21. Jun. 2017 (CEST)
5.  Pro --Jossi (Diskussion) 12:35, 22. Jun. 2017 (CEST)
6.  Pro --Dominic Z. (Diskussion) 18:01, 22. Jun. 2017 (CEST)
7.  Pro --Atamari (Diskussion) 14:28, 23. Jun. 2017 (CEST)
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
9.  Pro --Thomas Obermair 4 (Diskussion) 16:03, 28. Jun. 2017 (CEST)
10.  Pro -gpf- (Diskussion) 09:51, 30. Jun. 2017 (CEST)
11.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Hört sich sinnig an.
    
    

Einfache Tabellenerstellung

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)

Wen betrifft das Problem besonders?

Vorschlagende Person

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

Diskussion

@Elcap: Kennst du die Einfügemöglichkeiten von Tabellen im VisualEditor? Damit funktioniert das inzwischen recht gut, siehe: Hilfe:Tabellen/VisualEditor. Falls du normalerweise nur den Wikitext Editor nutzt, hier noch eine Beschreibung zum (kurzzeitigen) Wechseln vom Wikitext Editor zum VisualEditor und zurück: Hilfe:VisualEditor/Wikitext#Wechsel_von_der_Quelltextbearbeitung_zum_VisualEditor. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 21:15, 29. Mai 2017 (CEST)

@Elcap: Du kannst die auf Labs befindlichen Tools excel2wiki und tab2wiki nutzen. -- Reise Reise (Diskussion) 11:06, 30. Mai 2017 (CEST)

Danke für die Hinweise, werde versuchen, ob ich damit zurechtkomme. Grüße --Elcap (Diskussion) 09:02, 31. Mai 2017 (CEST)

Unterstützung

1.  Pro Elcap (Einreichende Person)
2.  Pro -- ^Thomas 11:23, 20. Jun. 2017 (CEST)
3.  Pro Conny 22:18, 20. Jun. 2017 (CEST).
4.  Pro (einschließlich Tabellennachbearbeitung) Mike Krüger, ?! 15:32, 21. Jun. 2017 (CEST)
5.  Pro --Jü (Diskussion) 06:57, 22. Jun. 2017 (CEST)
6.  Pro --mauriceKA (Diskussion) 10:47, 22. Jun. 2017 (CEST)
7.  Pro --Konfressor (Diskussion) 22:12, 22. Jun. 2017 (CEST)
8.  Pro --Kiste11 ^(Disk.Bew.), AW 15:07, 23. Jun. 2017 (CEST)
9.  Pro obwohl die Festlegung auf Excel vielleicht zu restriktiv ist Divof (Diskussion) 20:16, 24. Jun. 2017 (CEST)
10.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 23:50, 24. Jun. 2017 (CEST)
11.  Pro GodeNehler (Diskussion) 14:39, 25. Jun. 2017 (CEST)
12.  Pro --Thomas Obermair 4 (Diskussion) 16:03, 28. Jun. 2017 (CEST)
13.  Kontra im VE gelöst --Ailura (Diskussion) 12:06, 29. Jun. 2017 (CEST)
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)
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.
16.  Pro --Ghilt (Diskussion) 09:35, 4. Jul. 2017 (CEST)
    
    

Wikidata-Items aus Wikipedia-Artikel bearbeitbar machen

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)

Diskussion

Hallo Crazy1880, an diesem Wunsch wird bereits gearbeitet, s. https://www.wikidata.org/wiki/Wikidata:Client_editing_prototype/de. Das Wikidata-Team freut sich über Feedback zur vorgeschlagenen Lösung. Ist dein Wunsch damit erledigt? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:44, 1. Jun. 2017 (CEST)

Moin Moin Johanna, was für ein Witz soll das denn darstellen? Als Entwickler würde ich mich über diesen Entwicklungstand nicht freuen. Es ist starr, wesentliche Sachen fehlen und ich habe eher das Gefühl, als wollte man damit nur Infoboxen oder Listen zuganglich machen. Das was ich mir vorstellen möchte, ist, dass man eine Art IFrame aufruft, und dort eine Wikidata-Umgebung hat. Also die Dropdown-Funktionalität zum Aussuchen der Eigenschaften/Werten. Und natürlich, dass man Werte aus der Wikipedia via Drag'n'Drop kopieren kann. Schau dir bitte mal das oben genannte Helferlein an, dieses müsste nur etwas schneller und internationaler werden und nicht nach jedem Wert und Speichern wieder zugehen. Anschließend dieses in den Wikipedias verfügbar machen, fast fertig. Um also auf diese Frage einzugehen, ich habe jetzt auf der Diskussionsseite dort einen Abschnitt hinzugefügt, aber nein, eigentlich trifft es dieses nicht, weil, wie oben erwähnt, das Tool eher für Infoboxen und Listen gemacht wird. mfg --Crazy1880 22:10, 1. Jun. 2017 (CEST)

Moin moin, Crazy1880. Danke für dein Feedback auf der Diskussionsseite des Prototyps – der ausdrücklich auf Basis der Rückmeldungen noch weiterentwickelt werden soll. Und: Ja, in dem Prototypen geht es um Infoboxen und – wahrscheinlich deshalb – habe ich deinen Wunsch durch die Brille „Infobox“ gelesen. Beim nochmaligen Lesen ist mir jetzt klarer, was du dir wünschst. Weil es anderen Lesenden vielleicht auch so geht wie mir, könntest du ja noch mal explizit schreiben, dass es dir nicht nur um Infoboxen geht. Und könntest du auch noch einen Link zum Helferlein "Drag'n'drop" setzen? -- Vielen Dank und holl di munner, Johanna Strodt (WMDE) (Diskussion) 15:01, 8. Jun. 2017 (CEST)

Moin Moin Johanna, ich bin deiner Bitte auf Wikidata mal nachgekommen und habe auch noch einen Ping an den Ersteller der Seite gesetzt. mfg --Crazy1880 20:51, 12. Jun. 2017 (CEST)

Danke, Crazy1880! Könntest du der Vollständigkeit halber auch hier oben bei deinem Wunsch noch 1-2 Sätze dazu ergänzen, dass es dir nicht nur um Infoboxen geht? Die Diskussion wird nämlich zu Beginn der Abstimmung (19. Juni) ausgeblendet. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 09:40, 13. Jun. 2017 (CEST)

Unterstützung

1.  Pro Crazy1880 (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:22, 19. Jun. 2017 (CEST)
3.  Pro Iva 20:20, 20. Jun. 2017 (CEST)
4.  Pro --Gelber kaktus (Diskussion) 21:40, 20. Jun. 2017 (CEST)
5.  Pro --Kurt Jansson (Diskussion) 10:17, 21. Jun. 2017 (CEST)
6.  Pro Michi 19:00, 21. Jun. 2017 (CEST)
7.  Pro --MGChecker – (📞| 📝| ) 20:04, 21. Jun. 2017 (CEST)
8.  Pro --Pearli (Diskussion) 20:45, 21. Jun. 2017 (CEST)
9.  Pro --ArchibaldWagner (Diskussion) 20:07, 22. Jun. 2017 (CEST)
10.  Pro --Daniel749 Disk. (ST–WPST) 21:22, 23. Jun. 2017 (CEST)
11.  Pro --Nichtich (Diskussion) 22:41, 23. Jun. 2017 (CEST)
12.  Pro --Chiborg (Diskussion) 23:07, 23. Jun. 2017 (CEST)
13.  Pro -- Freddy2001 ^DISK 11:50, 24. Jun. 2017 (CEST)
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)
15.  Pro --DomenikaBo (Diskussion) 21:46, 25. Jun. 2017 (CEST)
16.  Pro --Incabell (Diskussion) 17:34, 27. Jun. 2017 (CEST)
17.  Pro --Thomas Obermair 4 (Diskussion) 16:04, 28. Jun. 2017 (CEST)
18.  Pro —DerHexer (Disk., Bew.) 21:37, 29. Jun. 2017 (CEST)
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)
20.  Pro --Maimaid ✉ • Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)
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)
22.  Pro --Mr N (Diskussion) 21:34, 2. Jul. 2017 (CEST)
    
    

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

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)

Diskussion

Bin zwar etwas überlastet; aber die Anregung, dass „Benutzerskripte, die auf Citoid zurückgreifen“, bei ISBN 3170032631 bzw. ISBN 9783170032631 mal die Existenz von BibISBN prüfen; oder bei PMID 12345 nach BibPMID und doi:10.1000/184 in BibDOI schaun, ist angekommen. LG --PerfektesChaos 03:39, 1. Jun. 2017 (CEST)

Nein, nicht das Benutzerskript soll dort nachschlagen, sondern Citoid. –Schnark 09:17, 1. Jun. 2017 (CEST)

@Schnark:

In citoidWikitext ist das Feature seit einigen Tagen implementiert und nunmehr in Erprobung.

Angesichts meta:WikiCite ist unser BibRecord-System ohnehin nicht mehr zukunftsfähig; da wird niemand mehr was entwickeln wollen.

LG --PerfektesChaos 10:08, 12. Jun. 2017 (CEST)

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)
3.  Pro --Thomas Obermair 4 (Diskussion) 16:04, 28. Jun. 2017 (CEST)
   
   

Sicherheitsabfrage bei Funktion kommentarlos zurücksetzen

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)

Diskussion

Ich habe es selbst nicht getestet, aber eigentlich sollte c:User:Whym/lockrollback.js funktionieren. Wenn ja, sollte es mit wenigen Anpassungen (deutsche Übersetzung) leicht als Helferlein verfügbar gemacht werden können. — Speravir – 01:09, 3. Jun. 2017 (CEST)

Nachtrag: Funktioniert bestens, es ist eben nur nicht übersetzt. — Speravir – 19:35, 7. Jun. 2017 (CEST)

@Orgelputzer: Möchtest du die Hinweise von Speravir noch unter „Lösungsvorschlag“ ergänzen? Die Diskussionen der Wünsche werden zu Beginn der Abstimmung (19. Juni) nämlich ausgeblendet, damit klar ist, worüber man abstimmt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:06, 8. Jun. 2017 (CEST)

• „Ein Klick mehr bei einem gewollten Rücksetzen halte ich für jeden zumutbar.“
  • Nein; eine Reihe von Benutzern, etwa die RCler, will das ausdrücklich nicht haben.
• Das kommentarlose Feature gibt es wohl schon seit einem Jahrzehnt.
  • Etwa genausolang gibt es die Diskussion um eine „Entschärfung“.
  • Es gibt mittlerweile bald ein Dutzend technische Lösungen, wie dem entgegengewirkt werden kann, und die sich jeder persönlich verfügbar machen könnte.
• Ein Eingriff in die Bedienfunktionalität für alle Benutzer benötigt einen vorherigen breiten Community-Konsens.
• Der Grund, warum bislang nichts gelaufen war, ist, dass diejenigen, die sowas für alle Benutzer verlangen, es noch nie auf die Kette gekriegt haben, einen projektweiten Community-Konsens herzustellen.
  • Dieser Punkt als einer unter mehreren Dutzend der Umfrage hat den Charakter einer „Hinterzimmer-Abstimmung“ und ist damit grundsätzlich ungeeignet.
• Im Übrigen ist der Wunsch nicht präzise genug ausgearbeitet:
  • Was passiert mit Benutzern mit deaktiviertem JavaScript?
  • Nicht angemeldete haben nebenbei kein rollback-Recht und wären nicht betroffen.

VG --PerfektesChaos 10:11, 12. Jun. 2017 (CEST)

Entschiedener Widerspruch. Dieses Feld gibt es gerade, um Vandalismus mit nur einem Klick zurück setzen zu können. Wenn du das für dich nicht willst, kannst du den Link ausblenden oder die Sicherheitsabfrage einbinden. --h-stt !? 18:18, 20. Jun. 2017 (CEST)

@H-stt:Wo/Wie kann ich den Link ausblenden?  — Johannes Kalliauer - Diskussion | Beiträge 20:27, 21. Jun. 2017 (CEST)

Mit einem Eingriff in deine Benutzer-Scripte. Zur genauen Ausführung solltest du auf WP:FzW nachfragen. Grüße --h-stt !? 13:24, 22. Jun. 2017 (CEST)

Unterstützung

1.  Pro Orgelputzer (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:04, 19. Jun. 2017 (CEST)
3.  Pro --Tkkrd (Diskussion) _{(Neulingshilfe)}
4.  Pro -- Karl432 (Diskussion) 15:09, 20. Jun. 2017 (CEST)
5.  Pro Zellmer (Diskussion) 15:29, 20. Jun. 2017 (CEST) 14:49, 20. Jun. 2017 (CEST)
6.  Pro Jordi (Diskussion) 15:33, 20. Jun. 2017 (CEST)
7.  Pro --Cοlin (Diskussion) 17:08, 20. Jun. 2017 (CEST)
8.  Pro --Gnom (Diskussion) 17:26, 20. Jun. 2017 (CEST)
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.

   @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)

   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)

10.  Pro --Claell (Diskussion) 19:03, 20. Jun. 2017 (CEST)
11.  Pro Gelber kaktus (Diskussion) 21:41, 20. Jun. 2017 (CEST)
12.  Pro --Universal-Interessierter_Disk.^Arbeit 23:32, 20. Jun. 2017 (CEST)
13.  Pro --HerrAdams (D) 09:52, 21. Jun. 2017 (CEST)
14.  Pro --Taigatrommel (Diskussion) 00:26, 22. Jun. 2017 (CEST)
15.  Pro --Jossi (Diskussion) 12:38, 22. Jun. 2017 (CEST)
16.  Pro --mauriceKA (Diskussion) 15:05, 22. Jun. 2017 (CEST)
17.  Pro --Daniel749 Disk. (ST–WPST) 21:23, 23. Jun. 2017 (CEST)
18.  Pro Warum beim Danken, aber nicht beim kommentarlosen Zurücksetzten? -- Freddy2001 ^DISK 11:51, 24. Jun. 2017 (CEST)
19.  Pro --Martin Luck (Diskussion) 15:14, 24. Jun. 2017 (CEST)
20.  Pro --Christian (Diskussion) 19:56, 24. Jun. 2017 (CEST)
21.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 23:51, 24. Jun. 2017 (CEST)
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)
23.  Pro --DomenikaBo (Diskussion) 21:47, 25. Jun. 2017 (CEST)
24.  Pro --Wrev (Diskussion) 23:03, 25. Jun. 2017 (CEST)
25.  Pro --Sophiston (Diskussion) 00:37, 27. Jun. 2017 (CEST)
26.  Pro --Incabell (Diskussion) 17:35, 27. Jun. 2017 (CEST)
27.  Pro -- Simulo (Diskussion) 20:03, 27. Jun. 2017 (CEST)
28.  Pro -- Density ^Disk. 20:34, 27. Jun. 2017 (CEST)
29.  Pro --W!B: (Diskussion) 20:56, 27. Jun. 2017 (CEST)
30.  Pro --Gr1 (Diskussion) 10:40, 28. Jun. 2017 (CEST)
31.  Pro --Ak ccm (Diskussion) 14:14, 28. Jun. 2017 (CEST)
32.  Pro --Thomas Obermair 4 (Diskussion) 16:05, 28. Jun. 2017 (CEST)
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)
34.  Pro —SDKmac (Disk., Bew.) 02:33, 30. Jun. 2017 (CEST)
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)
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)
37.  Pro Per Sitacuisses. --Fixuture (Diskussion) 18:59, 1. Jul. 2017 (CEST)
38.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 20:49, 1. Jul. 2017 (CEST)
39.  Pro --Maimaid ✉ • Wikiliebe?! 20:51, 1. Jul. 2017 (CEST)
40.  Pro --Drahreg01 (Diskussion) 22:42, 1. Jul. 2017 (CEST)
41.  Pro --ProloSozz (Diskussion) 23:36, 1. Jul. 2017 (CEST) kann zwar abgeschaltet werden; Sicherheits- resp. Bestätigungsabfrage wäre aber sehr sinnvoll
42.  Pro --Neigschmeckter (Diskussion) 13:04, 2. Jul. 2017 (CEST)
43.  Pro -- X:: black ::X (Diskussion) 15:22, 2. Jul. 2017 (CEST)
44.  Pro --PAB (Diskussion) 20:37, 2. Jul. 2017 (CEST)
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.
46.  Pro ーGhilt (Diskussion) 09:35, 4. Jul. 2017 (CEST)
    
    

Ladezeit & Ressourcen des visuellen Editors reduzieren

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)

Diskussion

Unterstützung

1.  Pro Chire (Einreichende Person)
2.  Pro --Gnom (Diskussion) 14:58, 20. Jun. 2017 (CEST)
3.  Pro Zellmer (Diskussion) 15:29, 20. Jun. 2017 (CEST) ‖ auch bei schlechtem Internet dauert es oft lange ...
4.  Pro Thoken (Diskussion) 17:43, 20. Jun. 2017 (CEST)
5.  Pro // Martin K. (Diskussion) 19:43, 20. Jun. 2017 (CEST)
6.  Pro Gubeko (Diskussion) 20:40, 20. Jun. 2017 (CEST)
7.  Pro Conny 22:19, 20. Jun. 2017 (CEST).
8.  Pro Michi 19:01, 21. Jun. 2017 (CEST)
9.  Pro mauriceKA (Diskussion) 10:49, 22. Jun. 2017 (CEST)
10.  Pro --HHill (Diskussion) 13:06, 22. Jun. 2017 (CEST)
11.  Pro --Minihaa (Diskussion) 12:33, 23. Jun. 2017 (CEST)
12.  Pro --Würfel (Diskussion) 12:47, 23. Jun. 2017 (CEST)
13.  Pro --Daniel749 Disk. (ST–WPST) 21:23, 23. Jun. 2017 (CEST)
14.  Pro -- Freddy2001 ^DISK 11:52, 24. Jun. 2017 (CEST)
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)
16.  Pro --RookJameson (Diskussion) 19:49, 27. Jun. 2017 (CEST)
17.  Pro --Thomas Obermair 4 (Diskussion) 16:05, 28. Jun. 2017 (CEST)
18.  Pro --Sebastian Wallroth 21:58, 29. Jun. 2017 (CEST)
19.  Pro -- Shoeper 18:06, 30. Jun. 2017 (CEST)
20.  Pro Generell Weiterentwicklung des VisualEditors. --Fixuture (Diskussion) 19:01, 1. Jul. 2017 (CEST)
21.  Kontra --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) VE abschaffen würde das Problem auch lösen.
    
    

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

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)

Diskussion

@Wikifreund: Der Übersichtlichkeithalber hier: Soweit ich das sehe, sind nur die Bildzeichensymbole mit Copyrights versehen. Und die lassen sich leicht gegen ein anderes Set austauschen. Entweder händisch über das Feld URL festlegen darunter oder am im Paket (das müsste dann wohl im Quellcode von Umap erledigt werden, sollte aber technisch machbar sein). Matthias Süßen ^?! 12:26, 21. Jun. 2017 (CEST)

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.
3.  Pro --Claell (Diskussion) 19:05, 20. Jun. 2017 (CEST)
4.  Pro Conny 22:20, 20. Jun. 2017 (CEST).
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?

   Die Antwort findet sich im ausklappbaren Diskussionsbereich. --Matthias Süßen ^?! 12:57, 21. Jun. 2017 (CEST)

6.  Pro --jcornelius  11:39, 21. Jun. 2017 (CEST)
7.  Pro Michi 19:04, 21. Jun. 2017 (CEST)
8.  Pro --Andi D (Diskussion) 00:02, 22. Jun. 2017 (CEST)
9.  Pro --mauriceKA (Diskussion) 13:05, 23. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 16:06, 28. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth 21:59, 29. Jun. 2017 (CEST)
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)
    
    

Verbesserung der Belegseinfügung unter Bearbeitung (Visual Editor)

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)

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)

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)

Diskussion

• 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)

@GodeNehler: Hallo! Könntest du die Hinweise von PerfektesChaos noch unter „Was ist das Problem?“ oder unter „Lösungsansatz“ ergänzen? Bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird (und damit wären dann die Ergänzungen unsichtbar). -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 14:03, 9. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Ich hoffe es so in Deinem sinne. --GodeNehler (Diskussion) 22:26, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro GodeNehler (Einreichende Person)
2.  Pro --Gnom (Diskussion) 17:26, 20. Jun. 2017 (CEST)
3.  Pro Conny 22:21, 20. Jun. 2017 (CEST).
4.  Pro --Gr1 (Diskussion) 10:42, 28. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 16:06, 28. Jun. 2017 (CEST)
6.  Pro --Sebastian Wallroth 22:08, 29. Jun. 2017 (CEST)
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)
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.
   
   

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

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)

Diskussion

Ich persönlich kann leider mit den phonetischen Fachausdrücken auf den Einzelseiten nicht viel mehr anfangen als mit diesen verformten Buchstaben der Lautschrift, aber für die Leute, die es können, wäre das sehr nützlich. Was ich mich schon lange frage: Wenn die Lautschrift eindeutig beschreibt, wie sich das Wort anhören soll (dafür ist sie ja wohl da), warum ist dann nicht schon längst in die Vorlage eingebaut, dass man sich (wenn man Sound am Rechner installiert hat) das Wort einfach akustisch ausgeben lassen kann? --Hanekomi (Diskussion) 01:37, 2. Jul. 2017 (CEST)

Unterstützung

1.  Pro Erdic (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:12, 19. Jun. 2017 (CEST)
3.  Pro  _hugarheimur 09:24, 20. Jun. 2017 (CEST) Sehr sinnvolle Idee!
4.  Pro --Andropov (Diskussion) 16:29, 20. Jun. 2017 (CEST) Bin ich auch schon häufiger drüber gestolpert.
5.  Pro --Mushushu (Diskussion) 16:28, 25. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)
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.
8.  Pro —DerHexer (Disk., Bew.) 21:42, 29. Jun. 2017 (CEST)
9.  Pro --Sebastian Wallroth 22:11, 29. Jun. 2017 (CEST)
10.  Pro --Maimaid ✉ • Wikiliebe?! 21:00, 1. Jul. 2017 (CEST)
11.  Pro --Hanekomi (Diskussion) 01:37, 2. Jul. 2017 (CEST)
12.  Pro -- X:: black ::X (Diskussion) 15:47, 2. Jul. 2017 (CEST)
13.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) verkürzt die Zeit, die der Leser benötigt.
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.
    
    

Umwandlung von URLs in Wikilinks mit Quelltext-Editor

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)

Diskussion

Wenn das Tool schon behauptet, einen externen Link in einen internen Link umwandeln zu können, dann müsste es zumindes in der Lage sein, auch ein URL zu dekodieren (was zumindest die Probleme mit Umlauten, ß und Sonderzeichen beheben würde), aber dafür müsste es abfragen, ob der URL URL-kodiert (aus einer Adresszeile kopiert) oder nicht kodiert (aus einem Textdokument kopiert) eigegeben wurde und dementsprechend unterschiedlich verfahren. Es wäre in der Tat sehr wünschenswert, wenn das Tool das könnte. Was die Unterstriche angeht, so können – wenn ich das richtig verstehe – in Seitentiteln ja auch Unterstriche enthalten sein (siehe: Hilfe:Seitenname#Leerzeichen und Unterstriche), die dann auf keinen Fall in Leerzeichen umgewandelt werden dürfen. Keine Ahnung, wie aufwändig es wäre das Tool zunächst überprüfen zu lassen, ob der Seitentitel der zu verlinkenden Seite Unterstriche enthält (d. h. {{SEITENTITEL:}}) und dann nur die anderen Unterstriche in Leerzeichen umwandeln zu lassen. (auch @ Erdic) --X:: black ::X (Diskussion) 16:44, 2. Jul. 2017 (CEST)

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)
4.  Pro --Atamari (Diskussion) 14:34, 23. Jun. 2017 (CEST)
5.  Pro --DomenikaBo (Diskussion) 21:48, 25. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)
7.  Pro --Sebastian Wallroth 22:12, 29. Jun. 2017 (CEST)
8.  Pro --Maimaid ✉ • Wikiliebe?! 21:13, 1. Jul. 2017 (CEST)
9. Abwartend. Siehe meinen Diskussionsbeitrag (auf „Ausklappen“ klicken). --X:: black ::X (Diskussion) 16:50, 2. Jul. 2017 (CEST)
   
   

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

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

Diskussion

@BlackEyedLion:, dein Name war hier rausgerutscht, ich hab ihn noch mal ergänzt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:20, 8. Jun. 2017 (CEST)

Zu den Lösungsvoschlägen:

• Warnen – diese Warnmeldungen begreift niemand, es verschreckt nur gerade die unerfahrenen Bearbeiter, und niemandem kann man begreiflich machen, was da wer von einem will und was jetzt zu tun wäre.
• Speichern der Seite verhindern – das machen wir nur bei missbräuchlichem oder inhaltlich schädlichem Einfügen, niemals aber bloß wegen verunglückter Syntax.
• Das fehlende Tag automatisch am Ende des bearbeiteten Abschnitts einfügen – Wikisyntax ist ein komplexes Ding; vielleicht sollte ein Abschnitt auskommentiert werden. Niemand als ein davorsitzender Mensch kann begreifen was (wenn überhaupt) die Absicht gewesen war.

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

• Die WP:Auskunft hat sich ihr Syntaxproblem durch ungeschickte und zu komplizierte Syntax in einem an Außenstehende adressierten Musterabschnitt selbst geschaffen.
• Auf Wikipedia:Verbesserungsvorschläge#Warnung bei fehlendem schließendem HTML-Kommentartag habe ich dargestellt, wie man sowas robuster gegen Fehlbedienung und ohne Auswirkungen über die Zeile hinaus realisieren kann.

VG --PerfektesChaos 10:25, 12. Jun. 2017 (CEST)

Unterstützung

1.  Pro BlackEyedLion (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:14, 19. Jun. 2017 (CEST) Auf HTML verzichten möchte ich nicht, aber eine Warnung wäre ganz gut.
3.  Pro -- Karl432 (Diskussion) 15:12, 20. Jun. 2017 (CEST)
4.  Pro --Andropov (Diskussion) 16:31, 20. Jun. 2017 (CEST) WArnhinweis ist ohne Aufwand umsetzbar und hilfreich.
5.  Pro --mauriceKA (Diskussion) 13:07, 23. Jun. 2017 (CEST)
6.  Pro --Atamari (Diskussion) 14:35, 23. Jun. 2017 (CEST)
7.  Pro --DomenikaBo (Diskussion) 21:48, 25. Jun. 2017 (CEST)
8.  Pro --Wrev (Diskussion) 23:05, 25. Jun. 2017 (CEST)
9.  Pro --Thomas Obermair 4 (Diskussion) 16:07, 28. Jun. 2017 (CEST)
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)
11.  Pro --PAB (Diskussion) 20:38, 2. Jul. 2017 (CEST)
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

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)

Diskussion

Es gibt unter den Beta-Funktionen bereits eine Quelltext-Variante des VisualEditor, die auch auf Diskussionsseiten funktioniert. Die visuelle Variante scheitert daran, dass insbesondere keine Einrückungen möglich sind und dies von den Programmierern des VE vehement abgelehnt wird. –Schnark 09:02, 31. Mai 2017 (CEST)

Wie von Orci hingewiesen, gibt es unter Wikipedia:Umfragen/Technische Wünsche 2017/Sonstiges#Einen Visual Editor für Diskussionsseiten von mir einen ähnlichen Vorschlag. Johanna empfiehlt vor die Beiden Vorschläge zusammenzulegen. Dem stimme ich zu. Was hältst Du davon @Rævhuld:?

Darum hier einigen Ergänzungen, die für mich besonders wichtig wären:

Wer and den Diskussionen auf den Diskussionsseiten teilnehmen will, muss immer in den Quelltext mode wechseln. Für einen einfachen Kommentar einfügen, haben wohl die Meisten kein Problem. Aber schon so etwas wie Leute Anpingen / Anmailen, habe persönlich (GodeNehler) Probleme, weil ich es so selten benutze. Auch diese Diskussion wäre mit einem Visual Editor einfacher. Außerdem ist es mir einmal in einer Diskussion aus versehen passiert (copy paste), jemanden mit mit GROSSBUCHSTABEN anzuschreiben, also anzubrüllen, was ich eigentlich garnicht wollte. So entstehen nur unnötige Missverständnisse. --GodeNehler (Diskussion) 19:01, 1. Jun. 2017 (CEST)

Diskussionsseiten auch visuell bearbeiten zu können, wäre sicher besser als nichts. Allerdings dürfte es das eigentliche Problem der Diskussionseiten leider nicht lösen – nämlich das diese nicht wie die Dikussionsseiten bzw. Kommentarabschnitte auf anderen Websites funktionieren, sondern wie ein Wikipedia-Artikel. Dass jeder den gesamten Text bearbeiten kann und runterscrollen muss, um dann seinen Kommentar selbst einzurücken und mit einer Signatur zu versehen, entspricht nicht gerade der Nutzererwartung. Damit sind insbesondere neue oder unerfahrene Nutzer meistens total überfordert.

Ich verfolge daher in dem Wunsch weiter unten eine etwas andere Strategie zur Lösung desselben Problems. Würde mich freuen, wenn Du Ihr die unterstützen würdet. // Martin K. (Diskussion) 11:19, 15. Jun. 2017 (CEST)

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.
3.  Pro --Gnom (Diskussion) 17:31, 20. Jun. 2017 (CEST)
4.  Pro Gubeko (Diskussion) 20:46, 20. Jun. 2017 (CEST)
5.  Pro Conny 22:22, 20. Jun. 2017 (CEST).
6.  Pro --GodeNehler (Diskussion) 05:50, 21. Jun. 2017 (CEST)
7.  Pro mauriceKA (Diskussion) 10:50, 22. Jun. 2017 (CEST)
8.  Pro --KorrekTOM (Diskussion) 13:16, 22. Jun. 2017 (CEST)
9.  Pro --Daniel749 Disk. (ST–WPST) 21:26, 23. Jun. 2017 (CEST)
10.  Kontra Nutzer sollten Feedback ohne Erlernen der Wikisytnax abgeben können. Was ist mit Flow? --Nichtich (Diskussion) 22:48, 23. Jun. 2017 (CEST)
11.  Pro -- Freddy2001 ^DISK 11:53, 24. Jun. 2017 (CEST)
12.  Pro --Skrippek (Diskussion) 16:26, 24. Jun. 2017 (CEST)
13.  Pro --Thomas Obermair 4 (Diskussion) 16:08, 28. Jun. 2017 (CEST)
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)
15.  Pro -- Per Barnos. --Fixuture (Diskussion) 19:12, 1. Jul. 2017 (CEST)
16.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 20:58, 1. Jul. 2017 (CEST)
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?
    
    

Einfache Kalkulationsfunktionen für Tabellen/Berechnen der Summe

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.:

• Liste der Orte im Landkreis Oberspreewald-Lausitz Anzahl der Einträge in der Liste; Anzahl der Einträge mit bestimmten Inhalten (z. B. Ortsteil)
• Liste der Baudenkmale in Oranienburg Anzahl aller Einträge der Untertabellen ermitteln
• Liste der Bau- und Bodendenkmale im Landkreis Oberhavel, Ausgabe der Summe der Einträge in den Unterlisten
• Bevölkerungszahlen
  Anmerkungen

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

Vorschlagende Person

 ^Thomas 10:15, 31. Mai 2017 (CEST) /Partynia ^{∞ RM} 10:38, 31. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro Partynia (Einreichende Person)
3.  Pro -- Marcus Cyron Reden 10:22, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 22:12, 19. Jun. 2017 (CEST)
5.  Pro Mike Krüger, ?! 13:33, 20. Jun. 2017 (CEST)
6.  Pro Jordi (Diskussion) 15:19, 20. Jun. 2017 (CEST)
7.  Pro Kontrollstelle Kundl 18:34, 20. Jun. 2017 (CEST)
8.  Pro --Claell (Diskussion) 19:06, 20. Jun. 2017 (CEST)
9.  Pro Conny 22:23, 20. Jun. 2017 (CEST).
10.  Pro GodeNehler (Diskussion) 05:51, 21. Jun. 2017 (CEST)
11.  Pro --Matthias Süßen ^?! 12:59, 21. Jun. 2017 (CEST)
12.  Pro --Jossi (Diskussion) 12:53, 22. Jun. 2017 (CEST)
13.  Pro --Louis ♫ Bafrance ☼ Schwätz halt mit m'r, wenn da ebbes saga witt 22:03, 22. Jun. 2017 (CEST)
14.  Pro --Konfressor (Diskussion) 22:13, 22. Jun. 2017 (CEST)
15.  Pro mauriceKA (Diskussion) 13:08, 23. Jun. 2017 (CEST)
16.  Pro --Daniel749 Disk. (ST–WPST) 21:27, 23. Jun. 2017 (CEST)
17.  Pro --Christian (Diskussion) 19:57, 24. Jun. 2017 (CEST)
18.  Pro --AdAstraPerScientiam (Diskussion) 10:09, 25. Jun. 2017 (CEST)
19.  Pro --Sophiston (Diskussion) 00:41, 27. Jun. 2017 (CEST)
20.  Pro --Gr1 (Diskussion) 10:43, 28. Jun. 2017 (CEST)
21.  Pro --Ak ccm (Diskussion) 14:18, 28. Jun. 2017 (CEST)
22.  Pro --Thomas Obermair 4 (Diskussion) 16:08, 28. Jun. 2017 (CEST)
23.  Pro —DerHexer (Disk., Bew.) 21:46, 29. Jun. 2017 (CEST)
24.  Pro --Drahreg01 (Diskussion) 22:46, 1. Jul. 2017 (CEST)
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)
26.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) very hilfreich.
    
    

Assistent zum Einfügen von Referenzen und Vorlagen im Quelltexteditor

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)

Diskussion

Vorlagenmeister macht genau das und ist für angemeldete Benutzer mit einem Häkchen aktivierbar. VG --PerfektesChaos 02:45, 1. Jun. 2017 (CEST)

Der im VisualEditor integrierte Quelltexteditor (derzeit noch im Beta-Stadium) auch. –Schnark 09:19, 1. Jun. 2017 (CEST)

Ich hätte einen ähnlichen, bzw. noch erweiterten Vorschlag bzw. Wunsch gehabt (den Vorlagenmeister kenne ich allerdings auch noch nicht, da ich JavaScript deaktiviert habe – werde es mir mal ansehen). Mir geht es allerdings nicht nur um die Vorlage, sondern auch um die Inhalte. Mein Vorschlag wäre:
Es gibt ja viele Webseiten von Datenbanken (z. B. PubMed), Zeitungen, Nachrichten (z. B. BBC News), deren Inhalte durch eine sich wiederholende Meta-Struktur gegliedert sind. Diese Seiten sind jeweils durch einen eindeutigen Identifier (z. B. PMID-Nummer bei PubMed), oder DOI bei wissenschaftlichen Publikationen, oder jeweilige Seitenadresse (z. B. www.bbc.com/news/world-middle-east-40175935, oder einfach world-middle-east-40175935 bei BBC) gekennzeichnet. Ich fände es sehr hilfreich, wenn das Einfügen von Einzelnachweisen im Quelltext-Editor so gestaltet werden könnte, dass man den Identifier eingeben könnte und dann alles Übrige (bei einer Publikation die Autoren, Titel, Zeitschrift oder Buch, Erscheinungsdatum, Nummer, ggf. Verlag, Sprache, ggf. Zugriffsdatum, etc.) automatisch ergänzt bekäme, so dass man eine komplette Referenz in der Form <ref>{{Internetquelle|url= ...|titel=...|hrsg=...datum=...|zugriff=...|sprache=...}}</ref> oder <ref>{{Literatur|Titel= ...|Autor=...|Sammelwerk=...|Datum=...|Band=...|Nummer=...|DOI=...|Sprache=...}}</ref> o. ä. erhält. Diese Möglichkeit sollte für möglichst viele häufig genutzte Quellen eingerichtet sein (z. B. alle größeren Zeitungen). Letztlich würde ich mir also so eine Art kleines Bibliografie-Programm vorstellen, das die Referenzen importiert und einheitlich formatiert. --Furfur ^{⁂ Diskussion} 22:38, 6. Jun. 2017 (CEST)

Auch das kann der VisualEditor bereits. –Schnark 09:02, 7. Jun. 2017 (CEST)

@Pietz: Danke für deinen Wunsch! Für die Abstimmung wäre es hilfreich, wenn du die Tipps von PerfektesChaos und Schnark noch mit unter „Lösungsansatz“ ergänzt und dazu schreibst, warum dir das noch nicht reicht. Die Diskussion der Wünsche wird zu Beginn der Abstimmung (19. Juni) ausgeblendet, damit klar ist, dass man seine Stimme für den Wunsch abgibt und nicht beispielsweise für Vorschläge in den Kommentaren. Falls du mit den Tipps von PerfektesChaos und Schnark schon glücklich bist, würde ich den Wunsch umziehen nach Bereits umgesetzte Wünsche. Dann gib bitte ein kleines Zeichen. -- Beste Grüße und lieben Dank! Johanna Strodt (WMDE) (Diskussion) 15:30, 9. Jun. 2017 (CEST)

Unterstützung

1.  Pro Pietz (Einreichende Person)
2.  Pro --KorrekTOM (Diskussion) 13:11, 22. Jun. 2017 (CEST)
3.  Pro --DomenikaBo (Diskussion) 21:49, 25. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)
5.  Pro --Jaquento (Diskussion) 02:34, 30. Jun. 2017 (CEST)
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)
8.  Pro --Sitacuisses (Diskussion) 11:36, 2. Jul. 2017 (CEST)
9.  Pro -- Mr N (Diskussion) 21:52, 2. Jul. 2017 (CEST)
   
   

Ganze Kapitel verschieben

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)

Diskussion

Unterstützung

1.  Pro Br. Klaus (Einreichende Person)
2.  Pro -- ^Thomas 11:27, 20. Jun. 2017 (CEST)
3.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 00:55, 22. Jun. 2017 (CEST)
4.  Pro -- Freddy2001 ^DISK 11:54, 24. Jun. 2017 (CEST)
5.  Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)
6.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 21:01, 1. Jul. 2017 (CEST)
7.  Pro --ProloSozz (Diskussion) 23:39, 1. Jul. 2017 (CEST)
8.  Pro --PAB (Diskussion) 20:39, 2. Jul. 2017 (CEST)
9.  Pro --Devotus (Diskussion) 20:44, 2. Jul. 2017 (CEST)
   
   

Kapitel hoch- und runterstufen

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)

Diskussion

Unterstützung

1.  Pro Br. Klaus (Einreichende Person)
2.  Pro -- ^Thomas 11:27, 20. Jun. 2017 (CEST)
3.  Pro Gubeko (Diskussion) 20:47, 20. Jun. 2017 (CEST)
4.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 00:55, 22. Jun. 2017 (CEST)
5.  Pro -- Freddy2001 ^DISK 11:54, 24. Jun. 2017 (CEST)
6.  Pro --Gr1 (Diskussion) 10:44, 28. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 16:09, 28. Jun. 2017 (CEST)
8.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 21:02, 1. Jul. 2017 (CEST)
9.  Pro --ProloSozz (Diskussion) 23:41, 1. Jul. 2017 (CEST)
10.  Pro -- X:: black ::X (Diskussion) 17:18, 2. Jul. 2017 (CEST)
11.  Pro --PAB (Diskussion) 20:40, 2. Jul. 2017 (CEST)
    
    

Shortcut für Benutzer-Ping im Quelltexteditor

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)

Diskussion

Hi FNDE, geht das nicht einfach per "@[[Benutzer:Name|Name]]"?

Das erzeugt natürlich auch einen Ping, mir geht es aber darum, nicht die komplette Zeichenkette tippen zu müssen, zumal auch viele Sonderzeichen wie []|@ enthalten sind. --FNDE 00:01, 25. Jun. 2017 (CEST)

Unterstützung

1.  Pro FNDE (Einreichende Person)
2.  Pro GodeNehler (Diskussion) 05:52, 21. Jun. 2017 (CEST)
3.  Pro Michi 19:04, 21. Jun. 2017 (CEST)
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.
5.  Pro -- Freddy2001 ^DISK 11:55, 24. Jun. 2017 (CEST)
6.  Pro --DomenikaBo (Diskussion) 21:52, 25. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 16:10, 28. Jun. 2017 (CEST)
   
   

Abschnittsweises Editieren mit dem Visual Editor ermöglichen

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 21:46, 1. Jun. 2017 (CEST)

Diskussion

Kann es sein, dass dieses Features vor kurzem (heimlich, still und leise) eingeführt wurde? -- Gruß  Sir Gawain Disk. 18:39, 20. Jun. 2017 (CEST)

ALso bei mir funktioniert das leider nicht. Und das ist gerade bei langen Artikeln ziemlich umständlich // Martin K. (Diskussion) 11:27, 22. Jun. 2017 (CEST)

Interessanterweise sehe ich in der mobilen Ansicht im Moment überhaupt keinen Bearbeiten-Link mehr neben Abschnittsüberschriften ... Wenn ich aber in der Mobil-Version z. B. https://de.m.wikipedia.org/w/index.php?title=Wikipedia:Umfragen/Technische_Wünsche_2017/Bearbeiten&action=edit&section=21#/editor/21 eingebe, öffnet sich auf meinem Android-Tablet sowohl im Firefox als auch im Chrome ausschließlich der ausgewählte Abschnitt zum Bearbeiten, nicht die ganze Seite. -- Gruß  Sir Gawain Disk. 15:05, 25. Jun. 2017 (CEST)

Unterstützung

1.  Pro Bjs (Einreichende Person)
2.  Pro GodeNehler (Diskussion) 05:53, 21. Jun. 2017 (CEST)
3.  Pro sk (Diskussion) 16:51, 21. Jun. 2017 (CEST)
4.  Pro Michi 19:04, 21. Jun. 2017 (CEST)
5.  Pro Martin K. (Diskussion) 11:27, 22. Jun. 2017 (CEST)
6.  Pro --KorrekTOM (Diskussion) 13:12, 22. Jun. 2017 (CEST)
7.  Pro mauriceKA (Diskussion) 13:10, 23. Jun. 2017 (CEST)
8.  Pro -- Nichtich (Diskussion) 22:50, 23. Jun. 2017 (CEST)
9.  Pro -- Freddy2001 ^DISK 11:56, 24. Jun. 2017 (CEST)
10.  Pro --  Sir Gawain Disk. 15:17, 25. Jun. 2017 (CEST)
11.  Pro Versat (Diskussion) 13:17, 26. Jun. 2017 (CEST)
12.  Pro --Incabell (Diskussion) 17:38, 27. Jun. 2017 (CEST)
13.  Pro --RookJameson (Diskussion) 19:50, 27. Jun. 2017 (CEST)
14.  Pro --Thomas Obermair 4 (Diskussion) 16:10, 28. Jun. 2017 (CEST)
15.  Pro --Ailura (Diskussion) 12:10, 29. Jun. 2017 (CEST)
16.  Pro --Wingsofcourage (Diskussion) 14:38, 30. Jun. 2017 (CEST)
17.  Pro --Fixuture (Diskussion) 19:17, 1. Jul. 2017 (CEST)
18.  Pro --Kritzolina (Diskussion) 20:39, 1. Jul. 2017 (CEST)
19.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 21:03, 1. Jul. 2017 (CEST)
20.  Pro --Maimaid ✉ • Wikiliebe?! 21:10, 1. Jul. 2017 (CEST)
21.  Pro —DerHexer (Disk., Bew.) 21:19, 1. Jul. 2017 (CEST)
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.
    
    

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

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 22:07, 1. Jun. 2017 (CEST)

Diskussion

Also bei mir macht er genau das. Kannst du das mal anhand eines konkreten Beispiels darstellen? --FNDE 22:29, 1. Jun. 2017 (CEST)

Rein technisch gesehen ist das vermutlich ein Duplikat von eins obendrüber: Wenn du im Quelltext einen einzelnen Abschnitt bearbeitest, kannst du nicht ohne Verlust zum VisualEditor wechseln, weil der eben keine Abschnittbearbeitung kennt. Beim Bearbeiten des ganzen Artikels gibt es keine Probleme. –Schnark 09:27, 2. Jun. 2017 (CEST)

Verstehe. Kann man insofern jetzt schon zusammenlegen, oder? --FNDE 09:54, 2. Jun. 2017 (CEST)

Stimmt, das war mir noch nicht aufgefallen, dass das nur passiert, wenn man den Quelltext-Editor für einen Abschnitt aufruft. Es sollte aber auch dann, wenn der Visual Editor weiterhin nur den gesamten Text bearbeitet, möglich sein, die beim Editieren eines Abschnitts mit dem Quelltext-Editor durchgeführten Änderungen in das Editieren des gesamten Artikels mit dem Visual Editor zu übernehmen, ohne erst im Quelltext-Editor speichern zu müssen und dann den Visual Editor aufzurufen. --bjs 16:40, 8. Jun. 2017 (CEST)

Unterstützung

1.  Pro Bjs (Einreichende Person)
2.  Pro Gubeko (Diskussion) 20:49, 20. Jun. 2017 (CEST)
3.  Pro GodeNehler (Diskussion) 05:54, 21. Jun. 2017 (CEST)
4.  Pro Michi 19:07, 21. Jun. 2017 (CEST)
5.  Pro --MGChecker – (📞| 📝| ) 20:06, 21. Jun. 2017 (CEST)
6.  Pro mauriceKA (Diskussion) 13:10, 23. Jun. 2017 (CEST)
7.  Pro Divof (Diskussion) 20:20, 24. Jun. 2017 (CEST)
8.  Pro --Sophiston (Diskussion) 00:43, 27. Jun. 2017 (CEST)
9.  Pro --W!B: (Diskussion) 21:04, 27. Jun. 2017 (CEST)
10.  Pro --Thomas Obermair 4 (Diskussion) 16:17, 28. Jun. 2017 (CEST)
11.  Pro --Fixuture (Diskussion) 19:17, 1. Jul. 2017 (CEST)
12.  Pro --PAB (Diskussion) 20:41, 2. Jul. 2017 (CEST)
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...
    
    

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

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 da • Skin-Entwurf 20:39, 10. Jun. 2017 (CEST)

Diskussion

# ist ebenfalls betroffen. Der Nachteil wäre allerdings, dass man den angezeigten Seitentitel nicht mehr zwangsläufig in den Editor kopieren kann, um die Seite zu verlinken. --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 21:48, 9. Jun. 2017 (CEST)

• Darauf wird man sich international auch nicht einlassen.
• Was da oben im Seitenkopf angezeigt wird, ist etwas, das man sich jederzeit mit C&P übernehmen und beispielsweise in ein Wikilink kopieren kann.
  • Die generierte Verlinkung wäre dann aber wegen Syntaxfehler kaputt; es bedarf des richtigen Seitentitels, um mit der Seite arbeiten zu können.
  • Die zulässigen dekorativen Änderungen sind nur solche, die beim C&P wieder einen gültigen und verlinkbaren Inhalt haben und auf dieselbe Seite verlinken.
• Es müsste also neben jede Darstellung in jeder Sprache auf jedem Wiki in jeder Skin ein auffallender Kasten generiert werden, der aussagt, dass der dort angezeigte Seitentitel nur dekorativ ist und der wirkliche und zum Verlinken zu benutzende Seitentitel jedoch dieser und jener wäre.
  • Das ist genau die gleiche Situation, die wir heute auch haben; nur ist die Reihenfolge der beiden Zeilen mit Mega-Aufwand vertauscht worden.
  • Viel Spaß bei der modern-Skin.
• Die Vorlage:Korrekter Titel wird man ohnehin nicht abschaffen können.
  • Wie schon richtig eingewandt wurde, kann das Problem mit # auf diese Weise grundsätzlich nicht gelöst werden, weil das ein legitimes Ankerlink ist und bleibt.
  • Auch De:Bug hat nun mal eine andere syntaktische Bedeutung, genauso wie D:Ream und V:NESS oder aber fil_da_Elephant.
  • Wobei fieserweise die Falschverlinkungen oft ganz normale Artikel sind, bloß zu einem anderen Thema. Oder was wäre der Unterschied zwischen C# und C, oder zwischen De:Bug und de:Bug?
• Vorlage:Korrekter Titel hat magere 86 Einbindungen, unter zwei Milllionen Artikeln, und vielleicht die Hälfte ließen sich mit dem Vorschlag und Riesenaufwand umgehen; der Rest muss ohnehin bleiben.
  • Die Auswirkungen wären weltweit und erheblich; es müsste bei allen Wikis der WMF eine konsistente und nicht verwirrende Handhabung geben, da die Mediawiki-Software im Kern zu ändern ist, nebst allen Skins. Das wird nichts.

LG --PerfektesChaos 22:23, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro Mabschaaf (Einreichende Person)
2.  Pro Morten Haan (Einreichende Person)
3.  Pro DCB (Diskussion • Bewertung) 22:13, 19. Jun. 2017 (CEST)
4.  Pro --MGChecker – (📞| 📝| ) 20:07, 21. Jun. 2017 (CEST)
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.
6.  Pro --Thomas Obermair 4 (Diskussion) 16:17, 28. Jun. 2017 (CEST)
7.  Pro --alexscho (Diskussion) 00:30, 2. Jul. 2017 (CEST)
8. Abwartend -- X:: black ::X (Diskussion) 17:33, 2. Jul. 2017 (CEST)
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.
   
   

Abspeichern von Inhalt ohne zu veröffentlichen

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)

Diskussion

Lässt sich dein Wunsch eher damit konkretisieren, dass du einen geschützten Bereich im Benutzernamensraum haben möchtest? Oder generell non-public Seiten einführen möchtest? --FNDE 16:42, 4. Jun. 2017 (CEST) - Gute Frage. Ich möchte eigentlich keine nichtöffentliche Seite im BNR, denn eine Seite müsste ich verschieben. Ich möchte Inhalt aufbewahren, mit dem ich auch eine existierende Seite im ANR bearbeiten kann. Ziko (Diskussion) 20:47, 4. Jun. 2017 (CEST)

Es ist zwar sicherlich nicht ganz, was Du willst, aber siehe dir Benutzer:Schnark/js/localFile an (auch in Fliegelflagel enthalten). Du solltest dann immer auf der Spielwiese weiterarbeiten. --Speravir 23:56, 4. Jun. 2017 (CEST)

Vielleicht ein Button mit der Funktion die letzte Version des Artikels in den Benutzernamensraum zu kopieren?--Avron (Diskussion) 14:35, 21. Jun. 2017 (CEST)

Habe ich das richtig verstanden: Gewünscht wird eine Funktion, die Atikelentwürfe/unveröffentlichte Artikel automatisch im Artikelnamensraum speichert? Das Ganze würde dann einen "Werkstattbereich" im Benutzernamensraum und das händische Copy & Paste in den ANR ersetzen? --Ak ccm (Diskussion) 14:33, 28. Jun. 2017 (CEST)

Ich sehe hier die BK-Problematik auf einer viel höheren Ebene. Was geschieht mit den zwischenzeitlichen Bearbeitungen? Das Problem ist ja beim Content Translation Tool nicht mal annähernd befriedigend gelöst. --Matthiasb – ^{(CallMyCenter)} 23:43, 28. Jun. 2017 (CEST)

Im Editor von Spezial:Inhaltsübersetzung werden Änderungen zwischengespeichert. Bei Browserabsturz und der gleichen kann man einfach weitereditieren. Vielleicht kann man sich dort Ideen holen. --Sebastian Wallroth 22:20, 29. Jun. 2017 (CEST)

Unterstützung

1.  Pro Ziko (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:23, 19. Jun. 2017 (CEST)
3.  Pro Schnark 11:30, 19. Jun. 2017 (CEST)
4.  Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)
5.  Pro Jordi (Diskussion) 15:29, 20. Jun. 2017 (CEST)
6.  Pro--grim (Diskussion) 15:56, 20. Jun. 2017 (CEST)
7.  Pro--Orgelputzer (Diskussion) 16:01, 20. Jun. 2017 (CEST)
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!
9.  Pro --Frank Schulenburg (Diskussion) 18:33, 20. Jun. 2017 (CEST)
10.  Pro --  Sir Gawain Disk. 18:58, 20. Jun. 2017 (CEST)
11.  Pro --Holder (Diskussion) 20:03, 20. Jun. 2017 (CEST)
12.  Pro Gubeko (Diskussion) 20:50, 20. Jun. 2017 (CEST)
13.  Pro --SkiFreak99 (Diskussion) 00:26, 21. Jun. 2017 (CEST)
14.  Pro --MGChecker – (📞| 📝| ) 20:17, 21. Jun. 2017 (CEST)
15.  Pro --Pelz (Diskussion) 22:38, 21. Jun. 2017 (CEST)
16.  Pro --HHill (Diskussion) 13:08, 22. Jun. 2017 (CEST)
17.  Pro --ArchibaldWagner (Diskussion) 20:01, 22. Jun. 2017 (CEST)
18.  Pro --Daniel749 Disk. (ST–WPST) 21:29, 23. Jun. 2017 (CEST)
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)
20.  Pro --RotWeisserHai (Diskussion) 13:55, 24. Jun. 2017 (CEST)
21.  Pro --Christian (Diskussion) 19:58, 24. Jun. 2017 (CEST)
22.  Pro ----wollewoox (Diskussion) 15:32, 25. Jun. 2017 (CEST)
23.  Pro --DomenikaBo (Diskussion) 21:54, 25. Jun. 2017 (CEST)
24.  Pro -- ^Thomas 08:11, 26. Jun. 2017 (CEST)
25.  Pro --Sophiston (Diskussion) 00:45, 27. Jun. 2017 (CEST) Visual SourceSafe für die Wiki :-)
26.  Pro --Thomas Obermair 4 (Diskussion) 16:18, 28. Jun. 2017 (CEST)
27.  Pro -- hgzh 19:26, 29. Jun. 2017 (CEST)
28.  Pro --Sebastian Wallroth 22:20, 29. Jun. 2017 (CEST)
29.  Pro -- Mboesch (Diskussion) 11:24, 1. Jul. 2017 (CEST)
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)
31.  Pro —DerHexer (Disk., Bew.) 21:22, 1. Jul. 2017 (CEST)
32.  Pro --Drahreg01 (Diskussion) 22:48, 1. Jul. 2017 (CEST)
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)
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)
35.  Kontra -- Zustimmung zu dealer. PAB (Diskussion) 20:42, 2. Jul. 2017 (CEST)
36.  Pro --Devotus (Diskussion) 20:48, 2. Jul. 2017 (CEST)
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.
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.
39.  Pro --Gruß Michael Hoefler50 Diskussion 21:09, 4. Jul. 2017 (CEST)
    
    

Auch nur Teile von Quellcode im MediaViewer kopierbar machen

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)

Diskussion

Unterstützung

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

Neuer Bearbeitungsmodus bei der Vorlagenprogrammierung

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)

Diskussion

1. Du (oder sonstwer) könntest versuchen, dir den CodeEditor dienstbar zu machen.
   • Der kann das mit den öffnenden-schließenden Klammerpaaren, und könnte sogar Bereiche einklappen.
   • An geschweiften Klammern würde es spontan der JavaScript- oder Lua-Modus erkennen, dann aber über anderes meckern; ich meine mich hingegen zu erinnern, dass es einen Universal-Modus gibt, der runde, eckige und geschweifte Klammern zuordnen kann.
2. Ich persönlich ziehe mir unübersichtlichen Code extern in meine Programmierumgebung; Java, C, JavaScript, aber auch unspezifisch können mir Klammerbereiche markieren und kopieren usw.
3. Ich muss dich allerdings dahingehend warnen, dass diese Klammerzuordnung in der Vorlagenprogrammierung nicht immer glatt aufgeht; wenn etwa Tabellensyntax generiert wird, ein öfffnendes {| rumsteht, oder in Zweigen an der Generierung von Syntaxelementen geschraubt wird, dann sind die Paarungen nicht immer ausgeglichen. Wobei in der Vorlagenprogrammierung geschweifte Klammern noch relativ regelmäßig paarig sind; eckige, runde und spitze <> öfters mal unbalanced, doppelte, gar dreifache geschweifte wiederum recht zuverlässig paarig sind.
   • Zuweilen könnnen aber die scheinbar fehlenden Klammern und Anführungszeichen aus der Expansion von Untervorlagen resultieren; allerdings nicht die mehrfachen geschweiften.
4. Das mit Pipes usw. würde ich mir lieber abschminken.
   • Wikisyntax, Vorlagenprogrammierung, Substituierung, Einschluss in bestimmte Tags, Kommentare, Expansion von Untervorlagen ist dermaßen hochkomplex, dass sich hier keine trivialen Regeln angeben lassen, wo in der Vorlagenprogrammierung welche Pipe wozu gehört.
   • Eine Stelle, wo eine unbalancierte Klammer fehlen würde, kann dir niemand markieren, weil es je nach Konstruktion ganz viele Stellen mit unterschiedlichen Auswirkungen geben kann, wo man die hintun kann, um etwas zu bewirken. Nur die öffnende Seite weiß, dass es irgendwie nicht gut ausgeht.
5. Generell ist die von einer Vorlagenprogrammierung generierte Zeichenkette nicht notwendigerweise vollständige Wikisyntax wie dann hinterher auf einer dargestellten Seite zusammengeführt.
   • Deshalb sind viele Konstrukte möglich, und die dürfen mit dann unterschiedlicher Interpretation auch viele Pipes haben. Wo eine Pipe erlaubt wäre oder nicht, kann dir auch eine schlaue Software nicht verraten, weil das davon abhängt, was du mit dem Konstrukt bezwecken möchtest.
   • Expandiert wird das am Schluss immer zu irgendwas; ggf. in anderen Vorlagen und als deren Untervorlage eingebunden. Ob das dann auf der dargestellten Seite so ausschaut, wie du dir das gewünscht hattest, kann die von dir ersehnte Software nicht ahnen.

LG --PerfektesChaos 02:19, 8. Jun. 2017 (CEST)

Mit etwas Abstand habe ich mir das wiedergekäut und komme zur nachstehenden Einschätzung:

• Zusammengehörende Gruppen von erst dreifachen, im Rest zweifachen geschweiften Klammern können farbig hinterlegt werden.
  • Die Farben sollten sich deutlich in der Abfolge unterscheiden; etwa die VGA-Palette (außer schwarz, weiß, rot) und dahinter sinngemäß fortgesetzt.
  • Die zusammengehörenden öffnenden und schließenden Klammergruppen sowie die ihnen syntaktisch eindeutig zuzuordnenden Pipes bekommen die gleiche Hintergrundfarbe.
  • Die erste Pipe bei einer Dreifachklammer, die erste nach Öffnung von Parserfunktion oder Vorlageneinbindung ist eindeutig. Darüberhinaus könnten bei Parserfunktion und Vorlageneinbindung weitere Pipes zugeordnet werden, wobei aber diejenigen innerhalb von Wikilink-Syntax nicht mitzählen; auch innere Konstrukte mit geschweiften Klammern bleiben außen vor.
  • Bestimmte Tags der Wikisyntax machen die im umschlossenen Bereich vorhandenen Pipes und Klammern nach außen unwirksam; das auszubaldowern ist tückisch, aber lösbar.
  • Gültig sind nach der öffnenden Klammergruppe nur bestimmte Zeichenfolgen; führenden Whitespace ignorierend kann weder Pipe noch geschweifte oder eckige Klammer folgen, womögich aber Tags.
  • Viel Spaß mit der Substitutionsverhinderungssyntax.
• Alle nicht farbig unterlegten Pipes und Klammern müssen eine sonstige syntaktische Bedeutung haben.
  • Das ist aber nicht unbedingt ein Fehler.
  • Welche Bereiche zu welchem Syntaxkonstrukt gehören sollen, muss inhaltlich durch die Bearbeiter geklärt werden und kann nicht von der Software erraten werden.
• Zusätzlich zur statischen farblichen Markierung sind zwei dynamische Features mit der Maus zu erreichen:
  • Beim Zeigen auf öffnende oder schließende Klammergruppe mag der gesamte umschlossene Bereich pastellfarbig (ggf. auf die permanente Hintergrundfarbe abgestimmt) vorübergehend hinterlegt werden.
  • Beim Klick auf öffnende oder schließende Klammergruppe kollabiert diese zu den umschließenden Klammern und dem maßgeblichen Schlüsselwort; vielleicht unterstrichen oder umrahmt. Ein erneuter Klick auf diesen Bereich (bzw. die Klammergruppe) expandiert die Syntax wieder.
• Nicht im Vorschlag erwähnt: Parserfunktionen und Variablen könnten mit kontextsensitivem Tooltip verbunden werden; zumindest dem generischen Namen lokalisierter Syntax. Was nicht darunter fällt, muss Name einer Vorlage (oder anderer Seite) sein und sollte ein Link auf genau diese Seite generieren (vulgo: Vorlagendoku).
• Das ganze ist nach längerer Einarbeitungszeit mit unserem auf den Servern vorhandenen und für richtige Programmiersprachen bereits eingesetzten CodeEditor realisierbar.

LG --PerfektesChaos 10:34, 12. Jun. 2017 (CEST)

+

• Man könnte die Dreifachklammern (Parameter) mit weißen Klammern und Pipes in einer Abfolge von sehr dunklen Hintergründen darstellen; von innen nach außen oder umgekehrt in schwarz, dunkelmagenta, navy usw.
  • Verschachtelte Parameter-Dreifachklammern gibt es bei Alias-Fallbacks und meist nur mäßig tiefgeschachtelt; eher auf drei oder vier begrenzt.
• Schwarze Klammern (und Pipes) auf hellerem Untergrund gibt es für die Doppelklammern von eingebundenen Seiten, Variablen, Parserfunktionen.
  • Nimmt man Weiß (Normaltext), Leuchtrot (Fehlersignal) und Blassgelb heraus, so gibt es ein Dutzend bis knapp zwanzig recht gut unterscheidbarer Hintergrundfarben, die in einer Palette – zu Beginn möglichst deutlich kontrastierend – die ersten 20 Verschachtelungsebenen kennzeichnen können. Je weiter das geht, desto schwieriger wird es, Nuancen zu finden, die sich von den bisher verwendeten Farben noch deutlich abheben.

LG --PerfektesChaos 13:33, 15. Jun. 2017 (CEST)

Unterstützung

1.  Pro Atamari (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:19, 19. Jun. 2017 (CEST)
3.  Pro Michi 19:07, 21. Jun. 2017 (CEST)
4.  Pro -- Nichtich (Diskussion) 23:00, 23. Jun. 2017 (CEST)
5.  Pro --DomenikaBo (Diskussion) 21:55, 25. Jun. 2017 (CEST)
6.  Pro --Sophiston (Diskussion) 00:46, 27. Jun. 2017 (CEST) Wiki Syntax Editor ist gut
7.  Pro --Thomas Obermair 4 (Diskussion) 16:19, 28. Jun. 2017 (CEST)
8.  Pro --Sebastian Wallroth 22:22, 29. Jun. 2017 (CEST)
9.  Pro -- X:: black ::X (Diskussion) 17:45, 2. Jul. 2017 (CEST)
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.
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).
    
    

Nicht-darstellbare Zeichen sollen auch nicht gespeichert werden

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: ­)

Vorschlagende Person

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

Diskussion

• Darauf wird man sich nicht einlassen.
• Die „nicht-darstellbaren Zeichen“ sind zwar für Leser und Bearbeiter unsichtbar; sie haben jedoch eine Funktion.
  • Genauer: Sie haben dort eine wichtige und bedeutungstragende Funktion, wo sie bestimmungsgemäß eingesetzt werden, und können dort auch nicht weggelassen werden.
  • Beispiele:
    • &zwnj; verändert innerhalb einer asiatischen Schrift die Gestalt der angrenzenden Buchstaben (Ligatur-Aufhebung); wirkt damit wie eine Trennung zwischen zwei Wörtern bei uns und ändert die Bedeutung der aufeinanderfolgenden Buchstabenfolgen.
    • &lrm; und &rlm; verändern die Schreibrichtung und damit ggf. die Interpretation, welche Zahlen vor oder nach einem Wort erscheinen sollen; dies ist bedeutungstragend und kann auch im Einzelfall die optische Präsentation deutlich verändern.
    • Damit sie überhaupt zu sehen sind, hier als Entities dargestellt.
• Das Problem liegt dort vor, wo die Bearbeiter derartige Zeichen sinnlos durch C&P irgendwo einstreuen; insbesondere innerhalb von Wikisyntax, deren Funktion dadurch aufgehoben wird.
• Die Klärung der Frage, an welcher Stelle ein derartiges Zeichen sinnvoll ist und an welcher es erforderlich wäre, ist hochkomplex, teils nur durch manuelle Inspektion möglich und Bot-gesteuert auf eine Vielzahl wechselnder und permanent anzupassender Regeln zu stützen.
  • Definitiv nichts für eine weltweite Software.

LG --PerfektesChaos 17:57, 7. Jun. 2017 (CEST)

Wäre es nicht besser, stattdessen nicht-darstellbare Zeichen im Editor sichtbar zu machen? Ich habe mir bereits mehrmals durch C&P derartige Zeichen eingefangen, aber an Stellen, wo sie überhaupt keinen Sinn machen. Hätte ich gesehen, dass dort etwas ist, wäre mir sofort klar geworden, warum da etwas nicht funktioniert. --bjs 16:28, 8. Jun. 2017 (CEST)

Damit wären viele Leutchen nicht glücklich.

Bei den (asiatischen) Texten, wo die Zeichen korrekt eingesetzt wurden, sind sie unsichtbar vorhanden und du hast sie bloß noch nie gesehen. Das wollen die auch weiterhin so haben.

(Frag mich nicht, mit welchen Spezialwerkzeugen die ihre Texte editieren und sowas einfügen oder rausnehmen)

Die angestrebte Software-Änderung beträfe den Kern von MediaWiki, damit nebenbei auch die asiatischen Wikis und würde individuellen Konfigurationsaufwand für jedes einzelne Wiki erfordern, weil eine andere Community mit deinem Vorschlag wiederum nicht einverstanden wäre. Bei uns ist ja auch sofort die Barrikade mit Kanonen bestückt, wenn ohne uns zu fragen das Verhalten der Software spürbar verändert wird.

Sowohl die Regeln, wann das sichtbar sein soll, wie die, wann es verborgen sein soll, sind sprach- und kontextabhängig und diffizil; sowas eignet sich nicht für die in Tausenden von Wikis eingesetzte Software.

LG --PerfektesChaos 22:01, 10. Jun. 2017 (CEST)

Unterstützung

1.  Pro Atamari (Einreichende Person)
2.  Pro Jordi (Diskussion) 15:20, 20. Jun. 2017 (CEST)
3.  Pro --Wikifreund (Diskussion) 23:49, 20. Jun. 2017 (CEST)
4.  Pro --MGChecker – (📞| 📝| ) 20:11, 21. Jun. 2017 (CEST)
5.  Pro --Furfur ^{⁂ Diskussion} 23:06, 21. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 16:19, 28. Jun. 2017 (CEST)
7. Abwartend resp.  Kontra --ProloSozz (Diskussion) 23:50, 1. Jul. 2017 (CEST) Unsichtbare Zeichen sollten sichtbar gemacht werden und nicht "nicht gespeichert".
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)
9.  Pro, siehe Vorredner --Zaccarias (Diskussion) 12:13, 2. Jul. 2017 (CEST)
10.  Pro --PAB (Diskussion) 20:43, 2. Jul. 2017 (CEST)
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.
    
    

Artikel mit Versionsgeschichte kopieren

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)

Diskussion

• Das gibt es schon seit einem Jahrzehnt: mw:Extension:Duplicator.
  • Gemäß Gerrit:144861 soll auch ein mergehistory to sysops gegeben worden sein und somit phab:T68155 als Vorbedingung erledigt sein; was immer das im Einzelfall heißen mag.
• Maßgeblich wäre hier eine präzise Community-Entscheidung, wer genau was damit anstellen dürfte.
  • Ich hätte was dagegen, jedem Sichter zu erlauben, beliebig oft mit drei Mausklicks Tausende von Versionseinträgen in die Datenbank zu schießen.
  • Für Admins ohne Import-Berechtigung oder vertiefte Import-Kenntnisse mag das eine Artikelduplizierung light als Alternative zu Hilfe:Artikelinhalte auslagern #Lizenzkonforme Auslagerung durch Duplikation ergeben.
• Vorangegangene Diskussionen zum selben Thema:
  • Wikipedia:Umfragen/Technische Wünsche 2015/Spezialseiten #Multiplizieren von Versionsgeschichte
  • Wikipedia:Verbesserungsvorschläge/Archiv/2007/Juli und diverse FZW 2007
• Allgemein fällt mir beim Durchgehen dieser WMDE-Seiten auf, dass jede Menge angeblicher technischer Programmierungswünsche vorgetragen werden, die in Wirklichkeit Community-Angelegenheiten sind und bei denen überhaupt nichts Neues zu programmieren wäre, oder bei denen vor irgendwelchen technischen Aktivitäten erstmal dewiki- oder globaler Community-Konsens über die Geschichten hergestellt werden müsste, und präzise zu spezifizieren wäre, was genau man sich eigentlich wünscht.

LG --PerfektesChaos 15:19, 8. Jun. 2017 (CEST)

Hm, das heisst: Es gibt zwar schon lange eine solche MediaWiki-Extension, diese ist aber in der Wikipedia bislang nicht eingerichtet? Auf welchem Wege könnte man denn eine solche Einrichtung (nach "präziser Community-Entscheidung") erwirken? Ich würde das Recht zum Duplizieren jedenfalls nicht nur Admins erteilen, aber es muss auch nicht gerade jeder Sichter sein. Wenn technisch möglich, könnte es ja ein Recht auf Antrag sein, das erfahrenen Benutzern ohne grosse Bürokratie gegeben wird. Gestumblindi 14:02, 9. Jun. 2017 (CEST)

1. Admins:
   • Hier reicht es, wenn die Admins die Köpfe zusammenstecken.
   • Die routinierten ImporteurInnen mögen organisatorische Hinweise geben.
2. Rechte für Normalos:
   • MB
   • Ausarbeitung genauer Regeln, welche Benutzer mit einem Sperrlog welcher Länge und welchem Editcount nach welchem Prüfungsverfahren und Überwachung der Aktivitäten durch genau wen die zusätzlichen Rechte erhalten. Community-Wahl zum Duplizierer?
   • Es gibt Leutchen mit fünf- bis sechsstelligem Editcount, denen eher die Sichterrechte entzogen gehören würden.
   • Wenn ein Admin(B) nach Gutsherrenart irgendeinem Benutzer freihändig zusätzliche Rechte einräumt, dann muss er auch jedem anderen Benutzer mit gleich hohem Editcount und vergleichbarer Anciennität automatisch die gleichen Rechte gewähren.
   • Im MB ist weiterhin eine zweite Instanz für Beschwerdefälle wegen nicht gewährter zusätzlicher Rechte und zur Aberkennung des Rechts bei Fehlverhalten trotz Abmahnung sowie entsprechendes Procedere festzulegen.
   • Büchse der Pandora.
3. Technische Rechtegewährung:
   • Existiert überhaupt eine weltweit definierte separate Benutzergruppe, der irgendwer zugeordnet werden könnte, so dass jemand ohne Admin-Status Duplizierer-Rechte bekäme?
   • An welche Rechte wäre die Nutzung der Extension überhaupt gebunden, so von sich aus?
4. Status quo plus:
   • Die paar Hanseln und Greteln, die einschlägige Fälle angehen wollen, melden sich wie bisher bei WP:IU, ggf. zukünftig auch WP:IMP.
   • Die routinierten Importeure gucken kurz drauf, ob das alles stimmig ist oder was aus dem Ruder läuft, und setzen das ggf. um.
   • Für die Importeure wird es einfacher, weil statt des bisher erforderlichen XML-Downloads und wieder Upload innerhalb desselben Wikis jetzt nur Duplizieren erforderlich ist.
   • Zuweilen scheint Nachbearbeitung der Versionsgeschichte nötig zu sein; so deutet sich die 2015er Diskussion an. Das können dann wieder nur richtige Importeure.
   • Wie viele IU-Anfragen innerhalb dewiki waren es eigentlich in 2016, und wie viele davon wurden von den präsumptiven Hilfsselbstimporteuren eingereicht?

LG --PerfektesChaos 21:18, 10. Jun. 2017 (CEST)

Duplicator ist im Marjorie-Wiki im Einsatz. Ich habe es bisher IIRC nur rund 3 Mal verwendet. Ja, es ist komfortabler als der Importupload, aber leider hat die Extension einen Bug, der auch schon auf Mediawiki.org angesprochen wurde (etwas unglücklich formuliert, das verlinkte Beispiel zeigt aber das Problem). Kann man so nutzen (ist ja nicht dramatisch), aber so sollte die Extension nicht in der WP zum Einsatz kommen. Für Admins ohne Importupload-Recht besteht natürlich noch die "hemdsärmelige" Möglichkeit: Löschen-Wiederherstellen-Verschieben-ErneutWiederherstellen ;-). Das wird wahrscheinlich nicht gerne gesehen (allerdings wird bei Versionsvereinigungen ja ähnlich gearbeitet) und wird bei "unsauberer" Versionsgeschichte (gelöscht Versionen) auch noch umkomfortabler als es sowieso schon ist (wenn nicht gar praktisch unmöglich). Wenn es auf WP:IU einen Auftragsstau gibt, dann soll man das Importupload-Recht einfach mehr Leuten geben. Ja, es erfordert mehr Vertrauen als der normale Trans-Wiki-Import, aber daran sollte es doch wohl nicht scheitern. -- Reise Reise (Diskussion) 11:26, 11. Jun. 2017 (CEST)

• Bug in der Extension
  • Davon erfahre ich hier erstmalig.
  • Dieser müsste präzise beschrieben werden: Was soll wann passieren, was passiert stattdessen?
  • Gibt es schon irgendwo den Bugreport?
  • Das zu fixen wäre eine sinnvolle Aufgabe für WMDE.
• Extension für Importeure verfügbar machen
  • Würde den Uploadern die Arbeit wesentlich erleichtern.
  • Nach Durchsicht der IU-VG wird eine Duplizierung pro Jahr aber nicht so dramatisch häufig beantragt.
• Duplizierungsberechtigung für alle oder für würdig befundene Sichter
  • Außerhalb der Kompetenzen von WMDE.
  • Die Ausführung einer Softwarefunktion an bestimmte Benutzer zu koppeln bedarf einer weltweit für alle mit MediaWiki betriebenen Wikis wirksamen Software-Änderung. Davon muss die Welt überzeugt sein.
  • Benutzern kann kein einzelnes Recht zugeordnet werden, sondern Benutzer müssen in eine neue Benutzergruppe aufgenommen werden, die einen bestimmten Rechteumfang hätte.
  • Weder eine Definition des Rechtes noch eine weltweite Definition der neuen Benutzergruppe gibt es bislang. Dies ist bereits heute äußerst umfangreich und damit unübersichtlich, und man ist international sehr widerstrebend, was die Einrichtung neuer Strukturen angeht, für die es keinen nachgewiesenen weltweiten Bedarf gibt.
  • Ein wirkicher Bedarf für Nicht-Admin-Duplizierungsrechte ist nicht zu sehen.
    • Gelegentlich auflaufende Duplizierungswünsche werden zeitnah abgearbeitet.
    • Wenn jemand nach Entlastung der Importeure zu rufen hätte, dann wären das Importeure, die mit der Abarbeitung der IU nicht hinterherkämen. Danach sieht es nicht aus.

VG --PerfektesChaos 13:33, 15. Jun. 2017 (CEST)

@Gestumblindi: Danke für deinen Wunsch! Wie PerfektesChaos schon schreibt, ist alles, was Nutzerrechte betrifft, eine Frage für die Community. Das heißt, so wie der Wunsch zzt. formuliert ist, kann er im Rahmen des Projekts „Technische Wünsche“ nicht umgesetzt werden und ich würde ihn am Sonntagabend in die Rubrik „Wünsche außerhalb des Projektrahmens“ verschieben. Was im Rahmen dieses Projekts ginge, wäre

• den Bug in der Extension zu beheben
• und falls die Community sich dafür entscheidet, dass mehr Leute das Recht bekommen sollen, könnten dann in einem zweiten Schritt vom Team Technische Wünsche die nötigen technischen Anpassungen vorgenommen werden.

Du könntest diesen Wunsch also dahingehend konkretisieren. Wenn du den Wunsch noch umformulieren willst, bitte bis Sonntagnachmittag, weil die Abstimmung am Montag beginnt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 21:33, 16. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Ich habe den Wunsch entsprechend umformuliert. Gestumblindi 23:41, 16. Jun. 2017 (CEST)

Unterstützung

1.  Pro Gestumblindi (Einreichende Person)
2.  Pro Freigut (Diskussion) 09:47, 20. Jun. 2017 (CEST)
3.  Pro Jordi (Diskussion) 15:27, 20. Jun. 2017 (CEST)
4.  Pro --  Sir Gawain Disk. 19:00, 20. Jun. 2017 (CEST)
5.  Pro Conny 22:24, 20. Jun. 2017 (CEST).
6.  Pro --Wikifreund (Diskussion) 23:50, 20. Jun. 2017 (CEST)
7.  Pro Michi 19:07, 21. Jun. 2017 (CEST)
8.  Pro --MGChecker – (📞| 📝| ) 20:16, 21. Jun. 2017 (CEST)
9.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 00:55, 22. Jun. 2017 (CEST)
10.  Pro --Jossi (Diskussion) 12:56, 22. Jun. 2017 (CEST)
11.  Pro --Daniel749 Disk. (ST–WPST) 21:34, 23. Jun. 2017 (CEST)
12.  Pro --Gr1 (Diskussion) 10:47, 28. Jun. 2017 (CEST)
13.  Pro --Kein Einstein (Diskussion) 15:58, 28. Jun. 2017 (CEST)
14.  Pro --Thomas Obermair 4 (Diskussion) 16:20, 28. Jun. 2017 (CEST)
15.  Pro --Sebastian Wallroth 22:24, 29. Jun. 2017 (CEST)
16.  Pro Brackenheim 19:10, 1. Jul. 2017 (CEST) noch immer dafür, vielleicht klappt es endlich mal in dieser Runde ...
17.  Pro – Doc Taxon • Disk. • WikiMUC • Wikiliebe?! • 19:28, 1. Jul. 2017 (CEST)
18.  Pro --DomenikaBo (Diskussion) 19:37, 1. Jul. 2017 (CEST)
19.  Pro --Luke081515 20:01, 1. Jul. 2017 (CEST)
20.  Pro -- Marcus Cyron Reden 20:18, 1. Jul. 2017 (CEST)
21.  Pro --Kritzolina (Diskussion) 20:38, 1. Jul. 2017 (CEST)
22.  Pro --Maimaid ✉ • Wikiliebe?! 21:07, 1. Jul. 2017 (CEST)
23.  Pro —DerHexer (Disk., Bew.) 21:26, 1. Jul. 2017 (CEST)
24.  Pro --Partynia ^{∞ RM} 23:09, 1. Jul. 2017 (CEST)
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).
26.  Pro --Flominator 10:27, 2. Jul. 2017 (CEST)
27.  Pro --PAB (Diskussion) 20:44, 2. Jul. 2017 (CEST)
28.  Pro --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 21:52, 2. Jul. 2017 (CEST) Da jeder verschieben darf, sollte auch jeder kopieren dürfen. Nicht nur Admins.
29.  Pro -- Mr N (Diskussion) 22:08, 2. Jul. 2017 (CEST)
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.
    
    

Spaltenweise Ausrichtung in Tabellen

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)

Diskussion

1. Der Wunsch ist verständlich.
2. HTML
   • Einfache Lösungen scheitern an der Struktur von HTML; genauer: an den Eigenschaften von Tabellen.
   • Spalten sind nicht die „Kinder“ einer Tabelle.
   • Die Kinder einer Tabelle sind die Zeilen; deren Kinder sind die Zellen. Eine Spalte kommt dadurch zustande, dass in jeder Zeile das dritte Kind gemeint sein mag; also eher als zufälliger Nebeneffekt. Das ist aber in der Philosophie von HTML/CSS keine trivial ausnutzbare Beziehung.
   • Wenn man es nur mit einer einzigen Tabelle im Wiki zu tun hätte, könnte man eine globale Formatierungsanweisung konstruieren, die sowas macht. Wir haben jedoch in der de-WP Millionen von Tabellen, und das in Tausenden von Konstellationen und Strukturen.
   • Weil Zeilen das Strukturelement sind, aus denen eine Tabelle besteht, lässt sich dein Wunsch trivial für eine Zeile realisieren; nicht aber für Spalten.
   • Bedenke außerdem, dass eine Tabelle nicht notwendigerweise ein regelmäßiges Gitter ist, sondern dass zwei oder mehr benachbarte Zellen verschmolzen sein können; was die Frage, zu welcher der beteiligten Spalten die gemeinsame Zelle stilistisch gehören soll, schwer zu entscheiden macht.
   • colgroup, col: Etwa 1995 bis 1998 gab es mal eine Syntax, die es erlaubte, das zu spezifizieren, was dir vorschwebt. Allerdings kaum Software, die in der Lage war, das auch optisch darzustellen. Inzwischen wird auch nicht mehr empfohlen, dies durch Browser zu unterstützen. Hintergrundinfos (englisch): stackoverflow hixie.ch
3. Zwischenfazit:
   • Der einzige robuste (und triviale) Lösungsweg ist es, weiterhin jeder Zelle die Formatierung explizit und inline (per style=) mitzugeben.
   • Die Umsetzung von Strukturbefehlen liegt in der Software beim Endnutzer. Das ist in unserem Fall der Browser, der kann nur HTML, und HTML kennt sowas ansonsten nicht.
4. Lösungsansatz:
   • Ein neuartiges Tool könnte einem markierten Spaltenbereich eine Eigenschaft (Ausrichtung, Farben) mitgeben; also einmalig jeder Zelle zuweisen.
   • Heutzutage würde man sowas nur noch innerhalb des VisualEditor programmieren.
   • Das steht danach also bei jeder gewünschten Zelle explizit drin.
   • Dabei muss das Tool in jeder Zelle vorhandene und ggf. abweichende Formatierungen erkennen, diese ggf. ersetzen oder ergänzen, und dabei auch die bei uns noch in Zehntausenden von Artikeln anzutreffenden seit 1998 veralteten Syntaxelemente erkennen und gleichwertig einbeziehen; intelligenterweise bei der Gelegenheit sofort durch zeitgenössische Syntax ersetzen.
   • Die Situation nicht-regelmäßiger Gitter ist zu beachten.
   • Der Quelltext der Tabelle muss nicht notwendigerweise vollständig im Quelltext der bearbeiteten Seite vorhanden sein. Vielmehr ist es in vielen Artikeln üblich, zentral für viele gleichartige Artikel das Design von Tabellenzeilen in Vorlagen zu hinterlegen. Die bleiben hiervon unbeeinflusst.
   • Es sollte eine Möglichkeit geben, im Header der Tabelle die Formatierung jeder einzelnen Spalte anzugeben. – Das wird aus den beschriebenen Gründen nix.
5. Tabellenvorlagen
   • Für viele Artikel zu gleichartigen Themen ist es üblich, das Design der Tabellenzeilen und weitere Auswertungen in speziellen Vorlagen zu hinterlegen, die dann auch zentral gepflegt werden können; und denen nur noch die inhaltlichen Werte übergeben werden, wobei die Werte gleich noch auf Gültigkeit und Plausibilität geprüft werden können und höhere Formatierungen wie etwa Verlinkungen daraus generiert werden können.
   • Auch dies käme deinem Ziel entgegen.

LG --PerfektesChaos 21:28, 10. Jun. 2017 (CEST)

Unterstützung

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

Antworten auf Diskussionsseiten vereinfachen

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)

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

• 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)

Diskussion

Ich würde mich voll und ganz dem Antrag anschließen und diesen sogar noch auf die Gestaltung von Wikipedia-Plattformen und -Portalen wie Auskunft, FzWP, Werkstätten etc. ausweiten, wo bei Auswahl von „neuer Abschnitt“ o. Ä. immer der Signaturstempel bereits vorgegeben ist, was einerseits die Sache natürlich vereinfacht, wenn man denn beim alten System bleiben will, aber andererseits auch störend ist, da immer noch eine zusätzliche Ziele unterhalb des eigentlichen Postings entsteht, wenn man die Signatur nicht manuell nach vorne zieht. Klingt vielleicht eher nach einem Rand- bzw. Luxusproblem, könnte aber in dem Zusammenhang ja ggf. mit berücksichtigt werden (besonders im Hinblick auf „Vielposter“).--Erdic (Diskussion) 17:56, 10. Jun. 2017 (CEST)

Ist eine gute Idee. Liquid Threads ist übrigens tot, und Flow wird nicht mehr weiterentwickelt. In der deutschen Wikipedia ist auch nicht geplant diese Funktionen einzuführen. Dein Vorschlag müsste dann standardmäßig als Helferlein aktiviert sein, dafür bräuchten wir auch ein Meinungsbild. Ich kündige aber schon mal an dich zu unterstützen, wenn du Hilfe brauchst. --FNDE 20:11, 11. Jun. 2017 (CEST)

@Martin Kraft: Danke für deinen Wunsch! Wir haben ihn im Team besprochen und möchten sicherheitshalber auf ein paar Dinge hinweisen:

• 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

Wenn du den Wunsch weiterhin einreichen möchtest, arbeite diese Hinweise doch bitte unter „Anmerkungen“ noch mit ein (wenn möglich noch heute), damit allen Abstimmenden bewusst ist, worauf sie abstimmen. Dankeschön und beste Grüße! -- Johanna Strodt (WMDE) (Diskussion) 10:32, 15. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Naja, es wäre auch nicht mehr „Hack“ als viele andere hier gebräuchliche Funktionen – zumal sich das Ganze ja umsetze liese ohne irgendeine der bestehenden Funktionalitäten zu beeinträchtigten. D.h. das Schlimmste was (auch im Falle eines Fehlers) passieren könnten, wäre, das man Diskussionseiten wieder genau so editieren muss, wie jetzt auch, oder?

Natürlich wäre eine sauberer Lösung technisch schöner. Aber die sauberen Lösung, die bisher vorgeschlagen wurden würden einen harten Schnitt erfordern. Und (wie bereits in Berlin besprochen) sehe ich hier-zu-wiki auf absehbare Zeit keine Akzeptanz für diesen harten Umstieg von Status Quo auf Flow. Im Gegensatz zum ebenfalls anfangs umstrittenen VisualEditor kann es hier ja keine Koexistenz beider Lösungen geben – was vermutlich auch der Grund dafür ist, dass es bisher meines Wissens keine nennenswerte Flow-Unterstützergemeinde innerhalb der Community gibt...

So wie es ist, kann und sollte es aber auch nicht bleiben. Jeder weitere Tag, mit dieser nicht selbsterklärenden Diskussionsseiten führt zu vermeidbaren Edit-Wars, Missverständnissen und unsinnigen Wartungsarbeiten und vergrault so potentielle Autoren. Ich sehe hier wirklich einen Handlungsbedarf, der auch einen Hack rechtfertigen würde, und möchte den Wunsch daher weiter einreichen. // Martin K. (Diskussion) 13:35, 15. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Du kannst Euer Statement natürlich gerne unter "Anmerkungen" ergänzen. // Martin K. (Diskussion) 13:35, 15. Jun. 2017 (CEST)

@Martin Kraft: Ich verstehe dein Problem und warum du das so vorgeschlagen hast. Auch wenn das Ziel der technischen Wünsche grundsätzlich ist, nachhaltige, „nicht hacky“ Lösungen zu schaffen, kann dein Wunsch wie gesagt trotzdem drin bleiben – wichtig ist es halt aus unserer Sicht, klar zu machen, dass es ein Hack ist und dass der entsprechend an seine Grenzen kommen kann. Darum habe ich unsere Hinweise nun unter „Anmerkungen“ ergänzt. -- Besten Dank, Johanna Strodt (WMDE) (Diskussion) 14:17, 15. Jun. 2017 (CEST)

Entschiedener Widerspruch: Wikisyntax auf Diskussionsseiten ist ungeheuer mächtig und ungeheuer simpel. Das Hauptproblem ist aber, dass Diskseiten unglaublich viele Funktionen erfüllen. Neben der reinen Diskussion werden dort auch Entwürfe für Artikelteile abgelegt, kopiert und gemeinsam bearbeitet. Diskseiten müssen also alle Funktionen einer Artikelseite erfüllen, woran bisher alle Konzepte (Liquid Thread, Flow) gescheitert sind. PS: Nichts an Diskseiten ist wirklich kompliziert. Das Einrücken erfordert einen einmaligen Verständnisvorgang. Dann hat man es drauf. Grüße --h-stt !? 18:25, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:24, 19. Jun. 2017 (CEST)
3.  Pro -- ^Thomas 10:57, 20. Jun. 2017 (CEST)
4.  Pro -- Karl432 (Diskussion) 15:14, 20. Jun. 2017 (CEST)
5.  Pro --Gnom (Diskussion) 17:37, 20. Jun. 2017 (CEST)
6.  Pro --Claell (Diskussion) 19:10, 20. Jun. 2017 (CEST)
7.  Pro Gubeko (Diskussion) 20:53, 20. Jun. 2017 (CEST)
8.  Pro Conny 22:25, 20. Jun. 2017 (CEST).
9.  Pro GodeNehler (Diskussion) 05:55, 21. Jun. 2017 (CEST)
10.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 00:55, 22. Jun. 2017 (CEST)
11.  Pro Iva 10:44, 22. Jun. 2017 (CEST)
12.  Pro --Minihaa (Diskussion) 12:36, 23. Jun. 2017 (CEST)
13.  Pro mauriceKA (Diskussion) 13:15, 23. Jun. 2017 (CEST)
14.  Pro -- ShWh3F (Diskussion) 21:15, 23. Jun. 2017 (CEST)
15.  Pro --Daniel749 Disk. (ST–WPST) 21:42, 23. Jun. 2017 (CEST)
16.  Kontra Notwendig ist Wechsel zu einem benutzerfreundlichen System wie Flow. -- Nichtich (Diskussion) 22:57, 23. Jun. 2017 (CEST)
17.  Pro --DomenikaBo (Diskussion) 21:58, 25. Jun. 2017 (CEST)
18.  Pro --Incabell (Diskussion) 17:39, 27. Jun. 2017 (CEST)
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)
20.  Pro --Thomas Obermair 4 (Diskussion) 16:21, 28. Jun. 2017 (CEST)
21.  Pro für Lösung des Problems --Sophiston (Diskussion) 12:54, 29. Jun. 2017 (CEST)
22.  Kontra für Lösungsvorschlag --Sophiston (Diskussion) 12:54, 29. Jun. 2017 (CEST)
23.  Pro Für eine Lösung des Problems. --Sebastian Wallroth 22:26, 29. Jun. 2017 (CEST)
24.  Pro --Häuslebauer (Diskussion) 17:43, 30. Jun. 2017 (CEST)
25.  Pro -- Mboesch (Diskussion) 11:26, 1. Jul. 2017 (CEST)
26.  Pro --Drahreg01 (Diskussion) 22:52, 1. Jul. 2017 (CEST)
27.  Pro --PAB (Diskussion) 20:45, 2. Jul. 2017 (CEST)
28.  Pro --Devotus (Diskussion) 20:46, 2. Jul. 2017 (CEST)
    
    

Optimierung des Link-einfügen-Tools im Quelltext-Editor

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)

Diskussion

Hallo Erdic, du beschreibst einen Lösungsvorschlag in der Problembeschreibung. Leider wird dabei das Problem nicht ganz klar, wenn einem das Hintergrundwissen fehlt. Es wäre hilfreich wenn du genau die Problematik schildern könntest, damit der Wunsch besser verständlich ist. Vielleicht kannst du dann noch kurz dazu schreiben was BKL-Links sind :), VG --Charlie Kritschmar (WMDE) (Diskussion) 15:04, 14. Jun. 2017 (CEST)

Hallo, Charlie Kritschmar (WMDE), und danke für deine Nachfrage. Allerdings bin ich darüber etwas verwundert, da ich meine, mein Anliegen so deutlich und verständlich wie mir nur möglich formuliert zu haben. BKL steht für Begriffsklärung. Was genau verstehst du sonst nicht? PS: Wie bekomme ich denn diesen unschönen Abstand vor meinem Posting weg?--Erdic (Diskussion) 20:28, 14. Jun. 2017 (CEST)

Hallo Erdic, Abstand ist durch 2 geschweifte Klammern entstanden, die hinter dem Diskussionsabschnitt liegen müssen :) Im Abschnitt "Was ist das Problem?" beschreibst du schon einen Lösungsvorschlag für das Problem, sodass ich nicht nachvollziehen kann, was das eigentliche Problem ist. Es wäre hilfreich, wenn du die Lösungsvorschläge in den Abschnitt "Lösungsvorschlag" verschiebst, und den ersten Abschnitt dazu nutzt die gegenwärtige Situation zu erläutern und warum und wie genau diese ein Problem für dich darstellt darstellt. VG --Charlie Kritschmar (WMDE) (Diskussion) 10:19, 15. Jun. 2017 (CEST)

Okay, besten Dank für die Konkretisierung! Habe das nun nachgetragen und hoffe, damit wird mein Anliegen einer Optimierung des Quelltext-Linktools verständlicher. Beste Grüße--Erdic (Diskussion) 22:54, 15. Jun. 2017 (CEST)

@Erdic: Ich danke dir! Jetzt ist es super. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 14:14, 17. Jun. 2017 (CEST)

Zur Stimmenstreichung [2]: Erstmal; echt gut aufgepasst ! Dann, Curg schreibt - Zitatanfang: "i Info: Man hat mir insbesondere hier ausdrücklich die Möglichkeit eingeräumt, unter neuem Namen regelkonform wieder mitzumachen. Das ist mein gutes Recht, solange ich mich an die Regeln halte. Und das tue ich doch bislang, oder? Der IP-Edit stammt übrigens diesmal auch nicht von mir! --Curc (Diskussion) 20:33, 28. Jun. 2017 (CEST)" - Zitatende. Soviel zur Einhaltung der Regeln... Ich bin echt baff. --Sophiston (Diskussion) 18:11, 30. Jun. 2017 (CEST)

Unterstützung

1.  Pro Erdic (Einreichende Person)
2.  Pro --Dominic Z. (Diskussion) 18:10, 22. Jun. 2017 (CEST)
3.  Pro --DomenikaBo (Diskussion) 21:59, 25. Jun. 2017 (CEST)

    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)

4.  Pro --Thomas Obermair 4 (Diskussion) 16:21, 28. Jun. 2017 (CEST)
5.  Pro --Sophiston (Diskussion) 12:58, 29. Jun. 2017 (CEST)
6.  Pro --Sebastian Wallroth 22:27, 29. Jun. 2017 (CEST)
7.  Pro -- Mr N (Diskussion) 22:30, 2. Jul. 2017 (CEST) Wie Praktisch.
   
   

Visual Editor: Verlinkungen und weitere Formatierungsmöglichkeiten in Vorlagen

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)

Diskussion

Hallo Mushushu, danke für deinen Wunsch! Könntest du das Problem noch etwas genauer schildern? Wie genau gehst du vor und was klappt da nicht? Vielleicht mit Screenshot, wenn möglich? Es wäre wichtig, dass du das direkt unter „Was ist das Problem?“ ergänzt, weil die Diskussionen mit Beginn der Abstimmung (19. Juni) ausgeblendet werden. -- Viele Grüße und besten Dank, Johanna Strodt (WMDE) (Diskussion) 11:59, 16. Jun. 2017 (CEST)

Hallo Johanna Strodt (WMDE)! Ich habe genauer beschrieben, was ich meine. Bitte sag mir, ob es eindeutig genug ist oder ob ich etwas übersehen habe. Viele Grüße --Mushushu (Diskussion) 12:38, 16. Jun. 2017 (CEST)

Mushushu, jetzt ist es viel klarer! -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:59, 16. Jun. 2017 (CEST)

Unterstützung

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

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

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)

Diskussion

Unterstützung

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

Weiterleitungslinks auf Kapitel warten

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

 ^Thomas 19:33, 11. Jun. 2017 (CEST)

Diskussion

Die Links auf Artikel sind Anker, weshalb eine automatische "Weiterleitung" meines Erachtens kaum möglich sein wird, zumal diese Änderung auch in den Ursprungsartikeln stattfinden müsste. Ich fürchte, dass dies eine Wartungsaufgabe ist und bleiben wird. Beste Grüße --FNDE 20:00, 11. Jun. 2017 (CEST)

Die Antwort verstehe ich nicht. Dem Nutzer geht es doch gerade um den Fall, dass im Ursprungsartikel eine Abschnittsüberschrift geändert wird, und dann passt ja bekanntlich der Abschnittslink nicht mehr, wodurch man am Anfang des Artikels statt im passenden Abschnitt landet. Ich wäre auch dafür, das – wenn möglich – durch eine automatische Synchronisierung zu verbessern.--Curc (Diskussion) 02:37, 12. Jun. 2017 (CEST)

Habe ich etwas missverständlich formuliert. Es geht ja darum, dass beispielsweise 20 Artikel geändert werden müssten, wenn in einem Artikel der Abschnitt geändert wird. Ich denke diese Variante fällt raus, da es sich ja um Änderungen im Quelltext handelt und die Software das nicht selbst darf. Durch das Ankersystem gibt es also nur eine einzige Möglichkeit: man müsste eine Vorlage für eine Abschnittsüberschrift entwerfen, die man abweichend von der Überschrift mit einer anderen Anker-ID versehen kann. Das halte ich semantisch aber nicht für klug, wenn es inhaltlich sehr stark abweicht. Deshalb oben der Hinweis, dass man sowas individuell (oder mit Botunterstützung) prüft und als Wartungsaufgabe abarbeitet. Aber vielleicht hat hier ja jemand noch eine kluge Idee dazu :) --FNDE 10:40, 12. Jun. 2017 (CEST)

Das ist ein inhaltiches Problem. Wenn man auf einen Abschnitt verlinken muss, fehlt entweder ein Artikel oder eine Weiterleitung, auf die man verlinken könnte, oder der Link ist einfach unangebracht. 129.13.72.198 10:59, 14. Jun. 2017 (CEST)

Das Problem lässt sich mit Vorlage:Anker beheben, indem man entweder von Anfang an einen "kanonischen" Anker setzt, auf den man verlinken kann, oder indem man nachträglich einen Anker setzt, der der alten Überschrift entspricht. -- Daniel Kinzler (WMDE) (Diskussion) 16:45, 14. Jun. 2017 (CEST)

Hallo Thomas, reicht dir der Lösungsvorschlag von Daniel? Wenn ja, würde ich deinen Wunsch Freitag nach Wünsche außerhalb des Projektrahmens verschieben, wo wir erledigte und Wünsche außerhalb unseres Rahmens sammeln. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 20:26, 15. Jun. 2017 (CEST) Nachtrag: Nach nochmaliger Absprache mit den Enwicklern, würden wir den Vorschlag drin lassen. --Charlie Kritschmar (WMDE) (Diskussion) 14:18, 17. Jun. 2017 (CEST)

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 14:25, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 22:15, 19. Jun. 2017 (CEST)
4.  Pro mauriceKA (Diskussion) 13:17, 23. Jun. 2017 (CEST)
5.  Pro --Curc (Diskussion) 20:53, 27. Jun. 2017 (CEST)
6.  Pro --Thomas Obermair 4 (Diskussion) 16:22, 28. Jun. 2017 (CEST)
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)
8.  Pro --PAB (Diskussion) 20:46, 2. Jul. 2017 (CEST)
9.  Pro -- Mr N (Diskussion) 22:38, 2. Jul. 2017 (CEST)
   
   

Leerzeichen bei der Überschrift im VE

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)

Diskussion

@Hoefler50: Danke für den Wunsch! Ich war so frei, ihn etwas zu überarbeiten, damit schneller verständlich wird, worum es geht. Kannst du noch mal prüfen, ob es so weiterhin in deinem Sinne ist? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:06, 15. Jun. 2017 (CEST)

Danke fürs umarbeiten. Ich war mir mit der Formatierung nicht so sicher. --93.255.127.117 18:03, 15. Jun. 2017 (CEST)

Konvention ändern in: Beides ist OK... --Sophiston (Diskussion) 13:07, 29. Jun. 2017 (CEST)

Unterstützung

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

Besser Archiv- als Fehlerlinks

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)

Diskussion

Das ist eine Botaufgabe, die nicht vollautomatisch von der Software erledigt werden kann. Außer du meinst direkt beim einfügen, also wenn jemand versucht, einen kaputten Link einzufügen. --FNDE 20:00, 12. Jun. 2017 (CEST)

@Curc: Danke für deinen Wunsch! Vielleicht habe ich ein Brett vorm Kopf, aber ich bin noch nicht sicher, ob ich deinen Vorschlag richtig verstanden habe:

1. Sollen alle Artikel regelmäßig dahingehend überprüft werden, ob sie veraltete Links enthalten? (so verstehe ich es)
2. Oder soll der Link schon beim Einsetzen überprüft werden? (s. FNDEs Rückfrage)
3. Oder noch etwas anderes?

Falls 1) der Fall ist, wäre das – wie FNDE schon schreibt – tatsächlich eine Aufgabe für einen Bot und damit wäre der Wunsch kein Fall für diese Wunschliste. Zudem müsste in jedem Fall ein Meinungsbild o. ä. dazu geben, weil ein Bot für diese Aufgabe ja in den Inhalten editieren würde. Wenn du nicht 1) meintest, gib mir bitte ein Zeichen. Ansonsten verschiebe ich den Wunsch in die Rubrik „Wünsche außerhalb des Projektrahmens“.

Falls 2) oder 3) zutrifft, wäre es wichtig, dass du den Wunsch noch etwas ausformulierst, damit die Problembeschreibung noch klarer wird. Was wäre für dich z. B. ein geeigneter Archivlink? Hast du ein Beispiel? In jedem Fall möchte ich dich um eine Meldung, wenn möglich noch heute, bitten.

Und noch ein verwandter Hinweis: Es wäre es gut, wenn du den Titel deines Wunsches umformulieren könntest, damit alle Abstimmenden schnell erfassen können, worum es geht: „Archivierung von Weblinks“ klingt danach, als würden Links selbst archiviert, aber das ist, glaube ich, nicht das, was dir vorschwebt. (Oder doch?) -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:47, 15. Jun. 2017 (CEST)

Fall 1 wurde schon per Bot bearbeitet, nämlich durch den GiftBot (vgl. auf der Benutzerseite Pkt. 18 unter regelmäßig). Auf defekte Weblinks wird dann jeweils mit einer Mitteilung auf der Diskussionsseite des betroffenen Artikels hingewiesen. Vollautomatisch kann man das nicht machen, da immer ein Mensch kontrollieren muss, weil Webseiten zum Teil die Archivierung verhindern dürfen oder Webseiten so geschrieben sind, dass die Archivierung nicht wirklich erfolgreich durchgeführt werden kann. — Speravir – 23:16, 15. Jun. 2017 (CEST)

Der Behauptung, dass eine vollautomatische Prüfung und Ersetzung nicht möglich ist, möchte ich dahingehend widersprechen, dass dies in einigen Wikipedias bereits geschieht. Siehe dazu meta:InternetArchiveBot. Jedoch ist eindeutig kompliziert (für den Bot-Programmierer), wenn nicht beim Einfügen des Links bereits automatisch ein Snapshot im InternetArchive erstellt wird. Daher würde ich sogar so weit gehen und fordern, dass bei jedem neuen Link in einem Artikel ein Snapshot beim InternetArchive ausgelöst wird. -- Chstdu (Diskussion) 15:16, 26. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Entschuldige bitte, dass ich erst jetzt dazu komme, dir zu antworten. Im Idealfall sollte die Umsetzung meiner Idee alle drei von dir angesprochenen Aspekte abdecken. Mit Meinungsbildern u. Ä. habe ich bislang noch keine Erfahrung. Falls jemand also den Vorschlag auch hinsichtlich Punkt 1, was aus meiner Sicht mit das wichtigste von allen drei Problemfeldern wäre, für sinnvoll erachtet, möge er dies am besten unten entsprechend vermerken. Und falls jemand mehr Erfahrung mit den nötigen Schritten für ein erfolgreiches Meinungsbild hat, würde ich mich natürlich sehr über Unterstützung freuen. Ich stelle mir das recht aufwendig vor und weiß nicht, ob ich alleine dazu käme, so etwas in Gang zu setzen. Liebe Grüße--Curc (Diskussion) 22:12, 26. Jun. 2017 (CEST)

@Curc: Danke für deine Antwort. Wenn es der Wunsch unter die Topwünsche schafft, könnten wir deine Unterstützer ja anpingen, um weitere Unterstützung anzufragen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 09:57, 27. Jun. 2017 (CEST)

Alles klar, danke dir ganz herzlich!--Curc (Diskussion) 09:59, 27. Jun. 2017 (CEST)

Aus meiner Sicht der mit Abstand inhaltlich wichtigste Änderungsvorschlag. Ich kann dem grundsätzlichen Problem mehr als zustimmen. Die Angabe von Quellen ist ja nicht ohne Grund, einer der zentralen Punkte für die Artikelqualität. Umso unverständlicher, warum es bisher keinen *globalen* Ansatz dafür gibt, Weblinks als Quellen erhaltbar zu machen. Leider steht der Vorschlag hier ganz unten und geht ein wenig unter. Wobei ich glaube der besser Ansatz wäre, direkt von jedem Link automatisiert einen Screenshot zu erstellen und als zweiten Link immer anzubieten. Es ist ja nicht ganz trivial Seiten zu erkennen, die nicht mehr verfügbar sind. Stichwort Weiterleitung.
Ich habe die Problembeschreibung angepasst: Wen betrifft das Problem besonders?= Die Glaubwürdigkeit von Wikipediaartiklen generell. --Sophiston (Diskussion) 13:25, 29. Jun. 2017 (CEST)

Vorschlag: Bei Einfügen eines Links sollte automatisch bei archive.org und/oder archive.is und/oder einem ähnlichen Dienst geprüft werden, ob es eine archivierte Version gibt; wenn nicht sollte dort eine angelegt werden. Die Archivversion sollte in der Vorlage verlinkt werden. Wenn die Originalseite nicht mehr erreichbar ist (wird durch Bot geprüft) wird der Link auf die Archivversion aktiviert. --Sebastian Wallroth 22:38, 29. Jun. 2017 (CEST)

Unterstützung

1.  Pro Curc (Einreichende Person)
2.  Pro Zabia (Diskussion) 17:11, 20. Jun. 2017 (CEST)
3.  Pro Gelber kaktus (Diskussion) 21:47, 20. Jun. 2017 (CEST)
4.  Pro mauriceKA (Diskussion) 13:18, 23. Jun. 2017 (CEST)
5.  Pro -- Nichtich (Diskussion) 23:00, 23. Jun. 2017 (CEST)
6.  Pro -- Chstdu (Diskussion) 15:16, 26. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 16:23, 28. Jun. 2017 (CEST)
8.  Pro --Sophiston (Diskussion) 13:25, 29. Jun. 2017 (CEST) Lösungs muss mehr als nur eine deutsche Lösung sein können.
9.  Pro --Sebastian Wallroth 22:38, 29. Jun. 2017 (CEST)
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.
11.  Pro -- Shoeper 18:03, 30. Jun. 2017 (CEST)
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)
13.  Pro --PAB (Diskussion) 20:47, 2. Jul. 2017 (CEST)