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.
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.
Commons-Nutzer.
Sinnvolle Navigation: << . < . 1 . 2 . 3 . ... . Gehe zu Seite ZZ . > . >> analog Navigation z. B. DNB unten--Frze > Disk 09:15, 28. Jun. 2017 (CEST)
Benachrichtigen farblich differenzieren[Quelltext bearbeiten]
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?
Eine individuelle Einstellung sollte ermöglicht werden.--Frze > Disk 10:02, 28. Jun. 2017 (CEST)
Bei Einbindung ersetzbare Vorlagen/Variablen[Quelltext bearbeiten]
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.
letztlich alle Nutzer, die entsprechende Vorlagen einsetzen, also die meisten
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.--C21H22N2O2 | 디굿숀 | Դիսք | Диск 23:13, 29. Jun. 2017 (CEST)
Höhe der Sonderzeichenleiste verschiebbar machen[Quelltext bearbeiten]
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.
Benutzer, die regelmäßig Sonderzeichen setzen.
Die Sonderzeichenleiste einfach mit Cursorgriff in der Höhe verschiebbar machen.--C21H22N2O2 | 디굿숀 | Դիսք | Диск 16:41, 30. Jun. 2017 (CEST)
Formulardaten merken beim Visual Editor[Quelltext bearbeiten]
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.)
Alle, die den Visual Editor benutzen
phab:T50274, Benutzer:Schnark/js/veSummary--Mushushu (Diskussion) 17:17, 30. Jun. 2017 (CEST)
- 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[Quelltext bearbeiten]
Wenn man ein einer Anmerkung[A 1] 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>).
- ↑ Eine Anmerkung ist ein erklärender Hinweis in einer <ref>-Umgebung.
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.
Verschachtelte <ref>'s zulassen und somit den Referenzfehler: Es fehlt ein schließendes </ref>. eliminieren.— Johannes Kalliauer - Diskussion | Beiträge 17:13, 2. Jul. 2017 (CEST)
- 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)
- 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)
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.
- Einzelnachweise
- ↑ Mit einem Belegtag
- Für Fußnoten gibt es die Vorlagenreihe {{FN}} {{FNZ}} {{FNBox}} Allerdings erschließt sich mir nicht wirklich weshalb man ein
ref in refsetzen sollte. --Liebe Grüße, Lómelinde Diskussion 14:28, 21. Mai 2020 (CEST)
Kein Zeilenumbruch vor Einzelnachweisen[Quelltext bearbeiten]
Zwischen einem Wort/Interpunktionszeichen und der folgenden Ziffer, die einen Einzelnachweis anzeigt, soll nie ein Zeilenumbruch entstehen.
Leserinnen und Leser
--Mushushu (Diskussion) 17:18, 2. Jul. 2017 (CEST)
- 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)
- Weil das nebenan auch kürzlich aufkam habe ich das auch kurz getestet: Nein, funktioniert nicht. --nenntmichruhigip (Diskussion) 11:05, 26. Sep. 2019 (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)
- 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)
- So einfach ist das? Na, dann wird es ja Zeit. :) Danke fürs technische Ausformulieren, FNDE! --Mushushu (Diskussion) 11:56, 17. Jul. 2017 (CEST)
- Dann der konkrete Vorschlag an die Entwickler: den hochgestellten Refs einfach
- @FNDE: Exakt! --Mushushu (Diskussion) 23:19, 16. Jul. 2017 (CEST)
Zugriffsdatum automatisch generieren (Visual Editor)[Quelltext bearbeiten]
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.)
Benutzer/innen des Visual Editor
--Mushushu (Diskussion) 17:18, 2. Jul. 2017 (CEST)
view-source von SVGs-Links zulassen[Quelltext bearbeiten]
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]
Leute die mit SVG-Grafiken arbeiten.
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.
— Johannes Kalliauer - Diskussion | Beiträge 20:29, 21. Aug. 2017 (CEST)
Automatisches Einfügen von Koordinaten in Fotos auf commons[Quelltext bearbeiten]
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.
Alle Fotografen... Und natürlich die Leser, die den Aufnahmeort auf Karten suchen.
Auswertung der exifdaten, falls vorhanden und automatische Übernahme in die Bildbeschreibung.Nightflyer (Diskussion) 19:41, 31. Aug. 2017 (CEST)
- 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[Quelltext bearbeiten]
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.
Wikipedianer_innen die Bilder aus anderen Sprachversionen verwenden wollen
Es braucht nur eine Textersetzung.
Es wurde von
https://tools.wmflabs.org/svgtranslate/vermutlich gelöst, jedoch scheint das Speichern nicht zu funktionieren.— Johannes Kalliauer - Diskussion | Beiträge 16:16, 7. Okt. 2017 (CEST)
- 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[Quelltext bearbeiten]
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
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.
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.Christallkeks (Diskussion) 23:40, 23. Okt. 2017 (CEST)
Inkscape SVG2PNG-Konverter statt buggy RSVG (phab:T40010)[Quelltext bearbeiten]
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
Grafiker, WP:Grafikwerkstatt, alle Autoren die Vektorgrafiken einbinden wollen (dafür müssen die richtig dargestellt werden)
Statt RSVG einen Inkscape-SVG2PNG-Batch Konverter zum Rendern der SVGs verwenden.- Geschwindigkeit: benchmark
| Program | Median time |
|---|---|
| Batik | 57.76 s |
| ImageMagick | 81.86 s |
| Inkscape | 70.95 s |
| rsvg | 41.48 s |
— Johannes Kalliauer - Diskussion | Beiträge 21:03, 17. Jan. 2018 (CET)
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 |
Auswertung zu besuchten Seiten[Quelltext bearbeiten]
Selbst als angemeldeter Benutzer hat man keine Übersicht (weder grafisch noch in Zahlen), welche Seiten man wie oft aufgerufen hat.
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.
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.HirnHerzHand (Diskussion) 12:50, 22. Mär. 2018 (CET)
Crosswiki-Beobachtungsliste[Quelltext bearbeiten]
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.
Alle, die sich auch für anderssprachige Projekte interessieren.
Irgendeiner programmiert das halt so, sofern das technisch geht... :)Informationswiedergutmachung (Diskussion) 15:43, 29. Mai 2018 (CEST)
@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[Quelltext bearbeiten]
Die aktuelle Zusammenfassungszeile im Quelltexteditor besteht aus einer einzigen Zeile. Wenn der eingegebene Text zu lang ist, verliert man schnell die Übersicht
Dieses Problem betrifft besonders Personen, die den Quelltexteditor verwenden und gerne längere Zusammenfassungen angeben möchten.
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)
--Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (Diskussion) 22:08, 5. Jun. 2018 (CEST)
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[Quelltext bearbeiten]
Umlaute und andere Sonderzeichen werden in TeX-Formeln nicht korrekt dargestellt (Beispiel: Kuppelproduktion). Dies sollte daher entsprechend angepasst werden.
Alle NutzerInnen
--134.61.100.245 21:27, 9. Sep. 2018 (CEST)
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)
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.
Alle NutzerInnen
--134.61.100.245 21:27, 9. Sep. 2018 (CEST)
Zitatvorlagen optimieren[Quelltext bearbeiten]
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.
Alle NutzerInnen
[1]--134.61.100.245 21:27, 9. Sep. 2018 (CEST)
Gleichzeitige Vergleichs- und Vorschauansicht[Quelltext bearbeiten]
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.
Alle Bearbeitenden
--134.61.100.245 21:27, 9. Sep. 2018 (CEST)
Interaktive (dynamische) Karten[Quelltext bearbeiten]
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.
Alle NutzerInnen
[2]--134.61.100.245 21:27, 9. Sep. 2018 (CEST)
Das Wissen der Menschheit: Suche nach Informationen nach Raum (Erde / Universum) und Zeit (Erdzeit / Zeit des Universums)[Quelltext bearbeiten]
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? …
Benutzergruppe: alle Menschen heute und in x Jahren
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.Klaus D K Welt (Diskussion) 14:57, 31. Jan. 2019 (CET)
@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[Quelltext bearbeiten]
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.
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.
Wir entwickeln und erkunden die Anforderungen einer solchen Software bei WikiDienstag #Sprint7 und wollen bald möglichst ein MVP realisieren: Work in Progress. Workshop-Vorschlag an der WikiCon19Wir freuen uns über Feedbacks: WikiDienstag - Wir koordinieren unsere Arbeit hier: #ve4phabricator.
Koordinatenangaben-Umwandler[Quelltext bearbeiten]
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[Quelltext bearbeiten]
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.
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.
- 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-GPGMailzu 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.
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.Keks um 18:18, 5. Apr. 2019 (CEST)
Einzelnachweise[Quelltext bearbeiten]
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?
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[Quelltext bearbeiten]
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.
Autoren, die nur gelegentlich Einträge in Wikidata aktualisieren.
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)
Tkarcher (Diskussion) 17:25, 15. Apr. 2019 (CEST)
Versionen zusammenfassen[Quelltext bearbeiten]
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.
Leser und Benutzer, die sich mit der Versionsgeschichte beschäftigen.
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.--Berlinschneid (Diskussion) 19:57, 16. Apr. 2019 (CEST)
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)
- @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)
Umgang mit Geoinformationen und Karten professionalisieren[Quelltext bearbeiten]
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. ==
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.
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.)
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. Präsentation möglichst aller Anwendungen von Geodaten im Wikipedia-Umfeld: https://tools.wmflabs.org/wp-world/docs/Wikicon2019-WP-OSM.pdf (13MB)Kolossos 19:57, 27. Apr. 2019 (CEST)
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[Quelltext bearbeiten]
- 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.
alle
- 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.
Keks um 23:29, 2. Mai 2019 (CEST)
Info: DIFF 189651908 --Keks Ping mich an! um 19:07, 18. Jun. 2019 (CEST)
Karte mit Geodaten bestimmter Bilder in einen Artikel einbinden[Quelltext bearbeiten]
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.
Leser
siehe oben 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.Keks Ping mich an! um 19:05, 5. Mai 2019 (CEST)
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
), 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)
- 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
Info: DIFF 189650475 --Keks Ping mich an! um 18:35, 18. Jun. 2019 (CEST)
Ablaufdatum für Beobachtungsstatus von Seiten (beobachtete Seiten automatisch entfernen)[Quelltext bearbeiten]
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.
Alle
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
- Klick auf den Stern
- 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
- Beim Benutzen des Feldes werden die Einstellungen entsprechend übernommen
- 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)
- 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.
Keks Ping mich an! um 21:07, 11. Mai 2019 (CEST)
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[Quelltext bearbeiten]
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?}}}
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.Nuhaa (Diskussion) 12:58, 20. Mai 2019 (CEST)
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[Quelltext bearbeiten]
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.
Personen, die hochauflösendes und/oder langes Videomaterial hochladen wollen. Auch das Projekt c:Commons:Featured videos
Erhöhung der internen Dateilimits von Mediawiki und ein Tool zum Upload großer Dateien(oder Integration in den Uploadwizard) Das Binden des Uploads ab einer bestimmten Dateigröße an bestimmte Rechte, sollte auf Commons diskutiert werden.GPSLeo (Diskussion) 15:30, 27. Mai 2019 (CEST)
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[Quelltext bearbeiten]
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.
Wikipedianer_innen im Filmbereich zB.
Die richtige, Originalseite, als Vorschlag in der Box "Link einfügen" als Autokorrektur und nicht die falsche.--Tromla (Diskussion) 04:33, 29. Mai 2019 (CEST)
Beobachtungsliste unterteilen[Quelltext bearbeiten]
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.
Ich denke, das mag für ziemlich alle interessant sein.
Wurgl (Diskussion) 11:29, 29. Mai 2019 (CEST)
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[Quelltext bearbeiten]
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.
Eigentlich alle.
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.Grüße, --Snookerado (Diskussion) 20:43, 29. Mai 2019 (CEST)
- 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)
- Dann steht es dir doch immernoch frei ein
Info: DIFF 189652577 --Keks Ping mich an! um 19:19, 18. Jun. 2019 (CEST)
Unnötige Benachrichtigungen bei Zurücksetzungen[Quelltext bearbeiten]
- 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.
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)
Eine einfache Möglichkeit wäre z.B. nur den Benutzer zu benachrichtigen der die erste nach der Wiederherrgestellten Version geschrieben hat.WikiBayer 👤💬 Kenst du scho de boarische Wikipedia? 19:48, 31. Mai 2019 (CEST)
Farbliche Kennzeichnungen von Änderungen in der Diff der Versionsgeschichte[Quelltext bearbeiten]
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.
Sichter.
Farbliche Anzeige von ÄnderungenClaude J (Diskussion) 08:05, 1. Jun. 2019 (CEST)
Siehe auch: [9]. Bisher noch nciht gefunden, wo das sein soll... --Keks Ping mich an! um 13:02, 3. 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[Quelltext bearbeiten]
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[Quelltext bearbeiten]
Hunderte von Ergebnissen von Suchvorgängen müssen durchgesehen werden, auch wenn nur Ergebnisse mit einem bestimmten oder ungefähren Kriterium gesucht werden.
Jeden, der etwas sucht, in allen Wikis, insbesondere Wikidata und Commons
sortierbarer Tabelle mit mehreren ParameternEduard47 (Diskussion) 12:11, 17. Jun. 2019 (CEST)
"Fachchinesisch" in Wikidata durch Umgangssprache ersetzen[Quelltext bearbeiten]
Viele Ausdrücke und auch Hilfen in Wikdata sind unverständlich, bzw. nur von Statistikern zu verstehen
Alle Benutzer, die gerne bei Gelegenheit Daten ergänzen möchten
Sprache verständlich machen, Fachausdrücke vermeidenEduard47 (Diskussion) 12:16, 17. Jun. 2019 (CEST)
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[Quelltext bearbeiten]
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[Quelltext bearbeiten]
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.
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.Sinuhe20 (Diskussion) 07:58, 18. Jun. 2019 (CEST)
Eigene Top-Level-Domain für alle Wikipedias[Quelltext bearbeiten]
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
Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.
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.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).vanGore 14:12, 21. Jun. 2019 (CEST)
Technische Wünsche 2017 Eigene Top-Level-Domain für alle Wikipedias
Begriffsklärungs-Check im Visual Editor[Quelltext bearbeiten]
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?
Alle, die den Visual Editor nutzen.
Möglicherweise gibt es noch andere Helferlein, die im VE vermisst werden – ich kenne nicht alle.Mushushu (Diskussion) 16:55, 21. Jun. 2019 (CEST)
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[Quelltext bearbeiten]
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.
Alle, die an einer bebilderten Wikipedia hängen.
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. Eine kleine Diskussion gab es hier-->Wikipedia:Fragen zur Wikipedia#Gelöschte Bider durch älteres Bild ersetzenEddgel (Diskussion) 23:50, 25. Jun. 2019 (CEST)
Besser Bezug zwischen Beiträgen, automatische Anker[Quelltext bearbeiten]
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.
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.
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). 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).
Dirk123456 (Diskussion) 16:03, 27. Jun. 2019 (CEST)
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[Quelltext bearbeiten]
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.
Jeden, der an Diskussionen, Abstimmungen, Umfragen u. ä. teilnehmen möchte.
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. Die ausführliche Beschreibung wurde in eine Baustelle ausgelagert: Benutzer:Dirk123456/X-D.2/2019-06.Wunschparkplatz#Eindeutig_abgegrenzte_Diskussionsbeiträge_(Baustelle)Dirk123456 (Diskussion) 22:54, 29. Jun. 2019 (CEST)
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)
Browser-Benachrichtigungen bei Seitenänderungen[Quelltext bearbeiten]
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.
alle Benutzergruppen
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? von Wikipedia_Diskussion:Wikimedia_Österreich#Benachrichtigungen_zu_ÄnderungenLg {TheTokl ► Disk 📢 • E-Mail ✉️ • ❔Hilfe❔} 16:06, 22. Aug. 2019 (CEST)
Live-Chat-Funktion zur Kommunikation mit neu angemeldeten Benutzern[Quelltext bearbeiten]
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.
- 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.
Newbies und Leute, die ihnen helfen wollen
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, vermutlich ist der Vorschlag nicht neu, habe aber gerade nicht gefunden, wann und weshalb das schonmal abgelehnt wurde, vielleicht irre ich mich auch.poupou review? 17:18, 21. Okt. 2019 (CEST)
@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: 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)
- @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[Quelltext bearbeiten]
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"!
Alle
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. Ja, ich weiß, es gibt URL-Shortener aber ich kenne auch die damit einhergehenden Problem.MAbW (Diskussion) 11:39, 9. Jan. 2020 (CET)
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[Quelltext bearbeiten]
Das Smithsonian Institut stellt seinen kompletten Bestand in elektronischer Form unter der CC0- Lizenz zur Verfügung.
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.
Alle Autoren, die Bilder oder 3-D- Modelle des Bestands des Smithsonian Instituts einbinden wollen.
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/ Eventuell kann auf den Smithsonian Bestand zu einem späteren Zeitpunkt direkt in den Artikeln verlinkt werden.--Odolom (Diskussion) 15:19, 29. Feb. 2020 (CET)
Sichten mit Huggle wieder ermöglichen[Quelltext bearbeiten]
- 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...
Benutzer von Huggle und solche die es werden wollen und damit zur Vandalismusbekämpfung beitragen wollen.
Laut der Diskussionsseite ging das früher schon, aber aus einem unerfindlichen Grund jetzt nicht mehr...Lg {TheTokl ► Disk • E-Mail • Hilfe} 16:51, 1. Apr. 2020 (CEST)
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[Quelltext bearbeiten]
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.
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 untercommon.cssund/oder global.css einrichten. Da reicht #content table tr:first-of-type th {position:-webkit-sticky; position:sticky;top:0;}
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
Problem: Bei Kopf mit rowspan/colspan kann es Displayfehler geben, da nur eine Kopfzeile dargestellt wird.
Dokumentation Tabellen für Fortgeschrittene entsprechend ergänzen.Klaus-Peter (ex und hopp) 20:39, 25. Apr. 2020 (CEST)
Benutzername im Sperrlogbuch unterdrücken/verstecken[Quelltext bearbeiten]
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.
Administratoren/Stewards/Oversighter
- 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.
𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Kenst du scho de boarische Wikipedia? 08:47, 21. Mai 2020 (CEST)
+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[Quelltext bearbeiten]
- Es wäre schön, wenn man sich für das Sichten bedanken könnte.
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.)
Neue Wikipedianerinnen und Wikipedianer, die noch nicht Sichten dürfen.
Schaltflächen für angemeldete Mitschreibende. siehe auch: Wikipedia:Verbesserungsvorschläge#DANKEN für’s SichtenMobil-Sockenpuppe (Diskussion) 06:38, 18. Jun. 2020 (CEST)
&nnbsp; als Synonym für  [Quelltext bearbeiten]
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.
Autor*innen
An der Stelle, wo 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
<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.
Weitere Entitäten zu benennen wäre auch überlegenswert, beispielsweise [ und ] 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   ungeeignet ist, weil sich das niemand merken könne.[11]
— Sivizius (Diskussion) 07:50, 4. Jul. 2020 (CEST)
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 (aufunddavon) 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[Quelltext bearbeiten]
Die Platzierung von Diskussionsseiten-Links ist in der Desktop-Ansicht über die gesamte Wikipedia hinweg gleich, in der mobilen Ansicht aber seitenspezifisch unterschiedlich:
- Im Artikelnamensraum unter dem kompletten Artikel (bei langen Artikeln nur durch langes Scrollen erreichbar)
- Im Benutzernamensraum klein unter dem Namen (warum nicht als Button wie im Artikelnamensraum?!)
- Die Diskussion zur Hauptseite ist aus der mobilen Ansicht heraus nicht erreichbar.
Alle Leser, die Wikipedia in der mobilen Ansicht nutzen.
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.Tkarcher (Diskussion) 12:01, 2. Okt. 2017 (CEST)
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[Quelltext bearbeiten]
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.
Erstmal die Neuautoren, weil viele es nicht richtig wissen, aber auch die erfahrenen Autoren, weil sie es korrigieren müssen.
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 &)
Craeosh 77 (Diskussion) 14:39, 2. Jun. 2019 (CEST)
Pro — Johannes Kalliauer - Diskussion | Beiträge 12:36, 10. Jul. 2020 (CEST)
Pro — --Klaus-Peter (aufunddavon) 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[Quelltext bearbeiten]
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.
- 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
- bessere Wirkung nach außen durch korrekte Anwendung des ABC
- Autoren-Arbeitsaufwand sinkt nach Erfüllung des Wunschs
Bluemel1 🔯 08:39, 10. Jun. 2019 (CEST)
- 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.[Quelltext bearbeiten]
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.
alle Benutzer
automatische Eintragung von Artikeln auf den vorgesehenen SeitenLg {TheTokl ► Disk 📢 • E-Mail ✉️ • ❔Hilfe❔} 12:26, 10. Sep. 2019 (CEST)
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[Quelltext bearbeiten]
Weiterleitungen können ohne Einschränkung angelegt werden; da kann es vorkommen, dass sich jemand vertippt oder auch absichtlich Vandalismus betreibt.
Jeden, der sich vertippt, und vor allem Autoren der boarischen Wikipedia.
Der Missbrauchsfilter könnte so angepasst werden das der Filter Weiterleitungen prüfen kann.𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Kenst du scho de boarische Wikipedia? 11:19, 19. Nov. 2019 (CET)
- 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[Quelltext bearbeiten]
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.
Administratoren/Globale Administratoren/Stewards
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)𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Rechte | Kenst du scho de boarische Wikipedia? 10:31, 26. Jul. 2020 (CEST)
Artikel auf Wiedervorlage setzen[Quelltext bearbeiten]
Schaffung einer Möglichkeit, für Artikel eine (benutzerspezifische) Wiedervorlage einzurichten. ==
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.
(angemeldete) Benutzer, die eine größere Anzahl Artikel längerfristig aktuell halten wollen
Ä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).M-hue (Diskussion) 06:28, 10. Aug. 2020 (CEST)
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 (aufunddavon) 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)
- 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)
- 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 (aufunddavon) 06:40, 9. Nov. 2020 (CET)
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[Quelltext bearbeiten]
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.
Autoren Administratoren usw.
Eine Art Notizblock auf den nur der Autor/Benutzer zugriff hat.𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Rechte | Kenst du scho de boarische Wikipedia? 11:18, 11. Aug. 2020 (CEST)
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 (aufunddavon) 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.[Quelltext bearbeiten]
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)
217.85.16.81 07:45, 19. Aug. 2020 (CEST)
Kommentar beim Danken sowie Undank- Funktion einführen und Kommentar beim Undank[Quelltext bearbeiten]
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.
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.
Erweiterung der Danke-Funtion um eine Kommentarmöglichkeit und Schaffung einer Undank-Funktion mit Kommentarmöglichkeit. Ganz konsequent wäre es dann, wenn Undank genauso wie Dank in der Statistik der Bearbeitungen ausgewiesen werden würde.Mobil-Sockenpuppe (Diskussion) 13:39, 20. Sep. 2020 (CEST)
"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[Quelltext bearbeiten]
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.
Alle Nutzer, die regelmäßig zwischen Wikipedia browserbasiert am Desktop und einer (nativen iOS/Android) mobile App hin und her wechseln.
In der Browserversion gibt es die "Beobachtungsliste". An ähnlicher Position könnten auch die mobil gespeicherten Artikel aufgeführt werden, falls technisch möglich.Tine2nd (Diskussion) 21:07, 9. Okt. 2020 (CEST)
- 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[Quelltext bearbeiten]
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.
Diverse, sowohl Autoren als auch Personen mit Wikipedia-Artikel
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. Steht alles bereits obenAndol (Diskussion) 21:09, 12. Okt. 2020 (CEST)
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 (aufunddavon) 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[Quelltext bearbeiten]
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.
Jeden, der auf seine Beobachtungsliste schaut.
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.Sinuhe20 (Diskussion) 12:30, 5. Nov. 2020 (CET)
- 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 (aufunddavon) 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 (aufunddavon) 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[Quelltext bearbeiten]
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.
Administratoren/Globale Administratoren/Stewards/andere Benutzer die mit dem Logbuch arbeiten.
Die Filtermöglichkeiten sollten ausgebaut werden. Zum Beispiel Einträge von gesperrten und global gesperrten Benutzer ausblenden.𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Rechte ︱ Kenst du scho de boarische Wikipedia? 13:26, 8. Nov. 2020 (CET)
geprüfte Datenübernahme aus Wikidata[Quelltext bearbeiten]
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.
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.
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.WikiFreibeuter Kontakt 11:07, 11. Dez. 2020 (CET)
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 (aufunddavon) 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 (aufunddavon) 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 (aufunddavon) 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[Quelltext bearbeiten]
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.
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.
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.Matthias Süßen ?! 11:12, 26. Jan. 2021 (CET)
- 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)
- @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)
Geänderte eigenen Beiträge suchen[Quelltext bearbeiten]
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.
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?
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.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.
Pascamel (Diskussion) 16:07, 1. Feb. 2021 (CET)
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)
Pro — --Wilhelm (Diskussion) 09:04, 20. Nov. 2021 (CET)
Seitenvorschau beim Verlinken auf andere WP-Seiten[Quelltext bearbeiten]
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.
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.
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.Sprachraum (Diskussion) 15:27, 3. Mär. 2021 (CET)
@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[Quelltext bearbeiten]
Ziel ist, dass in den 'Letzten Änderungen' die Filtereinstellung 'Kurze Links' stabil bestehen bleibt.
Alle angemeldeten Benutzer
Betterknower (Diskussion) 19:00, 3. Apr. 2021 (CEST)
Was ist mit "Kurze Links" in den Letzten Änderungen gemeint?—Hfst (Diskussion) 09:15, 12. Dez. 2021 (CET)
Optimierung der Vorlage Worldcat[Quelltext bearbeiten]
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:
Betroffen sind potentiell alle Benutzer, die einen Personenartikel anlegen.
?? - - -Qaswa (Diskussion) 20:34, 5. Apr. 2021 (CEST)
@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[Quelltext bearbeiten]
- Schaffung einer Mediawiki-Funktion, die die Definition von zusammengehörigen Zeichen (Bezeichnungen) festlegen kann, mit dem Ziel, automatische Zeilenumbrüche zu unterbinden.
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.
Alle, die sich um Umbrüche Gedanken machen, sind betroffen: also jeder, der weiß, was ist...
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).
Zusätzlich würde eine solche Funktion globale Ersetzungen erlauben, beispielsweise „z. B.“ in „z. B.“ usw... Eine ähnliche Funktion bzw. eine Erweiterung könnte auch erlauben, Falschschreibungen wie „z.B.“ (ohne Leerzeichen) bei der Anzeige automatisch in „z. B.“ zu ändern.
‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)
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)
- 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:
Intelligenter Textsatz (automatischer Zeilenumbruch)[Quelltext bearbeiten]
- Schaffung eines intelligenten Textsatzsystems u. a. beim automatischen Zeilenumbruch
- 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
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.
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>).
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:
Und es würde eine rein manuelle Implementierung großteils ersetzen (aber nicht unnötig machen):
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.‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)
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 / Wort2", denn dann wird es in jedem Fall korrekt dargestellt, und fügt bei "Wort1/Wort2" ein breitenloses Leerzeichen ein, also "Wort1/​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. B." oder ein "Wort1/​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.[Quelltext bearbeiten]
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.
Alle Nutzer, besonders die mit Mobilgeräten mit OLED-Display.
Bei den Einstellungen ein CSS mit Darkmode hinzufügen.≡c.w. @… 08:55, 30. Apr. 2021 (CEST)
- 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> [Quelltext bearbeiten]
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.
im Prinzip alle Autoren
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.
A1000 (Diskussion) 10:45, 3. Jun. 2021 (CEST)
Automatisch nachgefuehrte Links auf Abschnitte von Diskussionsseiten mit Archiv[Quelltext bearbeiten]
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).
Bearbeiter der Wikipedia, die an Diskussionen teilnehmen und diese an anderer Stelle verlinken wollen.
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.Juergen 217.61.204.70 00:36, 9. Jun. 2021 (CEST)
- 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.[Quelltext bearbeiten]
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].
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)
Hilfe:Tabellen/Sortierung#Rangliste aktualisierenQuintil Jan Verus (Diskussion) 10:57, 10. Jun. 2021 (CEST)--
Letzte eigene Bearbeitungen, die nicht aktuell sind, besser erkennen können[Quelltext bearbeiten]
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.
Sämtliche angemeldeten Benutzer
Filter ergänzen mit "nur letzten Edit einer Seite anzeigen" oder (o.ä.)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).ProloSozz (Diskussion) 11:03, 7. Jul. 2021 (CEST)
In Beobachtungsliste gleichzeitiges Öffnen aller Änderungen ermöglichen[Quelltext bearbeiten]
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.
Alle Nutzer der Beobachtungsliste, speziell die mit vielen beobachteten Seiten.
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.Lguenth1 (Diskussion) 18:32, 7. Jul. 2021 (CEST)
sehr gute Idee! --Fan-von-mir (Diskussion) 14:16, 29. Okt. 2021 (CEST)
Medienbetrachter sollte in Bildlegende enthaltenes TeX darstellen können[Quelltext bearbeiten]
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:
- Beispiel 1
- Artikel: Funktion (Mathematik)#Verknüpfung
- Bild mit TeX in Bildlegende im Medienbetrachter: Funktion (Mathematik)#/media/Datei:Binary operations as black box.svg
- Beispiel 2
- Artikel: Komplexe Zahl#Komplexe Konjugation
- Bild mit TeX in Bildlegende im Medienbetrachter: Komplexe Zahl#/media/Datei:Komplexe konjugation.svg
- 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
Alle NutzerInnen, die in Artikeln auf Bilder klicken, deren Bildlegende TeX enthält.
SweetWood (Diskussion) 19:54, 8. Jul. 2021 (CEST)
Bilder-Vorschau in Commons Unterkategorien[Quelltext bearbeiten]
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.
Commons-Nutzer
Entweder ein Button, oder z.B. in der Reiterleiste unter "Weitere" einen Punkt "Vorschau bei Unterkategorien"Gerd Fahrenhorst (Diskussion) 13:48, 12. Jul. 2021 (CEST)
- 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[Quelltext bearbeiten]
Ich möchte z. B. in Vorlagen identische Programmteile
- jeweils für alle Monate eines Jahres aufrufen und diese nicht 12 Mal mit identischem Code einprogrammieren.
- von einem Ausgangsjahr bis zum aktuellen Jahr das Ergebnis generieren ohne jährlich die Vorlage für das aktuelle Jahr zu erweitern.
Vorlagenprogrammierer
Diese Erweiterung in der deutschen Wikipedia installieren.Es geht um solche und ähnliche Konstruktionen:
{{ #loop: monat | 1 | 12 | <!-- Hier ein Anweisungsblock, in welchem {#var: monat}} benutzt wird --> }}{{ #loop: jahr | 2010 | {{#expr: 1+{{JETZIGES_JAHR}}-2010}} | <!-- Hier ein Anweisungsblock, in welchem {#var: jahr}} benutzt wird --> }}
Former111 (Diskussion) 16:37, 21. Okt. 2021 (CEST)
@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.repder Aufruf eines Systemroutine wäre.
Ich habe bereits in der Lua-Werkstatt um Unterstützung angefragt. --Former111 (Diskussion) 17:10, 28. 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
- @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)
- 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)
- 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)
- 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.
- @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)
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[Quelltext bearbeiten]
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.
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
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:
- 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
M2k~dewiki (Diskussion) 14:48, 25. Okt. 2021 (CEST)
- 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[Quelltext bearbeiten]
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
Alle Autorinnen und Autoren, Entlastung der Eingangkontrolle und Qualitätssicherung, mehr Effizienz und Konzentration auf inhaltliche Fehler statt Formalitäten
- 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
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
--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)
- 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[Quelltext bearbeiten]
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:
Alle Benutzer von Wikidata
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:
Dies sollte für alle Benutzer standardmäßig aktiviert werden.--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)
Online-Typografiecheck im Editfenster vor Abschicken eines Edits, z.B. wie in Word[Quelltext bearbeiten]
Haufenweise grottige Typografie insbesondere im Fließtext
jeden Autor
Jbergner (Diskussion) 18:50, 25. Okt. 2021 (CEST)
- 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[Quelltext bearbeiten]
Viele SVG-Grafiken können derzeit nicht richtig als PNG dargestellt werden (z.B. textPath, FlowRoot), dafür gibt bereits einige Problemsammlungen/Workarounds:
Grafiker, WP:Grafikwerkstatt, alle Autoren die Vektorgrafiken einbinden wollen (dafür müssen die richtig dargestellt werden)
Statt libRsvg REsvg zum Rendern der SVGs verwenden, siehe phab:T40010auf 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 |
— Johannes Kalliauer - Diskussion | Beiträge 19:28, 25. Okt. 2021 (CEST)
Artikel mit Versionsgeschichte einfach kopieren[Quelltext bearbeiten]
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.
Autoren, die sich um das Aufräumen der Erzeugnisse von Newsticker-Inklusionisten kümmern. Autoren, die die Artikellandschaft anders strukturieren wollen. Übersetzer.
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") 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)--TheRandomIP (Diskussion) 23:09, 25. Okt. 2021 (CEST)
- 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[Quelltext bearbeiten]
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.
Fast alle Autoren, die an größeren Artikeln arbeiten.
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.
TheRandomIP (Diskussion) 22:30, 25. Okt. 2021 (CEST)
- 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
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)
- 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)
- 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)
- 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)
- 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)
- 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)
&nnbsp; als Synonym für  [Quelltext bearbeiten]
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.
Autor*innen, die Typographie manchmal etwas zu ernst nehmen
An der Stelle, wo 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
<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.
Weitere Entitäten zu benennen wäre auch überlegenswert, beispielsweise [ und ] 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   ungeeignet ist, weil sich das niemand merken könne.[14].
— Sivizius (Diskussion) 13:12, 26. Okt. 2021 (CEST)
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 (aufunddavon) 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[Quelltext bearbeiten]
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.
alle Benutzer, die längere Texte bearbeiten und die „alte Methode“ verwenden (ohne Visueller Editor)
- 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 ;-)
Hannes 24 (Diskussion) 13:44, 26. Okt. 2021 (CEST)
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)
- 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)
- 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)
Reaktivierung der PDF-Buchfunktionalität[Quelltext bearbeiten]
Die PDF-Buchfunktionalität (Erstellung von mehreren gesammelten PDFs mit einer Auswahl von Artikel inkl. Inhaltsverzeichnis etc.)
ist seit ein paar Jahren nicht mehr verfügbar
Die vorgeschlagene Alternative
bietet hinsichtlich Lesbarkeit/Formatierung der erzeugten PDFs, Skalierbarkeit/Laufzeit leider nicht die Eigenschaften der ursprünglichen Funktionalität.
Wen betrifft das Problem besonders?
Eine Reaktivierung wäre wünschenswert.
- Wikipedia:Fragen_zur_Wikipedia#Wikipedia-Bücher_im_BNR_???
- Wikipedia:Fragen_zur_Wikipedia#Projekt_gedruckte_Bücher
--M2k~dewiki (Diskussion) 17:51, 26. Okt. 2021 (CEST)
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[Quelltext bearbeiten]
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.)
Neue Wikipedianerinnen und Wikipedianer, die noch nicht Sichten dürfen.
Schaltflächen für angemeldete Mitschreibende.Mobil-Sockenpuppe (Diskussion) 06:38, 18. Jun. 2020 (CEST)
- 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[Quelltext bearbeiten]
Verbesserung der Tools zum Hochladen von Dateien und die Möglichkeit große Dateien(>4GiB) hochzuladen.
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.
- 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.
Alle die Dateien hochladen, insbesondere große Dateien oder viele Dateien.
- 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.
GPSLeo (Diskussion) 20:06, 26. Okt. 2021 (CEST)
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[Quelltext bearbeiten]
Wenn man eine Seite mit dem Quelltexteditor bearbeitet, bemerkt man erst einen Bearbeitungskonflikt, wenn man auf Veröffentlichen geht.
Verhindert mühevolles neuedieren oder umändern, besonders bei umfangreicheren Bearbeitungen
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.
Alle Autoren, die mit dem Quelltexteditor arbeiten
Nach Druck auf den Vorschau-Button wird ein Hinweis eingeblendet, dass ein Bearbeitungskonflikt vorliegt Ich kann nicht beurteilen, ob das technisch überhaupt möglich istOrgelputzer (Diskussion) 16:42, 27. Okt. 2021 (CEST)
- 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[Quelltext bearbeiten]
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.
Leute die mit Wikidata arbeiten, z.B. um Lagekarten zu erstellen. Wenn man 50 Objekte übernehmen will, nervt das etwas.
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.Gerd Fahrenhorst (Diskussion) 19.22, 27. Okt. 2021 (CEST)
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. -→KPF
&Blabla← 19:46, 27. Okt. 2021 (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. -→KPF
Quelltexterstellung des Visual Editor[Quelltext bearbeiten]
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.
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.
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_*
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.
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.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
Fan-von-mir (Diskussion) 17:19, 28. Okt. 2021 (CEST)
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:
- 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)
(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)
- @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)
- @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)
- 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[Quelltext bearbeiten]
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.
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.
Ettablieren von 2FA beim Erreichen vom passiven Sicherrecht {{{Anmerkungen}}}Jonsonr (Diskussion) 21:48, 28. Okt. 2021 (CEST)
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)
- 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)
Wikipedia-App[Quelltext bearbeiten]
Verbesserungsvorschläge zum Umgang mit der Wikipedia-App
Ich nutze die Wikipedia-App und manches funktioniert mehr schlecht als recht. Ich würde mich freuen, wenn das besser funktioniert.
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.
Alle Autoren, die die App nutzen.
keine Ahnung, bin kein Software-Profi Kann gerne mit anderen Themenschwerpunkten vereinigt werden.Fan-von-mir (Diskussion) 15:00, 29. Okt. 2021 (CEST)
- 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.[Quelltext bearbeiten]
Es geht um den Vorgang des Bilderhochladens bei Wikimedia Commons und das anschließende Hochladen bzw. Einbinden der Bilder in einen Wikipedia-Artikel.
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.
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.
Alle, die Bilder hochladen möchten.
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. 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.Auguste de Gouges (Diskussion) 14:08, 30. Okt. 2021 (CEST)
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[Quelltext bearbeiten]
Hilfe:Zusammenfassung und Quellen
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.
siehe oben
siehe oben
Degon Trojvil (Diskussion) 21:02, 30. Okt. 2021 (CEST)
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. --→KPF
&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[Quelltext bearbeiten]
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.
Alle, insbesondere Suchende
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. 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.→KPF&Blabla← 10:22, 31. Okt. 2021 (CET)
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. --→KPF
&Blabla← 12:45, 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[Quelltext bearbeiten]
Wenn ich eine Vorlage wie Mehrspaltige Liste oder Infobox bearbeite, muss ich in sehr kleine Felder z.T. komplexe Syntax einfügen.
Alle die Inhalte in Vorlagen editieren
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. kann gerne mit anderen Abschnitten zusammengefasst werden.Fan-von-mir (Diskussion) 15:59, 31. Okt. 2021 (CET)
- 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[Quelltext bearbeiten]
- 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
Schreibende
Keine Ich finde die Unterstützung zur Erstellung von Einzelnachweisen ist vorsintflutlichHfst (Diskussion) 12:15, 1. Nov. 2021 (CET)
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[Quelltext bearbeiten]
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.
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)
Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET) Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET)
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[Quelltext bearbeiten]
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
Wikisource-Nutzer
Anordnung eines Buttons in der Bearbeitungsseite auf der Bearbeitungsleiste, ähnlich zu den dort schon vorhandenen. 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.A. Wagner (Diskussion) 18:12, 2. Nov. 2021 (CET)
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[Quelltext bearbeiten]
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
Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.
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.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).vanGore 18:55, 2. Nov. 2021 (CET)
Technische Wünsche 2017 Eigene Top-Level-Domain für alle Wikipedias
Bildbeschreibungen für Blinde (automatisiert) einbinden[Quelltext bearbeiten]
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.
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.
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.
Blinde und Menschen mit Sehbehinderungen.
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.Zartesbitter (Diskussion) 19:56, 3. Nov. 2021 (CET)
- 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[Quelltext bearbeiten]
Völlig leseunfreundlich
Jeden Leser/Leserin
2 oder 3 Spalten einführen Der Eindruck einer Seite erzählt von Unbeholfenheit--Wikipus (Diskussion) 00:33, 4. Nov. 2021 (CET)
Den Schalter [Abrufstatistik] in die Liste der Werkzeuge in der linken Spalte integrieren[Quelltext bearbeiten]
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)
- Seiteninformationen
- 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.
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.
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. 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 StelleCiao • Bestoernesto • ✉ 04:03, 4. Nov. 2021 (CET)
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.[Quelltext bearbeiten]
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.
Man kann bereits in der mail oder im feeditem den Änderungsinhalt sehen.
Man muss zusätzlich die Seite mit der diff Ansicht anklicken, das stört den Lesefluss in der mail oder im feedreader.
Alle mail und feed User.
greetz vanGore 13:54, 5. Nov. 2021 (CET)
Erleichterung für Neulinge[Quelltext bearbeiten]
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.
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.
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
Neue Wikipedianer
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.Knut Krüger (Diskussion) 16:02, 5. Nov. 2021 (CET)
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[Quelltext bearbeiten]
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 , richtig wären oder noch besser . 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.
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.
1. Fehlerhafte oder irreführende Beispiele und Beschriftungen bitte durch korrekte bzw. geeignetere ersetzen.
- , oder statt (nicht existentes Teilchen)
- statt (nicht existentes Teilchen)
- statt (sinnvolle Formel statt Quatsch)
- oder statt (zur didaktischen Verbesserung)
- Ladungen statt Aufladungen
- Weitere Punkte hier.
2. Fehlerhafte Beispiele wie (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 : 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 .
4. Die schon lange bekannten technischen Probleme des chem-Tags beheben.![{\displaystyle \mathrm {Hg^{2+}\xrightarrow {+I^{-}} HgI_{2}\xrightarrow {+I^{-}} [Hg^{II}I_{4}]^{2-}} }](https://wikimedia.org/api/rest_v1/media/math/render/svg/2d36876e581a02497fd391d5d441b97f17a221c9)
.jpg&action=history){kind=link}
#/media/Datei:Binary_operations_as_black_box.svg){kind=link}
#/media/Datei:Parabel-scal2.svg){kind=link}
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.Nick B. (Diskussion) 14:09, 13. Nov. 2021 (CET)
Pro — --Wilhelm (Diskussion) 09:10, 20. Nov. 2021 (CET)
Genaue Wortsuche, die Groß- und Kleinschreibung beachtet[Quelltext bearbeiten]
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.
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).
- 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).
Betroffen ist insbesondere die Community, die sich um Textqualität sorgt.
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.Frühlingsmädchen (Diskussion) 13:16, 14. Nov. 2021 (CET)
Tote Links (nach bestimmten Kriterien) ermitteln[Quelltext bearbeiten]
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.
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.
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)
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.
Einen konfigurierbaren Bot programmieren, der nach toten Links unter Berücksichtigung von bestimmten Kriterien suchen kann.tender tiger 🐯 18:09, 14. Nov. 2021 (CET) im Namen des Teams von Wikipedia:Hannover
Fortführung des Schwerpunktes "Leichter mit Vorlagen arbeiten"[Quelltext bearbeiten]
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“.
- <!-- 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. -->
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 ParameterSubspeziesgesetzt (<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
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:
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.
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.
Das habe ich nicht verstanden:
<!-- Vorlage zur Erfassung von Problemen kopieren, um weitere hinzuzufügen. -->Dirk123456 (Diskussion) 23:46, 14. Nov. 2021 (CET)