Wikipedia:Technische Wünsche/Wunschparkplatz/Wünsche für alte Umfragen

Wünsche, die vor der letzten Umfrage eingereicht wurden, wurden auf diese Seite verschoben. Wenn sie bei der nächsten Umfrage berücksichtigt werden sollen, verschiebt die entsprechenden Wünsche bitte – mit aktueller Signatur – wieder auf den Wunschparkplatz.

Bilder-Navigation in Commons Kategorien

Was ist das Problem?

Unabdingbar wichtig ist eine verbesserte Navigation, nicht nur 200 Bilder und vorhergehende Seite ↔ nächste Seite. Unsere Kategorien werden derzeit von Panoramiouploads überschwemmt, hunderte, in manchen Kategorien tausende Bilder. Niemand klickt sich z. B. 15x (!) durch 3129 Dateien in c:Category:Blasewitz, um ein Bild zu suchen oder gar zu finden.

Wen betrifft das Problem besonders?

Commons-Nutzer.

Lösungsvorschlag

Sinnvolle Navigation: << . < . 1 . 2 . 3 . ... . Gehe zu Seite ZZ . > . >> analog Navigation z. B. DNB unten

Vorschlagende Person

--Frze ^{> Disk} 09:15, 28. Jun. 2017 (CEST)

Diskussion

Benachrichtigen farblich differenzieren

Was ist das Problem?

Derzeit erfolgen wichtige Benachrichtigungen durch eine rot unterlegte Ziffer, die manchmal/einem wie ein rotes Tuch wirkt.

• Wen betrifft das Problem besonders/würde diese Neuerung helfen: alle angemeldeten Nutzer
• Falls bekannt: Existierende Lösungen, Lösungsvorschläge und/oder Link zu Phabricator-Ticket:

1. Farblich differenzieren:

rot (Rücksetzungen; es besteht möglicherweise Handlungsbedarf)

gelb (Erwähnungen; es besteht Handlungsbedarf)

Hintergrund weiß, Ziffer gelb, gelber Rahmen (eigene Erwähnung wurde gesendet, kein Handlungsbedarf)

grün (Dankeschön, kein Handlungsbedarf)

orange (bei mehreren Benachrichtigungen verschiedener Kategorien)

gelb-orange (gleicher Farbton wie bei Du hast neue Nachrichten auf Deiner Diskussionsseite)

blau (in anderen Projekten, z. B. Commons)

2. Nutzung der Notifications extension icons sofort im Seitenkopf, nicht nur in der Seite Spezial-Benachrichtigung:

• 
  rot
• 
  gelb
• 
  gelb, weiß hinterlegt
• 
  gelb-orange
• 
  grün

Wen betrifft das Problem besonders?

Wen betrifft das Problem besonders?

Lösungsvorschlag

Eine individuelle Einstellung sollte ermöglicht werden.

Vorschlagende Person

--Frze ^{> Disk} 10:02, 28. Jun. 2017 (CEST)

Diskussion

Bei Einbindung ersetzbare Vorlagen/Variablen

Was ist das Problem?

Bei zahlreichen Vorlagen, die vom Datum, an dem sie gesetzt wurden, abhängig sind, muss dieses händisch eingetragen werden, obwohl zahlreiche entsprechende Variablen verfügbar sind.

Wen betrifft das Problem besonders?

letztlich alle Nutzer, die entsprechende Vorlagen einsetzen, also die meisten

Lösungsvorschlag

Es sollte eine Möglichkeit geben, eine Vorlage genau dann zu substituieren, wenn sie erneut eingebunden wird. Beispiel: Vorlage A (z. B. CURRENTMONTH, die letztlich wie eine Vorlage funktioniert) wird in Vorlage B eingebunden. Wird dann Vorlage B auf einer normalen Seite C eingebunden, soll CURRENTMONTH substituiert werden. Damit würde genau der Monat, in dem Seite C gespeichert wird, stehenbleiben.

Aktuell dagegen würde bei normaler Verwendung von CURRENTMONTH sich der Monat auf Seite C dynamisch ändern und bei einer Substitution von CURRENTMONTH auf der Vorlage B bei allen ihren Einbindungen der Monat der entsprechenden Änderung von Vorlage B zu sehen sein.

Vorschlagende Person

--C₂₁H₂₂N₂O₂ | 디굿숀 | Դիսք | Диск 23:13, 29. Jun. 2017 (CEST)

Diskussion

Höhe der Sonderzeichenleiste verschiebbar machen

Was ist das Problem?

Es ist schon sehr praktisch, eine Sonderzeichenleiste zu haben, aber wenn man viele verschiedene Buchstaben heraussuchen möchte, etwa um einen längeren Namen in Kyrillisch/Griechisch/Armenisch/etc. zu schreiben, ist sie zu niedrig.

Wen betrifft das Problem besonders?

Benutzer, die regelmäßig Sonderzeichen setzen.

Lösungsvorschlag

Die Sonderzeichenleiste einfach mit Cursorgriff in der Höhe verschiebbar machen.

Vorschlagende Person

--C₂₁H₂₂N₂O₂ | 디굿숀 | Դիսք | Диск 16:41, 30. Jun. 2017 (CEST)

Diskussion

Formulardaten merken beim Visual Editor

Was ist das Problem?

Formulare im Visual Editor sollen sich Eintragungen merken, damit man häufig verwendete nicht jedes Mal neu eintippen muss. Die Zusammenfassungszeile sollte sich einfach alle früheren Eingaben merken, wie es auch die Zusammenfassungszeile im Quelltexteditor tut. Das ist praktisch, weil viele Bearbeitungskommentaren immer wieder vorkommen, z. B. "Tippfehler", "Linkkorrektur", "Begriffsklärung aufgelöst". Menüs wie z. B. "Vorlage einfügen" sollten eine Funktion "zuletzt eingefügt" haben, die meine letzten 5 (oder so) verwendeten Vorlagen anzeigt. Die meisten benutzen nur ein Tausendstel der Vorlagen, meist immer wieder dieselben. (Eventuell sind das zwei separate Wünsche. Ich werde das noch besser ausformulieren, ist ja noch Zeit.)

Wen betrifft das Problem besonders?

Alle, die den Visual Editor benutzen

Anmerkungen

phab:T50274, Benutzer:Schnark/js/veSummary

Vorschlagende Person

--Mushushu (Diskussion) 17:17, 30. Jun. 2017 (CEST)

Diskussion

Ich habe mal den Link zu Phabricator und mein Benutzerskript ergänzt. –Schnark 09:12, 1. Jul. 2017 (CEST)

Danke! --Mushushu (Diskussion) 17:17, 2. Jul. 2017 (CEST)

Referenzen in Anmerkungen hinzufügen

Was ist das Problem?

Wenn man ein einer Anmerkung macht und dort eine Referenz einfügt, dann bekommt meine eine Fehlermeldung, dass ein </ref> fehlen würde, weil zwei <ref>'s ineinender verschachtelt sind (<ref>Anmerkung<ref>Beleg</ref></ref>).

Wen betrifft das Problem besonders?

Editoren die komplexe und/oder strittige Fachthemen editieren und belegte erklärende Anmerkungen machen müssen um den Sachverhalt zu schildern und so eine stabile Version erzeugen zu können, die auch von Lesern inhaltlich nachvollzogen und geprüft werden kann.

Lösungsvorschlag

Verschachtelte <ref>'s zulassen und somit den Referenzfehler: Es fehlt ein schließendes </ref>. eliminieren.

Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 17:13, 2. Jul. 2017 (CEST)

Diskussion

In Wikisource lösen wir dieses Problem mit {{CRef|text}} {{References|TIT||}}, diese Vorlage hat kein Problem mit Verschachtelungen mit normalen <ref></ref>. Das einzige, was man beachten muss: wenn eine Pipe (|) vorkommt, muss man sie in nowiki packen. Zabia (Diskussion) 20:11, 16. Jul. 2017 (CEST)

Also man müsste nur die bereits erstellten Vorlagen (s:Vorlage:CRef,s:Vorlage:Ref, s:Vorlage:References) hier importieren?

@Zabia: weißt du zufällig wo man das machen/beantragen kann? (Bei Wikipedia:Importwünsche konnte ich nicht sehen, dass das auch für Schwesterprojekten gemacht wird.)

 — Johannes Kalliauer - Diskussion | Beiträge 17:20, 17. Jul. 2017 (CEST)

Nein, @JoKalliauer:, leider weiß ich das nicht. Zabia (Diskussion) 17:42, 17. Jul. 2017 (CEST)

Genau das habe ich mir auch schon als Wunsch vorgestellt (zur Überschrift ↑). Im Moment helfe ich mir so:
    Methanobacterium gehört in die Domäne Archaea und dort in das Phylum (oder in die Abteilung) Euryarchaeota.^{[A 3][8][9][10]}
    ...
    3. ↑ Garrity et al. (2001) haben das Phylum Euryarchaeota (Buchkapitel, Seiten 211-355) mit der neuen Klasse Methanobacteria (Boone 2001, Abschnitt ab Seite 213) in einem Buchband zur Domäne Archaea veröffentlicht (2001, doi:10.1007/978-0-387-21609-6). Von Woese et al. (1990, PMID 2112744) stammen die Namen Euryarchaeota und Archaea für die beiden höheren Taxa.
    ...
    8. ↑ a b c George M. Garrity, Joh... ...007/978-0-387-21609-6_17.
    9. ↑ a b c d e David R. Boone: Class I. Methanobac... ...78-0-387-21609-6.
    10. ↑ a b c d e f g C. R. Woese, O. Kandler, M. L. Whee... ...MC 54159 (freier Volltext).
--Dirk123456 (Diskussion) 13:27, 19. Jun. 2019 (CEST)

Sorry, habe mich vereditiert und die Vorlage kaputt gemacht; statt {{... |Diskussion= ... meins}} habe ich {{... |Diskussion= ... meins geschrieben. Wieder heil. --Dirk123456 (Diskussion) 14:50, 19. Jun. 2019 (CEST)

Schade, dass das Thema scheinbar sanft entschlafen ist -- oder gibt es schon eine brauchbare Lösung? --Klaus-Peter (auf und davon) 10:14, 21. Mai 2020 (CEST)

Sicher gibt es die. ^Anm.

 

Hier ist eine Anmerkung

Einzelnachweise

Für Fußnoten gibt es die Vorlagenreihe {{FN}} {{FNZ}} {{FNBox}} Allerdings erschließt sich mir nicht wirklich weshalb man ein ref in ref setzen sollte. --Liebe Grüße, Lómelinde Diskussion 14:28, 21. Mai 2020 (CEST)

Kein Zeilenumbruch vor Einzelnachweisen

Was ist das Problem?

Zwischen einem Wort/Interpunktionszeichen und der folgenden Ziffer, die einen Einzelnachweis anzeigt, soll nie ein Zeilenumbruch entstehen.

Wen betrifft das Problem besonders?

Leserinnen und Leser

Vorschlagende Person

--Mushushu (Diskussion) 17:18, 2. Jul. 2017 (CEST)

Diskussion

Mushushu, Du meinst quasi nicht so hier: Wort.

^[1]

--FNDE 21:13, 16. Jul. 2017 (CEST)

@FNDE: Exakt! --Mushushu (Diskussion) 23:19, 16. Jul. 2017 (CEST)

Dann der konkrete Vorschlag an die Entwickler: den hochgestellten Refs einfach white-space: nowrap; im Stylesheet anhängen. --FNDE 23:34, 16. Jul. 2017 (CEST)

So einfach ist das? Na, dann wird es ja Zeit. :) Danke fürs technische Ausformulieren, FNDE! --Mushushu (Diskussion) 11:56, 17. Jul. 2017 (CEST)

Zumindest als Zwischenlösung bräuchte es dafür sogar nicht mal einen Entwickler von WMF/WMDE – jeder Admin kann das mit einem Eintrag in die MediaWiki:Common.css korrigieren. -- Michi 12:24, 17. Jul. 2017 (CEST)

Das sind doch mal gute Nachrichten. Hab die o.g. Lösung nur halbherzig getestet, aber kann man sicher noch mal professionell durchgehen. --FNDE 16:16, 17. Jul. 2017 (CEST)

Gemeldet in Phabricator
Task T125480

Weil das nebenan auch kürzlich aufkam habe ich das auch kurz getestet: Nein, funktioniert nicht. --nenntmichruhigip (Diskussion) 11:05, 26. Sep. 2019 (CEST)

Zugriffsdatum automatisch generieren (Visual Editor)

Was ist das Problem?

Bei der Vorlage:Internetquelle (und ggf. anderen Vorlagen, die ein Zugriffsdatum erfordern) soll das aktuelle Datum automatisch als Zugriffsdatum eingetragen werden. (Eine Möglichkeit der manuellen Änderung muss bestehen bleiben. Beim späteren Bearbeiten der Vorlage soll sich das Zugriffsdatum nicht ändern.)

Wen betrifft das Problem besonders?

Benutzer/innen des Visual Editor

Vorschlagende Person

--Mushushu (Diskussion) 17:18, 2. Jul. 2017 (CEST)

Diskussion

view-source von SVGs-Links zulassen

Was ist das Problem?

Der link:

view-source:https://upload.wikimedia.org/wikipedia/commons/1/11/Climate_science_opinion_graph_3_Sans.svg

Funktioniert sowohl in Firefox als auch in Chrome, jedoch ist ein Verlinken mit

[view-source:https://upload.wikimedia.org/wikipedia/commons/1/11/Climate_science_opinion_graph_3_Sans.svg Angezeigter Text der zum Quelltext verlinkt]

nicht möglich, anscheinend geht nur http://*, https://*, ftp://* sftp://*, nntp://*.

Wen betrifft das Problem besonders?

Leute die mit SVG-Grafiken arbeiten.

Lösungsvorschlag

Man müsste nur view-source:https:// bei den bestehenden ( http://, https://, ftp:// sftp://, nntp://) hinzufügen und ein <a rel="nofollow" class="external free" href="view-source:https://">view-source:https://</a> erlauben.

Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 20:29, 21. Aug. 2017 (CEST)

Diskussion

Automatisches Einfügen von Koordinaten in Fotos auf commons

Was ist das Problem?

Wenn man auf commons ein Bild hochläst mit dem Formular: (B) Formular – bisherige Hochladeart, gibt es keine automatische Übernahme von Koordinaten in die Bildbeschreibung.

Bisher hat diese Aufgabe ein bot übernommen. Der allerdings scheint seit zwei Monaten (Juni 2017) inaktiv zu sein. Diese Funktion sollte die Wikisoftware übernehmen.

Wen betrifft das Problem besonders?

Alle Fotografen... Und natürlich die Leser, die den Aufnahmeort auf Karten suchen.

Lösungsvorschlag

Auswertung der exifdaten, falls vorhanden und automatische Übernahme in die Bildbeschreibung.

Vorschlagende Person

Nightflyer (Diskussion) 19:41, 31. Aug. 2017 (CEST)

Diskussion

Hallo Nightflyer, ich habe wahllos ein Foto auf Commons von mir herausgesucht. Dort hat der DschwenBot aus den EXIF-Daten den Ort des Fotoapparates als camera location eingefügt. Meinst Du etwas anderes? --Tommes ^✉ 12:24, 17. Mai 2020 (CEST)

Ja, den Bot meinte ich. Der sollte in die Wikisoftware integriert werden. Der Botbetreiber ist inaktiv. Aber mitlerweile egal, der Wizzard hat sich seit 2017 entscheidend verbessert.

SVG-Translate

Was ist das Problem?

Es gibt ein SVG-Bild in einer Sprache und man möchte es in eine anderern Sprache verwenden, will aber kein Programm wie Inkscape installieren und es gleich online ohne down-/up-load bewerkstelligen.

Wen betrifft das Problem besonders?

Wikipedianer_innen die Bilder aus anderen Sprachversionen verwenden wollen

Lösungsvorschlag

Es braucht nur eine Textersetzung.

Es wurde von

https://tools.wmflabs.org/svgtranslate/vermutlich gelöst, jedoch scheint das Speichern nicht zu funktionieren.

Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 16:16, 7. Okt. 2017 (CEST)

Diskussion

Tech/SVG Translation soll seit 05.06.2019 wieder funktionieren. Grüße --Flo Beck (Diskussion) 17:16, 7. Jun. 2019 (CEST)

Einfache und wartungsarme Möglichkeit, eingefärbte Karten einzubinden

Was ist das Problem?

In der Wikipedia werden oft Karten eingebunden, in denen Länder nach irgendwelchen Kriterien eingefärbt sind. Dazu werden meist Karten wie Datei:BlankMap-World6.svg genommen, eingefärbt, und dann neu hochgeladen. Das hat mehrere Nachteile:

• Der Umgang mit SVGs ist für technisch wenig versierte Nutzer nicht möglich bzw. sehr abschreckend → Konzeption und Umsetzung oft nicht durch denselben Nutzer → Viel Kommunikation nötig, "selber machen" nicht möglich
• Es werden Unmengen an redundanten Informationen gespeichert → Falls eine der viel genutzten Vorlagendateien geändert werden müsste (neue Grenzen, Fehler im Code usw.), müsste dies in zehn- oder hunderttausenden Dateien korrigiert werden. Das macht natürlich niemand → existierende Dateien werden immer weniger korrekt (es gibt z.B. jede Menge alte Karten, auf denen der Südsudan noch nicht existiert etc.)
• Die Karten sind sehr uneinheitlich, je nachdem, welche Ausgangsdatei genutzt wurde
• Von unerfahrenen Benutzern schlecht gewählte Ausgangskarten (unpassende Projektion o.ä.) zu korrigieren ist verhältnismäßig aufwändig

Wen betrifft das Problem besonders?

Alle Benutzer, die Karten einbinden wollen. Insbesondere solche, die mit SVGs nicht umgehen können – aber auch technik-affinen Benutzern wird die Nutzung von Karten schwerer gemacht, als es sein sollte, bzw. sie benötigen dafür unnötig viel Zeit.

Lösungsvorschlag

Es ist ein leichtes, ein mit den richtigen Klassen und IDs ausgestattetes SVG mit CSS zu stylen. Dies wird von den Leuten, die die Karten derzeit erstellen, auch meist genau so gemacht. Kartendefinition (Ländergrenzen etc.) sollten aber vom Styling (Einfärbungen etc.) getrennt werden, sodass der Endbenutzer z.B. über eine Vorlage nicht mehr machen muss als das hier:

{{Karte Europa|de=red|fr=blue|it=green}}

Auf Commons sollten nur noch die Ausgangskarten liegen, die dann über die Vorlage bequem modifiziert werden können. Parameter wie stand=YYYY, projektion=Robinson, mikronationen=Kreis etc. wären denkbar.

Leider ist es in der Wiki-Syntax derzeit nicht erlaubt, SVGs direkt einzubinden oder diese (außerhalb der Datei selbst) über CSS zu stylen. Theoretisch kann dies zwar über Umwege auch jetzt schon umgangen werden, aber diese Umwege sind sehr sehr hässlich.

Vorschlagende Person

Christallkeks (Diskussion) 23:40, 23. Okt. 2017 (CEST)

Diskussion

Inkscape SVG2PNG-Konverter statt buggy RSVG (phab:T40010)

Was ist das Problem?

Viele SVG-Grafiken können derzeit nicht richtig als PNG dargestellt werden (z.B. textPath, FlowRoot), dafür gibt bereits einige Problemsammlungen/Workarounds:

• Wikipedia:Probleme_mit_SVGs
• c:Librsvg_bugs
• c:Category:Pictures_showing_a_librsvg_bug
• c:Category:Images_with_SVG_1.2_features

Wen betrifft das Problem besonders?

Grafiker, WP:Grafikwerkstatt, alle Autoren die Vektorgrafiken einbinden wollen (dafür müssen die richtig dargestellt werden)

Lösungsvorschlag

Statt RSVG einen Inkscape-SVG2PNG-Batch Konverter zum Rendern der SVGs verwenden.

Anmerkungen

• Geschwindigkeit: benchmark

Program	Median time
Batik	57.76 s
ImageMagick	81.86 s
Inkscape	70.95 s
rsvg	41.48 s

Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 21:03, 17. Jan. 2018 (CET)

Diskussion

Ich halte libresvg für eine realistischerer und vielversprechenderere Alternative. Ist zwar noch ein sehr junges Projekt, aber bereits fast so gut wie rsvg und wenn das weiterentwickelt wird könnte es schon "bald" rsvg ablösen. -- Michi 21:59, 17. Jan. 2018 (CET)

@MichaelSchoenitzer: Der Bechmarklink funktioniert nicht mehr, hier der aktuelle: https://github.com/RazrFalcon/resvg/

Program	Render time for Oxygen Icon Theme (lower better)	Test passed: SVG test suite (higher better)
resvg	150 s	221
lib-rsvg	242 s	202
Inkscape	1610 s	257
Batik	3686 s	254

 — Johannes Kalliauer - Diskussion | Beiträge 22:42, 15. Jul. 2018 (CEST)

Auswertung zu besuchten Seiten

Was ist das Problem?

Selbst als angemeldeter Benutzer hat man keine Übersicht (weder grafisch noch in Zahlen), welche Seiten man wie oft aufgerufen hat.

Wen betrifft das Problem besonders?

Mir würde das sehr gefallen, vielleicht dem/der einen oder anderen auch. Ich finde, solch eine Auswertung wäre ein prima Nebeneffekt zur Anmeldung bei Wikipedia, was es imho bei keiner anderen Website bisher gibt. Mir würde es zeigen, wo ich mich überall herumtreibe und wie oft. Das fände ich nicht nur lustig, sondern auch hilfreich, gar lehrreich. Außerdem, Wikipedia weiß mein Surfverhalten eh, wäre es dann nicht ein Leichtes oder gar eine Pflicht, mir das auch zur Verfügung zu stellen, quasi als Wikipedia-History? Vielleicht wäre das auch ein postives Argument, um noch weitere aktive Schreiber gewinnen zu können.

Anmerkungen

Ich zitiere mal die Wikipedia-Nachteile, wenn man ein Benutzerkonto anlegt. Dort heißt es: "Außerdem werden auch alle in angemeldetem Zustand aufgerufenen Wikipediaseiten, welche du nicht bearbeitest (sogenannte Lesezugriffe), nicht-öffentlich in Server-Logfiles gespeichert und können von Mitarbeitern der Wikimedia Foundation gelistet und (in Übereinstimmung mit der Datenschutzrichtline) ausgewertet werden." Datenschutzrechtlich habe ich da nichts gegen, wenn mir, und ausschließlich mir, diese Daten auch angezeigt werden können.

Vorschlagende Person

HirnHerzHand (Diskussion) 12:50, 22. Mär. 2018 (CET)

Diskussion

Crosswiki-Beobachtungsliste

Was ist das Problem?

Ich hätte gerne eine auf meiner deutschsprachigen Beobachtungsliste auch Änderungen an Seiten auf anderen Wikis, z.B. Meta. Derzeit muss man sich die Seiten, die man beobachten will, irgendwo abspeichern und hoffen, dass man das nicht vergißt.

Wen betrifft das Problem besonders?

Alle, die sich auch für anderssprachige Projekte interessieren.

Lösungsvorschlag

Irgendeiner programmiert das halt so, sofern das technisch geht... :)

Vorschlagende Person

Informationswiedergutmachung (Diskussion) 15:43, 29. Mai 2018 (CEST)

Diskussion

@Informationswiedergutmachung: Schon ein Jahr alt... Aus anderer Ecke kam kürzlich der Wunsch nach einer Beobachtungsliste >30 Tage bzw. "umgedrehten" Beobachtungsliste, um Alt-Artikel mal wieder im Auge zu behalten. Da hab ich eine Crosswiki-Beobachtungsliste gebastelt. Nervig, da im Moment auf dem Toolserver, ist die Extra-Anmeldung. Aber vielleicht nützlich für Ideen-/Featuresammlung einer zukünftigen In-Wiki-Lösung. Filter für Wikis (im Moment immer Wikipedia, Commons, Meta, Wikisource) und die Zeiträume fehlen im Moment noch, ein kleiner Textfilter für schnelle Suche ist drin. Dasselbe gibt's auch nochmal, anmeldefrei, als Beitragsanzeige: https://tools.wmflabs.org/wikitools/contribs.php?user=Informationswiedergutmachung Gruß --DB111 (Diskussion) 18:09, 30. Apr. 2019 (CEST)

@Informationswiedergutmachung: Ewig alt, aber dennoch möchte ich an dieser Stelle auf DannyS712/Global_watchlist hinweisen. Zusammen mit jQuery("#pt-watchlist").after('<li id="pt-globalwatchlist"><a href="//meta.wikimedia.org/wiki/Special:BlankPage/GlobalWatchlist">Globale Beobachtungsliste</a></li>'); in der common.js merkt man kaum noch, dass das ein Drittanbieter-Tool ist. --Nw520 (Diskussion) 22:48, 26. Mär. 2020 (CET)

mehrzeilige Zusammenfassungszeile im Quelltexteditor

Was ist das Problem?

Die aktuelle Zusammenfassungszeile im Quelltexteditor besteht aus einer einzigen Zeile. Wenn der eingegebene Text zu lang ist, verliert man schnell die Übersicht

Wen betrifft das Problem besonders?

Dieses Problem betrifft besonders Personen, die den Quelltexteditor verwenden und gerne längere Zusammenfassungen angeben möchten.

Lösungsvorschlag

Die Lösung ist eine mehrzeilige Zeile.
(Am besten 2 bis 3 Zeilen. Falls der Text immer noch zu lang ist, soll eine Scrollbar rechts in der mehrzeiligen Zeile eingefügt werden)

Vorschlagende Person

--Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:08, 5. Jun. 2018 (CEST)

Diskussion

erstens sollte die Zusammenfaassungszeile bei unstritten Änderungen im Allgemeinen wirklich eine Zusammenfassung sein, dass es sich in einer Zeile ausgeht, wenn es länger wird, schreibe ich auch die Zusammenfassungszeile zuerst in einem Editor. Ich bevorzuge dass die Zusammenfassung nur einzeilige bleibt.  — Johannes Kalliauer - Diskussion | Beiträge 23:11, 16. Jun. 2018 (CEST)

(zur Überschrift) Ich denke, dass es eine Zeile bleiben sollte, weil es sozusagen die Überschrift ist und weil anderes wieder kleiner oder weniger angezeigt würde, wenn Ich habe mir schon dadurch geholfen, dass ich zusätzlichen Text in der Artikeldiskussion platziert habe. Man kann die Artikel-Version raussuchen, in der die (kurze) Zusammenfassung auftritt und in der Diskussion verlinken. Das ist allerdings umständlich. Ein einfachere Zuordnung von Beiträgen und Versionen zwischen Artikel <--> Diskussion wäre hilfreich.
--Dirk123456 (Diskussion) 14:28, 19. Jun. 2019 (CEST)

TeX-Darstellung optimieren

Was ist das Problem?

Umlaute und andere Sonderzeichen werden in TeX-Formeln nicht korrekt dargestellt (Beispiel: Kuppelproduktion). Dies sollte daher entsprechend angepasst werden.

Wen betrifft das Problem besonders?

Alle NutzerInnen

Vorschlagende Person

--134.61.100.245 21:27, 9. Sep. 2018 (CEST)

Diskussion

https://addons.mozilla.org/de/firefox/addon/native-mathml/ verbessert in firefox die darstellung von formeln deutlich. --Wetterwolke (Diskussion) 09:47, 29. Mai 2019 (CEST)

Optimierte Kompatibilität von Navizeilen und -boxen

Was ist das Problem?

Nicht selten trifft man auf Artikel wie William Henry Harrison, bei denen im Fußbereich Kombinationen von Navigationszeilen und -blöcken bzw. ineinander verschachtelten Leisten zu fehlerhaften Darstellungen führen (wie auch hier der Fall in Gestalt des zusätzlichen Zwischenraums nach der 3. Navizeile). Dies könnte u. U. durch eine verbesserte Vorlagenverwaltung abgestellt werden.

Wen betrifft das Problem besonders?

Alle NutzerInnen

Vorschlagende Person

--134.61.100.245 21:27, 9. Sep. 2018 (CEST)

Diskussion

Zitatvorlagen optimieren

Was ist das Problem?

Vorlagen wie z. B. Vorlage:"-en haben derzeit ein großes Problem: Sie machen unter anderem die für die typografisch korrekte Angabe von Belegen in solchen Vorlagen notwendige Verwendung des ref-Parameters unmöglich. Hier sollte dringend und systematisch Abhilfe geschaffen werden.

Wen betrifft das Problem besonders?

Alle NutzerInnen

Lösungsvorschlag

[1]

Vorschlagende Person

--134.61.100.245 21:27, 9. Sep. 2018 (CEST)

Diskussion

Gleichzeitige Vergleichs- und Vorschauansicht

Was ist das Problem?

Derzeit muss man im Editiermodus zwischen der Vorschau- und der Vergleichsansicht (Änderungen zeigen) wählen. Es sollte aber auch die Möglichkeit geben, sich wie bei Versionsgeschichten auch sowohl die Änderungen als auch darunter die Ausgabe des geänderten Textes auf einer Seite gemeinsam anzeigen zu lassen.

Wen betrifft das Problem besonders?

Alle Bearbeitenden

Vorschlagende Person

--134.61.100.245 21:27, 9. Sep. 2018 (CEST)

Diskussion

Interaktive (dynamische) Karten

Was ist das Problem?

In Wikipedia werden zahlreiche Karten verwendet, die jedoch beim Anklicken bspw. des Lokalisationspunktes in einem Ortsartikel wie München lediglich zu einer meist recht unspezifischen Commons-Datei ohne Lokalisationspunkte und sonstige Beschriftungen führen (wenn man hier auf den roten Punkt klickt, gelangt man zudem unsinnigerweise zu der Datei . Anders sieht dies schon bei Karten wie beispielsweise der im Artikel Nordrhein-Westfalen aus: Hier wird man beim Anklicken eines Kartenteils direkt zu dem jeweils einschlägigen Artikel weitergeleitet. Das könnte bzw. sollte man hier nun in ähnlicher Weise entsprechend auch für andere Kartenformen, insbesondere den in Ortsartikeln, anpassen.

Wen betrifft das Problem besonders?

Alle NutzerInnen

Lösungsvorschlag

[2]

Vorschlagende Person

--134.61.100.245 21:27, 9. Sep. 2018 (CEST)

Diskussion

Das Wissen der Menschheit: Suche nach Informationen nach Raum (Erde / Universum) und Zeit (Erdzeit / Zeit des Universums)

Was ist das Problem?

Der Wunsch ist da, das Wissen räumlich und zeitlich so strukturiert zu bekommen, das man bei Durchlaufen von Zeit und/oder Raum das Wissen über etwas dargestellt bekommt. Beispiel: Erfindungen: Bei Durchlaufen einer Zeitlinie sind die Erfindungen der Menschheit auf der Erddarstellung (der jeweiligen Zeit) als Punkte (?, die dann angeklickt werden) dargestellt.

Das Problem bei der Realisierung wird sicherlich die Auswahl des Wissens der Menschheit sein (Was ist wichtig? Was ist noch wichtig in 1000 Jahren? Wer bestimmt, was wichtig ist? Wie "sicher" sind historische Daten? …

Wen betrifft das Problem besonders?

Benutzergruppe: alle Menschen heute und in x Jahren

Lösungsvorschlag

Ich nehme an, dass momentan Beiträge in einer Datenbank hinterlegt sind. Auch jetzt schon werden Zugriffskriterien vorhanden sein. Der Zugriff müsste nun noch nach Zeit und Raumdaten erfolgt werden können.

Als ersten Schritte müsste man das Aussehen der Erde (Kontinente ändern ihr Aussehen!) darstellen und mit einer Zeitlaufleiste verbinden.

Vorschlagende Person

Klaus D K Welt (Diskussion) 14:57, 31. Jan. 2019 (CET)

Diskussion

@Klaus D K Welt: Kennst du das Projekt Histropedia? Dort kann man Zeitleisten ansehen und auch selbst erstellen. Histropedia nutzt dafür Daten aus Wikipedia und Wikidata. Eine Visualisierung auf dem Erdball gibt es dabei allerdings, soweit ich weiß, nicht. Aber vielleicht hilft dir das ja schon mal weiter. -- Viele Grüße, Johanna Strodt (WMDE) 18:11, 31. Jan. 2019 (CET)

#VE4Phabricator

Was ist das Problem?

Bei grösseren Editierprojekten, in welchen viele Beteiligte mitarbeiten, entstehen Koordinationsbedürfnisse. Als Fallbeispiel kann das #WikiAlpenforum dienen: Es bestehen aktuell mindestens drei Koordinationsseiten: auf globaler, sprachebezogenen und projektbezogener Ebene. Leicht denkbar wäre, dass es weitere Koordinationsseiten in anderen Wikimedia-Projekten gibt. Selbstverständlich gibt es "Tasks" - konkrete Aufgaben an welchen kollaborativ gearbeitet wird - welche auf unterschiedlichen Ebenen aktiv sind und unterschiedliche Bearbeitungstiefe verlangen. Weil alle diese Tasks händisch gepflegt werden, muss der Status einer Arbeit in mehreren Seiten angepasst werden. Die Probleme sind keineswegs speziell: Phabricator ist eine Umgebung, welche genau dieses Problem für die Erstellung und Pflege von Software löst und Wikimedia erfolgreich damit arbeitet: Woran wird gearbeitet? Was ist zu tun? Was ist der aktuelle Arbeitsstand? Bis wann muss was abgeschlossen sein, damit etwas anderes gemacht werden kann? Und immer so weiter. Ein Workboard von Phabricator.

Die Arbeitsmethoden von Scrum, Agile, Holokratie etc. werden dominant. Für Künstler, Wissenschafter, Sozialarbeitende war diese Vorgehensweise zwar schon immer der Normalfall: Komplexität ist Ausgangspunkt für Theorie und Praxis und hat einen ganz anderen Workflow verlangt, als dies technische, mechanische, mechanistische Projekte ausformuliert haben. Wir sprechen dann von Wasserfall-Modellen, wenn Projekte nicht iterativ abgearbeitet werden müssen. (Wenn du eine Brücke bauen willst, solltest du nicht 3x am Tag den Plan ändern. Wenn du Soziale Prozesse gestaltest, haben Störungen haben vorrang, oder du hast schon bald ein massives Problem.) Unter dem Arbeitstitel "Visual Editor für Phabricator" #ve4phabricator wird dem Fakt einer Umstellung in den Arbeitsprozessen rechnung getragen, welche ein zeit- und ortsunabhängiges, aufgaben- und lösungsorientiertes, kollaboratives (gemeinschaftliches) und kooperatives (arbeitsteiliges) arbeiten favorisiert.

Inzwischen kleben an vielen Bürofenstern Post-it-Zettelchen und Trello wäre bloss ein Beispiel für eine webbasierte Software-lösung für Agiles Arbeiten. Freilich fehlen all diesen kommerziellen Produkten, was die Basissoftware von Wikimedia so erfolgreich gemacht hat: Zum Beispiel die Versionsgeschichte.

Wen betrifft das Problem besonders?

Das #WikiAlpenforum wartet sicher nicht auf eine Lösung. Das beschriebene Problem würde zwar akzeptiert, aber es gibt genügend Programmierkenntnisse, um Problemlösungen zu entwickeln. Der "Visual Editor" für Wikipedia war - und ist! - ein wichtiges Element in der "Gewinnung von Neuen Beteiligten für Wikipedia". Die kollaborativen Schreibsysteme von Wikimedia sind so erfolgreich geworden, dass die Zeit für eine offene Software für kollaboratives Arbeiten, mit allen Vorzügen der Wiki-Software, gekommen sind. (Vergl. #Wikicon18 Vera Krick (WMDE), Verena Lindner (WMDE). Gemeinsam in Editierprojekten zu arbeiten - so zeigt die Erfahrung von WikiDienstag.ch, ist zudem ein Beitrag an eine freundliche, fehlerfreundliche, unterstützungsfreudige Arbeitskultur in einem #SmartSetting und unterstützt die Ziele von #CommunityCare.

Lösungsvorschlag

Wir entwickeln und erkunden die Anforderungen einer solchen Software bei WikiDienstag #Sprint7 und wollen bald möglichst ein MVP realisieren: Work in Progress.

Anmerkungen

Workshop-Vorschlag an der WikiCon19

Vorschlagende Person

User:Sms2sms

Diskussion

Wir freuen uns über Feedbacks: WikiDienstag - Wir koordinieren unsere Arbeit hier: #ve4phabricator.

Koordinatenangaben-Umwandler

Hallo! Vielleicht kann jemand mal einen Umwandler für aus fremdsprachigen Artikeln übernommene Koordinatenangaben basteln? --Reiner Stoppok (Diskussion) 13:20, 2. Apr. 2019 (CEST) PS: Oder habe ich da was übersehen?

Implementation von PGP und S/MIME zur Verschlüsselung von Wikimails

Was ist das Problem?

Aktuell bekomme ich ab und zu E-Mails über die Wikipedia, die sensible Informationen enthalten. E-Mails von Nutzern mit einem Freemailaccount (z.B. Web.de, GMX, Google), werden bei einigen Anbietern (mindestens Gmail, Outlook und Yahoo) indexiert, damit diese daraus u. a. Informationen für die Schaltung von personenbezogener Werbung gewinnen zu können. Primärziel ist die wirtschaftliche Nutzung der Daten, jedoch entstehen durch die angefallenen Daten auch immer Risiken (Angriff auf die IT, Weiterverkauf der Daten oder Zugriff durch Staatsorgane), denn letztendlich hat man nicht die Kontrolle über die Daten ^[3]. Selbst wenn man der Glückliche ist, dessen Mails nicht indexiert werden, werden die Mails dennoch unverschlüsselt gelagert. Die Übermittlung von Wikimails erfolgt aktuell verschlüsselt mittels "TLS", die Lagerung jedoch im Klartext. Wer Spezial:E-Mail senden aktiviert hat, weiß nicht, was in der nächsten Wikimail steht.

Wen betrifft das Problem besonders?

In erster Linie Oversighter, Techniker (hier eher WikiTech -> Responsible Disclosure), Administratoren, (SG-Mitglieder?), dann Benutzer, die aufgrund ihrer Aktivität häufig mit sensiblen Informationen konfrontiert werden.

Lösungsvorschlag

• Mitte 2007 wurde ein entsprechender Wunsch auf Phabricator geäußert, der sich allerdings nur mit PGP beschäftigt. Leider scheint das eingeschlafen zu sein: T12453
• Es ist das Projekt MediaWiki-extensions-GPGMail zu erwähnen, welches sich dem Thema angenommen hat und bereits als Erweiterungsbaustein bei Mediawiki publiziert wurde. Diese Implementation halte ich nach erstem Durchlesen für praktikabel.
  Anmerkungen

S/MIME wird leider etwas stiefmütterlich behandelt. Wie PGP hat auch S/MIME seine Vor- und Nachteile. So müssen beide Kommunikationspartner z.B. einer autorisierenden, zertifikatsausgebenden Stelle vertrauen. Auf der anderen Seite schätzen große Unternehmen eben diese Autorisierung/Validation durch den Dritten im Bunde, da sie bequemer und schneller als ein PGP Schlüsselaustausch ist. Auch bieten X.509-Zertifikate durch OCSP die Möglichkeit den Gültigkeitsstatus der selbigen jederzeit zurückzuziehen, ohne seine E-Mail Adresse an einen Keyserver schicken zu müssen.

Es gibt Menschen, die PGP-Verfechter sind, als auch solche, die auf S/MIME schwören. Um nicht eine der beiden "Ideologien" auszuschließen, sollten beide Standards in annehmbaren Zeitabstand zueinander implementiert werden.

Vorschlagende Person

Keks um 18:18, 5. Apr. 2019 (CEST)

Diskussion

Einzelnachweise

Was ist das Problem?

Wenn ich einen Abschnitt bearbeite und einen Einzelnachweis einfüge, wird er mir korrekt in der Vorschau dargestellt, gut so. Aber: Wenn im gesamten Artikel noch keine Einzelnachweise existieren, wird er als Weblink am Ende des Artikels angeklebt. Es sollte dann automatisch ein Abschitt „Einzelnachweise“ erzeugt werden. Beispiel: [4] wurde zu [5]. Ist nicht lebenswichtig, nur etwas ärgerlich. Gruss --Nightflyer (Diskussion) 00:16, 13. Apr. 2019 (CEST)

Wen betrifft das Problem besonders?

Wen betrifft das Problem besonders?

Diskussion

Hatte das Problem schon öfters. Manchmal übersehe ich es auch, denn Abschnitt "Einzelnachweise" anzuhängen und dann sieht der Artikel sch... aus. Das dürfte in leicht lösbares Problem sein. Und gerade Anfänger würden davon profitieren. --Berlinschneid (Diskussion) 17:30, 23. Jun. 2019 (CEST)

@Nightflyer, Berlinschneid: Das funktioniert aber nur, wenn es kein group="…"-Element innerhalb des EN gibt. Außerdem werden oft ENs als Fußnoten mißbraucht. Es wäre unschön, wenn ggf. mitten im Text ein Abschnitt Einzelnachweise auftaucht. -Tommes ^✉ 12:37, 17. Mai 2020 (CEST)

Hinweis auf Bedeutung der Ränge bei der Wikidata-Eingabe

Was ist das Problem?

Wer nur gelegentlich Wikidata pflegt, weiß in der Regel nichts von der Bedeutung von Rängen für Auswertungen. Es werden deshalb immer wieder verschiedenste Daten (Einwohnerzahlen, Staatsoberhäupter, Fußballtrainer etc.) aktualisiert, ohne dass der jeweils aktuelle Wert den "bevorzugten Rang" erhält oder der bisher bevorzugte Rang auf normalen Rang zurückgesetzt wird. In den meisten Auswertungen bleiben diese Änderungen damit unberücksichtigt - sie zeigen weiterhin die alten Werte.

Wen betrifft das Problem besonders?

Autoren, die nur gelegentlich Einträge in Wikidata aktualisieren.

Lösungsvorschlag

Bei der Eingabe von Werten zu einer Eigenschaft, die bereits Werte hat, sollte in der Eingabe-Maske mindestens an das Anpassen der Ränge erinnert werden. Möglicherweise könnte auch eine Checkbox "Diesen Eintrag zum neuen bevorzugten Eintrag machen" zur Vereinfachung ergänzt werden.
Ergänzung: wenn neuer "bevorzugter Rang" vergeben wird, automatisch bisherige auf "normaler Rang" zurückstufen ("bevorzugter Rang" darf es nur einmal geben) --Eduard47 (Diskussion) 17:33, 17. Jun. 2019 (CEST)

Vorschlagende Person

Tkarcher (Diskussion) 17:25, 15. Apr. 2019 (CEST)

Diskussion

Versionen zusammenfassen

Was ist das Problem?

Insbesondere Anfänger oder auch Profis, die die Anzahl der eigenen Bearbeitungen steigern wollen, produzieren häufig viele Versionen in kurzer Zeit in der Versionsgeschichte. Das macht zum einen die Versionsgeschichte unübersichtlich, zum anderen verfälscht es die Benutzerstatistiken.

Wen betrifft das Problem besonders?

Leser und Benutzer, die sich mit der Versionsgeschichte beschäftigen.

Lösungsvorschlag

Ein Tool, mit dem man bei einem Administrator beantragen kann, dass Versionen, die von einem (!) Nutzer in einen bestimmten Zeitraum (z.B. 6 Stunden) gemacht wurden, zur einer Version zusammengelegt werden. Der Administrator prüft auf Richtigkeit (z.B. dass wirklich nur ein Nutzer die Versionen verursacht hat) und hat dann die technische Möglichkeit, die Versionen zu einer Version zusammenzufassen.

Vorschlagende Person

--Berlinschneid (Diskussion) 19:57, 16. Apr. 2019 (CEST)

Diskussion

Heho, früher fand ich die Idee auch gut, zum einen, weil ich mich darüber geärgert hatte, dass ich immer wegen nur einer Kleinigkeit schon wieder einen Edit in der Versionsgeschichte hinterlassen musste und zum anderen, weil ich befürchtete, dass diese kleinen Edits den Wikipedia-Servern irgendwie schaden zufügen würden (dachte, dass zu viel Speicherplatz verbraucht werden würde). Weiß inzwischen, dass die Wiki-Server sowas nicht juckt und dass es durchaus interessanter bzw. aufschlussreicher sein kann, wenn man die ganzen kleinen Edits nacheinander und nicht zusammen begutachten kann. Falls es tatsächlich User gibt, die nur mehrere Edits an einem Artikel vornehmen um mehr Edits zu haben, dann ist es halt so. Bei erfahrenen Usern würde ich aber meist eher auf Bequemlichkeit tippen (in einem Abschnitt eines, in einem anderen Abschnitt etwas anderes ändern...das ist einfacher als den gesamten Artikel zu bearbeiten und dann nach den zu bearbeitenden Abschnitten zu suchen...und dann nochmal nach den Absätzen zu suchen usw.). Unter Umständen kann es auch passieren, dass sich ehrfahrene User mal irren und noch ein zweites mal ansetzen müssen...ist mir persönlich auch schon mehr als einmal passiert. Zu dem Tool: Ich denke mal, dass die Administratoren genug mit anderen Dingen in WP zu tun haben und das nur vergeudete Zeit ihreseits wäre. Die Versionsgeschichten sind schon gut so wie sie sind, obwohl ich mir manchmal auch wünschen würde, dass jemand meine Einstiegs- und auch späteren -Fehler wieder ausbügeln täte. Gruß.

Ich finde den Vorschlag ansich gut, aber dein Vorschlag zur Umsetzung ist meiner Meinung schlecht umsetzbar. 4+ Nacheinander folgende Beiträge einens Benutzers die innerhalb 4 Stunden gemacht werden sollten Automatisch zusammengeführt werden.--WikiBayer 👤💬 _{Kenst du scho de boarische Wikipedia?} 20:05, 31. Mai 2019 (CEST)

@WikiBayer, Berlinschneid: Das funktioniert nur, wenn die Zusammenfassungszeile jedesmal identischen Inhaltes ist. Das ist sie schon mal nicht bei abschnittsweisen Bearbeitungen. --Tommes ^✉ 12:40, 17. Mai 2020 (CEST)

Das wäre doch schonmal ein Anfang. So könnten zumindest die Versionen von unerfahrenden Benutzern zusammengefasst werden. Wahrscheinlich ist ein Automatismus besser, weil die Admins ohnehin viel zu tun haben. Im Zweifel muss man es rückgängig machen können. Das Problem des absichtlichen Missbrauch, mit dem Ziel die Beitragszahlen zu erhöhen, bleibt dann zwar weiter, aber das wird sich kaum verhindern lassen. Wer bescheißen will, wird immer einen Weg finden. --Berlinschneid (Diskussion) 23:27, 18. Mai 2020 (CEST)

Umgang mit Geoinformationen und Karten professionalisieren

WMDE möge sich bitte mit der WMF absprechen, ob es einen Plan und Verantwortlichkeiten für den Umgang mit Geodaten und Kartenanwendungen zukünftig geben kann. Ziel ist des dem Nutzer der Wikipedia auf ausgereifte und zeitgemäße Weise Geoinformationen zur Verfügung zu stellen und somit das Leseerlebnis zu verbessern. Neben automatisiert erstellten Karten geht es auch um die mit Kartographer erstellbaren Karten die dem Leser eines Artikel genau angepasste Zusatzinfos zur Verfügung stellen können. Es handelt sich also um eine notwendige Strategie für eine Vielzahl von Teilaufgaben. ==

Was ist das Problem?

Wir haben verschiedene Kartenanwendungen von freiwilligen Entwicklern im produktiven Einsatz, diese sind teilweise veraltet. An Stellen wo nur die WMF/WMDE Zugriff drauf haben (App, mobile Ansicht) gibt es am vielen Stellen leider keine geeignete Kartenanwendung. Seit der Auflösung des Mapsteam gibt es leider für die Community keinen festen Ansprechpartner für Geodaten-Themen.

So sind z.B. bei der OpenStreetMap-Einbindung die Daten von 2015 und die OpenLayers-Anwendung von 2012. Viele Anwendungen (wie der Geohack) machen einen eher altbackenen Eindruck. Kartographer z.B.könnte eine Möglichkeit sein für Artikel in der dt. Wikipedia individuell angepasste Karten bereitzustellen, aufgrund einer Kollision mit den gesichteten Versionen ist seine Aktivierung aber wohl derzeit nicht möglich. An seiner Weiterentwicklung zu mehr Benutzerfreundlichkeit (im Vergleich zu umap) sollte gearbeitet werden.... Viele Zukunftsthemen können nicht angegangen werden, da man ohne Unterstützung auf einer alten Entwicklungsstufe hängen bleibt. (Als eines der Beispiele sei erwähnt was im Bereich der Bilderkennung derzeit bei Mapillary geht.) Wo sind die automatisch generierten Karten für Verbreitungsgebiete von bestimmten Tier-und Pflanzenarten? Wo sind Karten zu historischen Entwicklungen? Wo sind Kartenanwendungen die dem Nutzer wie ein individueller Reiseführer helfen könnten? In Openstreetmap fehlen bestimmte Daten die für die Wikipedia von Interesse sein könnten. Die Probleme betreffen neben der Wikipedia vor allem Wikidata, Commons und Wikivoyage.

Alter Brockhaus: Der sechste Band ist ein Atlas.

Wen betrifft das Problem besonders?

Es gibt/gab kleinere Communities bei Wikipedia:WikiProjekt Georeferenzierung, Wikipedia:Kartenwerkstatt, Commons:Geocoding. Hauptsächlich sind es aber die Leser die unter der mangelnden Unterstützung von Geoinformationen leiden. Daher bin ich auch der Einschätzung, dass sich die Entwicklungsaktivitäten in diesem Bereich sich durch zukünftige Spendenaufkommen "refinanzieren" werden. 80% der Wikipedia-inhalte haben einen Geobezug, ca. 20% der Inhalte sind georeferenziert, man könnte also Fragen, warum geben WMF/WMDE nicht auch 20% ihrer Entwicklungsgelder für Geodatenanwendungen aus? (Es sollte schon deutlich weniger ausreichend sein.)

Lösungsvorschlag

Ich bin gerne bereit an der Ausarbeitung eines Planes mitzuhelfen. Es muss aber letztendlich die Entscheidung getroffen werden, ob der Geodatenbereich stärker und planvoller als in der Vergangenheit unterstützt werden kann. Es gibt schon jetzt vereinzelte Admins und Entwickler die bei der WMF Kleinigkeiten machen, aber es fehlt der große Blick auf die Sache aus Nutzersicht und die kartographische Professionalität.

Anmerkungen

Präsentation möglichst aller Anwendungen von Geodaten im Wikipedia-Umfeld: https://tools.wmflabs.org/wp-world/docs/Wikicon2019-WP-OSM.pdf (13MB)

Vorschlagende Person

Kolossos 19:57, 27. Apr. 2019 (CEST)

Diskussion

Die unter Wanderern beliebte App für OpenStreetMap-Karten OsmAnd zeigt auf Wunsch Wikipedia-Artikel mit Georeferenzen auf der Karte an. Auch das könnte ein Grund sein, Wikimedia mit einer kleinen Spende zu unterstürzen, sofern das weiterhin zuverlässig funktioniert. --HartmutGöthel (Diskussion) 20:09, 26. Mai 2020 (CEST)

Externe Apps sind zwar nicht die Aufgabe / das Problem der WMDE, aber einfach herunterladbare und zu nutzende Datensätze wäre hilfreich für alle externen Nutzer. --Kolossos 11:52, 7. Jun. 2020 (CEST)

Logbuchverbesserungen

Was ist das Problem?

• Beim Wechsel durch die Logbücher eines Benutzers muss der Benutzername manchmal zwischen den Feldern "Ausführender Benutzer" und "Ziel (Titel oder Benutzer:Benutzername für einen Benutzer)" wechseln. Dazu muss der Nutzername kopiert und z.B. in "Ziel" eingefügt werden. Dort muss dann wieder ein Benutzer: davorstehen.

• Umbenennungen sind für mich nur in eine Richtung nachvollziehbar. Der Zielbenutzername lässt sich nicht verfolgen, man benötigt den ursprünglichen Nutzernamen. Ich kann aus Hilfeseiten nicht erkennen, dass ich etwas falsch mache. Ich muss immer das Verschieblogbuch nutzen.

Wen betrifft das Problem besonders?

alle

Lösungsvorschlag

• Einen Button zum Tauschen der Feldinhalte der genannten Felder
• Zwei Radiobuttons mit denen man wählen kann, ob das Ziel ein "Benutzer" oder ein "Artikel" ist (bei "Artikel" kann man dann den Namensraum mittels eines Dropdownmenüs wählen)
• Umbenennungslogbuch in dem man mit beiden Nutzernamen (alt und neu), bzw. eben einem der beiden suchen kann und alle Umbenennungen dieses Kontos (auch einen dritten Nutzernamen z.B.) der Transparenz wegen angezeigt bekommt.
  Vorschlagende Person

Keks um 23:29, 2. Mai 2019 (CEST)

Diskussion

 Info: DIFF 189651908 --Keks Ping mich an! um 19:07, 18. Jun. 2019 (CEST)

Karte mit Geodaten bestimmter Bilder in einen Artikel einbinden

Was ist das Problem?

Ich habe bereits auf WP:FZW nach einem solchen Tool gefragt, aber keine Antwort bekommen. Daher gehe ich nicht davon aus, dass es dergleichen schon gibt. Ich möchte mehrere Bilder eines Ortes in einen Artikel einbinden. Das soll sehr defensiv geschen, beispielsweise in ähnlicher Position und Größe wie die Koordinatenvorlage oben rechts in Artikeln. Klickt man dort auf den entsprechenden Button (Design offen), öffnet sich eine Karte, die ca. 1/3 des Bildschirms einnimmt und die Koordinaten von Bildern (an der richtigen Position) anzeigt. Der Parameter welche Bilder eingebunden werden könnte z.B. eine Commons-Kategorie (also alle Bilder daraus) sein. In Verbindung mit der Vorlage PanoViewer wäre dies ein schönes Feature, das den Leser direkt an den Ort des Lemmas versetzt.
Wie die genaue Ausgestaltung bzgl. Mousehovering oder onclick-events ist, darüber habe ich keine konkreten Wünsche.

Wen betrifft das Problem besonders?

Leser

Lösungsvorschlag

siehe oben

Anmerkungen

Das funktioniert ja jetzt schon mit PanoViewer, aber bei Artikeln über größere Orte, auf denen es mehrere rektanguläre Projektionen gibt wird das im Artikel unübersichtlich. Eine Karte, die sich auf Zuruf öffnet und die Bilder an den entsprechenden Positionen anzeigt wäre vom Platz her in der Artikelgestaltung besser einzubinden.

Vorschlagende Person

Keks Ping mich an! um 19:05, 5. Mai 2019 (CEST)

Diskussion

Ich weiß, dass manche den Vorschlag für zu weitgehend für eine Enzyklopädie halten werden. Auch ich habe darüber nachgedacht, aber spätestens als ich beim Sichten auf die Vorlage PanoViewer gestoßen bin dachte ich mir, wenn man den Artikel schon mit einem 360° Bild illustriert, dann geht mein Vorschlag auch. Und 360°-Bilder werden populärer, das kann ich sicher sagen. Dass ich mich jetzt auf 360° Bilder konzentriert habe liegt einfach daran, dass es der Auslöser für das Überwinden der Hemmschwelle hier was einzutragen war und ich dort in den kommenden Jahren Probleme sehe. Es können natürlich auch "normale" Bilder eingebunden werden --Keks Ping mich an! um 19:05, 5. Mai 2019 (CEST)

Wird nicht produktiv verwendet, Spielerei von mir: [6]. Gruß --DB111 (Diskussion) 21:48, 5. Mai 2019 (CEST)

Guck mal oben rechts unter "Köln", die Karte mit der Lupe davor. So etwas (Das Icon vielleicht etwas größer und aussagekräftiger also doch etwas offensiver Vorlage:Smiley/Wartung/:) ), wo dann die Bilder (z.B. wie bei deiner Karte) eingeblendet werden. Wenn man drauf klickt öffnet sich dann je nach Benutzereinstellung die Commonsseite oder diese Fotovorschau, wegen der Superprotect eingeführt wurde. Wenn das Bild ein 360° Bild ist dann öffnet sich der PanoViewer. Die Fotos sind ja bei dir nicht örtlich begrenzt. Auch können Artikelfremde Bilder, oder "nicht-so-gute" Bilder enthalten sein. Dem könnte man eben durch eine Kategorie mit ausgewählten Bildern entgegenwirken. Die Karte würde nur die Bilder aus dieser Kategorie anzeigen. --Keks Ping mich an! um 22:31, 5. Mai 2019 (CEST)

Gute Idee, hab eine Kategorie-Ansicht gleich mal umgesetzt: [7]. Aber Dir geht es ja vor allem um den Einbau in Seiten, da müssen andere ihren Senf dazu geben. Gruß --DB111 (Diskussion) 13:35, 6. Mai 2019 (CEST)

 Info: DIFF 189650475 --Keks Ping mich an! um 18:35, 18. Jun. 2019 (CEST)

Ablaufdatum für Beobachtungsstatus von Seiten (beobachtete Seiten automatisch entfernen)

Was ist das Problem?

Idee beim Frankfurter Stammtisch am 09. Mai durch ich glaube @FordPrefect42:
Aktuell müllt man sich mit verschiedenen Disks, die einen gar nicht mehr interessieren die Beobachtungsliste zu. Auch Artikel, die man mal durch WP:SICHT wegen POV oder Werbetreibenden unter seine Fittiche genommen hat, sind irgendwann (auch durch Vergessen der damaligen Ereignisse) abgeklungen.

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Die Lösung ist eigentlich recht simpel: Wenn ich etwas beobachte bekomme ich eine Option (siehe →Umsetzung), um ein Ablaufdatum zu setzen. Das ganze könnte lauten: "Seite nach [Feld mit Pfeilbuttons] Tagen automatisch von der Beobachtungsliste entfernen" oder eben "Seite am [Kalender] automatisch [...]"

Sollte (z.B.) 5 Tage vor Ablauf der Frist weiter Aktivität auf der Seite herrschen, könnte der Eintrag in der Beobachtungsliste z.B. ganz links mit einem Achtungssymbol gekennzeichnet werden. Nur mal als Idee in den Raum geworfen: Was ist mit einer roten Markierung in der Beo., wenn der von mir bearbeitete (oder meinentwegen auch nur erstellte) Abschnitt zwischenzeitlich bearbeitet wurde?

Umsetzung
Meine Idee wäre folgende:

Im Lesemodus

1. Klick auf den Stern
2. Stern wird ausgefüllt und es erscheint eine Meldung in eimen Fenster oben rechts (ähnlich der Meldung, dass man auf einem anderen Wiki angemeldet sei und die Seite aktualisieren solle um die Anmeldedaten zu übernehmen) "Ablaufdatum einstellen". Das Fenster kann nach einer Zeit X verschwinden
   1. Beim Benutzen des Feldes werden die Einstellungen entsprechend übernommen
   2. Bei Nichtbenutzung (z.B. Nutzer zu langsam) sollte die Meldung z.B. beim Hovern über dem Stern (mit der Maus über dem Beo.-Stern schweben) wieder erscheinen, ähnlich der Wikilinkvorschau. Andere Lösungen von mir sind finde ich eher störend (z.B. ein eigener Punkt für die Beo.-Einstellungen, der in dem Dropdown-Menü oben rechts neben dem Stern unter "Verschieben" angezeigt wird)
3. Die Standardzeit ist in den Einstellungen festlegbar. Bitte eigene Standardeinstellung für den WP- und den BD-Namensraum, da sich zumindest bei mir hier häufig andere Beobachtungszeiten ergeben.

Im Editiermodus (VE und Quelltext)

• (Unten) bei der Checkbox "Diese Seite beobachten" die entsprechende oben genannte Meldung (ob nun Anzahl der Tage oder Kalenderdatum ist mir doch egal) ebenfalls gleich zum Auswählen verfügbar machen. Ließe sich doch gut in den grauen Hintergrund (beim QT-Editor) einarbeiten.
  Vorschlagende Person

Keks Ping mich an! um 21:07, 11. Mai 2019 (CEST)

Diskussion

Dein Vorschlag entspricht ziemlich genau dem, was hier gewählt wurde: [8] ( Community_Wishlist_Survey_2019/Watchlists/Watchlist_item_expiration) beteilige Dich am Besten mit deinen Wünschen dort. Grüße --Flo Beck (Diskussion) 11:16, 5. Jun. 2019 (CEST)

Vielen Dank für den Link! Die Umfrage dort ist ja leider schon abgeschlossen, daher lasse ich das einfach mal hier so weiterlaufen, bis es als gelöst (da durch meta umgesetzt) geschlossen werden kann. --Keks Ping mich an! um 16:15, 5. Jun. 2019 (CEST)

So die tatsächliche die Projektseite, wenn dann gearbeitet wird ist hier m:Community_Tech/Watchlist_item_expiration Grüße --Flo Beck (Diskussion) 16:36, 6. Jun. 2019 (CEST)

Danke :) --Keks Ping mich an! um 22:02, 6. Jun. 2019 (CEST)

 Info: Technische Wünsche 2019 Themenschwerpunkte/Von Inhaltsänderungen erfahren, die mich interessieren --Keks Ping mich an! um 19:11, 18. Jun. 2019 (CEST)

Neuanmeldung für Bots erschweren

Was ist das Problem?

In den letzten Wochen treten vermehrt Spambots auf, zuletzt (laut VM) Benutzer:PamTuckfield821.

Vermutlich wurde das Captcha mit den "verzitterten" Buchstaben längst geknackt und kann von Bots gelesen werden.

Wen betrifft das Problem besonders?

{{{Wen betrifft das Problem besonders?}}}

Lösungsvorschlag

Auch wenn es zeitraubend, lästig und als Datensammler bekannt ist: Bei der Neuanlage von Accounts (und ausschließlich dort!) reCAPTCHA mit dem "Bildersuchspiel" einbinden.

Vorschlagende Person

Nuhaa (Diskussion) 12:58, 20. Mai 2019 (CEST)

Diskussion

Ich bezweifle stark das die Bots die Accounts selbst anlegen, die Accounts werden mit Sicherheit von hand erstellt, die Bots Spamen nur mit den Accounts.--WikiBayer 👤💬 _{Kenst du scho de boarische Wikipedia?} 19:58, 31. Mai 2019 (CEST)

Erhöhung der Maximalen Dateigröße

Was ist das Problem?

Beim Hochladen von Dateien mit dem Uploadwizard gibt es ein Limit von 2GiB, dass interne Limit von Mediawiki liegt bei 4GiB. Videos in 4k und mit 60FPS sind, ohne starke verlustbehaftete Komprimierung, jedoch schnell deutlich größer.

Wen betrifft das Problem besonders?

Personen, die hochauflösendes und/oder langes Videomaterial hochladen wollen. Auch das Projekt c:Commons:Featured videos

Lösungsvorschlag

Erhöhung der internen Dateilimits von Mediawiki und ein Tool zum Upload großer Dateien(oder Integration in den Uploadwizard)

Anmerkungen

Das Binden des Uploads ab einer bestimmten Dateigröße an bestimmte Rechte, sollte auf Commons diskutiert werden.

Vorschlagende Person

GPSLeo (Diskussion) 15:30, 27. Mai 2019 (CEST)

Diskussion

Meiner Meinung ist 2 GB ausreichend, Wikipedia ist nicht Youtube und 4k und mit 60FPS braucht man nicht unbedingt, wenn die Videos doppelt so groß sind wird mehr Speicher gebaucht und somit entstehen auch mehr Kosten. Full HD ist meiner Meinung nach für die enzyklopädische Arbeit völlig ausrreichend.---WikiBayer 👤💬 _{Kenst du scho de boarische Wikipedia?} 19:54, 31. Mai 2019 (CEST)

Gedankenstrich einfügen bei der Autokorrektur

Was ist das Problem?

Wenn man mit dem Kasten "Link einfügen" einen Link einfügen will und hat keinen Gedankenstrich auf der Tastatur, wird meistens das "Minus" angezeigt bei der Autokorrektur. Also muss man Hunderte von Verbesserungen machen. Zb so: Django - Ein Leben für die Musik wird vorgeschlagen.

Wen betrifft das Problem besonders?

Wikipedianer_innen im Filmbereich zB.

Lösungsvorschlag

Die richtige, Originalseite, als Vorschlag in der Box "Link einfügen" als Autokorrektur und nicht die falsche.

Vorschlagende Person

 --Tromla (Diskussion) 04:33, 29. Mai 2019 (CEST)

Diskussion

Beobachtungsliste unterteilen

Was ist das Problem?

Manche Seiten beobachte ich, weil ich eine Frage habe, weil etwas unklar ist. Manche Seiten, wegen Vandalismus, manche einfach nur weil mich der Inhalt von z.B. Diskussionsseiten interessiert. Und dann gibt es auch Arbeitslisten. Momentan ist die Beobachtungsliste "flach", ich hab da also alles gemischt.

Ich wünsche mir da ein paar Gruppen um ein wenig Ordnung ins Chaos zu bringen. Ein i-Tüpfelchen wäre natürlich eine individuelle Benennung der Gruppen, aber das muss nicht unbedingt sein. Sowas wie Nummer 1-5 reicht schon.

Wen betrifft das Problem besonders?

Ich denke, das mag für ziemlich alle interessant sein.

Vorschlagende Person

Wurgl (Diskussion) 11:29, 29. Mai 2019 (CEST)

Diskussion

ich würde mir auch wünschen, dass ich Seiten z.B. nur für einen gewissen Zeitraum, z.B. 1 Monat beobachten kann, die danach automatisch wieder von der Beo gelöscht werden. das geht vielleicht in einer ähnliche richtung.--poupou review? 17:25, 21. Okt. 2019 (CEST)

Einführung eines Gelesen-Knopfes

Was ist das Problem?

Bei zahlreichen Diskussion wird die Diskussion in stillem Einvernehmen der Diskussionsteilnehmer beispielsweise durch ein „Danke!“ o.Ä. beendet. Um dem Diskussionspartner zu zeigen, dass man seine finale Antwort gelesen hat und dabei nicht entweder den Danke-Knopf zu bemühen oder mit dies mit einem „Gelesen.“ zu verdeutlichen, bräuchte es einen zusätzlichen „Gelesen-Knopf“, der ähnlich wie der Danke-Knopf funktioniert.

Wen betrifft das Problem besonders?

Eigentlich alle.

Lösungsvorschlag

Ein Duplikat des Danke-Knopfes reicht eigentlich schon aus, jedoch sollte dann als Meldung für den empfangenen Benutzer so etwas wie „XYZ hat die Nachricht von dir zur Kenntnis genommen.“ erscheinen.

Vorschlagende Person

Grüße, --Snookerado (Diskussion) 20:43, 29. Mai 2019 (CEST)

Diskussion

• Finde ich gut. --Craeosh 77 (Diskussion) 14:41, 2. Jun. 2019 (CEST)
• Gleiches Problem habe ich auch immer wieder. Es heißt doch 1 Edit kostet so viel Hamsterenergie wie 100.000 Aufrufe oder? Bisher nutze ich oft die Dankefunktion, was aber auch nicht Sinn und Zweck des Ganzen ist... --Keks Ping mich an! um 13:00, 3. Jun. 2019 (CEST)
• Für mich würde das erst dann interessant werden, wenn ich das öffentlich tun könnte. Wenn ich eine Diskussion mit einem Dank beende, stört mich daran auch, dass es für Dritte so aussieht, als hätte ich einfach nicht mehr geantwortet. Da schreibe ich dann doch lieber etwas wie „Ja, stimmt“ darunter, denn manchmal ist es für Dritte interessant zu wissen, dass eine Diskussion im Einvernehmen beendet wurde und nicht einfach im Sande verlaufen ist. --Mushushu (Diskussion) 21:14, 23. Jun. 2019 (CEST)

• Dann steht es dir doch immernoch frei ein {{erl.}} Danke --~~~~ auf die Disk zu platzieren. Hier geht es doch um eine einfache "nicht-öffentliche" Benachrichtigung, für die man keine Hamster quälen muss. --Keks Ping mich an! um 16:38, 25. Jun. 2019 (CEST)

 Info: DIFF 189652577 --Keks Ping mich an! um 19:19, 18. Jun. 2019 (CEST)

Unnötige Benachrichtigungen bei Zurücksetzungen

Was ist das Problem?

• Wenn ich Vandalismus zurücksetze und dabei nicht bemerke das zuvor ein anderer Benutzer vandaliert hat und den danach ein anderer Benutzer den zurücksetzt bekomme ich jedes mal eine Benachrichtiung, das meine Bearbeitung zurückgesetzt wurde.

Das Problem liegt daran, das ich ich jedes mal Nachschauen überprüfen muss ob die Rücksetzung von einen Vandal gemacht wurde oder ob der oben genannte Fall eingetroffen ist.

Wen betrifft das Problem besonders?

Im Pinzip betrifft das jeden Benutzer, der Vandalismusbekämpft. Besonders betrifft es aber Benutzer wie mich die Globalen Vandalismus bekämpfen, da hier es vorige Vandalismusbearbeitungen auf Grund der Fehlenden Sprachkenntnissen noch schlechter auffällt und der oben genannte Fall öfter eintritt. (Beispiel)

Lösungsvorschlag

Eine einfache Möglichkeit wäre z.B. nur den Benutzer zu benachrichtigen der die erste nach der Wiederherrgestellten Version geschrieben hat.

Vorschlagende Person

WikiBayer 👤💬 _{Kenst du scho de boarische Wikipedia?} 19:48, 31. Mai 2019 (CEST)

Diskussion

Farbliche Kennzeichnungen von Änderungen in der Diff der Versionsgeschichte

Was ist das Problem?

Häufiger als man denkt kommt es vor dass jemand nur ein Zeichen ändert, zum Beispiel jüngst auf meiner Beobachtungsliste Diff (in Summe ein Zeichen hinzugefügt). Ich kann jedenfalls nicht auf Anhieb (und was das Beispiel betrifft auch nicht nach einer Minute betrachten) erkennen ob da nur ein Leerzeichen eingefügt wurde oder Vandalismus durch Einfügen eines unpassenden Buchstabens geschah oder irgend was anderes wie Löschen/Einfügen/Einfügen etc. Vielleicht habe ich aber auch nur Schwierigkeiten Fettdruck bei einem Buchstaben zu erkennen und wäre deshalb für Farbe.

Wen betrifft das Problem besonders?

Sichter.

Lösungsvorschlag

Farbliche Anzeige von Änderungen

Vorschlagende Person

Claude J (Diskussion) 08:05, 1. Jun. 2019 (CEST)

Diskussion

Siehe auch: [9]. Bisher noch nciht gefunden, wo das sein soll... --Keks Ping mich an! um 13:02, 3. Jun. 2019 (CEST)

Lösung @Claude J: Musst ein JavaScript einbinden --Keks Ping mich an! um 20:41, 4. Jun. 2019 (CEST)

Danke. Ich weiss zwar im obigen Beispiel immer noch nicht was der genau gemacht hat (der ganze Absatz ist blau umrandet) aber neben Fettdruck ist jetzt eine blaue Kennzeichnung.--Claude J (Diskussion) 10:05, 5. Jun. 2019 (CEST)

Wahlmöglichkeit Desktop / Mobil

Derzeit wird man ungefragt mit der Mobilversion "beglückt", auch wenn man mit Desktoprechner unterwegs ist (bei mobilem Internet). Immer und immer wieder schaltet Mediawiki um. Gesucht ist eine Möglichkeit, das als angemeldeter Benutzer fest vorzugeben. --M@rcela 10:18, 17. Jun. 2019 (CEST)

Am besten pro Gerät einstellbar (z.B. per Cookie), dann könnte man es am Tablet/iPad auf Desktop stellen und am Handy weiterhin mobil arbeiten. -- Gerd Fahrenhorst (Diskussion) 12:54, 17. Jun. 2019 (CEST)

Die Lösung dieses Problems ist browserabhängig. Suche nach "User-Agent Switcher". --FriedhelmW (Diskussion) 17:31, 17. Jun. 2019 (CEST)

Suchergebnisse in sortierbarer Tabelle mit mehreren Parametern darstellen

Was ist das Problem?

Hunderte von Ergebnissen von Suchvorgängen müssen durchgesehen werden, auch wenn nur Ergebnisse mit einem bestimmten oder ungefähren Kriterium gesucht werden.

Wen betrifft das Problem besonders?

Jeden, der etwas sucht, in allen Wikis, insbesondere Wikidata und Commons

Lösungsvorschlag

sortierbarer Tabelle mit mehreren Parametern

Vorschlagende Person

Eduard47 (Diskussion) 12:11, 17. Jun. 2019 (CEST)

Diskussion

"Fachchinesisch" in Wikidata durch Umgangssprache ersetzen

Was ist das Problem?

Viele Ausdrücke und auch Hilfen in Wikdata sind unverständlich, bzw. nur von Statistikern zu verstehen

Wen betrifft das Problem besonders?

Alle Benutzer, die gerne bei Gelegenheit Daten ergänzen möchten

Lösungsvorschlag

Sprache verständlich machen, Fachausdrücke vermeiden

Vorschlagende Person

Eduard47 (Diskussion) 12:16, 17. Jun. 2019 (CEST)

Diskussion

Bin dafür. :) dee.lite (Diskussion) 19:39, 10. Nov. 2019 (CET)
@Eduard47: kannst du ein paar Beispiele nennen? Vieles liegt vielleicht an der teilweise schwierigen Übersetzung, weil es keine richtige deutsche Übersetzung gibt, die auch wirklich die Bedeutung trifft. So blieb mir z.B. nichts anders übrig als "depicts statement" mit "Aussagen zum Motiv" zu übersetzen. --GPSLeo (Diskussion) 19:52, 10. Nov. 2019 (CET)

Löschanträge

In WP ist es möglich, dass ein Löschantrag von einem nicht angemeldeten Smartphone gestellt werden kann. Die Gefahr, dass sich hinter dieser Smartphone-IP ein angemeldeter Benutzer verbirgt und auf diese Weise anonym bleiben will, ist sehr hoch (siehe Artikel "Nachteil"). Ich schlage deshalb vor, dass Löschanträge nur von angemeldeten Benutzern gestellt werden können. Nur dies wäre reversibel zu Text-Edits, die ja auch erst sichtbar werden, wenn sie durch angemeldete Benutzer gesichtet wurden. Grüße: --Wowo2008 (Diskussion) 12:24, 17. Jun. 2019 (CEST)

Ich glaube da bist du hier falsch. So etwas müsste m.E. durch ein Meinungsbild beschlossen werden. Wenn nur die mobile Version gesperrt würde, ist die Desktopversion ja auch noch verfügbar. --Keks Ping mich an! um 12:54, 17. Jun. 2019 (CEST)

Technisch gesehen kann das jeder Admin (Missbrauchsfilter). Kann aber über die API oder einen gefälschten Useragent problemlos umgangen werden, daher macht das wenig Sinn.-𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Kenst du scho de boarische Wikipedia?} 14:32, 23. Mai 2020 (CEST)

Bessere Unterstützung bei der Kategorisierung

Was ist das Problem?

Umfangreiche Kategorisierungen sind sehr zeitaufwändig, z.B. wenn man eine neue Unterkategorie anlegt und dort eine Menge von Artikeln einsortieren möchte. Bisher muss man jedem Artikel einzeln die neue Kategorie zuweisen.

Wen betrifft das Problem besonders?

Lösungsvorschlag

Es sollte möglich sein, mehrere Artikel in einer Kategorie auszuwählen und diese dann in die neue Kategorie zu kopieren/verschieben, am besten per Drag-and-Drop.

Vorschlagende Person

Sinuhe20 (Diskussion) 07:58, 18. Jun. 2019 (CEST)

Diskussion

Eigene Top-Level-Domain für alle Wikipedias

Was ist das Problem?

Die Wikipedia URLs sind ja grundsätzlich recht lang (xx.wikipedia.org/wiki/)). Es wäre sinnvoll eine Top-Level-Domain (z.B. .wp) als forwarder (nicht als shortener) für Wikipedias zu betreiben.

de.wp/Top-Level-Domain

wäre ja viel kürzer als :

de.wikipedia.org/wiki/Top-Level-Domain

Das wichtigste wäre dass man die kurze URL noch selber lesen (was mit bitly und co nicht möglich ist) und die URL, ähnlich wie ein hashtag oder einem interwiki, in den Satz einbauen kann, anstatt eine (short)-URL anzuhängen (egal ob auf twitter oder einer mail)

Der Legende nach ist unter dem #Grabhügel https://de.wp/Raknehaugen ein König zwischen zwei weißen Pferden begraben worden.

anstatt :

Der Legende nach ist unter dem #Grabhügel Raknehaugen ein König zwischen zwei weißen Pferden begraben worden. https://de.wikipedia.org/wiki/Raknehaugen

Wen betrifft das Problem besonders?

Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.

Lösungsvorschlag

Betreiben müsste diese TLD vermutlich die Wikimedia Foundation, ich denke technisch wäre das möglich.

Die ICANN will anscheinend 185.000 $ für eine sponsored TLD, aber vielleicht gibt es die TLD für ein nonprofit günstiger.

Ich bin darauf hingewiesen worden das die ICANN 2-stellige TLDs nur an Länder und die EU (.eu) vergibt, aber vielleicht bekommt man für eine sooo große "Webseite" und zentrale Ressource im Netz eine Ausnahme;)

Diese kurzen URLs sollen nicht die klassische URL (de.wikipedia.org/wiki/Top-Level-Domain) als canonical URL ersetzen, sondern nur darauf weiterleiten.

Anmerkungen

Ich habe diesen Vorschlag schon einmal auf der VereinDE-l und 2017 gestellt.

Auf mediawiki.org gibt es einen RFC für einen URL shortener, dieser würde aber "unlesbare", wenn auch kurze, shortlinks erzeugen (wi.ki/a4Kd anstatt de.wp/Raknehaugen).

Vorschlagende Person

vanGore 14:12, 21. Jun. 2019 (CEST)

Diskussion

Technische Wünsche 2017 Eigene Top-Level-Domain für alle Wikipedias

Begriffsklärungs-Check im Visual Editor

Was ist das Problem?

Das Helferlein Begriffsklärungs-Check zeigt (in den meisten Fällen unerwünschte) Links auf Begriffsklärungen in Artikeln an und ist sowohl beim Verfassen von Artikeln nützlich als auch beim Korrekturlesen. Beim Setzen von Links mit dem Visual Editor ist nicht zu erkennen, ob es ein Link auf eine BKS oder auf einen Artikel ist (es sei denn, die Seite heißt „Begriffsklärung“). Es wäre hilfreich, wenn die Hervorhebungen im Bearbeitungsmodus des Viual Editors zu sehen wären. Das ist mit dem Quelltext-Editor natürlich auch nicht anders, aber da dürfte es keine Lösung geben. Gibt es eine für den Visual Editor?

Wen betrifft das Problem besonders?

Alle, die den Visual Editor nutzen.

Anmerkungen

Möglicherweise gibt es noch andere Helferlein, die im VE vermisst werden – ich kenne nicht alle.

Vorschlagende Person

Mushushu (Diskussion) 16:55, 21. Jun. 2019 (CEST)

Diskussion

Beim Einfügen des Links wird doch als Beschreibung „Begriffsklärungsseite“ angezeigt (fast immer, das ist die Beschreibung aus Wikidata) und (immer) das BKL-Icon angezeigt. Wenn man einen Link auf eine BKS frisch eingefügt hat, dann markiert das Helferlein den Link auch wie gewöhnlich, nur bei Links, die schon vor dem Bearbeiten vorhanden waren geht das nicht (das ist im Wesentlichen identisch phab:T148325). –Schnark 09:57, 22. Jun. 2019 (CEST)

Oh. Du hast Recht. Verzeihung. Aufgefallen ist mir das als Mangel tatsächlich bei schon vorhandenen Links. Ich lese oft Artikel Korrektur, und da erweist es sich als hilfreich, im Bearbeitungsmodus des VE zu lesen, da man da gleich sieht, wie alles aussieht – aber Begriffsklärungen sieht man da eben nicht. Hab oben das von mir falsch Beschriebene gestrichen. --Mushushu (Diskussion) 11:14, 23. Jun. 2019 (CEST)

Nach einer Rückfrage an die Programmierer ist nun klar, dass die Hervorhebung im Bearbeitungsmodus auch für bereits vorhandene Links funktioniert, allerdings befinden sich teilweise nach alte Versionen ohne die Markierung im Cache. Aber prinzipiell funktioniert alles so, wie es sein sollte. Testen kannst du es am Artikel 0. –Schnark 08:53, 3. Jul. 2019 (CEST)

Benachrichtigung auf der Diskussionsseite, wenn Bilder durch einen Bot gelöscht werden

Was ist das Problem?

Manchmal wird in einem Artikel ein urheberrechtlich unbedenkliches Bild durch ein urheberrechtlich fragwürdiges Bild ersetzt. Später kommt dann ein Bot vorbei, der das urheberrechtlich fragwürdige Bild aus dem Artikel löscht und diesen ohne Bild zurücklässt. Das vorherige unbedenkliche Bild müsste manuell wieder eingefügt werden. Allerdings kommt es ab und zu vor, dass sich niemand der Sache annimmt, der Botedit in der Versionsgeschichte untergeht und dadurch halt ein Artikel ohne Bild zurückbleibt, obwohl es vorher ja ein unbedenkliches Bild gab.

Wen betrifft das Problem besonders?

Alle, die an einer bebilderten Wikipedia hängen.

Lösungsvorschlag

Auf Wikipedia:Fragen zur Wikipedia#Gelöschte Bider durch älteres Bild ersetzen wurde vorgeschlagen, dass der Bot, der das URV-Bild löscht gleichzeitig eine Nachricht auf der Disskussionsseite des Artikels hinterlässt, in der steht, dass es bereits ein urheberrechtlich unbedenkliches Bild in dem Artikel gab (vielleicht auch mit Link zu dem vorherigen Bild aus der Versionsgeschichte?). So können Benutzer auch später noch darauf aufmerksam werden und das nicht zu beanstandende Bild wieder einfügen.

Anmerkungen

Eine kleine Diskussion gab es hier-->Wikipedia:Fragen zur Wikipedia#Gelöschte Bider durch älteres Bild ersetzen

Vorschlagende Person

Eddgel (Diskussion) 23:50, 25. Jun. 2019 (CEST)

Diskussion

Besser Bezug zwischen Beiträgen, automatische Anker

Was ist das Problem?

Wenn man in einer Diskussion auf einen Beitrag antwortet oder in einem Artikel auf eine bestimmte Textpassage beziehen möchte, findet man oft keinen Anker vor, auf den man sich beziehen kann.

Wen betrifft das Problem besonders?

Jeden, aber in unterschiedlichem Maße:
Grad 1 (Am meisten betroffen sind) Nutzer, die auf Seiten mit viel Text oder zu solchen Seiten etwas schreiben wollen.
Diskussion <--> Diskussion: Nutzer, die auf einen Beitrag innerhalb eines Textes antworten oder sich auf einen solchen Beitrag (oder mehrere) beziehen. Hier ist oft nichts da, was man verlinken könnte.
Artikel <--> Diskussion: Nutzer, die im Artikel entdecken, was sie selbst verbessern können und dies in der Artikeldiskussion dokumentieren wollen.
Artikel <--> Artikel: Nutzer, die einen Artikel schreiben und weder einen kompletten Artikel verlinken noch einen passenden Abschnitt im Zielartikel verlinken wollen, weil der Begriff zu speziell ist.
Grad 2 Nutzer, die auf Seiten mit wenig Text oder zu solchen Seiten etwas schreiben wollen.
Grad 3 Lesende der Wikipedia.

Lösungsvorschlag

Möglicherweise könnten automatisch gesetzte Anker das Problem bei einige Punkten reduzieren, z. B. bei Diskussion <--> Diskussion.
So wie eine Signatur automatisch generiert wird und dann einzigartig sein könnte (wenn sie nicht doppelt generiert oder kopiert wird), könnte zu jedem Diskussionsbeitrag automatisch ein eindeutiger Anker und gegebenenfalls ein Haupt-Link erzeugt werden, falls der Betrag sich auf einen anderen Beitrag beziehen soll (der dann ja auch einen eindeutigen Anker hätte).

Anmerkungen

Die einfachen Werkzeuge zum Antworten, Einrücken usw. könnten an die Stelle, wo heute :: oder #** und ähnliches steht, noch einen automatisch generierten, möglichst einmaligen Anker setzen. Z. B. in etwa dieser Form ::{{Anker|BenutzerDatumZeitWebseite}}Mein Text, wenn man das mit Wikitext ausdrückt. Ich helf mir heute mit ::{{Anker|2019-mm-dd_Dirk123456.Kurzform-des-Themas}} oder ähnlichen Sachen, um wenigstens meine eigenen Beträge verlinken zu können. Eindeutig sind die Anker auch nicht, da man Wikitext kopieren kann (siehe Beispiel #2019-06-27_Dirk123456.Antwort.1.Mehrdeutige-Anker).

Vorschlagende Person

Dirk123456 (Diskussion) 16:03, 27. Jun. 2019 (CEST)

Diskussion

Das ist ein unmittelbarer "Diskussionsbeitrag" der vorschlagenden Person (Dirk123456).
Nebenbefund: Wenn wir jetzt anfangen, ganze Diskussionsthreads innerhalb einer Vorlage abzuhandeln, wird es nicht einfacher.
Deshalb habe ich das Angebot: <!-- Hier können andere deinen Vorschlag kommentieren. Du musst hier noch nichts ausfüllen. --> in abgewandelter Form unterhalb der Vorlage (hinter das schließende geschweifte Klammerpaar gesetzt ("}}"). Außerhalb einer Vorlage muss man vielleicht etwas weniger auf wikipedianische Zusatzinterpretationen der Zeichen 123 bis 125 (ASCII-Code, dezimale Angabe) achten als innerhalb.

Hallo, dieser Beitrag "2019-06-27_Dirk123456.Antwort.1.Mehrdeutige-Anker" bezieht sich auf die Anmerkung im obigen Beitrag "Besser(er) Bezug zwischen Beiträgen, automatische Anker". Kopien von Ankern und Links führen manchmal zu Sachen, die ursprünglichen Ansinnen nicht entsprechen.
Betrag auf dem Wunschparkplatz:
* https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz#mehrzeilige_Zusammenfassungszeile_im_Quelltexteditor
Kopie des Betrages unter Diskussion zur Hilfestellung:
* https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Umfragen/Technische_W%C3%BCnsche_2019_Themenschwerpunkte/Hilfestellung_beim_Bearbeiten_von_Artikeln#kopiert_vom_Wunschparkplatz:_mehrzeilige_Zusammenfassungszeile_im_Quelltexteditor
Gleicher Anker in zwei Dokumenten und ein Link, der ebenfalls kopiert wurde:
* :{{Anker|2019-06-19_Dirk123456.Antwort.1.mehrzeilige-Zusammenfassungszeile}} ([[Wikipedia:Technische_Wünsche/Wunschparkplatz#mehrzeilige Zusammenfassungszeile im Quelltexteditor|zur Überschrift]])
Der Schriftzug "(zur Überschrift)" verlinkt sowohl beim Original als auch bei der Kopie zur Überschrift im Original (Wunschparkplatz).
--Dirk123456 (Diskussion) 16:57, 27. Jun. 2019 (CEST)

Um mich auf ganze Beiträge zu beziehen, nutze ich Spezial:DIFF. Bei Textpassagen habe ich aber auch ab und zu das Problem. --Keks Ping mich an! um 17:13, 27. Jun. 2019 (CEST)

Eindeutig abgegrenzte Diskussionsbeiträge

Was ist das Problem?

Das Problem ist, dass Diskussionbeiträge schwierig abzugrenzen und aufzufinden sind. Bei einigen Seiten wird es schnell unübersichtlich. Komplexe Darstellungen von Sachverhalten sind deshalb auf Diskussionsseiten nur eingeschränkt möglich.

Wen betrifft das Problem besonders?

Jeden, der an Diskussionen, Abstimmungen, Umfragen u. ä. teilnehmen möchte.

Lösungsvorschlag

Einen wirklich einfach zu beschreibenden Lösungsvorschlag habe ich nicht. Nur eine Grundidee, die mit „Bildern“ veranschaulicht wird (und von der ich nicht weiß, ob sie funktioniert.) Es geht darum, die Diskussionen zu strukturieren, ohne die Freiheiten bei der Gestaltung von Beiträgen aufzugeben.

Anmerkungen

Die ausführliche Beschreibung wurde in eine Baustelle ausgelagert: Benutzer:Dirk123456/X-D.2/2019-06.Wunschparkplatz#Eindeutig_abgegrenzte_Diskussionsbeiträge_(Baustelle)

Vorschlagende Person

Dirk123456 (Diskussion) 22:54, 29. Jun. 2019 (CEST)

Diskussion

Die Diskussion sollte vielleicht am besten unterhalb dieser Vorlage stattfinden (Dirk123456).

Die elendiglich langen Diskussionswürste sind mir auch ein Dorn im Auge. Vor allem bekommt man keinen Überblick über die diversen Argumente, weil alles in Würsten und die in einer Gesamtwurst zusammengepappt sind.

Daher meine ich:

1. Facebook macht es doch recht gut vor. Wenn man auf eine Aussage antworten will, klickt man (Button für "Antworten hier"?) und automatisch wird die Antwort unter DIESE Aussage gereiht. So kann man parallel verschiedene Aussagen kommentieren ohne in einer Hauptwurst bleiben zu müssen.

2. Auch halte ich die Thumbs up / Thumbs down Funktion für brauchbar. So ein Baustein, den jeder user nach seinem Kommentar einfügen kann. Wie bei fb, Amazon und Co. erkennt man dann sofort ein ranking der wichtigsten und beliebtesten Meinungen. Somit könnte auch dem Mißbrauch von Trollen und Artikelbesetzern Einhalt geboten werden, die nur Sinnloskommentare rausschießen um die seriösen Autoren zu erschöpfen. lg, dee.lite (Diskussion) 19:48, 10. Nov. 2019 (CET)

@1: Du scheinst das hiesige System noch nicht verstanden zu haben, konsultiere diesbezüglich bitte Hilfe:Diskussionsseiten#Diskussionen_gliedern; es gibt keinen Grund, "in einer Hauptwurst bleiben zu müssen". Dass das Ganze technisch gesehen und auch in der Threadansicht übersichtlicher gestaltet werden könnte/müsste, ist bekannt und es gab/gibt schon zig Ansätze hierzu, vgl. z.B. https://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Flow_Test

@2: Wüsste nicht, wie man die Schubladen "am wichtigsten" und "am beliebtesten" gleichsetzen können soll im Zuge von Diskussionen zum Aufbau enzyklopädischer Artikel. --JD {æ} 16:05, 15. Nov. 2019 (CET)

@@1: Na du abar auch nicht. Solcherlei Kommentare gehörten meiner Ansicht nach auf die Diskussionsseite, und nicht hierher.

@@2: Die beliebtesten Aussagen (= die meisten likes) sind ja gleichzeitig die wichtigsten, weil ja am meisten Leute (aus irgendwelchen Gründen) diese Aussagen als interessant/wichtig/gut/zustimmungswürdig/... empfinden.

Anstatt immer nur gegenzumotzen, könntest du auch mal Pro-Aktiv mithelfen Ideen weiterzubringen, zu entwickeln und umzusetzen. dee.lite (Diskussion) 13:44, 16. Nov. 2019 (CET)

Konsultiere mal jemand Unbeteiligtes und frage nach, wer hier seiner Meinung nach beständig sprachlich daneben greift. --JD {æ} 16:47, 16. Nov. 2019 (CET)

Dito. dee.lite (Diskussion) 01:48, 17. Nov. 2019 (CET)

Browser-Benachrichtigungen bei Seitenänderungen

Was ist das Problem?

Von der eigenen Disk bekommt man ja schon Benachrichtigungen, aber auch nur, wenn man Wikipedia öffnet und nur von der eigenen Disk. Ich finde es nämlich umständlich, ständig die Beobachtungsliste zu öffnen.

Wen betrifft das Problem besonders?

alle Benutzergruppen

Lösungsvorschlag

Ich hab da eine Idee: Es gibt ja jetzt eigentlich auf jeder größeren Medien- und anderen Webseiten die Möglichkeit, Benachrichtigungen der Seite über Änderungen, neue Artikel, Nachrichten, etc. zu bekommen. Wäre es nicht interessant, wenn so etwas auch in der Wikipedia angeboten werden könnte? Also dass man quasi bestimmte Seiten auf eine Liste setzen kann und dann über Änderungen auf diesen im Browser benachrichtigt wird?

Anmerkungen

von Wikipedia_Diskussion:Wikimedia_Österreich#Benachrichtigungen_zu_Änderungen

Vorschlagende Person

Lg {TheTokl ► Disk 📢 • E-Mail ✉️ • ❔Hilfe❔} 16:06, 22. Aug. 2019 (CEST)

Diskussion

Live-Chat-Funktion zur Kommunikation mit neu angemeldeten Benutzern

Ich wünsche mir eine Live-Chat-Funktion mit der man Newbies in Echt-Zeit und onwiki helfen kann sich zurechtzufinden. Als Gesprächspartner könnten sich erfahrene Wikipedianer anbieten, die sich für Neulinge engagieren. Es geht um eine gezielte Unterstützung von neuen Autoren durch erfahrene Wikipedianer. Es geht nicht darum, ein allgemeines Chat-Tool zu etablieren.

Was ist das Problem?

• Newbies finden sich in der Wikipedia nicht zurecht, sind mit Regeln und Anforderungen überfordert und verwirrt.
• Unsere Hilfsangebote (Mentorenprogramm, Tutorials, Hilfeseiten) sind oft nicht niederschwellig genug sondern verlangen, dass Newbies sich schon in die Funktionsweise von Wikis grundsätzlich eingearbeitet haben, um Hilfe zu bekommen.
• Andere Hilfsangebote (Kurse, Events, Editathons) sind zu weit weg vom real life.

Wen betrifft das Problem besonders?

Newbies und Leute, die ihnen helfen wollen

Lösungsvorschlag

Für neu angemeldete Benutzer öffnet sich die Möglichkeit, mit einer anderen Person in Echtzeit per Chatfenster in Kontakt zu treten und sich helfen zu lassen,

Anmerkungen

vermutlich ist der Vorschlag nicht neu, habe aber gerade nicht gefunden, wann und weshalb das schonmal abgelehnt wurde, vielleicht irre ich mich auch.

Vorschlagende Person

poupou review? 17:18, 21. Okt. 2019 (CEST)

Diskussion

@Poupou l'quourouce: Hallo! Kennst du schon das Projekt Newcomer Homepage vom Growth-Team der Wikimedia Foundation? Es ist nicht genau deckungsgleich mit deinem Vorschlag, aber hat eine ähnliche Zielstellung, insbesondere die Box „Get Help“. Die Homepage-Funktion ist aktuell auf einigen ersten Wikis testweise in Betrieb. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 11:04, 6. Nov. 2019 (CET)

cool, nein kannte ich nicht. sehr interessant. das wäre genau das umfeld, in dem ich meine idee sehe, dass man nämlich mit "ask for help" nicht irgendwo auf eine seite schreibt, die dann irgendwann von irgendwem beantwortet wird, sondern dass man darüber in einen echtzeit-dialog einsteigen kann, der einem sofort und ganz konkret da hilft, wo man gerade steht. am besten mit einer art back-end-kombiniert, die der helfenden person zeigt, was der newbie gerade sieht. lg,--poupou review? 12:06, 6. Nov. 2019 (CET)

@Poupou l'quourouce: Wenn du dich wohl damit fühlst, auf Englisch zu schreiben, wäre es eine gute Idee, deinen Vorschlag auf der dortigen Diskussionsseite zu erörtern. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 14:11, 6. Nov. 2019 (CET)

ich hab es mal versucht, bitte ergänze gern, falls ich mich dort nicht klar ausgedrückt habe. lg,--poupou review? 18:41, 6. Nov. 2019 (CET)

@Poupou l'quourouce: Sieht sehr gut aus, vielen Dank. -- Johanna Strodt (WMDE) (Diskussion) 09:54, 7. Nov. 2019 (CET)

 Pro --MAbW (Diskussion) 11:50, 9. Jan. 2020 (CET)

Zusätzliche anti-generische ASCII-Kurz-URL

Was ist das Problem?

Die URLs von Wikipedia sind generisch (?) und teilw. irre lang und deshalb äußerst schlecht zum weitergeben. Umlaute, Sonderzeichen, Groß-/Kleinschreibung geht verloren oder wird verstümmelt, wenn man die URL in einem anderen Programm einfügt (bspw. email) oder in einem Buch veröffentlichen will. Und ich meine bewußt nicht die Funktion "Permanenter Link"!

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Ich wünsche mir zusätzlich eine Art Kurz-URL, die auf der Artikelseite unten angezeigt wird und die minimalistisch ist und vor allem ausschließlich aus ASCII-Zeichen besteht Bspw.: https://wikipedia.org/-01234567 - sogar ohne "de", damit das international funktioniert und so kurz wie möglich bleibt.

Anmerkungen

Ja, ich weiß, es gibt URL-Shortener aber ich kenne auch die damit einhergehenden Problem.

Vorschlagende Person

MAbW (Diskussion) 11:39, 9. Jan. 2020 (CET)

Diskussion

Kennst Du die Variante: https://de.wikipedia.org/w/index.php?curid=2796167? Statt https://de.wikipedia.org/wiki/%D0%83 bzw. [[Ѓ]]kannst Du damit auf die gleiche Seite verlinken. Die Zahl am Ende ist die Seitenkennnummer, die Du auf jeder Seite in den "Seiteninformationen" findest.--Mabschaaf 12:26, 9. Jan. 2020 (CET)

Das ist keine Lösung. --MAbW (Diskussion) 20:58, 9. Jan. 2020 (CET)

@MAbW: Kennst du schon den neuen Wikimedia Urlshortener: w.wiki? Der erzeugt sehr kurze URLs (https://w.wiki/4eW ist diese Seite) und umschifft die meisten der Probleme anderer URL-Shortener dadurch das er explizit nur für Wikimedia-Seiten geht und von der Wikimedia Foundation betrieben wird. (Also keine Gefahr auf Porno/Malware/Phishing/etc.-Seiten zu landen, kein Tracking durch dritte, kann in Wikipedia verwendet werden, etc.) Es gibt ein bookmarklet und ein Gadget zu einfachen Verwendung. -- Michi 13:16, 9. Jan. 2020 (CET)

Nein, den kannte ich nicht - woher auch? Wie immer bei Wikipedia: 1000 Lösungen - alle super versteckt. Sozusagen fast genau was ich will. Aber dann stellt sich doch die Frage: warum ist das nicht per default für jede Seite (unten/links) vorhanden? Warum soll ich erst einen (unbekannten) Dienst nutzen (oder gar aus fehlender Kenntnis und Verzweiflung auf irgendwelche dubiosen Anbieter zurückgreifen), wenn man das einfach automatisch einblenden könnte => kein suchen, keine Fragen, glücklich.
Fazit: der Grund-Wunsch bleibt: bitte auf jeder Artikelseite integrieren. kostet nix und ist praktisch. --MAbW (Diskussion) 20:58, 9. Jan. 2020 (CET)

Integration der Smithsonian Open Access Datenbank in Wikipedia

Was ist das Problem?

Das Smithsonian Institut stellt seinen kompletten Bestand in elektronischer Form unter der CC0- Lizenz zur Verfügung.

https://www.si.edu/OpenAccess

Dort können zu mehr als 2 Millionen Exponaten Bilder und 3D- Modelle heruntergeladen werden. Um sie in diese in die Wikipedia aufnehmen zu können, müssen diese anschließend z.B über Wiki-Commons hochgeladen werden. Erst danach kann man sie als Autor über den "Einfügen"- Link in einen Artikel einfügen.

Wen betrifft das Problem besonders?

Alle Autoren, die Bilder oder 3-D- Modelle des Bestands des Smithsonian Instituts einbinden wollen.

Lösungsvorschlag

Integration der Smithsonian Open Access Api in die Bilder und Mediensuche während der GUI- basierten Seitenerstellung (Menüpunkt: "Einfügen --> Bilder und Medien), so dass die Daten des Smithsonian Instituts ebenfalls als integrierbar erscheinen.

https://edan.si.edu/openaccess/apidocs/

Anmerkungen

Eventuell kann auf den Smithsonian Bestand zu einem späteren Zeitpunkt direkt in den Artikeln verlinkt werden.

Vorschlagende Person

--Odolom (Diskussion) 15:19, 29. Feb. 2020 (CET)

Diskussion

Sichten mit Huggle wieder ermöglichen

Was ist das Problem?

• Huggle ist ein Programm zur Vandalismusbekämpfung. Leider ermöglicht es aufgrund technischer Differenzen nicht das Sichten.
• Während man sowieso schon Änderungen auf Vandalismus überprüft, liegt es natürlich nahe, diese danach gleich sichten zu können.
• Ansonsten wird die ohnehin schon ewige Liste von ungesichteten Seiten und Versionen immer länger...

Wen betrifft das Problem besonders?

Benutzer von Huggle und solche die es werden wollen und damit zur Vandalismusbekämpfung beitragen wollen.

Lösungsvorschlag

Laut der Diskussionsseite ging das früher schon, aber aus einem unerfindlichen Grund jetzt nicht mehr...

Vorschlagende Person

Lg {TheTokl ► Disk • E-Mail • Hilfe} 16:51, 1. Apr. 2020 (CEST)

Diskussion

WMDE ist nicht an der Entwicklung von Huggle beteiligt, du musst dich für deinen Vorschlag an die Huggle Entwickler wenden.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Kenst du scho de boarische Wikipedia?} 13:38, 17. Mai 2020 (CEST)

Tabelle: fixierte Kopfzeile

Was ist das Problem?

Darstellungshilfe bei langen Tabellen (vertikal), da dort viele Einträge oft nicht mehr dem Kopfbezeicher zuzuordnen sind, insb. bei Zahlenwerten.

Häufig findet mal Listen, die außerordentlich lang und umfangreich sind. Günstig wäre sie mit CSS-style="overflow ... in einer überschaubaren, scrollbaren Tabelle anzubieten. Versuche habe ich bereits durchgeführt (siehe Scrollbare Tabellen, doch WP funkt so sehr dazwischen, dass mir bisher keine 100 % funktionierende Lösung eingefallen ist.

Als kleine Lösung bietet sich position:sticky; an, die Tabellenkopfzeilen werden beim Scrollen über die Tabelle an oberen Fensterrand fixiert.

Wen betrifft das Problem besonders?

Ausschließlich ‚fremde‘ Leser von Seiten mit längeren Listen. Vorlage:Coltab

Mitglieder/Autoren, die eine einfache Lösung brauchen, können es für sich selbst unter common.cssund/oder global.css einrichten. Da reicht

#content table tr:first-of-type th {position:-webkit-sticky; position:sticky;top:0;}

Lösungsvorschlag

Beispiel: {| class="wikitable sortable kopf" Die zentrale css-Datei (elements.css ?) um die class="kopf" mit einer Anweisung ergänzen (statt ‚kopf‘ wäre anderer Klassenbezeichner denkbar:

table.'''kopf''' tr:first-of-type th {position:-webkit-sticky; position:sticky;top:0;}</code> /* -webkit-sticky für Safari

Anmerkungen

Problem: Bei Kopf mit rowspan/colspan kann es Displayfehler geben, da nur eine Kopfzeile dargestellt wird.

Dokumentation Tabellen für Fortgeschrittene entsprechend ergänzen.

Vorschlagende Person

Klaus-Peter (ex und hopp) 20:39, 25. Apr. 2020 (CEST)

Diskussion

Benutzername im Sperrlogbuch unterdrücken/verstecken

Was ist das Problem?

Sobald man einen Benutzersperrt wird die Sperre im Logbuch einschließlich den Benutzernamen vermerkt. Das Problem dabei ist, das man bei Ungeeigneten Benutzernamen, Benutzernamen nachträglich aus den Sperrlogbuch entfernen muss. Dies ist oft mit viel Aufwand verbunden, da solche Benutzernamen meist massenhaft angelegt werden.

Wen betrifft das Problem besonders?

Administratoren/Stewards/Oversighter

Lösungsvorschlag

1. Man könnte auf der Seite "Spezial:Sperren" einfach eine Checkbox hinzufügen, mit der man optional den Benutzernamen automatisch versteckt.

2. Eine andere Möglichkeit zur Vereinfachung der unterdrückung wäre eine Spezial:Seite mit der man einen Benutzernamen automatisch aus allen Logbucheinträgen (Versionsgeschichte, Neuanmeldungslogbuch, Benutzersperrlogbuch usw.) entfernen kann, zu schaffen.

Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Kenst du scho de boarische Wikipedia?} 08:47, 21. Mai 2020 (CEST)

Diskussion

+1; stattdessen könnte an allen entsprechenden Orten die User-ID angezeigt werden, damit eine gewisse Transparenz erhalten bleibt.--Mabschaaf 08:58, 21. Mai 2020 (CEST)

Mabschaaf. Diese Benutzer haben zwar in der Regel keine oder sehr wenige Bearbeitungen, es könnte aber nach mehr Transparenz ausschauen.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Kenst du scho de boarische Wikipedia?} 10:31, 21. Mai 2020 (CEST)

Danken für’s Sichten

• Es wäre schön, wenn man sich für das Sichten bedanken könnte.

Was ist das Problem?

Sichten ist of aufwendig und verantwortungsvoll. Ein Dankeschön ist eine nette Geste. (Sicherlich könnte ich in Einzelfällen auf die Disk des Sichters schreiben. Das finde ich im Normalfall aber zu aufwendig.)

Wen betrifft das Problem besonders?

Neue Wikipedianerinnen und Wikipedianer, die noch nicht Sichten dürfen.

Lösungsvorschlag

Schaltflächen für angemeldete Mitschreibende.

Anmerkungen

siehe auch: Wikipedia:Verbesserungsvorschläge#DANKEN für’s Sichten

Vorschlagende Person

Mobil-Sockenpuppe (Diskussion) 06:38, 18. Jun. 2020 (CEST)

Diskussion

&nnbsp; als Synonym für &#8239;

Was ist das Problem?

Es scheint sehr großes Interesse zu geben, in Abkürzungen oder zwischen Zahl und Einheit das typografisch ›korrektere‹ schmale geschützte Leerzeichen zu verwenden. Siehe Verwendung der HTML-Entität oder die {{Nnbsp}}. Ersteres hat den Nachteil, dass es derartige Zahlen recht kryptisch erscheinen. Letzteres hat u. a. den Nachteil, dass dies im visuellen Editor kaputt erscheint. Auch war diese Vorlage lange Zeit fehlerhaft eingestellt und wird nun Fehlerhaft als Tausendertrenner verwendet (dort sollte zwar ein größerer Zwischenraum erscheinen, beim kopieren darf aber kein Leerzeichen gesetzt werden).

Da HTML-Entitäten sowieso von der Software in die dezimale Form umgewandelt werden, siehe z. B. der Quelltext dieser Seite in den Abkürzungen, könnte die Software auch weitere benannte Enitäten erlauben, die so eigentlich nicht existieren. Ein Nachteil daran könnte sein, dass möglicherweise nicht alle Browser diese Entität kennen. Alle großen Browser und Browserengines, nahezu alle Schriftarten und auch viele ungewöhnliche Browser wie w3m scheinen damit umgehen zu können, insofern denke ich, dass das mehr als 99 % der Leser nicht betreffen wird.

Wen betrifft das Problem besonders?

Autor*innen

Lösungsvorschlag

An der Stelle, wo &nbsp; ersetzt wird ein Synonym für &nnbsp; hinzufügen:

Hinter Zeile 210 in [10] 'nnbsp' => 8239, // MediaWiki-specific named entity to prevent magic numbers einfügen

Falls das Problem veralteter Browser noch existiert, könnte man eine kompliziertere Lösung wählen, wo anhand des User-Agent statt &#8239; einfach &#160; gesetzt wird. Beispielsweise durch einsetzen eines <span class="nnbsp"></span> und über css und js clientseitig. Ich glaube aber, die einfachste Lösung wird am ehesten akzeptiert, da man bei einem einfach &…; kein komplexes Verhalten erwarten würde.

Anmerkungen

Weitere Entitäten zu benennen wäre auch überlegenswert, beispielsweise &lsqb; und &rsqb; für [ und ]. Ein gleichlautender Vorschlag wurde 2010 abgelehnt. Die Löschung von   wurde im Übrigen deshalb abgelehnt, weil es noch keine bessere Lösung, wie z. B. ein &nnbsp; gibt und &#8239; ungeeignet ist, weil sich das niemand merken könne.[11]

Vorschlagende Person

— Sivizius (Diskussion) 07:50, 4. Jul. 2020 (CEST)

Diskussion

Ich hörte, es gebe mit Safari 13.1, einem durchaus modernen Browser Probleme. Kann das jemand bestätigen?— Sivizius (Diskussion) 10:19, 4. Jul. 2020 (CEST)

Ungewöhnliche Browser sollte man modernisieren, um aus der Inter-Nett-Steinzeit herauszukommen. Ansonsten unbedingt dafür! --Klaus-Peter (^aufund_davon) 10:39, 4. Jul. 2020 (CEST)

Wie würde es sich eigentlich mit dem visuellen Editor verhalten, wenn da ein &nnbsp; steht? Derzeit wird einfach &nnbsp; angezeigt, aber ich weiß nicht, ob das nach dieser Änderung ebenfalls bleibt.— Sivizius (Diskussion) 20:39, 7. Jul. 2020 (CEST)

Platzierung von Diskussions-Seiten-Links in der mobilen Ansicht

Was ist das Problem?

Die Platzierung von Diskussionsseiten-Links ist in der Desktop-Ansicht über die gesamte Wikipedia hinweg gleich, in der mobilen Ansicht aber seitenspezifisch unterschiedlich:

Diskussionsseiten-Links

1. Im Artikelnamensraum unter dem kompletten Artikel (bei langen Artikeln nur durch langes Scrollen erreichbar)
2. Im Benutzernamensraum klein unter dem Namen (warum nicht als Button wie im Artikelnamensraum?!)
3. Die Diskussion zur Hauptseite ist aus der mobilen Ansicht heraus nicht erreichbar.

Wen betrifft das Problem besonders?

Alle Leser, die Wikipedia in der mobilen Ansicht nutzen.

Lösungsvorschlag

Keine der drei Platzierungen finde ich richtig gelungen. Am liebsten wäre mir entweder ein Link im Seitenmenü oder ein Button im oberen Bereich der Seite. In jedem Fall sollte die Platzierung genauso einheitlich realisiert werden wie in der Desktop-Ansicht.

Vorschlagende Person

Tkarcher (Diskussion) 12:01, 2. Okt. 2017 (CEST)

Diskussion

ja. fände ich wichtig. überhaupt, dass mobile die diskussion zugänglich gemacht wird. --Sms2sms (Diskussion) 10:21, 28. Mär. 2019 (CET) Oh, ja, das Problem kenne ich. Hoffe ebenfalls auf eine baldige Lösung.— Sivizius (Diskussion) 08:12, 4. Jul. 2020 (CEST)

Diskussion sollte ein Link sein und kein Button, weil navigiert wird. Buttons stehen eher fuer Aktionen. Anstelle von

Im Benutzernamensraum ... Warum nicht als Button wie im Artikelnamensraum ?!

wuerde ich also schreiben:

Im Artikelnamensraum ... Warum nicht als Link wie im Benutzernamensraum ?!

-- Juergen 217.61.204.70 12:47, 8. Jun. 2021 (CEST)

Das lässt sich dadurch erreichen, dass die erweiterte Mobilansicht (advanced mobile contributions) zur Standardansicht gemacht wird. Würde ich sehr begrüßen.–XanonymusX (Diskussion) 13:14, 26. Okt. 2021 (CEST)

 Pro Klingt logischer. --Grizma (Diskussion) 10:31, 1. Nov. 2021 (CET)

Automatische Ersetzung bestimmter Zeichen

Was ist das Problem?

Viele Bearbeitungen in der Wikipedia gehen auf formale Sachen zurück, wie z. B. das Setzen von richtigen Anführungszeichen („ und “ anstatt " ") oder eines Halbgeviertstrichs (– anstatt -) oder des geschützten Leerzeichens bei z. B.; u. a. usw. . Wenn man die richtigen Zeichen auf der Tastatur kennt, oder die kleinen Zeichen unten am Quelltexteditor beachtet, ist das kein Problem. Aber viele machen das nicht und so fällt formale Arbeit an, die sich mittels Technik beheben lässt.

Wen betrifft das Problem besonders?

Erstmal die Neuautoren, weil viele es nicht richtig wissen, aber auch die erfahrenen Autoren, weil sie es korrigieren müssen.

Lösungsvorschlag

Automatische Ersetzung von Kombinationen, die die Wikisoftware erkennt:

• Leerzeichen + Anführungszeichen + Buchstabe ( "b) durch „b
• Buchstabe + Anführungszeichen + Leerzeichen (b" ) durch b“
• Buchstabe + Leerzeichen + Minus + Leerzeichen + Buchstabe (b - b) durch b – b
• z. B. direkt durch z.& nbsp;B. (nur ohne Leerzeichen nach dem &)
  Vorschlagende Person

Craeosh 77 (Diskussion) 14:39, 2. Jun. 2019 (CEST)

Diskussion

 Pro  — Johannes Kalliauer - Diskussion | Beiträge 12:36, 10. Jul. 2020 (CEST)

 Pro  — --Klaus-Peter (^aufund_davon) 05:39, 11. Jul. 2020 (CEST)

 Neutral Sowas wird wohl nur mit aktiviertem JavaScript funktionieren (was bei mir i.d.R. abgeschaltet ist). NB: sorry für die Darstellungsänderungen ... :) [Signatur fehlt]

 Pro — --Fuchs B (Diskussion) 20:34, 31. Okt. 2021 (CET)

Änderungsvorschlag: Grundsätzlich gute Idee. In manchen Fällen kann man aber auch explizit die ersetzten Zeichen wollen. Deshalb bin ich der Meinung, dass die automatischen Änderungen vorgeschlagen werden, und man ja oder nein klicken muss. Eine automatische ERsetzung finde ich problematisch. Wir kennen doch alle Autokorrektur-Fails. --Fan-von-mir (Diskussion) 13:32, 29. Okt. 2021 (CEST)

 Pro für optional. Zumal in der Einzelnachweis-Formatvorlage im Visual Editor die Korrektur der Zeichen nicht möglich ist, dafür muss ich erst wieder in den Quelltext wechseln, um dann auf die kleine Leiste unter dem Bearbeitungsfenster zu klicken. Auch wieder ein Arbeitsschritt mehr als nötig. --Grizma (Diskussion) 10:29, 1. Nov. 2021 (CET)

 Pro ---Bärbel Miemietz (Diskussion) 20:14, 14. Nov. 2021 (CET)

 Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)

 Pro für optional — --Wilhelm (Diskussion) 08:56, 20. Nov. 2021 (CET)

Automatische alphabetische Reihenfolge auf Begriffsklärungsseiten

Was ist das Problem?

Ich habe heute in einem Artikel den Boxverband „IBO“ verlinkt und ich kam natürlich, wie gewünscht, erst einmal auf die Begriffsklärungsseite Ibo. Wie schon des Öfteren, habe ich zunächst die Begriffsklärungsseite aufgeräumt, also alle Einträge nach dem ABC geordnet. Das habe ich bei unterschiedlichen Begriffsklärungsseiten schon oft gemacht, aber eigentlich wollte ich mich damit nicht aufhalten, dachte nur, dass es sinnlos wäre, eine falsche alphabetische Reihenfolge stehen zu lassen.

Wen betrifft das Problem besonders?

• Leser, die nach einem bestimmten Begriff suchen und dann eine verwirrende, fehlerhafte alphabetische Sortierung vorfinden
• Autoren, die nicht nur eine angetäuschte alphabetische Reihenfolge wünschen, sondern eine tatsächliche alphabetische Reihenfolge

Lösungsvorschlag

wenn jemand einen neuen Begriff einträgt, zum Beispiel bei Ibo, dann wird ihm eine Maske gezeigt mit genau zwei Feldern: erstes Feld Pflicht: der Begriff (zum Beispiel International Boxing Organization), zweites Feld keine Pflicht: die Erklärung (im Fall der International Boxing Organization ist eine Erklärung obsolet, zweites Feld wird nicht ausgefüllt)

Anmerkungen

• bessere Wirkung nach außen durch korrekte Anwendung des ABC
• Autoren-Arbeitsaufwand sinkt nach Erfüllung des Wunschs
  Vorschlagende Person

Bluemel1 🔯 08:39, 10. Jun. 2019 (CEST)

Diskussion

•  Kontra alphabetische Reihenfolge ist nicht immer sinnvoll; vielmehr sind die BKS oft nach Themen oder Chronologie zu sortieren. --ProloSozz (Diskussion) 11:41, 7. Jul. 2021 (CEST)
•  Kontra +1 --Jbergner (Diskussion) 10:51, 26. Okt. 2021 (CEST)
• Warum müsst ihr da jetzt Contra geben? Es geht doch nur um eine optional Vorlage, die nicht zwangsweise eingebaut wird, oder verstehe ich das falsch? --Fan-von-mir (Diskussion) 13:35, 29. Okt. 2021 (CEST)
•  Pro --Fuchs B (Diskussion) 20:35, 31. Okt. 2021 (CET)
•  Pro --Bärbel Miemietz (Diskussion) 20:17, 14. Nov. 2021 (CET)

Automatisches Eintragen von Artikeln bei LA, QS, etc.

Was ist das Problem?

Es kann doch nicht sein, dass man alle Artikel immer noch manuell in auf der LA-Diskseite, QS-Seite, etc. eintragen muss, wenn man die Vorlagen ({{ers:QS...}}, {{ers:Löschantrag...}}, etc. einbindet, oder? Das muss doch automatisch auch gehen.

Wen betrifft das Problem besonders?

alle Benutzer

Lösungsvorschlag

automatische Eintragung von Artikeln auf den vorgesehenen Seiten

Vorschlagende Person

Lg {TheTokl ► Disk 📢 • E-Mail ✉️ • ❔Hilfe❔} 12:26, 10. Sep. 2019 (CEST)

Diskussion

Der Vorschlag ist hier nicht umsetzbar. Jedes Projekt hat eigene Regeln und Seiten, daher muss dieser Vorschlag per Userscript umgesetzt werden und nicht per MediaWiki.-𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 22:16, 8. Nov. 2020 (CET)

Anlagen von weiterleitungen zu nicht existierenden Seiten verhindern

Was ist das Problem?

Weiterleitungen können ohne Einschränkung angelegt werden; da kann es vorkommen, dass sich jemand vertippt oder auch absichtlich Vandalismus betreibt.

Wen betrifft das Problem besonders?

Jeden, der sich vertippt, und vor allem Autoren der boarischen Wikipedia.

Lösungsvorschlag

Der Missbrauchsfilter könnte so angepasst werden das der Filter Weiterleitungen prüfen kann.

Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Kenst du scho de boarische Wikipedia?} 11:19, 19. Nov. 2019 (CET)

Diskussion

• Eine Warnung (und nicht sofortiges Speichern) kann sinnvoll sein – Verunmöglichung wäre doof! Oftmals ist es sehr wohl angebracht, eine WL auf eine noch nicht existierende Seite zu setzen – nämlich wenn parallel dazu dort etwas entstehen oder etwas dorthin verschoben werden soll. (PS: sorry für Ortho)--ProloSozz (Diskussion) 11:49, 7. Jul. 2021 (CEST)
• Kann man dies mithilfe eines Bearbeitungsfilters umsetzen? --Zabe (Diskussion) 15:55, 25. Okt. 2021 (CEST)

Massblock-Erweiterung

Was ist das Problem?

Bei Spambots und LTAs ist es oft nötig 100+ Accounts zu sperren, dies ist sehr aufwendig und dauert lange. Zwar gibt es Scripts wie m:User:Tks4Fish/massBlock.js Massensperrungen erheblich beschleunigen diese Scripts haben aber auch Grenzen und sind in der Bedienung auch nicht gerade schnell.

Wen betrifft das Problem besonders?

Administratoren/Globale Administratoren/Stewards

Lösungsvorschlag

Eine Erweiterung die es durch eine Auswahl (z. B. Checkboxen) in Logbüchern (letzte Änderungen/Neuanmeldungslogbuch) ermöglicht, diese Accounts mit vergleichsweise wenig Aufwand zu sperren.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 10:31, 26. Jul. 2020 (CEST)

Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 10:31, 26. Jul. 2020 (CEST)

Diskussion

Artikel auf Wiedervorlage setzen

Schaffung einer Möglichkeit, für Artikel eine (benutzerspezifische) Wiedervorlage einzurichten. ==

Was ist das Problem?

Derzeit gibt es keine besonders gut geeigneten Hilfsmittel, um Artikel mit sich regelmäßig (aber nicht zwingenderweise häufig) ändernden Informationen aktuell halten. Ein Beispiel sind Unternehmensartikel, in denen man in jährlichem Turnus die Umsatz- und Mitarbeiterzahlen aktualisieren möchte.

Wen betrifft das Problem besonders?

(angemeldete) Benutzer, die eine größere Anzahl Artikel längerfristig aktuell halten wollen

Lösungsvorschlag

Ähnlich dem Stern zum Hinzufügen eines Artikels zur Beobachtungsliste gibt es ein weiteres Icon. Beim Klick auf das Icon erscheint ein Popup oder eine anderweitige Eingabemöglichkeit, die es dem Benutzer erlaubt, zu spezifizieren, wann der Artikel wiedervorgelegt werden soll (bspw. "in x Tagen/Wochen/Monaten" oder "am dd.MM.yyyy").

Ähnlich der Beobachtungsliste gibt es zudem eine Wiedervorlageliste:

• Die auf WV gesetzten Artikel sind darin anhand des ausgewählten WV-Datums sortiert.
• Einträge, deren WV-Datum in der Vergangenheit liegt, die aber immer noch auf der Liste sind (d.h. nicht als erledigt markiert worden sind), werden in geeigneter Weise hervorgehoben (z.B. farblich).
• Jeder der Einträge kann einzeln als "erledigt" markiert werden (dann verschwindet er von der Liste).
• Alternativ zum "erledigen", sollte man auch "erledigen und erneut wiedervorlegen" können; in diesem Fall erscheint erneut ein Popup zur Auswahl des WV-Termins wie eingangs beschrieben.

Die WV-Funktion sollte unabhängig davon funktionieren, ob ein Artikel beobachtet wird oder nicht.

Optional: Beim erstmaligen Aufruf einer dewiki-Seite an einem Tag wird der Benutzer auf fällige WV hingewiesen (bspw. per Browser-Benachrichtigung).

Vorschlagende Person

M-hue (Diskussion) 06:28, 10. Aug. 2020 (CEST)

Diskussion

Aus ähnlichem Wunsch eines Benutzers habe ich mal eine Komplettbeobachtungsliste programmiert, um sich seine ältest-ungeänderten Artikel gelegentlich zur Brust zu nehmen, Du meinst das natürlich noch viel automatischer. --DB111 (Diskussion) 00:52, 9. Nov. 2020 (CET)

Das ist ja schön und hilfreich, aber nie gebe ich in einer externen Anwendung mein Passwort ein. Das sollte für alle 3 Listen entbehrlich sein.--Klaus-Peter (^aufund_davon) 06:40, 9. Nov. 2020 (CET)

Die Bedenken kann ich verstehen (ich versichere hiermit nochmal ausdrücklich, dass das Passwort in keiner Weise abgegriffen oder missbraucht wird), das wurde wie gesagt auch nur nach einem Stammtischgespräch für jemanden gebastelt, der konkret dieses Problem hatte. Die Beobachtungsliste ist persönlich und geheim, ohne Authentifizierung des Nutzers geht da nichts. Falls die hier vorgeschlagene Funktionalität aber ewig auf sich warten lässt, werde ich die Funktion vielleicht auch mal als Helferlein in die normale Wiki-Oberfläche integrieren, dann ohne Extra-Anmeldung. --DB111 (Diskussion) 11:33, 9. Nov. 2020 (CET)

Jetzt ohne Extra-Anmeldung... --DB111 (Diskussion) 17:00, 3. Mai 2021 (CEST)

Siehe auch Benutzer:Schnark/js/notizen mit seitengebundener Erinnerung. --FriedhelmW (Diskussion) 21:53, 8. Apr. 2021 (CEST) Siehe auch Benutzer:ErinnerMichBot. Wobei ich nichts dagegen hätte, diesen Bot durch eine bessere, integrierte Lösung zu ersetzen. --Tkarcher (Diskussion) 12:10, 26. Okt. 2021 (CEST)

 Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)

Privaten Notizblock

Was ist das Problem?

Wenn man sich etwas Notieren, muss/möchte kann man das entweder öffentlich im Benutzernamensraum machen oder man benötigt etwas Externes. Nicht alle Notizen sollen öffentlich sein, dies erfordert immer eine Externe Lösung und ist unpraktisch.

Wen betrifft das Problem besonders?

Autoren Administratoren usw.

Lösungsvorschlag

Eine Art Notizblock auf den nur der Autor/Benutzer zugriff hat.

Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 11:18, 11. Aug. 2020 (CEST)

Diskussion

So öffentlich ist der Benutzerraum nicht! Einfach mal Benutzer:WikiBayer/Schmierzettel anlegen, das kommt nur raus, wenn man es verbreitet oder gute Hacker bemüht.--Klaus-Peter (^aufund_davon) 13:49, 11. Aug. 2020 (CEST)

Oder wenn man »Benutzer:…« in die Suche eingibt, meist reichen auch schon die Vorschläge. Aber ich glaube, ein einfacher Schmierzettel, ob auf Papier oder als .txt, reicht wohl auch. Aber ich wäre dieser Idee nicht abgeneigt, vielleicht ist das gar nicht mal so schlecht, vor allem, wenn man von mehreren Rechnern editiert und nicht den eigenen Rechner zumüllen will.— Sivizius (Diskussion) 20:02, 21. Aug. 2020 (CEST)

Oder wenn man auf Spezial:Präfixindex/Benutzer:WikiBayer geht. --Zabe (Diskussion) 15:59, 25. Okt. 2021 (CEST)

Das Problem an Benutzerunterseiten ist, dass da jedes Detail in der Beitragshistorie landet. Ein Notizzettel ist da schon praktischer. Mittlerweile nutze ich eine lokale Textdatei. Der Vorteil eines Notizzettel ist aber, dass er überall, egal wo man sich einloggt, verfügbar ist. Also schon sinnvoll, wenn auch höchstpriorisiert mMn --Fan-von-mir (Diskussion) 13:44, 29. Okt. 2021 (CEST)

•  Kontra Finde, jede*r kann sich eine lokale Textdatei anlegen und auf die eigene Cloud legen, das muss WP nicht leisten. Was für Notizen sollten denn nicht BNR-öffentlich sein? Ist dann WP auch für den Datenschutz zuständig, falls der Private Notizblock gehackt wird? Gruß --Fuchs B (Diskussion) 20:40, 31. Okt. 2021 (CET)

Überschriften aus Tabellen; Links auf Abschnitte aus Tabellen setzen.

Was ist das Problem?

Beim Verwenden von Tabellen kann die Sortierfunktion ganz nützlich sein. Das Problem daran ist, dass mögliche Zwischenüberschriften nicht mehr im Inhaltsverzeichnis auftauchen und auch nicht mehr direkt auf diese verlinkt werden kann. Fügt man == ... == in der Tabelle ein, erscheinen zwar die Zeichen in der Tabelle, aber der Text wird nicht, wie üblich, als Überschrift formatiert. 217.85.16.81 07:45, 19. Aug. 2020 (CEST)

Wen betrifft das Problem besonders?

Vorschlagende Person

217.85.16.81 07:45, 19. Aug. 2020 (CEST)

Diskussion

Kommentar beim Danken sowie Undank- Funktion einführen und Kommentar beim Undank

Was ist das Problem?

Wenn ich eine Änderung sinnvoll finde bedanke, ich mich sehr gerne und manchmal möchte ich noch ein paar Wöter an den Bedankten hinzufügen. Gleichzeitig gibt es Situationen, in den ich den Änderung nicht so glücklich finde, sie aber akzeptiere (warum auch immer). Wäre es da nicht konsequent, dies mit einem Undank auszudrücken. Auch den Undank würde ich dann möglicherweise kommentieren wollen.

Wen betrifft das Problem besonders?

Auf die Idee bin ich beim Lesen des Universal Code of Conduct gekommen. Vielleicht würden dies auch zur Durchsetzung des Universal Code of Conduct betragen.

Lösungsvorschlag

Erweiterung der Danke-Funtion um eine Kommentarmöglichkeit und Schaffung einer Undank-Funktion mit Kommentarmöglichkeit.

Anmerkungen

Ganz konsequent wäre es dann, wenn Undank genauso wie Dank in der Statistik der Bearbeitungen ausgewiesen werden würde.

Vorschlagende Person

Mobil-Sockenpuppe (Diskussion) 13:39, 20. Sep. 2020 (CEST)

Diskussion

"Undank- Funktion einführen" Trolle jubeln jetzt schon. Kommentare kann man auch auf einer Diskussionsseite hinterlassen. Der Vorschlag ist zwar nicht schlecht, aber es gibt weitaus wichtigere Baustellen, die angegangen werden müssen.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 10:58, 11. Nov. 2020 (CET)

Also ich verstehe den Gedanken schon. Wenn ich mir das vorstelle, meine ich, dass sich dadurch die Stimmung innerhalb der Community im besten Fall konstant bleibt, weil es nicht genutzt wird, die Stimmung sich verschlechtert oder im schlimmsten Fall sogar kippen könnte. Ich glaube eine Verschlechterung der Stimmung innerhalb der Community kann man nicht wollen, weil es ja auch die Motivation mindert. Und wenn Beiträge garnicht angehen, gibts ja schon die Revert-Funktion. --Fan-von-mir (Diskussion) 13:50, 29. Okt. 2021 (CEST)

Ja, ich erinnere mich auch an einen problematischen Benutzer, der grundsätzlich alles anders machen wollte als vorgesehen. Der hat neue Artikelversionen auf Benutzerdiskussionsseiten verhandelt, neue Artikelversionen erst mal auf der englischen Wikipedia gespeichert etc. Probleme mit Benutzern wurden auf Artikeldiskussionsseiten oder in der Kommentarzeile verhandelt oder auf VM. Und die Danke-Funktion hat er immer dann benutzt, wenn er mit irgendwas nicht zufrieden war, wofür auch sonst? --Giftzwerg 88 (Diskussion) 12:34, 31. Okt. 2021 (CET)

•  Kontra --Fuchs B (Diskussion) 20:45, 31. Okt. 2021 (CET)
•  Kontra Es wird schon genug gehatet, dafür ein Knöpfchen einführen, das es sogar noch mehr erleichtert? Nein danke. --Grizma (Diskussion) 10:23, 1. Nov. 2021 (CET)
• Letztlich geht es darum eine konkrete Änderung zu kommentieren. Heute kopiere ich dazu den Difflink auf die Diskussionsseite und schreibe dann meine Bemerkung. Wenn das einfacher wäre wird der Undankknopf nicht gebraucht.—Hfst (Diskussion) 12:25, 1. Nov. 2021 (CET)

Gespeicherte Artikel in Mobile App auch in Browser Version sichtbar

Was ist das Problem?

Unterwegs nutze ich die Wikipedia App (Native iOS), um Artikel zu lesen und setzte Lesezeichen (Gespeicherte Artikel), wenn ich später weiterlesen oder ergänzen möchte. Es wäre super, wenn ich auf diese Liste auch in der Browser-Version zugreifen könnte, sofern ich unter gleichem Namen eingeloggt bin.

Wen betrifft das Problem besonders?

Alle Nutzer, die regelmäßig zwischen Wikipedia browserbasiert am Desktop und einer (nativen iOS/Android) mobile App hin und her wechseln.

Lösungsvorschlag

In der Browserversion gibt es die "Beobachtungsliste". An ähnlicher Position könnten auch die mobil gespeicherten Artikel aufgeführt werden, falls technisch möglich.

Vorschlagende Person

Tine2nd (Diskussion) 21:07, 9. Okt. 2020 (CEST)

Diskussion

 Pro Betrifft auch den Abschnitt weiter unten zum Thema App-Verbesserungen. Dass die Beo nicht geräteübergreifend nutzbar ist, ist lästig. --Grizma (Diskussion) 10:22, 1. Nov. 2021 (CET)

Ping-Funktion an Oversighter und Admins für dringende Versionslöschungen

Was ist das Problem?

Hallo zusammen, es kommt immer wieder vor, dass in der Wikipedia Texte eingebracht werden, die Versionsgelöscht werden müssen. Das sind z.B. schwere Beleidigungen gegen im ANR beschriebene Personen, gegen Autoren, Volksverhetzungen aber z.B. auch ANON-Verstöße. Auf häufig frequentierten Seiten werden solche Sätze meist recht schnell enfernt, aber gerade auf abgelegenen Seiten, die nur von wenigen Personen beobachtet werden, stehen solche Verstöße oft viele Stunden. Nun kann man zwar eine VM stellen, die dann oft schnell abgearbeitet wird, allerdings ist das natürlich immer auch mit einem gewissen Streisand-Effekt verbunden, weswegen diese Option gerade für besonders schwere Verstöße flach fällt. Die empfohlene Alternative, diskret eine E-Mail an die Oversighter zu schreiben, führt abhängig von er Tageszeit aufgrund der geringen Zahl dieser Posten nicht selten dazu, dass die Entfernung erst nach einigen Stunden stattfindet. Das ist eine suboptimale Situation, wofür man aber den Oversightern keinen Vorwurf machen kann. Dashalb wäre es gut, wenn es eine technische Lösung für dieses Problem gäbe, die sowohl schnell als auch effektiv ist.

Wen betrifft das Problem besonders?

Diverse, sowohl Autoren als auch Personen mit Wikipedia-Artikel

Lösungsvorschlag

Mein Lösungsvorschlag wäre deshalb, die Pingfunktion so zu erweitern, dass man mit dieser diskret Oversighter und ggf. Admins auf Verstöße aufmerksam machen kann. Ich stelle mir vor, dass in der Versionsgeschichte neben der Danke-Funktion auch ein Versionslöschungs-Funktion implementiert wird. Löst diese ein Autor aus, dann erhalten alle Oversighter einen Ping, dass eine Versionslöschung beantragt wurde (hier sollte am besten noch ein Kommentar übermittelt werden können), sodass diese sofort zur Tat schreiten und bei Bedarf die Version verstecken können. Alternativ könnte der Ping zusätzlich auch an Admins gehen, um die Geschwindigkeit abzuarbeiten (evtl. auch mit Wählfunktion Nur Oversighter bzw. Oversighter plus Admins).

Optimal wäre eine Funktion, bei der das System automatisch erkennt, welche Admins aktiv sind, und nur diesen dann einen Ping zukommen lässt. Das könnte z.B. so funktionieren, dass nach Auslösen des Alarms durch einen Autoren nur die Admins einen Hinweis bekommen, die darauf editiert haben. Wenn also um 12:00 ein Alarm ausgelöst wird und um 12:01 ein Admin einen Edit tätigt, bekommt er mit diesem Edit einen Ping "Versionslöschung angefragt". Ein Admin, der hingegen nicht editiert, bekommt auch nichts angezeigt. So könnte der Kreis der Empfänger begrenzt werden, ohne an Effektivität und Bearbeitungsgeschwindigkeit zu verlieren. Natürlich müssten abarbeitende Admins diesen Ping dann auch abschalten können, entweder durch die Versionslöschung oder eben, falls nicht angebracht, durch aktives Abschalten. Um etwaigen Missbrauch der Meldefunktion durch IPs oder Vandalen zu verhindern, könnte man die Nutzung der Funktion nur auf (aktive/passive) Sichter beschränken.

Anmerkungen

Steht alles bereits oben

Vorschlagende Person

Andol (Diskussion) 21:09, 12. Okt. 2020 (CEST)

Diskussion

Hat enormes Missbrauchspotential und es gibt bereits Möglichkeiten Admins zu informieren ohne extrem viel Aufmerksamkeit auf sich zu ziehen--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 13:29, 8. Nov. 2020 (CET)

Leider hapert es auch an der mitunter mehr als lässigen Aufmerksamkeit der Admins, z.B. in WP:AA. Da erlebte ich schon Anfragen, die ohne jegliche Admin-Reaktion archiviert wurden. Das ist fast so langweilig und witzlos wie hier. --Klaus-Peter (^aufund_davon) 11:39, 12. Dez. 2020 (CET)

Oversighter kann man potienziell in [#wikipedia-de-os] ^Webchat anpingen. --Zabe (Diskussion) 16:04, 25. Okt. 2021 (CEST)

Beobachtungsliste, Trennung Artikel / Diskussion

Was ist das Problem?

Wenn man einen Artikel beobachten will, hat man immer die Diskussionsseite mit auf der Beobachtungsliste. Manchmal möchte man aber nur die Änderungen am Artikel verfolgen und keine ausufernenden Diskussionen, die manchmal zeitgleich dazu stattfinden. Andererseits gibt es vielleicht auch Seiten, auf denen man lieber nur die Diskussion verfolgt, aber von den Artikeländerungen nichts mitbekommen will.

Wen betrifft das Problem besonders?

Jeden, der auf seine Beobachtungsliste schaut.

Anmerkungen

Verfeinern könnte man die Sache noch, wenn sich nur einzelne Artikel- oder Diskussionsabschnitte auf die Beobachtungsliste setzen lassen. Wird aber vermutlich schwierig, weil sich die Überschriften der Abschnitte jederzeit ändern können.

Vorschlagende Person

Sinuhe20 (Diskussion) 12:30, 5. Nov. 2020 (CET)

Diskussion

• Sehr gut!!! Ich stehe voll dahinter! Ich habe zwar keine Ahnung, wie und wo es technisch realisierbar ist, aber könnte mir vorstellen, dass man in der Beobachtungsliste statt [[Artikel:Diskussion]] [[Artikel:Diskussion#Abschnitt]] speichert/verfolgt. --Klaus-Peter (^aufund_davon) 06:08, 6. Nov. 2020 (CET)

• Still ruht der See und man sollte den Parkplatz in Abstellplatz umbenennen. Zeit kann man besser verplempern! --Klaus-Peter (^aufund_davon) 11:48, 12. Dez. 2020 (CET)

• Ich finde den Vorschlag von Sinuhe20 gut. --Fan-von-mir (Diskussion) 13:53, 29. Okt. 2021 (CEST)
•  Neutral --Fuchs B (Diskussion) 20:47, 31. Okt. 2021 (CET)

Missbrauchsfilter besser Filtern

Was ist das Problem?

Das Missbrauchsfilterlogbuch bietet einen guten Überblick über Vandalen/Spambots. Es gibt immer eine Vielzahl von Einträgen, die aber nicht immer aktuell sind, dies muss man aber immer kontrollieren.

Wen betrifft das Problem besonders?

Administratoren/Globale Administratoren/Stewards/andere Benutzer die mit dem Logbuch arbeiten.

Lösungsvorschlag

Die Filtermöglichkeiten sollten ausgebaut werden. Zum Beispiel Einträge von gesperrten und global gesperrten Benutzer ausblenden.

Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte ︱ Kenst du scho de boarische Wikipedia?} 13:26, 8. Nov. 2020 (CET)

Diskussion

geprüfte Datenübernahme aus Wikidata

Was ist das Problem?

Daten, welche in Wikidata gepflegt werden, und durch Einbindung / Verknüpfung in der deutschen Wikipedia erscheinen können, sollten vor der automatischen „Datenübernahme“ im Artikel überprüft werden.
In der de.wikipedia wird mit der Einbindung von Wikidata-Daten sehr unterschiedlich verfahren. In der Vorlage:Infobox Software können Daten aus der Wikidata übernommen werden, in anderen Vorlagen, z.B. in der Vorlage:Infobox Unternehmen ist eine Datenverknüpfung nicht gewünscht. Die ablehnende Haltung hinsichtlich der Einbindung der Wikidata wird damit begründet, dass die automatisch „übernommenen“ / angezeigten Daten im Artikel keiner Sichtung unterliegen und somit die Qualität der Artikel gemindert werden kann.

Wen betrifft das Problem besonders?

Auch wenn Wikidata eine andere Plattform ist, bietet sie doch Chancen für die Gesamtstuktur wikipedia.org und damit auch Chancen für die de.wikipedia.

Lösungsvorschlag

Um von der zentralen Datenhaltung der Wikidata profitieren zu können und gleichzeitig den hohen Qualitätsanforderungen der de.wikipedia gerecht werden zu können, sollen Artikel, in denen Wikidata-Daten eingebunden sind, den Status „ungesichtet“ erhalten, sofern Daten in der Wikidata aktualisiert und somit im Artikel angezeigt werden.

Vorschlagende Person

WikiFreibeuter ^Kontakt 11:07, 11. Dez. 2020 (CET)

Diskussion

Der Ansatz ist beachtenswert. Wikidata ist eine tolle Idee, aber ein recht stumpfes Schwert.
Primär sehe ich das Problem bei der teilweise mangelhaften Pflege von Wikidata. Die Idee ist ja generell zu begrüßen, aber oft erweckt es den Eindruck, dass Wikidata zwangsläufig mitgeschleppt wird.

Alle Autoren sollten generell und international animiert werden, diese Daten vorrangig zu pflegen, damit der globale Nutzen gewährleistet wird. Wenn man sich auf Wikidata verlassen kann, sollte eine Nachprüfung (Status „ungesichtet“ ) obsolet sein. Mein Ergänzungs- oder Alternativvorschlag:

• Entwicklung einer bequeme (und damit quasi einladenden) Editieroberfläche für Wikidata (mehrsprachig) bei der alle gemeinsam relevanten Daten erfasst und gepflegt werden.
  • Der derzeitige Aufbau von Wikidata ist nur versierten Autoren zugänglich. die die Property-Nummern im Kopf haben.
• Deutlicher Hinweis auf ALLEN Bearbeitungsseiten, Wikidata zu pflegen (Ergänzung, Aktualisierung)
  • Ggf. Wikidata durch Quellangaben zu ergänzen, die evtl. auch in den Artikel als Verweis übernommen werden.
• Entwicklung einer ‚Universalvorlage‘, mit der locker und bequem Wikidata abgefragt und eingebunden werden kann.
  • Auch hier sollte Eingabe via Klartext in Property-Nummern umgesetzt werden.

Als Denkansatz sehe ich die individuell resp. gestaltbaren Möglichkeiten von JOSM mit entsprechenden Vorlagen/Plugins an. Denkbar wäre auch etwas Generierbares auf der Basis von TemplateData/Generator. Doch das ist noch ein weiter Weg. --Klaus-Peter (^aufund_davon) 11:33, 12. Dez. 2020 (CET)

Dem ersten Punkt kann ich irgendwie nicht zustimmen, die Oberfläche von Wikidata ist schon sehr benutzerfreundlich und zudem bereits mehrsprachig. Wenn man eine Aussage hinzufügen will, werden einem meist passende (bzw. fehlende) Eigenschaften angezeigt, und man braucht nicht „die Nummer im Kopf haben“, sondern bekommt den Namen und die Beschreibung angezeigt.--Sinuhe20 (Diskussion) 12:38, 12. Dez. 2020 (CET)

Ist jetzt nicht das Thema, aber erst mal muss man wissen, dass Zusatzangaben via „Aussage hinzufügen“ eingetragen werden. Das findet man ganz ‚dezent‘ irgendwo weit unten, aber nicht mal ganz unten. So, will ich den Landkreis eintragen (P131) sollte man nicht nach Landkreis suchen, sondern „liegt in der Verwaltungseinheit“. Klar, das ist Allgemeinwissen, aber ich bin ein WP-ungebildeter Fachidiot, also bleibt mein Wissen außen vor. Aber wie gesagt, andere Thematik! --Klaus-Peter (^aufund_davon) 16:20, 12. Dez. 2020 (CET)

Vielen Dank für die positive Rückmeldung. Ich erkenne ebenfalls erhebliches Entwicklungspotenzial in der Wikidata. Mein Wunsch hat allerdings nichts mit der Hebung dieser Potenzialle zu tun, sondern bezieht sich rein auf die Datenanzeige/Datenübernahme aus der Wikidata zur Wikipedia. Die korrekte Verknüpfung von Wikidata-Daten in die Wikipedia kann durch technisch solide Vorlagen und deren Dokumentation unterstützt werden. --WikiFreibeuter ^Kontakt 14:17, 14. Dez. 2020 (CET)

Interessant: Angenommen Wikidata würde für die Unternehmens-Infobox verwendet werden und irgendjemand läd einen großen Datensatz mit beispielsweise Umsatzdaten der an Börse XY gehandelten Unternehmen bei Wikidata hoch in der Annahme, dass das so passt und setzt bei uns automatisiert einen ganzen Stapel Unternehmensartikel auf "ungesichtet". Wer will das überprüfen und ggf. nacharbeiten? Wir haben schon nicht genug Mitarbeiter, die Artikel in diesem Bereich rudimentär qualitätssichern, geschweige denn Lust verspüren sich in das, mit Verlaub, nicht gerade selbsterklärende System Wikidata einzuarbeiten. Kurz: "Edits woanders ändern bei uns den Sichtungsstatus" halte ich für kein sinnvolles Konzept. --Millbart talk 15:04, 14. Dez. 2020 (CET)

Ich erkenne hier kein Gegenargument. Wenn jemand in der WP einen „großen Datensatz“ hochlädt, hätten wir doch genau das gleiche Szenario... Daten aus der Wikidata können selbstverständlich die Qualität der de-WP mindern, das genaue Gegenteil kann aber auch der Fall sein. --WikiFreibeuter ^Kontakt 15:14, 14. Dez. 2020 (CET)

Der Ansatz mit Wikidata war sicherlich gut. Es sollte und müsste ein international relevantes Gerippe sein, um dass sich die verschiedensprachigen Artikel ranken. Dort stehende Daten müssten quasi amtlich sein und bei Aktualisierung sofort in alle Versionen der Lemmas übernommen werden. Das dann jeweils dort noch mal zu überprüfen, wäre unproduktiv. Blasse Theorie, denn Wikidata ist scheinbar weniger kontrolliert, als jeder Bla-Bla-Text in de:WP. Da stimme ich @Millbart: zu, Wikidata ist nicht sehr einladend gestaltet, um sich damit zu vergnügen. Nun noch mal übernommene Daten in der Sprachversion zu sichten, wäre doppelt-gemoppelt. --Klaus-Peter (^aufund_davon) 15:23, 14. Dez. 2020 (CET)

Solange die zu jener damaligen Zeit eingetragenen WD-Daten nicht gleichzeitig jeweils in den alten Versionen einer Historie zu finden sind, sondern nur die aktuellen, hat WD in Wikipedia nichts zu suchen. --Jbergner (Diskussion) 18:58, 25. Okt. 2021 (CEST)

Siehe dazu auch

• Wikipedia:Meinungsbilder/Lokale Seiten-Kurzbeschreibungen
• d:User:MisterSynergy/patrol
• Wikipedia:Umfragen/Normdaten aus Wikidata
• Kategorie:Vorlage:verwendet Daten aus Wikidata
• Kategorie:Wikipedia:Seite verwendet Daten von Wikidata
• Kategorie:Wikipedia:Wikidata-Beobachtung
• Kategorie:Wikipedia:Wikidata

--M2k~dewiki (Diskussion) 19:51, 25. Okt. 2021 (CEST)

Ich finde es bei weitem einfacher, die vielleicht nicht perfekten aber unterm Strich ziemlich klaren Regeln von Wikidata zu erlernen als die teils ungeschriebenen, von Auslegung abhängigen und keineswegs leicht auffindbaren Regeln für Wikipedia. Die Nutzung von Wikidata Infos bei Wikipedia wäre eine riesengroßer Gewinn. --Bärbel Miemietz (Diskussion) 20:44, 14. Nov. 2021 (CET)

Weblinks automatisch archivieren

Was ist das Problem?

Weblinks kommen und gehen. Ein Phänomen, das unter den Begriffen tote Links, Totlinks, Broken Links und Linksterben zusammengefasst wird. Ursachen dafür gibt es viele: So kann eine Domain nicht mehr existieren, neu vergeben worden sein oder der Webserver nicht mehr erreichbar sein. Darüber hinaus entstehen oft tote Links, wenn der Inhalt einer Website neu organisiert oder das Content Management System gewechselt wird, wie das bei Tageszeitungen und anderen Medien immer wieder passiert.

Wen betrifft das Problem besonders?

Das Problem betrifft alle Wikipedianer, die Weblinks in Artikeln verwenden oder als Einzelnachweise nutzen. Die vielen von Bots im Artikelnamensraum gefundenen und auf den dazugehörigen Diskussionsseiten gemeldeten toten Links sprechen da eine deutliche Sprache. Trotzdem dürften sie nur einen Bruchteil der toten Links erfassen. Bisher ist es so, dass Bots, so vorhanden, auf den Diskussionsseiten auf archivierte Versionen z. B. aus dem Internet Archive hinweisen.

Lösungsvorschlag

Weblinks, die als Einzelnachweise genutzt werden, sollten künftig automatisch im Internet Archive gespeichert werden. Bisher ist es so, dass jeder, der einen Link archivieren möchte, dies händisch veranlassen kann. In der en-Wikipedia gibt es dazu eine Anleitung. Dieser Prozess müsste auch automatisiert zu erledigen sein.

Vorschlagende Person

Matthias Süßen ^?! 11:12, 26. Jan. 2021 (CET)

Diskussion

• InternetArchiveBot siehe auch http://blog.archive.org/2018/10/01/more-than-9-million-broken-links-on-wikipedia-are-now-rescued/

@Matthias Süßen:, dieser Wunsch kam 2017 in die Top10 der Wünsche, wir haben daher vorletztes Jahr mit dem Team des Internet-Archivs geredet. Diese haben uns versichert, dass sie schon seit einiger Zeit die Recent Changes der Wikipedias nach neu eingetragenen URLs scannen und diese dann automatisch archivieren. Ausgenommen sind nur Webseite deren Betreiber das Archivieren untersagt haben. Insofern dürfte dieser Wunsch unseres Wissens nach bereits gelöst sein. -- Michael Schönitzer (WMDE) (Diskussion) 16:02, 1. Feb. 2021 (CET)

@Michael Schönitzer (WMDE): Vielen Dank für die schnelle Antwort. Das war mir bis dato nicht aufgefallen. Ich werde das jetzt mal beobachten. Vielen Dank aber schonmal für Euer Engagement (nicht nur) in Zusammenarbeit mit dem Internet-Archiv. Gruß --Matthias Süßen ^?! 18:01, 1. Feb. 2021 (CET)

Das heißt, InternetArchive archiviert seit 2019 (fast) alle Weblinks in der WP? - Das wäre sehr begrüßenswert. Es ist wahrscheinlich nicht so zuverlässig, dass die seit 2019 gesetzten, archivierten Links nicht mehr händisch überprüft werden müssen,oder? Das ist nämlich sehr aufwändig und zeitraubend. Ich arbeite gerade die elend lange Liste an Defekte-Weblinks-Artikeln dieses WikiProjekts ab und leider sind erstaunlich viele, ca. 30 % aller defekten Weblinks, nicht archiviert. Ca. 20 % der defekten Weblinks wurden außerdem vom Bot nicht als defekt erkannt.

Finde dieses Thema jedenfalls sehr wichtig, denn zum Teil sind jetzt schon wieder in Artikeln, die ich im Januar 2021 überarbeitet habe, schon wieder Links kaputt. So schnell kann man gar nicht hinterherprüfen. Gruß --Fuchs B (Diskussion) 21:00, 31. Okt. 2021 (CET)

Hallo Fuchs B, das Internet Archive archiviert schon seit 2013 so gut es eben geht alle Weblinks, die in die Wikipedia eingefügt werden. Auch wenn eine Archivversion nicht sofort öffentlich verfügbar ist, liegt sie meistens schon wenige Sekunden nach Speichern der Änderung im Internet Archive ab. Eine Ausnahme scheint es für in den BNR eingefügte Links zu geben, das versuche ich gerade, in Erfahrung zu bringen. Ich schaue mir gerne mal eure Defekte-Weblink-Liste an, um herauszufinden, warum die Archivierungsquote bei euch so niedrig zu sein scheint.

Eigentlich soll der InternetArchiveBot die defekten Links erkennen und passende Archivlinks einfügen, allerdings hat dieser Bot seit Jahren technische Probleme und die teilweise vom Internet Archive dafür bezahlten Entwickler kommen nur langsam voran. (Ich würde sagen, es ist ein typischer Fall eines Tools, das von einem Ehrenamtlichen entwickelt und ihm dann zwischenzeitlich über den Kopf gewachsen ist, als es auf einmal weltweit in vielen Sprachversionen eingesetzt werden sollte.) Sobald der Bot wieder zuverlässig arbeitet, wird er seinen Betrieb wieder aufnehmen.--Cirdan ± 12:40, 1. Nov. 2021 (CET)

Geänderte eigenen Beiträge suchen

Was ist das Problem?

Ich möchte eine Liste von Artikeln (nicht Versionen im Sinne von einzelnen Bearbeitungen), in denen ich mitgewirkt habe, aber die aktuellste Version nicht von mir ist. Am besten wäre dann ein Link mit dem diff von meiner letzten Bearbeitung an dem Artikel zum aktuellen Stand.

Wen betrifft das Problem besonders?

Alle Leute, die auf Wikipedia schreiben und sich über Feedback freuen. Wie wurde „mein“ Artikel (i.e. ein Artikel, in dem ich mitgewirkt habe) weiterentwickelt? Wurden vielleicht meine Bearbeitungen ergänzt oder verändert, oder gar zurückgesetzt? Wie wurde durch andere Wikipedianer der Artikel seit meiner letzten Beteiligung weiter geschrieben?

Lösungsvorschlag

Die Liste "Benutzerbeiträge" ist leider nicht geeignet, da dort alle Änderungen einzeln aufgelistet sind, und es gibt nur einen Filter für die aktuellen Beiträge, nicht das umgekehrte.

Anmerkungen

Warum die Liste "Benutzerbeiträge" nicht geeignet ist.

• Es ist nicht übersichtlich und die Liste ist unnötig lang. Genau dafür sollte ja eine Suche da sein - als Filter.
• Es werden mehrere Einträge angezeigt, wenn ich mehrmals einen Artikel geändert habe. Das möchte ich nicht.

Referenz: Benutzerbeiträge Frage

Vorschlagende Person

Pascamel (Diskussion) 16:07, 1. Feb. 2021 (CET)

Diskussion

Gibt es dafür nicht die Beobachtungsliste? --Fan-von-mir (Diskussion) 13:58, 29. Okt. 2021 (CEST)

Nein, das ist deutlich mehr als die Beobachtungsliste, ich habe mir sowas offline gestrickt: Ein Skript liest mein Spezial:Beiträge aus und zeigt mir die Liste nur der Beiträge, die nicht mehr aktuell sind UND die ich mir seit meiner letzten Änderung noch nicht habe anzeigen lassen. Das Ergebnis ist gleich verlinkt auf das Diff zwischen der aktuellen Version und meiner letzten Bearbeitung. Das ist ein ganz wichtiges Feedback, so erfahre ich, ob meine letzte Änderung überlebt hat. Da sich nur 4000(?) Beiträge abrufen lassen (ich rufe 1000 ab), muss ich irgendwann (nach etwa 500 Änderungen) das „Gedächtnis“ manuell aufräumen. Das ist aber immer noch besser als ohne Gedächtnis (aka Beobachtungsliste). Mit serverseitiger Unterstützung könnte das perfektioniert werden, danke Pascamel für den Vorschlag. Sprecht mich bitte an, wenn ich das näher ausführen soll. --Frühlingsmädchen (Diskussion) 12:17, 14. Nov. 2021 (CET)

• auch hier behandelt
•  Pro --Frühlingsmädchen (Diskussion) 12:21, 14. Nov. 2021 (CET)

 Pro  — --Wilhelm (Diskussion) 09:04, 20. Nov. 2021 (CET)

Seitenvorschau beim Verlinken auf andere WP-Seiten

Was ist das Problem?

Wenn man ein oder mehrere Worte mittels dem Link-setzen-Tool verlinken möchte, wird einem derzeit eins von drei Textkommentaren angezeigt: "Seite existiert nicht", "Seite bereits vorhanden", oder "Begriffsklärungsseite". Bei letzterem bekommt man durch Eingabe eines Leerzeichens noch ein Dropdown-Menü mit verschiedenen Möglichkeiten aus der BKS angezeigt. So weit, so gut. Trotzdem passieren immer wieder falsche Verlinkungen, zu Seiten die eine andere Person oder einen anderen Themengegenstand haben, als jenen, den man eigentlich verlinken möchte. Weil man im Tool nicht sehen kann, was auf der Seite steht, die man gerade verlinken möchte, muss man erst den Link setzen, den Knopf "Vorschau zeigen" anwenden, und dann prüfen, ob der Link tatsächlich dorthin führt, wo er hin soll.

Wen betrifft das Problem besonders?

Besonders Neulinge und etwas seltener arbeitende Wikipedianer setzen natürlich falsche Links, aber auch Erfahrene könnten fehlerfreier und vor allem schneller arbeiten, wenn sie beim Verlinken schon wüssten, wie der Inhalt der zu verlinkenden Seite aussieht.

Lösungsvorschlag

Es gibt seit ein paar Jahren die tolle Möglichkeit, sich eine Seitenvorschau von bereits verlinkten Textstellen anzeigen zu lassen, also wenn die Maus über einem Wiki-Link schwebt, bekommt man den ersten Absatz und gegebenfalls auch ein Bild aus dem Artikel angezeigt. So würde ich es mir auch für das Verlinkungstool wünschen: Dass mir eine Seitenvorschau geboten wird, bevor ich den Link setze. Vielleicht lässt sich das für das Dropdown-Menü bei mehreren Begriffen technisch nicht realisieren, aber jedenfalls der vorausgewählte Begriff im Eingabefenster, sollte eine Vorschau bieten, wenn die Maus über ihm schwebt. Dadurch würde man z.B. ganz schnell erkennen, dass zwar ein bestimmter Name bereits als Artikel existiert, es sich aber um eine andere Person handelt, als diejenige, zu der man verlinken möchte.

Vorschlagende Person

Sprachraum (Diskussion) 15:27, 3. Mär. 2021 (CET)

Diskussion

@Sprachraum: Der VisualEditor (und auch der darauf basierende neue Quelltext-Editor) zeigen beim Verlinken zumindest die Wikidata-Kurzbeschreibungen an. Vielleicht ist das schon ausreichend?--Cirdan ± 13:10, 25. Okt. 2021 (CEST)

Filter "Kurze Links" in den Letzten Änderungen in die Benutzereinstellungen

Was ist das Problem?

Ziel ist, dass in den 'Letzten Änderungen' die Filtereinstellung 'Kurze Links' stabil bestehen bleibt.

Wen betrifft das Problem besonders?

Alle angemeldeten Benutzer

Vorschlagende Person

Betterknower (Diskussion) 19:00, 3. Apr. 2021 (CEST)

Diskussion

Was ist mit "Kurze Links" in den Letzten Änderungen gemeint?—Hfst (Diskussion) 09:15, 12. Dez. 2021 (CET)

Optimierung der Vorlage Worldcat

Was ist das Problem?

In der Vorlage Worldcat ist es --- im Gegensatz etwa zu den Vorlagen DNB oder IMDb --- nötig, bei abgeleiteten Lemmata jedes Mal die Lemmaperson unter NAME= einzusetzen, was äußerst nervig ist, wenn man diese Vorlage mehrmals täglich neu in einen Artikel einsetzt. Der Gebrauch dieser Vorlage etwa im Literaturbereich hat stark zugenommen, sodass eine Anpassung an die automatische Generierung ohne die Klammerangabe höchst wünschenswert wäre. Beispiel:

• Vorlage:Worldcat id

Wen betrifft das Problem besonders?

Betroffen sind potentiell alle Benutzer, die einen Personenartikel anlegen.

Lösungsvorschlag

??

Anmerkungen

- - -

Vorschlagende Person

Qaswa (Diskussion) 20:34, 5. Apr. 2021 (CEST)

Diskussion

@Qaswa: Dieser Änderungswunsch wäre auf Wikipedia:WikiProjekt Vorlagen/Werkstatt gut aufgehoben. Hier auf den Wunschparkplatz passt er nicht gut, weil im Projekt Technische Wünsche keine individuellen Vorlagen bearbeitet werden. Ich wünsch dir viel Erfolg, dass die Vorlagenwerkstatt dir weiterhelfen kann. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:34, 8. Apr. 2021 (CEST)

definierte Bezeichnungen vor automatischem Zeilenumbruch schützen

• Schaffung einer Mediawiki-Funktion, die die Definition von zusammengehörigen Zeichen (Bezeichnungen) festlegen kann, mit dem Ziel, automatische Zeilenumbrüche zu unterbinden.

Was ist das Problem?

Es gibt Bezeichnungen, die freistehende Zeichen beihalten und daher als gesonderte Zeichen automatisch in die nächste Zeile rutschen können. Beispielsweise „z. B.“, was derzeit durch manuelles Setzen eines geschützten Leerzeichens unterbunden wird. Andere Beispiele sind Eigennamen wie das X Window System, Mutant X oder OS X, aber auch bei Namen mit zwei freistehenden Zeichen wie Windows NT oder Windows 9x.

• Was ich möchte: Um nicht jedes einzelne Mal dieselbe Bezeichnung wieder und wieder mit einem geschützten Leerzeichen (oder der Vorlage:Nowarp, oder einem geschützten Bindestrich) vor einem ungewollten Zeilenumbruch schützen zu müssen, wünsche ich mir eine Möglichkeit, pro Artikel Bezeichnungen zu definieren, die im gesamten Artikel wie eine Einheit behandelt und daher nicht umgebrochen werden. Die Wikimedia-Software würde dann automatisch für jedes Vorkommen der definierten Zeichenkette die darin enthaltenen Leerräume und Bindestriche durch deren geschützten Varianten ersetzen.
• Welche Schritte sind derzeit notwendig: Jedes Vorkommen der Bezeichnung, etwa „Mutant X“, muss (bzw. müsste) derzeit manuell mit einem geschützten Leerzeichen zusammengehalten werden. Mit einer solchen Funktion wäre nur noch ein einziger Schritt notwendig: Ähnlich der Funktion DISPLAYTITLE würde man per Funktion die Zeichenkette „Mutant X“ als zusammenhängend definieren, woraufhin der Umbruch im gesamten Artikel verhindert würde.
• Die Probleme, die im Moment (durch das Fehlen einer solchen Funktion) auftreten, sind, dass manche Autoren darauf keine Acht geben (oder im Visuellen Editor die geschützten Leerzeichen nicht erkennen) und sich so im selben Artikel bei fortschreitender Bearbeitung immer wieder unerwünschte Umbrüche ergeben, bzw. Autoren, denen der Lesefluss wichtig ist, ständig nacharbeiten müssen. Ein zusätzliches Problem sind Meinungsstreitigkeiten, wo und wann ein geschütztes Leerzeichen wirklich nötig ist, weil es ja gleichzeitig die Lesbarkeit des Quelltextes erschwert. Das ist Ansichtssache und fördert derlei Meinungsstreitigkeiten sogar noch, die sich negativ auf die Produktivität auswirken können.

Wen betrifft das Problem besonders?

Alle, die sich um Umbrüche Gedanken machen, sind betroffen: also jeder, der weiß, was &nbsp; ist...

Lösungsvorschlag

Eine Wikimedia-Funktion, die die Definition von zusammenhängenden Worten erlaubt, ähnlich wie es im Textsatzsystem TeX mit dem Kommando \hyphenation möglich ist, Umbrüche für einzelne Worte zu verhinden. Als Beispiel könnte dies so aussehen:

{{nowrap:Mutant X}}

würde im gesamten Artikel – Nachtrag: bei der Ausgabe (und daher nicht im Quelltext) – jedes Mutant X per Software automatisch in Mutant X umwandeln, und jedes Mutant-X in Mutant‑X (für Durchkopplungen).

Anmerkungen

Zusätzlich würde eine solche Funktion globale Ersetzungen erlauben, beispielsweise „z. B.“ in „z.&nbsp;B.“ usw... Eine ähnliche Funktion bzw. eine Erweiterung könnte auch erlauben, Falschschreibungen wie „z.B.“ (ohne Leerzeichen) bei der Anzeige automatisch in „z.&nbsp;B.“ zu ändern.

Vorschlagende Person

‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)

Diskussion

Also wenn soll die Software bitte nicht selbst das geschützte in den Quelltext setzen, sondern der Quelltext soll ohne diese Sonderzeichen auskommen, vielmehr soll wie beim % auch jetzt schon die Anzeige entsprechend angepasst werden, so dass letztendlich nur die Ausgabe betroffen ist (so wie aus dem Wiki-Quelltext [[Hier|dort]] der Quelltext der Internetseite generiert wird: <a href="/wiki/Hier" title="dort">. Godihrdt (Diskussion) 11:46, 29. Apr. 2021 (CEST)

Ja, so war es aber auch gemeint. Im Quelltext steht oben das zusammengesetzte Wort ("Mutant X"), das keinen Umbruch haben soll, und bei der Ausgabe wird es dann ersetzt. Im Quelltext selbst entfällt dann die Notwendigkeit, ein geschütztes Zeichen manuell einzusetzen. So wie beim %-Zeichen. ‣Andreas•⚖ 12:34, 29. Apr. 2021 (CEST)

Warum eigentlich pro Artikel? Wie wäre es mit einer Mediawiki-Systemseite? Sie könnte pro Zeile ein Pärchen beinhalten und der Parser muss nur Suchen und Ersetzen: z.B.|z. B.. Alternativ wäre der Ansatz, dies vom Quelltext/Markup zu entkoppeln. Ein Gadget könnte solchen Text doch auch live im Browser typografisch korrigieren. -- DerFussi 14:09, 27. Okt. 2021 (CEST)

Wichtig wäre aus meiner Sicht auch soviel Wiki-Markup wie möglich aus Artikeln herauszuhalten - für die Nicht-Nerds. -- DerFussi 09:36, 2. Nov. 2021 (CET)

Ich finde beides wichtig und richtig – systemweit und pro Artikel. Das Problem bei einer rein systemweiten Umsetzung wäre, dass sehr sehr spezifische Zeichenketten dort landen würden, und die müssten dann alle bei der Darstellung jedes Artikels abgearbeitet werden. Wenn man aber für das gesamte System nur Dinge wie "z.B." und "u.a." einführt, und dann dem Artikel überlässt, sich seine eigenen Worte zu setzen, wird die effektive Liste deutlich kürzer. Man könnte auch eine Liste von Zeichenketten in den entsprechenden Kategorien unterbringen, die, weil sie im Artikel eingebunden sind, dann für den Artikel übernommen werden (wenn man die Funktion so umsetzt).

Die Kategorien am Ende des Artikels sind auch jetzt schon nichts für Einsteiger. Profi-Formatierungen wie ein {{TOC limit|3}} einzusetzen, ist auch jetzt schon nicht gerade etwas für Nicht-Nerds, und trotzdem wird es gemacht. Warum auch nicht?

‣Andreas•⚖ 22:58, 8. Dez. 2021 (CET)

Intelligenter Textsatz (automatischer Zeilenumbruch)

• Schaffung eines intelligenten Textsatzsystems u. a. beim automatischen Zeilenumbruch

Was ist das Problem?

• Zu viel, was in einer Textverarbeitung oder in einem Textsatzsystem automatisch geschieht, muss in der Wikipedia manuell und händisch erledigt werden.
• Jeder Autor macht bei seinen Edits Stilentscheidungen beim Textsatz, die mit anderen Autoren bzw. anderen Artikeln in der Konvention brechen, sodass viele Artikel unterschiedlich aussehen. Ein automatisches System könnte dies teilweise beheben.
• Beispiele für Systeme, die des semi-automatisch erledigen: TeX

Wen betrifft das Problem besonders?

Alle, die sich über Typografie, Layout, Textsatz und üblichen Konventionen Gedanken machen und denen das daher auch in der Wikipedia wichtig ist, da es nicht selten die Lesbarkeit unserer Artikel fördert.

Lösungsvorschlag

Sprachspezifischer von TeX inspirierter (oder daraus übernommener) intelligenter automatischer Textsatz. Eine Implementierung könnte sich stufenweise voranarbeiten, beginnend bei automatischen Umbrüchen bzw. Verhinderung derselben an Stellen, wo dies nicht passieren sollte (bei „z. B.“, „u. a.“ usw...). Ebenso die automatische Nutzung von typgrafischen Anführungszeichen. Es muss dabei die Möglichkeit bestehen, dieses Verhalten zu beeinflussen/abzuschalten (analog zu HTML-<pre>).

Anmerkungen

Intelligenter Textsatz erkennt, wann ein automatischer Zeilenumbruch gut ist und wann nicht. Umbrüche nach einem Viertelgeviertstrich sind zwar sehr oft richtig, aber nicht immer, beispielsweise bei Wortergänzungen. Beispiele (von Viertelgeviertstrich#Ergänzungsstrich): Verkehrslenkung und ‑überwachung oder Laserstrahlschmelz-, ‑brenn- und ‑sublimierschneiden. Die Wikimedia-Software macht dies derzeit noch zu oft falsch. Es gibt aber auch noch weitere Beispiele, wo eine intelligente Software den Autoren viel Arbeit (und Streit) abnehmen würde...

Ein derartiges Textsatzsystem könnte nicht nur Zeilenumbrüche intelligenter steuern, sondern auch automatische Zeichenersetzung:

• #Automatische Ersetzung bestimmter Zeichen
• #&nnbsp; als Synonym für  

Und es würde eine rein manuelle Implementierung großteils ersetzen (aber nicht unnötig machen):

• #definierte Bezeichnungen vor automatischem Zeilenumbruch schützen

Ein weiters Beispiel ist die Nutzung von Schrägstrichen im Deutschen. Zwischen WortEins/WortZwei macht die Software keinen automatischen Zeilenumbruch, obwohl nach dem Schrägstrich einer zugelassen werden sollte: WortEins/↵WortZwei. Gerade bei langen Worten, die mit Schrägstrich gleichwertig nebeneinander stehen (Bedeutungseinheit), sieht der automatische Zeilenwechsel sonst oft sehr unprofessionell aus. Die Schreibweise mit Leerzeichen (wenn es keine Bedeutungseinheit gibt) hat ebenfalls das Problem, dass es damit möglich wird, dass der Schrägstrich selbst bereits in der nächsten Zeile steht. "WortEins/ WortZwei" ist keine im Deutschen typografisch korrekte Form, sie ist rein der (derzeit) schlechten Automatik geschuldet.

Vorschlagende Person

‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)

Diskussion

Zeilenumbrüche regelt nicht MediaWiki, sondern der Browser. Wenn das gewünscht ist, könnte das per CSS aktiviert werden bzw. kannst du es dir in deine common.css eintragen: ausführliche Erläuterung. Das scheint mir im Internet aber recht ungewöhnlich zu sein, weil es – wie du schon andeutest – recht komplex ist, einen Text passend zu setzen. Bei TeX funktioniert das, weil die Zeilenlänge und Laufweite der Schrift fest definiert ist (und selbst da muss man manchmal per Hand nachhelfen und problematische Zeilen und Wörter zurechtrücken). Bei einer Website wie Wikipedia weiß niemand, wie viel Platz und welche Schriftarten zur Verfügung stehen.--Cirdan ± 20:20, 2. Nov. 2021 (CET)

Tja, das ist dann ein Problem. Wenn man sich als Wikipedia-Nutzer eine eigene common.css anlegen muss, dann wird das gewünschte wohl nur von demjenigen gesehen, der a) das Know-How hat, und b) der bei Wikipedia mitarbeitet. Ein unangemeldeter Nutzer wird wohl kaum eine eigene common.css erstellen können...

Und es gibt noch ein Problem: die in der Quelle verlinkte Methode legt zuerst die Sprache fest. Doch die weiß ich ja gar nicht: wenn ich mir einen englischen Artikel ansehe, ist dann immer noch der deutsch Zeilenumbruch aktiv? Ach, ich müsste mir wohl in jeder Sprachversion eine common.css anlegen...

Und wie sieht es mit fremdsprachigen Wörtern in deutschen Artikeln aus? Diese kann man ja mit der Vorlage:lang als anderssprachig auszeichnen, was u.a. für Screenreader gedacht ist. Für grammatikalische Regeln und Zeilenumbrüche könnte diese Information aber auch verwendet werden.

Und wie würde das das Problem mit den Schrägstichen lösen? "Wort1 / Wort2" kann immer noch so umgebrochen werden, dass "Wort1" am Ende der oberen Zeile steht, "/ Wort2" dann in der nächsten, was nicht gewünscht ist (denn "Wort1 /" soll zusammen bleiben). Wie beim Schrägstrich zwischen zwei gleichwertigen Worten (Bedeutungseinheit), was man ohne Leerzeichen schreibt, also "Wort1/Wort2", ist derzeit immer ein falscher Umbruch möglich... Außer man ersetzt "Wort1 / Wort2" vor der Darstellung durch den Browser (wie man es jetzt schon beim %-Zeichen tut, also "99 %" wird nicht getrennt) durch "Wort1&nbsp;/ Wort2", denn dann wird es in jedem Fall korrekt dargestellt, und fügt bei "Wort1/Wort2" ein breitenloses Leerzeichen ein, also "Wort1/&#x200b;Wort2", denn dann wird auch das korrekt umgebrochen.

Müsste soetwas nicht Sprachen-abhängig die Wikimedia-Software machen?

Die Sache würde deshalb Sinn machen, weil das ja immer zutrifft, wie "99 %" und "z. B." gelten diese Regeln ja in jedem Fall. Mir fällt jetzt auch gar nicht ein, warum man das nicht wollte... Und wenn es theoretisch einen Fall gibt, dann müsste man eine Funktion einführen bei der diese Automatik ausgeschaltet wird, etwa (nur ein Vorschlag) {{plain|Plain text without autoformat}} – was dann sicher weniger oft verwendet werden muss, als derzeit das beinahe obligatorische "z.&nbsp;B." oder ein "Wort1/&#x200b;Wort2"... Letzeres führt nochdazu bei vielen Autoren zu Verwirrung, und die löschen es dann wieder, und in meinem Browser muss ich dann wieder "SehrLangesWortEins/NochVielLängereBezeichnungFürWortZwei" als gesamtes in der nächsten Zeile lesen, obwohl "SehrLangesWortEins/" noch in die vorige gepasst hätte...

‣Andreas•⚖ 22:43, 8. Dez. 2021 (CET)

Bitte eine Benutzeroberfläche mit Darkmode-CSS hinzufügen.

Was ist das Problem?

Bei einem Rechner, der überwiegend mit Programmen in einem Darkmode betrieben wird, wird man bei Aufruf der Wikipedia durch die Helligkeit geblendet. Ein Darkmode in Wikipedia würde das Arbeiten am Bildschirm angenehmer machen und bei Mobilgeräten mit OLED-Displays auch die Batterie schonen. Das oft empfohlene Herunterregeln der Helligkeit ist keine Lösung, da beim Hin- und Herschalten zwischen den Programmen nicht jedes mal die Helligkeit nachgeregelt werden kann.

Sicherlich ist das Augenschonende eines Darkmodes noch umstritten, aber das grelle Aufblitzen des Bildschirmes bei Aufruf von Wikipedia stört eben doch. Da wäre es eine gute Möglichkeit, bei den Einstellungen statt Vector oder Monobook auch einen Darkmode einstellen zu können.

Wen betrifft das Problem besonders?

Alle Nutzer, besonders die mit Mobilgeräten mit OLED-Display.

Lösungsvorschlag

Bei den Einstellungen ein CSS mit Darkmode hinzufügen.

Vorschlagende Person

≡c.w. @… 08:55, 30. Apr. 2021 (CEST)

Diskussion

Ja, nun: nachdem das hier mehr als 2 Monate unbeachtet blieb und eine professionelle Lösung nicht in Aussicht ist, habe ich eine private, nicht-professionelle Lösung erarbeitet: Benutzer:Charly_Whisky/common.css

…nicht vollkommen und mit heißer Nadel gestrickt, aber für meine Augen ausreichend. (Und wenn mir noch irgendeine farbliche Dissonanz auffällt, wird sie dort ergänzt.)

Von dem Team „Technische Wünsche“ bin ich stark enttäuscht: sie reagieren zwar wenn man ihnen auf die Füße tritt (was die hiesige Disk zeigt), aber besonders hilfreich ist das nicht.--≡c.w. @… 07:36, 10. Jul. 2021 (CEST)

Das ganze CSS des Wikis ist auch sehr unsauber und völlig chaotisch programmiert. Es gibt ungewöhnlich viele Objekte, die schon vom PHP her eine direkte Style-Zuweisung machen (also ohne Klassen oder ID-Namen) und die man dann gar nicht über eine individuelle Farbgebung beeinflussen kann. Dazu kommen noch die Style-Angaben direkt in den Vorlagen, die keinerlei Rücksicht auf mögliche andere Farbvarianten nehmen. --≡c.w. @… 21:31, 10. Jul. 2021 (CEST)

Hallo c.w., ich kann verstehen, dass das enttäuschend ist. Es gibt einfach so viele Dinge, die man an der Software hinter Wikipedia verbessern könnte, aber leider ist es nicht möglich, sie alle anzugehen. Hinter jedem Wunsch stecken mehrere Monate Recherchearbeit, um beispielsweise zu verhindern, dass Änderungen, die für eine Person hilfreich sind, die Arbeitsabläufe von anderen Personen behindern. Auch die Umsetzung von Funktionen in MediaWiki (und auf MediaWiki konzentrieren wir uns ja) ist selbst bei vermeintlich kleineren Änderungen immer zeitaufwändig; u.a. muss in der Regel alter Code erstmal aufgeräumt werden, bevor man neue Funktionen ergänzen kann, aber auch die Vielzahl von Nutzerscripten, Helferlein, Skins usw. verlangsamen die Arbeit. Auf dem Wunschparkplatz befinden sich gerade 88 Wünsche. Wenn jeder Wunsch innerhalb von drei Monaten lösbar wäre (was bereits superoptimistisch geschätzt ist), wäre das Projektteam damit schon 264 Monate beschäftigt.

Darum lässt das Projekt Technische Wünsche die gesammelten Probleme durch die Mitglieder der deutschsprachigen Community priorisieren und es wird dann das umgesetzt, das den meisten Leuten wichtig ist. Um diese Priorisierung ging es schon in der ersten Umfrage 2013 und geht es weiterhin. Ich hoffe, ich konnte ein bisschen Klarheit schaffen, warum das hier nur ein Parkplatz sein kann, und es nicht möglich ist, sich all die Wünsche hier im Einzelnen anzusehen, geschweige denn Lösungen dafür zu entwickeln. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:57, 12. Jul. 2021 (CEST)

Es gibt bereits die DarkMode Erweiterung für MediaWiki, welche seit einiger Zeit von einigen Freiwilligen entwickelt wird. Ich habe sie mal lokal getestet und sie scheint recht gut zu funktionieren. Allerdings ist es wie immer eine große Qual eine neue Erweiterung auf die WikiMedia Server zu bekommen, siehe den vollen Prozess: mw:Writing an extension for deployment. --Zabe (Diskussion) 16:14, 25. Okt. 2021 (CEST)

Diese Extension benötigt zur Einbindung allerdings root-Rechte auf dem Server, weil u.a. die LocalSettings.php manuell geändert werden muss. Wäre eine einfache Lösung, die Anwendung müsste aber in einer zusätzlichen Hilfedatei dem Nutzer gut erklärt werden. Sie benötigt aber ebenfalls zusätzliche Modifikationen in einer Nutzer-eigenen CSS-Datei. --≡c.w. @… 08:41, 9. Dez. 2021 (CET)

Ich bin gerade dabei, aufbauend auf dem CSS von @Charly Whisky: mir ein eigenes Set zusammenzubauen: meta:User:DerFussi/global.css. Dabei sind mir ein paar Dinge aufgefallen die vielleicht mal vorbereitend getan und gewünscht werden sollten

• Ich habe hier auf der WP Infoboxen, die ich nicht umgefärbt bekomme. Ich denke vorher sollten alle Vorlagen auf der Wikipedia daraufhin überprüft und gefixt werden, die die Farbanweisungen hart im Tag vercodet haben und alle Styles in Klassen ausgelagert werden. Ich habe das auf Wikivoyage früher schon mal begonnen (wir haben ja nicht so viele wie ihr) und gerne ein Präfix davorgesetzt wie "wv" für Wikivoyage oder besser noch mit Sprachcode, sowas wie: "WVde-foo-bar". Dann kann man den Darkmode auch ordentlich parametrieren.
• Einige Symbole in den Wikis wie z. B. die Edit-Buttons auf Wikidata sind als Hintergrundbild eingebunden. Wäre es SVG direkt innerhalb des HTML könnte man die Bildchen auch einfach per CSS einfärben, mit Hover-Effekten versehen usw. Vielleicht sollte man als ersten Schritt mal von den Technikern das geparste HTML daraufhin optimieren lassen, dass man sämtliche Designelemente einfach und bei Basiselementen der Wikisoftware gleichzeitig für alle Wikis beeinflussen kann. -- DerFussi 12:06, 3. Nov. 2021 (CET)

•  Pro Darkmode auf Handy und PC wäre schön. --Fuchs B (Diskussion) 21:11, 31. Okt. 2021 (CET)
•  Pro Bin auch dafür -- DerFussi 12:06, 3. Nov. 2021 (CET)
•  Pro Klar doch, nur schade, dass in der Vorlagenwerkstatt die Meinung vorherrscht, ein Dark-mode sei Quatsch und würde (der Vorlagenwerkstatt!) viel zu viel Arbeit machen. (Da gab es schon eine sehr negative Diskussion darüber.) Und deswegen werden auch bei neuen Vorlagen demonstrativ direkte Farbzuweisungen eingesetzt, die durch derart CSS-Dateien nicht geändert werden können. --≡c.w. @… 08:58, 5. Nov. 2021 (CET)
•  Pro greetz vanGore 13:52, 5. Nov. 2021 (CET)
•  Pro Dark Mode ist ein absolut essenzielles Basis-Feature im Kontext des Jahres 2021. Der aktuelle Zustand wirkt auf mich schlicht vorsteinzeitlich. --BourgetJuin (Diskussion) 09:05, 6. Nov. 2021 (CET)

 Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)

•  Pro aber zumindest in der Wikipedia-App gibt es einen Darkmode und dort ist es am wichtigsten, da auf dem Smartphone --Lupe (Diskussion) 17:18, 5. Sep. 2022 (CEST)

Auflösen von <ref> bei <onlyinclude>

Was ist das Problem?

Besonders bei Künstlern ist es beliebt die Diskographie in eine eigene Seite auszulagern. Dann werden oft Teile dieser Seite z.B. Liste mit Titel mit Hilfe von <onlyinclude> wieder in den Originalartikel importiert. Wird nun im <onlyinclude> ein <ref name="" /> verwendet kann dieser nicht in der Originalseite nicht aufgelöst werden und führt zu einem Fehler, der nicht ohne weiteres zu finden ist, da eine einfache Suche nichts findet.

Wen betrifft das Problem besonders?

im Prinzip alle Autoren

Lösungsvorschlag

1. Beim Parsen von onlyinclude immer die Referenzen der Originalseite mitnehmen (Cache)
2. Als Minimum eine Fehlermeldung ausgeben, mit dem Hinweis das die Referenz vermutlich auf der Seite include liegt.

3. Bei onlyinclude einen Fehler ausgeben, dass eine Referenz nicht exportiert wird (kann zu Missverständnissen führen)

Anmerkungen

Ich denke das ein großen Problem darin liegt, das mit dem jetzigen Verfahren eine Fehlermeldung ausgegeben wird, die einfach nur verwirrt, da diese Referenz auf der Seite nicht existiert. Das passiert bei (fehlerhafter) Verwendung von ref auch in anderen Umständen. Mit Erfahrung ist das Problem lösbar, führt aber dann unter Umständen dazu, dass auf der Original-Seite und der Include-Seite die gleiche Referenz eingetragen wird und im verlauf der Zeit sich aber an einem Ort verändert oder beim Inlcude gleich (versehentlich) auf die falsche Ref zeigt. Eine echte Gefahr bei Namen wie ":0" etc.

Vorschlagende Person

A1000 (Diskussion) 10:45, 3. Jun. 2021 (CEST)

Diskussion

Automatisch nachgefuehrte Links auf Abschnitte von Diskussionsseiten mit Archiv

Was ist das Problem?

Setzt man einen Link auf eine Diskussion in einer archivierten Diskussionsseite, verwandelt sich dieser Link eine Woche nach Ende der Diskussion in einen toten Link, weil der betreffende Abschnitt auf die Archivseite verschoben wird, die darauf zeigenden Links beim Archivieren aber nicht mitgenommen werden.

Besonders bedeutsam ist das bei Links, die man gar nicht nachtraeglich anpassen kann, naemlich Links in der Zusammenfassungszeile von Artikelaenderungen, die ja auf eine der Aenderung zugrunde liegende Diskussion verweisen sollen. Ein Beispiel dafuer ist der Link in der Zusammenfassungszeile dieser Aenderung (von mir selbst).

Wen betrifft das Problem besonders?

Bearbeiter der Wikipedia, die an Diskussionen teilnehmen und diese an anderer Stelle verlinken wollen.

Lösungsvorschlag

Ich habe den Eindruck, dass sich das nicht einfach mit einer Vorlage erledigen laesst, die dynamisch ermittelt, ob der Abschnitt schon verschoben wurde oder noch nicht, und dann den richtigen Link generiert, sondern dass fuer die Loesung dieses Problems weitergehende technische Unterstuetzung erforderlich ist.

Konkreter Vorschlag wird gesucht.

Vorschlagende Person

Juergen 217.61.204.70 00:36, 9. Jun. 2021 (CEST)

Diskussion

•  Pro --Fuchs B (Diskussion) 21:12, 31. Okt. 2021 (CET)
•  Pro Lästig und nervt mich immer wieder, dann stundenlang suchen zu müssen, wo im Archiv der Abschnitt dann abgelegt ist. --Grizma (Diskussion) 10:18, 1. Nov. 2021 (CET)

 Pro—Hfst (Diskussion) 09:19, 12. Dez. 2021 (CET)

Tabelle mit sortierbaren Spalten: Möglichkeit, eine statische (nummerierende) Randspalte zu erstellen, um den Rang ablesen zu können.

Was ist das Problem?

Beispiel: Liste der Länder nach Gefängnisinsassen: Eine Liste, in denen die eingetragenen Länder in den sortierbaren Spalten (Gesamtzahl der Gefangenen; Anzahl der Gefangenen pro 100 Einwohner, Frauen- und Ausländeranteil) unterschiedliche Ränge einnehmen. Es ist nicht möglich, links eine statische Randspalte zu erstellen, an der man den Rang betreffend der ausgewählten Sortierspalte ablesen kann. Stattdessen wären dort in Kleinarbeit (wie für vorgenannte Liste bereits erfolgt für Gesamtzahl der Gefangenen und Anzahl der Gefangenen pro 100 Einwohner) jeweils für die Kategorie zusätzlich eine entsprechende Spalte für die dementsprechende Rangliste zu erstellen. Das bedeutet einmal erheblichen Arbeitsaufwand zur Erstellung und erst Recht bei Aktualisierung längerer Ranglisten. Zudem ist es ziemlich "unschön", mehrere Spalten für den entsprechenden Rang einer Sortieroption vorzusehen. Wie es im Optimalfall aussehen könnte, sieht man in der englischen Version des Artikels, siehe [12].

Wen betrifft das Problem besonders?

Leser und Bearbeiter längerer Ranglisten mit unterschiedlichen Sortieroptionen, es existiert eine Vielzahl von Listen mit diesem Defizit, wahllos fünf Beispiele nur aus der Kategorie Liste (Staaten): Liste der Länder nach Zigarettenkonsum (Rangliste betreffend Geschlechteranteil nicht ablesbar);Liste der Staaten mit dem höchsten Energieverbrauch (Rang nur für das Jahr 2016 ablesbar);Rangliste der Pressefreiheit (Rangliste ohne ablesbaren Rang);Liste der Länder nach Staatshaushalt (Rang betreffened BIP nicht ablesbar); Liste von Ländern nach durchschnittlicher Lebenserwartung (Rangliste nur für ein Jahr ablesbar, Rang zudem betreffend Geschlechteranteil nicht ablesbar)

Anmerkungen

Hilfe:Tabellen/Sortierung#Rangliste aktualisieren

Vorschlagende Person

Quintil Jan Verus (Diskussion) 10:57, 10. Jun. 2021 (CEST)--

Diskussion

•  Pro --Fuchs B (Diskussion) 21:13, 31. Okt. 2021 (CET)

Letzte eigene Bearbeitungen, die nicht aktuell sind, besser erkennen können

Was ist das Problem?

Ich will nachschauen können, wenn auf einer von mir editierten Seite nach meinem letzten Edit jemand anders etwas geändert hat.

Nachschauen auf der Seite der eigenen Beiträge (bei angemeldeten Benutzern auf der Seite ganz oben rechts; 2. Wort/Link von rechts, links von Abmelden) ist äußerst unübersichtlich, wenn es darum geht, jene Beiträge aufzulisten, die nicht mehr aktuell sind UND bei denen ich nicht selbst der letzte Editor war. Dies gilt für Artikel genauso wie für Diskussionen.

Beispiel: ich editiere irgendwo; solange niemand anders dort editiert, erscheint auf meiner Liste ein (aktuell) hinter dem Edit. Hat später jemand dort editiert, verschwindet die Klammer mit "(aktuell)". Ich editiere nicht nur einmal, sondern z.B. in einer Diskussion innert Wochenfrist mehrmals. Damit entstehen in meiner Liste mehrere Einträge mit einem Link zu jener Diskussion, wovon hinter dem letzten ein (aktuell) steht, solange niemand anders etwas geändert hat. D.h.: die derzeitige Hervorhebung besteht dann, wenn ich der letzte Editor war.

Viel interessanter sind jedoch jene Artikel/Diskussionen, bei denen nach mir sonstwer etwas editiert hatte. Bei mir erscheinen alle Einträge der genannten Seite ohne aktuell-Klammer. Insbesondere bei Vorhandensein mehrere Einträge kann ich aber nur schwer erkennen, welches nun der letzte dieser Einträge war, da die Einträge auf meiner Seite mehrfach erscheinen – und alle ohne Hervorhebung.

Ziel ist es, sämtliche Artikel/Diskussionen besser erkennen zu können (in welcher Art auch immer), die ich editiert hatte, bei denen ich aber nicht der letzte Editor war – und zwar pro Artikel/Diskussion nur mit einer einzigen Erwähnung (nämlich der allerletzten – sprich: mein allerletzter Edit).

Fazit: die Liste der eigenen Beiträge müßte so gefiltert werden können, daß eine editierte Seite nur ein einziges mal aufgeführt wird – nämlich nur der letzte von mir getätigte Edit auf jeder Seite. Frühere nicht mehr aktuelle Edits müßten weggefiltert werden können.

D.h. die Filtermöglichkeit müßte ergänzt werden mit sowas wie "editierte Seiten nur 1x aufführen" resp. "nur letzten Edit einer Seite aufführen". Dann wird es übersichtlicher, zu erkennen, wenn eine Seite nach meinem Edit wieder geändert worden ist (die hat dann keine "(aktuell)"-Klammer.

Wen betrifft das Problem besonders?

Sämtliche angemeldeten Benutzer

Lösungsvorschlag

Filter ergänzen mit "nur letzten Edit einer Seite anzeigen" oder (o.ä.)

Anmerkungen

Dieser Filter auf nur die letzten Edits jeder Seite soll zusätzlich zur jetzigen Anzeige sämtlicher Edits bestehen.

Eine andere (ohne zusätzlichen Filter) ev. einfach(er) umsetzbare Variante wäre, daß bei sämtlichen Edits jeweils die letzte Erwähnung jeder Seite erkennbar andersfarbig unterlegt würde. Das Auge müßte sich dann nur auf diese Hinterlegungsfarbe konzentrieren und könnte so besser erkennen, ob nun ein "(aktuell)" dasteht oder nicht. Eine Variante wäre, daß dieses anderfarbige Hinterlegungsfarbe in den eigenen Einstellugnen ein-/ausgeschaltet werden müßte (und nicht automatischaktiv wäre).

Vorschlagende Person

ProloSozz (Diskussion) 11:03, 7. Jul. 2021 (CEST)

Diskussion

• auch hier behandelt

In Beobachtungsliste gleichzeitiges Öffnen aller Änderungen ermöglichen

Was ist das Problem?

Wer viele Seiten beobachtet und sich die Änderungen auch im Detail anschauen möchte, muss derzeit jede Seite einzeln öffnen. Das ist ein unnötiger Aufwand, der vermutlich relativ einfach minimiert werden könnte.

Wen betrifft das Problem besonders?

Alle Nutzer der Beobachtungsliste, speziell die mit vielen beobachteten Seiten.

Lösungsvorschlag

Anbieten zusätzlicher Links auf der Beobachtungsseite, die dafür sorgen, dass die Mindestangebote "Alle Seiten mit ungesehenen Änderungen öffnen" sowie "Alle Seiten mit ungesehenen Änderungen unter Anzeige der Versionsunterschiede öffnen" mit einem Mausklick ausgewählt werden können. Ich persönlich hätte das gerne als neue Tabs, andere vielleicht lieber als neues Fenster. Deshalb und weil es bestimmt noch andere Nutzungsvorlieben für die Beobachtungsliste gibt, sollte man je nach Diskussionsverlauf vielleicht eine benutzerspezifische Einstellung ermöglichen.

Vorschlagende Person

Lguenth1 (Diskussion) 18:32, 7. Jul. 2021 (CEST)

Diskussion

sehr gute Idee! --Fan-von-mir (Diskussion) 14:16, 29. Okt. 2021 (CEST)

Medienbetrachter sollte in Bildlegende enthaltenes TeX darstellen können

Was ist das Problem?

Wenn man in einem Wikipedia-Artikel auf ein dort eingebundenes Bild klickt, wird es bekanntlich im Medienbetrachter geöffnet und (oft vergrößert) dargestellt. Die Bildlegende wird dabei aus dem Artikel übernommen und im Medienbetrachter unten angezeigt. In der Bildlegende enthaltenes TeX geht im Medienbetrachter allerdings fehlerhafterweise verloren – anstelle der TeX-Inhalte wird hier nichts ausgegeben. Das kann im Medienbetrachter zu verstümmelt dargestellten Bildlegenden führen. (In den Artikeln werden TeX-Inhalte in Bildlegenden hingegen problemlos dargestellt.)

Daher mein Anliegen: Auch der Medienbetrachter sollte in der Bildlegende enthaltenes TeX darstellen können.

Beispiele:

1. Beispiel 1
   • Artikel: Funktion (Mathematik)#Verknüpfung
   • Bild mit TeX in Bildlegende im Medienbetrachter: Funktion (Mathematik)#/media/Datei:Binary operations as black box.svg
2. Beispiel 2
   • Artikel: Komplexe Zahl#Komplexe Konjugation
   • Bild mit TeX in Bildlegende im Medienbetrachter: Komplexe Zahl#/media/Datei:Komplexe konjugation.svg
3. Beispiel 3
   • Artikel: Parabel (Mathematik)#Jede Parabel ist zur Normalparabel y=x² ähnlich
   • Bild mit TeX in Bildlegende im Medienbetrachter: Parabel (Mathematik)#/media/Datei:Parabel-scal2.svg

Wen betrifft das Problem besonders?

Alle NutzerInnen, die in Artikeln auf Bilder klicken, deren Bildlegende TeX enthält.

Vorschlagende Person

SweetWood (Diskussion) 19:54, 8. Jul. 2021 (CEST)

Diskussion

Bilder-Vorschau in Commons Unterkategorien

Was ist das Problem?

Man möchte ein Foto in eine Kategorie einsortieren weiß aber nicht ob/welche Unterkategorie eventuell passt. Ich habe z.B. eine Skulptur fotografiert, bei der Titel und Künstler nicht angegeben sind, und schaue dann z.B. in c:Category:Sculptures in Hannover - da sind aber 196 Unterkategorien, wohin gehört nun mein Foto? Wäre schön wenn man hier eine Vorausschau einiger Bilder aller direkten Unterkategorien aktivieren könnte (je drei? fünf? je nach Bildschirmbreite?) (ggfs. Gesamtzahl limitiert falls Performanceprobleme). Ähnliche Anwendung: man sucht ein bestimmtes Gebäude kennt aber den Namen der Unterkategorie nicht.

Wen betrifft das Problem besonders?

Commons-Nutzer

Lösungsvorschlag

Entweder ein Button, oder z.B. in der Reiterleiste unter "Weitere" einen Punkt "Vorschau bei Unterkategorien"

Vorschlagende Person

Gerd Fahrenhorst (Diskussion) 13:48, 12. Jul. 2021 (CEST)

Diskussion

•  Pro --Fuchs B (Diskussion) 21:17, 31. Okt. 2021 (CET)
•  Pro Das wär toll. Arbeite im Moment immer mit unterschiedlichen Fenstern, in dem einen suche ich nach passenden Kategorien, in das andere füge ich sie ein. Echt umständlich. --Grizma (Diskussion) 10:16, 1. Nov. 2021 (CET)
•  Pro - --Bärbel Miemietz (Diskussion) 20:53, 14. Nov. 2021 (CET) Super Idee! Mit dem Problem schlage ich mich auch ständig rum.
•  Pro theoretisch gäbe es neben den Kategorien noch die Galerie-Seiten, die aber in der verlinkten Kategorie noch niemand erstellt hat --Lupe (Diskussion) 17:25, 5. Sep. 2022 (CEST)

In der Vorlagenprogrammierung die Funktion Schleife ermöglichen

Was ist das Problem?

Ich möchte z. B. in Vorlagen identische Programmteile

1. jeweils für alle Monate eines Jahres aufrufen und diese nicht 12 Mal mit identischem Code einprogrammieren.
2. von einem Ausgangsjahr bis zum aktuellen Jahr das Ergebnis generieren ohne jährlich die Vorlage für das aktuelle Jahr zu erweitern.

Wen betrifft das Problem besonders?

Vorlagenprogrammierer

Lösungsvorschlag

Diese Erweiterung in der deutschen Wikipedia installieren.

Anmerkungen

Es geht um solche und ähnliche Konstruktionen:

1. {{ #loop: monat | 1 | 12 | <!-- Hier ein Anweisungsblock, in welchem {#var: monat}} benutzt wird --> }}
2. {{ #loop: jahr | 2010 | {{#expr: 1+{{JETZIGES_JAHR}}-2010}} | <!-- Hier ein Anweisungsblock, in welchem {#var: jahr}} benutzt wird --> }}
   Vorschlagende Person

Former111 (Diskussion) 16:37, 21. Okt. 2021 (CEST)

Diskussion

@Former111: Könntest du hierfür nicht Lua einsetzen? Das ist mutmaßlich auch deutlich performanter als die Loops-Extension. Vielleicht kann Benutzer:MGChecker als Maintainer dazu eine Einschätzung abgeben?--Cirdan ± 13:05, 25. Okt. 2021 (CEST)

Das sehe ich ganz genau so. Loops ist für größere Wikis wie die Wikipedia durch Scribunto effektiv obsolet, und ich kann mir nicht vorstellen dass die WMF eine Installation zulassen würde. Darüber hinaus kann Loops seine Vorzüge so wirklich nur im Zusammenhang mit Variables ausspielen, die gemäß der Parsoid-Pläne ganz gewiss nicht von der WMF installiert werden werden. (nicht signierter Beitrag von MGChecker (Diskussion | Beiträge) 14:16, 25. Oktober 2021 (CEST))

@MGChecker: Danke für deine kompetente Einschätzung!--Cirdan ± 16:08, 25. Okt. 2021 (CEST)

BK: : @Cirdan: Nach meiner Erkenntnis muss dann die gesamte Vorlage mit LUA programmiert werden, da die Laufvariable nicht in die Schleife der "normalen" Programmierung übergeben wird. Mir wurde von Benutzer PerfektesChaos mitgeteilt, dass gesamte Vorlagen mit LUA zu programmieren nicht gewünscht ist. Ich habe das so verstanden, dass nur noch universell einsetzbare Module in LUA erstellt werden sollen. Auch möchte ich aufgrund meines Alters nicht die Programmsprache LUA erlernen, dafür gibt es sicher Spezialisten. --Former111 (Diskussion) 14:27, 25. Okt. 2021 (CEST)

@Former111: Du könntest aber doch ein Schleifen-Modul in Lua bauen? Dann übergibst du aus einer "klassischen" Vorlage die Liste, über die iteriert werden soll, an das Lua-Modul. Wenn du programmieren kannst, sollte Lua kein Problem für dich darstellen, ich habe selbst auch ohne Lua-Erfahrung vor einigen Jahren ein Modul geschrieben und fand das wesentlich angenehmer als das übliche Vorlagen-Gebastel.--Cirdan ± 16:08, 25. Okt. 2021 (CEST)

Ich habe das Programmieren und Kodieren Anfang der 1960er Jahre gelernt und wir haben die Maschinenbefehle noch als Binärkode kodiert. Die späteren Assembler waren eine enorme Erleichterung, da wir dann symbolische Anweisungen verwenden konnten. Mittels "If, Then, Goto ..." usw. wurden vorher im Groben die Programmablaufpläne dargestellt um eine Codierung danach zu ermöglichten. Deshalb fiel mir das "übliche Vorlagen-Gebastel" relativ leicht.
Könntest du einem solchen universellen Lua-Modul erstellen? --Former111 (Diskussion) 16:28, 25. Okt. 2021 (CEST)

Ich habe leider keine Zeit dazu bzw. derzeit andere Interessen in der Wikipedia, als Entwicklung von Vorlagen. Gerade mit deinem Grundlagenwissen sollte dir Lua allerdings sehr leichtfallen. Hast du dir "mein" Modul einmal näher angeschaut? Das ist genau solch ein sehr strukturierter Ablauf, wie du ihn beschreibst. Sei mutig!--Cirdan ± 16:51, 25. Okt. 2021 (CEST)

Habe mir deinen Modul angesehen. Es ist doch was ganz anderes als ein "linearer" PAP. Mein Einarbeiten in diese Hochsprache würde zu Fehlern und Problemen führen. Entsprechend "Schuster bleib bei deinen Leisten" sollen das besser jüngere LUA-Codierer machen. --Former111 (Diskussion) 11:25, 26. Okt. 2021 (CEST)

@Former111: Schade, ich hatte den Eindruck bzw. die Hoffnung, dass wenigstens durch die Kommentare im Code sehr deutlich wird, was in jedem Schritt passiert.--Cirdan ± 18:12, 26. Okt. 2021 (CEST)

@Cirdan: Dein Quellcode ist vorbildlich kommentiert. Voraussetzung das Verständnis des Codes ist aber wie immer bei IT, dass man die Syntax der Sprache des Assemblers, Compilers oder Interpreters beherrscht. Ich kann vieles vermuten, z. B., dass mw.ustring.rep der Aufruf eines Systemroutine wäre.
Ich habe bereits in der Lua-Werkstatt um Unterstützung angefragt. --Former111 (Diskussion) 17:10, 28. Okt. 2021 (CEST)

Oh gott, ich sehe es schon kommen, Wikiseiten, die willkürlich abstürzen / nicht laden, weil irgend ein Bug in den Schleifenparametern zu einer Endlosschleife führt. ;-) Könnte man aber umgehen, wenn man die Zahl der Iterationen beschränkt. Dann ist maximal die einzelne Vorlage kaputt aber nicht die gesamte Seite. --TheRandomIP (Diskussion) 22:53, 25. Okt. 2021 (CEST)

Hat ein sehr großes Missbrauchspotenzial auf Wikis so groß wie die Wikipedia. Würde die WMF daher auch höchst wahrscheinlich nicht zulassen. --Zabe (Diskussion) 23:45, 25. Okt. 2021 (CEST)

Worin sollte das Missbrauchspotential bestehen? Mit Lua ist diese Funktionalität ohnehin seit langem schon vorhanden.--Cirdan ± 09:27, 26. Okt. 2021 (CEST)

Verbinden/Anlegen von bestehenden/neuen Wikidata-Objekten mit neu angelegten Artikeln/Kategorien unter Vermeidung von Dubletten

Was ist das Problem?

Das Problem, neu angelegte Artikel, Kategorien, Vorlagen, Navigationsleisten, Commonscats, etc. entweder

• mit bestehenden Wikidata-Objekten zu verbinden, sofern vorhanden oder
• neue Wikidata-Objekte anzulegen, sofern noch nicht vorhanden

für hunderte von täglich neu angelegten Artikeln, Kategorien, etc. (siehe Bild)

• bei gleichzeitiger möglichster Vermeidung von Dubletten unter den 95 Millionen vorhandenen Objekten (d:Special:Statistics)

wird seit Jahren immer wieder diskutiert, beispielsweise unter

• meta:Community Wishlist Survey 2021/Wikidata/Creation of new objects resp. connecting to existing objects while avoiding duplicates
• d:Wikidata:Contact_the_development_team/Archive/2020/09#Connecting_newly_created_articles_to_existing_objects_resp._creating_new_object_-_additional_step_when_creating_articles,_categories,_etc.
• d:User_talk:Mike_Peel/Archive_2#Matching_existing_wikidata_objects_with_unconnected_articles
• d:Wikidata:Requests_for_permissions/Bot/RegularBot_2
• d:Wikidata:Requests for permissions/Bot/Pi bot 19
• d:User_talk:Mike_Peel/Archive_3#Creation_of_categories_and_articles_after_14_days
• d:Topic:Vplpjjjpwfpmelfo
• d:Wikidata:Forum/Archiv/2020/07#Wikidata-Objekte_für_noch_nicht_zugordnete_Artikel,_Kategorien,_Vorlagen,_Listen,_Begriffsklärungen,_mit_bestehenden_Objekten_verbinden_bzw._neu_anlegen
• d:User_talk:Mike_Peel/Archive_3#Julie_von_Kästner
• d:User_talk:Mike_Peel/Archive_4#once_againg
• d:User_talk:Mike_Peel/Archive_3#Q105613214
• d:User_talk:MrProperLawAndOrder#Mathilde_Welcker_(Q94753027)_and_Mathilde_Welcker_(Q94753026)_are_identical
• Wikipedia:Kurier#Unterstützung_bei_der_Eingangskontrolle_und_Tätigkeiten_der_Qualitätssicherung_gesucht

uvam.

Wen betrifft das Problem besonders?

Alle Autorinnen und Autoren sowie alle Leserinnen und Leser, weil ein Artikel bei falscher/fehlender Zuordnung ggf. keine/falsche/fehlende Interwiki-Links zu anderen Sprachen bzw. Projekten (Wikisource, Commons, Wikivoyage, ...) hat

Lösungsvorschlag

Im Zuge der Diskussionen, wer, wann, wie (z.B. über verschiedene eindeutige IDs, wie Baudenkmal-IDs, GND, VIAF, LCCN, IMDb, Wfb, ...), ... die Artikel bestehenden Objekten zugeordnet werden bzw. neue Objekte angelegt werden sollen (durch einen Bot, manuell, teilweise durch Bot/teilweise manuell, ..., wann soll der Bot für welche Artikel laufen, etc.) wurde der Vorschlag gemacht, dem Autor/der Autorin nach dem Anlegen eines Artikels, einer (Commons)-Kategorie, etc. ein Pop-Up anzubieten, mit dem das Verbinden bzw. Anlegen eines Objektes ermöglicht werden, analog zu "Duplicate" in "PetScan".

Problem sind dabei unterschiedliche Sprachen, Bedeutungen, Schriftzeichen/Zeichensätze, usw., sodass ein Bot das Problem nur teilweise sinnvoll lösen kann. Viele Autoren/Autorinnen wissen nicht von der Existenz von Wikidata oder vergessen, mit einem Objekt zu verbinden bzw. ein Objekt zu erstellen oder es fehlt das entsprechende Wissen, wie dieser Schritt vorgenommen werden kann. Ein Pop-Up nach dem Anlegen eines Artikels, einer Kategorie, ... könnte den Autor/die Autorin daran erinnern, diese Aktivität noch durchzuführen.

Beispiel:

• https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro

• Außerdem sollten Übersetzungen automatisch mit jenen Artikel verbunden werden, aus denen die Übersetzung vorgenommen werden (auch nach Verschiebung vom Benutzernamensraum in den Artikelnamensraum)
• Soweit eindeutig möglich (z.B. anhand von IDs, wie CAS-Nummer, IMDb, GND, VIAF, ...) könnten Bots automatisch Anlegen/Verbinden übernehmen und nur im Zweifel/bei Nichteindeutigkeit diese Arbeit einem Benutzer überlassen
  Vorschlagende Person

M2k~dewiki (Diskussion) 14:48, 25. Okt. 2021 (CEST)

Diskussion

•  Pro --Fuchs B (Diskussion) 21:19, 31. Okt. 2021 (CET)
•  Pro Ja bitte! --Grizma (Diskussion) 10:15, 1. Nov. 2021 (CET)
•  Pro --Bärbel Miemietz (Diskussion) 20:58, 14. Nov. 2021 (CET)

Häufig fehlende Kategorien, Normdaten, Personendaten, Links auf BKLs, falsche Commonscat, etc. bei neu anlegten Artikeln bzw. vom BNR in den ANR verschobenen Artikeln

Was ist das Problem?

Bei neu angelegten Artikeln gibt es eine Reihe von häufig auftretenden Problemen:

• Benutzer:M2k~dewiki/Checklist
• Wikipedia:Kurier#Unterstützung_bei_der_Eingangskontrolle_und_Tätigkeiten_der_Qualitätssicherung_gesucht

Beispielsweise

• fehlen Kategorien (z.B. Helferlein "HotCat") inkl. Sortierschlüssel
• fehlen bei biografischen Artikel Personendaten und Normdaten (Benutzer:Schnark/js#personendaten.js, Benutzer:Schnark/js/personendaten)
• sind Rechtsschreibfehler enthalten (Wikipedia:Helferlein/Rechtschreibprüfung)
• sind Links auf BKLs enthalten (Wikipedia:Helferlein/Begriffsklärungs-Check)
• fehlt die Verbindung zu einem Wikidata-Objekt
• wird auf eine nicht vorhandene Commonscat verlinkt (oder es existiert eine Commonscat, diese wird aber nicht verlinkt, vorhandene Inhalte/Fotos nicht eingebunden)
• fehlt das reference-Tag im Abschnitt Einzelnachweise
• ist das Lemma in der Einleitung nicht hervorgehoben
• gibt es leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift

Wen betrifft das Problem besonders?

Alle Autorinnen und Autoren, Entlastung der Eingangkontrolle und Qualitätssicherung, mehr Effizienz und Konzentration auf inhaltliche Fehler statt Formalitäten

Lösungsvorschlag

• Daher sollten standardmäßig verschiedene Helferleins aktiviert werden, sofern dies noch nicht der Fall ist
• Benutzer sollten beim Speichern von neuen Artikeln
• sowie beim Verschieben von Artikel vom Benutzernamensraum in den Artikelnamensraum
  • an das Hinzufügen von Kategorien (und ggf. Personendaten, Normdaten, ...) erinnert werden bzw. dabei (z.B. mittels Wizard/Pop-Up) unterstützt werden
  • eventuell können passende Kategorien automatisch vorgeschlagen werden (siehe Schnark-Helferlein), sodass der Benutzer diese nur mehr bestätigen/korrigieren muss
  • an das Verbinden/Anlegen mit/von einem Wikidata-Objekt erinnert werden, z.B. https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro
  • Commonscats sollten beim Speichern auf Existenz überprüft werden, falls nicht vorhanden sollte eine Fehlermeldung erscheinen
  • ein fehlendes reference-Tag im Abschnitt Einzelnachweise sollte automatisch hinzugefügt werden
  • das Lemma in der Einleitung sollte ggf. automatisch hervorgehoben werden
  • könnte auf leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift beim Speichern hingewiesen werden
    Anmerkungen

Siehe auch

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Online-Typografiecheck_im_Editfenster_vor_Abschicken_eines_Edits,_z.B._wie_in_Word
  Vorschlagende Person

--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)

Diskussion

•  Pro --Fuchs B (Diskussion) 21:20, 31. Okt. 2021 (CET)
•  Pro Ähnliches Problem wie in den Commons mit dem Bild-Upload. Wär super, wenn da Hilfestellungen und Erinnerungen auftauchen würden, wenn diese Abschnitte fehlen. --Grizma (Diskussion) 10:14, 1. Nov. 2021 (CET)

Farbliche unterschiedliche Darstellung von missbilligten bzw. bevorzugten Rängen in Wikidata-Objekten

Was ist das Problem?

In Wikidata-Objekten sind Eigenschaften mit missbilligten Rängen optisch nicht von solchen mit bevorzugten oder normalen Rängen zu unterschieden, was zu Verwirrungen/Missverständnissen führen kann.

Beispielsweise:

• d:Topic:Wicllgduvgnw9lwy
• d:Wikidata:Forum#Q64168538
• Benutzer:M2k~dewiki/FAQ#missbilligter_Rang

Wen betrifft das Problem besonders?

Alle Benutzer von Wikidata

Lösungsvorschlag

Die missbilligten und bevorzugten Eigenschaften können mittels CSS farblich (z.B. rot für missbilligt bzw. grün für bevorzugt) gekennzeichnet werden.

Für das CSS siehe:

• Benutzer:M2k~dewiki/FAQ#missbilligter_Rang

Dies sollte für alle Benutzer standardmäßig aktiviert werden.

Vorschlagende Person

--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)

Diskussion

Online-Typografiecheck im Editfenster vor Abschicken eines Edits, z.B. wie in Word

Was ist das Problem?

Haufenweise grottige Typografie insbesondere im Fließtext

Wen betrifft das Problem besonders?

jeden Autor

Vorschlagende Person

Jbergner (Diskussion) 18:50, 25. Okt. 2021 (CEST)

Diskussion

Aus meiner Sicht ein Teilaspekt von Wikipedia:Technische Wünsche/Wunschparkplatz#Häufig fehlende_Kategorien, Normdaten, Personendaten, Links auf BKLs, falsche Commonscat, etc. bei neu anlegten Artikeln bzw. vom BNR in den ANR verschobenen Artikeln (Punkt Wikipedia:Helferlein/Rechtschreibprüfung), es sollten meiner Meinung nach darüber hinaus wie oben vorgeschlagen weitere Punkte beim Speichern geprüft, sofern möglich (halb)automatisch korrigiert/ergänzt oder dem Benutzer zur Korrektur gemeldet/vorgeschlagen werden. --M2k~dewiki (Diskussion) 19:37, 25. Okt. 2021 (CEST)

Aus meiner Sicht nicht mit etwas anderen verquicken, und dann bekommen wir gar nichts davon. Das ist mMn ein unabhängiges Thema, das immer die Glaubhaftigkeit der Texte betrifft. Viele glauben nicht, dass Qualität in der Sache dahintersteckt, wenn schon die Qualität der Darstellung nicht stimmt. --Jbergner (Diskussion) 10:57, 26. Okt. 2021 (CEST)

Ändern des SVG-Renderers, wie in phab:T283083 vorgeschlagen

Was ist das Problem?

Viele SVG-Grafiken können derzeit nicht richtig als PNG dargestellt werden (z.B. textPath, FlowRoot), dafür gibt bereits einige Problemsammlungen/Workarounds:

• Wikipedia:Probleme_mit_SVGs
• c:Librsvg_bugs
• c:Category:Pictures_showing_a_librsvg_bug

Wen betrifft das Problem besonders?

Grafiker, WP:Grafikwerkstatt, alle Autoren die Vektorgrafiken einbinden wollen (dafür müssen die richtig dargestellt werden)

Lösungsvorschlag

Statt libRsvg REsvg zum Rendern der SVGs verwenden, siehe phab:T40010

Anmerkungen

auf c:User:JoKalliauer/SVG_test_suites sind Vergleiche von rsvg, resvg, inkscape and batik. Resvg ist in allen Kategorien rsvg überlegen.

SVG	librsvg 2.50	resvg 0.14.0	Inkscape 1.0	batik 1.13; 1.14
W3C correctness	0,662	0,831	0,745	0,801
W3C cpu-time (512px)	1m 46,776s	1m 04,490s	7m 57,465s	6m 51,560s
RazrFalcon correctness	0.754	0.956	0.729	0.703
RazrFalcon time	4min 05sek	2min 30sek	46min 22sek	61min 29sek
featured correctness	0.92	1.00
featured time	5m 17,701s	4m 46,639s	15m 28,202s	11m 30,768s
time 2006-MediaWiki-collection (512px)	23.129s	9.551s	186.809s	87.313s
solved phab:-tasks relative to all tasks	0.55	0.88	0.78

Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 19:28, 25. Okt. 2021 (CEST)

Diskussion

Artikel mit Versionsgeschichte einfach kopieren

Was ist das Problem?

Häufig hat man das Problem, dass Artikel zu aktuellen Themen unüberschaubar lang werden oder man ältere Artikel anders aufteilen möchte. Dann möchte man Teile des Artikels in andere (neue) Artikel kopieren. Dabei ist aber das Urheberrecht zu beachten. Dazu gibt es aktuell Möglichkeiten des Versionsimports. Diese können aber nur von speziell technisch begabten Administratoren gemacht werden, und wenn ein Artikel mehr als 1000 Versionen hat, ist es eine mega Arbeit für den Administrator. Das ist technisch nicht mehr zeitgemäß und liegt an einer veralteten technischen Umsetzung in der Wikisoftware. Besonders bei den Artikelserien zur COVID-19-Pandemie ist das Problem sichtbar geworden. Dort haben Leute anfangs alles in einen Artikel geschrieben aber schnell wurde klar, dass man solch ein Weltereignis nicht bloß in einem Artikel beschreiben kann. Es folgten unzählige Auslagerungen mit mühsamen Versionsimport.

Oder wenn ich einen Artikel übersetzen möchte aus einer anderen Sprache, dann ist es genau das gleiche Prozedere.

Wen betrifft das Problem besonders?

Autoren, die sich um das Aufräumen der Erzeugnisse von Newsticker-Inklusionisten kümmern. Autoren, die die Artikellandschaft anders strukturieren wollen. Übersetzer.

Lösungsvorschlag

Wenn ich einen Artikel sehe, den ich gerne in mehrere Einzelartikel spalten möchte, dann möchte ich einen Knopf drücken, und schwupps hab ich einen zweiten Artikel unter anderem Namen, der exakt die gleiche Versionsgeschichte teilt. Einen Knopf. Mehr nicht. So wie man das z.B. von Versionsverwaltungstools wie git kennt. Dort können einzelne Commits (Edits) auch zwischen verschiedenen Branches (Lemma) geteilt werden. Wikipedia sollte genau so funktionieren.

Bonusfeatures: Mehrere Versionsgeschichten zusammenführen, Versionsgeschichte in eine andere Versionsgeschichte importieren usw. sollte auch mit einem Knopf möglich sein.

Technisch sollte das alles möglich sein, denn wenn man etwas manuell machen kann, kann man es auch automatisieren. Nur als Reminder: Computer sind turing-vollständig, also (fast) alles, was erdacht werden kann, kann auch programmiert werden. (Falls das Gegenargument käme "technisch nicht umsetzbar")

Anmerkungen

Aktuell werden Versionsimports manuell durchgeführt. Laut Statistik gab es im letzten Jahr 5824 Importe (etwa 485 pro Monat). Gehen wir mal davon aus, jeder Import dauert im Schnitt 5 Minuten (via.), dann werden pro Monat 40 Stunden ehrenamtliche Arbeitszeit derzeit verbraucht, um einen eigentlich voll-automatisierbaren Task zu erledigen. Wenn man das mal gescheit automatisiert, sollte sich das also recht schnell amortisieren. (Wenn man es zentral für alle Wikis macht sowieso)

Vorschlagende Person

--TheRandomIP (Diskussion) 23:09, 25. Okt. 2021 (CEST)

Diskussion

Das lässt sich vielleicht technisch, aber nicht organisatorisch bewerkstelligen. Ein Problem wäre, dass nur jemand mit Admin- oder Importrechten importieren darf, egal ob ein einzelner Knopf da ist oder nicht. Ein weiteres Problem wäre, dass Importoptionen nicht ausgewählt werden können, wie sie auf Special:Import beim XML-Upload einstellbar sind. Des Weiteren prüft der Importeur, inwieweit ein Import überhaupt notwendig ist, bevor er ihn ausübt, denn wir importieren einzig und allein aus lizenzrechtlichen Gründen. Außerdem muss darauf geachtet werden, dass sich bei der Vereinigung von Artikeln die Versionsgeschichten nicht überschneiden. Mit einem Knopf geht das leider nicht. Soll das Importieren künftig auch anderen Benutzern als Administratoren erlaubt werden, muss zuerst ein Meinungsbild durchlaufen werden, aber auch dann ist der einzelne Knopf zu wenig. – Doc Taxon • Disk. • 22:29, 27. Okt. 2021 (CEST)

Ich bin mir sicher, wenn man das mal gescheit mit GUI-Elementen implementiert, wenn man nicht mit XML-Dateien? herumfummeln muss, mit denen man im Zweifel wohl auch einiges kaputt machen kann, wenn es also "idiotensicher" ist, wird die Community den Vorteil schon erkennen.

Wenn ich mal träumen dürfte, Wikipedia müsste eigentlich intern mal die ganze Versionsverwaltung umschreiben, damit es funktioniert wie bei git. Damit so etwas wie eine Nicht-lineare Entwicklung möglich ist. Beliebig branchen (abzweigen), mergen (zusammenführen) usw. Das wär's doch. Überleg mal, man könnte "Pull Requests" für Artikel machen. Man könnte eine Änderung an einem Artikel zuerst in einem privaten Branch vorbereiten, und dann der Community als sogenanntes "Pull Requests" vorstellen. Und erst, wenn eine gewisse Mindestzahl an "Approvern" (formal) zugestimmt haben, darf gemergt werden. Damit könnte man umkämpfte Honey-Pots sofort entschärfen und würde die Ambiguität, ob nun ein Konsens herrscht, sofort auflösen. Wobei man das natürlich bei weniger umkämpften Artikeln nicht machen muss. Das würde die Wikipedia auf ein neues Level heben... Da müsste Wikipedia perspektivisch hin... der Use Case Artikel duplizieren wäre ein Anfang, den man sich vornehmen könnte. --TheRandomIP (Diskussion) 23:03, 27. Okt. 2021 (CEST)

An XML-Dateien fummelt man nicht rum. So kriegt man die dann auch nicht kaputt. Für ein Editieren per git müsstest Du so ziemlich die gesamte Software umschreiben. So kaputt, wie die jetzt schon ist, und so voll, wie die Datenbanken sind, kriegst Du wohl kaum eine Änderung diesbezüglich hin. Du müsstest die Software komplett neu schreiben und die Datenbankinhalte dann rüberschieben. Aber wer von unseren Benutzern ist schon geübt darin, mit Pull Request und Merge zu arbeiten? Du könntest ja mit einer Wikigitia einen ernstzunehmenden Wikipedia-Konkurrenten auf den Markt werfen. – Doc Taxon • Disk. • 05:27, 28. Okt. 2021 (CEST)

Visueller Editor performanter machen

Was ist das Problem?

Der Wikisyntax ist umständlich, man muss viel tippen, er ist nicht barrierefrei, ein Relikt aus den 00er Jahren, nicht für alle konzeptionell verständlich (Ältere Menschen usw.). Deshalb wurde vor einiger Zeit endlich der visuelle Editor vorgestellt.

Doch leider ist dieser immer noch viel zu langsam und träge, gerade bei längeren Artikeln nicht zu gebrauchen. z.B. versucht mal COVID-19-Pandemie mit dem visuellen Editor zu bearbeiten. Holt euch schon mal einen Kaffee. Also muss man wieder auf den Wikisyntax ausweichen.

Wen betrifft das Problem besonders?

Fast alle Autoren, die an größeren Artikeln arbeiten.

Lösungsvorschlag

Es gäbe mehrere Möglichkeiten, die man evaluieren könnte:

• Entwicklungszeit in das Profiling des visuellen Editor investieren, um ihn schneller zu machen. Sprich: Langsamen Code identifizieren, ihn durch performanteren Code ersetzen. Ihr denkt vielleicht, das bringt nichts? Doch! Durch Softwaretricks kann man manchmal die Laufzeit um den Faktor 100 und mehr reduzieren.
• Andere Webtechniken, Programmiersprachen evaluieren, z.B. WebAssembly. Vielleicht ist der Bottleneck auch die Skriptsprache, die aktuell verwendet wird, könnte ja sein.
• Möglichkeit einbauen, visuellen Editor auf einzelne Abschnitte beschränken zu können, so wie man es heute auch mit dem Wikisyntax kann.
• Visueller Editor mit optionalem "Fast Mode", bei dem z.B. Bilder und Tabellen (oder alles, was ihn langsam macht) nicht geladen werden, wenn man eh nur am Text arbeiten will.
  
  Vorschlagende Person

TheRandomIP (Diskussion) 22:30, 25. Okt. 2021 (CEST)

Diskussion

Der visuelle Editor ist auch noch nicht fertig und wurde bereits vor der Komplettierung bereitgestellt. Seit dem hakt die Weiterentwicklung, Fehlerbekämpfung, und es fehlt ein Team, das sich auf diesen Editor spezialisiert hat. Des Weiteren empfehle ich die Nutzung mit mobilen Phones, wie man es auch nehmen mag Vorlage:Smiley/Wartung/zwinker  Wer ernsthaft editieren will, nimmt den herkömmlichen Editor. – Doc Taxon • Disk. • 05:43, 28. Okt. 2021 (CEST)

Es gäbe wahrlich viel zu modernisieren in der Wikipedia... die sollen halt mal unsere Spendengelder zielgerichteter einsetzen. Anstatt für unnötige Dinge wie ein Code of Conduct, sollen die mal Geld für Programmierer ausgeben, die das weiterentwickeln. --TheRandomIP (Diskussion) 16:10, 28. Okt. 2021 (CEST)

Sowohl der VisualEditor als auch die zugehörige Komponente Parsoid werden bei der WMF jeweils von einem Team aktiv betreut und weiterentwickelt.--Cirdan ± 22:03, 28. Okt. 2021 (CEST)

Im Artikel Bundestagswahl 2021/Umfragen und Prognosen konnte ich schlicht keine Veränderungen durchführen (auch Quelltext nicht), weil der ARtikel wohl zu groß oder komplex war. Ich musste dann über die Disk alles regeln, war etwas anstrengend. --Fan-von-mir (Diskussion) 15:21, 31. Okt. 2021 (CET)

Die Quelltextbearbeitung solltest du hinbekommen, wenn du Syntaxhervorhebung ausschaltest. Also zumindest bei mir hat das dann geholfen. Darüber hab ich auch schon mal einen Rant verfasst. --TheRandomIP (Diskussion) 16:57, 31. Okt. 2021 (CET)

Der Visual Editor ist für große Artikel nicht geeignet, weil die Browser das schlichtweg nicht schaffen. Beim VE wurde die Kuh ohne Milch aufgezogen, und mit dem erzeugenden Ärger dann auf uns losgelassen. Das schlichtweg einfachste wäre eine kombinierte Edit-Umgebung gewesen, aber wer entwickelt schon lieber etwas weiter als etwas neues. Letzten Endes will ich damit sagen, dass die Benutzer viel zu wenig (bzw. nicht ausreichend oder gar gar nicht) in die Weiterentwicklung der Software, die sie selbst dauernd benutzen, einbezogen werden, und das finde ich wirklich sehr schade. – Doc Taxon • Disk. • 07:53, 1. Nov. 2021 (CET)

Ich hatte Syntyhervorhebung aus und war auch im Queltexteditor, also daran lags nicht – bei mir zumindest. --Fan-von-mir (Diskussion) 12:57, 1. Nov. 2021 (CET)

&nnbsp; als Synonym für &#8239;

Was ist das Problem?

Es scheint sehr großes Interesse zu geben, in Abkürzungen oder zwischen Zahl und Einheit das typografisch ›korrektere‹ schmale geschützte Leerzeichen zu verwenden. Siehe Verwendung der HTML-Entität oder die {{Nnbsp}}. Ersteres hat den Nachteil, dass es derartige Zahlen recht kryptisch erscheinen. Letzteres hat u. a. den Nachteil, dass dies im visuellen Editor kaputt erscheint. Auch war diese Vorlage lange Zeit fehlerhaft eingestellt und wird nun fehlerhaft als Tausendertrenner verwendet (dort sollte zwar ein größerer Zwischenraum erscheinen, beim kopieren darf aber kein Leerzeichen gesetzt werden).

Da HTML-Entitäten sowieso von der Software in die dezimale Form umgewandelt werden, siehe z. B. der Quelltext dieser Seite in den Abkürzungen, könnte die Software auch weitere benannte Enitäten erlauben, die so eigentlich nicht existieren. Ein Nachteil daran könnte sein, dass möglicherweise nicht alle Browser diese Entität kennen. Alle großen Browser und Browserengines, nahezu alle Schriftarten und auch viele ungewöhnliche Browser wie w3m scheinen damit umgehen zu können, insofern denke ich, dass das mehr als 99 % der Leser nicht betreffen wird.

Wen betrifft das Problem besonders?

Autor*innen, die Typographie manchmal etwas zu ernst nehmen

Lösungsvorschlag

An der Stelle, wo &nbsp; ersetzt wird ein Synonym für &nnbsp; hinzufügen:

Hinter Zeile 210 in [13] 'nnbsp' => 8239, // MediaWiki-specific named entity to prevent magic numbers einfügen

Falls das Problem veralteter Browser noch existiert, könnte man eine kompliziertere Lösung wählen, wo anhand des User-Agent statt &#8239; einfach &#160; gesetzt wird. Beispielsweise durch einsetzen eines <span class="nnbsp"></span> und über css und js clientseitig. Ich glaube aber, die einfachste Lösung wird am ehesten akzeptiert, da man bei einem einfach &…; kein komplexes Verhalten erwarten würde.

Anmerkungen

Weitere Entitäten zu benennen wäre auch überlegenswert, beispielsweise &lsqb; und &rsqb; für [ und ]. Ein gleichlautender Vorschlag wurde 2010 abgelehnt. Die Löschung von {{Nnbsp}} wurde im Übrigen deshalb abgelehnt, weil es noch keine bessere Lösung, wie z. B. ein &nnbsp; gibt und &#8239; ungeeignet ist, weil sich das niemand merken könne.[14].

Vorschlagende Person

— Sivizius (Diskussion) 13:12, 26. Okt. 2021 (CEST)

Diskussion

Ich hörte, es gebe mit Safari 13.1, einem durchaus modernen Browser Probleme. Kann das jemand bestätigen?— Sivizius (Diskussion) 10:19, 4. Jul. 2020 (CEST)

Ungewöhnliche Browser sollte man modernisieren, um aus der Inter-Nett-Steinzeit herauszukommen. Ansonsten unbedingt dafür! --Klaus-Peter (^aufund_davon) 10:39, 4. Jul. 2020 (CEST)

Wie würde es sich eigentlich mit dem visuellen Editor verhalten, wenn da ein &nnbsp; steht? Derzeit wird einfach &nnbsp; angezeigt, aber ich weiß nicht, ob das nach dieser Änderung ebenfalls bleibt.— Sivizius (Diskussion) 20:39, 7. Jul. 2020 (CEST)

Individuelle Anpassung des Bearbeitungsfensters

Was ist das Problem?

Beim Erstellen längerer Textblöcke oder Artikel ist es oft lästig, dass das Bearbeitungsfenster auf ca. die halbe Bildschirmhöhe begrenzt ist. Es wäre mMn nach günstiger wenn man die Höhe des Fensters individuell festlegen kann.

Wen betrifft das Problem besonders?

alle Benutzer, die längere Texte bearbeiten und die „alte Methode“ verwenden (ohne Visueller Editor)

Lösungsvorschlag

• der Parameter, der die Höhe definiert, sollte in den eigenen Grundeinstellungen (Profil) veränderbar sein. Das wird ja nur ein Zahlenwert sein? Das wäre dann immer wirksam (solange man/frau den Wert gleich lässt)
• Noch besser wäre ein Button in der Bearbeitungsleiste, der das Fenster größer macht (im jeweiligen Bearbeitungsschritt), zB durch die + / - Taste
• technisch aufwendigere aber noch praxisnähere Lösungen, wie zB Klicken eines Button und ziehen des unteren Bildrandes auf die gewünschte Höhe, wären das Optimum ;-)
  Vorschlagende Person

Hannes 24 (Diskussion) 13:44, 26. Okt. 2021 (CEST)

Diskussion

Oder Firefox benutzen :-) --TheRandomIP (Diskussion) 14:05, 26. Okt. 2021 (CEST)

solche Kommentare kannst Du dir eigentlich ersparen, die sind nicht sehr hilfreich. --Hannes 24 (Diskussion) 19:32, 26. Okt. 2021 (CEST)

Firefox fügt eben automatisch die Resize-Eigenschaft hinzu, wenn nicht schon vorhanden. Sicher, dass es bei dir nicht auch geht? Einfach mal in die untere rechte Ecke gehen und Textbox per Drag & Drop größer ziehen. Sollte bei allen modernen Browsern gehen.

Und ist eigentlich sogar schon automatisch aktiviert: https://de.wikipedia.org/w/load.php?lang=de&modules=ext.wikiEditor.styles&only=styles&skin=vector #wpTextbox1{line-height:1.5em;resize:vertical}

Sofern du nicht einen Uralt-Browser nutzt, oder einen anderen Wikipedia-Stil als Vektor, sollte das gehen.

Wikipedia sendet jedenfalls die richtigen Eigenschaften mit, wenn es nicht geht liegt es nicht an Wikipedia... --TheRandomIP (Diskussion) 20:23, 26. Okt. 2021 (CEST)

ich bin schon ein „älteres Semester“ und nutze einen „Uralt-Browser“, das ist reine Bequemlichkeit (keine Lust in der Arbeit/privat zwei versch Systeme merken zu müssen ;-) Wenn es technisch nicht geht, dann eben nicht. --Hannes 24 (Diskussion) 21:08, 26. Okt. 2021 (CEST)

Sicher wäre das technisch möglich, was du vorschlägst, aber wäre dann halt nur als "Krücke" für "Uralt-Browser" nützlich, während der Rest einfach die schon vorhandene Möglichkeit nutzt, die Textbox per Maus größer zu ziehen. --TheRandomIP (Diskussion) 00:47, 27. Okt. 2021 (CEST)

P.S. Der Internet Explorer, wie ich ihn liebe. "Resize? Nie gehört! Rot unterkringeln". Die Resize-Eigenschaft gibt es seit mehr als 10 Jahren. Der Firefox kann das seit Version 5. Der Internet Explorer kann das bis heute nicht. Firefox kann das seit 10 Jahren. Vielleicht sollte man die Wahl des Browsers doch nochmal überdenken ;-) --TheRandomIP (Diskussion) 01:02, 27. Okt. 2021 (CEST)

Danke für deine Erläuterungen. Ich verwende auch Chrome, aber du hast im Grunde recht, es wäre zu aufwändig. lG --Hannes 24 (Diskussion) 18:49, 28. Okt. 2021 (CEST)

hat sich erledigt, hab die Funktion jetzt (in chrome) entdeckt. ;-) --Hannes 24 (Diskussion) 19:34, 28. Okt. 2021 (CEST)

Reaktivierung der PDF-Buchfunktionalität

Was ist das Problem?

Die PDF-Buchfunktionalität (Erstellung von mehreren gesammelten PDFs mit einer Auswahl von Artikel inkl. Inhaltsverzeichnis etc.)

• https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality/de
• Wikipedia:Bücher

ist seit ein paar Jahren nicht mehr verfügbar

Die vorgeschlagene Alternative

• https://mediawiki2latex.wmflabs.org/

bietet hinsichtlich Lesbarkeit/Formatierung der erzeugten PDFs, Skalierbarkeit/Laufzeit leider nicht die Eigenschaften der ursprünglichen Funktionalität.

Wen betrifft das Problem besonders?

Wen betrifft das Problem besonders?

Lösungsvorschlag

Eine Reaktivierung wäre wünschenswert.

• Wikipedia:Fragen_zur_Wikipedia#Wikipedia-Bücher_im_BNR_???
• Wikipedia:Fragen_zur_Wikipedia#Projekt_gedruckte_Bücher
  Vorschlagende Person

--M2k~dewiki (Diskussion) 17:51, 26. Okt. 2021 (CEST)

Diskussion

Warum wurde das denn deaktiviert? --Fan-von-mir (Diskussion) 14:20, 29. Okt. 2021 (CEST)

Naja es wurde deaktiviert weil es keiner die Entwickler bezahlen wollte um die Software zu warten. Ich selbst könnte die Funktion mit den ursprünglichen Eingenschaften leicht herstellen, nur da man auch mich nicht dafür bezahlen würde, werde ich es lassen. Man muss lediglich das HTML etwas bereinigen und anschließend durch den PDF Generator von QtWebkit jagen. Eine C Bibliothek mit der sich dass HTML bereinigen lässt ist htmltidy. Das ist dann auch hinreichen performant wie ich bereits gemessen habe. Geschätzte Kosten 200000 EURO Viele Grüße --Dirk Hünniger (Diskussion) 17:41, 29. Okt. 2021 (CEST)

Meiner Meinung nach sind die genannten Kosten im Verhältnis zum Ergebnis unverhältnismäßig hoch. Ich persönlich habe aber auch keine so hohen Ansprüche an das Aussehen von Texten.--Hogü-456 (Diskussion) 11:29, 30. Okt. 2021 (CEST)

Danken für’s Sichten

Was ist das Problem?

Sichten ist of aufwendig und verantwortungsvoll. Ein Dankeschön ist eine nette Geste. (Sicherlich könnte ich in Einzelfällen auf die Disk des Sichters schreiben. Das finde ich im Normalfall aber zu aufwendig.)

Wen betrifft das Problem besonders?

Neue Wikipedianerinnen und Wikipedianer, die noch nicht Sichten dürfen.

Lösungsvorschlag

Schaltflächen für angemeldete Mitschreibende.

Vorschlagende Person

Mobil-Sockenpuppe (Diskussion) 06:38, 18. Jun. 2020 (CEST)

Diskussion

•  Pro --Fuchs B (Diskussion) 21:26, 31. Okt. 2021 (CET)
•  Pro --Himbeerbläuling (Diskussion) 22:23, 4. Nov. 2021 (CET)
•  Neutral Manchmal gibt es auch ungesichtete Beiträge, die niemand sichten oder revertieren mag. Wenn dann sich jemand intensiv damit beschäftigt hat und den gordischen Knoten durchtrennt hat, möchte man gern mal Dankbarkeit zeigen, auch wenn man die Sichterrechte schon hat. Auf der anderen Seite sind für mich andere Vorschläge einfach wichtiger. --Fan (Diskussion) 22:38, 4. Nov. 2021 (CET)

Dateien Hochladen und Verwalten

Beschreibung des Themas

Verbesserung der Tools zum Hochladen von Dateien und die Möglichkeit große Dateien(>4GiB) hochzuladen.

Begründung

Das Fotos und andere Medien zuverlässig und einfach hoch geladen werden können ist wichtig, um Inhalte zu illustrieren. Gibt es dabei Probleme werden neue Menschen die eigene Fotos beitragen wollen abgeschreckt und Menschen die große Mengen an meist eigenen Fotos beitragen wollen hören im schlimmsten Fall damit auf.

Was ist das Problem?

• Der UploadWizard funktioniert nicht zuverlässig. Es gibt Abbrüche, unklare Fehlermeldungen und lange Wartezeiten.
• Es gibt kein offizielles Uploadtool das auf dem System installiert werden kann, so dass, gerade für Massenuploads, eine Alternative besteht. Alle existierenden Tools werden von Freiwilligen gepflegt, die aber zum Teil gar nicht mehr dabei sein. Das GLAM Toolset wurde 2019 eingestellt.
• Dateien über 4GiB Größe können nicht hochgeladen werden.

Wen betrifft das Problem besonders?

Alle die Dateien hochladen, insbesondere große Dateien oder viele Dateien.

Lösungsvorschlag

• Behebung der Probleme des UploadWizard.
• Bau eines modernen Crossplattform Tools zum Massenupload als Nachfolger für das GLAM Toolset.
• Schaffung einer Möglichkeit zum Upload von Dateien größer als 4GiB.
  Vorschlagende Person

GPSLeo (Diskussion) 20:06, 26. Okt. 2021 (CEST)

Diskussion

Es gibt im UploadWizard seit Jahren unverändert einen Bug, der insbesondere neue oder mit Commons unerfahrene Benutzer unnötig in Stress versetzt. Bilder im Hochformat werden nicht erkannt und in der Vorschau im Querformat angezeigt. Manche Benutzer brechen dann mehrfach ab und versuchen es erneut oder denken ihr Bild sei defekt, obwohl es dann später korrekt angezeigt wird. Und der Wizzard nutzt aus irgendwelchen Gründen die mögliche Bandbreite für den Upload nicht und ist unnötig langsam. Manchmal muss auch ein Benutzer mal schlafen oder zur Arbeit oder möchte mehr Zeit für die Fotografie als für den Upload verbringen. Ein Dropdown Menü für die Dateibeschreibungsseite, das sich die zuvor eingegebenen Kategorien merkt und auch sonst noch ein paar Hilfen dabei hat. Eine Pausenfunktion fehlt auch. Nicht immer kann man stundenlang neben dem PC sitzen und warten, bis die letzte Datei nach drei Versuchen endlich hochgeladen ist. Dateien im Stash kann man nicht per Mausklick auswählen und nachträglich veröffentlichen, wenn es zwischendurch einen Verbindungsabbruch gab, gleichzeitig kann man das Bild auch nicht ein zweites Mal hochladen. Auch das bringt neue Benutzer an den Rand des Nervenzusammenbruchs. Und es ist ja nicht so, dass nur wenige das Programm benutzen. Gemäß einer alten einfachen Regel sollten die am meisten benutzten Werkzeuge oder wenn man will einer Software von besonders hochwertiger Qualität, besonders gebügelt, gestriegelt und geschniegelt werden und besonders stabil laufen und flutschen. Gelegentlich werden Dateien am Ende abgeschnitten, der Uploadwizzard merkt anscheinend nichts davon, oder wenn er es tut, so lässt er sich das nicht anmerken, was für den Benutzer das Gleiche ist. Erst Wochen später merkt das dann ein Bot, dass die letzten Zeilen des Bildes alle grau sind. Jetzt, um Himmels willen, wie hieß die Datei noch beim Hochladen? Das wäre mal eine nützliche Information, die nicht mehr angezeigt wird. Auch wenn man später eine Datei nachbearbeiten will, wäre so ein ursprünglicher Dateiname nützlich. Dann viel Spaß beim erneuten Suchen der Originaldatei. Suche nach Datum und Uhrzeit bleibt da noch. Das Tool ist im momentanen Zustand mit zwei bis drei von fünf möglichen Sternen gerade noch gut genug, dass die Benutzer nicht anfangen sich aus lauter Frust selbst zu verletzen oder ihren PC aus dem Fenster werfen wollen. Aber so mancher Fluch über den Wizzard bringt mir negatives Karma.--Giftzwerg 88 (Diskussion) 12:18, 31. Okt. 2021 (CET)

•  Pro --Fuchs B (Diskussion) 21:27, 31. Okt. 2021 (CET)
•  Pro -- Besonders Massenupload. So was wie Commonist. Ich muss sehr viele alte Dateien überschreiben. --Thirunavukkarasye-Raveendran (Diskussion) 13:10, 3. Nov. 2021 (CET)
•  Pro — WIr brauchen einen funktionierenden, nativen Uploader, der auch institutionelle Uploads unterstützt. --Gnom (Diskussion) Wikipedia grün machen! 20:23, 15. Nov. 2021 (CET)
•  Pro --Hubertl (Diskussion) 17:02, 14. Dez. 2021 (CET)

Bearbeitungskonflikt bereits bei der Vorschau erkennen

Beschreibung des Themas

Wenn man eine Seite mit dem Quelltexteditor bearbeitet, bemerkt man erst einen Bearbeitungskonflikt, wenn man auf Veröffentlichen geht.

Begründung

Verhindert mühevolles neuedieren oder umändern, besonders bei umfangreicheren Bearbeitungen

Was ist das Problem?

Wenn man nach einer Inhaltsänderung in einem Artikel im Quelltexteditor auf Veröffentlichen geht, wird dann erst ein aufgetretener Bearbeitungskonflikt angezeigt. Daraufhin muss man einzelne Textpassagen des eigenen Textes an die richtige Stelle wieder einfügen, was auch fehlererzeugend sein kann. Oft nutzt man bekanntlich zwischendurch die Vorschau. Bei einem frühzeitig angakündigten Bearbeitungskonflikt kann man die Bearbeitung neu starten und/oder der nachzubearbeitende Textumfang ist geringer.

Wen betrifft das Problem besonders?

Alle Autoren, die mit dem Quelltexteditor arbeiten

Lösungsvorschlag

Nach Druck auf den Vorschau-Button wird ein Hinweis eingeblendet, dass ein Bearbeitungskonflikt vorliegt

Anmerkungen

Ich kann nicht beurteilen, ob das technisch überhaupt möglich ist

Vorschlagende Person

Orgelputzer (Diskussion) 16:42, 27. Okt. 2021 (CEST)

Diskussion

So was hab ich mir auch schon so oft gewünscht, und mit Sicherheit sind wir beiden da nicht die einzigen. Eine Vorschau sollte vorausschauen, also auch auf eine Änderung des Artikels aufspringen, während jemand anders dran arbeitet. Nur so funktioniert die Erkennung und Bearbeitung von Bearbeitungskonflikten wirklich sinnvoll. – Doc Taxon • Disk. • 05:51, 28. Okt. 2021 (CEST)

•  Pro --Fuchs B (Diskussion) 21:28, 31. Okt. 2021 (CET)
•  Pro Zwar schon verbessert im Vergleich zu früher, als noch Textmengen unwiderruflich verloren waren, aber immer noch ein nerviges Problem. --Grizma (Diskussion) 10:10, 1. Nov. 2021 (CET)

Übernahme von Geokoordinaten nach Wikidata mit deutschem Zahlenformat

Was ist das Problem?

Bei der manuellen Übernahme von Geokoordinaten aus der deutschen Wikipedia nach Wikidata sollte auch das deutsche Zahlenformat akzeptiert werden. Bisher muss man manuell wandeln z.B. aus der Anzeige rechts oben 53° 31′ 44,43″ N, 10° 20′ 24,3″ O muss werden 53° 31′ 44.43″ N, 10° 20′ 24.3″ E , d.h. Punkt durch Komma ersetzen und O durch E - das könnte doch automatisch gehen.

Wen betrifft das Problem besonders?

Leute die mit Wikidata arbeiten, z.B. um Lagekarten zu erstellen. Wenn man 50 Objekte übernehmen will, nervt das etwas.

Lösungsvorschlag

Eine Möglichkeit wäre wenn die Software die eingegebenen Daten analysiert und das Format der Daten automatisch erkennt und passend wandelt. Noch schöner wäre, wenn es einen Button gäbe "Übernahme aus dt. Wikipedia" gleich mit Angabe der Fundstelle.

Vorschlagende Person

Gerd Fahrenhorst (Diskussion) 19.22, 27. Okt. 2021 (CEST)

Diskussion

Meines Wissens nutzen nicht nur die Deutschen Wikidata. Andere erdreisten sich ebenfalls, die dort eingetragenen Koordinaten zu verwenden. Die Variante mit 'E'st und Dezimalpunkt wird international verstanden und kann zudem von Programmen, die diese Daten nutzen, verarbeitet werden.

Als Alternative denkbar wäre die Dezimaldarstellung, aber auch die mag den Dezimalpunkt aber zumindest entfallen die Himmelsrichtungen.--Klaus-Peter (auf und davon) 08:39, 18. Mai 2020 (CEST)

Es geht mir zunächst einmal darum, dass das Copy&Paste aus der dt. Wikipedia funktioniert. Wie die internen numerischen Koordinaten hinterher angezeigt werden, ist eine ganz andere Frage. Falls man als Konfortlösung einen Button zu Übernahme vorsieht, könnte der natürlich die Sprachversion abfragen. -- Gerd Fahrenhorst (Diskussion) 21:23, 18. Mai 2020 (CEST)

Da das Format in GeoHack inzwischen oben rechts international dargestellt wird, ist es via dem kleinen ‚Umweg‘ flott realisierbar. Auch unten unter „Koordinaten für Kartendienste ...“ findet man alle verwertbaren Darstellungsfornmen. -→_KP^F_&Blabla← 19:46, 27. Okt. 2021 (CEST)

Quelltexterstellung des Visual Editor

Beschreibung des Themas

Der Visual Editor erstellt Quelltext, der nicht immer optimal ist und zu Edits im Quelltext führt, die überflüssig gemacht werden könnten, indem der Visual Editor verbessert würde.

Begründung

Weil es mich immer wieder nervt und es aber einmalig gelöst werden könnte. Es führt zu längeren Versionsgeschichten bzw. vielen Änderungen im Quelltext, die im Versionsunterschied angezeigt werden, aber eigentlich keine Relevanz haben.

Was ist das Problem?

Beispiel 1: Durchkopplung

• Ich verlinke ein Wort mit dem Visual Editor, z.B. „Aktivistin“ verlinke ich zu „Aktivist“.
• Im Quelltext steht dann aber [[Aktivist|Aktivistin]]
• besser wäre [[Aktivist]]in
• deshalb gehe ich dann nochmal in den Quelltext und passe das direkt an oder andere User ändern das händisch
• reelles Beispiel (betrifft den Wikilink zu DVD)
• siehe auch: Hilfe_Diskussion:Links#Durchkopplung

Beispiel 2 Mit typo wie Kursivschrift ist mir das auch schon mehrfach passiert. Das folgende Beispiel ist real, siehe hier

• [[MTV Unplugged – Live aus dem Hotel Atlantic|''MTV Unplugged – Live aus dem Hotel Atlantic'']] statt ''[[MTV Unplugged – Live aus dem Hotel Atlantic]]''

Beipiel 3

• Ich erstelle eine Liste im Visual Editor
• Im Quelltext wird zwischen dem Stern und dem ersten Buchstabe kein Leerzeichen eingefügt
• entweder ich oder andere machen das dann händisch im Quelltext, zum Beispiel hier
• siehe auch Hilfe_Diskussion:Listen#Leerzeichen_nach_*

Wen betrifft das Problem besonders?

Benutzer wie Aka und andere, denen ein möglichst gut lesbarer Quelltext wichtig ist. Nicht technisch versierte (und neue) User werden unnötig durch die Änderungen verwirrt.

Lösungsvorschlag

Der Visual Editor sollte die Verienfachung von Wikilinks automatisch erkennen und entsprechend anpassen und beim Erstellen von Listen/Aufzählungen u. ä. automatisch ein Leerzeichen hinter das Sternchen bzw. die Raute machen.

Anmerkungen

Von mir aus kann das in einen größeren Themenschwerpunkt gebündelt werden, zB mit:

• Online-Typografiecheck im Editfenster vor Abschicken eines Edits, z.B. wie in Word
• Visueller Editor performanter machen
• Individuelle Anpassung des Bearbeitungsfensters
• Bearbeitungskonflikt bereits bei der Vorschau erkennen

Ehrlich gesagt scheint mir der Aufwand nicht allzugroß zu sein. Ein paar Zeilen zur Stringbearbeitung sind zu schreiben und anschließend muss der Visual Editor geupdatet werden. Ich kann nicht nachvollziehen, warum das zu anderen Themen in Konkurrenz treten soll.

Vorschlagende Person

Fan-von-mir (Diskussion) 17:19, 28. Okt. 2021 (CEST)

Diskussion

Gemeldet in Phabricator
Task T50463

Gemeldet in Phabricator
Task T54240

Gemeldet in Phabricator
Task T247241

Die ersten beiden Fehler sind seit Jahren bekannt und aus verschiedenen Gründen offenbar schwer zu lösen: phab:T50463/phab:T54240 entsprechen Beispiel 1, phab:T247241 entspricht Beispiel 2 (dort wird auch eine Methode beschrieben, wie das Problem umgangen werden kann). Dein Beispiel drei kann ich nicht nachvollziehen. Wenn ich mit dem VisualEditor eine Liste anlege, werden Leerzeichen zwischen Stern und Listeneintrag eingefügt (Beispiel). Falls das bei dir anders ist: Kannst du mir eine Schritt-für-Schritt-Anleitung geben, damit ich den Fehler nachvollziehen kann? Grundsätzlich ist es so, dass der VisualEditor bzw. die Komponente Parsoid, die letztlich den Wikitext erzeugt, durch Altlasten in der Wikisyntax und dem nicht sauber entworfenen MediaWiki-Parser sehr eingeschränkt sind. Es ist also leider nicht mit „ein paar Zeilen zur Stringbearbeitung“ getan – allein schon, weil dann auch in Stellen des Quelltexts eingegriffen würde, die gar nicht bearbeitet wurden, was erst recht zu unleserlichen Versionsunterschieden führen würde. (Es ist schon fast eine Meisterleistung, dass der VisualEditor es von ganz wenigen Ausnahmen abgesehen schafft, nicht den Quelltext zu verändern, wenn man mit ihm eine Seite bearbeitet.)--Cirdan ± 21:54, 28. Okt. 2021 (CEST)

Vielen Dank für die Erläuterung! Dann kann das ja archiviert werden. --Fan-von-mir (Diskussion) 00:21, 29. Okt. 2021 (CEST)

Hallo Fan-von-mir, ich denke nicht, dass das unbedingt archiviert werden sollte. Ich wollte mit meinem Beitrag nur darauf hinweisen, dass die Probleme schon bekannt und kompliziert zu lösen sind – was man durchaus auch als Grund sehen könnte, sich darum zu kümmern, weil es im laufenden Entwicklungsbetrieb der Wikimedia Foundation offenbar nicht möglich ist. In jedem Fall fände ich es prima, wenn du entweder hier oder auf Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen das Problem mit den Leerzeichen bei Listen beschreiben könntest. Danke!--Cirdan ± 10:47, 29. Okt. 2021 (CEST)

Bei neue erstellten Listen im Visual Editor gibt es das Problem nicht. Problematisch wird es, wenn irgendwo innerhalb einer bereits existierenden Liste ein Stichpunkt mit Enter eingefügt wird:

(Stichpunkte 1, 2 und 3 existierten bereits vorher richtig formatiert.)

* Stichpunkt 1

*hinter „Stichpunkt 1“ war der Curor, anschließend Enter gedrückt so ist dieser Stichpunkt entstanden

*gleich nochmal Enter gedrückt

* Stichpunkt 2

* Stichpunkt 3 --Fan-von-mir (Diskussion) 14:38, 29. Okt. 2021 (CEST)

aktuelles Beispiel: [[15]] --Fan-von-mir (Diskussion) 15:18, 31. Okt. 2021 (CET)

Gemeldet in Phabricator
Task T294714

Gemeldet in Phabricator
Task T53654

@Fan-von-mir: Vielen Dank für die Beschreibung, ich konnte damit den Fehler nachvollziehen und habe ihn gemeldet.--Cirdan ± 23:12, 31. Okt. 2021 (CET)

Das Problem war tatsächlich schon in anderer Form bekannt.--Cirdan ± 17:33, 3. Nov. 2021 (CET)

•  Pro Ich hätte gerne nicht mehr so ein schlechtes Gewissen gegenüber Aka. --Fuchs B (Diskussion) 21:34, 31. Okt. 2021 (CET)
•  Pro Ja bitte! Manchmal denk ich nicht dran, nochmal den Quelltext zu checken und dann sind da diese blöden nowikis drin, die anderen Leuten wieder nur Arbeit machen. --Grizma (Diskussion) 10:07, 1. Nov. 2021 (CET)

Zwei-Faktor-Authentifizierung

Was ist das Problem?

Die Accounts normaler Nutzer*innen sind normalerweise lediglich durch ein Passwort geschützt. Die meisten Nutzer*innen müssen erst einen Antrag auf 2FA stellen. 2FA gehört mitlerweile zu den typischen Sicherheitsmaßnahmen und ist insbesondere bei Plattformen, die eine große Informationsmacht haben, wie die Wikipedia, wichtig.

Wen betrifft das Problem besonders?

Momentan wird scheinbar davon ausgegangen, dass das Hacken einer passiven oder aktiven Sichterin keinen großen Schaden anrichten kann. Aber gerade diese Accounts sind attraktiv für Personen, die nicht häufig abgerufende Artikel ändern wollen.

Lösungsvorschlag

Ettablieren von 2FA beim Erreichen vom passiven Sicherrecht

Anmerkungen

{{{Anmerkungen}}}

Vorschlagende Person

Jonsonr (Diskussion) 21:48, 28. Okt. 2021 (CEST)

Diskussion

Sehr sinnvoll. Besser Vorsicht als Nachsicht. Und Sicherheitsprobleme merkt man erst dann wenn es zu spät ist. Danke für den Voschlag! Ich werde es womöglich erst machen, wenn ich sanft dazu gezwungen werde und glaube auch, dass das anderen so geht. Also bitte bitte! Die 2FA ist ja technisch bereits ausgerollt, also muss man das „nur“ schrittweise als Pflicht einführen. So unter dem Motto. Du willst sichten? Dann hier entlang zur 2FA --Fan-von-mir (Diskussion) 14:24, 29. Okt. 2021 (CEST)

ZFA setzt voraus, dass man immer ein Handy mit sich rumschleppt. Das schließt alle aus, die ein Telefon zum Telefonieren haben und alle, die nur einen Desktop haben, ist also nicht barrierefrei. Man kann also nicht schnell mal im Internetcafe was machen, wenn der Handyakku leer ist und das Netzteil nicht dabei. Wenn, dann also höchstens als Opt-in. --Jbergner (Diskussion) 22:42, 30. Okt. 2021 (CEST)

Dies ist phab:T166622. Einer der Hauptgründe warum die Meisten für 2FA erst einen Antrag stellen müssen ist de-facto, dass T&S nicht mit Zurücksetzungsanträgen überschwemmt werden will, siehe phab:T180648#3975239 und Beschreibung von phab:T180896. --Zabe (Diskussion) 02:12, 31. Okt. 2021 (CET)

 Kontra Mich nervt die 2F-Authentifizierung kolossal. Bei Bankkonten und sonstigen kritischen Apps und Portalen ergibt das für mich noch einigermaßen Sinn, aber bitte nicht bei Wikipedia. Vor allem, wenn man unterwegs editiert oder an einem anderen Gerät. Es ist für Hacker wohl wenig lohnend, sich in WP-Nutzer:innenkonten einzuhacken ... --Grizma (Diskussion) 10:06, 1. Nov. 2021 (CET)

Wir sprechen nicht von einer Verpflichtung (soweit ich weiß), sondern davon, dass jeder der 2FA möchte, diese aktivieren kann. --Zabe (Diskussion) 17:56, 1. Nov. 2021 (CET)

Ich bin dagegen, das zur Pflicht zu machen. Ist hoffentlich nicht gemeint.--Himbeerbläuling (Diskussion) 22:21, 4. Nov. 2021 (CET)

Wikipedia-App

Beschreibung des Themas

Verbesserungsvorschläge zum Umgang mit der Wikipedia-App

Begründung

Ich nutze die Wikipedia-App und manches funktioniert mehr schlecht als recht. Ich würde mich freuen, wenn das besser funktioniert.

Was ist das Problem?

1) Gerne schaue ich mir mobil die Beobachtungsliste an. Leider funktioniert das nicht immer. Manchmal kommt stattdessen die Meldung, dass ich mich anmelden müsse, was Quatsch ist, weil ich ja eingeloggt bin. Z.B. kann ich immer direkt auf meine Benutzerdisk zugreifen, habe also Netz und die App weiß auch, dass ich das bin. Nach Neustart klappt es manchmal, manchmal nicht. Absolut zufälliges Auftreten. Manchmal hilft es auch ein paar Minuten zu warten und es erneut zu versuchen :D Bitte bugfixen

2) In der App kann man die sog. „Artikelbeschreibung“ ändern, aber nicht am PC. Wäre doch super, wenn man das auch ohne App erledigen könnte.

3)

• Ich bin auf der Beobachtungsliste und touche auf einen Edit auf einer Diskussionsseite
• Ich touche oben links auf „Diskussion:[Lemma]“ um mir den Kontext nochmal zu erschließen
• Dann stelle ich fest: Hm, ich möchte aber noch in den Artikel schauen. Oben rechts gibt es 3 Punkte und ich kann die „Seite im Browser ansehen“, warum nicht in der App? Ich möchte mir das aber ohne große Umweg in der App anschauen können.

Übrigens: Innerhalb der App kommt man von einem Artikel zur Diskussion, nur nicht andersherum

4) Leider sind Versionsgeschichten auch noch nicht in der App implementiert

5)

• Ich habe ein paar Artikel gelesen.
• Danach möchte ich auf meine Beobachtungsliste
• Das geht nur indem ich ganz oft auf zurück klicke, aber auch nicht zuviel, weil sich sonst die App schließt...

Fände ich schöner, wenn die 5 Symbole unten nicht einfach verschwinden, und man direkt zur Beobachtungsliste kommen kann.

6) [nachgetragen am 3. Nov. 2021] Beim Lesen gibt es quadratische Vorschaubilder. Diese werden gewöhnlich aus dem Hauptbild oben rechts des Artikels generiert, indem diese auf ein Quadrat zugeschnitten wird. Bei besonders breiten und v.a. hohen Bildern wird das manchmal ungünstig bis problematisch: Bei Porträts sieht man z.T. mehr Ausschnitt als Stirn. Gibt man „Annalena“ in die Suchleiste ein, sieht man nicht nur den oben etwas abgeschnittenen Kopf von Annalena Baerbock, man stößt auch beim runterscrollen auf Vorschaubilder von Sportlerinnen (Annalena Grätz, Anna-Lena Grönefeld, Anna-Lena Friedsam) von Mund bis zum Oberschenkel, also quasi ohne Kopf. Man sollte im Quelltext der Artikel einstellen können, welcher Ausschnitt des Hauptbildes angezeigt werden soll. Twitter nutzt soweit ich weiß da eine Automatik, die aber auch fehlerhaft und wohl auch teilweise recht schräg sein soll, also ich bin für händische Lösung. Vieleicht wäre auch ein erster Ansatz nicht einfach den mittleren Bildteil zu nehmen, sondern bei Menschen den oberen.

Wen betrifft das Problem besonders?

Alle Autoren, die die App nutzen.

Lösungsvorschlag

keine Ahnung, bin kein Software-Profi

Anmerkungen

Kann gerne mit anderen Themenschwerpunkten vereinigt werden.

Vorschlagende Person

Fan-von-mir (Diskussion) 15:00, 29. Okt. 2021 (CEST)

Diskussion

 Pro Die App nervt mich kolossal. Ich kann mich in die Logik nicht eindenken und verstehe bis heute nicht, wo ich welche Einstellung finde. Im Browserfenster am klassischen Monitor ist alles so schön übersichtlich eingerichtet, in der App kommt mensch erst nach Zwischenschritten in die Einstellungen oder findet überhaupt den Knopf für Login oder Logout. Finde die komplett verwirrend, weil sie nicht der Wikipedia-Logik folgt. --Grizma (Diskussion) 10:03, 1. Nov. 2021 (CET)

•  Pro Es werden in der App auch keine Rotlinks angezeigt. Die Bedienung ist unübersichtlich und oft mit sehr viel Zeitaufwand verbunden um die gewünschte Funktion zu finden. Auch nervt mich, dass manchmal, wenn ich im Smartphone-Browser einen Wikipedia-Artikel ansehe, sich automatisch dieselbe Seite in der App öffnet.

Bilder hochladen.

Beschreibung des Themas

Es geht um den Vorgang des Bilderhochladens bei Wikimedia Commons und das anschließende Hochladen bzw. Einbinden der Bilder in einen Wikipedia-Artikel.

Begründung

Das Thema ist wichtig, weil eine Bebilderung von Wikipedia-Artikeln wichtig ist, besonders bei biographischen Artikeln, aber auch generell um Themen anschaulich darzustellen, und Menschen ohne viel Technikkenntnis und Zeit sollten auch einfach Bilder hochladen können, um Artikel zu bereichern.

Probleme sind z.B.: Das aufwendige Prozedere, man muss sich bei Wikimedia Commons anmelden, um dort Bilder hochzuladen, arbeitet aber eigentlich bei Wikipedia.de an einem Artikel. D.h. man muss zwischen diesen beiden Plattformen hin- und herwechseln. Einfacher wäre es, wenn man direkt auf der Seite der Wikipedia z.B. unter seinem Benutzeraccount Bilder hochladen könnte und die dann automatisch auch bei Wikimedia Commons gespeichert werden. Zweitens ist das Hochladen von Bildern sehr zeitaufwendig, es ist zwar wichtig, alle notwendigen Angaben dort zu machen, aber vielleicht könnte man die Schritte dort verkürzen/vereinfachen. Drittens kann man bei Wikimedia Commons nicht einfach seine eigenen hochgeladenen Bilder löschen, falls man ausversehen einen Fehler gemacht hat, sondern muss erst einmal rausfinden, wo man sich an wen wenden muss, um das Bild löschen zu lassen. Viertens wäre es einfacher, wenn man die Bildbearbeitung (Zuschneiden usw.) bei Wikimedia Commons nicht extra einrichten müsste, sondern wenn sie bereits in der Menüleiste angezeigt wird oder wenn man beim Einbinden eines Bildes in einen Wikipedia-Artikel dort das Bild zuschneiden könnte.

Was ist das Problem?

Ich möchte z.B. einen Wikipedia-Artikel mit einem Bild bereichern. Hierzu muss ich mich bei Wikimedia Commons anmelden, alle Schritte durchlaufen (Urheberrecht angeben, Bild mehrmals mit Stichworten versehen usw.). Dann gehe ich wieder zu Wikipedia und dem Artikel zurück und lade das Bild hoch. Es ist insgesamt einfach ein sehr zeitaufwendiger Prozess.

Wen betrifft das Problem besonders?

Alle, die Bilder hochladen möchten.

Lösungsvorschlag

Z.B.: Bilderhochladen direkt bei Wikipedia ermöglichen (damit man nicht zwei Plattformen auf einmal offen hat) bzw. beide miteinander verknüpfen, sodass man nur bei Wikipedia.de angemeldet ist und die Bilder automatisch bei Wikimedia Commons gespeichert werden. Die Schritte beim Hochladen von Bildern könnten abgekürzt werden, nicht bei den Urheberrechtsangaben, sondern bei der Beschriftung und Verschlagwortung des Bildes. Bei der Übersicht der eigenen hochgeladen Bilder auch die Möglichkeit durch einen Button geben, das Bild zu löschen.

Anmerkungen

Ich hoffe, meine Angaben sind verständlich, ich habe leider nicht so viel Zeit, um das Formular so ausführlich auszufüllen und bin auch nicht so versiert mit dieser Quelltextansicht, hoffe aber, dass mein Problem verständlich geworden ist.

Vorschlagende Person

Auguste de Gouges (Diskussion) 14:08, 30. Okt. 2021 (CEST)

Diskussion

Du kannst jederzeit Bilder in der DE-Wiki hochladen. Dass dir eingeredet wird, das ginge nicht, ist nur, weil MAMA möchte, dass die Bilder weltweit und von jedem in jedem Wiki nutzbar sind. --Jbergner (Diskussion) 22:34, 30. Okt. 2021 (CEST)

•  Pro - Ich fände es wert, sich das Problem einmal genauer anzuschauen und zu versuchen, das Bilderhochladen aus einem Artikel heraus zu erleichtern. Viele Neulinge kommen über das Schreiben von Artikeln zur WP. Ihre Artikel möchten sie gerne bebildern (und die WP will Bilder), logisch, erst dann sind sie rund. Das Hochladen ist aber noch mal eine neue Komplexitätsstufe und vielleicht eine Hürde, vor der man zurückschreckt.

Vielleicht könnte man mit Drag&Drop arbeiten? Wenn man eine Bilddatei auf einen Artikel zieht, könnte ein Dialogfeld erscheinen in Richtung "Willst Du die dieses Bild verwenden? Lade es hier bei Commons hoch" und dann öffnet sich der UploadWizzard (und die Person ist automatisch in Commons angemeldet). Richtig toll wäre natürlich auch, wenn man einfach Bilder aus Commons in einen Artikel mit Drag&Drop ziehen könnte... Gruß --Fuchs B (Diskussion) 21:48, 31. Okt. 2021 (CET)

•  Pro - mobiles und analoges hochladen ist mit Lizenzgewirr bei nicht-eigenen Werken sehr abschreckend-und könne für eigene Bilder noch viel einfacher sein. Auch das einbinden könnte einfacher sein-also alles, was die Hürden von veröffentlichen und einbinden niedriger machen könnte. MfG --Alter Fritz 09:42, 1. Nov. 2021 (CET)
•  Pro Was fehlt, ist auch ein verständlicher Dialog, der unerfahrenere Nutzende durch das Procedere führt, insbesondere wenn ich noch Freigaben von Urheber:innen einholen und diese an permissions senden muss. So eine Art integrierte Checkliste oder Standard-Verfahren. Das müssen Menschen, die Anfänger:innen betreuen extrem aufwändig erklären. Wir sind schon am Überlegen, so eine Checkliste handzustricken, offenbar gibt es nirgends eine Schritt-für-Schritt-Anleitung, wie das Vorgehen ist, wenn Bilder Dritter hochgeladen werden. --Grizma (Diskussion) 09:54, 1. Nov. 2021 (CET)
•  Pro Ich als "Anfängerin" (obwohl jetzt mehr als ein Jahr aktiv) möchte das unterstützen. Ich hab mehrere Anläufe genommen, selbst Bilder hochzuladen oder die Rechte zu besorgen, hab es dann aber aufgegeben, weil es wirklich höllisch kompliziert ist. Bei einer Vereinfachung würde ich mich wieder mehr um Bilder kümmern, versprochen! --Helga Wiki (Diskussion) 12:57, 1. Nov. 2021 (CET)
•  Pro Wir brauchen einen funktionierenden, nativen Uploader, der auch institutionelle Nutzungen zulässt. --Gnom (Diskussion) Wikipedia grün machen! 20:25, 15. Nov. 2021 (CET)

"wieder editierbare" Bearbeitungszusammenfassungen

Beschreibung des Themas

Hilfe:Zusammenfassung und Quellen

Begründung

Ich bin mir sicher, dass ich nicht der Einzige bin, der eine Bearbeitung vornimmt und dann in der Bearbeitungszusammenfassung einen Tippfehler, einen grammatikalischen Fehler usw. bemerkt, und da diese nicht wieder editierbar sind, bleibt es für immer in dieser Form. Glaubt ihr, dass Bearbeitungszusammenfassungen wieder editierbar sein sollten? Ich weiß nicht, ob für unbegrenzte Zeit, für 24 Stunden, 60 Minuten oder vielleicht 10 Minuten nach der Bearbeitung, aber es wäre toll, wenn man die Bearbeitungszusammenfassungen einfach abändern könnte.

Was ist das Problem?

siehe oben

Wen betrifft das Problem besonders?

siehe oben

Vorschlagende Person

Degon Trojvil (Diskussion) 21:02, 30. Okt. 2021 (CEST)

Diskussion

 Kontra später nicht mehr verfälschbare Z&Q sind vor ihrer Speicherung der Zeitpunkt, sich in Ruhe zu überlegen, was man da getan hat und dass man dazu steht. Für jetzt und immer. --Jbergner (Diskussion) 22:31, 30. Okt. 2021 (CEST)

 Kontra die Korrektur von Tipp- oder Grammatikfehler in Zusammenfassungen sind unerheblich, wie aber Jbergner schon richtig betont, gibt es auch systemische Zusammenfassungen, die nicht verfälscht werden dürfen (z.B. Sperr-, Schutz- oder Entscheidungsbegründungen). Aber es gibt da durchaus noch mehr. – Doc Taxon • Disk. • 08:01, 1. Nov. 2021 (CET)

 Kontra Das ist ja nur interne Kurz-Info über gemachte Änderungen und kommt nicht an die Öffentlichkeit. --→_KP^F_&Blabla← 08:36, 1. Nov. 2021 (CET)

 Kontra Öffnet Tür und Tor für Verfälschungen. Selbst bei einem Zehn-Minuten-Zeitfenster. Man denke an einen Edit-War, in dem es Schlag-auf-Schlag geht. --Grizma (Diskussion) 09:57, 1. Nov. 2021 (CET)

 Pro Es ist möglicherweise schwierig, d.h. nicht leicht mit der vorhandenen Software zu lösen. Die obigen Contra-Argumente laufem m.M.n. darauf hinaus, dass die nachträglichen Änderungen sinnvoll dokumentiert werden müssten, was vermutlich nur möglich ist, wenn gleichzeitig eine (für den Artikelleser ungeänderte) neue Artikelversion geschaffen wird und dann die Version mit der feherhaften Zusammenfassungszeile versteckt wird. Das Anliegen wird aus den oben genannten Gründen wohl abgelehnt werden. Trotzdem ist es berechtigt und ich möchte es unterstützen: das Problem an sich existiert, es ist lästig und zumindest im Prinzip mit gewissem Aufwand (vermutlich Bestätigung durch einen Administrator) auch lösbar. Sehr ärgerliche Fehler (Tipp/Grammatik u.A.) in der Zusammenfassung hatte ich jedenfalls auch schon… --Nick B. (Diskussion) 13:23, 13. Nov. 2021 (CET)

 Pro sofern nur der Autor ändern kann. Da die Änderung selber unverändert bleibt kann ich das Problem beim Editwar nicht nachvollziehen. —Hfst (Diskussion) 09:04, 12. Dez. 2021 (CET)

Entrümpelung der Kategorien

Was ist das Problem?

Es gibt etliche überladene „Monster-Kategorien“

• Kategorie:Mann hat heute 696.646 Einträge.
• Kategorie:Frau ‚nur‘ 139.856, aber immer noch ziemlich unnütz.

Ich bin mir sicher, dass da nicht einmal alle erfasst und entsprechend kategorisiert sind.

Kategorie:Diverse könnte (immer noch) übersichtlich sein, gibt es aber nicht.

Das sind nur exemplarische Bespiele. So etwas findet sich in sehr vielen Themenkreisen.

Wen betrifft das Problem besonders?

Alle, insbesondere Suchende

Lösungsvorschlag

Ich schlage vor, die Anzahl der aller Kategorie-Einträge auf ein festzulegendes Höchstmaß zu begrenzen (über 2 Bildschirmseiten wird es nmuM schon zu viel). Sollte es sinnvoll sein, konnte man passende Unterkategorien Anlegen (‚Mann mit Bart‘, ‚Mann mit Glatze‘, ‚Mann der Geschichte‘, der Wirtschaft, Politik ...), die ggf. selbst wieder begrenzt werden und sich dann auf weitere Unterkategorien verzweigen.

Anmerkungen

Ich kann mir gut vorstellen, dass ein Bot alle relevanten Kategorie-Einträge pauschal löscht. Die Autoren und Beobachter werden dann schon sinnvolle Einträge in entsprechende Unterkategorien machen. Bleibt es aus, wird es nicht so wichtig und somit entbehrlich sein.

Vorschlagende Person

→_KP^F_&Blabla← 10:22, 31. Okt. 2021 (CET)

Diskussion

Hier falsch, kein "technischer Wunsch". --Jbergner (Diskussion) 10:28, 31. Okt. 2021 (CET)

Kann man das anders, als durch ‚technische‘ Eingriffe realisieren? Erbitte sachliche und realisierbare Hinweise auf ein entsprechendes Portal. --→_KP^F_&Blabla← 12:45, 31. Okt. 2021 (CET)

→Wikipedia:Projektdiskussion --Mabschaaf 15:27, 31. Okt. 2021 (CET)

Wohl keine technische Lösung möglich, dafür bräuchte es eine Restrukturierung, eine Mammut-Aufgabe. --Grizma (Diskussion) 09:58, 1. Nov. 2021 (CET)

Unabhängig einer technischen Lösung. Das ist so nicht erwünscht. Wir machen das bewusst so, damit die Schnittmengensuche funktioniert. Wenn du Schweizer Männer, die Fussballer sind und nebenbei auch Politiker waren, suchen möchtest, suchst du nach der Schnittmenge Kategorie:Mann, Kategorie:Schweizer, Kategorie:Fußballspieler (inkl. Unterkat.), Kategorie:Politiker (inkl. Unterkat.) und hast gleich alle. Mit deiner Lösung müsstest du, vorausahnend, dass jemand genau das möchte, eine Kategorie Kategoire:Männliche Fußballspieler Schweizer Nationalität, Politikerfunktion ausübend anlegen. --Filzstift (Diskussion) 12:03, 3. Nov. 2021 (CET)

Kann mich Kpfiwas Idee nur weitgehend anschließen. Diese ganze Kategosiererei ist völlig schwachsinnig und nur ein Zeichen bzw Ausdruck für typisch teutsches Schubladendenken. Habe die noch nie für irgend etwas gebrauchen können. Leser*innen aus dem RL werden da erst recht nix damit anfangen können. Aber die Kategosiererei ist natürlich heiß begehrt bei allen Querulanten und allen Quer-Querulanten und allen Trolls und allen selbsternannten Besserwissern etc. pp. Man kann dort eher unauffällig wochenlange Grabenkämpfe mit allem was das Herz begehrt, wie EWs, VMs usw vom Zaun brechen oder sich einmischen. Mein Wunsch an die Techniker*innen hier wäre einen Bot zu basteln der sämtliche Kategorien so wie die Links dazu aus der gesamten deWP raus putzt.--Ciao • Bestoernesto • ✉ 06:53, 4. Nov. 2021 (CET)

Vorlage bearbeiten im VisualEditor

Was ist das Problem?

Wenn ich eine Vorlage wie Mehrspaltige Liste oder Infobox bearbeite, muss ich in sehr kleine Felder z.T. komplexe Syntax einfügen.

Wen betrifft das Problem besonders?

Alle die Inhalte in Vorlagen editieren

Lösungsvorschlag

Es wäre optimal wenn die Bearbeitung von Vorlagen ohne eigenes Fenster sondern so wie im VisuEditor auch direkt an der Stelle vorgenommen werden könnte.

Anmerkungen

kann gerne mit anderen Abschnitten zusammengefasst werden.

Vorschlagende Person

Fan-von-mir (Diskussion) 15:59, 31. Okt. 2021 (CET)

Diskussion

Das Problem ist, dass Vorlagen das Thema der Technischen Wünsche in der letzten Runde war. Ich fände das auch prima, wenn im Visual Editor an Ort und Stelle bearbeitet werden könnte, gehe dann aber einfach in den Quelltext, was auch kein großer Aufwand ist. --Grizma (Diskussion) 10:00, 1. Nov. 2021 (CET)

Vereinfachte Eingabe von ähnlichen Einzelnachweisen

Was ist das Problem?

• Ich verwende in einem Artikel ein Buch und muss als Einzelnachweis unterschiedliche Seiten angeben
• Das Vorgehen nach hilfe:Einzelnachweise#Mehrfache Referenzierung desselben Werks mit verschiedenen Seitenangaben ist unpraktisch und fehleranfällig
• Letztlich möchte ich die Angaben zum Werk und die Angabe zum Fundort im Werk trennen

Wen betrifft das Problem besonders?

Schreibende

Lösungsvorschlag

Keine

Anmerkungen

Ich finde die Unterstützung zur Erstellung von Einzelnachweisen ist vorsintflutlich

Vorschlagende Person

Hfst (Diskussion) 12:15, 1. Nov. 2021 (CET)

Diskussion

In der englischsprachigen Wikipedia gibt es dazu eine Vorlage, die zum Verweis auf die Seite einer schon genannten Literaturstelle dient: das Template en:Template:Rp. Sie wird dort über 45.000 mal genutzt. Dann erscheint im Artikeltext die Seitennummer direkt nach dem hochgestellten Link zu Literaturangabe (z.B. ^[2]:53 verweist auf Seite 53 der Literatur [2]). Für diese Art des Verweises kenne ich kein Beispiel außerhalb der Wikipedia, d.h. das ist bei wissenschaftlichen Literaturangaben nicht etabliert. Aber ich finde, diese neue Methode hat durch die Knappheit der Angaben durchaus Eleganz. Wenn es auf Englisch funktioniert ist vermutlich die technische Übertragung auf die deutschen Seiten kein Problem.--Nick B. (Diskussion) 13:43, 13. Nov. 2021 (CET) Vielleicht etwa konkreter: bei LaTeX gebe ich einmal die bibliographischen Daten an. Und dann verweise ich auf das Dokument und kann als optionales Argument sowas wie „S.42“ ergänzen. Und dann steht da [63, S.42] also ähnlich wie oben beschrieben. Und das finde ich auch in ingenieurwissenschaftlichen Literatur. Was das Argument „nicht etabliert“ angeht, so ist auch das Verbot von „aaO“ oder „ebenda“ nicht etabliert; also also kein Argument. Diese oder eine ähnliche Bequemlichkeit wünsche ich mir.—Hfst (Diskussion) 15:48, 13. Nov. 2021 (CET)

 Pro Ich fände es prima, technische Unterstützung für eine einfache Seitenangabe zu haben. --Bärbel Miemietz (Diskussion) 21:12, 14. Nov. 2021 (CET)

Fehler beim Einfügen eines Wikipedia-Links in einen Text außerhalb von Wikipedia

Was ist das Problem?

Wikipedia-Link mit abschließender Klammer "verlieren" trotz mitkopierter abschließender Klammer ebendiese Klammer (sie wird zwar angezeigt, ist aber nicht unterstrichen und somit außerhalb des Links -> Effekt: Wird der WP-Link aufgerufen, kommt es zu einer Fehlermeldung und NICHT zum gewünschten Beitrag, da ja die abschließende Klammer fehlt.

Wen betrifft das Problem besonders?

Sehr viele von mir eingefügte Wikipedia-Links, wie etwa

• https://de.wikipedia.org/wiki/Pankow_(deutsche_Band)
• https://de.wikipedia.org/wiki/Markuskirche_(Leipzig)

Lösungsvorschlag

Keine Ahnung.

Anmerkungen

Vermutlich gibt es hier den "Vorführeffekt", dass alles klappt mit den beiden Beispiel-Links. Doch das ist ja in Wikipedia; das Problem tritt bei Texten außerhalb von Wikipedia, Wikimedia etc. auf ...

Vorschlagende Person

Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET) Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET)

Diskussion

Kannst du eine Schritt-für-Schritt-Anleitung geben, wie der Fehler reproduziert werden kann? In welchem Programm befindet sich der „Text außerhalb der Wikipedia“ und welchen Browser benutzt du?--Cirdan ± 20:06, 2. Nov. 2021 (CET)

Kann das nicht nachvollziehen. Habe beide URLs mal in ein MS-Office Dokument als auch in eine E-Mail, die ich anschließend an mich selbst schickte, eingefügt. In allen Fällen war der kompl. Link inkl. der schließenden Klammer unterstrichen und ließ sich auch ordnungsgemäß ohne Fehleranzeige aufrufen. Möglicherweise ist dir ja bei der Kopiererei irgendwie ein Leerzeichen vor die schließende Klammer geraten, dann wird sie auch von jeglicher Software nicht mehr als Bestandteil der URL wahrgenommen.--Ciao • Bestoernesto • ✉ 06:25, 4. Nov. 2021 (CET)

Unterdrückung automatisches Inhaltsverzeichnis auf Wikisource-Seiten

Was ist das Problem?

Bei Anlagen von Index-Seiten wird ab 4 Überschriften das Inhaltsverzeichnis automatisch generiert. Dies ist aber bei den Einzelseiten unnötig und nervt. Dies kann mit dem händischen Eintrag von __NOTOC__ in der Kopfzeile unterdrückt werden. Beispiel: s:Seite:Die Bereitung warmer und kalter Bowlen.pdf/86

Wen betrifft das Problem besonders?

Wikisource-Nutzer

Lösungsvorschlag

Anordnung eines Buttons in der Bearbeitungsseite auf der Bearbeitungsleiste, ähnlich zu den dort schon vorhandenen.

Anmerkungen

Wenn das Problem gelöst ist, kann sich der Bearbeiter/die Bearbeiterin mit den Rezepten auf der verlinkten Seite einen schönen Glühwein machen, die klassische Win-Win-Situation.

Vorschlagende Person

A. Wagner (Diskussion) 18:12, 2. Nov. 2021 (CET)

Diskussion

Ich kann das Problem nicht direkt nachvollziehen, auf der von dir verlinkten Seite sehe ich weder ein Inhaltsverzeichnis noch __NOTOC_ im Quelltext, aber ich kenne mich mit den Begriffen und der Systematik von Wikisource leider auch überhaupt nicht aus. Aber wäre es eine Lösung, die Sache umzudrehen, also nie ein Inhaltsverzeichnis zu zeigen, außer es wird per __TOC__ explizit gewünscht? Ich denke, das sollte man in MediaWiki ohne Änderungen an der Software konfigurieren können, indem man die Mindestzahl der Überschriften, ab der automatisch ein Inhaltsverzeichnis erzeugt wird, extrem hoch (quasi auf unendlich) einstellt.--Cirdan ± 20:05, 2. Nov. 2021 (CET)

Das __NOTOC__ steht in der sog. Kopfzeile, diese siehst Du, wenn Du die Seite bearbeitest: [16]. Ich nehme es hier s:Seite:Die Bereitung warmer und kalter Bowlen.pdf/87 jetzt mal raus, dann siehst Du das Ergebnis. --A. Wagner (Diskussion) 21:58, 2. Nov. 2021 (CET) PS: Dein Vorschlag, nie ein Inhaltsverzeichnis anzuzeigen, es sei denn, es wäre gewünscht, könnte für Wikisource praktikabel sein, denn wir brauchen das Inhaltsverzeichnis in Quellentexten nicht, da die Quelle original wiedergegeben werden muss. Sollten wir eins brauchen (z. B. in Themen- oder Autorenseiten), dann muss es mit __TOC__ erzeugt werden. Aber... falls so eine Änderung käme, müsste das dann in allen Seiten nachgeführt werden, wo es derzeit nicht vorhanden ist. Ein immenser, nicht zu realisierender Aufwand...--A. Wagner (Diskussion) 22:05, 2. Nov. 2021 (CET)

Deine Idee ist super, wenn man diese auf den Namensraum Seite: beschränkt. --A. Wagner (Diskussion) 12:47, 5. Nov. 2021 (CET)

Eigene Top-Level-Domain für alle Wikipedias

Was ist das Problem?

Die Wikipedia URLs sind ja grundsätzlich recht lang (xx.wikipedia.org/wiki/)). Es wäre sinnvoll eine Top-Level-Domain (z.B. .wp) als forwarder (nicht als shortener) für Wikipedias zu betreiben.

de.wp/Top-Level-Domain

wäre ja viel kürzer als :

de.wikipedia.org/wiki/Top-Level-Domain

Das wichtigste wäre dass man die kurze URL noch selber lesen (was mit bitly und co nicht möglich ist) und die URL, ähnlich wie ein hashtag oder einem interwiki, in den Satz einbauen kann, anstatt eine (short)-URL anzuhängen (egal ob auf twitter oder einer mail)

Der Legende nach ist unter dem #Grabhügel https://de.wp/Raknehaugen ein König zwischen zwei weißen Pferden begraben worden.

anstatt :

Der Legende nach ist unter dem #Grabhügel Raknehaugen ein König zwischen zwei weißen Pferden begraben worden. https://de.wikipedia.org/wiki/Raknehaugen

Wen betrifft das Problem besonders?

Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.

Lösungsvorschlag

Betreiben müsste diese TLD vermutlich die Wikimedia Foundation, ich denke technisch wäre das möglich.

Die ICANN will anscheinend 185.000 $ für eine sponsored TLD, aber vielleicht gibt es die TLD für ein nonprofit günstiger.

Ich bin darauf hingewiesen worden das die ICANN 2-stellige TLDs nur an Länder und die EU (.eu) vergibt, aber vielleicht bekommt man für eine sooo große "Webseite" und zentrale Ressource im Netz eine Ausnahme;)

Diese kurzen URLs sollen nicht die klassische URL (de.wikipedia.org/wiki/Top-Level-Domain) als canonical URL ersetzen, sondern nur darauf weiterleiten.

Anmerkungen

Ich habe diesen Vorschlag schon einmal auf der VereinDE-l und 2017 gestellt.

Auf meta.wikimedia.org gibt es einen Special:UrlShortener, dieser würde aber "unlesbare", wenn auch kurze, shortlinks erzeugen (https://w.wiki/4Kmi anstatt de.wp/Raknehaugen).

Vorschlagende Person

vanGore 18:55, 2. Nov. 2021 (CET)

Diskussion

Technische Wünsche 2017 Eigene Top-Level-Domain für alle Wikipedias

Bildbeschreibungen für Blinde (automatisiert) einbinden

Beschreibung des Themas

Bildbeschreibungen ermöglichen blinden und sehbeeinträchtigten Menschen Zugang zu bildhaften Darstellungen wie Gemälden, Fotografien, Diagrammen und Schaubildern. Bisher müssen diese Beschreibungen einzeln eingefügt werden.

Begründung

Alt-Texte (kurz für Alternativtexte) sind kurze Bildbeschreibungen, kurze sprachliche Übersetzungen visueller Inhalte im Internet, die blinden Benutzern von Hilfsmitteln wie Screenreadern anstelle des Bildes vorgelesen werden. Sie sind eine wichtige Bedingung für ein barrierefreies Internet. Sie können jedoch auch anstelle des Bildes im Browser angezeigt werden, wenn z. B. die Internetverbindung zu langsam ist, um das Bild zu laden, oder wenn Bildanzeige zum beschleunigten Laden oder Einsparen von Datenvolumen deaktiviert ist, sowie von textbasierten Browsern. Mit Alt-Text versehene Bilder können von Suchmaschinen besser gefunden werden.

Was ist das Problem?

Bildhafte Darstellungen wie Gemälden, Fotografien, Diagrammen und Schaubilder sind für blinde und sehbehinderte Menschen in Wikipediaartikeln oftmals nicht zugänglich. Die Bildbeschreibung (Alt-Text) muss momentan manuell im Quelltext zu den jeweiligen Bildern im Artikel eingetragen werden. Einfacher wäre es, wenn beispielsweise direkt beim Hochladen des Bildes/Fotos diese Möglichkeit gegeben wäre, welche dann von dort aus auch für andere Seiten/Artikel weiter verwendet werden können.

Wen betrifft das Problem besonders?

Blinde und Menschen mit Sehbehinderungen.

Lösungsvorschlag

Alt-Texte (kurz für Alternativtexte) automatisiert beim Hochladen der Bilder, Grafiken etc. in Form einer Vorlage, welche vielfach weiterverwendet werden kann, einbauen. Beispielsweise direkt im Hochladevorgang mit eigenem Feld, wie die reguläre Bildbeschreibung, der entsprechenden Medien. So wird ein Standart geschaffen und es muss nicht in jedem Artikel immer wieder neu diese Ergänzung manuell eingefügt werden. Ideal wäre, wenn direkt bei Commons ein Eingabefeld, wie auch für die reguläre Bildbeschreibung, dafür geschaffen werden könnte. So ließe sich das mehrfache Eingeben der Bildbeschreibung vermeiden und evtl. wird so auch ein Bewusstsein geschaffen, diese Möglichkeit zukünftig öfter zu nutzen.

Vorschlagende Person

Zartesbitter (Diskussion) 19:56, 3. Nov. 2021 (CET)

Diskussion

 Pro Top, ein Eingabefeld gleich in den Commons, so ist es immer hübsch im Fokus. Bin dafür.

 Pro Ich bin SEHR für eine klare, präzise, informative Bildbeschreibung, allerdings bin ich  Kontra noch eine weitere Beschreibung. Es gibt ja schon drei: eine Bescheibung, eine Kurzbeschreibung und eine "Motivauswahl"-Beschreibung bei den strukturierten Daten. Und das alles in mehreren Sprachen - so man es für sinnvoll hält. Lässt sich daraus vielleicht eine einzige Beschreibung machen? Und dann möglicherweise sogar technisch verhindern, dass eine Datei hochgeladen wird, die keine richtige Bildbeschreibung hat? --Bärbel Miemietz (Diskussion) 21:31, 14. Nov. 2021 (CET)

3-spaltig, bitte

Was ist das Problem?

Völlig leseunfreundlich

Wen betrifft das Problem besonders?

Jeden Leser/Leserin

Lösungsvorschlag

2 oder 3 Spalten einführen

Anmerkungen

Der Eindruck einer Seite erzählt von Unbeholfenheit

Vorschlagende Person

--Wikipus (Diskussion) 00:33, 4. Nov. 2021 (CET)

Diskussion

Den Schalter [Abrufstatistik] in die Liste der Werkzeuge in der linken Spalte integrieren

Was ist das Problem?

So gut wie auf allen Seiten (Artikel-, WP:-, Projekt, Hilfe-, Disk-Seiten etc.) gibt es in der schmalen linken Spalte (ich nenne sie "Dashboard") unter anderem auch eine kleine Werkzeugliste: Werkzeuge

• Links auf diese Seite
• Änderungen an verlinkten Seiten
• Datei hochladen
• Spezialseiten
• PermaLink
• Permalink (Artikel)
• Seiten­informationen
• Artikel zitieren
• Wikidata-Datenobjekt

Nur den Schalter "Links auf diese Seite" benötige und benutze ich immer wieder mal, den Rest so gut wie nie. Aber so richtig häufig, vor allem bei Diskussionen um das richtige Lemma oder bei Relevanz-Fragen in LAs benötige und benutze ich das Werkzeug bzw den Schalter [Abrufstatistik]. Dieses Tool befindet sich jedoch seltsamer Weise im tiefen Keller gaaanz unten auf jeder Seite und manch eine Seite ist ziemlich lang. Z.B.: beim Artikel Student muss ich 32 Bildschirmhöhen auf meinem Laptop nach unten scrollen, um dort an das Tool [Abrufstatistik] zu gelangen, bei Europäische Union 76 Bildschirmhöhen.

Wen betrifft das Problem besonders?

Zunächst natürlich alle Benutzer*innen, die aus welchen Gründen auch immer, das Werkzeug benutzen möchte. Für reine Leser*innen im RL sind alle aktuell angezeigten Werkzeuge in der Liste vermutlich völlig uninteressant. Aber wie häufig ein Artikel zu bestimmten Zeiten aufgerufen wird, würde sie dann vielleicht doch interessieren. Nur ahnen die natürlich nicht, dass es am untersten Ende der Seite einen Schalter dafür gibt.

Lösungsvorschlag

Für einen Webdesign versierten Menschen dürfte das Umpositionieren bzw Einreihen des Schalters in die vorhandene Werkzeugliste eine der leichtesten Übungen sein. Und da es wohl das einzige auch für reine Leser*innen interessante Werkzeug ist, würde ich es an die oberste Position noch vor [Links auf diese Seite] setzen.

Anmerkungen

Ausschließlich auf Seiten im ANR gibt es ganz unten neben [Abrufstatistik] auch noch ein Tool namens [Autoren]. Da diese ja bereits in der Versionsgeschichte feststellbar sind, hab ich da noch nie reingeschaut. Aber man kann dieses Tool bei der Gelegenheit natürlich auch nach in die Werkzeugliste verschieben, am besten an letzter Stelle

Vorschlagende Person

Ciao • Bestoernesto • ✉ 04:03, 4. Nov. 2021 (CET)

Diskussion

2 Anmerkungen, die vermutlich Gegenrede sind: (1) Ich habe auf meinem Schoßrechner (Laptop) eine Taste mit Aufschrift „Ende“, die bei mir das Scroll-Problem zufriedenstellend löst. (2) Die Funktionen „Autoren“ und „Abrufstatistik“ rufen so weit ich weiß einen externen Dienstleister auf, „Links auf diese Seite“ etc sind meines Wissens Wikimedia-intern, vielleicht macht das einen Unterschied. --Himbeerbläuling (Diskussion) 22:18, 4. Nov. 2021 (CET)

Beobachtungsliste als Email und Feed mit diff.

Beschreibung des Themas

Die Beobachtungsliste als Email, sowie der als feed enthält derzeit nur das Lemma, die Bearbeitungszusammenfassung und den Autor.

Es wäre besser beide format würden auch die Änderung an sich als diff mitliefern. Evtl als Zusatzoption mit unterschiedlichen Ausgabeformaten: normal diff (>), unified diff (+) oder der HTML-Tabelle wie in der Mediawiki Webansicht.

Begründung

Man kann bereits in der mail oder im feeditem den Änderungsinhalt sehen.

Was ist das Problem?

Man muss zusätzlich die Seite mit der diff Ansicht anklicken, das stört den Lesefluss in der mail oder im feedreader.

Wen betrifft das Problem besonders?

Alle mail und feed User.

Vorschlagende Person

greetz vanGore 13:54, 5. Nov. 2021 (CET)

Diskussion

Erleichterung für Neulinge

Beschreibung des Themas

Als langjähriger Editor habe ich mich an diverse Problemchen gewöhnt. Das aber schreckt neue Editoren ab. Sollte irgendetwas fehlen, wäre es gut eine Warnmeldung zu generieren, das Abspeichern aber trotzdem möglich sein. Noch besser wäre es, wenn dann an die Qualitätssicherung ein Hinweis weitergeleitet wird.

Begründung

Wikipedia lebt von Editoren. Gerade neue Editoren werden aber von Fehlermeldungen abgeschreckt

Automatisches einfügen von Weblinks bei Quellenangaben

Es sollten alle Dinge z.B Banner "Belege fehlen" oder "Qualitätssicherungsseite" usw. durch anklicken eingebunden werden können.

Was ist das Problem?

Beispiel Weblink Wysiwyg Editor Weblink einfügen

"Belegen" aufrufen

Link eingeben z.B https://www-baseball--reference-com.translate.goog/bullpen/Jürgen_Helmig

Ergebnis: Wir konnten kein Zitat für dich erstellen. Du kannst eines manuell erstellen, indem du den Reiter „Manuell“ oben benutzt.

Wenn dann der Ungeübte die Eingabemaske sieht gibt er oftmals auf

Wen betrifft das Problem besonders?

Neue Wikipedianer

Anmerkungen

Sicher gibt es noch andere Hürden für Einsteiger, eventuell können hier andere noch Beispiele dazu beitragen.

Leider hört man selten etwas von denen die sich abschrecken lassen. Wir müssten also aufmerksam sein und solche Dinge, die Routiniers inzwischen als normal empfinden hier zusammenfassen.

Vorschlagende Person

Knut Krüger (Diskussion) 16:02, 5. Nov. 2021 (CET)

Diskussion

Siehe auch

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Häufig fehlende ategorien, Normdaten, Personendaten, Links auf BKLs, falsche Commonscat, etc. bei neu anlegten Artikeln bzw. vom BNR in den ANR verschobenen Artikeln
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Online-Typografiecheck_im_Editfenster_vor_Abschicken_eines_Edits,_z.B._wie_in_Word
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten

--M2k~dewiki (Diskussion) 16:07, 5. Nov. 2021 (CET)

Fehler im VisualEditor beheben: Mängel des Editors für chemische Formeln

Was ist das Problem?

Der Formeleditor für chemische Formeln, den man im Werkzeug VisualEditor aufrufen kann (unter Einfügen > Mehr > Chemische Formel), hat eine Reihe von z.T. gravierenden Fehlern und fehlerhafter oder zumindest ungünstig gewählter Beispiele.

Es geht um ein Werkzeug, das bei der Erstellung korrekt gesetzter Formeln helfen soll. Da ist es schlecht, wenn das Werkzeug Beispiele zeigt, die zu falsche Ergebnissen führen. Da es um den korrekten Formelsatz geht, ist ein nicht hochgestelltes Minuszeichen (bei der Angabe einer Ladung) hier als schwerer Fehler zu werten. Didaktisch ist es mangelhaft, wenn die Beispiele fehlerhaft oder irreführend sind.

Beispielsweise versteht man unter dem Aggregatzustand eigentlich den temperaturbedingten Wechsel zwischen Fest, Flüssig und Gasförmig. Im Formeleditor finden sich aber nur Beispiele zum gelösten Zustand (mit (aq) als Bezeichnung für wässrige Lösung). Ein gravierender Fehler im Formeleditor ist in der Formel des gelösten Carbonats: Mit den Beispielen des Editors erhält man dafür ${\ce {CO3^2-{}_{(aq)}}}$, richtig wären ${\ce {CO3^{2-}{}_{(aq)}}}$ oder noch besser ${\ce {CO3^{2-}{}(aq)}}$. Eine umfangreiche Liste dieser und vieler weiterer Fehler und Verbesserungsmöglichkeiten habe ich im Juni 2020 dort bei den Rückmeldungen zum VisualEditor gemeldet. Da die genannten Probleme immer noch alle ungelöst sind melde ich sie hier.

Wen betrifft das Problem besonders?

Das Problem trifft Nutzer, die mit Hilfe des VisualEditors chemische Formeln oder Reaktionsgleichungen erstellen wollen. Es betrifft besonders die Nutzer, die wenig Erfahrung mit Formelsatz und mit der korrekten Schreibweise chemischer Formeln haben. Das sind vermutlich genau diejenigen, die die Formeln nicht als Quelltext schreiben, sondern dafür gerne ein Hilfswerkzeug nutzen wollen. Schlecht, wenn das Werkzeug mangelhaft ist.

Lösungsvorschlag

1. Fehlerhafte oder irreführende Beispiele und Beschriftungen bitte durch korrekte bzw. geeignetere ersetzen.

${\ce {Fe^3+}}$, ${\ce {Ti^4+}}$ oder ${\ce {Fe^13+}}$ statt ${\ce {Y^99+}}$ (nicht existentes Teilchen)

${\ce {^1_0n}}$ statt ${\ce {^{0}_{-1}n^{-}}}$ (nicht existentes Teilchen)

${\ce {Fe^{II}Fe^{III}2O4}}$ statt ${\ce {Fe^{II}Fe^{III}204}}$ (sinnvolle Formel statt Quatsch)

${\ce {Sb4O6}}$ oder ${\ce {Al2O3}}$ statt ${\ce {Sb2O3}}$ (zur didaktischen Verbesserung)

Ladungen statt Aufladungen

Weitere Punkte hier.

2. Fehlerhafte Beispiele wie ${\ce {nH2O}}$ (die Variable n sollte kursiv gesetzt werden) bitte entfernen, solange sie vom Editor nicht richtig dargestellt werden können. Das betrifft insbesonders aufrecht zu beschriftende Reaktionspfeile.

3. Für die Fälle, die mit dem chem-Tag problematisch sind, beispielsweise bei der Reaktionsgleichung $\mathrm {Hg^{2+}\xrightarrow {+I^{-}} HgI_{2}\xrightarrow {+I^{-}} [Hg^{II}I_{4}]^{2-}}$: wäre es sinnvoll und möglich, dass der Formeleditor sie – analog zur Arbeit mit Quelltext wie hier beschrieben – mit dem math-Tag setzt? Mit diesem erhält man auch den korrekten Formelsatz von $n\ \mathrm {H_{2}O}$.

4. Die schon lange bekannten technischen Probleme des chem-Tags beheben.

Anmerkungen

Wie hier bereits andiskutiert wurde lassen sich die Probleme in zwei Kategorien einteilen:

1.) ungünstige und fehlerhafte Beispiele und Beschriftungen und sprachliche Mängel, die man vermutlich relativ leicht verbessern könnte.

2.) Mängel, die auf technischen Problemen des chem-Tags beruhen. Diese lassen sich vermutlich nicht so leicht beheben. Dazu gehören beispielsweise die nicht problemlos funktionierenden aufrechten Beschriftungen von Pfeilen. Zu schlecht oder nicht funktionierenden Funktionen sollte man dann aber wenigstens keine Beispiele bringen.

Vorschlagende Person

Nick B. (Diskussion) 14:09, 13. Nov. 2021 (CET)

Diskussion

 Pro  — --Wilhelm (Diskussion) 09:10, 20. Nov. 2021 (CET)

Genaue Wortsuche, die Groß- und Kleinschreibung beachtet

Beschreibung des Themas

Ich suche Tippfehler. Oft muss ich dabei genau nach einer Schreibweise eines Wortes suchen und die Groß- und Kleinschreibung berücksichtigen. Die Such-Syntax ~"Wort" ist schon sehr hilfreich, unterscheidet jedoch nicht die Groß- und Kleinschreibung, so dass die Falschschreibung in vielen false positives untergeht und nicht effektiv gefunden wird.

Begründung

Textqualität trägt zur Reputation von Wikipedia bei. Sie steigt, wenn sich genaue Schreibweisen von Wörtern leicht finden lassen. Denn das ist die Voraussetzung für die Korrektur.

In Wikipedia wimmelt es von Tippfehlern (Zusammenerbeit statt Zusammenarbeit, Dictionery statt Dictionary, Seminer statt Seminar, völling statt völlig). Das sind Tausende. Zwar gibt es die Suchmöglichkeit im Volltext (insource:/völling/), aber oft ist der Server überlastet oder nach 30 Anfragen wird man nicht mehr bedient, weil das ja auch „teuer“ ist. Wikipedia nach ~"völling" durchsuchen geht hingegen fix, hilft meist schon, reicht oft nicht (Völling ist häufig und korrekt, völling nicht, geht aber im Suchergebnis unter).

Was ist das Problem?

• Häufig ist die Groß- und Kleinschreibung wichtig, z. B. bei einar statt einer. Da gibt die Suche dann tausend richtige Schreibungen des Vornamens Einar zurück – die eigentlich gesuchte Kleinschreibung lässt sich nicht effektiv finden.
• Ich suche (um im Beispiel zu bleiben) nach insource:/ einar /. Das dauert bestenfalls lange (zum Beispiel 20 Sekunden), oder es wird nur eine „Teilliste“ ausgegeben (0 Einträge), weil der Server überlastet ist. Je häufiger ich suche, desto weniger erfolgreich bin ich, weil offenbar die Priorität mit jeder insource-Anfrage herabgesetzt wird. Meine jetzige Lösung ist unbefriedigend: Ich suche lokal im Volltext (verlässlich, aber nur ein Wort in zwei Minuten, Lüfter springt an).

Wen betrifft das Problem besonders?

Betroffen ist insbesondere die Community, die sich um Textqualität sorgt.

Lösungsvorschlag

Für die genaue Wortsuche gibt es offenbar bereits eine Wortdatenbank, die die Groß-/Kleinschreibung nicht berücksichtigt. Es kann also nicht so aufwändig sein, eine weitere Wortdatenbank anzulegen, die Groß- und Kleinschreibung berücksichtigt, und diese über eine bestimmte Syntax (Vorschlag: ~~"suchtext") verfügbar zu machen. Oder das Ergebnis von ~"suchtext" (liefert Groß- und Kleinschreibung) wird nach Großschreibung bzw. Kleinschreibung gefiltert.

Vorschlagende Person

Frühlingsmädchen (Diskussion) 13:16, 14. Nov. 2021 (CET)

Diskussion

Tote Links (nach bestimmten Kriterien) ermitteln

Beschreibung des Themas

Es ist kein Geheimnis, dass die Wikipedia-Artikel jede Menge tote Links enthalten. Die Gründe dafür sind vielfältig und an dieser Stelle nicht relevant. Die Anzahl der toten Links wächst stetig, deren Pflege und Beseitigung hinkt aber hinterher.

Begründung

Der Fakt, dass man immer wieder auf veraltete Inhalte und nicht funktionierende Links in den Wikipedia-Artikeln stößt, trägt nicht zum Vertrauen in Wikipedia bei. Damit sie den verdienten Respekt und die Glaubwürdigkeit nicht verliert, sollen wir darauf achten, dass die Informationen immer aktuell und zuverlässig sind.

Was ist das Problem?

Ein konkretes Beispiel für das Problemausmaß könnte dieses Projekt des Teams Wikipedia Hannover dienen.

Alle vorhandenen Links (tot und funktionierend), die auf eine bestimmte Domain zeigen, kann man z. B. mithilfe dieses Tools ermitteln. Das wäre schon eine gute Hilfe, wenn der Bot richtig funktionieren würde. Die Ergebnisse werden als numerierte Liste dargestellt, 100 Treffer pro Seite. Das Problem ist, dass nur die erste Seite mit den Suchergebnissen angezeigt wird. Versucht man, weitere Treffer auf der nächsten Seite anzeigen zu lassen, klappt es nicht.

Bei unseren Wiki-Kollegen aus anderen großen Städten "vorbeigeschaut" muss ich feststellen, dass es da nicht besser aussieht. Z. B. fünf zufällig angeklickte Links, die mit dem giftbot ermittelt wurden, ergeben folgendes Bild:

• berlin.de – drei von fünf zufällig angeklickten Links: Fehler 404 (Seite nicht gefunden)

• hamburg.de – zwei von fünf: Fehler 404 (nicht gefunden)

• koeln.de – zwei von fünf: Fehler 404 (nicht gefunden)

• muenchen.de – fünf von fünf: Umleitung auf die Startseite (die Inhalte können also nicht mehr als Nachweis dienen)

• stuttgart.de – vier von fünf: Fehler 404 (nicht gefunden)

Wen betrifft das Problem besonders?

Sowohl alle Wikipedianer, die Weblinks als solche oder als Einzelnachweise verwenden als auch alle Nicht-Wikipedianer, die nach den verlässlichen Informationen auf den Wikipedia-Seiten suchen.

Lösungsvorschlag

Einen konfigurierbaren Bot programmieren, der nach toten Links unter Berücksichtigung von bestimmten Kriterien suchen kann.

Vorschlagende Person

tender tiger 🐯 18:09, 14. Nov. 2021 (CET) im Namen des Teams von Wikipedia:Hannover

Diskussion

Fortführung des Schwerpunktes "Leichter mit Vorlagen arbeiten"

Beschreibung des Themas

Als Hinweis für das Ausfüllen dieses Punktes (Beschreibung des Themas) wurde in diesem „Formular“ (Vorlage Themenvorschlag) Folgendes angemerkt:

• <!-- Bitte beschreibe, was du dir unter dem Themenschwerpunkt vorstellst. Bitte darauf achten, dass die Beschreibung so formuliert ist, sodass man sie auch ohne Fachkenntnis verstehen kann. -->

Damit ist ein großes Problem bereits angesprochen: Das Thema Vorlagen ist ohne Fachkenntnisse auf dem Gebiet der „Wikipedianologie“ nicht besonders gut zu verstehen. Da das Thema „Leichter mit Vorlagen arbeiten" bereits der Gewinner als Schwerpunkt für die Mühen des Teams Technische Wünsche in 2019 geworden ist, liegen Beschreibungen bereits vor:

• Wikipedia:Technische Wünsche/Topwünsche/Leichter mit Vorlagen arbeiten; dort eine Unterseite am 11. Dez. '19: oldid=194822419 – „Häufigst genannte Probleme“.

Einiges, was während der Laufzeit des Schwerpunkts herausgearbeitet wurde, ist bereits umgesetzt worden, bspw. Zeilennummerierung und farblich markierte Klammerpaare für Vorlagenprogrammierende. Anderes ist erst einmal nicht möglich gewesen, z. B. „Verbesserungen im Vorlagendokumentations-Editor“.

Begründung

• <!-- Warum ist das Thema wichtig? -->

Das Thema ist deshalb wichtig, weil es Vorlagen nun einmal gibt und weil sich Benutzer*innen, die einen Artikel bearbeiten wollen, es sich nicht aussuchen können, ob sie dort Vorlagen vorfinden oder nicht.

• <!-- Beschreibe jetzt noch MINDESTENS ZWEI PROBLEME, die deiner Ansicht nach zu diesem Themenschwerpunkt gehören. OHNE konkrete Beispiel-Probleme kann der Themenschwerpunkt NICHT zur Wahl gestellt werden. -->

Was ist das Problem?

Beispiel-Problem 1: Anmerkung in einer Infoboxen

Was möchtest du machen und warum?

Ich wollte im Artikel SARS-CoV-2 in der einleitenden „Infobox Virus“ einen Anmerkung bei einer Rubrik anbringen. In einer einfachen Tabelle würde man diese Anmerkung in der entsprechenden Zelle einfügen. In der Vorlage:Infobox Virus ist es ein Parameter, der anders heißt, nämlich Subspezies, als man das Ergebnis in der Infobox letztlich sieht: als Rubrik „Unterart“. Der sachliche Hintergrund für die Anmerkung ist der, dass es Subspezies bzw. Unterarten zwar in manchen Fällen geben könnte, dies aber beim Virus SARS-CoV-2 nicht der Fall ist.

Welche Schritte durchläufst du dabei?

Im konkreten Fall hatte ich mich dazu entschieden, die Gründe für die explizite Anmerkung und meine Vorgehensweise bei der Umsetzung auf der Diskussionsseite zu notieren (April 2021, später im Archiv: Diskussion:SARS-CoV-2/Archiv/2021/2#SARS-CoV-2, ICTV-CSG, Schwesterklade). Ich hatte eine Art „Lesezeichen“ (Vorlage:Anker) im ersten Beitrag unter dem Abschnitt angelegt, wobei die Texte unter den ersten fünf Sprungzielen von Virentaxonomie handeln. Unter dem nächsten Sprungziel steht eine Zusammenfassung, was ich warum vorhatte, Lesezeichen Fazit (zum Sprungziel: ...006), und dann folgen zwei Sprungziele,

• Lesezeichen Anmerkung in der Infobox (zum Sprungziel: ...007) und
• Lesezeichen Plan (zum Sprungziel: ...008).

Welche Probleme treten auf?

• Ich konnte den Visual Editor (WP:VE; H:VE) nicht wirklich direkt benutzen, da innerhalb eines Feldes für einen Parameter nur Wikitext funktioniert.
• Normalerweise kann man im VE die Belegen-Funktion nutzen, um eine Anmerkung als Referenz einzufügen. Die Funktion erstellt Tags in der Form <ref>...</ref> oder <ref name=":0">...</ref>. Bei einer Anmerkung in meinem Sinne, z. B. <ref name=":0" group="A">...</ref>, würden die drei Punkte (...) für jede Menge Text stehen, der eine Vorlageneinbindung für eine Infobox sehr unübersichtlich machen würde. Daher hatte ich die Referenz benannt und eine Kurzform in der Vorlage-Einbindung beim Parameter Subspezies gesetzt (<ref name="Anm-Schwesterkladen-CSG" group="A" />), während ich die Referenz mit ihrem Inhalt zwischen <reference ...> und </reference> platziert hatte.
• Die komplizierte Referenz für die Anmerkung in der Infobox lässt sich nicht besonders einfach warten, da sie im Fließtext nicht auftaucht. Im Fließtext bekäme man durch den VE ein Dialogfenster, wenn man auf die Referenz klickt, in einer Vorlage-Einbindung erscheint bloß ein Parameterfeld, in dem Wikitext ohne Syntax-Hervorhebung steht.

Beispiel-Problem 2: Dieses Abfrage-Formular

Was möchtest du machen und warum?

Ich möchte die Wikisyntax-Konstruktion, die ich beim Klick auf [ Themenschwerpunkt vorschlagen ] erhalte – und die als eine Art „Formular“ dient – ausgefüllt abschicken, um die Verlängerung des Themenschwerpunktes „Leichter mit Vorlagen Arbeiten“ anzuregen. Genau genommen möchte ich das Formular mittlerweile vermutlich nicht mehr abschicken, da es schon erlegt ist, wenn Du diesen Text vor Dir sieht.

Welche Schritte durchläufst du dabei?

Ich habe mir die Wikisyntax in maskierter Form auf eine Benutzerseite kopiert, um sie dort zu analysieren. Ich bin die einzelnen Punkte Schritt für Schritt durchgegangen und habe versucht, das Formular sinnvoll auszufüllen. Das habe ich mit dem VE erledigt. Nachdem ich meinte, mit der Vorbereitung fertig zu sein, habe ich die Textpassagen als Wikitext zu den einzelnen Parametern kopiert und die Vorlage abgeschickt.

Welche Probleme treten auf?

Da ich ganz gern den Text so sehe, wie er am Ende sein wird (WYSIWYG), nutze ich auch gern den VE. Bei einem Qelltexteditor, z. B. WikEd (Hilfe), hat man immerhin eine Vorschau. Bei einer Vorlage hat man weniger. Auch wenn ich die Texte vorbereite, weiß ich nie genau, welcher Code auf der Vorlage-Seite welchen Code auf der Einbindungs-Seite wie umsetzen wird. Vor allem verhalten sich irgendwelche Sonderzeichen oft für mich nicht eindeutig vorhersagbar. Bei der Vorlage (Themenvorschlag) ist zwar eine Vorschau möglich, ich muss aber Stück für Stück den auf einer Benutzerseite vorbereiteten Text übertragen und nachsehen.

Was ich auch ein wenig für eine Absurdität halte, ist die Diskussion, die innerhalb einer einzelnen Vorlage-Einbindung erfolgen soll, wobei jede und jeder eigentlich daran denken muss, die schließenden Klammer unterhalb ihres oder seines Beitrags zu platzieren.

Wikipedia:Technische_Wünsche/Topwünsche/Verbesserungen_im_Vorlagendokumentations-Editor

Wen betrifft das Problem besonders?

Den Wunsch, der hinter dem Schwerpunkt „Leichter mit Vorlagen arbeiten“ stand, könnte man als Problem so formulieren: „Mit Vorlagen zu arbeiten ist schwer“.

Das betrifft unterschiedlich Gruppen in verschiedenem Maße.

Unter: oldid=194822419 – „Häufigst genannte Probleme“ wurden zwei Gruppen definiert:

1. Primäre Zielgruppe: Personen, die an Vorlagen arbeiten;
2. Primäre Zielgruppe: Nutzende von Vorlagen.

Die Schwierigkeiten bestehen wohl vor allem bei den „Nutzenden von Vorlagen“, die mit dem zurecht kommen müssen, was da ist. Die „Personen, die an Vorlagen arbeiten“ können sich vermutlich häufiger selbst helfen. Es gibt natürlich auch Vorlagenprogrammierende, die auch Vorlageneinbindungen nutzen. Ich denke, die Pesonen, die den VE nutzen, würden am meisten profitieren, wenn das Thema in entsprechender Richtung weitergeführt würde.

Lösungsvorschlag

Weiterführung des Themas unter besonderer Berücksichtigung

• der Integration des Visual Editors und von
• Wikipedia:Technische_Wünsche/Topwünsche/Verbesserungen_im_Vorlagendokumentations-Editor.
  Anmerkungen

Das habe ich nicht verstanden:

<!-- Vorlage zur Erfassung von Problemen kopieren, um weitere hinzuzufügen. -->

Vorschlagende Person

Dirk123456 (Diskussion) 23:46, 14. Nov. 2021 (CET)

Diskussion

Tabellenedition

Was ist das Problem?

Ich habe den Termin im November um einige Tage verpasst, daher hier mein Vorschlag für 2023... Ich schlagen vor, dass die Erstellung und Bearbeitung von Tabellen weiter vereinfacht wird - in visuellen Modus ist zwar schon einiges möglich, aber vieles eben noch nicht, und in Quellcode ist es ein reiner Albtraum, besonders wenn es gilt, grosse Tabellen zu bearbeiten oder zu aktualisieren. Ist es nicht möglich einen an Excel oder andere Tabellenkalkulationsprogramme angelehnten Editor zu erstellen, der mehr Flexibilität bietet, um Tabellen zu bearbeiten (inklusive Formatierung von einzelnen Zellen oder Spalten/Zeilen (z.B. rechtsbündig, linksbündig, mittig, Ausrichtung auf Dezimalkomma, Farbgebung, etc), nachträgliche Sortierung, Einrücken, Fusionieren von Zellen, uvm). danke

Wen betrifft das Problem besonders? Jeder, der gelegentlich mit grossen Tabellen arbeitet und dabei nicht jedesmal langwierige Bearbeitung des Quellcodes riskieren will (und dabei oft auch zum Studium der WP-Dokumentation zur Arbeit mit Quellcodes gezwungen wird)

1. WP-Autoren, die Tabellen erstellen oder bearbeiten, die sowohl linksbündige Texte als auch mittige Bilder als auch rechtsbündige Zahlen spaltenweise fornmatieren müssen. Beispiele: Listen von Personen, von Städten oder Zeitreihen.--Wolfdietmann (Diskussion) 16:40, 9. Dez. 2021 (CET)
2. WP-Leser, die sich mit falsch formatierten Tabelleninhalten herumschagen müssen (weil deren Autoren sich verständlicherweise nicht die Mühe gegeben haben, die Tabellenzellen einzeln zu formatieren)--Wolfdietmann (Diskussion) 16:40, 9. Dez. 2021 (CET)

Lösungsvorschlag

1. Ergänzung des Visual Editor um die Funktion, Spalteninhalte zu formatieren. Die Bearbeitung von Spalten (Löschen, Verschieben) ist schon implementiert.--Wolfdietmann (Diskussion) 16:40, 9. Dez. 2021 (CET)
2. Editor erweitern, so dass der Funktionsumfang grösser ist - es sollten auch möglich sein, Einzelzellen zu bearbeiten und formatieren

Anmerkungen

Vorschlagende Person Stauffen (Diskussion) 22:14, 8. Dez. 2021 (CET)

Ich schließe mich an. Ich hatte den Termin um exakt einen Tag verpasst. Ich werde auch gern meinen Beitrag leisten, wenn die Detailspezifikation erarbeitet wird.--Wolfdietmann (Diskussion) 16:40, 9. Dez. 2021 (CET)

Diskussion @Stauffen: Danke für deine Einreichung. Es würde sehr helfen, wenn du noch die anderen Felder ausfüllst, die in der Vorlage „Problem für die Umfrage 2023 einreichen“ (erreichbar über die blaue Schaltfläche oben auf der Seite) enthalten sind. Ich hab die Felder hier schon mal ergänzt. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 13:29, 9. Dez. 2021 (CET)

Danke - habe dass erst jetzt gesehen (und auch etwas ergänzt) --Stauffen (Diskussion) 15:38, 2. Jan. 2022 (CET)

Zum Thema Tabellen gibt es auf jeden Fall Verbesserungsbedarf auch wenn der Visual Editor hier schon eine riesige Hilfe gegenüber dem Quelltexteditor ist und eigentlich Hauptgrund wieso ich ihn manchmal doch verwende - Ideen, teilweise schon grob erwähnt:

• Für Zahlen, Daten, etc. einfacher Vorlagen verwenden können (über eine ganze Spalte) oder am besten diese wie bei Excel formatieren zu können. Es ist mühsam 100 x Vorlage XYZ einzufügen und gleichzeitig braucht man diese fast immer
• evtl. Möglichkeit einer "Bildspalte" als weitere Formatierungsmöglichkeit - Bilder einzufügen geht ja ähnlich umständlich wie bei den Vorlagen nur einzeln und auch sie haben aber wie Zahlen typischerweise in einer Spalte immer die gleiche Formatierung. Einfügen wird man sie immer einzeln, aber Optionen wie die Bildgröße nur einmal pro Spalte definieren zu müssen wäre hilfreich. Diese könnte erst über die Formatierung der Spalte gesetzt (vorher Default-Optionen wie rahmenlos, mittig, sinnvolle Bildgröße von ca. 150px) und dann beim Einfügen eines Bildes in einer in der Spalte befindlichen Zelle automatisch vorgewählt, aber wo nötig dann noch angepasst werden.
• Zeilen verschieben: Nicht nur einzeln per Maus "Nach oben/unten verschieben" auswählen, sondern auch schneller per Tastenbefehl; Spezielleres, was man seltener braucht, aber wenn doch viel Zeit kostet: Tabellenzeilen spiegeln können, also Reihenfolge genau umkehren können ohne jede Zeile einzeln verschieben zu müssen. Auch Zeilen in Spalten und umgekehrt tauschen, falls beispielsweise eine Tabelle zu breit wird
• Sticky Header: Als weitere Formatierungsmöglichkeit, siehe Wunsch eins drunter

--Lupe (Diskussion) 21:01, 20. Sep. 2022 (CEST)

Fixierte Kopfzeilen in Tabellen

Was ist das Problem?

• Bei Tabellen mit vielen Einträgen ist beim Runterscrollen nicht mehr klar, was ein Wert bedeutet, da die Kopfzeile der Tabelle nicht mehr sichtbar ist.

Wen betrifft das Problem besonders?

Bei langen Tabellen, Beispielsweise bei Liste der Länder nach Vermögensverteilung

Lösungsvorschlag

Änlich wie die Option "Oberste Zeile fixieren bzw. einfrieren" in Tabellenkalkulationsprogrammen

Anmerkungen

Wurde wohl auch schon an folgenden Stellen erwähnt: Wikipedia:Verbesserungsvorschläge/Archiv/2020/Mai#Tabelle: fixierte Kopfzeile, phab:T42763, en:Wikipedia:Village pump (proposals)/Archive 172#Always Show Column Headers in Tables

Vorschlagende Person

R4nd0m1 (Diskussion) 11:03, 11. Dez. 2021 (CET)

Diskussion

• meinst du so wie hier: AC/DC/Diskografie#Studioalben? WikiFreibeuter ^Kontakt 14:44, 14. Dez. 2021 (CET)
• da gibt es eine Lösung, hab es in deinem Beispiel eingefügt --Lupe (Diskussion) 14:27, 16. Sep. 2022 (CEST)
  • H:Tabellen/Erweitert#tabelle-kopf-fixiert, funktioniert aber nicht mit dem neuen Vector-Skin. --FordPrefect42 (Diskussion) 16:46, 8. Okt. 2024 (CEST)

Bilder um 90° / 180° / 270° drehen

Was ist das Problem?

Ich möchte ein Bild einbinden, z.B. commons:File:SARS-CoV-2 (Corona) -Schnelltest.jpg. Da die Schrift so schlecht lesbar ist möchte ich das Bild bei der Anzeige um 90° drehen. Das geht lt. Hilfe Diskussion:Bilder/Archiv/5#Drehung eines vorhandenen Bildes um 180° bzw. ±90° ? nicht.

Wen betrifft das Problem besonders?

Autoren, die Bilder (mit Text) einbinden wollen

Lösungsvorschlag

"Parameter" der Art rotate=180?

Vorschlagende Person

Hfst (Diskussion) 21:05, 20. Dez. 2021 (CET)

Diskussion

Auf Wikimedia Commons kann man Bilder drehen (Option ist rechts direkt unter dem Bild, siehe "Wie kann ich ein Bild drehen?" [17])- ich hab das mal gemacht, dauert aber noch bis es ausgeführt wird. --Lupe (Diskussion) 21:23, 19. Jan. 2022 (CET)

Ich hab gedreht. Gruss --Nightflyer (Diskussion) 22:05, 19. Jan. 2022 (CET)

Wäre unnötig gewesen. Ich hoffe das wird jetzt nicht weitergedreht --Lupe (Diskussion) 22:29, 19. Jan. 2022 (CET)

Es ging mir auch nicht darum, dass in Commons zu drehen sondern bei der Darstellung im Artikel zu drehen.--Hfst (Diskussion) 15:03, 1. Dez. 2022 (CET)

Verschieben von einzelnen Abschnitten

Was ist das Problem?

Ich beschäftige mich hin und wieder mit der Abarbeitung von Redundanz-Altlasten. Dabei ist es das Prozedere zum Zusammenführen von Artikeln sehr aufwändig und nervig. Es wäre schön, wenn es eine simplere Lösung gäbe, als die Versionsgeschichte des Quellartikels in den Artikeltext des Zielartikels zu kopieren, dann wieder alles zurückzusetzen und am Ende den Lizenzhinweis auf die Diskussionsseite zu setzen.

Wen betrifft das Problem besonders?

Jeden, der sich mit der Auflösung von Redundanzen befasst. Insbesondere auf Neuautoren wirkt das Vorgehen abschreckend und stellt eine unnötige Hürde dar.

Lösungsvorschlag

Ich weiß nicht, ob das technisch möglich ist, aber eine elegante Lösung wäre imho die Möglichkeit, analog zum Verschieben von Seiten, auch einzelne Abschnitte verschieben zu können. Dies würde über einen entsprechenden Button neben den „bearbeiten“ und „Quelltext bearbeiten“ Buttons des jeweiligen Abschnitts gehen. Technisch würde der für den verschobenen Abschnitt relevante Teil der Versionsgeschichte des Quellartikels automatisch kopiert und in die Versionsgeschichte des Zielartikels eingepflegt werden; das einzige, was für den Verschiebenden zu tun bliebe, wäre, den Abschnitt an der richtigen Stelle des Zielartikels zu platzieren und ggf. an dessen Struktur anzupassen.

Anmerkungen

Der oben genannte Lösungsvorschlag würde auch das Auslagern von Artikelteilen erleichtern. Dass dafür kein Import mehr nötig wäre, könnte die Administratoren entlasten.

Vorschlagende Person

Gesellschaft von Gelehrten (Diskussion) 19:05, 19. Jan. 2022 (CET)

Diskussion

Ich bin zwar kein Softwareentwickler oder so, aber das dürfte meiner Einschätzung nach umsetzbar sein. Problematisch wird es halt, wenn der ganze Artikel inkl. des betreffenden Abschnitts bearbeitet wurde, da dann das ganze „Unnötige“ mitverschoben würde. --MfG – olivenmus • 🥏 • Beiträge • 21:12, 19. Jan. 2022 (CET)

Wp-Nachschlagungen während des Editierens, insbesondere bei der Erstellung neuer Artikel.

Was ist das Problem?

Während des Editierens, gerade bei Neu-Artikeln (weniger bei Korrekturen in vhd. Artikeln) entsteht öfters der Bedarf, im vorhandenen WP-Bestand etwas nachzuschauen, eine vorhandene bzw. fehlende Verlinkung eines Begriffs nachzuschlagen etc. Man muss dann immer das bisher Editierte abspeichern, das Gewünschte aufsuchen und klären, dann wieder die bisherige Bearbeitung fortsetzen. Leider recht umständlich und zeitraubend, und es werden gar manche, eigentlich unnötige Abspeicherungen notwendig. Könnte man nicht irgendwie die bisherige Eigen-Bearbeitung irgendwo parken, das Gesuchte nachschaun und dann direkt zur eigentlichen Arbeit zurückkehren? Selbstverständlich kann man das dann machen, wenn man eine 2., unabhängige Internet-Verbindung hat. Aber wer hat das schon?
Realistischerweise fürche ich, dass mein Wunsch (leider?) nicht umsetzbar ist. Oder vielleicht doch? Würde mich freuen!

Wen betrifft das Problem besonders?

Es ist eigentlich kein Problem im engeren Sinne. Profitieren könnten von einer solchen Möglichkeit sicher alle Neu-Ersteller*innen.

Lösungsvorschlag

Habe ich keinen - bin hier zu wenig technisch versiert.

Anmerkungen

keine weiteren.

Vorschlagende Person

--Johann Jakob Pfeifendeckel (Diskussion) 16:58, 24. Jan. 2022 (CET)

Diskussion

Man kann doch einfach in einem neuen Tab nachschlagen. Oder verstehe ich dich gerade falsch?-Gesellschaft von Gelehrten (Diskussion) 17:05, 24. Jan. 2022 (CET)

Oder noch geschickter in einer neuen Browser-Instanz. Dann kann man auch ganz fix mit ALT+TAB zwischen Fenstern wechseln. --FordPrefect42 (Diskussion) 16:14, 13. Apr. 2022 (CEST)

In dem Fenster eines Browsers können mehrere Wikipediaseiten gleichzeitig geöffnet sein. So kann man eine Seite bearbeiten und auf anderen Seiten nachschlagen.

Wie vorgeschlagen kann man das durch ein zweites Browserfenster oder durch ein zweites Browsertab lösen. In Firefox findet man das beispielsweise unter dem Menüpunkt „Datei“: Dort gibt es einmal den Punkt „neuer Tab“ oder den Punkt „neues Fenster“. Wahlweise geht es (sowohl in Firefox als auch in Microsoft Edge) auch mit den Tasten Strg+T bzw. Strg+N. Oder man öffnet einen neuen Tab (= Registerkarte) durch einen Mausklick auf das Pluszeichen. Siehe auch Tabbed Browsing. --Pseudoneu Anondeux Zweitnamensmann (Diskussion) 15:30, 10. Jun. 2022 (CEST)

Stadtbezeichnung Berlin

Eine Nutzerin meinte, für Berlin sollte eine Bezeichnungskonvention gelten. Das ist wichtig, weil viele Nutzer das hinschreiben, was ihnen gerade einfällt bei Berlin. Es ist aber von Bedeutung, ob jemand im Berlin des Reiches bis 1945, zwischen 1945 und 1949 in Berlin-Ost oder Berlin-West, zwischen 1949 und 1989 in Berlin-Hauptstat der DDR oder Westberlin und nach 1990 in Berlin geboren wurde oder gestorben ist. Ich bitte um Bearbeitung dieses Vorschlages. --BrThomas (Diskussion) 18:15, 28. Jan. 2022 (CET)

DeepL Implementierung

Was ist das Problem?

Keine Unterstüzung eines Übersetzungstools (z.B. DeepL) somit mühsame manuelle Arbeit (Artikel übersetzen, Quellen herraussuchen, ggf. passende Bilder einfügen, usw., usw.)

Wen betrifft das Problem besonders?

Wikipedia Benutzer die kein Übersetzungstool benutzen oder den Artikel nicht finden da sie nicht im andersprachigen Wikipedia nachschauen

Lösungsvorschlag

Erstellung einens Bots der z.B. englische Wikipedia-Artikel übersetzt und neue (im deutschsprachigem) erstellt.

Anmerkungen

Vllt. könnte noch einen Hinweis mit z.B. "Dieser Artikel wurde von Bot 'XY' auf DeepL übersetzt, falls irgendwelche Fehler (Grammatik, Falschangaben, usw.) vorhanden sind einfach ausbessern." erstellt werden. Auch könnten die Quellen dann vom ursprünglichen Artikel übernommen werden.

Vorschlagende Person

Nuzer (Diskussion) 00:29, 2. Feb. 2022 (CET)

Diskussion

Den Sinn dieses Vorschlags verstehe ich nicht. Ein Übersetzungstool kann man doch nur für Teilbereiche eines Artikels einsetzen. Und was heißt: "keine Unterstützung"? Na und? Ich kopiere die Textteile und gebe sie bei DeepL ein, kopiere die Übersetzung, wenn sie stimmt, zurück und habe den übersetzten Text, muss ich nur noch dran feilen. Dabei muss man schon ziemlich gut aufpassen, dass überhaupt richtig übersetzt wird, der Sinn also erhalten bleibt. Die Probleme der Übersetzer aus dem Englischen oder Französischen sind ganz andere, nur ist dafür hier wohl nicht der richtige Ort (Lokalisierung von Vorlagen, vor allem von Cite Web und dergleichen). --Cabanero (Diskussion) 17:37, 25. Nov. 2023 (CET)

Besondere Ereignisse wie Importe, Wechsel des Namensraums und Umbenennungen von Artikeln in der Versionsgeschichte kenntlich machen

Was ist das Problem?

Wenn Artikel von einem Ort an einen anderen überführt bzw. "importiert" oder anläßlich einer Umbenennung (Verschiebung) thematisch erweitert (oder reduziert) werden, wird die Versionsgeschichte am neuen Ort bzw. unter neuem Lemma nahtlos weitergeführt. Dies kommt wohl insbesondere vor, wenn Artikel aus dem Benutzernamensraum in den Artikelnamensraum überführt oder wenn fremdsprachige Artikel in die deutsche Wikipedia importiert und anschließend übersetzt werden.

Beim Durchsehen der Vereinsgeschichte weiß man dann nicht auf Anhieb, in welcher Episode des Artikels man sich befindet, was unter Umständen sehr verwirrend sein kann. Bei importierten und übersetzten Artikeln sind die Versionen vor dem Import dann in einer Fremdsprache verfasst, was zwar zunächst ebenso überraschend und verwirrend ist, aber immerhin darüber Auskunft gibt, dass man gerade eine Version betrachtet, die vor dem Import geschrieben wurde.

Zu einem solchen "Sprung" in der Versionsgeschichte kommt es aber auch, wenn zu einem bestimmten Zeitpunkt in der Vergangenheit entschieden wurde, zwei (speziellere) Artikel zu einem neuen Artikel unter einem etwas allgemeiner gefassten Lemma zusammenzuführen. Wenn dann einer der Artikel umbenannt (und der Inhalt des zweiten Artikels in diesen übernommen) wird, dann bleibt die Versionsgeschichte des umbenannten Artikels vollständig erhalten, ohne dass die Umbenennung und Erweiterung des Gegenstandsbereichs des Artikels an der Versionsgeschichte auf einfache Weise erkennbar wäre.

Wenn man in der Vereinsgeschichte solcher Artikel hin- und herspringt, kann man also nicht ohne weiteres feststellen, ob der Artikel zum betreffenden Zeitpunkt noch den engeren Gegenstandsbereich behandelte oder ob man schon die inhaltlich und thematisch erweiterte Fassung betrachtet.

Als interessanter (und nicht minder verwirrender) Nebeneffekt von Importen aus anderssprachigen Ausgaben der Wikipedia (welche regelmäßig die Versionsgeschichte enthalten), erscheinen dann die ursprünglichen Autoren, die in der deutschen Wikipedia eigentlich gar nicht aktiv sind, dann plötzlich bei uns mit eigener Beitragsliste. Siehe beispielsweise die Beitragslisten in der hiesigen Wikipedia Spezial:Beiträge/Timrollpickering und Spezial:Beiträge/BrownHairedGirl, die beide offenbar ausschließlich englischsprachige Bearbeitungen enthalten, die zusammen mit den zugehörigen Artikeln bei uns "importiert" worden sind.

Wen betrifft das Problem besonders?

Jede/n, die/der sich aus den unterschiedlichsten Gründen mit der Bearbeitungsgeschichte eines Artikels (oder der Beitragsliste von Autoren) befasst.

Lösungsvorschlag

Vielleicht wäre es denkbar, die Versionsgeschichte und die historischen Versionen eines Artikels vor dem Zeitpunkt des Imports, der Übertragung aus einem anderen Namensraum oder der Umbenennung durch eine anderen Hintergrundfarbe kenntlich zu machen?

Falls dies nicht für sinnvoll befunden wird, könnte alternativ der Zeitpunkt des Import, der Übertragung oder der Umbenennung in der Versionsgeschichte durch einen farbigen Balken oder Ähnliches hervorgehoben werden. Und beim Betrachten der vor diesem Zeitpunkt erstellten Versionen könnte im Kopfbereich ein entsprechender Hinweis erscheinen. Ähnlich etwa dem Hinweis "Achtung: Du bearbeitest nicht die aktuelle, sondern eine ältere Version dieser Seite." könnte ein Hinweis wie der folgende erscheinen: "Achtung: Du betrachtest eine Version dieser Seite, die vor der Verschiebung des Artikels in einen anderen Namensraum // dem Import aus einer andere (Sprach-)Ausgabe der Wikipedia // einer Umbenennung des Artikels erstellt wurde." Idealerweise noch mit der zusätzlichen Information: "Der Import fand am xx.xx.xx aus der englischsprachigen Wikipedia statt. // Die Verschiebung aus dem Benutzernamensraum geschah am xx.xx.xxx. // Die Umbenennung von xxxxx geschah am xx.xx.xxxx."

In den meisten Fällen hat die/der Ausführende bei der Bearbeitung einen entsprechenden Hinweis in die Zusammenfassungszeile geschrieben, so dass dieser der Versionsgeschichte zu entnehmen ist. Für alle Fälle und der besseren Übersicht halber sollte ein solcher, automatisch generierter Hinweis aber zusätzlich auch noch einmal am betreffenden Datum in besonders hervorgehobener Form in der Versionsgeschichte eingefügt werden.

Anmerkungen

Ich habe sicher noch Fälle übersehen, die ebenfalls zu einem "Bruch" in der Versionsgeschichte führen und freue mich über entsprechende Hinweise.

Falls zwei Artikel tatsächlich vereint werden können, führt dass dann ja sicherlich auch zu einem Zusammenstückeln der Versionsgeschichten ..

Zu diskutieren wäre vielleicht auch die Frage, ob geringfügige Änderungen des Lemmas, sowie solche, die nicht mit einer Änderung (z.B. Erweiterung oder Einschränkung) des Gegenstandsbereichs des Artikels verbunden sind, anders behandelt werden sollten und wie die Software dies erkennen könnte.

Vorschlagende Person

Kai Kemmann (Diskussion) - Verbessern statt löschen - 03:52, 11. Mär. 2022 (CET)

Diskussion

"der Zeitpunkt des Import, der Übertragung oder der Umbenennung in der Versionsgeschichte durch einen farbigen Balken oder Ähnliches hervorgehoben werden" - ein guter Vorschlag, kann ich nur unterstützen. Ich könnte mir eine fett hervorgehobene Zeile mit solchen Inhalten vorstellen.--Cabanero (Diskussion) 17:45, 25. Nov. 2023 (CET)

Zusammenfassungszeile zeitnah bearbeiten können

Was ist das Problem?

Heidiho Leute, Mir passiert es immer wieder, dass ich gewissenhafte Edits tätige, dann aber, im "Eifer" diese abzuspeichern, ich unten in der Zusammenfassungszeile schlampige Angaben bezüglich der Edits angebe (Zusammenfassungszeile ist halt nur so lala...aber klar, trotzdem wichtig!). Heißt also, dass ich mitunter richtige Angaben bei den Edits mache, ich in der Zusammenfassungszeile aber leider dann (schlampenbedingt) auch ab und zu mal Sachen schreibe, die meinen Edit-Angaben widersprechen. Dumm, klar...aber passiert der Erfahrung nach halt immer wieder. Kurzum...gebe mir bei der Zusammenfassungszeile nicht immer so recht mühe, was bei anderen Lesern zu widersprüchlichem Verstehen während der Lesung der betreffenden Zusammenfassungszeile in Bezug zu meinem da getätigten Edit führen könnte. Also frage ich mal, wie es wäre, wenn alle, die etwas abspeichern, vielleicht wenigstens noch 10 Min. lang die Möglichkeit hätten ihren Zusammenfassungszeilen-Beitrag zu bearbeiten? So könnten kleine, sagen wir mal Schusselfehler, seitens der Abspeichernden noch geändert werden, falls sie nicht ganz richtig waren und so besser von anderen verstanden werden.--Eddgel (Diskussion) 08:42, 13. Apr. 2022 (CEST) (Frage bereits auf Wikipedia:Fragen zur Wikipedia#Zusammenfassungszeile zeitnah bearbeiten können gestellt)

Wen betrifft das Problem besonders?

vermutlich fast alle

Lösungsvorschlag

Zusammenfassungszeile bearbeiten können

Vorschlagende Person

Eddgel (Diskussion) 16:17, 13. Apr. 2022 (CEST)

Diskussion

• Der BK dokumentiert von Benutzern unverfälschbar was geschrieben wurde, so wie auch jede Einzelversion einer Seite.
• Auch diese können nicht nachträglich manipuliert werden, lediglich durch Admins/OS unlesbar gemacht werden, aber es bleibt aus Transparenzgründen öffentlich sichtbar, dass es dort einmal eine Version, einen Bearbeitungskommentar oder eine Seite gegeben hatte.
• Würde man dieser schon hundertfach vorgetragenen Idee folgen, dann müsste jede einzelne Version des Bearbeitungskommentars mit Datum und Uhrzeit und änderndem Benutzerkonto nachvollziehbar in der Datenbank hinterlegt werden, und der ursprüngliche Bearbeitungskommentar wäre immer noch öffentlich lesbar.
• Andernfalls könnte ich was ganz Böses über ‎Eddgel in den Bearbeitungskommentar schreiben, verschiedene Leute anpingen, und danach wie vorgeschlagen in den 10 Minuten danach diese Version des Bearbeitungskommentars spurenlos verschwinden lassen und man könnte mir nichts nachweisen.
• Wenn aber in der Versionsgeschichte jetzt lauter einzelne Versionen mit unterschiedlichem Bearbeitungskommentar aufgelistet würden – ganau wem wäre nun mit dieser Idee gedient?
• Bereits vielfach global abgelehnt.
• Um das Gedaddel des Bearbeitungskommentars wird es keine neuen Seitenversionen mit Datum und Urzeit und identischem Inhalt geben; der Bearbeitungskommentar kommentiert den Inhalt und wenn am Inhalt nichts verändert wird gibt es auch keinen anderen Bearbeitungskommentar mit Datum und Urzeit und Benutzerkonto. Jeder Zeitstempel und jede Veränderung bedarf einer eigenen Seitenversion, einer eigenen Versionsnummer in der Datenbank und eines vollständigen neuen Inhalts.
• VG --PerfektesChaos 18:00, 13. Apr. 2022 (CEST)

OK, den Mehraufwand (Seiten extra abspeichern zu müssen) verstehe ich. Macht Sinn. Vielleicht könnte die Funktion ja nur für diejenigen zugänglich gemacht werden, die ihre eigenen Zusammenfassungszeilen bearbeiten wollen (mit keiner extra Abspeicherung sondern mit Überschreiben) und sonst niemanden? Aber wenn es keine gute Idee ist, nun gut, dann ist es auch OK.--Eddgel (Diskussion) 18:46, 13. Apr. 2022 (CEST)

Und nochmal von vorne:

• Jede Veränderung des Bearbeitungskommentars benötigt einen eigenen Eintrag in der Datenbank, einen eigenen Zeitstempel, bekommt eine eigene Versionsnummer für die inhaltliche Änderung.
• Jede dieser Veränderungen wird in der Versionsgeschichte einzeln und für alle nachlesbar aufgelistet.
• Wenn das nicht so wäre, dann könnten damit böse Sachen angestellt werden, wie bereits oben erläutert.
• Weil das aber nur die Versionsgeschichte aufbläht, ohne dass sich am Seiteninhalt etwas ändern soll, wird das bereits seit zwei Jahrzehnten als absolut unerwünscht abgelehnt.
• Jede Veränderung, jeder administrative Eingriff bekommt einen eigenen Eintrag in Versionsgeschichte oder Logbuch und wird nachvollziehbar öffentlich protokolliert. Weil wegen Transparenz.

VG --PerfektesChaos 20:35, 13. Apr. 2022 (CEST)

Man bräuchte dafür ein eigenes Logbuch, in dem alte und neue Version drin stehen, die History der Artikel würde dabei nicht aufgebläht werden. Man könnte nur seinen eigenen Kommentar bearbeiten (ggf. Ausnahmen für Admins) und hinter bearbeiteten Kommentare stünde ein Link zum Logbuch, damit äre es komplett transparent. Es würde damit zwar jeweils ein zusätzlicher Datenbankeintrag entstehen, das passiert aber bei jeder noch so kleinen Korrektur in Artikeln auch.

Alternativ ließe sich das auch mittels Nulledits bewerkstelligen, das wäre aber deutlich umständlicher. --Morten Haan 🫖 Wikipedia ist für Leser da 00:04, 14. Apr. 2022 (CEST)

gudn tach!

ich wuerde versuchen, an einer anderen stelle anzusetzen. wenn du, Eddgel, das problem haeufiger hast, dann versuch es bei dir lokal zu loesen, z.b. indem du dir per javascript verbietest, aenderungen abzuspeichern, wenn dein cursor nicht zuletzt im summary-feld war, oder so.

das haengt halt davon ab, wie du normalerweise vorgehst. also: wann (in welcher konstellation) genau passiert dir der fehler?

zudem wuerde ich bei der lokalen technischen loesung versuchen, eine "bestrafung" einzubauen, sodass du dir den fehler mit der zeit abgewoehnst (und nicht von deinem modifizierten interface abhaengig bist). -- seth 22:26, 18. Apr. 2022 (CEST)

Höhö, lustig. Das Problem bleibt trotzdem bestehen (auch bei anderen, die es nicht so wie ich ausdrücken würden). In den Artikeln editieren wir auch andauernd wegen Kleinigkeiten, was jedes Mal zu einer Extra-Abspeicherung führt (mit original Versionsgeschichte). Wieso das nicht auch bei der Zusammenfassungszeile so handhaben?--Eddgel (Diskussion) 07:55, 24. Apr. 2022 (CEST)

Die Möglichkeit, den Bearbeitungskommentar nachträglich zu verbessern habe ich mir auch schon gewünscht. Die von Morten Haan genannte Möglicheit eines separaten Logbuchs scheint mir eine elegante und sinnvolle Lösung, wenn dieses viele der oben genannten schwerwiegenden Probleme lösen könnte: Sämtliche Änderungen wären nach wie vor dokumentiert. Damit könnte man dem Mißbrauch einer Änderungsmöglichkeit entgegenwirken. Das Logbuch bräuchte wenig Speicherplatz, und in der Änderungshistorie könnte man die mangelhafte Zusammenfassung standarmäßig ausblenden.

Wenn die Änderung, wie PerfektesChaos oben schreibt, eine „hundertfach vorgetragenen Idee“ ist, sollte das zu denken geben. Dann würde ich davon ausgehen, dass sie mindestens tausendfach gewünscht wurde. Nicht jeder Wunsch kann erfüllt werden, auch das ist OK. Vielleicht ist es technisch wirklich kaum zu machen? --Pseudoneu Anondeux Zweitnamensmann (Diskussion) 13:04, 10. Jun. 2022 (CEST)

Missbrauchsmöglichkeiten würden stark eingedämmt, wenn nur der Autor der betreffenden Änderung (und evtl. Admins) die Zusammenfassungszeile bearbeiten könnten, und außerdem nur in einer sinnvoll bemessenen Zeit, vielleicht bis zu 24h nach der Editierung des Artikels. Ein Logbucheintrag o. dgl. ist mMn unnötig, wenn doch nur die Zusammenfassung geändert wird und der Artikel selbst nicht. Dadurch braucht es keinen zusätzlichen Speicherplatz, und nichts wird aufgebläht.--Megatherium (Diskussion) 20:03, 20. Sep. 2022 (CEST)

• So etwas hatte ich mir auch schon gewünscht und ich denke, wenn man es restriktiv handhaben würde, gäbe es auch kaum Missbrauchspotential. Mein Vorschlag wäre, dass der Verfasser eines Edits bis zu 10 Minuten nach dem Speichern seine eigene Zusammenfassungszeile noch bearbeiten kann, danach nicht mehr. Meinetwegen mit einem Logbuch für solche Änderungen (damit man nicht etwa jemanden beschimpfen und das dann spurlos rückgängig machen kann, wie von PerfektesChaos angesprochen), das müsste ja möglich sein. Würde ich doch recht vorteilhaft finden. Mir passiert es nicht oft, dass ich in der Zusammenfassungszeile danebenhaue, aber wenn, dann ärgert es mich doch - gerade eben z.B. bei diesem Edit. Da wollte ich eigentlich schreiben "Otto F. Walter leitete das literarische Programm des Verlags ab 1956", nun fehlt das Jahr. Gestumblindi 21:31, 23. Mai 2023 (CEST)

Filtern in Tabellen ermöglichen

Was ist das Problem?

Ich erstelle bzw. überarbeite gerade eine Tabelle, die aus inhaltlichen Gründen (leider) recht groß wird, um einen guten Überblick über ein bestimmtes Themengebiet zu erhalten. Es ist wünschenswert, die Tabelle nach verschiedenen Kriterien sortierbar zu halten, um die jeweils interessanten Informationen blockweise zusammenzuhalten. was durch eine geschickte Reihenfolge der angewendeten Sortierkriterien prinzipiell möglich, aber mühsam ist. Noch wünschenswerter wäre es, eine Filtermöglichkeit zu haben, um eine überschaubarere Teil-Tabelle anzuzeigen, die leichter zu handeln ist.

Wen betrifft das Problem besonders?

Alle, die aus großen Tabellen nach verschiedenen Kriterien interessierende Datenzusammenhänge auslesen möchten.

Lösungsvorschlag

Vorbild könnte die Schnellfilterfunktion aus Excel sein, d.h. Klick auf ein „Filter“-Icon in einer Zelle der Kopfleiste und dann Auswahl eines Zellenwertes in der betreffenden Spalte oder Eingabe eines Teilstreings. Die gefilterte Tabelle sollte idealerweise weiterhin sortierbar bleiben.

Vorschlagende Person

FordPrefect42 (Diskussion) 23:56, 1. Jun. 2022 (CEST)

Diskussion

Tabellen in einer Master-Tabelle zusammenfügen

Was ist das Problem?

Ein möglicher Umgang mit großen Datenmengen in Tabellen kann das Aufsplitten in Teiltabellen sein, die verschiedenen Artikeln gespeichert werden. Wünschenswert wäre eine Möglichkeit, die Teil-Tabellen (gleiche Tabellen-Struktur vorausgesetzt) dergestalt in einen Master-Artikel einzubinden, dass in der Ansicht eine virtuelle Gesamt-Tabelle entsteht. Sie sollte für den Leser wie eine einzige Tabelle erscheinen, also z.B. das Sortieren über die Teil-Tabellen hinweg ermöglichen.

Wen betrifft das Problem besonders?

Alle, die aus großen Tabellen nach verschiedenen Kriterien interessierende Datenzusammenhänge auslesen möchten.

Lösungsvorschlag

Kein konkretes Vorbild, aber die Idee ist den Master-Dokumenten aus MS Office entlehnt.

Anmerkungen

Der Wunsch könnte als Alternative zum vorigen Vorschlag #Filtern in Tabellen ermöglichen umgesetzt werden, oder auch mit diesem in Kombination.

Vorschlagende Person

FordPrefect42 (Diskussion) 00:10, 2. Jun. 2022 (CEST)

Diskussion

• Benutzer:Thiemo Kreuz (WMDE) hat mir auf der WikiCon den Hinweis gegeben, dass das per Vorlagen-Einbindung von Tabellenzeilen in <onlyinclude>-Tags auch mit Bordmitteln bereits funktioniert. Vielen Dank für den Tipp, ich probier's mal aus. --FordPrefect42 (Diskussion) 17:30, 8. Okt. 2024 (CEST)

Softwareunterstützung bei der schnellen und massenhaften Aktualisierung von Daten in Artikeln

Was ist das Problem?

Viele Angaben in Wikipedia-Artikeln veralten, beispielsweise Einwohnerzahlen von Städten oder Ländern. In Artikeln über Hochschulen veralten die Zahlen der Studierenden und der Dozenten. Oft gibt es Datenbanken, die die gewünschten Werte enthalten. Ich habe in Dutzenden Hochschulartikeln Werte aus Datenbanken eingefügt: Für Hochschulen in Großbritannien Daten aus der HESA-Datenbank (Higher Education Statistics Agency https://www.hesa.ac.uk/), für Hochschulen der USA Daten aus dem College Navigator des U.S. Department of Education (https://nces.ed.gov/collegenavigator/). Ein Großteil der Arbeit besteht im Suchen und Kopieren der Werte aus der Datenbank und im Einfügen in den passenden Artikel. Da es um hunderte Hochschulen geht, brauche ich Monate dafür, das manuell zu machen, und ehe ich fertig bin sind die Werte auch schon wieder veraltet. Könnte man das nicht automatisieren?

Ein Hauptproblem besteht natürlich darin, dass jede Datenbank anders aufgebaut ist, die der HESA anders als die US-Datenbank. Für jede Datenbank müsste man daher ein separates Auslesetool erstellen. Dann bräuchte man ein Tool, das die passenden Wikipedia-Artikel aufruft und die Daten einfügt, z.B. die Zahl der Studierenden in den Parameter „Studentenzahl“ in der Infobox Hochschule.

Wen betrifft das Problem besonders?

Ein Großteil der Wikipedia-Artikel enthält Daten, die veralten, und viele sind auch veraltet. Das Problem betrifft daher alle Leser. Unter den Autoren sind diejenigen besonders betroffen, die eine Liste aktueller Daten gefunden haben und diese bisher manuell in dutzende oder hunderte Artikel übertragen mussten. Zum Stiftungsvermögen der US-Hochschulen beispielsweise gibt es eine Liste mit Einträgen zu 706 Einrichtungen. Vermutlich hat die Hälfte davon einen deutschen Wikipedia-Eintrag.

Lösungsvorschlag

1. Tools, die Datenbanken abfragen, oder aus Excel-Tabellen oder Textdokumenten übernehmen könnten, wären hilfreich.

2. Tools, die Werte aus einer Datenliste (z.B. mit Hochschulnamen und Studierendenzahl) in betreffende Wikipedia-Artikel (jeweilige Hochschulen) übertragen könnten, wären nützlich. Neben dem Übertragen der Werte wäre auch eine automatische Erstellung eines Einzelnachweises zur Nennung der Quelle hilfreich. Im ersten Schritt geht es nur um Werte in Infoboxen, da deren Parameter definiert und bekannt sind und daher von Software leicht zu finden sind. Ein Traum für viel später wären dann auch Änderungen im Fließtext.

Anmerkungen

Bestimmt ist dieser Vorschlag nicht neu, ich könnte mir vorstellen, dass er z.B. im Zusammenhang mit Einwohnerzahlen schon gemacht wurde. Im Falle der USA gibt es dafür Daten vom United States Census Bureau, für Deutschland findet man Datentabellen und das Gemeindeverzeichnis-Informationssystem auf www.destatis.de. Muss man die Einwohnerzahlen wirklich jedesmal von Hand in den Artikel kopieren?

Solange die künstliche Intelligenz noch in den Kinderschuhen steckt, ist es völlig unrealistisch anzunehmen, dass solche Aktualisierungen vollständig von Software übernommen werden. Daher geht es mehr um Softwaretools, die Unterstützung leisten. Selbst wenn das automatische Auslesen von Online-Datenbanken noch nicht klappt, wäre eine Hilfe beim Einfügen (z.B. aus einer passend manuell erstellten Liste) auch dann gut, wenn man jeden Schritt noch überwachen und genehmigen müsste.

Vorschlagende Person

Pseudoneu Anondeux Zweitnamensmann (Diskussion) 12:19, 10. Jun. 2022 (CEST)

Diskussion

Was ich noch toll finde, wäre ein Quelltext-Tag, um sich verändernde Daten zu kennzeichnen und z. B. nach 5 Jahren zur Überprüfung in einer Liste zusammenzustellen. Oder hilfsweise einen Bot, der über reguläre Ausdrücke nach Anmerkungen der Form ,,(Stand xxxx)", ,,. Stand xxxx ", ,,(letzter Stand: xxxx)", "kürzlich", "nach aktuellem Stand" oder so sucht. Mathelerner (Diskussion) 22:51, 23. Jul. 2022 (CEST)

Alternativvorschlag: Pflege der Daten in den zugehörigen Wikidata-Objekten und Einbindung aus Wikidata über Vorlagen und Infoboxen (de:Benutzer:M2k~dewiki/FAQ#Wie_verwende_ich_in_Vorlagen_und_Infoboxen_Werte_aus_Wikidata?). --M2k~dewiki (Diskussion) 15:50, 5. Sep. 2022 (CEST)

Verbinden/Anlegen von bestehenden/neuen Wikidata-Objekten mit neu angelegten Artikeln/Kategorien unter Vermeidung von Dubletten

Was ist das Problem?

Das Problem, neu angelegte Artikel, Kategorien, Vorlagen, Navigationsleisten, Commonscats, etc. entweder

• mit bestehenden Wikidata-Objekten zu verbinden, sofern vorhanden oder
• neue Wikidata-Objekte anzulegen, sofern noch nicht vorhanden

für hunderte von täglich neu angelegten Artikeln, Kategorien, etc. (siehe Bild)

• bei gleichzeitiger möglichster Vermeidung von Dubletten unter den 100 Millionen vorhandenen Objekten (d:Special:Statistics)

wird seit Jahren immer wieder diskutiert, beispielsweise unter

• Wikipedia:Technische Wünsche/Wunschparkplatz#Verbinden/Anlegen von bestehenden/neuen Wikidata-Objekten mit neu angelegten Artikeln/Kategorien unter Vermeidung von Dubletten
• Special:Diff/216675021/216675917
• d:Wikidata talk:Events/Data Quality Days 2022#Discussion: Matching new Wikipedia articles to Wikidata items
• d:User talk:GZWDer#Content-free and wrong item you created
• meta:Community Wishlist Survey 2021/Wikidata/Creation of new objects resp. connecting to existing objects while avoiding duplicates
• meta:Community Wishlist Survey 2022/Wikidata/Creation of new objects resp. connecting to existing objects while avoiding duplicates
• meta:Community Wishlist Survey 2022/Wikidata/Autosuggest linking Wikidata item after creating an article
• d:Wikidata:Contact the development team/Archive/2020/09#Connecting newly created articles to existing objects resp. creating new object – additional step when creating articles, categories, etc.
• d:User talk:Mike Peel/Archive 2#Matching existing wikidata objects with unconnected articles
• d:Wikidata:Requests for permissions/Bot/RegularBot 2
• d:Wikidata:Requests for permissions/Bot/Pi bot 19
• d:User talk:Mike Peel/Archive 3#Creation of categories and articles after 14 days
• d:Topic:Vplpjjjpwfpmelfo
• d:Wikidata:Forum/Archiv/2020/07#Wikidata-Objekte für noch nicht zugordnete Artikel, Kategorien, Vorlagen, Listen, Begriffsklärungen, mit bestehenden Objekten verbinden bzw. neu anlegen
• d:User talk:Mike Peel/Archive 3#Julie von Kästner
• d:User talk:Mike Peel/Archive 4#once againg
• d:User talk:Mike Peel/Archive 3#Q105613214
• d:User talk:MrProperLawAndOrder#Mathilde Welcker (Q94753027) and Mathilde Welcker (Q94753026) are identical
• Wikipedia:Kurier#Unterstützung bei der Eingangskontrolle und Tätigkeiten der Qualitätssicherung gesucht
• Benutzer:M2k~dewiki/FAQ#Technische Wünsche / Wunschliste / Wishlist

uvam.

Wen betrifft das Problem besonders

Alle Autorinnen und Autoren sowie alle Leserinnen und Leser, weil ein Artikel bei falscher/fehlender Zuordnung ggf. keine/falsche/fehlende Interwiki-Links zu anderen Sprachen bzw. Projekten (Wikisource, Commons, Wikivoyage, ...) hat

Lösungsvorschlag

Im Zuge der Diskussionen, wer, wann, wie (z.B. über verschiedene eindeutige IDs, wie Baudenkmal-IDs, GND, VIAF, LCCN, IMDb, Wfb, ...), ... die Artikel bestehenden Objekten zugeordnet werden bzw. neue Objekte angelegt werden sollen (durch einen Bot, manuell, teilweise durch Bot/teilweise manuell, ..., wann soll der Bot für welche Artikel laufen, etc.) wurde der Vorschlag gemacht, dem Autor/der Autorin nach dem Anlegen eines Artikels, einer (Commons)-Kategorie, etc. ein Pop-Up anzubieten, mit dem das Verbinden bzw. Anlegen eines Objektes ermöglicht werden, analog zu "Duplicate" in "PetScan".

Problem sind dabei unterschiedliche Sprachen, Bedeutungen, Schriftzeichen/Zeichensätze, usw., sodass ein Bot das Problem nur teilweise sinnvoll lösen kann. Viele Autoren/Autorinnen wissen nicht von der Existenz von Wikidata oder vergessen, mit einem Objekt zu verbinden bzw. ein Objekt zu erstellen oder es fehlt das entsprechende Wissen, wie dieser Schritt vorgenommen werden kann. Ein Pop-Up nach dem Anlegen eines Artikels, einer Kategorie, ... könnte den Autor/die Autorin daran erinnern, diese Aktivität noch durchzuführen.

Beispiel:

• https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro

• Außerdem sollten Übersetzungen automatisch mit jenen Artikel verbunden werden, aus denen die Übersetzung vorgenommen werden (auch nach Verschiebung vom Benutzernamensraum in den Artikelnamensraum)
• Soweit eindeutig möglich (z.B. anhand von IDs, wie CAS-Nummer, IMDb, GND, VIAF, ...) könnten Bots automatisch Anlegen/Verbinden übernehmen und nur im Zweifel/bei Nichteindeutigkeit diese Arbeit einem Benutzer überlassen

Update 7. Februar 2023 - siehe auch

• meta:Community Wishlist Survey 2023/Wikidata/Popup to link to or create a new Wikidata object after creating an article
• https://phabricator.wikimedia.org/T308059
• meta:Meta:AutosuggestSitelink
  • meta:User:M2k~dewiki/global.js
• d:Wikidata:Project_chat/Archive/2022/11#Reducing_the_backlog_of_unconnected_pages_on_a_regular_base
• Wikipedia_Diskussion:Kurier/Archiv/2023/01#Benutzerschulung,_vom_Einzelfall_zum_gesamten_Artikelbestand

Update 25. April 2023 - Lösungsvorschlag

Beispielscreenshot für Luis Giraldo

• eine mögliche Lösung wäre das AutosuggestSitelink-Helferlein (siehe Screenshot) für die deutschsprachige Wikipedia für alle Benutzer standardmäßig zu aktivieren, siehe auch
• Benutzer:M2k~dewiki/FAQ#AutosuggestSitelink-Helferlein_für_andersprachige_Artikel_(Interwiki-Links/Wikidata-Sitelinks)
• meta:Talk:AutosuggestSitelink

Update 13. Februar 2024

Siehe auch

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Standardmäßiges_Aktivieren_diverser_Helferleins_für_alle_Benutzer_und_Pflege_mit_aktuellen_Skins

Wen betrifft das Problem besonders?

Wen betrifft das Problem besonders?

Vorschlagende Person

--M2k~dewiki (Diskussion) 12:28, 5. Sep. 2022 (CEST)

Diskussion

Häufig fehlende Kategorien, Normdaten, Personendaten, Links auf BKLs, falsche Commonscat, etc. bei neu anlegten Artikeln bzw. vom BNR in den ANR verschobenen Artikeln

Was ist das Problem?

Bei neu angelegten Artikeln gibt es eine Reihe von häufig auftretenden Problemen:

• de:Benutzer:M2k~dewiki/Checklist
• de:Wikipedia:Kurier#Unterstützung_bei_der_Eingangskontrolle_und_Tätigkeiten_der_Qualitätssicherung_gesucht

Beispielsweise

• fehlen Kategorien (z.B. Helferlein "HotCat") inkl. Sortierschlüssel
• fehlen bei biografischen Artikel Personendaten und Normdaten (Benutzer:Schnark/js#personendaten.js, Benutzer:Schnark/js/personendaten)
• sind Rechtsschreibfehler enthalten (Wikipedia:Helferlein/Rechtschreibprüfung)
• sind Links auf BKLs enthalten (Wikipedia:Helferlein/Begriffsklärungs-Check)
• fehlt die Verbindung zu einem Wikidata-Objekt
• wird auf eine nicht vorhandene Commonscat verlinkt (oder es existiert eine Commonscat, diese wird aber nicht verlinkt, vorhandene Inhalte/Fotos nicht eingebunden)
• fehlt das reference-Tag im Abschnitt Einzelnachweise
• ist das Lemma in der Einleitung nicht hervorgehoben
• gibt es leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift

Wen betrifft das Problem besonders?

Alle Autorinnen und Autoren, Entlastung der Eingangkontrolle und Qualitätssicherung, mehr Effizienz und Konzentration auf inhaltliche Fehler statt Formalitäten

Lösungsvorschlag

• Daher sollten standardmäßig verschiedene Helferleins aktiviert werden, sofern dies noch nicht der Fall ist
• Benutzer sollten beim Speicherbedarf von neuen Artikeln
• sowie beim Verschieben von Artikel vom Benutzernamensraum in den Artikelnamensraum
  • an das Hinzufügen von Kategorien (und ggf. Personendaten, Normdaten, ...) erinnert werden bzw. dabei (z.B. mittels Wizard/Pop-Up) unterstützt werden
  • eventuell können passende Kategorien automatisch vorgeschlagen werden (siehe Schnark-Helferlein), sodass der Benutzer diese nur mehr bestätigen/korrigieren muss
  • an das Verbinden/Anlegen mit/von einem Wikidata-Objekt erinnert werden, z.B. https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro
  • Commonscats sollten beim Speichern auf Existenz überprüft werden, falls nicht vorhanden sollte eine Fehlermeldung erscheinen
  • ein fehlendes reference-Tag im Abschnitt Einzelnachweise sollte automatisch hinzugefügt werden
  • das Lemma in der Einleitung sollte ggf. automatisch hervorgehoben werden
  • könnte auf leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift beim Speichern hingewiesen werden
    Anmerkungen

Siehe auch

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten_2
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Online-Typografiecheck_im_Editfenster_vor_Abschicken_eines_Edits,_z.B._wie_in_Word

Update 13. Februar 2024

Siehe auch

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Standardmäßiges_Aktivieren_diverser_Helferleins_für_alle_Benutzer_und_Pflege_mit_aktuellen_Skins
  Vorschlagende Person

--M2k~dewiki (Diskussion) 12:33, 5. Sep. 2022 (CEST)

Diskussion

Die Fehlermeldung bei Commonscats würde ich streichen, wenn die Vorlage gemeint ist. Eine existierende Commonskategorie unter Weblinks nicht anzugeben ist kein Fehler auch wenn die Vorlage häufig verwendet wird. Zum Beispiel könnte die Kategorie ja nur ein einziges schon im Artikel enthaltenes Bild enthalten. --Lupe (Diskussion) 23:42, 20. Sep. 2022 (CEST)

Häufig wird unter Weblinks auf eine nicht existierende Commonscat verlinkt, die entweder noch nicht angelegt wurde oder unter einer vom Artikellemma abweichenden (häufig englischen) Bezeichnung vorhanden wäre. Viele Autoren geben hier einfach ungeprüft {{Commonscat}} an. Wenn der Leser/die Leserin im Artikel darauf klickt, bekommt er/sie eine Fehlermeldung. Das sollte aus meiner Sicht beim Speichern eines Artikels geprüft werden und der speicherende Autor/die Autorin darauf hingewiesen werden. Der umgekehrte Fall, dass eine Kategorie auf Commons vorhanden wäre, aber im Artikel nicht verlinkt wird ist natürlich kein Fehler. Eine vorhandene, gültige Commonscat hilft häufig auch beim Auffinden des zugehörigen Wikidata-Objektes, um den Artikel mit anderen Sprachen zu verbinden. --M2k~dewiki (Diskussion) 18:21, 21. Sep. 2022 (CEST)

Siehe auch https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Display_warnings_in_case_of_missing_categories_etc._when_saving_an_article,_activate_gadgets --M2k~dewiki (Diskussion) 18:18, 28. Jul. 2024 (CEST)

Mobile Darstellung von Diskussionssträngen auf Hochfrequenzseiten wie wd:kurier

Datei:Screenshot 2022-09-14-07-09-06.png

Screenshot

Ab einer gewissen Anzahl von Einrückungen wird die Diskussion auf Mobils unlesbar, weil im Extremfall nach jedemn Zeichen umgebrochenen wird. Screenshot auf der Disk. Eine Verringerung der Standardeinrückung zB auf 1 oder 2 Zeichen wäre hilfreich. Vielleicht wäre ein individuelle Vorgabe in den Benutzereinstellungen möglich.--ClaudeWiko (Diskussion) 03:07, 16. Sep. 2022 (CEST)

Danke, @ClaudeWiko. Ich hab den Screenshot hier eingefügt und „mobil“ im Titel ergänzt. -- Johanna Strodt (WMDE) (Diskussion) 15:26, 16. Sep. 2022 (CEST)

Danke --ClaudeWiko (Diskussion) 04:11, 17. Sep. 2022 (CEST)

Versionsvergleich verbessern

Was ist das Problem?

Beim Vergleich von Artikelversionen werden gleiche oder fast gleiche Textabschnitte einander oft nicht zugeordnet, wenn Absätze umorganisiert wurden, z. B. ein Absatz in zwei aufgeteit oder zwei zu einem zusammengefügt wurden. Dann muss man die fraglichen Textabschnitte mühsam durchlesen, da die darin gemachten Änderungen nicht hervorgehoben werden.

Wen betrifft das Problem besonders?

Jeden, der sehen will, was an einem Artikel geändert wurde, z. B. um die Änderung auf Richtigkeit zu prüfen.

Lösungsvorschlag

Ein Algorithmus, der das Problem (weitgehend) löst, könnte etwa so aussehen: Zuerst werden wie bisher gleiche oder ähnliche Absätze bestimmt und einander zugeordnet. Die übrigen werden darauf geprüft, ob ihr Anfang einem Absatzanfang der anderen Version gleich oder ähnlich ist, und ebenso, ob ihr Ende einem Absatzende der anderen Version gleich oder ähnlich ist. Von da ausgehend ermittelt man die Stelle, ab der sich diese beiden Absätze völlig unterscheiden (oder einer davon endet). Die dadurch erkannten ähnlichen Absatzteile werden mit Hervorhebung ihrer Unterschiede dargestellt (am besten mit einer Kennzeichnung, z. B. Trennlinie, wo der Teil vom Absatz abgetrennt wurde). Die nicht zugeordneten Absatzteile werden im Folgenden jeweils wie ein ganzer Absatz behandelt. Das wird fortgesetzt, bis nichts mehr zugeordnet werden kann.

Vorschlagende Person

Megatherium (Diskussion) 18:09, 20. Sep. 2022 (CEST)

Diskussion

Vielen Dank, Megatherium. An der Verbesserung des Versionsvergleichs haben wir vor einigen Jahren im Zuge dieses Wunsches schon mal gearbeitet. Damals haben wir sehr lange getüftelt, bis die veränderten und verschobenen Absätze auch als solche erkannt wurden. Es ist sehr unwahrscheinlich, dass wir das noch verbessern können, auch wenn es leider nach wie vor Einzelfälle geben kann, bei denen der Algorithmus die Verschiebung nicht erkennt. Oder geht es dir noch um etwas anderes? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 18:29, 20. Sep. 2022 (CEST)

Hier ein Beispiel, wo ein Absatz in drei Teile geteilt wurde, wovon der aktuelle Versionsvergleich nur den ersten zuordnet, während er die beiden Folgenden wie neu geschrieben behandelt:

https://de.wikipedia.org/w/index.php?title=Double_Asteroid_Redirection_Test&diff=next&oldid=226997624

Der Algorithmus, den ich oben skizziert habe, könnte das besser machen. Zuerst würde er den Anfang des alten Absatzes dem ersten und das Ende dem dritten neuen Absatz zuordnen und jeweils abtrennen, und als nächstes erkennen, dass der so gekürzte alte Absatz dem zweiten neuen entspricht.--Megatherium (Diskussion) 16:24, 13. Okt. 2022 (CEST)

Danke, Megatherium. Dann lass ich das mal so stehen und wir werden in Vorbereitung der nächsten Umfrage wieder draufschauen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:00, 17. Okt. 2022 (CEST)

Dieses Problem hat 2022 die internationale Wunschliste gewonnen und wird unter „Better diff handling of paragraph splits“ aktuell von der Foundation bearbeitet. --Thiemo Kreuz (WMDE) 10:22, 9. Jun. 2023 (CEST)

Suche nach Vorlagen im Visual Editor verbessern

Was ist das Problem?

Beim Visual Editor könnte das Einfügen von Vorlagen noch verbessert werden hinsichtlich Auffindbarkeit der richtigen Vorlage und schnellerer Auswahl. Einerseits ist es manchmal mühsam eine noch nicht bekannte, geeignete Vorlage zu finden. Andererseits braucht man oft die gleichen Vorlagen immer wieder, sodass eine Vorauswahl Zeit sparen würde. Ein Beispiel wo man besonders oft die gleiche Vorlage hintereinander verwendet sind Tabellen.

Wen betrifft das Problem besonders?

Alle Autoren die den Visual Editor verwenden – sowohl Neulinge als auch hinsichtlich Zeitersparnis Experten.

Lösungsvorschlag

• Hilfreich wäre es Vorschläge für Vorlagen auch nach Themen / Kategorien wie Kategorie:Vorlage:Formatierungshilfe/Medien & Kategorie:Vorlage:Infobox zu erhalten, da man nicht immer die richtigen Schlagworte trifft - gerade für Neulinge, ansonsten kennt man die Vorlagen meist bereits. Also grobe Idee ist die noch leere Spalte links dafür zu nutzen. Dort würde ein Kategorienbaum und/oder eine Auswahl per Häkchen setzen hineinpassen
• Da man als Autor oft in einem bestimmten Themenbereich arbeitet, gibt es für jeden individuell Vorlagen, die häufig verwendet werden, insbesondere zu Infoboxen & Navigationsleisten. Hier könnten unter der Suchmaske zum Beispiel die letzten 10 verwendeten Vorlagen oder eine selbt definierte Auswahl an Vorlagen vorgegeben werden, um Zeit zu sparen. Ich möchte nicht ständig das gleiche eintippen müssen
• Bei Tabellenspalten wird oft in jeder Zeile die gleiche Vorlage verwendet, z.B. in einer Datumsspalte. Hier wäre eine Formatierungsmöglichkeit für die gesamte Spalte hilfreich, um Zeit zu sparen. Siehe auch Vorschlag "Tabellenedition"
  Vorschlagende Person

Lupe (Diskussion) 22:09, 20. Sep. 2022 (CEST)

Diskussion

Die WMF arbeitet aktuell unter dem Titel template recall and discovery an genau diesem Wunsch. --Thiemo Kreuz (WMDE) 14:48, 9. Okt. 2024 (CEST)

Suche nach Bildern verbessern

Beim Einfügen von Bildern im Visual Editor ist die Suchfunktion wenig hilfreich.

Was ist das Problem?

Auch beim Einfügen von Bildern im Visual Editor ist die Suchfunktion verbesserungsdürftig. Auf Deutsch zu suchen ist zudem deutlich weniger erfolgreich, selbst wenn in Bildern deutsche Beschreibungen stehen. Beispiel "Temperaturanomalie 2022" vs. "temperature anomaly 2022". In einem Fall finde ich Stand heute 1-2 Bilder, im anderen deutlich mehr, aber auch dann nicht alle aus der entsprechenden Kategorie. Ich muss also zwangsweise auf Commons wechseln und da die Suchfunktion analog nicht alles zeigt, gehe ich oft auf die Kategoriensuche, von einem Bildvorschlag auf zugeordnete Kategorien oder von einem Artikel auf die verlinkte Kategorie/Galerie um ein passendes Bild zu finden und dessen Filenamen, den ich dann in die Suchmaske im Visual Editor eingebe, wenn ich nicht gleich den Quelltexteditor verwendet habe.

Wen betrifft das Problem besonders?

Jeden, der Bilder einfügen möchte

Lösungsvorschlag

• Bei der Bildersuche im Visual Editor nicht nur einzelne Bilder, sondern auch passende Commons-Galerien und -Kategorien und deren Inhalt beim Anklicken anzuzeigen, würde schon helfen
  Anmerkungen

Hauptsächlich ein Commonsproblem, aber da es die Bild-Suchmaske im Visual Editor gibt und ich auf Commons keine Technischen Wünsche finde einfach mal hier geparkt

Vorschlagende Person

Lupe (Diskussion) 22:50, 20. Sep. 2022 (CEST)

Diskussion

Karten von Swisstopo als dynamische Karte in Wikipedia-Artikel einbinden können

Was ist das Problem?

• Beim Anlegen von Wiki-Artikeln zu Naturschutzgebieten (u.a. Amphibienlaichgebiete, Flach-, Hoch- und Übergansmoore, Pro Natura Waldreservaten, ISOS-Ortsbilder) sind Positionskarten ungeeignet, mittels VisualEditor eingebettete Karten zwar nützlich, aber die verschiedenen Flächen (z.B. Hochmoore, Flachmoore, Amphibienlaichgebiete) sind von Hand einzuzeichnen.
• Der Aufwand für die Herstellung eigener Karten ist relativ gross. Diese Karten später zu pflegen entfällt, wenn die Karte von Swisstopo eingebunden werden kann. Sie zeigen diese Gebiete an (und übrigens auch Zeitreise-Karten oder Kulturgüter). Swisstopo hat den Auftrag, die Geodaten des Landes zu verwalten, in Kooperation mit Kantonen und Gemeinden zu aktualisieren und der Öffentlichkeit zur Verfügung zu stellen.
• Im Moment ist es möglich, Kartenausschnitte von Swisstopo zu verlinken, aber Wikipedia schafft es nicht, den Swisstopo-Code für einen dynamischen Kartenausschnitte in einem Artikel zu verarbeiten und wiederzugeben.

Wen betrifft das Problem besonders?

• Wikipedians, die Artikel zu Schweizer Themen verfassen und Karten/Geodaten dazu verwenden (und vermutlich auch solche, die in Wikivoyage Touren beschreiben.)

Lösungsvorschlag

Wie erwähnt, sind Links mit Georeferenzierung möglich. Swisstopo bietet zudem die Möglichkeit, mittels <iframe> dynamische Kartenausschnitte in Webseiten einzubetten. Die Nutzung der Daten und Datendienste stellt für Wikipedia kein rechtliches Hindernis dar, denn die Nutzung ist gratis, die Weiterverbreitung und kommerzielle Nutzung sind erlaubt unter der Bedingung, dass das Bundesamt für Landestopografie swisstopo oder © swisstopo als Quelle angegeben wird (cf.Nutzungsbedingungen für kostenlose Geodaten und Geodienste (OGD) von swisstopo.

Anmerkungen

Es wäre m. E. klug, von dieser Möglichkeit Gebrauch zu machen.

Vorschlagende Person

Matutinho (Diskussion) 10:44, 21. Sep. 2022 (CEST)

Diskussion

,Nach oben‘-Button unterhalb der Kapitel längerer Artikel einfügen

Was ist das Problem?

Bei der Lektüre längerer WP Artikel auf dem Smartphone geht die Übersicht gerne verloren. Etwa nach dem Öffnen des Abschnitts ‚Leben‘ in einem Personenartikel.

Wen betrifft das Problem besonders?

Alle Benutzer mit kleinen Bildschirmen.

Lösungsvorschlag

Es könnte am Schluss eines Abschnitts eine ‚Schliessen’-Schaltfläche eingefügt werden.

Vorschlagende Person

Hükeno (Diskussion) 10:12, 13. Okt. 2022 (CEST)

Diskussion

Artikel speichern, aber ohne Beobachtung

Was ist das Problem?

Wenn ich einen Artikel, bspw. WP:SLA für ein Nachlesen speichern möchte, so bleibt mir nur die Beobachtungsliste oder das manuelle Verlinken im Benutzerraum. Fallen nun mehrere Artikel an, so ist die Beobachtungsliste geflutet mit Edit-Benachrichtigungen dieser Seiten, wobei die für mich wichtigen Edit-Benachrichtigungen oder Verlinkungen auf Disk-Seiten untergehen.

Wen betrifft das Problem besonders?

Aktive/Neue Nutzer, die bestimmte Regeln nachlesen möchten

Lösungsvorschlag

Entweder Einträge auf der Beobachtungsliste stumm schalten können, oder eine zweite Liste (= Lesezeichen, etc.) einführen.

Vorschlagende Person

VECTR¹⁹³ONATOR (DISK) 14:52, 1. Dez. 2022 (CET)

Diskussion

Für die Android- und iOS-Apps hat die Foundation eine Leselisten-Funktion entwickelt, die man sich als Browsererweiterung installieren kann. --Thiemo Kreuz (WMDE) 10:34, 9. Jun. 2023 (CEST)

Rücksetzten von Userbeiträgen nur mit Begründung

Was ist das Problem?

Es ist hauptsächlich für Neulinge frustrierend, wenn man nur das Zurücksetzten bemerkt, aber im Unklaren bleibt warum

Wen betrifft das Problem besonders?

Neue Autoren

Lösungsvorschlag

Beim Rücksetzten von Userbeiträgen sollte immer eine Begründung möglich sein. Besser wäre noch, dass man das begründen muss.

Vorschlagende Person

Knut Krüger (Diskussion) 09:56, 7. Dez. 2022 (CET)

Diskussion

Ich bin nicht neu. Interessiert mich aber jedes mal. Das würde aber auch die Hürte, mal (vor-)schnell zu löschen, hochsetzen.--Rudolf.l.s (Diskussion) 12:47, 3. Feb. 2024 (CET)

Ja, Zurücksetzen muss begründet erfolgen. Das sollte technisch erzwungen werden (ggf. Ausnahme für Zurücksetzen eigener Edits). erforderlich ia auch eine ausreichende und verständliche Begründung - was technisch leider nicht erzwungen werden kann ;-) Gruss, --Markus (Diskussion) 18:00, 10. Mär. 2024 (CET)

Lizenzhineweisgenerator sollte auch für andere Commons-kompatible Linzenzen als CC-Liznenzen Ergebnisse liefern

Was ist das Problem?

Bitte eine Problembeschreibung angeben

Wen betrifft das Problem besonders?

{{{Wen betrifft das Problem besonders?}}}

Lösungsvorschlag

{{{Lösungsvorschlag}}}

Vorschlagende Person

Gereon K. (Diskussion) 09:39, 26. Mär. 2023 (CEST)

Diskussion

Der Hochladeassistent sollte in bestimmten Fällen automatisch den Baustein Permission pending setzen

Was ist das Problem?

Wenn beim Hochladen fremder Arbeiten Permission pending nicht gesetzt wird, besteht das Risiko einer schnellen Löschung, was sowohl unerfahrene Wikipedistas als auch die Schaffenden solcher Arbeiten abschrecken kann. Meiner Erfahrung nach (bin langjähriger Mitarbeiter im Support) denken die wenigsten Wikipedistas daran, den Baustein manuell zu setzen.

Wen betrifft das Problem besonders?

1. Wikipedistas, die fremde Schöpfungen auf Commons hochladen
2. Künstlys und Fotografys, die Schöpfys dieser Werke

Lösungsvorschlag

Der Hochladeassistent sollte in automatisch den Baustein Permission pending setzen, wenn angeklickt wird, dass es sich um eine fremde Arbeit handelt und angeklickt wird, dass Rechteinhabery mit einer Freigabe per gültiger Lizenz einverstanden ist.

Anmerkungen

Der Wunsch entstand in einer Diskussion bei Wikipedia:Stuttgart im Dezember 2022.

Vorschlagende Person

Mussklprozz (Diskussion) 21:26, 26. Mär. 2023 (CEST) und Rudolf Simon

Diskussion

Ja, da denke ich auch nicht dran. Soll automatisch erfolgen. --Markus (Diskussion) 18:02, 10. Mär. 2024 (CET)

Referenzen im Quelltexteditor hervorheben

Was ist das Problem?

Wenn ein Text viele Referenzen (<ref>...</ref>) enthält, ist er im Quelltexteditor schwer lesbar und damit auch schwerer editierbar, da man Anfang und Ende einer Referenz nicht auf einen Blick erkennen kann, vor allem, wenn sie über mehrere Zeilen geht.

Wen betrifft das Problem besonders?

Jeden, der den Quelltexteditor benutzt.

Lösungsvorschlag

Referenzen könnten im Quelltexteditor z. B. durch eine andere Hintergrundfarbe (irgendeine helle Pastellfarbe) hervorgehoben werden.

Vorschlagende Person

Megatherium (Diskussion) 20:58, 21. Apr. 2023 (CEST)

Diskussion

Hast Du schon mal Benutzer:Schnark/js/syntaxhighlight ausprobiert?--Mabschaaf 09:10, 22. Apr. 2023 (CEST)

Ja, automatische farbliche Kennzeichnung von <ref>und Inhalt ist wünschenswert. --Markus (Diskussion) 18:11, 10. Mär. 2024 (CET)

Schleichwerbung für Schmierphone

Könnte endlich diese widerliche Werbung für Android/Äppel und den ganzen Mobilkram aus den Versionsgeschichten verschwinden??? Siehe z. B. die letzten Bearbeitungen zu "Zerstörung des Kachowka-Staudamms" Ob da jemand auf seinem Schmierphone herumschmiert, und welches Betriebssystem auf diesem ist, interessiert mich doch weniger als ein Sack Reis in China. Im Übrigen: Dieser Edit stammt von meinem Aldi-Computer :-( Das muß die ganze Welt nämlich unbedingt wissen.--32 Fuß-Freak (Diskussion) 12:20, 10. Jun. 2023 (CEST)

@ Benutzer:32 Fuß-Freak: Für die Softwareentwickler ist das durchaus interessant/wichtig. Aber Du kannst es für dich Ausblenden: Hilfe:Bearbeitungsmarkierung#Individuelle_Ausblendung_oder_Hervorhebung.--Mabschaaf 12:32, 10. Jun. 2023 (CEST)

Ja, ich glaube, das wäre eine deutliche Erleichterung für mich. Aber, wo auf meiner Benutzerseite fange ich damit an? Bei "Einstellungen", und wie gehts dann weiter, und wo füge ich diese Codes ein? Im Prinzip sind die visuellen Bearbeitungen das Einzige, was ich angezeigt bekommen möchte oder dulde, und im Grunde brauche ich nicht mal das. Eigentlich ist jeder Hinweis auf irgendeine Bearbeitungsart für mich vermutlich entbehrlich. Aber schon mal Danke für den Tipp, auch wenn ich noch nicht weiß, wie ich das Ausblenden umsetze.--32 Fuß-Freak (Diskussion) 12:40, 10. Jun. 2023 (CEST)

Es ist shcon besser. Jetzt erscheint nur noch "Bearbeitung von einer mobilen Anwendung". Aber auch das soll weg.--32 Fuß-Freak (Diskussion) 13:17, 10. Jun. 2023 (CEST)

Du erstellst die Seite Benutzer:32 Fuß-Freak/common.css und kopierst den hervorgehobenen Block aus dem Abschnitt "Ausblenden" von der oben verlinkten Seite dort hinein. Dann einmal Browser-Cache löschen (wie, steht dann dort beschrieben) und das wars. --Mabschaaf 13:22, 10. Jun. 2023 (CEST)

Es liegt wohl daran, daß ich den Browserverlauf oder -Cache jetzt nicht lösche, denn sonst muß ich mich überall (nicht nur bei Wiki) wieder mit Paßwort und Co. einklinken. Das mache ich erst, wenn sowieso ein Neustart des PC´s nötig ist und der Browser dabei sowieso neu gestartet und ausgeräumt wird. Gruß--32 Fuß-Freak (Diskussion) 13:33, 10. Jun. 2023 (CEST)

Ich verstehe beide Seiten. MMn ist alles, was mit Wikipedia:Anonymität zu tun hat, höherwertig. Mein Vorschlag ist, dass die Markierung optional wird und nur bei expliziter Zustimmung angezeigt wird. --Fan-vom-Wiki (Diskussion) 17:32, 12. Jun. 2023 (CEST)

Der "Entwickler" kann sicher auch, ohne, daß es jedermann (selbst Leuten, die nur sporadisch ohne Benutzerkonto bei Wiki reinschauen) angezeigt wird, ablesen, womit editiert wurde. Ich muß es nicht wissen, es ist nur unnütze oder lästige Information für mich.--32 Fuß-Freak (Diskussion) 02:01, 13. Jun. 2023 (CEST)

<Ich wünsche mir, mit meinem Spracherkennungsprogramm (DragonDictate) in Wikipedia unmittelbar diktieren zu können

Was ist das Problem?

<Ich benutze für meine Tätigkeiten am Computer nur selten die Tastatur und überwiegend ein Spracherkennungsprogramm (in diesem Fall: DragonDictate). Wenn ich in Wikipedia einen neuen Text einfügen will, muss ich das »Diktierfenster« benutzen, dass für alle Fälle vorgesehen ist, in der das Programm den Eingriff von DragonDictate nicht gestattet, obwohl auf dem Display von DragonDictate ein grünes LED aufleuchtet, das normalerweise bestätigt, dass DragonDictate mit dem jeweiligen anderen Softwareprogramm technisch verbunden ist. Der dort erfasste Text wird dann über copy + Paste in Wikipedia übertragen. Das ist ziemlich umständlich, vor allem dann, wenn man innerhalb eines Wikipedia-Artikels viele Kleinigkeiten zu verbessern oder zu ändern hat. Bei DragonDictate gibt es sogenannte Extensions, die das Problem lösen sollen, aber sie wirken bei Wikipedia nicht.

• Was möchtest du machen und warum?

Ich möchte unmittelbar in Wikipedia hinein diktieren können

• Welche Schritte durchläufst du dabei?

Derzeit muss ich erst das Diktierfenster bei DragonDictate öffnen, dort diktieren und dabei vermisse ich zahllose Funktionen, die der Quelltext anbietet. Ich erstelle also erst einen unvollkommenen Text, speichere ihn dann in Wikipedia und überarbeite ihn dort.

• Welche Probleme treten auf?

Das wesentliche Problem ist die Umständlichkeit.Ich will dazu noch ergänzen, dass ich es regelmäßig vergesse, das Diktierfenster zu öffnen (weil es in anderen Programmen nicht erforderlich ist) und dann zerstört mein Diktat Teile des Quelltextes, die ich dann wieder rekonstruieren muss. Das kann man sich natürlich abtrainieren, aber es ist eine Fehlerquelle. Besser wäre es also, direkt diktieren zu können.

Wen betrifft das Problem besonders?

<Alle Benutzer, die überwiegend diktieren. Besonders betroffen sind Behinderte, die die Tastatur überhaupt nicht bedienen können. Rechte sind insofern betroffen, als Wikipedia den Eingriff von Spracherkennungsprogrammen dulden muss, wenn diese dort wirksam werden sollen. Fremde Rechte sind nicht betroffen.

Lösungsvorschlag

<Die 1. Idee ist: Die Softwareleute bei Wikipedia sollten sich einmal mit den Softwareleuten von DragonDictate zusammensetzen. Die sitzen zwar in den USA, aber im Grunde ist es auch für Wikipedia ein internationales Problem. Denn überall auf der Welt taucht es auf. Natürlich sollte nicht nur DragonDictate, sondern jedes Spracherkennungsprogramm zugelassen sein, dies schon aus kartellrechtlichen Gründen. Ich habe bei Dr. Stephan Küpper (egs), der für DragonDictate dort zuständig ist, angefragt und folgende Antwort erhalten:

"Was Ihre Frage angeht: das Diktat „nach Wikipedia“ hängt wesentlich davon ab, welchen Browser Sie verwenden. Für Microsoft Edge und Google Chrome gibt es Browser Add-In, die es erlauben, in fast alle Textfelder zu diktieren, außerdem den Browser per Sprache zu steuern, Hyperlinks per Sprache auszulösen usw. ich habe das Diktat in den Wikipedia-Editor mit Dragon 16 gerade selbst erfolgreich ausprobiert.

Die Browser Add-In sollten sich eigentlich bei der ersten Verwendung des Browser nach der Installation von Dragon selbstständig installieren. Falls nicht, hier die direkten Links:

Google Chrome: https://chrome.google.com/webstore/detail/dragon-medical-web-extens/dkidoflkcabkfmcpnndogifoldoegnmk?hl=de Microsoft Edge: https://microsoftedge.microsoft.com/addons/detail/dragon-weberweiterung/banejkelfpdmmmfobepfdnbmbbnecnol?hl=de Firefox: das Add-In, welches es gab, wird leider von Firefox nicht mehr unterstützt.

Zur Installation öffnen Sie den Link mit dem jeweiligen Browser und wählen Sie rechts oben „abrufen“ bzw. „installieren“."

Könnt Ihr das mal testen und sehen, ob es bei Euch funktioniert? Bitte Rückmeldung. Ich teste es auch in den nächsten Tagen.

Vorschlagende Person

Sergio.Germann (Diskussion) 12:10, 11. Sep. 2023 (CEST)

@ Sergio.Germann vielen Dank für deinen ausführlichen Beitrag! Wir werden uns im Zuge der nächsten Umfrage 2024 mit allen hier gelisteten Vorschlägen auseinandersetzen und zu Themenschwerpunkten zusammenfassen. Bis dahin dient diese Seite als Sammelstelle. Das bedeutet, dass wir vorerst die einzelnen Probleme leider nicht testen und ausprobieren können. Schau dir für nähere Erklärung auch gerne die Abschnitte "Wie entstehen die Themenschwerpunkte, über die in der Umfrage abgestimmt wird?" und "Welche Bedeutung haben die konkreten Probleme für die Umfrage?" auf dieser Seite an. Beste Grüße -- Thereza Mengs (WMDE) (Diskussion) 13:18, 13. Sep. 2023 (CEST)

Diskussion

Hier ist der oben genannte Stephan Küpper. Ich teste gerade mit Dragon v16 das Diktat in den Editor unter Verwendung des aktuellen Microsoft Edge-Browsers mit installiertem Dragon-Add-In. Grundsätzlich funktioniert das Diktat, das Problem scheint aber darin zu bestehen, dass die Änderungen nicht gespeichert werden.

Ich verwende aktuell MS Edge Version 116.0.1938.81 (Offizielles Build) (64-Bit), Dragon Professional v16. 00.200.159 und die Dragon-Web Erweiterung für Microsoft Edge in Version 15.7.0.5 812. Diese können Sie abrufen bzw. einsehen unter edge://extensions/?id=banejkelfpdmmmfobepfdnbmbbnecnol.

In der Vorschau wird meine Anmerkung korrekt angezeigt. Ich werde jetzt die Änderungen veröffentlichen und testen, inwieweit sie auch da übernommen werden - wie man sieht, ja.

Das Problem ist überraschend gelöst worden!Eine vertiefte Analyse hat ergeben, dass auf meinem Computer (offenbar durch Zufall) Mehrere Dragon-Erweiterungen gespeichert waren. Ich habe nur die jüngste von Ihnen behalten und die anderen deaktiviert. Der Test hat ergeben, dass nun sowohl auf der visuellen Ebene wie auf der Quelltextebene Der Text richtig erfasst wird. Was allerdings nicht funktioniert sind die Korrekturfunktionen etc.

Kommando zurück! Nach tagelangen Versuchen, eine stabile Funktionalität herzustellen, ist das nicht gelungen. Verwendet wurde Dragon Version 16, Windows-Version 11 und die aktuelle Dragon Erweiterung. Der Text wird zwar auf dem Display sichtbar, verschwindet aber bei der Speicherung. Das Problem kann offenbar nur aus einer Zusammenarbeit von Experten der Wikipedia und von DragonDictate gelöst werden. Ich wäre dankbar, wenn sich jemand darum kümmert. Gruß Sergio

Es meldet sich noch einmal Stephan Küpper: ich kann das Problem nach wie vor in meiner Installation nicht nachvollziehen, bei mir funktioniert alles in der angeblich identischen Konstellation (Dragon 16, Windows 10, MS Edge in aktueller Version 118.0.2088.61 (Offizielles Build) (64-Bit)).

Jetzt meldet sich wieder Sergio.Germann:Ich habe die gleiche Systemumgebung die Stephan Küpper und verwende folgende Dragon Erweiterung:Dragon (DMO, DMD, DPA, DLA) Web Extension Größe: < 1 MB Größe< 1 MB Version: 2 3 . 2 . 8 9 7 . 0 Version23.2.897.0 Bei einem heutigen Test sind meine Änderungen gespeichert worden. Diesen Text hier diktiere ich wieder. Sollte auch er gespeichert worden sein, haben wir das Problem gelöst.

Anmerkung Stephan Küpper: ich habe versucht das nachzustellen, musste aber für die vollständige Funktionalität die Erweiterung von https://microsoftedge.microsoft.com/addons/detail/dragon-weberweiterung/banejkelfpdmmmfobepfdnbmbbnecnol?hl=de herunterladen. Die Dragon (DMO, DMD, DPA, DLA) Web Extension hat bei mir nicht zufriedenstellend funktioniert.

Tabellen statt Listen auf Spezialseiten

Was ist das Problem?

Viele Spezialseiten, z. B. Letzte Änderungen, aber auch viele andere, geben ihre Daten in Listen aus. Es wäre wesentlich praktischer, wenn das in Tabellen ausgegeben würde. Dann kann man z. B. einfacher per copy&paste Inhalte von Spezialseiten in ein Tabellenkalkulationsprogramm übertragen, wenn man etwas auswerten möchte, ohne die API bemühen zu müssen

Wen betrifft das Problem besonders?

Es betrifft besonders Benutzer*innen, die keine Kenntnisse der Verwendung der MediaWiki APO haben und trotzdem Inhalte von Spezialseiten auswerten wollen.

Lösungsvorschlag

Einfach stat über unordered lists, die dann jede Menge Inhalte per Komma oder Leerzeichen enthalten, die Inhalte einfach in einer MediaWiki-Tabelle anzeigen.

Vorschlagende Person

Krabina (Diskussion) 10:45, 1. Okt. 2023 (CEST)

Diskussion

Beiträge eines Benutzers beobachten

Was ist das Problem?

Besonders als Mentor möchte ich gerne sehen, wen einer meiner Mentees, eine Bearbeitung gemacht hat. Im Moment muss ich dazu regelmäßig die Beitragslisten aller meiner Mentees überprüfen und sehe nur, wenn dessen Benutzer- oder benutzerdiskussionsseite bearbeitet wird.

Wen betrifft das Problem besonders?

Mentoren

Lösungsvorschlag

Beheben könnte man dieses Problem, indem man die Beiträge (bzw. die Beitragsliste) eines Benutzers beobachten könnte und diese so auf der eigenen Beobachtungsliste auftauchen.

Vorschlagende Person

Wandelndes Lexikon (Diskussion • ) „Wissen wächst, wenn man es teilt.“ 23:20, 16. Nov. 2023 (CET)

Diskussion

@Wandelndes Lexikon soweit ich weiß, wurde sowas bisher bewusst nicht umgesetzt, um Wikihounding zu erschweren. Du könntest aber einfach auf Benutzer:Wandelndes Lexikon/Mentor (oder ner anderen von dir gewählten Seite) {{Spezial:Beiträge/Benutzername des Mentee}} einbinden (jeweils einmal pro Mentee), dann siehst du dort alle aktuellen Beiträge auf einen Blick. --Johannnes89 (Diskussion) 00:51, 17. Nov. 2023 (CET)

Ok, vielen Dank für die Antwort. --Wandelndes Lexikon (Diskussion • ) „Wissen wächst, wenn man es teilt.“ 00:54, 17. Nov. 2023 (CET)

Bearbeiten von Bildern

Was ist das Problem?

• Was möchtest du machen und warum: Ich möchte gerne Bilder leicht bearbeiten und als abgewandelte Werke auf Wikimedia Commons hochladen. D.h. Zuschneiden, ggf. Spiegeln, oder Overlays mit Beschreibungen oder Zahlen hinzufügen, Bereiche hervorheben oder mehrere Bilder kombinieren. An Vektorgrafiken möchte ich ggf. kleinere Änderungen vornehmen. Das möchte ich vor allem machen, um Tools zu dokumentieren, Bilderrahmen abzuschneien oder einfach, um in Diskussionen ein Bildschirmfoto schnell einzufügen und Bereiche hervorheben zu können.
• Welche Schritte durchläufst du dabei? Aktuell lade ich die Datei herunter. Dann öffne ich Gimp oder Inkscape, bearbeite die Datei und lade sie mit DerivativeFX wieder hoch oder muss bei zusammengesetzen Werken selbst alle Quellenangaben, sowie Autoren zusammensuchen, sowie eine kompatible Lizenz finden.
• Welche Probleme treten auf?
  • Ich muss die Datei herunterladen und lokal bei mir speichern. Vielleicht hat mir der Administrator verboten, Dateien lokal zu speichern. Entwder muss ich hinterher sauber machen (löschen) oder mir eine Art Arbeitsplatz für Wikipedia-Bilder schaffen, damit mein Rechner nicht zumüllt.
  • Ich muss Inkscape und Gimp lokal installiert haben. Vielleicht hat der Administrator verboten, zusätzliche Programme zu installieren.
  • Ich muss die veränderte Datei lokal abspeichern. Entwder muss ich hinterher sauber machen (löschen) oder mir irgendeine Art Arbeitsplatz für Wikipedia-Bilder schaffen, damit mein Rechner nicht zumüllt.
  • Ich muss Quellen und Lizenzen zusammentragen oder DerivativeFX nutzen. Das ist aufwändig und fehleranfällig. Letzteres funktioniert mit modernen Sicherheitseinstellungen nicht mehr richtig.
  • Ich muss die korrekte Datei auswählen und hochladen. Wahrscheinlich habe ich einen asymetrischen Internetzugang. D.h. das Hochladen dauert viel länger als das Herunterladen.
  • Dabei muss ich zwischen mehreren Fenstern und Dialogen hin- und herwechseln. Nach Arbeitsunterbrechungen muss ich wir wieder einen Überblick über den aktuellen Zustand meines Arbeitsplatzes machen, weil ich ggf. vergessen habe, warum ich welche Fenster geöffnet habe und an welchem ich zuletzt gearbeitet habe.

Wen betrifft das Problem besonders?

Alle Nutzer, die mit Bildern arbeiten.

Lösungsvorschlag

Web-Werkzeuge zum rudimentären Bearbeiten von Bildern, die in MediaWiki integriert sind. Beispiel, das schon viel mehr kann, als absolut notwendig.

Vorschlagende Person

rillke fragen? 16:19, 18. Nov. 2023 (CET)

Diskussion

Bearbeiten und Verwalten von Videos

Was ist das Problem?

• Was möchtest du machen und warum? Ich möchte Videos schneiden (chronologisch), ggf. zuschneiden, ggf. pixeln, Overlays hinzufügen, ggf. mergen, ggf. Tonspuren hinzufügen oder entfernen oder einen Kompressor/ dynamische Normalisierung darauf anwenden. Dabei möchte ich von ggf. von lokalen oder bereits hochgeladenen Dateien auf Wikimedia Commons ausgehen und diese weiter bearbeiten. Im zweiten Fall möchte ich eine Option haben, das Original zu überschreiben oder unter einem anderen Namen hochzuladen. Das brauche ich z.B. wenn ich die WikiCon-Aufzeichnungen zuschneiden möchte oder Zitate aus Videos herausschneiden möchte, um diese ggf. in Artikeln verwenden zu können. Beim Schneiden sollen Unteritel ebenfalls korrekt geschnitten werden. Dabei möchte ich nicht gezwungen sein, das Video komplett lokal herunter zu laden, Programme zu installieren und wieder hochladen zu müssen. Auch möchte ich ggf. Videos von Commons kombinieren/ neu zusammenschneiden und mir dabei nicht manuell Gedanken über das Zusammensuchen von Autoren und kompatiblen Lizenzen machen müssen.

• Welche Schritte durchläufst du dabei?
  1. Ggf. Original von Wikimedia Commons herunter laden.
  2. Datei in einem lokalen Player ansehen und Schnittmarken finden.
  3. Mit ffmpeg -ss ... -i ... -t ... zuschneiden.
  4. Ggf. mit shotcut Effekte wie Blur oder Pixelize anwenden, um personenbezogene Daten unkenntlich zu machen.
  5. Video von Shotcut kommend noch einmal mit ffmpeg ... -video_track_timebase neu codieren, damit die time base (tb) mit den anderen Schnipseln übereinstimmt
  6. Videos mit ffmpeg konkatenieren ohne neu zu codieren, um Qualitätsverluste zu vermeiden und weil das um Welten schneller geht.
  7. Video zur Ansicht und Einholung von Freigaben in die WMDE Cloud laden. Als MP4 damit das auch von Apple-Geräten problemlos abgespielt werden kann und keine weiteren Rückfragen kommen.
  8. Gesamtes Video in ein Format bringen, das von Wikimedia Commons unterstützt wird (Transcode).
  9. Hochladen.
• Welche Probleme treten auf?
  1. Größenbeschränkung etwa 4G bei video2commons und Wikimedia Commons beschränken die Auflösung, die Wiedergabedauer oder erfordern stärkere Kompression/Verluste oder einen stärkeren Komprimierungsalgorithmus, der meist noch langsamer läuft (z.B. AV1 vs VP8). Chronologisch geteilte Video-Dateien verstehen Benutzer nicht, u.a. da es keine Wiedergabelisten gibt (siehe z.B. Nachfrage von Gnom, warum sein Vortrag abgeschnitten sei.
  2. Ich muss ggf. herunterladen und über eine asymetrische Leitung wieder hochladen. Das kann sehr lange dauern. Selbst mit sonst gutem Anschluss.
  3. Ich muss mehrere Programme lokal installieren, Fenster öffnen und verwalten.
  4. Mein lokaler Rechner muss schreib- und CPU-intensive Aufgaben lokal erfüllen oder ich muss die Datei auf einen Server übertragen, dort bearbeiten und von dort wieder herunterladen bevor ich sie zu Commons hochladen kann.
  5. Commons unterstützt bestimmte Codecs aus patentrechtlichen Gründen nicht, was ggf. zusätzliches Transcoding erfordert.
  6. Zur Freigabe-Prüfung durch die Sprecherinnen und Sprecher und alles dazwischen und außerhalb und andere Urherberrechtsinhaber muss das Video in einem anderen Format als auf Commons vorliegen und darf nicht aufgelistet/durch die Öffentlichkeit auffindbar sein.

Wen betrifft das Problem besonders?

Benutzer, die mit Videos arbeiten. Auf der WikiCon habe ich z.B. eine Dokumentar-Filmerin getroffen und musste ihr sagen, dass der Video-Support in Wikimedia-Projekten eher schwierig ist. Und wo keine Benutzer sind, die damit arbeiten, keine Konsumenten und kein induced demand, sondern ein reduced demand.

Lösungsvorschlag

• 1. Video-Management-Features für Autoren, mindestens wie Opencast sie bietet.
     Vorschlagende Person

rillke fragen? 18:14, 18. Nov. 2023 (CET)

Diskussion

Ich möchte gern wieder Interaktive Diagramme verwenden können

Was ist das Problem?

• Was möchtest du machen und warum? Ich möchte interaktive Graphen mit Daten aus Wikidata erstellen. z.B. habe ich Vorlage:Opencast Versionsgraph mit Vega-Definitionen erstellt. Die Vorlage nutzt Daten von WikiData und <graph>. Sie diente v.a. in der englischsprachigen Wikipedia der Illustration des Textes, der behauptet, Opencast folge einem time-based-release schedule. Das könnte man in einer Enzyklopädie natürlich statisch umsetzen. Macht aber mehr Arbeit in der Artikel-Wartung. Darüber hinaus gibt es nahezu unendlich viele weitere Anwendungsfälle für interaktive Graphen. Und bevor hier wieder die Diskussion losgeht, ob Wikipedia ein Almanach sei: Auch in Schwesterprojekten wie der WikiVoyage oder WikiBooks ist es sehr nützlich. Vor allem muss man solche Graphen nicht ständig neu nach Commons hochladen oder die Daten aktualisieren, wenn die Daten aus WikiData genommen werden können.
• Welche Schritte durchläufst du dabei? <graph mode=interactive> oder einen Lua-Wrapper verwenden.
• Welche Probleme treten auf? Die Erweiterung ist wegen phab:T334940 deaktiviert. Aber das erfährt man hier auf de.wp erst, wenn man sich 2x durchklickt.
• Außerdem wäre es allgemein hilfreich zu wissen, wie die Roadmap aussieht? Wie lange wird eine jeweilige Vega.js Version unterstützt und wer kümmert sich um die Updates der Einbindungen? Hilfe:Graph#Wartung behaupted: "Graph ist ein modernerer und mutmaßlich robusterer Ersatz für Hilfe:Zeitleisten (EasyTimeline)." Die Aussage ist nach der bis jetzt andauernden Stillegung ab April 2023 schlecht gealtert.

Wen betrifft das Problem besonders?

Alle Nutzer, die Graphen direkt oder indirekt durch die Verwendung von <graph> einbinden (möchten) und für die EasyTimeline und einfache andere Tortendiagramme o.ä. nicht ausreichend sind.

Lösungsvorschlag

• Workaround vorschlagen oder Problem beheben.
• Falls Migrationen notwendig sind und die JSON Definition automatisch migriert werden kann, gern das. Ansonsten bitte um zielgerichtete Hilfe.
  Anmerkungen
• Die Software heißt MediaWiki. Vom Setzen der Prioritäten her bei der Problembehandlung und Umsetzung von Features sollte sie eher TextWiki heißen. Das ist nicht schlimm, aber es würde weniger Erwartungen in eine wenig abgedeckte Richtung wecken.
  Vorschlagende Person

rillke fragen? 23:44, 18. Nov. 2023 (CET)

Diskussion

Unter mw:Extension:Chart/Project arbeitet die WMF aktuell aktiv an einem Ersatz. --Thiemo Kreuz (WMDE) 14:53, 9. Okt. 2024 (CEST)

Unterkategorien beobachten

Was ist das Problem?

Wenn ich Kategorien folge, werde ich ja über hinzugefügte und gelöschte Artikel auf meiner Beo informiert. Ich möchte aber bei der Beobachtung die Option haben, nicht nur über die Vorgänge direkt in der Kategorie informiert zu werden, sondern auch über alle Vorgänge in allen Unterkategorien.

Wen betrifft das Problem besonders?

Aktive.

Lösungsvorschlag

Ich denke, wir haben hier mehrere Möglichkeiten:

1. Man kann sich in den Einstellungen zwischen beiden Optionen entscheiden.
2. Man entwickelt ein extra Tool/Helferlein.
3. (Man bekommt bei der Beobachtung beide Optionen angezeigt und kann sich für eine entscheiden.)

Ich bevorzuge Option 1.

Vorschlagende Person

Vergänglichkeit (Diskussion) 02:14, 19. Nov. 2023 (CET)

Diskussion

Werkzeuge zum Auffinden und Löschen von Urheberrechtsverletzungen (auch in zeitbasierten Medien) (auf Commons)

Was ist das Problem?

• Was möchtest du machen und warum? Um Nachnutzende zu schützen gilt auf Wikimedia Commons das precautionary principle und Urheberrechtsverletzungen werden gelöscht, wenn sie gefunden werden. Je eher das passiert, desto besser, denn i.d.R. steigt die Nachnutzung mit zunehmender Verweildauer eines Mediums auf Commons an. Handelt es sich um eine Urheberrechtsverletzung, steigt damit das Risiko von Abmahnungen und, viel schlimmer, es führt unter Gelegenheitsnutzenden zu einem Lernprozess - es sei ja eine stillschweigende Einwilligung, dass diese Art von Rechteverletzung geduldet sei. Aktuell sehe ich mir dazu c:Special:NewFiles oder eine von dort verlinkte Seite an. Bei den meisten Bildern kann ich sehr schnell entscheiden, ob es sich wohl um eine Urheberrechtsverletzung handelt. Fehlen Angaben zu Quellen, um eine Einschätzung zu erhalten, gibt es auf Commons die Möglichkeit, diese mit nur einem Klick vom Benutzer nachzufordern. Ich hätte gern eine Liste mit potenziellen Urheberrechtsverletzungen unter den neuen Uploads und eine Möglichkeit Upload als durch eine Eingangskontrolle geprüft zu markieren.
• Welche Schritte durchläufst du dabei?
  1. Ich öffne c:Special:NewFiles oder eine Seite, die von dort auf ein Tool wie Neue Dateien in Echtzeit oder Neue Dateien neuer Benutzer verweist.
  2. Wenn ich auf Grund eines Vorschaubildes eine Urherberrechtsverletzung vermute, öffne den Link zur Dateibeschreibungsseite und sehe mir die Angaben genau an.
  3. Ggf. führe ich eine reverse Bildsuche mit Google Image Search oder Tineye (Link von Gadget bereit gestellt) durch, um andere Verwendungen oder die Originalquelle zu finden.
  4. Fehlen Angaben, fordere ich diese vom Uploader mit einem Klick nach. Ggf. sehe ich mir mit c:Help:VisualFileChange.js weitere Uploads des Benutzers an.
  5. Handelt es sich um eine offensichtliche Urheberrechtsverletzung, markiere ich die Datei zur Löschung als Urheberrechtsverletzung. (ebenfalls per QuickDelete)
  6. Handelt es sich möglicherweise um eine Urheberrechtsverletzung, stelle ich einen Löschantrag.
• Welche Probleme treten auf?
  1. Bestimmte Medien, die Urheberrechtsverletzungen darstellen, werden in abgewandelter Form immer wieder hochgeladen. Da die Medien abgewandelt sind und nicht identisch (bei JPEG reicht i.d.R. ein einfaches Umspeichern), können Sie bei Eingangskontrolle nur durch Zufall gefunden werden; sie tauchen nicht in der Liste doppelter Dateien auf.
  2. Zeitbasierte Medien (Audio, Video) sind äußerst aufwändig zu kontrollieren und können potenziell mehrere (Ton)spuren enthalten. Zu Aufwändig für eine Eingangskontrolle.
  3. Das Vorhandensein mehrerer Audio-Spuren wird nicht visuell gezeigt und es gibt weder Waveform noch Spektrogramm von Audio-Spuren, um zu sehen, welche Bereiche man ggf. manuell kontrollieren möchte.

Wen betrifft das Problem besonders?

Eingangskontrolle für Medien auf Commons.

Lösungsvorschlag

• System ähnlich ContentID für die Tonspur von zeitbasierten Medien aber ohne Auto-Blocking.
• Perceptual ImageHash (oder eine ähnliche Software) für eingehende Bilder und die Möglicheit diese mit den ImageHashes gelöschter Urheberrechsverletzungen abzugleichen.
• Liste mit Dateien, die visuell ähnlich aussehen oder ähnlich klingen. Für Patroller oder Administratoren inklusive die Namen und Links zu gelöschten Dateien am besten mit Link zur Benutzerdiskussionsseite des Uploaders.
  Vorschlagende Person

rillke fragen? 08:58, 19. Nov. 2023 (CET)

Diskussion

Wozu soll das gut sein? Bitte kein vorauseilender Gehorsam. Ich nehme auf Commons bereits jetzt tendenziell eher ein overblocking wahr (z.B. bei älteren, potenziell verwaisten Werken oder Werken mit unklarem Eigentumsverhältnis). --Max schwalbe (Diskussion) 14:43, 20. Aug. 2024 (CEST)

Nur Vorder- oder Rückseite beobachten

Was ist das Problem?

Warum kann man derzeit nur Vorder- und Rückseite zusammen beobachten und nicht getrennt voneinander, z. B. nur die Artikeldisk oder die Disk einer Metaseite (z. B. die VM-Disk)? Wenn eine Seite sehr frequentiert ist (und die Beobachtungsliste "verstopfen" würde) und man die andere Seite gerne beobachten möchte, wäre es sehr praktisch, wenn man Seiten einzeln beobachten könnte.

Wen betrifft das Problem besonders?

alle Wikipedianer

Lösungsvorschlag

Nur Vorder- oder Rückseite beobachten

Vorschlagende Person

-- Toni 14:14, 4. Dez. 2023 (CET)

Diskussion

+1: Bei mir ein uraltes Thema (WP:VM nein, aber WD:VM ja; hingegen WP:K ja, aber WD:K nein). --Filzstift (Diskussion) 16:11, 13. Dez. 2023 (CET)

Erkennen von Marketing und nicht neutraler Sprache

Das Projekt UmbS könnte etwas gebrauchen, das in der Lage ist, werbliche Artikel, Marketingsprache und unneutrale Darstellungen zu erkennen, ohne dass man von Hand in der Suchfunktion groß rumfummeln muss. Es gibt eine Liste von Wörtern und Formulierungen, die ganz hilfreich zur Suche von zehntausenden solcher unenzyklopädischen Artikel ist. --Schlesinger ^schreib! 13:53, 6. Dez. 2023 (CET)

Bessere Vorschläge für Verlinkungen über den Verlinken-Button

Was ist das Problem?

Wer im Visual Editor auf das Verlinken-Symbol klickt und anfängt zu tippen, erhält Vorschläge zu möglichen Zielartikeln mit der Wikidata-Definition. Sie lassen sich wie eine Art Autovervollständigung nutzen. Vor allem aber sind sie nützlich, um bei Namensgleichheiten den richtigen Artikel zu treffen. Diese Vorschläge funktionieren aber nur per Erweiterung des Eingegebenen um weitere Buchstaben am Ende, nicht um weitere Buchstaben in der Mitte.

Beispiel: Ein spanischer zweiter Nachname wird gefunden, weil er am Ende steht. Ein russisches Patronym wird nicht gefunden, weil es in der Mitte steht.

Wenn ich „Javier Fernandez“ eintippe, erhalte ich als Vorschläge

• Javier Fernández Aguado, spanischer Wirtschaftswissenschaftler und Autor
• Javier Fernández López (Eiskunstläufer), spanischer Eiskunstläufer
• Javier Fernández López (Handballtrainer), spanischer Handballspieler und Handballtrainer

und viele mehr. Das ist nützlich und macht das richtige Verlinken einfach.

Wenn ich „Nikita Wolodin“ eintippe, erhalte ich als einzigen Vorschlag die Begriffsklärungsseite Nikita Wolodin.
Hilfreich wäre, wenn ich zusätzlich die beiden dort gelisteten Personen

• Nikita Andrejewitsch Wolodin, russischer Eiskunstläufer
• Nikita Nikolajewitsch Wolodin, russischer Billardspieler

als Vorschläge erhielte. Dann könnte ich sie direkt aus dem Menü auswählen, anstatt erst die BKS zu wählen, diese dann zu besuchen, den richtigen Eintrag zu finden und in meinen zu bearbeitenden Artikel händisch zu übertragen.

Wen betrifft das Problem besonders?

Alle, die den Verlinken-Button nutzen – also wahrscheinlich fast alle, die Wikipedia bearbeiten.

Lösungsvorschlag

Mit meiner begrenzten technischen Kenntnis vermute ich zwei mögliche Wege: 1. die Suchfunktion so zu gestalten, dass sie Erweiterungen in der Mitte des Begriffs findet; 2. sie so zu gestalten, dass beim Versuch, auf eine Begriffsklärung zu verlinken, die auf der BKS gelisteten Artikel in die Vorschläge einbezogen werden.

Anmerkungen

Mir ist bewusst, dass dies im Grunde nur ein Teilaspekt des größeren Themas „Suchfunktion“ ist. Vielleicht lässt sich der Wunsch mit anderen zusammenführen.

Vorschlagende Person

Mushushu (Diskussion) 15:35, 17. Dez. 2023 (CET)

Diskussion

Anderes Beispiel, was mir heute bei einem Neuling begegnet ist: Wenn ich den Verlinken-Button für das Wort Ermittlungen nutze, kommen lediglich zwei Vorschläge (Ermittlungen gegen einen über jeden Verdacht erhabenen Bürger und Ermittlungen gegen Hernando de Talavera), die beide nicht gemeint sind. Das Tool sollte mir sinnvollerweise auch alle Vorschläge anzeigen, die ich beim Stichwort Ermittlung erhalte, insbes. Ermittlungsverfahren. --Johannnes89 (Diskussion) 18:53, 17. Dez. 2023 (CET)

Datenbank für häufig genutzte Literatur

Was ist das Problem?

Aktuell müssen häufig genutzte Quellen entweder in jedem Artikel neu als Einzelnachweis generiert werden oder werden aus einem anderen Artikel händisch kopiert. Viele Nutzer/innen speichern häufig verwendete Literatur auf einer Benutzerseite. Von dort müssen sie dann händisch kopiert und in einen Artikel eingefügt werden. Wer mit viel Literatur arbeitet, sammelt dabei sicherlich einen ganzen Batzen an und muss sich eine Struktur überlegen, alles manuell sortieren und bei Bedarf durchsuchen. Das beschriebene Verfahren funktioniert, erscheint mir aber unbequem und zeitaufwendig. Als neuer Benutzer musste ich mir das auch erstmal von erfahrenen Nutzer/innen erklären lassen.

Wen betrifft das Problem besonders?

Jede/r der/die Artikel schreibt, verbessert, redigiert und dabei Einzelnachweise einfügt.

Lösungsvorschlag

Eine individualisierte Literatur-Datenbank für jede/n Benutzer/inn. Auf diese Datenbank kann aus jedem Artikel zugegriffen werden, um Einzelnachweise schnell einzufügen.

Ich weiß nicht, ob über dieses Thema in der Vergangenheit schon diskutiert wurde. Eigentlich ist es ja eine recht naheliegende Sache. Von den technischen Hintergründen und Möglichkeiten habe ich keine Ahnung. Mit meinem Laienwissen über IT formuliere ich mal zwei Vorschläge:

1. Es wird ein Helferlein programmiert, das beim Einfügen eines Einzelnachweises neben den üblichen Möglichkeiten zum Erzeugen von Einzelnachweisen die Möglichkeit gibt auf die eigene Datenbank zuzugreifen. Diese Datenbank könnte beispielsweise mittels einer Vorlage auf einer Benutzerseite angelegt werden. Das Helferlein greift dann immer auf diese Benutzerseite zu und zeigt die dort bereits gespeicherte Literatur zum Einfügen im aktuellen Artikel an. So würde das manuelle Verfahren technisiert werden. Schön wäre, wenn es auch einen Button gibt, um Literatur in diese Datenbank zu übernehmen, andernfalls kann sie einmalig manuell hinzugefügt werden.

2. Es wird eine Konnektivität mit einer auf dem PC installierten Literaturverwaltungssoftware (bspw. Zotero als freie Software) hergestellt. Für Zotero gibt es bereits Add-Ons in verschiedenen Browsern, die das Speichern von Internetseiten in der Zotero-Datenbank ermöglichen. Es müsste technisch möglich sein, dass das Plugin auf die lokale Datenbank zugreift und dann Einzelnachweise für Wikipedia erstellt.

Lösung 1 ist wahrscheinlich die niedrigschwelligste, da alles innerhalb der Wikipedia bleibt. Außerdem wäre Lösung 2 vermutlich limitiert auf die Webbrowser, für die ein solches Tool implementiert wird.

Anmerkungen

Vielleicht ist es ein Luxus-Problem, aber ein solches Tool würde in meinen Augen für mehr Komfort beim Editieren sorgen.

Vorschlagende Person

Plumerianer (Diskussion) 10:32, 18. Dez. 2023 (CET)

Diskussion

Grundlegende Überarbeitung des Vorlage:Bibel

Mit der Vorlage:Bibel kann leicht auf Bibelstellen verlinkt werden. Diese liegen auf externen Servern, so dass sich die Links bzw. die Linkbildung gelegentlich ändern oder auch die Server wechseln. Dies führt dann zu Fehlerbehebungen, die immer wieder für Ärger sorgen. Siehe z.B. Vorlage_Diskussion:Bibel#Link auf Vulgata funktioniert nicht. Meiner Meinung nach braucht es eine Vorlage mit einer ordentlichen SW-Struktur, die zwischen

• Parsen der Vorlagen-Parameter
• Bilden des html-Links aus einem Basislink (inkl. Server) und dem Verweis auf die genannte Stelle. Ggf. eine Rückfallebene, falls das gewünschte nicht verfügbar ist
• Darstellung im Artikeltext

unterscheidet. --Hfst (Diskussion) 11:30, 20. Dez. 2023 (CET)

verbesserte Datumssortierung in Tabellen

Was ist das Problem?

Vgl. Hilfe Diskussion:Tabellen#data-sort-type="date" (Permalink): Die Sortierung von Kalenderdaten ist von den Benutzereinstellungen abhängig. Das ist hierzuwiki besonders unpraktisch, weil je nach Einstellungen der Jänner oder der Januar nicht als Monat erkannt wird und falsche (misslungene) Sortierungen erzeugt werden.

Die vorhandene Lösung Vorlage:DatumZelle scheint mir angesichts des (enormen?) Umfangs des Problems nicht optimal zu sein. Nichts deutet darauf hin, dass Januar-Daten aufgrund dieses Problems nur mit der Vorlage eingespielt werden sollten. Ich kann nicht einmal einschätzen, wie viele Tabellen/Tabellenzellen betroffen sind und nachgerüstet werden sollten. Jedenfalls gibt es keine Benutzereinstellung, mit der Januar und Jänner ohne Vorlagenverwendung korrekt sortiert werden.

Da die Projektsprache eigentlich klar definiert ist (und zwar als Deutsch), sollte die Sortierung nur von dieser abhängig sein und Varianten (hier Jänner/Januar, im Spanischen septiembre/setiembre, etc.) keine Probleme verursachen. Oder anders gesagt: Wenn es data-sort-type="date" gibt, sollte das auch praxisnah funktionieren.

Wen betrifft das Problem besonders?

Leser und Ersteller von Tabellen

Lösungsvorschlag

siehe oben: Umprogrammierung von data-sort-type="date", sodass es mit Varianten klarkommt.

Vorschlagende Person

… «« Man77 »» Alle Angaben ohne Gewehr. 11:43, 10. Jan. 2024 (CET)

Diskussion

(nicht signierter Beitrag von Man77 (Diskussion | Beiträge) 11:43, 10. Jan. 2024 (CET))

farben bei Ansicht der Änderungen kräftiger gestalten, damit sie besser sichtbar/erkennbar sind auch für Benutzer, die nicht exzellent sehen.

Was ist das Problem?

Die angeblich farbigen Hervorhebungen in der Versionsgeschichte, wenn jemand etwas geändert hat, sind fast unsichtbar. Könntet ihr nicht die Farben bitte von pastell zu kräftig ändern? Ich such mir immer einen Wolf, um zu verstehen, was geändert wurde, und das ist echt mühsam - ich sehe es einfach nicht, weil eure Markierungen a winzig sind und b in pastell.

Wen betrifft das Problem besonders?

Benutzer, die es nicht ganz so leicht haben, Farben zu erkennen und zu unterscheiden.

Lösungsvorschlag

Farben kräftiger darstellen; Farbtöne ändern; Standardfarbtöne kräftiger darstellen

Vorschlagende Person

Benutzerin:Naomi Hennig (Difflink) (nicht signierter Beitrag von Tommes (Diskussion | Beiträge) 22:46, 11. Jan. 2024 (CET))

Diskussion

Die Farben wurden erst kürzlich angepasst und kräftiger gemacht, siehe phab:T361717. --Thiemo Kreuz (WMDE) 15:04, 9. Okt. 2024 (CEST)

Bearbeiten von TimedText beim Ansehen eines Videos

Was ist das Problem?

• Welche Schritte durchläufst du dabei?
  1. Ich sehe und höre mir ein Video mit Closed Captions/ Timed Text/ Untertiteln an, z.B. File:WikiCon 2023 - Abschlussveranstaltung.webm
  2. Ich aktiviere die Closed Captions/ Timed Text/ Untertiteln bei der Wiedergabe.
  3. Ich stelle fest, dass die Captions/ Timed Text/ Untertitel an genau der Stelle fehlerhaft sind, die ich mir gerade ansehe und möchte diesen Teil verbessern.
  4. Dafür muss ich mich zuerst zur Dateibeschreibungsseite durchhangeln, dann auf den Reiter TimedText klicken, dann die richtige Sprache ausfwählen (in diesem Fall "de - Deutsch"), dann auf "bearbeiten" klicken, dann die richtige Stelle finden, dann die Korrektur vornehmen und dann speichern und dann habe ich nach einmal Korrektur schon keine Lust mehr, weil der Workflow so unglaublich aufwändig ist.
• Was möchtest du machen und warum?
  • Ich möchte TimedText an Ort und Stelle beim Ansehen des Videos bearbeiten, um Fehler direkt zu korrigieren.
• Welche Probleme treten auf?
  • Es der Video-Wiedergabe-Fluss wird durch die das ganze Rumgeklicke gestört und es ist sehr zeitfressend.

Wen betrifft das Problem besonders?

Alle, die Closed Captions/ Timed Text/ Untertitel beim Ansehen eines Videos bearbeiten möchten.

Lösungsvorschlag

Editor im Player, der mir direkt erlaubt, die aktuell angezeigte Untertitel-Zeile zu korrigieren.

Anmerkungen

• Die Untertitel, die so bearbeitet werden, müssen natürlich schon gut getimed sein. Wenn ASR wie OpenAI Whisper verwendet wurde, ist das aber schon der Fall und man muss nur falsch verstandene Worte austauschen.
  Vorschlagende Person

rillke fragen? 15:02, 4. Feb. 2024 (CET)

Diskussion

Hochladeassistent/ Smartphone App für iOS/ iPhone

Was ist das Problem?

Es gibt inzwischen die Commons Mobile app für Android. Die Version für das iPhone wurde aber offenbar schon vor vielen Jahren (2014?) wieder zurückgezogen.

Angesichts der Verbreitung des iPhone wundert es mich schon, dass es im Jahr 2024 noch nicht möglich ist, die hiermit aufgenommenen Bilder direkt zu Commons hochzuladen. Es muss doch zig-Zehntausende iPhone-Nutzer unter den bei Commons aktiven Genossen geben, die gerne auch mal von unterwegs etwas hochladen möchten. Und immer alles erst vom Telefon oder der Cloud auf den Computer zu ziehen und dann hochzuladen, kann ja schon recht mühsam sein.

Wen betrifft das Problem besonders?

Alle iPhone besitzer, die ihre Telefon-Kamera nutzen möchten, um Bilder zu Commons hochzuzladen.

Lösungsvorschlag

Im AppleAppStore findet man einzig den Wiki Uploader, der im Prinzip auch ziemlich toll ist, aber aufgrund einiger Problemchen, die ich hier beschrieben habe, nur sehr beschränkt nutzbar ist.

Sofern nicht demnächst eine Eigenproduktion ausgerollt wird, wäre es doch ganz toll, wenn sich vielleicht einer unserer 160 Mitarbeiter, die wir offenbar alleine in der deutschen Wikimedia Foundation haben, mal mit der Entwicklering vom "Wiki Uploader" Lyudmyla Ivanova in Verbindung setzt und sie fragt, ob wir ihr nicht ein Monatssalär dafür spendieren können, dass sie ihr Helferlein aktualisiert und wartet oder die Rechte an Wikimedia verkauft. Sie muß ja auch von etwas leben.

Vorschlagende Person

Kai Kemmann (Diskussion) - Verbessern statt löschen - 01:05, 5. Feb. 2024 (CET)

Diskussion

Standardmäßiges Aktivieren diverser Helferleins für alle Benutzer und Pflege mit aktuellen Skins

Für die Pflege von

• Normdaten
• Personendaten
• Kategorien
• Wikidata-Objekten
• Begriffsklärungen
• Nekrolog

usw. sollten diverse Helferleins für alle Benutzer standardmäßig aktiviert werden, die Tools sollten mit den jeweils aktuellen Skins (Vector22 etc.) getestet und gewartet werden.

Beispielsweise:

• deutschsprachige Wikipedia:
  • de:Benutzer:Schnark/js/personendaten/normdaten
  • de:Wikipedia:Helferlein/Begriffsklärungs-Check
  • de:Wikipedia:Helferlein/HotCat
  • de:Benutzer:Wurgl/8Schwestern
  • de:Benutzer:Wurgl/Nekrolog
• alle Projekte (z.B. auch Commons) und Sprachen:
  • meta:AutosuggestSitelink
  • d:Help:Infobox_export_gadget/de
• Wikidata:
  • d:User:Bargioni/moreIdentifiers
  • d:User:Bargioni/QuickNames
  • d:User:Frettie/consistency check add.js
  • d:User:MichaelSchoenitzer/quickpresets
  • d:User:YMS/labelcollect.js
  • Duplicate Item tool
  • moveClaims

Was ist das Problem?

• Diverse wichtige Helferleins müssen bislang explizit manuell pro Benutzer aktiviert werden, anstatt standardmäßig für alle aktiv zu sein
• teilweise wurden diese von Usern gepflegt, die nicht mehr aktiv sind
• teilweise funktionieren diese mit der Umstellung von Skins nicht mehr

Wen betrifft das Problem besonders?

Anmerkungen

Siehe auch

• https://de.wikipedia.org/w/index.php?title=Wikipedia%3AFragen_zur_Wikipedia&diff=242157597&oldid=242152535
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Häufig_fehlende_Kategorien,_Normdaten,_Personendaten,_Links_auf_BKLs,_falsche_Commonscat,_etc._bei_neu_anlegten_Artikeln_bzw._vom_BNR_in_den_ANR_verschobenen_Artikeln
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten
  Vorschlagende Person

M2k~dewiki (Diskussion) 17:45, 13. Feb. 2024 (CET)

Diskussion

Ob die Skripte standardmäßig aktiv sein sollten, möchte ich offenlassen. Jedenfalls sollte es eine Lösung geben, um sicherzustellen, dass solche Skripte, die eine gewisser Verbreitung haben, gepflegt und an die Entwickung der Skins laufend angepasst werden. Zumal es Benutzer geben dürfte, die es vom Umstieg auf neuere Skins abhält, wenn ihr gewohntes Skript dort nicht funktioniert. Viele Grüße, Aschmidt (Diskussion) 18:26, 13. Feb. 2024 (CET)

HotCat ist jetzt so alt und verbreitet, dass ich mich frage, warum etwas Vergleichbares noch immer nicht Teil der MediaWiki-Software ist. Schaut man sich die Bearbeitungshistorie auf Commons an, stellt man leicht fest, dass dort zahlreiche WMF-Entwickler (mindestens 6) an Kompatibilitäts-Fixes mitgewirkt haben, seit es der Ersteller/Maintainer nicht mehr tat. Ob WMF-Entwickler die Fixes an ihrem "Community Friday" oder in ihrer regulären Arbeitszeit oder sogar ihrer Freizeit durchführten, geht bei einigen nicht hervor. Dennoch zeigt es, dass das Gadget wiki-übergreifend eingesetzt und als sehr wichtig empfunden wird. Die Diskussion, dass Commons hier als Code-Repository herhält mache ich an dieser Stelle lieber nicht auf. Eine dem Gadget gleichwertige Fähigkeit der schnellen Kategorisierung gehört meines Erachtens in den MediaWiki Kern, mit dazu gehörigen Integrationstests, damit es bei neuen Skins oder sonstigen Änderungen nicht zu den angesprochenen Problemen kommt. Für die übrigen Helferlein könnte es gern gut beschriebene Prozesse geben, um Integrationstests vollautomatisch vor dem Ausrollen neuer MediaWiki Versionen und mit neuen Skins zu testen. Ich weiß noch, wie sehr Lupo immer hinterher war, HotCat manuell auf den beta-Servern zu testen, damit alles lief, wenn die neue MediaWiki Version auf Commons ausgerollt wurde. -- rillke fragen? 19:10, 19. Feb. 2024 (CET)

• Personendaten, Normdaten und Sortierschlüssel sollten auch vom VisualEditor unterstützt werden, sofern noch nicht der Fall
• ein fehlendes References-Tag könnte ggf. automatisch beim Speichern ergänzt werden (auch beim VisualEditor)
• Beim Versuch, Artikel ohne Kategorien zu speichern könnte eine Meldung an den Benutzer erfolgen, Basiskategorien bei biografischen Artikel könnten ggf. automatisch vorgeschlagen werden (analog de:Benutzer:Schnark/js/personendaten/normdaten), auch beim VisualEditor --M2k~dewiki (Diskussion) 17:34, 21. Feb. 2024 (CET)

Erweiterung der Funktion Belegen bei Büchern auch auf Quelltextebene

Was ist das Problem?

Erweiterung 1:

Zusätzlich zu der Angabe von Seiten, sollte zusätzlich Zu Seite (S.) ermöglicht werden, Kapitel (K.) anzugeben. Bei E-Books gibt es keine feste Seitenzahl, die Kapitelangabe ist oftmals die einzige Möglichkeit, die Textstelle einzugrenzen. Zusätzlich könnte man dadurch bei E-Book und Printmedium auf denselben Abschnitt verweisen.

Erweiterung 2:

Die Funktion <ref name="xyz"> sollte um Seitenzahl/Kapitel erweitert werden, damit man übersichtlich auf verschiedenen Seiten/Kapitel hinweisen kann

Wen betrifft das Problem besonders?

alle

Lösungsvorschlag

Derzeit in der Literaturliste:

1. a b Grundgesetz für die Bundesrepublik Deutschland. 71., neu bearbeitete Auflage, Stand 13. Juni 2023. C.H.Beck, Ort=München 2023, ISBN 978-3-406-81106-7, S. 142.

3. Grundgesetz für die Bundesrepublik Deutschland. 71., neu bearbeitete Auflage, Stand 13. Juni 2023. C.H.Beck, Ort=München 2023, ISBN 978-3-406-81106-7, S. 242.

12. Grundgesetz für die Bundesrepublik Deutschland. 71., neu bearbeitete Auflage, Stand 13. Juni 2023. C.H.Beck, Ort=München 2023, ISBN 978-3-406-81106-7, S. 442.

18. Grundgesetz für die Bundesrepublik Deutschland. 71., neu bearbeitete Auflage, Stand 13. Juni 2023. C.H.Beck, Ort=München 2023, ISBN 978-3-406-81106-7, S. 42.

Besser der Übersicht wegen bei großen Artikeln

1. a b (S 242) Grundgesetz für die Bundesrepublik Deutschland. 71., neu bearbeitete Auflage, Stand 13. Juni 2023. C.H.Beck, Ort=München 2023, ISBN 978-3-406-81106-7, S. 142.

3. S. 242. / 12. S. 442 / 18. S. 42

Oder ähnlich

Abzuwägen ist allerdings, ob die Verkürzung der Literaturliste gegen Durchbrechung der Zitatreihenfolge in Kauf genommen werden kann (und technisch möglich ist)

Anmerkungen

Punkt zwei dürfte noch ausreichend Diskussionsbedarf bestehen...

Vorschlagende Person

Knut Krüger (Diskussion) 20:15, 26. Feb. 2024 (CET) Knut Krüger (Diskussion) 20:15, 26. Feb. 2024 (CET)

Diskussion

Hallo Knut Krüger, danke für deinen Eintrag. An einer solchen Veränderung arbeitet das Team Technische Wünsche gerade: Wikipedia:Technische Wünsche/Topwünsche/Erweiterung der Einzelnachweise. Wir rechnen damit, eine entsprechende Funktion im Laufe dieses Jahres bereitstellen zu können. Das soll dann übrigens nicht nur für Seiten funktionieren, sondern auch für Kapitel und Verse usw. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:12, 27. Feb. 2024 (CET)

automatische Formatierung von Einwohnerzahlen

Was ist das Problem?

auf https://de.wikipedia.org/wiki/Liste_der_Gemeinden_im_Landkreis_Oberallg%C3%A4u#Gemeinden werden die Einwohnerzahlen über 10.000 amerikanisch mit Komma statt mit Punkt formatiert und landen deshalb beim Sortieren weit hinten.

Wen betrifft das Problem besonders?

jeden Leser der die Sortierfunktion benutzt. (und natürlich ist die Zahl auch falsch - innerhalb der Tabelle wird das Komma nicht einheitlich benutzt)

Anmerkungen

Scheint eine automatische Übernahme aus einer Datenbank zu sein - die Bearbeitung dieser Formatierung übersteigt meine Fachkenntnis (und vermutlich auch meine Berechtigung?)

Vorschlagende Person

Jschreiber (Diskussion) 13:01, 5. Mär. 2024 (CET)

Diskussion

--Jschreiber (Diskussion) 13:01, 5. Mär. 2024 (CET)

Hallo Jschreiber, ich habe mir das Problem mal angeschaut und es scheint mir weniger ein Fall für die technischen Wünsche als viel mehr falsche Vorlageneinbindung zu sein. Das Problem ist, dass die Werte zwei mal formatiert werden: In der Vorlage:EWZ wird auf die Zahlen FormatNum angewendet, was ab fünfstelligen Zahlen Tausenderpunkte ergänzt, und in der Liste selbst wird auf die Zahlen formatnum angewendet, was die Punkte als Kommas interpretiert. Ich habe jetzt mal formatnum in der Tabelle entfernt, was wieder für korrekte Sortierung sorgt. Mich persönlich stört zwar, dass es bei vierstelligen Zahlen kein Tausendertrennzeichen gibt. Da das aber der von Vorlage:FormatNum vorgegebene Standart ist, würde ich es erstmal dabei belassen. Vielen Dank für den Hinweis und viele Grüße, DerIch27 (Diskussion) 12:16, 15. Mär. 2024 (CET)

Hintergrundfarbe bei Vorschaubildern (Miniatur)

Was ist das Problem?

Bei Vorschaubildern ist die Hintergrundfarbe standardmäßig #F8F9FA (grau), vgl. Hilfe:Bilder#Vorschaubilder (Miniatur).

Wen betrifft das Problem besonders?

Jeder, der Vorschaubilder in Wikipedia-Artikel einfügt.

Lösungsvorschlag

Oftmals bietet sich weiß, ggf. auch eine andere Hintergrundfarbe an. Die Umsetzung könnte über einen zusätzlichen Wert colour= erreicht werden, indem man Standardfarben wählen kann wie white oder auch Farbcodes, z.B. #F8F9FA. Ohne den Wert bleibt es beim bisherigen Standard-Grau als Hintergrund.

Anmerkungen

Gerade für SVG-Dateien ohne Hintergrund sinnvoll, die Farbe variieren zu können.

Vorschlagende Person

--Asperatus (Diskussion) 11:10, 24. Mär. 2024 (CET)

Diskussion

Umfangreichere Funkionalität von Leselisten der Mobile Apps (iOS/Android)

Was ist das Problem?

Ich möchte in der App:

• Leselisten als privat oder öffentlich markieren können
• öffentliche Leselisten per Link teilen können, in etwa wie ../wiki/Benutzer:USER/reading-list/TITEL oder einer entsprechenden ShortURL
• Artikel mehreren Leselisten zuordnen können
• zusammengefasst also so etwas wie „Dossiers“ anlegen können

Wen betrifft das Problem besonders?

Alle (angemeldeten) Nutzer der mobilen Apps

Lösungsvorschlag

Ich habe keine Kenntnis davon.

Vorschlagende Person

TagWerk (Diskussion) 16:09, 10. Apr. 2024 (CEST)

Diskussion

(nicht signierter Beitrag von TagWerk (Diskussion | Beiträge) 16:09, 10. Apr. 2024 (CEST))

Wikidata-Änderungen führen zu Artikeländerungen

Was ist das Problem?

Änderungen von eingebundenen Daten aus Wikidata sollen nicht unbemerkt bleiben, sondern zu einer neuen Artikelversion führen, die erst gesichtet werden muss.

Dies soll die Akzeptanz erhöhen, Wikidata-Objekte in Artikel einzubinden.

Wen betrifft das Problem besonders?

Autoren, Sichter

Vorschlagende Person

Sinuhe20 (Diskussion) 06:56, 21. Apr. 2024 (CEST)

Diskussion

(nicht signierter Beitrag von Sinuhe20 (Diskussion | Beiträge) 06:56, 21. Apr. 2024 (CEST))

Bearbeitungskommentar zur Pflicht machen

Was ist das Problem?

{{{Was ist das Problem?}}}

Wen betrifft das Problem besonders?

Changes-Interessierte wie ich, der viel watches, aber auch Admins, Vandalismusbekämpfer etc.

Lösungsvorschlag

Wenn sich der Inhalt des Zusammenfassungsfeldes für die Bearbeitung nicht geändert hat, ein Hinweis „Bitte beschreiben...was geändert wurde“

Anmerkungen

{{{Anmerkungen}}}

Vorschlagende Person

Hlambert63 (Diskussion) 20:15, 18. Jun. 2024 (CEST)

Die Vorlage vom grünen Knopf neuen Vorschlag tut nicht oder ich blicks nicht :-( --Hlambert63 (Diskussion) 20:18, 18. Jun. 2024 (CEST)

Diskussion

Umgang mit Rotlinks

Was ist das Problem?

z. Zt. öffnet sich, wenn man auf einen Rotlink klickt, der visuelle Editor. Man wird sozusagen dazu aufgefordert den Artikel zu schreiben, aber ohne jede Hintergrundinfo. Inzwischen gibt es oft zu Rotlinks ein Wikidata-Objekt, was hilfreich wäre, worauf man aber nicht weitergeleitet wird. Auch weiß man nicht, von wo überall auf den Rotlink verwiesen wird. Das wäre aber ebenfalls eine hilfreiche /wichtige Information.

Wen betrifft das Problem besonders?

Leser & Schreiber von Artikeln

Lösungsvorschlag

Bei Klick auf einen Rotlink sollte man entweder zum entsprechenden Wikidata-Objekt weitergeleitet werden (welches ggbf. sogar automatisch erstellt werden sollte) oder zu einer Übersicht kommen, von welchen Punkten aus auf das Lemma des Rotlinks verwiesen wird.

Der Editor sollte gar nicht aufgehen.

Vorschlagende Person

Kreuz Elf (Diskussion) 18:45, 2. Aug. 2024 (CEST)

Diskussion

Den Wunsch würde ich sehr unterstützen. Aus meiner Erfahrung wird oft sogar versucht, Rotlinks zu vermeiden, weil sie gefühlt zur Verwirrung von Lesenden beitragen. Auch sieht der Artikel mit mehreren Rotlinks für Lesende so aus, als weise der Artikel selbst irgendwelche Mängel oder Probleme auf. Rot markierter Text steht schließlich intuitiv für Fehler/Falsch/Achtung/Gefahr. Auch Schreibende vermeiden deshalb Rotlinks mitunter rein aus ästhetischen Gründen. Fehlen Artikel, werden oft Weiterleitungen auf ähnliche Artikel eingerichtet, um die Lesenden nicht per Klick auf den Rotlink automatisch in die Verantwortung eines Schreibenden zu transferieren, ohne jegliche weitere Unterstützung und Informationen konkret bezogen auf das Lemma. Weiterleitung macht bei Synomen etc. Sinn, nicht aber, wenn tatsächlich ein eigenständiger Artikel fehlt. Ergebnis der Weiterleitung ist, dass kein Rotlink auftaucht, und somit der Bedarf an dem neuen Artikel weder technisch noch menschlich gut erkannt werden kann (aktuelles Beispiel war die Weiterleitung von Pastellfarbe und Pastellton auf Pastellmalerei, Problem war seit mehr als 15 Jahren bekannt, vor wenigen Tagen wurde es endlich gelöst). Im Endeffekt erfüllen Rotlinks bisher nur eingeschränkt die Funktion, die sie eigentlich haben sollen. Die hier vorgeschlagene Lösung möchte ich aus den o.g. Gründen unterstützen und zusätzlich anregen, dass anstatt roter Farbe ein helles blau oder grau verwendet wird, um den Eindruck eines Fehlers im Artikel zu vermeiden. Das könnte die Verbreitung/Anwendung der "Rotlinks" deutlich verbessern und gleichzeitig Irritation der lesenden vermeiden.--Max schwalbe (Diskussion) 14:31, 20. Aug. 2024 (CEST)

Ich unterstütze den Vorschlag ebenfalls und möchte ihn noch ein wenig konkretisieren:
Es geht darum, einem Rotlink nicht nur wie bisher üblich den "anzuzeigenden Namen" („[[Thomas Müller (Regisseur)|Thomas Müller]]“) sondern zusätzlich auch noch die Wikidata-ID mitgeben zu können (also „[[Thomas Müller (Regisseur)|Thomas Müller||Q5999317]]“). Dies ermöglicht es, auf der Landing-Page, auf die man momentan gelangt, wenn man auf einen Rotlink klickt, eine Vielzahl neuer Optionen anbieten zu können:

• Artikel erstellen mit dem Visual Editor
• Artikel erstellen mit dem Quelltext-Editor
• Artikel lesen in einer der folgenden Sprachen: <es folgt das Angebot der auf dem Wikidata-Item vorhandenen Sprachen, hier also sv:Thomas Müller (regissör)>
• Artikel für die deutschsprachige Wikipedia übersetzen aus einer der folgenden Sprachen: <es folgt das Angebot der auf dem Wikidata-Item vorhandenen Sprachen mit Link zum Content Translation Tool>
• Wikidata-Eintrag anzeigen
• ...

...und irgendwann vielleicht sogar: KI-generierten Artikel aus Wikidata-Daten anzeigen.

Das technische Möglichkeit der Hinterlegung der WD-ID anzubieten (selbst wenn sich das Verhalten nach außen nicht ändert) hätte zumindest den Vorteil, dass keine Verwechselung mehr möglich ist („welcher Thomas Müller ist hier gemeint?“) und auch Synonyme (hier bspw. [[Thomas Hilding Herthelius Müller||Q5999317]] auf das gleiche Objekt zurückgeführt werden können.--Mabschaaf 20:29, 21. Aug. 2024 (CEST)

Verbesserung der Anzeige bei der Edit-Patrol

Was ist das Problem?

Ich nutze gerne in der Android App bei Bearbeiten die "Edit-Patrol". Nun ist es mir schon häufiger passiert, dass mir Seiten angezeigt wurden und ich sie manchmal mit etwas Mühe (reinlesen ins Thema, User anschauen) kontrolliert und die letzten Eintragungen rückgängig gemacht habe. Beim Blick in die Versionsgeschichte fiel mir auf, dass jemand anderes auch schon gemacht hatte und eher fertig war, d.h. meine Mühe war umsonst

Wen betrifft das Problem besonders?

Jeden User der gerne hilft

Lösungsvorschlag

Sperrung der Seite falls jemand anderes schon bearbeitet oder eine Art Anzeige, so dass man nicht gleichzeitig dran ist

Vorschlagende Person

Gerhardbeck (Diskussion) 00:19, 24. Aug. 2024 (CEST)

Diskussion

Hi @Gerhardbeck, mit Apps können sich die WMDE Technischen Wünsche leider nicht beschäftigen, weil sich darum Teams der Wikimedia Foundation kümmern. Ich habe dein Feedback weitergeleitet [18], es gibt nun das Ticket phab:T376479 für deinen Vorschlag. --Johannes Richter (WMDE) (Diskussion) 11:51, 16. Okt. 2024 (CEST)

@Johannes Richter (WMDE) Danke fürs Weitergeben!Gerhardbeck (Diskussion) 00:37, 17. Okt. 2024 (CEST)

"Bearbeiten"-Modus auf Projekt- und deren Unterseiten ermöglichen

Was ist das Problem?

• Auf Projektseiten lässt sich, soweit ich weiß, nur im Quelltext arbeiten. Beispiel: Wikipedia:FilmFrauen/Berlinale-Edit-a-thon 2024 Das behindert z. B. bei der einfachen Bearbeitung von Tabellen. Unpraktisch ist es auch, wenn man Unterseiten anlegt, auf denen bei einer Veranstaltung Neulinge arbeiten sollen; die sind - anfangs zumindest - nur mit dem VE vertraut.
• Ich möchte gerne beide Bearbeitungsmodi zur Verfügung haben / ermöglichen. Falls sich das jetzt schon durch eine Einstellung lösen lässt, sagt mir bitte, welche!

Wen betrifft das Problem besonders?

• Alle, die mit Projektseiten zu tun haben - also viele.
• Leute, die gemeinsam an Artikeln arbeiten und die Entwürfe als Unterseite einer Projektseite anlegen, nicht einer individuellen Seite

Vorschlagende Person

LG -- Benutzerin:Reisen8 • Benutzerin Diskussion:Reisen8 • Wikiliebe?! 14:21, 13. Okt. 2024 (CEST)

Diskussion

Hi @Reisen8 danke für die Einreichung. Über deine Einstellungen kannst du den Visual Editor leider nicht im Metabereich aktivieren. Aber erst vor wenigen Wochen wurde bekannt gegeben, dass Projekte nun eine Konfigurationsänderung beantragen können, wenn sie den VisualEditor in anderen Namensräumen haben möchten. Weil der Metabereich aber auch für Diskussionen genutzt wird, und der VisualEditor darauf nicht ausgelegt ist, könnte es sein, dass er dort nicht korrekt funktioniert und die WMF hat auch keine Kapazitäten, bei eventuellen Fehlern zu helfen, siehe mw:Help:VisualEditor/FAQ#WPNS. Im Wesentlichen bräuchte es eine Mehrheitsentscheidung der dewiki Community (z.B. per WP:Umfrage) für eine weitergehende Aktivierung des VisualEditors. Ich würde allerdings empfehlen, das Thema vor einer Umfrage erstmal an anderer Stelle, z.B. WP:Technik/Werkstatt und/oder WP:Fragen zur Wikipedia zu diskutieren, um erste Einschätzungen anderer User zu erhalten. --Johannes Richter (WMDE) (Diskussion) 11:49, 16. Okt. 2024 (CEST)

Wir sitzen hier gerade bei WomenEdit und haben eine Frage dazu: Es ist ja grundsätzlich bereits möglich, Seiten z. B. im Wikipedia-Namensraum visuell zu bearbeiten, indem man &veaction=edit anhängt, also so: https://de.wikipedia.org/w/index.php?title=Wikipedia%3ATechnische_W%C3%BCnsche%2FWunschparkplatz&veaction=edit. Da das also eigentlich bereits geht, das nur fast niemand weiß – hat es denn irgendeinen Nachteil oder birgt es irgendwelche Gefahren, diesen Trick bekannter zu machen? (Ich denke, wer diesen Trick anwenden kann, kann auch mit den eventuellen Nachteilen halbwegs umgehen.) --Mushushu (Diskussion) 19:44, 16. Okt. 2024 (CEST)

Hi @Mushushu, im Normalfall sollte es kein Problem sein, so den VisualEditor zu nutzen. Beim von dir als Beispiel genannten Link sieht man, dass der VisualEditor halt nicht gut mit Diskussionen zurecht kommt (z.B. nicht wirklich versteht, was Signaturen sind). Aber wenn man Diskussionen in Ruhe lässt und nur in Artikelentwürfen, die im Metabereich liegen editiert oder wie Reisen8 ne Tabelle anpassen möchte, sollte alles klappen (und falls doch was nicht gut klappt, kann man den Edit ja immer noch revertieren). Die Variante mit dem &veaction=edit die man bei Links in der Form deines Beispiels anhängt, finde ich persönlich übrigens etwas umständlich und würde einfach den normalen Link nehmen https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz und da ?veaction=edit anhängen -> https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz?veaction=edit --Johannes Richter (WMDE) (Diskussion) 10:28, 17. Okt. 2024 (CEST)

Danke für die ausführliche Antwort! Und stimmt – das ist viel einfacher! --Mushushu (Diskussion) 17:12, 17. Okt. 2024 (CEST)

Vorschaubild oft unpassend

Was ist das Problem?

Ich erstelle ungern Infoboxen, weil das dort integrierte Bild oft nicht in der (Cursor-)Vorschau gezeigt wird, sondern das erste darauf folgende Bild. Zwei Beispiele wären:

• Infobox Gemälde: z.B. Charlotte Berend im Liegestuhl -> zeigt in der Vorschau das Ehepaar Corinth
• Infobox Amt: z.B. Prince of Wales -> zeigt in der Vorschau die Princess

Erfreulich anders ist es bei Infobox Song: z.B. Mambo Italiano (Lied) -> zeigt in der Vorschau das integrierte Bild.

Wen betrifft das Problem besonders?

alle Nutzer der Wikipedia

Lösungsvorschlag

In der Vorschau das Bild aus der Infobox, also das Hauptbild des Artikels, zeigen.

Vorschlagende Person

Artessa (Diskussion) 19:25, 24. Okt. 2024 (CEST)

Diskussion

Hi Artessa, es scheint, als würdest du in deinen Einstellungen unter "Helferlein" die Wikipedia:Technik/Skin/Gadgets/navigation-popups aktiviert haben. Das ist ein von der Community gepflegtes Gadget, also nicht Teil der der MediaWiki-Software, an der die WMDE Technischen Wünsche arbeiten. Ich empfehle, das Thema mal auf Wikipedia:Technik/Werkstatt anzusprechen, um dort zu klären, ob/wie das Gadget ggf. durch Communitymitglieder angepasst werden kann.

Ich persönlich nutze (auch bei meinem Volunteer-Account) dieses Helferlein nicht und habe stattdessen in meinen Einstellungen die in die MediaWiki-Software integrierte Seitenvorschau aktiviert, die im Normalfall auch mit Bildern in der Infobox zurecht kommt (lediglich bei Prince of Wales müsste man noch nachjustieren – weil in der Infobox "class=notpageimage" glaub ich nicht nutzbar sein wird, müsste man wahrscheinlich auf MediaWiki Diskussion:Pageimages-denylist darum bitten, das Bild des Badge auszuschließen). --Johannes Richter (WMDE) (Diskussion) 14:10, 25. Okt. 2024 (CEST)

Hi Johannes, sorry, ich wusste nicht, dass meine Frage gar nicht hierher gehört. Ja, es stimmt, ich habe das besagte Helferlein mal aktiviert, weil es mir mehr zusagt als die Seitenvorschau (mehr Zeichen, keine abgebrochenen Sätze, aussagekräftigerer Inhalt). Wahrscheinlich sehen das aber die meisten Nutzer anders (weshalb das von mir beschriebene Manko wohl auch noch besteht). Danke für die Erklärung und den Tipp. Ich werde mich dann mal an die Technik-Werkstatt wenden. Einen herzlichen Gruß von Artessa (Diskussion) 10:27, 26. Okt. 2024 (CEST)

Einen Punkt hätte ich allerdings noch: Die Seitenvorschau funktioniert bei älteren Versionen nicht. Beispiel Mambo Italiano: Wettbewerbsversion für den Wikipedia:Miniaturenwettbewerb. Wäre es sehr aufwendig, das zu ermöglichen? Das o.g. Helferlein unterscheidet alt/neu nicht. Gruß --Artessa (Diskussion) 11:39, 27. Okt. 2024 (CET)

Hi Artessa, vorweg noch kurz zu Helferlein vs. Seitenvorschau: Ich denke letzteres wurde wohl stärker mit Blick auf Leser*innen entwickelt, während das Helferlein 10 Jahre früher primär von und für Wikipedianer*innen erstellt wurde, entsprechend gibt's ein paar Unterschiede bei den Funktionen. Sollte die Technikwerkstatt beim Helferlein nicht weiterhelfen können, könntest du es im Anschluss auch bei der Wikipedia:Technische Wünsche/Reparaturhilfe probieren (wobei wir da nichts versprechen können, weil unser Team aktuell stark bei Wikipedia:Technische Wünsche/Topwünsche/Subreferenzierung eingebunden ist).

Zur Seitenvorschau: In der Tat funktioniert die leider nicht bei alten Versionen. Ich notier das mal als möglichen Wunsch für die nächste Technische Wünsche Umfrage. Viele Grüße --Johannes Richter (WMDE) (Diskussion) 11:30, 29. Okt. 2024 (CET)

Hi Johannes, es hat ja auch keine Priorität. Danke, dass Du Dich dem Thema gewidmet hast. (Ich fühle mich in guten Händen ;-)) Von meiner Seite kann die Disk. ab ins Archiv. Herzlichen Gruß --Artessa (Diskussion) 13:59, 29. Okt. 2024 (CET)

Diskussion besser einbinden

Was ist das Problem?

Diskussionsseiten werden nicht gelesen Auf der Artikelseite könnte bei einer offenen Diskussion ein wie auch immer geartetes Zeichen darauf hinweisen.

Wen betrifft das Problem besonders?

Leute, die Anregungen geben möchten.

Lösungsvorschlag

Neu eröffnete Fäden mit nur einem Beitrag, also ohne Antwort sollten auf der Artikelseite ein Flag setzen.

Anmerkungen

Wenn da eine Anmerkung über einen längeren Zeitraum nicht beantwortet wird, macht dies die Diskussionsseite entbehrlich.

Eventuell könnte auch ein Ping an den Hauptverfasser eines Artikels gesendet werden.

Vorschlagende Person

Heppina (Diskussion) 21:32, 31. Okt. 2024 (CET)

Diskussion

Unterstützung texturierter 3D Modelle

Was ist das Problem?

Bisher werden von der MediaWiki Extension:3D keine texturierten 3D Modelle unterstützt.

Die aktuellen Entwicklungen bei Sketchfab zeigen, wie wichtig eine nicht-kommerzielle Plattform für den Austausch und die Visualisierung texturierter 3D-Modelle wäre. Zehntausende von 3D-Modellen unter freien Lizenzen sind bedroht, und in einer Petention an Sketchfab heißt es, dies sei „das virtuelle Äquivalent zur Verbrennung der Bibliothek von Alexandria“.

Noch eine andere Entwicklung macht dieses 3D Format so interessant. Heutzutage ist die Erstellung von texturierten 3D-Modellen mit einem Smartphone nicht viel aufwändiger als die Aufnahme eines Fotos oder Videos.

Wen betrifft das Problem besonders?

Alle, die texturierte 3D Modelle hochladen, oder nutzen möchten.

Lösungsvorschlag

Das Dateiformat glTF (Graphics Library Transmission Format) ist ein offener Standard für texturierte dreidimensionale Szenen und Modelle (ISO/IEC 12113:2022).

Während des Wikimedia Hackathon 2024 wurde bereits an der Unterstützung dieses Formats gearbeitet (WIP 1026883).

Die Community hat inzwischen funktionale Prototypen entwickelt, auf denen weitere Arbeiten aufbauen könnten, um die bestehende Extension:3D um das glTF Format zu erweitern.

Tasks: T246901 T187844

Commons:Textured_3D

Vorschlagende Person

OpenDEM (Diskussion) 06:38, 4. Nov. 2024 (CET)

Diskussion