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

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]]
}}

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]]
}}

–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

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.

Lösungsvorschlag

Das Icon wieder in die Bearbtungsleiste 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

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

Reflist und Reflist-talk

Was ist das Problem?

Einfügen von Referenzen verkompliziert und schlecht gestaltet. Insbesondere auf Diskussionsseiten (Reflist-talk), aber auch im Artikel (Reflist). Diese Funktionen gibt es im englischen Wikipedia, aber nicht im Deutschen!

Wen betrifft das Problem besonders?

Diejenigen die auf einer Diskussionsseite Artikel verlinken.

Lösungsvorschlag

Einführung von Reflist und Reflist-talk.=== Vorschlagende Person === Rævhuld (Diskussion) 16:00, 29. Mai 2017 (CEST)

=== Diskussion ===

Verstehe ich das richtig, dass Du willst, dass die Vorlagen en:Template:Reflist und en:Template:Reflist-talk auch in der De-Wikipedia verfügbar sind? Dann bist du hier falsch damit. Das wäre eine Community-Entscheidung und gehört zunächst nach Wikipedia:WikiProjekt Vorlagen/Werkstatt. Lies dir aber vorher die sachkundigen Antworten vom Perfekten Chaos in Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2014/2#Englische Vorlagen {{efn|}} und {{math|}} durch (ist zwar länger, aber reflist kommt vor).
Übrigens kann man eine mehrspaltige Darstellung der Referenzen seit einiger Zeit völlig ohne Vorlage erreichen, siehe Hilfe:Einzelnachweise#Mehrspaltige Darstellung aller Einzelnachweise. — Speravir – 22:05, 1. Jun. 2017 (CEST)

Unterstützung

Diskussionsseiten einrichten

Was ist das Problem?

Ziemlich kompliziert die wichtigsten Funktionen zu finden / hereinzukopieren. Wenn man eine Diskussionsseite einrichtet, wie z.B. Talk:2016_Orlando_nightclub_shooting, dann muss es a) von einem Experten erstellt werden und b) auch dann nimmt es viel Zeit in Anspruch.

Wen betrifft das Problem besonders?

Diskussionsseiten

Lösungsvorschlag

Eine automatische Einrichtung von einer Diskussionsseite. Möglicherweise auch durch Ausfüllung eines Formulars, die dann ein Mensch ausfüllen kann. Inhalten sollten vor allem folgendes sein: Automatisch archivieren, die verschiedenen Archive und Einbindung in die verschiedene Wikiprojekte. Bei lebenden Personen dann auch diese Vorlage automatisch einbinden.=== Vorschlagende Person === Rævhuld (Diskussion) 16:17, 29. Mai 2017 (CEST)

=== Diskussion ===

Darf man bei deinem Lösunsvorschlag noch Vorlage:Artikel über lebende Person hinzufügen? ーTesser4D 【Diskussion】 11:14, 30. Mai 2017 (CEST)

Vielen Dank. Habe es in meinem Vorschlag eingebunden.--Rævhuld (Diskussion) 16:32, 30. Mai 2017 (CEST)

Einbindung von Wikiprojekt-Bausteinen sind schon jetzt möglich, aber von der Community nicht gewünscht, also nichts technisches, sondern nur was für ein MB. Archivierung braucht man bei der ersten Einrichtung einer Diskussionsseite ohnehin nicht, erst wenn die so stark genutzt wird, dass sich eine Archivierung auch lohnt. Die erstmalige Einrichtung einer normalen Artikeldiskussionsseite ist eigentlich denkbar einfach, man muss einfach nur seine Anmerkung/Frage etc. dorthin schreiben und speichern. --Orci Disk 16:37, 30. Mai 2017 (CEST)

@Rævhuld: Hallo und danke für diesen Wunsch! Es wäre toll, wenn du noch etwas detaillierter die Situation beschreiben könntest, in der du dem Problem begegnest. Beispielsweise: Wann legst du Diskussionsseiten an und mit welchem Ziel? Wie gehst du dabei vor und was ist dabei zu kompliziert? Das hilft allen, die später abstimmen, den Wunsch besser zu verstehen, und erhöht somit deine Chancen darauf, gewählt zu werden. :) -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:12, 10. Jun. 2017 (CEST)

Unterstützung

Diskussionssieten Layout und Funktionsumfang wie im englischen Wikipedia.

Was ist das Problem?

Diskussionsseiten Layout und Funktionsumfang wie im englischen Wikipedia fehlt im deutschen.

Wen betrifft das Problem besonders?

Diskussionsseiten

Lösungsvorschlag

Übernehmen.=== Vorschlagende Person === Rævhuld (Diskussion) 16:18, 29. Mai 2017 (CEST)

=== Diskussion ===

@Rævhuld: Danke für den Wunsch! Könntest du noch genauer beschreiben, was dir fehlt? Und deckt sich dein Wunsch möglicherweise mit diesem: Trennung der Communityfunktionen von Mediawiki? Dann wäre es sinnvoll, dass newt713 und du euren Wunsch gemeinsam einreicht und den anderen aus der Umfrage entfernt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 15:51, 10. Jun. 2017 (CEST)

Unterstützung

Automatisch Referenz aus Hyperlink generieren

Was ist das Problem?

Ein Problem ist es nicht. Es wäre nur komfortabel, wenn es so etwas gäbe. Ich bin mir nicht sicher, ob und inwieweit das umsetzbar ist, aber es wäre schön, ein

→ Tool zu haben, bei dem man einen Link eingibt und das dann einen (mehr oder weniger perfekten) <ref>-Baustein für eine Fußnote ausgibt. Setzt natürlich voraus, dass man dafür an die Daten kommt, mit denen man diesen Baustein dann befüllt. Womöglich rücken die einige Anbieter heraus bzw. lassen sich auslesen?

(Einfach eine Idee..)

Wen betrifft das Problem besonders?

Fast jeden.

Lösungsvorschlag

Das überlasse ich versierteren Leuten.

→ Bsp./Variante : man gibt dem Programm den Link zu dem Artikel auf einer Nachrichtenseite (z.B. Welt online); das Programm holt sich den Titel, Autor etc. von der Website und packt das in einen Ref-Baustein, der als Kopiervorlage angezeigt wird.. Umsetzbar?=== Vorschlagende Person === Zuviele Interessen (Diskussion) 17:29, 29. Mai 2017 (CEST)

=== Diskussion ===

Gelegentlich dauert die Erstellung der Fußnote (etwa mit zig Autoren etc..) ja länger als die Erstellung des Textes, der referenziert wird..

Hallo @Zuviele Interessen:, danke für den Wunsch. Meinst du so etwas, wie der Visual-Editor es mit Citoid bereits macht? Das geht mit Gadgets auch für den Quelltext-Editor und wird im neuen Quelltext-Editor auch integriert sein. Michael Schönitzer (WMDE) (Diskussion) 01:37, 30. Mai 2017 (CEST)

@Zuviele Interessen: Über Bookmarklets, wie Wikipedia:Technik/Browser/Bookmarklet#Einzelnachweise / Fußnoten, ist das auch heute schon möglich. --Flominator 08:26, 30. Mai 2017 (CEST)

Es ist schon alles gesagt, nur noch nicht von allen. Im VisualEditor funktioniert das bereits erstaunlich gut. Auf „Belegen“ klicken, URL oder ISBN reinkopieren, Beleg erzeugen lassen, vielleicht noch ein paar Kleinigkeiten von Hand optimieren, fertig. –Schnark 10:32, 30. Mai 2017 (CEST)

Ja, das geht alles in die richtige Richtung. Mir ist jetzt auch so, als ob ich schon mal eine Lösung wie über Bookletmarklets gesehen aber für zu aufwendig befunden hatte - war wohl doch keine so eigene Idee.

Wenn so etwas bereits für den neuen Quelltext-Editor eingeplant ist, dann freue ich mich drauf. Vielen Dank.--Zuviele Interessen (Diskussion) 12:52, 30. Mai 2017 (CEST)

Du kannst den neuen Quelltext-Editor in den Betafunktionen (ganz oben rechts unter "Beta") aktivieren und das schon mal ausprobieren. Wenn das deinem Wunsch entspricht, würden wir ihn in die Rubrik "Wünsche die bereits erledigt oder in Arbeit sind" verschieben. Falls nicht, kannst du deinen Wunsch ja noch entsprechen abändern. -- Michael Schönitzer (WMDE) (Diskussion) 17:18, 30. Mai 2017 (CEST)

Unterstützung

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)

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)

Unterstützung

Danke für die Hinweise, werde versuchen, ob ich damit zurechtkomme. Grüße --Elcap (Diskussion) 09:02, 31. Mai 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, ob expliziet 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)

Unterstützung

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)

Unterstützung

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.=== 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)

Unterstützung

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

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 ===

Unterstützung

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

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.

Lösungsvorschlag

Vorlage_Diskussion:IPA#Verlinkung_von_einzelnen_Lauten (idealiter global wirksam)=== Vorschlagende Person === Erdic (Diskussion) 21:33, 30. Mai 2017 (CEST)

=== Diskussion ===

Unterstützung

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?

Lösungsvorschlag

Wikipedia:Fragen zur Wikipedia#Automatische Linkumwandlung (idealiter global wirksam)=== Vorschlagende Person === Erdic (Diskussion) 21:41, 30. Mai 2017 (CEST)

=== Diskussion ===

Unterstützung

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)

Unterstützung

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)

Unterstützung

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

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 de Fall ist.=== 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

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

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

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 ===

Unterstützung

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 ===

Unterstützung

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

Die zwangsweise Einfügung von Zeilenumbrüchen in den Vorlagen Literatur und Internetquelle durch die Verwendung von WSTM beenden.

Was ist das Problem?

Durch die Zeilenumbrüche werden die Vorlagen in die Länge gezogen und die zu editierenden Texte dadurch unnötig und unübersichtlich verlängert. Gerade bei der Verwendung von vielen Vorlagen in einem Artikel kann das ganz schön nerven. Es gibt Editoren, die die Zeilenumbrüche in ihren Artikeln nicht wünschen.

Wen betrifft das Problem besonders?

Editoren

Lösungsvorschlag

Das WSTM soll nur Zeilenumbrüche anwenden, wenn sie vorher schon in dem Artikel verwendet wurde und soll keine zwangsweise neu erzeugen.=== Vorschlagende Person === Ulanwp (Diskussion) 23:03, 1. Jun. 2017 (CEST)

=== Diskussion ===

WSTM = WikiSyntaxTextMod, oder? Dann gehört Dein Wunsch/Deine Beschwerde nicht hierher, sondern auf die zu diesem Skript gehörende Diskussionsseite, wo dir der Skriptautor PerfektesChaos dann mit Sicherheit auch eine kompetente Antwort gibt. — Speravir – 20:23, 2. Jun. 2017 (CEST)

Unterstützung

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

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 abspeichert. 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)

Unterstützung

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

Neuer Bearbeitungsmodus bei der Vorlagenprogrammierung

Was ist das Problem?

Bei der Hilfe:Vorlagenprogrammierung 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)

Unterstützung

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.

Lösungsvorschlag

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

=== 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

Einheitliches Layout von Tabellen

Was ist das Problem?

Ich bebildere die Wikipedia mit Fotos von Kulturdenkmalen und Naturschutz. Dazu trage ich die Bilder und evtl. den Link auf die Kategorie in Commons in die entsprechenden Tabellen ein.
Beispiele:

• Liste der Geotope im Kreis Nordfriesland
• Liste der FFH-Gebiete in Schleswig-Holstein
• Liste der EU-Vogelschutzgebiete in Schleswig-Holstein
• Liste der Naturdenkmale in Ludwigshafen am Rhein
• Liste der Naturschutzgebiete im Kreis Bergstraße
• Liste der Kulturdenkmale in der Aacher Altstadt
• Liste der Baudenkmäler in Wolfratshausen
• Liste der Baudenkmale in Lüneburg
• Liste der Baudenkmäler in Hagen
• Liste der Kulturdenkmäler in Neustadt an der Weinstraße (Kernstadt)
• Liste der Kulturdenkmale in Wyk auf Föhr
• Liste des monuments historiques de Wissembourg
• Liste der Baudenkmäler in Stilfs
• Llista de monuments de Santanyí

Der unterschiedliche Aufbau ist IMHO für die Betrachter und die Bearbeiter verwirrend und lenkt vom Wesentlichen (Inhalt) ab.

Wen betrifft das Problem besonders?

Benutzer von Wikipedia, Fotografen und Ersteller von Tabellen zum Thema Denkmäler und Naturschutz.

Anmerkungen

Am Besten wäre es, wenn man für die Unzahl von Tabellen zum Thema Natur- und Denkmalschutz eine einheitliche Darstellung finden würde.=== Vorschlagende Person === F. Riedelio (Diskussion) 11:49, 6. Jun. 2017 (CEST)

=== Diskussion ===

Hallo @F. Riedelio: Danke für den Wunsch. Ich bin mir aber leider nicht sicher, ob er hier am richtigen Platz ist, da man ihn wohl nicht durch eine Technische Änderung durch die Softwareentwickler lösen würde sondern sich die Wikipedia Community auf ein Format einigen müsste – oder habe ich dich falsch verstanden? -- Michael Schönitzer (WMDE) (Diskussion) 13:49, 6. Jun. 2017 (CEST)

Hallo @Michael Schönitzer (WMDE):,

vielen Dank für die schnelle Antwort.

Dass mit den technischen Wünschen Probleme gemeint sind, die nur durch Entwickler gelöst werden können, war mir leider nicht bewusst.

Dass sich die Wikipedia Community länderübergreifend auf ein Format einigt habe ich kaum Hoffnung ;-(

--F. Riedelio (Diskussion) 17:49, 6. Jun. 2017 (CEST)

Unterstützung

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

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.=== 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)

Unterstützung

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

Es sollte ein Programm geben, mit dem ich auf der Spezialseite „Benutzerbeiträge“ gezielt nach von einem Nutzer verfasstem Text suchen kann (ähnlich wie bei WikiBlame; das funktioniert aber bei Spezialseiten wie „Benutzerbeiträge“ nicht).

Was ist das Problem?

Nehmen wir an, ich suche gezielt nach einer bestimmten Äußerung eines Nutzers. Ich weiß, wer diese Äußerung getätigt hat, aber ich weiß nicht mehr, wann, wo und in welchem Zusammenhang er dies getan hat. Das ist sicherlich schon vielen hier passiert. Wie kommt man nun an das Zitat heran?

Wen betrifft das Problem besonders?

Jeden aktiven Nutzer

Lösungsvorschlag

Dafür wäre doch ein „Beitragsscanner“ – wie das bereits für normale Seiten bestehende WikiBlame – großartig! (idealiter global wirksam)=== Vorschlagende Person === Erdic (Diskussion) 17:34, 10. Jun. 2017 (CEST)

=== Diskussion ===

Unterstützung

Bei Verschiebungen sollen alle Links auf die Ursprungsseite automatisch zu Links auf die neue Seite umgewandelt werden (also keine bloße Weiterleitung).

Was ist das Problem?

Jeder kennt das Problem: Man will eine Seite verschieben, und wenn diese noch besonders häufig verlinkt ist, steht man vor dem lästigen Problem, idealiter alle diese Links auf das neue Lemma „umbiegen“ zu müssen, damit man nicht erst über den Zwischenschritt einer Weiterleitung zum richtigen (neuen) Lemma gelangt.

Wen betrifft das Problem besonders?

Jeden aktiven Nutzer

Lösungsvorschlag

Automatische Synchronisierung (?) oder aber, wenn das partout nicht möglich ist, Bot (idealiter beide Lösungen global wirksam).=== Vorschlagende Person === Erdic (Diskussion) 17:38, 10. Jun. 2017 (CEST)

=== Diskussion ===

Unterstützung

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.=== Vorschlagende Person === Martin K. (Diskussion) 17:40, 10. Jun. 2017 (CEST)

=== Diskussion ===

Unterstützung

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)

Möglichkeit zur optionalen Ergänzung eines Kommentars in der Vorlage:Webarchiv

Was ist das Problem?

Bei dieser Vorlage gibt es, wenn ich es richtig gesehen habe, anders als bei ähnlichen Vorlagen wie z. B. Vorlage:Internetquelle nicht die Möglichkeit, sprich keinen Parameter, um einen ergänzenden Kommentar anzubringen. Dies kann jedoch gerade bei komplexeren Archivalien durchaus notwendig und somit sinnvoll sein. Es wäre auch ggf. auch ratsam, auch über die Möglichkeit zur Einbindung weiterer Parameter bspw. aus Vorlage:Internetquelle nachzudenken.

Wen betrifft das Problem besonders?

Alle Benutzer der Vorlage:Webarchiv

Vorschlagende Person

Erdic (Diskussion) 19:43, 10. Jun. 2017 (CEST)

=== Diskussion ===

Das gehört doch nicht in die Technischen Wünsche, sondern in die Vorlagendiskussion und/oder die Vorlagenwerkstatt. — Speravir – 00:11, 11. Jun. 2017 (CEST)

Unterstützung

Aktive Sichter können eigene Unterseiten löschen.

Was ist das Problem?

Ich benutze meine Unterseiten recht intensiv zur Vorbereitung von Artikeln, muss aber einen Admin bitten, diese zu löschen. Ich fände es wünschenswert, dass man als "Inhaber" der Unterseite dieses selbst machen könnte.

Wen betrifft das Problem besonders?

Benutzer, die intensiv Artikel auf ihren Unterseiten anlegen.

Vorschlagende Person

 Nicola - Ming Klaaf 18:20, 10. Jun. 2017 (CEST)

=== Diskussion ===

Das sollte aus Sicherheitsgründen auf selbst im eigenen BNR angelegte Seiten beschränkt bleiben. Nicht, dass man einen öffentlichen Artikel verschiebt und dann in seinem BNR löscht. --Sitacuisses (Diskussion) 00:56, 11. Jun. 2017 (CEST)

Unterstützung

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

Was ist das Problem?

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
  • diese bei Änderungen von Artikel- (Lemmata) und Abschnittsüberschriften in den Wiki-Projekten bzw. bei Verschiebungen auf externen Websites automatisch angepasst werden und
  • bei Eingabe von Wiki-Links in – auch für einzelne Abschnitte – stets die aktuelle Linkversion in der Autovervollständigung angezeigt wird?

Wen betrifft das Problem besonders?

Alle aktiven Nutzer

Vorschlagende Person

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

=== Diskussion ===

Unterstützung