Wikipedia:Umfragen/Technische Wünsche 2017/Lesen

Umfrage Technische Wünsche 2017

Rubrik „Lesen“

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

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

Vorschau von Einzelnachweisen

Was ist das Problem?

Während des Lesens Einzelnachweise anzusehen, ist oft zu umständlich. Durch das Klicken auf einen Einzelnachweis (EN) an das Ende des Textes springt und dass man nach dem Lesen den richtigen der zum Teil vielen Buchstaben („42. ↑ ^{a b c d e f g}“) auswählen muss (oder eben die „Zurück“-Taste des Browsers nutzen muss), wird der Lesefluss unterbrochen. So lässt es sich nicht sinnvoll vereinen, einen Text angenehm zu lesen und währenddessen die Quellen anzusehen.

(10:36, 2. Jun. 2017 (CEST)) Einem Tool (Einstellungen: Fußnoten-Tooltip), das im Sinne des Lösungsvorschlages dies Problem lösen könnte und in den persönlichen Einstellungen aktiviert werden kann, liegt problematischerweise ein Code zugrunde, der „ein modifizierter Fork aus der englischen Wikipedia [ist], der praktisch nicht mehr gepflegt wird. Neben bereits bestehenden Problemen ist daher damit zu rechnen, dass die Funktion sich in Zukunft immer weiter verschlechtert, ohne dass etwas dagegen unternommen wird. Bekannte Probleme sind unter anderem die Schriftgröße, die deutlich kleiner ist als die Einzelnachweise im Normalfall, fehlende Symbole für externe Links, mangelhafte Barrierefreiheit bei einer Kombination von Screenreader und Touchscreen und weitere Kleinigkeiten, die am Ende von Wikipedia:Verbesserungsvorschläge/Archiv/2012/August#MouseOver bei Einzelnachweisen genannt sind. Zudem wurde in Einzelfällen berichtet, dass die Popups entgegen der Konfiguration nur auf Klick erscheinen, bei einem weiteren Klick um den Inhalt zu markieren und kopieren aber wieder verschwinden. Außerdem ist für die Zukunft eine Änderung der HTML-Struktur von Einzelnachweisen geplant, die dazu führen würde, dass das Skript diese in seinem gegenwärtigen Zustand nicht mehr finden würde und damit nicht mehr anzeigen könnte.“ (Schnark in der Diskussion)

Wen betrifft das Problem besonders?

Lesende im Allgemeinen. (10:36, 2. Jun. 2017 (CEST)) Unangemeldete Benutzer sind (siehe oben) noch stärker betroffen.

Lösungsvorschlag

Berührt („hovert“) man Links auf Einzelnachweise („^[42]“) ohne zu klicken, so soll der Inhalt des Einzelnachweises (EN) automatisch angezeigt werden. Es soll also, wenn man den EN-Link berührt, eine Art Kasten erscheinen, in dem der EN-Inhalt – das, was zwischen <ref> und </ref> steht – angezeigt wird (inklusive Links etc.). Beispiel sollen die EN der englischsprachigen Wikipedia sein.

(10:36, 2. Jun. 2017 (CEST)) Eine standardmäßige Aktivierung der Einstellung „Fußnoten-Tooltip“ würde dies Problem im Sinne des obigen Abschnittes lösen, ist aber mit weiteren Probelemen (2. Abschnitt „Problem“) verbunden.

Anmerkungen

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

Vorschlagende Person

Rübenkopf 10:31, 29. Mai 2017 (CEST)

Diskussion

@Rübenkopf: Die gewünschte Funktion gibt es schon. Du kannst sie in deinen Einstellungen (Helferlein) ganz unten im Abschnitt "Lesehilfen" aktivieren: "Fußnoten-Tooltip: Zeigt beim Überfahren eines Referenzlinks im Artikeltext die zugehörige Fußnote im Fließtext an, ohne dass es notwendig würde, ans Ende des Artikeltextes zu springen.". Man könnte darüber diskutieren/abstimmen, ob man diese Funktion für alle (auch unangemeldete Benutzer) standardmäßig aktiviert. -- Reise Reise (Diskussion) 12:29, 29. Mai 2017 (CEST)

Vielen Dank für den Tipp, @Reise Reise. Deinem letzteren Vorschlag stimme ich zu – dies sollte standardmäßig aktiviert werden. Wem die Funktion dann doch nicht gefälligt, kann sie dann ja in den persönlichen Einstellungen wieder ausschalten … —Rübenkopf 12:38, 29. Mai 2017 (CEST)

Dank an Rübenkopf für diesen Vorschlag, den ich gern unterstützen möchte. Ich habe diese Funktion für mich aktiviert, würde mir aber sehr wünschen, dass sie als Standard für unsere Leserinnen und Leser eingerichtet würde und zwar so, dass im Vorschaufenster des EN auch direkt dem dort eventuell vorhandenen Link gefolgt werden kann. Freundlichen Gruß --Andrea014 (Diskussion) 07:23, 31. Mai 2017 (CEST)

Der Code des Gadgets ist ein modifizierter Fork aus der englischen Wikipedia, der praktisch nicht mehr gepflegt wird. Neben bereits bestehenden Problemen ist daher damit zu rechnen, dass die Funktion sich in Zukunft immer weiter verschlechtert, ohne dass etwas dagegen unternommen wird. Bekannte Probleme sind unter anderem die Schriftgröße, die deutlich kleiner ist als die Einzelnachweise im Normalfall, fehlende Symbole für externe Links, mangelhafte Barrierefreiheit bei einer Kombination von Screenreader und Touchscreen und weitere Kleinigkeiten, die am Ende von Wikipedia:Verbesserungsvorschläge/Archiv/2012/August#MouseOver bei Einzelnachweisen genannt sind. Zudem wurde in Einzelfällen berichtet, dass die Popups entgegen der Konfiguration nur auf Klick erscheinen, bei einem weiteren Klick um den Inhalt zu markieren und kopieren aber wieder verschwinden. Außerdem ist für die Zukunft eine Änderung der HTML-Struktur von Einzelnachweisen geplant, die dazu führen würde, dass das Skript diese in seinem gegenwärtigen Zustand nicht mehr finden würde und damit nicht mehr anzeigen könnte. –Schnark 09:59, 31. Mai 2017 (CEST)

Ich verstehe zwar Dein Technik-Sprech nicht, Schnark, aber das klingt mir nicht gut. Vorlage:Smiley/Wartung/traurig  Gibt es keine Chance auf etwas Vergleichbares, das die genannten Nachteile nicht hat? Die Lesefreundlichkeit würde doch sehr erhöht, so dass sich Mühen vielleicht lohnen könnten? Gruß --Andrea014 (Diskussion) 08:02, 1. Jun. 2017 (CEST)

Hallo Andrea014 und Schnark! Ich kann mir vorstellen, dass einige das Helferlein nutzen, aber die Problematik, die Schnark beschreibt, nicht auf dem Schirm haben. Insofern scheint es mir sinnvoll, die Anmerkungen von Schnark noch in die Problembeschreibung selbst einzubauen - denn mit Beginn der Abstimmungsphase wird der Abschnitt „Diskussion“ ausgeblendet. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:50, 1. Jun. 2017 (CEST)

Danke für den Hinweis. Bestimmt ist es so, Johanna Strodt (WMDE), ich z.B. konnte es gar nicht „auf dem Schirm haben“, weil ich von diesen technischen Dingen nichts verstehe. Aber ich möchte dann noch etwas anfügen: mir geht es nicht um uns, sondern um unsere Leserschaft. Und als ich noch nur-Leserin war, hab ich mich (in langen Artikeln mit vielen EN, die auch mehrfach verwendet wurden) die Plätze geärgert über diese Sprunglinks - ebenso wie in Büchern oder wissenschaftlichen Zeitschriften, die die Fußnoten nicht auf der Leseseite haben. Noch gebe ich die Hoffnung nicht auf, dass unsere Tekki's eine Lösung finden. Es grüßt --Andrea014 (Diskussion) 16:04, 1. Jun. 2017 (CEST)

@Schnark: Ist denn Dein Skript Popuprefs von den beschriebenen Problemen auch betroffen, oder hast Du es gerade deshalb geschrieben? — Speravir – 21:19, 1. Jun. 2017 (CEST)

Mein Skript hat andere Probleme, aber es hat auch genug davon, dass das nicht einfach für alle Benutzer aktiviert werden könnte. Insbesondere hat es allerlei Hacks, um in allen Skins eine vernünftige Schriftgröße zu erhalten, und auf Geräten ohne Maus funktioniert es im Idealfall gar nicht, in einigen Fällen (insbesondere in Firefox) aber sehr störend. Genau daher weiß ich, dass diese Funktion wesentlich schwerer ist, als sie den Anschein hat.

In der Vergangenheit gab es bereits zwei Versuche, eine solche Funktion direkt in MediaWiki (bzw. eine Erweiterung) zu integrieren, aber beide hatten so viele Probleme, dass sie es nie auch nur zum Testbetrieb geschafft haben. Wir können natürlich WMDE mit einem dritten Versuch beauftragen, aber ich fürchte, dass mehr als die dritte Coderuine auch diesmal nicht rauskommt. –Schnark 09:22, 2. Jun. 2017 (CEST)

@Johanna Strodt (WMDE), Andrea014, Schnark: Ich habe mal die Problembeschreibung erweitert und dabei Schnark zitiert. Seid ihr damit einverstanden? Gibt es noch weitere Anmerkungen, Wünsche, etc.? Wird der Text oben zu lang? —Rübenkopf 10:36, 2. Jun. 2017 (CEST)

@Rübenkopf: Aus meiner Sicht ist es so gut und auch nicht zu lang. Das Problem darf ruhig ausführlich beschrieben werden. Wenn andere Mitlesende Ergänzungen oder Rückfragen haben, gerne Bescheid geben. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 12:54, 8. Jun. 2017 (CEST)

Zufälligerweise wurde gerade gestern der zweite Versuch einer Implementierung offiziell für gescheitert erklärt. –Schnark 09:10, 9. Jun. 2017 (CEST)

Eventuell könnte man bis zur Lösung dieses Problems sowohl den Fußnoten-Tooltip als auch Schnarks Popuprefs als Lesehilfen-Helferlein in den Einstellungen zur individuellen Aktivierung anbieten, versehen mit einem Link zu einer Seite, in der auf die bestehenden Caveats (Probleme, Anwendungsbeschränkungen, Abweichungen etc.) der beiden Helferlein hingewiesen wird (@all, insbesondere @Schnark:). --X:: black ::X (Diskussion) 02:18, 1. Jul. 2017 (CEST)

Unterstützung

1.  Pro Rübenkopf (Einreichende Person)
2.  Pro --Stefanhinz (Diskussion) 23:30, 24. Jun. 2017 (CEST)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 13:17, 19. Jun. 2017 (CEST)
4.  Pro --† Alt ♂ 14:43, 20. Jun. 2017 (CEST)
5.  Pro --Furfur ^{⁂ Diskussion} 14:57, 20. Jun. 2017 (CEST)
6.  Pro --HerrAdams (D) 15:02, 20. Jun. 2017 (CEST)
7.  Pro Lee (Diskussion) 15:45, 20. Jun. 2017 (CEST)
8.  Pro Windharp (Diskussion) 15:56, 20. Jun. 2017 (CEST)
9.  Pro --Rita2008 (Diskussion) 16:08, 20. Jun. 2017 (CEST)
10.  Pro --Rjh (Diskussion) 16:09, 20. Jun. 2017 (CEST)
11.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe} 16:47, 20. Jun. 2017 (CEST) dieses Problem ist mir schon öfter aufgefallen - danke für die Anbringung!
12.  Pro Zabia (Diskussion) 16:50, 20. Jun. 2017 (CEST)
13.  Pro --mirer (Diskussion) 18:25, 20. Jun. 2017 (CEST)
14.  Pro Dass diese offensichtlich hilfreiche Funktionalität, die wirklich die letzte Kraut-und-Rüben-Datenbank seit Jahren anbietet, noch nicht ihren Weg in die deutschsprachige Wikipedia gefunden hat, ist ein Versagen, zu dem sich die Foundation und die deutschsprachige Community gegenseitig gratulieren können. Die einen entwickeln eine entsprechende Funktion für die eine Seitenversion (Mobilversion) und lassen die andere außen vor, die anderen haben sich wieder und wieder dagegen gewehrt, die – über die Benutzereinstellungen bereits zuschaltbare – Funktionalität aus enwiki einfach ebenfalls für alle Nutzer zu übernehmen, wie üblich unter Rekurs auf irgendwelche Extremfälle (á la: „Das funktioniert nicht, wenn fünfzehn aufeinandergestapelte Bilder in der Fußnote stehen, also können wir das auf keinen Fall für alle aktivieren!“). — Pajz (Kontakt) 19:04, 20. Jun. 2017 (CEST)
15.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 20:20, 20. Jun. 2017 (CEST)
16.  Pro --Prüm 20:25, 20. Jun. 2017 (CEST)
17.  Pro --Till.niermann (Diskussion) 20:39, 20. Jun. 2017 (CEST)
18.  Pro Gelber kaktus (Diskussion) 21:49, 20. Jun. 2017 (CEST)
19.  Pro --Avron (Diskussion) 22:24, 20. Jun. 2017 (CEST)
20.  Pro --Wikifreund (Diskussion) 22:27, 20. Jun. 2017 (CEST) Es genügt aber die Funktion unter Einstellungen (Helferlein) ganz unten im Abschnitt "Lesehilfen" dies immer aktiv zu lassen auch für unangemeldete Besucher.
21.  Pro --Thomas Obermair 4 (Diskussion) 22:57, 20. Jun. 2017 (CEST)
22.  Pro Michaelt1964 (Diskussion) 23:57, 20. Jun. 2017 (CEST) Wie oben gesagt: Gute Funktion, Problem einfach fixen. Am Geld sollte es ja nicht scheitern
23.  Pro --SkiFreak99 (Diskussion) 00:20, 21. Jun. 2017 (CEST)
24.  Pro Das Helferlein nutze ich gerne und jede Verbesserung dabei bzw. standardmäßige Aktivierung begrüße ich gern. --rugk (Diskussion) 00:26, 21. Jun. 2017 (CEST)
25.  Pro --Joerch (Diskussion) 11:32, 21. Jun. 2017 (CEST)
26.  Pro --jcornelius  11:34, 21. Jun. 2017 (CEST)
27.  Pro --Aarakast (Diskussion) 12:45, 21. Jun. 2017 (CEST)
28.  Pro --Bombenleger (Diskussion) 14:39, 21. Jun. 2017 (CEST)
29.  Pro sk (Diskussion) 16:49, 21. Jun. 2017 (CEST)
30.  Pro--Carolus requiescat (Diskussion) 17:09, 21. Jun. 2017 (CEST)
31.  Pro --Quantenwiki (Diskussion) 18:00, 21. Jun. 2017 (CEST)
32.  Pro --S. F. B. Morse^{ditditdadaditdit} 18:44, 21. Jun. 2017 (CEST)
33.  Pro --Louis ♫ Bafrance ☼ Schwätz halt mit m'r, wenn da ebbes saga witt 19:44, 21. Jun. 2017 (CEST)
34.  Pro ---MGChecker – (📞| 📝| ) 19:53, 21. Jun. 2017 (CEST)
35.  Pro WRuss 20:55, 21. Jun. 2017 (CEST)
36.  Pro --Maxian D-C (Diskussion) 21:52, 21. Jun. 2017 (CEST)
37.  Pro --Pelz (Diskussion) 22:19, 21. Jun. 2017 (CEST)
38.  Pro --Jonsger (Diskussion) 22:56, 21. Jun. 2017 (CEST) gibts schon ewig in der engl. Wikipedia und ich hab mich immer gefragt warum "wir" sowas nicht haben
39.  Pro --Andi D (Diskussion) 23:47, 21. Jun. 2017 (CEST)
40.  Pro --Auranofin (Diskussion) 00:23, 22. Jun. 2017 (CEST)
41.  Pro --JLuckenb (Diskussion) 10:37, 22. Jun. 2017 (CEST)
42.  Pro --Jossi (Diskussion) 12:19, 22. Jun. 2017 (CEST)
43.  Pro --HHill (Diskussion) 12:23, 22. Jun. 2017 (CEST)
44.  Pro --GodeNehler (Diskussion) 19:25, 22. Jun. 2017 (CEST)
45.  Pro --Atamari (Diskussion) 12:03, 23. Jun. 2017 (CEST)
46.  Pro --Eriom (Diskussion) 12:24, 23. Jun. 2017 (CEST)
47.  Pro Quiethoo (Diskussion) 13:28, 23. Jun. 2017 (CEST)
48.  Pro mauriceKA (Diskussion) 13:30, 23. Jun. 2017 (CEST)
49.  Pro KPFC 💬 15:32, 23. Jun. 2017 (CEST)
50.  Pro --Karl432 (Diskussion) 20:30, 23. Jun. 2017 (CEST)
51.  Pro --Daniel749 Disk. (ST–WPST) 20:54, 23. Jun. 2017 (CEST)
52.  Pro --Nichtich (Diskussion) 22:02, 23. Jun. 2017 (CEST)
53.  Pro --Cmecklen67 (Diskussion) 09:35, 24. Jun. 2017 (CEST)
54.  Pro --Crazy1880 11:04, 24. Jun. 2017 (CEST)
55.  Pro --Martin Luck (Diskussion) 15:10, 24. Jun. 2017 (CEST)
56.  Pro --Rainald62 (Diskussion) 15:14, 24. Jun. 2017 (CEST)
57.  Pro --Skrippek (Diskussion) 16:17, 24. Jun. 2017 (CEST)
58.  Pro --Christian (Diskussion) 19:31, 24. Jun. 2017 (CEST)
59.  Pro Divof (Diskussion) 19:45, 24. Jun. 2017 (CEST)
60.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
61.  Pro --Mojoaxel (Diskussion) 14:23, 25. Jun. 2017 (CEST)
62.  Pro --Mushushu (Diskussion) 16:08, 25. Jun. 2017 (CEST)
63.  Pro --DomenikaBo (Diskussion) 21:26, 25. Jun. 2017 (CEST)
64.  Pro --Wrev (Diskussion) 22:23, 25. Jun. 2017 (CEST)
65.  Pro -- ^Thomas 08:03, 26. Jun. 2017 (CEST)
66.  Pro --Chstdu (Diskussion) 15:19, 26. Jun. 2017 (CEST)
67.  Pro --Sophiston (Diskussion) 23:53, 26. Jun. 2017 (CEST)
68.  Pro --Merlin2001 (Diskussion) 00:02, 28. Jun. 2017 (CEST)
69.  Pro --Gr1 (Diskussion) 16:21, 28. Jun. 2017 (CEST)
70.  Pro --Ak ccm (Diskussion) 00:12, 29. Jun. 2017 (CEST)
71.  Pro --Orgelputzer (Diskussion) 13:18, 29. Jun. 2017 (CEST)
72.  Pro -- hgzh 19:15, 29. Jun. 2017 (CEST)
73.  Pro --Sebastian Wallroth (Diskussion) 20:59, 29. Jun. 2017 (CEST)
74.  Pro --MfG Monsterxxl <>< 22:06, 29. Jun. 2017 (CEST)
75.  Pro --1971markus ^{⇒ Laberkasten ...} 23:37, 29. Jun. 2017 (CEST)
76.  Pro --Anearthling (Diskussion) 00:05, 30. Jun. 2017 (CEST)
77.  Pro --Jaquento (Diskussion) 02:11, 30. Jun. 2017 (CEST)
78.  Pro -gpf- (Diskussion) 09:11, 30. Jun. 2017 (CEST)
79.  Pro -- Schönitzer (Diskussion) 20:50, 30. Jun. 2017 (CEST)
80. Abwartend. Für Übergangszeit evtl. Popuprefs als Lesehilfen-Helferlein anbieten und auf jeden Fall eine Caveats-Seite für Fußnoten-Tooltip und Popuprefs anlegen. --X:: black ::X (Diskussion) 02:18, 1. Jul. 2017 (CEST)
81.  Pro --XXThePhischXx (Diskussion) 14:50, 1. Jul. 2017 (CEST)
82. Abwartend. Hover-Fenter mit Kurzzitat ist eine gute Idee. Bisher läßt sich das per "in neuem Tab öffnen" und danach der Quelle nachgehen auch machen, ohne den "Lesestandort im Artikel" zu unterbrechen (nach Konsultation der Quelle einfach zurück zum vorherigen Tab, der ja dort stehenbleibt, wo man vorhin gelesen hatte). Diese Funktionalität sollte nicht beeinträchtigt werden; v.a. wenn man ohne Scripting unterwegs ist. Ob die angestrebte Funktion ohne Scripting auch funktionieren wird, bleibt eh offen und ist nicht unbedingt zu erwarten, was aber kein Problem wäre- --ProloSozz (Diskussion) 15:07, 1. Jul. 2017 (CEST)
83.  Pro --alexscho (Diskussion) 23:49, 1. Jul. 2017 (CEST)
84.  Pro --Tecumseh*1301 (Diskussion) 13:11, 2. Jul. 2017 (CEST)
85.  Pro -- Michi 14:46, 2. Jul. 2017 (CEST)
86.  Pro --Devotus (Diskussion) 15:12, 2. Jul. 2017 (CEST)
87.  Pro --Mr N (Diskussion) 19:17, 2. Jul. 2017 (CEST)
88.  Kontra ーTesser4D 【Diskussion】 23:03, 2. Jul. 2017 (CEST) Steuerung drücken und dann auf den Ref klicken geht auch. Hört sich wie ein Luxusproblem an. Gibt deutlich wichtigeres.
    
    

Sortierbare Tabellen in der Mobilversion ermöglichen

Was ist das Problem?

• mit der Klasse sortable ausgestattete Wikitabellen können in der Desktopansicht per JavaScript sortiert werden.
• in der Mobilversion ist das nicht möglich
  • mitunter wird im Artikeltext explizit auf das mögliche Sortieren einer Tabelle hingewiesen
  • in der Mobilversion, über die rund 50% aller Zugriffe auf unsere Inhalte erfolgen, gehen diese Hinweise ins Leere und verwirren den Leser
  • die Sortierfunktion stellt gerade bei großen Tabellen ein wichtiges Werkzeug zum Erfassen der Inhalte dar, dieses wird so der Hälfte unserer Leser verwehrt.

Wen betrifft das Problem besonders?

• Leser und Autoren

Lösungsvorschlag

phab:T49858 behandelt dieses Problem

Vorschlagende Person

hgzh

Diskussion

Hallo KnorxThieus (♂), weil die Abstimmung noch nicht läuft (s. Zeitplan), habe ich dein „Pro“ entfernt. Vom 19. Juni bis 2. Juli kann abgestimmt werden. Viele Grüße -- Johanna Strodt (WMDE) (Diskussion) 13:26, 29. Mai 2017 (CEST)

Unterstützung

1.  Pro Hgzh (Einreichende Person)
2.  Pro Rewo (Diskussion) 11:06, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 21:56, 19. Jun. 2017 (CEST)
4.  Pro Zellmer (Diskussion) 14:59, 20. Jun. 2017 (CEST)
5.  Pro --Noobius2 (Diskussion) 15:47, 20. Jun. 2017 (CEST)
6.  Pro --R.ganaus (Diskussion) 21:37, 20. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 22:57, 20. Jun. 2017 (CEST)
8.  Pro Michaelt1964 (Diskussion) 23:59, 20. Jun. 2017 (CEST) Wenn umsetzbar, ja bitte
9.  Pro --SkiFreak99 (Diskussion) 00:21, 21. Jun. 2017 (CEST)
10.  Pro --Quantenwiki (Diskussion) 18:00, 21. Jun. 2017 (CEST)
11.  Pro --MGChecker – (📞| 📝| ) 19:58, 21. Jun. 2017 (CEST)
12.  Pro --Septatrix (Diskussion) 23:46, 21. Jun. 2017 (CEST)
13.  Pro --Jossi (Diskussion) 12:20, 22. Jun. 2017 (CEST)
14.  Pro Dromedar61 (Diskussion) 11:55, 23. Jun. 2017 (CEST)
15.  Pro --Eriom (Diskussion) 12:25, 23. Jun. 2017 (CEST)
16.  Pro --Fernsehfan2014 (Diskussion) 12:59, 23. Jun. 2017 (CEST
17.  Pro Gestumblindi 22:22, 23. Jun. 2017 (CEST)
18.  Pro --Martin Luck (Diskussion) 15:11, 24. Jun. 2017 (CEST)
19.  Pro --Christian (Diskussion) 19:33, 24. Jun. 2017 (CEST)
20.  Pro --DomenikaBo (Diskussion) 21:27, 25. Jun. 2017 (CEST)
21.  Pro -- ^Thomas 08:04, 26. Jun. 2017 (CEST)
22.  Pro --Uj1405 10:37, 27. Jun. 2017 (CEST)
23.  Pro --Ak ccm (Diskussion) 00:13, 29. Jun. 2017 (CEST)
24.  Pro --Ailura (Diskussion) 11:58, 29. Jun. 2017 (CEST)
25.  Pro --Sebastian Wallroth (Diskussion) 20:59, 29. Jun. 2017 (CEST)
26.  Pro --Birne1993 (Diskussion) 21:40, 29. Jun. 2017 (CEST)
27.  Pro --MfG Monsterxxl <>< 22:08, 29. Jun. 2017 (CEST)
28.  Pro --Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST)
29.  Pro --X:: black ::X (Diskussion) 02:01, 1. Jul. 2017 (CEST)
30.  Pro --ProloSozz (Diskussion) 15:09, 1. Jul. 2017 (CEST)
31.  Pro --Fixuture (Diskussion) 17:53, 1. Jul. 2017 (CEST)
32.  Pro --MatthiasDD (Diskussion) 18:47, 1. Jul. 2017 (CEST)
33.  Pro --Ingeniör (Diskussion) 18:52, 1. Jul. 2017 (CEST)
34.  Pro --Sitacuisses (Diskussion) 12:38, 2. Jul. 2017 (CEST)
35.  Pro --Mr N (Diskussion) 19:20, 2. Jul. 2017 (CEST)
    
    

Bei Mehrfachreferenzierung Fußnoten-Link-Buchstaben hervorheben

Was ist das Problem?

• Derzeit ist es bei einer Mehrfachreferenzierung nahezu unmöglich, aus der Anmerkung mit vielen Link-Buchstaben wieder genau zu der Textstelle zu springen, von der aus die Fußnote angeklickt wurde. Bsp.: Pfullendorf hat in Fußnote 2 die Link-Buchstaben a bis l. Das wird ein Lotteriespiel, wieder in den Text oben zu kommen, und ist kaum zumutbar.

Wen betrifft das Problem besonders?

Alle Leser, die (aus welchen Gründen auch immer) nicht nur die Mouse-over-Mini-Vorschau (s. Vorschlag oben zur Hover-Funktion [die ich aktiviert habe]), benutzen wollen, sondern die Fußnote in voller Schriftgröße betrachten wollen und deshalb die Fußnotenziffer im Text angeklickt haben.

Lösungsvorschlag

Es wäre viel getan, wenn der zutreffende Link-Buchstabe hervorgehoben würde: Fettschreibung, Unterstreichung, Rahmung o. dgl. Danke!

Anmerkungen

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

Vorschlagende Person

Wi-luc-ky (Diskussion) 14:57, 29. Mai 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Wi-luc-ky (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:15, 19. Jun. 2017 (CEST)
3.  Pro Rübenkopf 12:18, 19. Jun. 2017 (CEST) … oder Hevorhebung durch Hintergrundfarbe …
4.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 13:19, 19. Jun. 2017 (CEST)
5.  Pro --FNDE 00:50, 20. Jun. 2017 (CEST)
6.  Pro  _hugarheimur 09:07, 20. Jun. 2017 (CEST)
7.  Pro Zellmer (Diskussion) 15:01, 20. Jun. 2017 (CEST)
8.  Pro --HerrAdams (D) 15:03, 20. Jun. 2017 (CEST)
9.  Pro --Andropov (Diskussion) 15:57, 20. Jun. 2017 (CEST)
10.  Pro --Rita2008 (Diskussion) 16:09, 20. Jun. 2017 (CEST)
11.  Pro --Avron (Diskussion) 22:26, 20. Jun. 2017 (CEST)
12.  Pro --Emergency doc (D) 22:39, 20. Jun. 2017 (CEST)
13.  Pro --Thomas Obermair 4 (Diskussion) 22:57, 20. Jun. 2017 (CEST)
14.  Pro --S. F. B. Morse^{ditditdadaditdit} 18:45, 21. Jun. 2017 (CEST)
15.  Pro Michi 19:10, 21. Jun. 2017 (CEST)
16.  Pro --MGChecker – (📞| 📝| ) 20:03, 21. Jun. 2017 (CEST)
17.  Pro --Pelz (Diskussion) 22:21, 21. Jun. 2017 (CEST)
18.  Pro --Jossi (Diskussion) 12:21, 22. Jun. 2017 (CEST)
19.  Pro --GodeNehler (Diskussion) 19:26, 22. Jun. 2017 (CEST)
20.  Pro … «« Man77 »» (A) wie Autor 21:26, 22. Jun. 2017 (CEST)
21.  Pro --Eriom (Diskussion) 12:27, 23. Jun. 2017 (CEST)
22.  Pro --Daniel749 Disk. (ST–WPST) 20:55, 23. Jun. 2017 (CEST)
23.  Pro --Frīheidasliova (FRĀGĀ) 08:40, 24. Jun. 2017 (CEST) Hat mich schon immer gestört. Gut, wenn das Problem endlich behoben würde.
24.  Pro --Cm95 (Diskussion) 11:27, 24. Jun. 2017 (CEST)
25.  Pro --Alva2004 (Diskussion) 13:54, 24. Jun. 2017 (CEST)
26.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
27.  Pro --Mushushu (Diskussion) 16:09, 25. Jun. 2017 (CEST)
28.  Pro --DomenikaBo (Diskussion) 21:28, 25. Jun. 2017 (CEST)
29.  Pro --Wrev (Diskussion) 22:25, 25. Jun. 2017 (CEST)
30.  Pro -- ^Thomas 08:05, 26. Jun. 2017 (CEST)
31.  Pro -- X:: black ::X (Diskussion) 16:12, 26. Jun. 2017 (CEST)
32.  Pro --W!B: (Diskussion) 18:24, 27. Jun. 2017 (CEST)
33.  Pro --Merlin2001 (Diskussion) 00:06, 28. Jun. 2017 (CEST)
34.  Pro --Ak ccm (Diskussion) 00:14, 29. Jun. 2017 (CEST)
35.  Pro -- hgzh 19:15, 29. Jun. 2017 (CEST)
36.  Pro --Sebastian Wallroth (Diskussion) 21:00, 29. Jun. 2017 (CEST)
37.  Pro --DerHexer (Disk., Bew.) 21:02, 29. Jun. 2017 (CEST)
38.  Pro Super Idee. Bitte mit Hervorhebung mit Schrift fett, Schriftgröße +1 und Hintergrund farbig --Snurb3010 (Diskussion) 23:02, 29. Jun. 2017 (CEST)
39.  Pro --Jaquento (Diskussion) 02:15, 30. Jun. 2017 (CEST)
40.  Pro --Frze ^{> Disk} 12:06, 30. Jun. 2017 (CEST)
41.  Pro --ProloSozz (Diskussion) 15:11, 1. Jul. 2017 (CEST)
42.  Pro -- Platte ^{∪∩∨∃∪} 22:23, 1. Jul. 2017 (CEST)
43.  Pro --Mabschaaf 22:38, 1. Jul. 2017 (CEST)
44.  Pro --Sitacuisses (Diskussion) 12:40, 2. Jul. 2017 (CEST)
45.  Pro --Devotus (Diskussion) 15:14, 2. Jul. 2017 (CEST)
46.  Pro --Mr N (Diskussion) 19:25, 2. Jul. 2017 (CEST)
47.  Pro --PAB (Diskussion) 19:46, 2. Jul. 2017 (CEST)
48.  Pro --Ghilt (Diskussion) 09:16, 4. Jul. 2017 (CEST)
    
    

Einfaches dauerhaftes Abschalten der Werbebanner, die stets auf Sachen hinweisen wie diese, oder aktuell den Fotowettbewerb, die mich nicht interessieren und die wegen springenden Seiteninhalts den Lesefluß stören und seekrank machen.

Was ist das Problem?

Man will in WP etwas nachschlagen und wird mit eingeblendeten Hinweise auf Events davon abgehalten. Und das auf jedem Brower auf jeder Maschine einzeln. <facepalm />

Wen betrifft das Problem besonders?

Alle.

Lösungsvorschlag

Generelles und globales Opt-in.

Vorschlagende Person

AchimP (Diskussion) 18:48, 29. Mai 2017 (CEST)

Diskussion

Ob du es glaubst oder nicht: Dieses tolle Feature gibt es schon seit Jahren! Du musst nur wahlweise in deine common.css, deine global.css auf meta oder die entsprechende .css deines Lieblingsskins die Zeile

#centralNotice{ 
  display: none;
}

einfügen und schon bist du alle nervigen Banner los. – KPFC 💬 19:19, 29. Mai 2017 (CEST)

Und das nennst Du "einfach"? Die OMA wird sich bedanken. --AchimP (Diskussion) 19:27, 29. Mai 2017 (CEST)

Der Klick auf „Verbergen“ sollte zumindest global und für alle Geräte gelten, auf denen man angemeldet ist. Wenn ich ein globales Banner hier im Desktopbrowser weggeklickt habe, dann will ich nicht nochmal das Gleiche lesen, weder in einer anderen Sprachversion/Schwesterprojekt, noch auf einem anderen Computer.

Oder, ganz andere Alternative: Angemeldete Benutzer bekommen gar keine Banner mehr angezeigt, stattdessen können sie in den Einstellungen angeben, für welche Themen sie sich interessieren und bekommen dann Nachrichten, die es bisher per Banner gab, über die Echo-Funktion, wo man sie wie üblich mit einem Klick als gelesen markieren kann. –Schnark 11:34, 30. Mai 2017 (CEST)

@Schnark: Während der Abstimmung wird dieses Mal der Diskussionsbereich ausgeblendet sein, damit klar ist, worauf abgestimmt wird. Könntest du deine Vorschläge also am besten als neue Wünsche formulieren? Danke schön! Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:31, 30. Mai 2017 (CEST)

Das ist zunächst einmal AchimPs Wunsch. Er muss entscheiden, ob er aus dem Diskussionsverlauf einen bestimmten Lösungsvorschlag in die Überschrift übernehmen will. Ob ich dann dazu einen Konkurrenzvorschlag mache, kann ich dann immer noch später entscheiden (und da ich weiß, wie man Phabricator verwendet, kann ich meine Wünsche auch anderweitig loswerden, insbesondere wenn ich meine, dass ein anderer Weg eher zur Umsetzung führt). –Schnark 09:07, 31. Mai 2017 (CEST)

Beide Vorschläge von Schnark sind nur Umformulierungen meiner Problembeschreibung bzw. meines Lösungsvorschlag. Sein "sollte zumindest global und für alle Geräte gelten" steht bei mir als Problembeschreibung "auf jedem Brower auf jeder Maschine einzeln". Sein "gar keine Banner mehr angezeigt, stattdessen können sie in den Einstellungen angeben, für welche Themen sie sich interessieren" ist mein Lösungsvorschlag "Opt-In".

Die Lösungsimplementierung sollte dann allerdings nicht, wie bereits möglich und von KPFC oben angeführt, das Einfügen "magischer" CSS-Befehle in eine bestimmte Datei (oder war es doch eine andere?) sein, sondern ein einfach zu findender(!) Schalter entweder an jedem Banner (wenn's bei Opt-Out bleibt) oder in den Benutzereinstellungen sein. --AchimP (Diskussion) 12:54, 31. Mai 2017 (CEST)

Ist bestimmt was feines, denn die Banner nerven nur: Viel zu groß, zu aufdringlich, … . Als Lösung wäre vielleicht noch interesant, ob man nicht neben das Symbol "Deine Mittelungen" ganz oben ein weiteres Symbol mit "allgemeine Mitteilungen" anbringt und so ganz auf Banner für alle verzichtet. --Boehm (Diskussion) 15:17, 20. Jun. 2017 (CEST)

Die Idee hatte schon ein anderer auf https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_Wünsche_2017/Beobachten_&_Benachrichtigen unter dem Punkt: "Meldungen" für Ankündigungen nutzen anstelle von Bannern. --Boehm (Diskussion) 23:47, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro AchimP (Einreichende Person)
2.  Pro Schnark 11:24, 19. Jun. 2017 (CEST)
3.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
4.  Pro --FNDE 00:51, 20. Jun. 2017 (CEST)
5.  Pro --Boehm (Diskussion) 15:16, 20. Jun. 2017 (CEST)
6.  Pro Bin aber für ein manuelles Aus- und Abschalten einzelner Inhalte. Was der Nutzer dann sehen will soll dieser selbst entscheiden können --Noobius2 (Diskussion)
7.  Pro Und stimme Noobius2 zu --Marvin2k (Diskussion)
8.  Pro Diese Bevormundung, was ich wie oft lesen soll, muss ein Ende haben. --mirer (Diskussion) 18:34, 20. Jun. 2017 (CEST)
9.  Pro --Holder (Diskussion) 19:58, 20. Jun. 2017 (CEST)
10.  Pro --Prüm 20:27, 20. Jun. 2017 (CEST)
11.  Pro --Wikifreund (Diskussion) 22:35, 20. Jun. 2017 (CEST) Die Häufigkeit der jetzigen Einblendungen gegenüber früheren Wikipedia-Jahren ist schon spürbar. Eine dauerhafte Option zum Abmelden der Nachrichten für angemeldete Benutzer überzeugt mich.
12.  Pro --Thomas Obermair 4 (Diskussion) 22:57, 20. Jun. 2017 (CEST)
13.  Pro --Bombenleger (Diskussion) 14:39, 21. Jun. 2017 (CEST)
14.  Pro --BlueDino (Diskussion) 01:22, 22. Jun. 2017 (CEST)
15.  Pro --Jossi (Diskussion) 12:22, 22. Jun. 2017 (CEST)
16.  Pro --HHill (Diskussion) 12:25, 22. Jun. 2017 (CEST)
17.  Pro --RotWeisserHai (Diskussion) 14:00, 24. Jun. 2017 (CEST)
18.  Pro --Martin Luck (Diskussion) 15:11, 24. Jun. 2017 (CEST)
19.  Pro --Rainald62 (Diskussion) 15:18, 24. Jun. 2017 (CEST)
20.  Pro --Christian (Diskussion) 19:36, 24. Jun. 2017 (CEST) Ich stimme Noobius2 zu.
21.  Pro --Pfeffermakrele (Diskussion) 22:52, 24. Jun. 2017 (CEST)
22.  Pro -- HBR (Diskussion) 01:23, 25. Jun. 2017 (CEST)
23.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
24.  Pro -- E-O (Diskussion) 22:37, 25. Jun. 2017 (CEST)
25.  Pro --Ak ccm (Diskussion) 00:16, 29. Jun. 2017 (CEST)
26.  Pro --M.Melcher (Diskussion) 12:48, 29. Jun. 2017 (CEST)
27.  Pro --Azaël (Diskussion) 17:04, 29. Jun. 2017 (CEST)
28.  Pro -- hgzh 19:16, 29. Jun. 2017 (CEST)
29.  Pro Ein ganz kleines BlinkBlink reicht doch auch. Wer es lesen will kann es dann groß machen. --Snurb3010 (Diskussion) 23:05, 29. Jun. 2017 (CEST)
30.  Kontra -gpf- (Diskussion) 09:13, 30. Jun. 2017 (CEST)
31.  Kontra. Sinvoll wäre aber meiner Meinung nach, die betehende Opt-Out-Funktion dahingehend zu diversifizieren, dass ein angemeldeter Benutzer wahlweise die Möglichkeit eines generellen Opt-Outs aber auch selektiver Opt-Outs nur für bestimmte Arten von Bannern hat. Auch den Wunsch Wikipedia:Umfragen/Technische Wünsche 2017/Beobachten & Benachrichtigen#"Meldungen" für Ankündigungen nutzen anstelle von Bannern halte ich für sinnvoll. --X:: black ::X (Diskussion) 02:44, 1. Jul. 2017 (CEST)
32.  Pro --Whisker (Diskussion) 21:06, 1. Jul. 2017 (CEST)
33.  Pro --Linopolus (Diskussion) 10:52, 2. Jul. 2017 (CEST)
    
    

(automatische) Silbentrennung für lange Wörter

Was ist das Problem?

Mitunter gibt es sehr lange Wörter in den Artikeln, besonders in der Mobilansicht und in Bildunterschriften laufen deshalb manche Wörter aus dem Seiten- /Bildbereich hinaus.

Übertriebenes Beispiel: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz

Wen betrifft das Problem besonders?

Mobilbenutzer und Leser nicht trivialer Artikel

Lösungsvorschlag

Aufbau eines Globalen Wörterbuchs nötig. (Oder Nutzung von https://de.wiktionary.org) Dadurch in der "gerenderten" Textvariante alle möglichen Trennungen der Wörter mit Weichen Trennzeichen versehen.

Anmerkungen

Man kennt dies beispielsweise aus LaTeX.

Vorschlagende Person

ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 20:56, 29. Mai 2017 (CEST)

Diskussion

Ich kenne die Wiktionary-Lösung nicht, aber vielleicht könnte man den Hyphenator in Wikimedia übernehmen und adaptieren. Beispielsweise müsste das wahrscheinlich individuell abschaltbar gemacht werden, weil sich Nutzer über so etwas aufregen. — Speravir – 00:57, 30. Mai 2017 (CEST)

Übertriebenes Beispiel: Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz

Browser beherrschen heutzutage eine Silbentrennung, wenn man es ihnen erlaubt. Funktioniert bei mir in Firefox auch prinzipiell, wenn im genannten Beispiel auch leicht fehlerhaft. Man müsste nur hyphens: auto irgendwo im CSS für die Bereiche deklarieren, in denen man eine Silbentrennung möchte. –Schnark 08:50, 30. Mai 2017 (CEST)

Warum nicht im gesamten Artikel? Ggf. mit opt-out für z. B. Eigennamen (mit Speravir's Einwand einer "globalen" deaktivier Möglichkeit). --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 18:57, 30. Mai 2017 (CEST)

Danke, Schnark, kannte ich noch nicht. Wenn ich mir aber SELFHTML, CSS/Eigenschaften/Textausrichtung/hyphens und Can I use... CSS Hyphenation ansehe, dann ist das noch nicht gut einsetzbar bzw. die Chromium-Variation müsste beachtet werden, und außerdem müsste dann wohl überall in Wikimedia sichergestellt sein, dass alle Texte mit einem lang-attribut versehen sind. — Speravir – 23:36, 4. Jun. 2017 (CEST)

Hallo ℱℒ𝒪ℛℐ𝒜𝒩, bei der Abstimmung wird die Diskussion eingeklappt, damit klar ist, worüber abgestimmt wird. Wenn die Hinweise in der Diskussion für deinen Wunsch hilfreich sind, wäre es wichtig, dass du sie oben – z. B. unter „Was ist das Problem?“ oder „Lösungsvorschlag“ ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 13:33, 8. Jun. 2017 (CEST)

@Flor!an: Hallo, hier bin ich noch mal mit einer anderen Sache: Der Titel deines Wunsches „Globales Wörterbuch mit Silbentrennung in den Artikeln übernehmen“ geht schon sehr stark in Richtung einer konkreten Lösung. Würdest du ihn so umformulieren, dass allen Lesenden das Problem schnell ersichtlich wird? Beispielsweise „Sehr lange Wörter werden nicht umgebrochen, v. a. in Mobilansicht und Bildunterschriften “-- Viele Grüße und besten Dank, Johanna Strodt (WMDE) (Diskussion) 13:01, 9. Jun. 2017 (CEST)

@Johanna Strodt (WMDE): Hi, aber der "Wunsch" ist doch eine Silbentrennung und nicht der "lange Wörter werden nicht umgebrochen". Vielmehr bezieht sich auch der Wunsch nicht darauf, dass Umbrüche/Silbentrennung in Wörtern möglich sind/werden (denn das gibt es ja schon: Weiches Trennzeichen) sondern das sie es per "default" sind. Deshalb dachte ich es ist eine "Wunschliste" und nicht eine "Fehlerdokumentationsliste" ... aber ich mag mich irren. Grüße --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 17:49, 9. Jun. 2017 (CEST)

@Flor!an: Hallo! Okay, mein Beispiel für den Wunsch-Titel war - einfach als Beispiel - zugegeben aus der Hüfte geschossen. Konkret kannst du das natürlich besser formulieren.

Aber ich verstehe, was du meinst: Das Projekt heißt Wunschliste und nicht Problemliste. Allerdings steht hinter jedem Wünschen ja ein Problem. Der Hintergrund meiner Bitte ist folgender: Für alle, die später am Wunsch arbeiten, ist es wichtig, das Problem genau zu verstehen. Denn es kann sein, dass der erste Lösungsansatz sich als technisch nicht umsetzbar herausstellt und man eine Alternative finden muss. Auch für die Abstimmung kann es vorteilhaft sein, das Problem in den Vordergrund zu stellen, denn es kann es sein, dass Leute deinem Problem zustimmen, aber nicht der vorgeschlagenen Lösung. Ist es durch diese Erklärung klarer geworden? -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 14:34, 10. Jun. 2017 (CEST)

erledigt --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 11:04, 13. Jun. 2017 (CEST)

@Flor!an:Da die Zeilenlänge ja erst auf dem jeweiligen Endgerät fest steht kann auch eine Silbentrennung erst dort vorgenommen werden. Wenn man das nicht über die bereits in vielen Browser implementierte hypens-Lösung erledigt oder mit eine Pattern-basierende (und dadurch fehleranfälligen Lösung) wie dem Hyphenator, sondern über (wie hier vorgeschlagen mittels eines Wörterbuches, dann müsste dieses Wörterbuch ja erst mal an den Client übertragen und dort dann mittels JavaScript angewandt werden. Und das dürfte im Hinblick auf die Ladezeiten (das aktuelle deutsche igerman98-Wörterbuch ist fast ein halbes MB groß) und die Performance (insbesodnere bei längeren Artiken und Diskussionen) nicht unproblematisch sein.

Ich fände es daher sinnvoller mit der CSS-Eigenschaft hypens zu arbeiten. Das ist immerhin ein Web-Standard, wir browserseitig implementiert (wodurch es so performant ist, wie möglich) und selbst wenn irgendein älterer Browser es mal nicht unterstützt, sieht es im schlimmsten Fall eben so aus, wie bisher auch.

Ich würde daher vorschlagen, die gerade vorgeschlagene Implementierung entweder erstmal ganz aus dem Wunsch zu nehmen oder durch hypens zu ersetzen. // Martin K. (Diskussion) 10:35, 19. Jun. 2017 (CEST)

@Martin K.: Nein, das stimmt nicht. Mit dem Einfügen von soft hyphens (HTML-Entität ­) kann serverseitig mithilfe eines Wörterbuchs Silbentrennung ermöglicht werden. --Gorlingor (Diskussion) 16:42, 20. Jun. 2017 (CEST)

@Gorlingor: Willst Du ernsthaft an jeder potentiellen Trennstelle in jedem einzelnen Wort jedes Artikels dieses Entity ausgeben lassen? Das sind hunderte, wenn nicht tausende Stellen pro Artikel! Von der Quelltextlesbarkeit mal ganz zu schweigen.

Übertriebenes Beispiel: Rind­fleisch­etikettierungs­überwachungs­aufgaben­übertragungs­gesetz
Mit manuell gesetztem ­ kein Problem

Soft hyphens sind dazu da einige wenige problematische Worte manuell damit auszustatten (und das kann man ja heute schon tun) - aber doch nicht durchgängig ganze Texte?! // Martin K. (Diskussion) 19:28, 20. Jun. 2017 (CEST)

Ja, also theoretisch ist das nicht so abwegig. Statt den Entities könnte auch direkt das Unicode-Symbol ins HTML eingefügt werden. Beim Copy&Pasten von Text aus der Wikipedia könnte das allerdings komisch werden, weil nicht alle Programme mit den soft hyphens richtig umgehen. Aber es ist nicht so, als wären soft hyphens nur dafür da, „einige wenige problematische“ Wörter damit auszustatten. So wird das vielleicht aktuell in der Wikipedia gehandhabt. Aber hier würde das ja programmatisch beim Rendern des HTML eingefügt werden, der Quelltext, den man beim Bearbeiten der Seite sieht, wäre davon unberührt. --Gorlingor (Diskussion) 20:06, 20. Jun. 2017 (CEST)

Abgesehen davon ist es auch denkbar, nicht jede Silbe mit einem Trennzeichen zu versehen, sondern nur an Wortfugen welche einzusetzen. Das ist typographisch gesehen eventuell sinnvoller, da wir in der Wikipedia eh Flattersatz haben. --Gorlingor (Diskussion) 20:12, 20. Jun. 2017 (CEST)

Hinweis: Ein deutsches Wörterbuch zur Silbentrennung wird zum Beispiel hier erstellt: [1] --Gorlingor (Diskussion) 16:42, 20. Jun. 2017 (CEST)

Ich hab mir das dortige Repo mal gecloned. Das Wörterbuch ist selbst komprimiert noch über 3MB groß (unkomprimiert 15MB). Das ist für die Client-Seite zu viel. Und zur Serverseite hatte ich ja oben schon einiges geschrieben. // Martin K. (Diskussion) 19:50, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Flor!an (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 15:07, 19. Jun. 2017 (CEST) Wörter mit Solltrennstellen sollten auf einfache Weise in eine entsprechende Liste eingetragen werden können; die Automatische Trennung sollte mit Tags (vor/nach Wort) abgeschaltet werden können (wenn das (aus welchem Grund auch immer) anders getrennt werden soll. Das sollte auch ohne Scripting und mit nicht mehr allerneusten Browsern funktionieren. ... -- 15:14, 1. Jul. 2017 (CEST) Nachtrag: default = keine automatische Silbentrennung; Einstellung in den persönlichen Eigenschaften (wo man es bei Bedarf einschalten können soll).
3.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
4.  Pro --Boehm (Diskussion) 15:20, 20. Jun. 2017 (CEST) (Wie in LaTeX, das wäre eine große Wohltat)
5.  Pro Wie ProloSozz --Blik (Diskussion) 16:19, 20. Jun. 2017 (CEST)
6.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe} 16:50, 20. Jun. 2017 (CEST)
7.  Pro Kontrollstelle Kundl 18:22, 20. Jun. 2017 (CEST)
8.  Pro --BigbossF★rin 19:33, 20. Jun. 2017 (CEST) ein internationales Wiktionary muss her, ggf. durch Wikidata.
9.  Pro --Thomas Obermair 4 (Diskussion) 22:57, 20. Jun. 2017 (CEST)
10.  Pro Michaelt1964 (Diskussion) 00:03, 21. Jun. 2017 (CEST) Wichtige Funktion, vor allem bei Mobiltelefonen. Dort sind die Spalten so schmal, dass bei langen Wörtern große Leerstellen in der Zeile bleiben
11.  Pro --SkiFreak99 (Diskussion) 00:22, 21. Jun. 2017 (CEST)
12.  Pro --BlueDino (Diskussion) 01:26, 22. Jun. 2017 (CEST)
13.  Pro --GodeNehler (Diskussion) 19:26, 22. Jun. 2017 (CEST)
14.  Pro --Minihaa (Diskussion) 12:30, 23. Jun. 2017 (CEST)
15.  Pro --Nichtich (Diskussion) 22:06, 23. Jun. 2017 (CEST)
16.  Pro --Frīheidasliova (FRĀGĀ) 08:42, 24. Jun. 2017 (CEST)
17.  Pro --Cmecklen67 (Diskussion) 09:40, 24. Jun. 2017 (CEST)
18.  Pro --Martin Luck (Diskussion) 15:12, 24. Jun. 2017 (CEST)
19.  Pro --Christian (Diskussion) 19:37, 24. Jun. 2017 (CEST)
20.  Pro Divof (Diskussion) 19:46, 24. Jun. 2017 (CEST)
21.  Pro --Wrev (Diskussion) 22:27, 25. Jun. 2017 (CEST)
22.  Pro --MikeTheGuru (Diskussion) 01:04, 26. Jun. 2017 (CEST)
23.  Kontra: das ist job des browsers, nicht unserer (was nicht heisst, dass man in zusammenarbeit mit den entwicklern etwa von firefox die wiktionary-silbentrennung abrufbar macht -- das ist aber ein wikt-projekt, kein WP-projekt: gibts aber auch schon wo anders, bitte das rad nicht nochmal erfinden, dazu ist entwicklerarbeitszeit zu kostbar). wir sollten uns eher um elegantere anwendung des &shy; (soft hyphen) für spezialanwendungen im layout kümmern: brauchen tut man den etwa bei ortsnamen, die nie in einem lexikon stehen werden, oder fremdsprachigem, oder insbesondere im tabellensatz und (wie beispiel oben) in bildunterschriften, um einen speziellen umbruch (von diversen möglichen) zu forcieren, also etwas, was die allgemeine silbentrennung, wer auch immer die macht, speziell zu artikelzwecken overruled --W!B: (Diskussion) 10:52, 27. Jun. 2017 (CEST)

    Hauptsache Du hast Dich in die Unterstützerliste eingetragen. --Gorlingor (Diskussion) 13:59, 27. Jun. 2017 (CEST)

24.  Pro --Merlin2001 (Diskussion) 00:09, 28. Jun. 2017 (CEST)
25.  Pro --Sebastian Wallroth (Diskussion) 21:03, 29. Jun. 2017 (CEST)
26.  Pro --MfG Monsterxxl <>< 22:12, 29. Jun. 2017 (CEST)
27.  Kontra -gpf- (Diskussion) 09:13, 30. Jun. 2017 (CEST)
28.  Pro --Anima (Diskussion) 14:21, 30. Jun. 2017 (CEST)
29.  Pro --Drahreg01 (Diskussion) 22:14, 1. Jul. 2017 (CEST)
    
    

Bessere Darstellung von Einrückungen in der mobilen Wikipedia

Was ist das Problem?

Bei Diskussionen mit vielen Einrückungen (mit ‚:‘) wird der Text oft auf viele Zeilen aufgeteilt, sodass manchmal pro Zeile nur noch ein Buchstabe steht, was sowohl dazu führt, dass der Lesefluss unterbrochen wird, als auch dazu, dass man ewig scrollen muss.

Wen betrifft das Problem besonders?

Alle Benutzer der mobilen Wikipedia

Lösungsvorschlag

Eine (auch nicht ganz optimale) Möglichkeit wäre, nach zum Beispiel drei Einrückungen eine Linie von rechts nach Links zu ziehen die rechts einen Strich nach oben hat und links einen nach unten, als Verbildlichung des nach links Ziehen des Textes. Dies ist für den Lesefluss gut, nicht unbedingt aber für die Übersichtlichkeit. Man könnte auch die Tiefe der einzelnen Einrückungen vergeringern, sodass eine Einrückung zB nicht mehr 1em, sondern nur noch 0.2em tief ist, wodurch das Problem entschärft, jedoch wahrscheinlich nicht komplett gelöst wird.

Vorschlagende Person

KPFC 💬 21:16, 29. Mai 2017 (CEST)

Diskussion

@KPFC: Danke für deinen Vorschlag! Ich könnte mir vorstellen, dass nicht ganz so erfahrene Leser dieser Umfrage mit "Minerva" nicht soviel anfangen können. Was hälst du davon, im Titel deshalb eher auch von der "mobilen Wikipedia" oder "mobilen Ansicht" zu sprechen, und Minerva eher in der Problembeschreibung zu nennen? Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:39, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro KPFC (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 21:57, 19. Jun. 2017 (CEST)
3.  Pro --FNDE 00:52, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 22:58, 20. Jun. 2017 (CEST)
5.  Pro -- Freddy2001 ^DISK 11:31, 24. Jun. 2017 (CEST)
6.  Pro --Ailura (Diskussion) 11:58, 29. Jun. 2017 (CEST)
7.  Pro --DerHexer (Disk., Bew.) 21:04, 29. Jun. 2017 (CEST)
8.  Pro --Birne1993 (Diskussion) 21:42, 29. Jun. 2017 (CEST)
9.  Pro --Wingsofcourage (Diskussion) 14:40, 30. Jun. 2017 (CEST)
10.  Pro --Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST)
11.  Pro ーTesser4D 【Diskussion】 23:05, 2. Jul. 2017 (CEST) Die Lösungsvorschläge sind alle nicht so top, aber schlimmer kanns kaum werden.
    
    

Follow-up zu dem Wunsch Schriftgröße mathematischer Formeln vereinheitlichen

Was ist das Problem?

• 
  so wäre es perfekt
• 
  und so
• 
  oder so
• 
  oder so
• 
  sieht es meistens aus

Wen betrifft das Problem besonders?

Mathematische und naturwissenschaftliche Artikel

Anmerkungen

Seit der letzten Umfrage hat sich zwar schon einiges verbessert, aber dies soll als Motivation dienen, weiterzumachen. Die Darstellung ist abhängig von Browser, Betriebssystem, Schriftarten, Bildschirmauflösung... daher kann ich nur beispielhaft ein paar Dinge nennen, die mutmaßlich auch andere betreffen:

• Die ${\text{Buchstaben}}$ sollten möglichst so aussehen wie die Buchstaben ohne math, erscheinen aber fett obwohl sie nicht $\mathbf {fett}$ sind. (Betrifft SVG?)
• Die Baseline und Schriftgröße der ${\text{Buchstaben}}$ sollte passen und sich z.B. für Bildunterschriften ${\text{automatisch}}$ der Schriftgröße anpassen . (Betrifft PNG?)
• Etwas wie ein Pfeil bei einem Vektor $\textstyle {\vec {V}}$ sollte (mit \textstyle) keinen zusätzlichen Zeilenabstand erfordern. (Betrifft SVG und PNG?)
• Zeichen wie ü in ${\text{für alle}}$ oder $\mathrm {\AA}$ (Ångström) sollten etwa so aussehen wie für alle oder Å bzw. workaround $\mathrm {f{\ddot {u}}r\ alle}$ oder ${\overset {\circ }{\mathrm {A} }}$. (Betrifft SVG?)
• Natürlich müssen Größen und Abstände von Symbolen auch innerhalb von Formeln richtig sein. (Betrifft native MathML mit Firefox-Plugin?)

Nicht alle rendering-Methoden müssen gefixt werden. Eine Methode, die für fast alle Leser funktioniert ist ausreichend. Für mich hat damals MathJax (phab:T99369) recht gut funktioniert.

Vorschlagende Person

Debenben (Diskussion) 23:37, 29. Mai 2017 (CEST)

Diskussion

siehe auch: Wikipedia:Technische_Wünsche/Topwünsche/Schriftgröße_mathematischer_Formeln_vereinheitlichen --Boehm (Diskussion) 12:31, 21. Jun. 2017 (CEST)

Unterstützung

1.  Pro Debenben (Einreichende Person)
2.  Pro Rübenkopf 12:20, 19. Jun. 2017 (CEST)
3.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 21:57, 19. Jun. 2017 (CEST)
5.  Pro --FNDE 00:55, 20. Jun. 2017 (CEST)
6.  Pro --HerrAdams (D) 15:08, 20. Jun. 2017 (CEST)
7.  Pro --Boehm (Diskussion) 15:28, 20. Jun. 2017 (CEST) (Längst überfälling: In der engl. WP verzweifeln die Autoren durch ein unsinniges Einfügen von \scriptsytle (der Schriftgröße für einen Index) für normalen Mathe-Text -- die dann erzeugten Indices sind nur noch mit der Lupe lesbar. Ich hoffe es wird eine bessere Lösung gefunden.)
8.  Pro --Rjh (Diskussion) 16:07, 20. Jun. 2017 (CEST)
9.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe 16:52, 20. Jun. 2017 (CEST)
10.  Pro --Claell (Diskussion) 19:15, 20. Jun. 2017 (CEST)
11.  Pro --Gelber kaktus (Diskussion) 21:52, 20. Jun. 2017 (CEST)
12.  Pro Hermannh (Diskussion) 22:22, 20. Jun. 2017 (CEST)
13.  Pro --Thomas Obermair 4 (Diskussion) 22:59, 20. Jun. 2017 (CEST)
14.  Pro --Abubiju (Diskussion) 13:59, 21. Jun. 2017 (CEST)
15.  Pro --Quantenwiki (Diskussion) 18:00, 21. Jun. 2017 (CEST)
16.  Pro Michi 19:11, 21. Jun. 2017 (CEST)
17.  Pro --Furfur ^{⁂ Diskussion} 22:26, 21. Jun. 2017 (CEST)
18.  Pro --GodeNehler (Diskussion) 19:27, 22. Jun. 2017 (CEST)
19.  Pro --Karl432 (Diskussion) 20:32, 23. Jun. 2017 (CEST)
20.  Pro --Daniel749 Disk. (ST–WPST) 20:58, 23. Jun. 2017 (CEST)
21.  Pro --Frīheidasliova (FRĀGĀ) 08:45, 24. Jun. 2017 (CEST)
22.  Pro --Rainald62 (Diskussion) 15:29, 24. Jun. 2017 (CEST)
23.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
24.  Pro --MikeTheGuru (Diskussion) 01:08, 26. Jun. 2017 (CEST)
25.  Pro --RookJameson (Diskussion) 19:43, 27. Jun. 2017 (CEST)
26.  Pro --Merlin2001 (Diskussion) 00:11, 28. Jun. 2017 (CEST)
27.  Pro --Kein Einstein (Diskussion) 15:01, 28. Jun. 2017 (CEST)
28.  Pro --Gr1 (Diskussion) 16:23, 28. Jun. 2017 (CEST)
29.  Pro ---Doc ζ 16:50, 28. Jun. 2017 (CEST)
30.  Pro --Digamma (Diskussion) 18:43, 28. Jun. 2017 (CEST)
31.  Pro --Alturand (Diskussion) 21:06, 28. Jun. 2017 (CEST)
32.  Pro --Franz 00:17, 29. Jun. 2017 (CEST)
33.  Pro --UvM (Diskussion) 09:40, 29. Jun. 2017 (CEST)
34.  Pro --Sebastian Wallroth (Diskussion) 21:06, 29. Jun. 2017 (CEST)
35.  Pro --mfb (Diskussion) 01:15, 30. Jun. 2017 (CEST)
36.  Pro --Jaquento (Diskussion) 02:12, 30. Jun. 2017 (CEST)
37.  Pro -gpf- (Diskussion) 09:16, 30. Jun. 2017 (CEST)
38.  Pro -- X:: black ::X (Diskussion) 17:06, 30. Jun. 2017 (CEST)
39.  Pro -<)kmk(>- (Diskussion) 03:19, 1. Jul. 2017 (CEST) längst überfällig.
40.  Pro -- Pemu (Diskussion) 13:31, 1. Jul. 2017 (CEST)
41.  Pro --PAB (Diskussion) 19:51, 2. Jul. 2017 (CEST)
42.  Pro --Ghilt (Diskussion) 09:18, 4. Jul. 2017 (CEST)
    
    

"Seitengröße in Bytes" der Versionen und ihre Veränderung besser vermitteln

1. In "Versionsgeschichte": Den Erläuterungstext instruktiver gestalten
2. In "Gewählte Versionen vergleichen": Den Änderungswert auch zur Detailanzeige eines Versionsunterschieds darstellen
3. Im "Artikel": Am Kopf der Seite die Seitengröße anzeigen

Was ist das Problem?

1. Der Beispielstext zur Erläuterung lautet aktuell:

(123 Bytes) = Größe der Version; (+543)/(-792) =‎ Änderung der Seitengröße in Bytes gegenüber der vorherigen Version

Die Zahl 123 ist dem Betrag nach viel kleiner als (+)543 und (-)792. Das ist nicht plausibel.

Mein Vorschlag daher:

(123 Bytes) = Größe der Version; (+/-45) =‎ Änderung der Seitengröße in Bytes gegenüber der vorherigen Version

... ist kürzer und macht Sinn, denn Veränderungen sind in der Regel kleiner als der aktuelle Größenstand des Artikels ... niedrige Zahlen lassen das Beispiel etwas schneller lesen, wenn auch 1.234 oder 12.345 plausibler für die Artikelgröße wären

2. In der Liste der Versionen ist die "Spalte Änderung der Seitengröße" die kürzeste Information über den Charakter eines Veränderungsschritts durch Redigieren.

Die – ich nenne sie – Größenänderungszahl ist mit dem Vorzeichen und der Größe ihres Zahlenwerts ein guter Anhaltspunkt für den Charakter der Änderung von Version zu Folgeversion.

Ein- bis zweistellige Werte weisen meist auf nur kleine Korrekturen hin. Drei- bis vierstellige (positive) gehören meist zu entsprechend großen Beiträgen, größere negative Werte zu kürzenden Löschungen. Genaue Reverts weisen den ins Negative gekehrten Wert der Vor-Veränderung auf.

Lässt man sich per Gewählte Versionen vergleichen die Änderungen Spalte gegenüber Spalte im Detail anzeigen, verschwindet diese Größenänderungszahl.

Dabei habe ich mir gerade diese kurze Zahlen besser eingeprägt als die ja immer 12-stelligen Datumangaben (hh:mm, dd.monat.jjjj) der Versionen.

Gut wäre also im Kopf der Anzeige Gewählte Versionen vergleichen die Größenänderungszahl (als Bilanz zwischen den zwei verglichenen Versionen, im Kopf der rechten Spalte) anzuzeigen.

Damit lässt auch die Größenänderungszahl zwischen zwei beliebig ausgewählten Versionen bilanzieren.

Beim Durchblättern von unmittelbar aufeinander abfolgenden Versionen erscheinen gut wiedererkennbar die Größenänderungszahlen der Versionsliste.

Zweckmässig ist wohl auch das Anzeigen der Seitengröße (in Byte) im Kopf der zwei Versionen in der Vergleichsansicht.

3. Artikelansicht

Die Seitengröße in kleiner Schriftgröße, eventuell auch das Datum der Version der Version anzeigen.

Im Sinn von "abgerufene Version" für Leser der Wikipedia, die eine Seite ausdrucken.

Wen betrifft das Problem besonders?

Wer sich in die Versionsgeschichte vertieft

Lösungsvorschlag

siehe oben

Anmerkungen

–

Vorschlagende Person

Helium4 (Diskussion) 06:16, 30. Mai 2017 (CEST)

Diskussion

@Helium4: Ich könnte mir vorstellen, dass es Sinn machen würde, hier drei Wünsche anstelle von einem zu formulieren. Dann könnte man für 1, 2 und 3 separat abstimmen. Könntest du sie vielleicht separieren? Danke und viele Grüße, Lea Voget (WMDE) (Diskussion) 14:14, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Helium4 (Einreichende Person)
2.  Pro --FNDE 00:55, 20. Jun. 2017 (CEST)
3.  Pro --Thomas Obermair 4 (Diskussion) 22:59, 20. Jun. 2017 (CEST)
4.  Pro --DomenikaBo (Diskussion) 21:29, 25. Jun. 2017 (CEST)
5. (Unter-)Wünsche 1 und 2:  Pro; (Unter-)Wunsch 3:  Kontra, die Artikelseite soll leserorientiert sein und nicht mit für den Leser in der Regel irrelevanten Informationen überfrachtet werden. -- X:: black ::X (Diskussion) 17:16, 30. Jun. 2017 (CEST), aktualisiert 02:54, 1. Jul. 2017 (CEST) und 10:44, 2. Jul. 2017 (CEST)
6.  Pro --Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST)
7.  Pro --ProloSozz (Diskussion) 15:17, 1. Jul. 2017 (CEST)
8.  Kontra -- Vorschlag 1 ist irreführend, wenn zwischen zwei (nicht notwendigerweise aufeinander folgenden) Versionen mehr Bytes gelöscht und eingefügt werden, als die Seite lang ist, ist auch das eine sinnvolle und wertvolle Information, die erhalten bleiben sollte. PAB (Diskussion) 19:56, 2. Jul. 2017 (CEST)
   
   

Einbindung der Beacon-Datei in Personenartikeln

Ich wünsche mir eine prominentere Präsentation der Beacon-Datei in biografischen Artikeln.

Was ist das Problem?

Für die biografische Artikel wird die sogenannte GND eingepflegt (sofern vorhanden), die von der Deutschen Nationalbibliothek vergeben wird. Zweck ist eine eindeutige Identifizierung von Personen über alle beteiligten Projekte, die über das Beacon-Projekt koordiniert wird. Leider wird nicht angemeldeten Nutzern die Verlinkung zu den beteiligten Projekten gar nicht angezeigt und angemeldete Nutzer sehen die Verlinkung ganz unten (über den Kategorien bzw. den Personendaten) und wird damit unterrepräsentiert für den Informationsgehalt, den die Beacon-Datei leisten könnte.

Wen betrifft das Problem besonders?

• Unangemeldete Nutzer

Lösungsvorschlag

Schön wäre ein ausklappbares Menü ganz oben im Artikel, das sämtliche Verlinkungen der beteiligten Projekte anzeigt, so dass der Umweg über den AKS-Link wegfällt. Der AKS-Link ist jener, der zu einer Übersicht führt, der sämtliche Projekte auflistet, die die GND nutzen und für die eine Beacon-Datei zur Verfügung gestellt wird. Zum Beispiel für Johann Sebastian Bach. Manche Websiten binden die Übersicht direkt ein (z.B. die Sächsische Biografie: Albrecht der Beherzte)

AKS-Link

Vorschlagende Person

Das Robert .... gibs mir! 10:47, 30. Mai 2017 (CEST)

Diskussion

@Das Robert: Könntest du noch erklären, was der AKS-Link ist? Das wäre super! Gerne auch ein Screenshot :) Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:25, 30. Mai 2017 (CEST)

Der AKS-Link (nicht AKL-Link. Ich hatte mich verschrieben :) ) ist jener, der zu einer Übersicht führt, der sämtliche Projekte auflistet, die die GND nutzen und für die eine Beacon-Datei zur Verfügung gestellt wird. Hier zum Beispiel für Johann Sebastian Bach.

@Das Robert: Super, danke! Könntest du als letzten Schritt die Info noch in das Problem oder den Lösungsvorschlag einfügen? Bei der Abstimmung wird die Diskussion versteckt, damit klar ist, worüber abgestimmt wird (und damit wäre dann deine schöne Erklärung unsichtbar). Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:43, 30. Mai 2017 (CEST)

Unterstützung

1.  Pro Das Robert (Einreichende Person)
2.  Pro --Thomas Obermair 4 (Diskussion) 23:01, 20. Jun. 2017 (CEST)
3.  Pro -- wobei nicht die Beacon-Datei sondern die darin enthaltenen Links relevant sind. Nichtich (Diskussion) 22:08, 23. Jun. 2017 (CEST)
4.  Kontra prominentere Darstellung (Wesentliches zur Person gehört in den WP-Artikel),  Pro Darstellung für unangemeldete Benutzer. --Rainald62 (Diskussion) 15:34, 24. Jun. 2017 (CEST)
   • @Rainald62: Ich habe mich leider missverständlich ausgedrückt. Mit "prominenter" meine ich, dass der AKS-Link oder ein aufklappbares Menü ganz oben im Artikel (ähnlich wie bei Artikeln mit Geo-Koordinaten) stehen soll. --Das Robert .... gibs mir! 13:19, 26. Jun. 2017 (CEST)
     • So ähnlich hatte ich mir das vorgestellt und lehne es ab. Die Verlinkung mit Normdaten ist für sehr viel weniger Leser interessant als die Koordinaten. Wer auf den Geo-Link klickt, wird selten enttäuscht, wer als Nicht-Experte auf Normdaten-Links klickt, ist meist enttäuscht, während BEACON-Experten den Link unten kennen und ohne Scrollen hinkommen (Taste <Ende> in Firefox). --Rainald62 (Diskussion) 14:04, 26. Jun. 2017 (CEST)
5.  Kontra Ich sehe den Mehrwert nicht. Wenn ich sehen will was bei GND steht, klicke ich auf den Link bei den Normdaten.--Avron (Diskussion) 10:07, 26. Jun. 2017 (CEST)
   • @Avron: Der Mehrwert besteht m.E. darin, dass man nicht ständig bis zum Ende des Artikels scrollen muss, um an den Link zu kommen. Ich stelle mir das so vor, oben rechts (ähnlich wie bei Artikeln mit Geo-Koordinaten) die GND eingeblendet wird, die sich mit einem Klick ein Menü aufklappen lässt, das die teilnehmenden Projekte preisgibt. --Das Robert .... gibs mir! 13:19, 26. Jun. 2017 (CEST)
     • Ich sehe es ähnlich wie Benutzer:Rainald62. --Avron (Diskussion) 15:12, 26. Jun. 2017 (CEST)
6.  Pro --Whisker (Diskussion) 21:09, 1. Jul. 2017 (CEST)
7.  Pro --Mr N (Diskussion) 19:59, 2. Jul. 2017 (CEST)
   
   

Gallery Darstellung in der Mobilansicht vergrößern

Was ist das Problem?

Beispiel Hochformat

Beispiel Querformat

bei regulärer Nutzung der Hilfe:Galerie sprich z. B.:

<gallery>
Bild1
Bild2
Bild3
</gallery>

werden in der Mobilversion riesige Abstände (Margins) um die einzelnen Bilder angezeigt, die Bilder hingegen sehr klein.

Wen betrifft das Problem besonders?

Mobil Nutzer

Lösungsvorschlag

Margins (vor allem oben und unten) deutlich verkleinern und Bilder größere Anzeigen (auf den Vorschauen erkennt man ja nicht mal was drauf ist). Ggf. je nach Auflösung zwei nebeneinander anzeigen.

Vorschlagende Person

ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 09:49, 31. Mai 2017 (CEST)

Diskussion

@Flor!an: Das dürfte sich mit diesem Wunsch überschneiden/kombinieren lassen, oder? // Martin K. (Diskussion) 18:35, 13. Jun. 2017 (CEST)

@Martin Kraft: Hmmm ähnlich aber eine Überschneidung sehe ich nicht direkt. Klar man könnte den Rahmen weglassen. Aber hier geht es ja nicht um eine Verkleinerung DURCH den Rahmen, sondern das die Bilder (zu) klein Dargestellt werden. Auf der Nicht-Mobil Ansicht finde ich diesen prinzipiell garnicht schlecht (wenn auch etwas zugroß) aber der Vorschlag den Modus "packed" anstelle zu Nutzen gefällt mir nicht soo gut. Zusammenfassend ich sehe dadrin 2 paar Schuhe. Hier: Größe der Bilder (besonders Mobil). Der andere Beitrag: Gegen den dort beschriebenen "Skeuomorphismus" bei der Gallery. --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 19:15, 13. Jun. 2017 (CEST)

Unterstützung

1.  Pro Flor!an (Einreichende Person)
2.  Pro Rewo (Diskussion) 11:08, 19. Jun. 2017 (CEST)
3.  Pro Martin K. (Diskussion) 11:37, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 21:59, 19. Jun. 2017 (CEST)
5.  Pro --FNDE 00:56, 20. Jun. 2017 (CEST)
6.  Pro -- Barnos (Post) 08:08, 20. Jun. 2017 (CEST)
7.  Pro Zellmer (Diskussion) 15:08, 20. Jun. 2017 (CEST)
8.  Pro --Thomas Wozniak (HSP) (Diskussion) 15:14, 20. Jun. 2017 (CEST)
9.  Pro --Blik (Diskussion) 16:22, 20. Jun. 2017 (CEST)
10.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe 16:53, 20. Jun. 2017 (CEST)
11.  Pro --  Sir Gawain Disk. 17:55, 20. Jun. 2017 (CEST)
12.  Pro --Till.niermann (Diskussion) 20:42, 20. Jun. 2017 (CEST)
13.  Pro --Thomas Obermair 4 (Diskussion) 23:01, 20. Jun. 2017 (CEST)
14.  Pro --rugk (Diskussion) 00:35, 21. Jun. 2017 (CEST)
15.  Pro --jcornelius  11:36, 21. Jun. 2017 (CEST)
16.  Pro --Quantenwiki (Diskussion) 18:00, 21. Jun. 2017 (CEST)
17.  Pro --Atamari (Diskussion) 12:13, 23. Jun. 2017 (CEST)
18.  Pro mauriceKA (Diskussion) 13:33, 23. Jun. 2017 (CEST)
19.  Pro --Nichtich (Diskussion) 22:09, 23. Jun. 2017 (CEST)
20.  Pro -- Freddy2001 ^DISK 11:32, 24. Jun. 2017 (CEST)
21.  Pro --DomenikaBo (Diskussion) 21:30, 25. Jun. 2017 (CEST)
22.  Pro --Merlin2001 (Diskussion) 00:16, 28. Jun. 2017 (CEST)
23.  Pro -- hgzh 19:16, 29. Jun. 2017 (CEST)
24.  Pro --Sebastian Wallroth (Diskussion) 21:10, 29. Jun. 2017 (CEST)
25.  Pro --DerHexer (Disk., Bew.) 21:19, 29. Jun. 2017 (CEST)
26.  Pro Warum steht das nicht auf der Wunschliste für Mediendateien? --Snurb3010 (Diskussion) 23:14, 29. Jun. 2017 (CEST)
27.  Pro --Linopolus (Diskussion) 10:53, 2. Jul. 2017 (CEST)
    
    

Maschinengesteuertes vorlesen von Wikipedia-Artikeln unter Berücksichtigung der Vorlage Lang

Was ist das Problem?

Ältere Menschen haben oft Probleme mit dem Lesen längerer Texte am Bildschirme, erblindete und sehbehinderte Menschen sind davon grundsätzlich betroffen. Ich kenne derzeit keine Softwarelösung, die Wikipedia-Artikel mit unterschiedlichen Sprachattributen lesen kann.

Wen betrifft das Problem besonders?

Erblindete und sehbehinderte Menschen sowie ältere Menschen

Lösungsvorschlag

Der Screenreader muss zuerst die Basis-Sprache erkennen und dann Anhand der unterschiedlichen Kürzel in den verwendeten Vorlagen Lang die entsprechenden Sprachmodule laden und dann anschließend beim Lesen des Textes in Abhängigkeit des Sprachkürzels in der Vorlage Lang auf die verschiedenen Sprachmodule zugreifen und sprachbezogen vorlesen.

Vorschlagende Person

Ulanwp (Diskussion) 23:33, 31. Mai 2017 (CEST)

Diskussion

So etwas wird bereits unter dem Namen mw:Wikispeech entwickelt. Ob dort die Sprachattribute bereits korrekt beachtet werden, weiß ich nicht, aber ich gehe davon aus, dass es zumindest geplant ist. –Schnark 09:32, 1. Jun. 2017 (CEST)

Danke für die Info, habe mir die Projektseiten gerade mal angeschaut. Das ganze Projekt ist selbst für technikaffine Menschen schwer zugänglich. Was ich nicht finden konnte ist so etwas wie ein Pflichtenheft, in dem genau beschrieben steht, was die Software im Detail können muss und wie sie beim Lesen vorgehen soll. Es wird lediglich auf Modulebene etwas beschrieben, aber ob die Vorlage Lang dabei Berücksichtigung findet, ist nicht zu ermitteln. Gibt es die Vorlage eigentlich in den anderen Sprachumgebungen oder ist sie nur in der dt. WP existent? — Ulanwp (Diskussion) 19:16, 1. Jun. 2017 (CEST)

Die Vorlage an sich ist nicht das Entscheidende, wichtig ist das HTML, das die Vorlage erzeugt. Dort setzt sie korrekt das lang-Attribut, womit jede Vorlese-Software problemlos erkennen kann, welche Sprache gewünscht ist. Ob sie das auch beachtet (insbesondere ob sie überhaupt während des Vorlesens die Sprache wechseln kann), ist eine andere Frage. Theoretisch müsste mein Proof-of-Concept-Skript Benutzer:Schnark/js/vorleser dazu sogar in der Lage sein, hat aber seine ganz eigenen Probleme. –Schnark 09:15, 2. Jun. 2017 (CEST)

Für Menschen, die auf Screenreader angewiesen sind, gibt es im Prinzip bereits eine Vielzahl an guten Lösungen, die für alle möglichen Websites und natürlich auch die Wikipedia einsetzbar sind. Verstehe ich den Vorschlag daher richtig, dass es im Prinzip einzig um den Aspekt geht, dass etablierte Screenreader fremdsprachige, per {{Lang}} gekennzeichnete Textteile nicht als solche identifizieren und daher z.B. ein englisches Zitat in einem deutschen Text falsch aussprechen? Und daher den Wunsch, so etwas in geeigneter Form einzubauen? Gestumblindi 22:29, 23. Jun. 2017 (CEST)

Ich verstehe den Vorschlag auch nicht ganz. Mit {{Lang}} ausgezeichnete Textstellen sollten im Jahre 2017 von jedem Screenreader korrekt behandelt werden. --Gorlingor (Diskussion) 14:32, 27. Jun. 2017 (CEST)

Unterstützung

1.  Pro Ulanwp (Einreichende Person)
2.  Pro --Thomas Wozniak (HSP) (Diskussion) 15:13, 20. Jun. 2017 (CEST)
3.  Pro --Claell (Diskussion) 19:16, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 23:02, 20. Jun. 2017 (CEST)
5.  Pro --GodeNehler (Diskussion) 19:28, 22. Jun. 2017 (CEST)
6.  Pro --Mushushu (Diskussion) 16:10, 25. Jun. 2017 (CEST)
7.  Pro --Menschpædia (Diskussion) 23:33, 25. Jun. 2017 (CEST)
8.  Pro --Merlin2001 (Diskussion) 00:18, 28. Jun. 2017 (CEST)
9. Abwartend. Wenn mw:Wikispeech Fortschritte macht und die gewünschte Funktionalität darin angestrebt wird, sollte es – auch für die deutsche Sprache – genutzt werden und nicht das Rad in jedem Wikiprojekt neu erfunden werden. --X:: black ::X (Diskussion) 03:07, 1. Jul. 2017 (CEST)
10.  Pro --Devotus (Diskussion) 15:21, 2. Jul. 2017 (CEST)
    
    

SVG-Dateien sollten direkt in Artikel und andere Seiten eingebunden werden anstatt Pixelgrafiken einzubinden.

Was ist das Problem?

Derzeit kann man zwar SVG-Dateien hochladen, diese werden allerdings nicht in den Artikeln angezeigt, sondern stattdessen in PNG-Dateien konvertierte Version, obwohl inzwischen moderne Browser SVG darstellen können. Dieses Vorgehen ist gerade beim Zoomen von Nachteil, denn diese konvertierten Grafiken werden nicht detaillierter, lediglich unscharf. Um zur eigentlichen Vektorgrafik zu gelangen, muss man erst auf die Beschreibungsseite und dann auf die Datei. Das sind für jede Grafik, die man sich genauer ansehen will, zwei zusätzliche Klicks.

Wen betrifft das Problem besonders?

Alle Leser, insbesondere solche mit Touchscreens

Lösungsvorschlag

Über eine Benutzereinstellung und/oder eine Browserweiche soll entschieden werden, ob eine konvertierte PNG- oder die SVG-Version in die HTML-Seite eingebunden werden soll. Um bei mehrsprachigen Dateien die richtige Sprache auszuwählen und ggf. Skripte zu entfernen, muss für jede SVG-Datei eine entsprechende Version zum Einbinden erstellt werden, das sollte technisch kein Problem sein.

Vorschlagende Person

Morten Haan 🍱 Wikipedia ist für Leser da • Skin-Entwurf 00:41, 1. Jun. 2017 (CEST)

Diskussion

• Siehe phab:T5593. –Schnark 09:38, 1. Jun. 2017 (CEST)
• @Morten Haan: Das in „Einbindung interaktiver Medieninhalte ermöglichen“ vorgeschlagen Vorgehen dürfte doch auch diesen Wunsch hier erfüllen?! // Martin K. (Diskussion) 18:38, 13. Jun. 2017 (CEST)

  Denke schon, ich will es aber trotzdem als eigenständigen Wunsch hier stehen lassen, da es bei deinem um ein anderes Problem geht. --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 02:52, 15. Jun. 2017 (CEST)

Ich bin in der WP:Grafikwerkstatt aktiv, und es gibt genug SVG->PNG Bugs Wikipedia:WikiProjekt_SVG#Einschr.C3.A4nkungen_des_SVG-PNG-Renderers_der_Wikipedia,Wikipedia:Probleme_mit_SVGs die das erstellen von SVGs sehr mühsam machen, da man diese umgehen muss und z.B. eine Schrifteneinbindung nicht erlauben so z.B. in File:Beziehung_zwischen_Wikipedia_und_Wikipedia.svg, dabei kann Chrome und Firefox auch ausgerichteten Text richtig anzeigen: https://upload.wikimedia.org/wikipedia/commons/archive/d/d8/20170608163431%21Manfeild_Autocourse_track_map_%28New_Zealand%29_clockwise.svg

wobei dann wird jegliche Darstellung Browserabhänig, weiß nicht ob das vorteilhaft ist (bei Internet Explorer und Windows Edge gibt es viele Funktionen nicht und Chrome und Firefox unterscheiden sich auch in der Funktionalität)

@Antonsusi: Als aktivster in der WP:Grafikwerkstatt, was haltest du von der Idee.  — Johannes Kalliauer - Diskussion | Beiträge 20:09, 21. Jun. 2017 (CEST)

Klar wäre es besser, wenn die SVGs direkt dargestellt erden. Hierzu muss man nur ein Set an freien Fonts festlegen, welche bei der Erstellung der SVGs verwendet werden sollten. alle anderen Elemente sind nicht vom System des Nutzers abhängig. Wenn ein Browser diverse Features nicht unterstützt, ist das kein Mangel der Datei. Ich z. B. benutze standardmäßig den Firefox, aber SVGs betrachte ich bevorzugt mit dem Opera, denn der hat den besten SVG-Renderer. ÅñŧóñŜûŝî (Ð) 19:33, 22. Jun. 2017 (CEST)

Das mit den Fonts wäre kein Problem, wenn der Media-Wiki-Renderer Webfonts unterstützen würde. Dann könnte man nämlich auf irgendeinem Wikimedia-Server eine freie Alternative zu Google-Fonts aufbauen und die nach Belieben in SVGs einsetzen, die dann trotzdem in allen vernünftigen Browsern oderndetlich dargestellt werden.

P.S.: Hat Opera einen anderen SVG-Renderer als Chrome? Das ist doch beides Blink mittlerweile ?! // Martin K. (Diskussion) 20:13, 22. Jun. 2017 (CEST)

Das Übertragen einer sehr detaillierten SVG verursacht weitaus mehr Datentraffic als eine auf 220px runtergerechnete PNG-Datei. Dies sollte vor allem bei mobilen Nutzern, die volumenbasiert abgerechnet werden, berücksichtigt werden. -- Freddy2001 ^DISK 11:35, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Morten Haan (Einreichende Person)
2.  Pro ProloSozz (Diskussion) 15:09, 19. Jun. 2017 (CEST) (sofern bei SVG-Darstellungsunfähigkeit des Browsers stattdessen ein PNG gezeigt wird, aber dennoch das SVG verlinkt)
3.  Pro DCB (Diskussion • Bewertung) 22:00, 19. Jun. 2017 (CEST)
4.  Pro --Boehm (Diskussion) 15:34, 20. Jun. 2017 (CEST)
5.  Pro --Andropov (Diskussion) 16:02, 20. Jun. 2017 (CEST)
6.  Pro --Claell (Diskussion) 19:17, 20. Jun. 2017 (CEST)
7.  Pro --FriedhelmW (Diskussion) 21:49, 20. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 23:02, 20. Jun. 2017 (CEST)
9.  Pro --Bombenleger (Diskussion) 14:39, 21. Jun. 2017 (CEST)
10.  Pro sk (Diskussion) 16:50, 21. Jun. 2017 (CEST)
11.  Pro Michi 19:11, 21. Jun. 2017 (CEST)
12.  Pro --MGChecker – (📞| 📝| ) 19:52, 21. Jun. 2017 (CEST)
13.  Pro  — Johannes Kalliauer - Diskussion | Beiträge 20:09, 21. Jun. 2017 (CEST) Für angemeldete Nutzer in Optionen verfügbar, da SVG-Darstellung sehr Browserabhängig.
14. Abwartend Manchmal steht auf der Beschreibungsseite (also auf der Seite, die beim Hochladen eines Bildes in die Commons ausgefüllt werden muss) noch wesentlicher Inhalt, beispielsweise die Legende zu einem Stadtplan, o. ä. Das würde verlorengehen, wenn man immer gleich zur SVG-Datei gelangt und das fände ich nicht so sinnvoll. Meines Erachtens nach sollte das Problem eher so angegangen werden, dass die SVG-zu-PNG-Renderer von MediaWiki optimiert wird, was schon lange fällig ist. --Furfur ^{⁂ Diskussion} 22:45, 21. Jun. 2017 (CEST)
    @Furfur: Es geht nicht um das mit der Vorschau verbundene Linkziel, sondern um das Vorschaubild im Artikel, zurzeit ein per librsvg gerendertes png, für manche svg/Geräte/Browser besser das svg, weil zoombar und ohne die vielen librsvg-Fehler. Das svg würde natürlich mit gleicher Rahmengröße in den Artikel eingebaut, sodass für eine große Ansicht immer noch zu klicken ist, mit Linkziel Beschreibungsseite. --Rainald62 (Diskussion) 21:51, 26. Jun. 2017 (CEST)
15.  Pro --Dominic Z. (Diskussion) 18:15, 22. Jun. 2017 (CEST)
16.  Pro --GodeNehler (Diskussion) 19:28, 22. Jun. 2017 (CEST)
17.  Pro // Martin K. (Diskussion) 20:13, 22. Jun. 2017 (CEST)
18.  Pro --Atamari (Diskussion) 12:18, 23. Jun. 2017 (CEST)
19.  Pro --Minihaa (Diskussion) 12:32, 23. Jun. 2017 (CEST)
20.  Pro --Quiethoo (Diskussion) 13:28, 23. Jun. 2017 (CEST)
21.  Pro An Mobilgeräte die kleinere Datei senden. Und rsvg updaten. --Rainald62 (Diskussion) 15:47, 24. Jun. 2017 (CEST)
22.  Pro Divof (Diskussion) 19:48, 24. Jun. 2017 (CEST)
23.  Pro --Menschpædia (Diskussion) 23:34, 25. Jun. 2017 (CEST)
24.  Pro --MikeTheGuru (Diskussion) 01:10, 26. Jun. 2017 (CEST)
25.  Pro --Merlin2001 (Diskussion) 00:19, 28. Jun. 2017 (CEST)
26.  Pro --Gr1 (Diskussion) 16:25, 28. Jun. 2017 (CEST) Aber nur für die Desktopansicht, nicht für die mobile Ansicht (Datentraffic, Renderingperformance).
27.  Pro -- hgzh 19:17, 29. Jun. 2017 (CEST)
28.  Pro --Sebastian Wallroth (Diskussion) 21:13, 29. Jun. 2017 (CEST)
29.  Pro --Snurb3010 (Diskussion) 23:16, 29. Jun. 2017 (CEST)
30.  Pro --Linopolus (Diskussion) 10:54, 2. Jul. 2017 (CEST)
31.  Pro --Doc ζ 14:11, 2. Jul. 2017 (CEST)
32.  Pro --Mr N (Diskussion) 19:41, 2. Jul. 2017 (CEST)
33.  Kontra -- Ältere Computer und einfachere Geräte mit alternativen Betriebssystemen werden Ressourcen-Probleme bekommen, wenn zu viele SVG-Grafiken direkt in die Seite eingebunden sind bzw. können teilweise SVG garnicht direkt darstellen. Wenn überhaupt, sollte man vorher testen, ob der Browser SVGs akzeptiert und nur dann direkt einbetten. PAB (Diskussion) 20:13, 2. Jul. 2017 (CEST) Geräte, die Performance-Probleme haben, sind heute weit überwiegend mobile Geräte, und da sind die Probleme Zeit und Energieverbrauch für den Download. Also die kleinere Datei ausliefern. Bei meinen SVGs ist das stets die SVG-Version (Bsp. File:Doubleslitexperiment.svg). Man sollte nicht die große Mehrheit benachteiligen, um auf eine Handvoll (oder weniger) Rücksicht zu nehmen, die noch mit einem Amiga surfen, imho. --Rainald62 (Diskussion) 15:53, 3. Jul. 2017 (CEST)
    
    

Suche im Volltext bei Mobile Leser

Was ist das Problem?

Länge und Gliederung unserer Artikel sind nicht an kleine Bildschirme angepasst. Deshalb macht schon das Lesen Probleme. Die Anzeige der Kapitelüberschriften lässt oft nicht erkennen, ob und wenn ja in welchem Kapitel eine gesuchte Information enthalten ist.

Wen betrifft das Problem besonders?

Mobile Leser

Lösungsvorschlag

Volltextsuche im Artikel, auch in den eingeklappten Kapiteln

Anmerkungen

Suche im Text gibt es zumindest in der Android-App und der iOS-App, aber nicht in der nativen mobile-Web-Version.

Vorschlagende Person

h-stt !? 21:57, 1. Jun. 2017 (CEST)

Diskussion

Unterstützung

 Info: Wohl identisch mit Wikipedia:Umfragen/Technische Wünsche 2017/Suchen#Suche von Wörtern in einem Artikel auf der mobilen Seite Falls nicht: bitte Unterschied darstellen und diesen Hinweis entfernen. -- Reise Reise (Diskussion) 10:18, 1. Jul. 2017 (CEST)

1.  Pro H-stt (Einreichende Person)
2.  Pro Rewo (Diskussion) 11:09, 19. Jun. 2017 (CEST)
3.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe 16:55, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 23:02, 20. Jun. 2017 (CEST)
5.  Pro --MGChecker – (📞| 📝| ) 20:03, 21. Jun. 2017 (CEST)
6.  Pro --Pfeffermakrele (Diskussion) 22:55, 24. Jun. 2017 (CEST)
7.  Pro --Mushushu (Diskussion) 16:10, 25. Jun. 2017 (CEST)
8.  Pro --DomenikaBo (Diskussion) 21:31, 25. Jun. 2017 (CEST)
9.  Pro --Sophiston (Diskussion) 23:56, 26. Jun. 2017 (CEST)
10.  Pro --Neptuul (Diskussion) 10:49, 29. Jun. 2017 (CEST)
11.  Pro --Sebastian Wallroth (Diskussion) 21:14, 29. Jun. 2017 (CEST)
12.  Pro --X:: black ::X (Diskussion) 01:52, 1. Jul. 2017 (CEST)
13.  Pro --Mr N (Diskussion) 20:01, 2. Jul. 2017 (CEST)
    
    

Klassische Tabs als Menu im Mobile Skin

Was ist das Problem?

Zugriff auf Informationen außerhalb des reinen Artikeltexts in der Standardanzeige. Es fehlen einfache Menu-Zugriffe auf Diskussion und History und anderes. Leser, die die Möglichkeiten des Desktop-Skins kennen, vermissen den Zugriff auf viele Inhalte im nativen mobile Skin (in den Apps gibt es manches, aber im mobile Browser eben nicht). Diskseite und Versionsgeschichte sind nicht oder nur umständlich zugänglich.

Wen betrifft das Problem besonders?

Power-Leser auf mobilen Geräten.

Lösungsvorschlag

Änderung der Menu-Struktur im mobile Skin. "Start, Zufall und In der Nähe" sind ganz sicher nicht die wichtigsten Optionen, die man in der Menustruktur suchen würde. Auch das "Beobachtungslisten"-Sternchen ist völlig sinnlos bei nicht angemeldeten Benutzern. Da muss die Disk rein und die History sollte auch nach oben ins Menu.

Vorschlagende Person

h-stt !? 21:58, 1. Jun. 2017 (CEST)

Diskussion

@H-stt: Danke für den Wunsch! Es wäre super, wenn du das Problem schon kurz im Titel benennen könntest, damit die Abstimmenden gleich wissen, worum es geht. Könntest du vielleicht in der Problembeschreibung auch noch genauer erläutern, wann genau welche Probleme auftreten? Also zum Beispiel (hypothetisch): "Wenn ich in der mobilen Version einen Artikel lese, und dort etwas ändern möchte, gehe ich zuerst auf die Diskussionsseite, um zu sehen, ob darüber schon gesprochen wurde. Leider muss ich dafür den Umweg x, y, z verwenden, weil es keinen direkten Link vom Artikel gibt". Das wäre super! Viele Grüße, Lea Voget (WMDE) (Diskussion) 14:21, 2. Jun. 2017 (CEST)

Unterstützung

1.  Pro H-stt (Einreichende Person)
2.  Pro Rewo (Diskussion) 11:10, 19. Jun. 2017 (CEST)
3.  Pro --  Sir Gawain Disk. 17:55, 20. Jun. 2017 (CEST)
4.  Pro --Thomas Obermair 4 (Diskussion) 23:03, 20. Jun. 2017 (CEST)
5.  Pro -- Freddy2001 ^DISK 11:36, 24. Jun. 2017 (CEST)
6.  Pro --Rainald62 (Diskussion) 15:50, 24. Jun. 2017 (CEST)
7.  Pro --DomenikaBo (Diskussion) 21:32, 25. Jun. 2017 (CEST)
8.  Pro --Sebastian Wallroth (Diskussion) 21:15, 29. Jun. 2017 (CEST)
9.  Kontra Die Einträge „Zufall und In der Nähe“ finde ich z.B. wichtiger als „History“. Das aktuelle Menü finde ich sinnvoll. --Snurb3010 (Diskussion) 23:23, 29. Jun. 2017 (CEST)
10.  Pro --X:: black ::X (Diskussion) 00:21, 1. Jul. 2017 (CEST)
11.  Pro --Whisker (Diskussion) 21:16, 1. Jul. 2017 (CEST)
12.  Pro --Devotus (Diskussion) 15:24, 2. Jul. 2017 (CEST)
13.  Pro --Mr N (Diskussion) 20:13, 2. Jul. 2017 (CEST) Der Link zur Diskussionsseite (und gern auch die die restlichen Einträge) sollte wirklich ins Menü.
    
    

Bestimmung der Autoren eines Artikels (→ WikiHistory)

Was ist das Problem?

Der erfahrende Wikipedianer möchte auf einen Blick erkennen, wer der Hauptautor eines Artikels ist. Damit man bei Problemen jemanden gezielt ansprechen kann.

Wen betrifft das Problem besonders?

Erfahrende Wikipedianer

Lösungsvorschlag

Das Tool Benutzer:APPER/WikiHistory überarbeiten und als allgemeine Funktionalität in die Wikimedia-Software integrieren. Leider ist das Tool seit einem Jahr nicht mehr funktionsfähig. Es geht um die grobe Einschätzung, wer die Handvoll Hauptautoren an diesem Artikel sind. Eine Byte-genaue Auswertung kann nicht (auf den einfachen Weg) erreicht werden und will es gar nicht.

Anmerkungen

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch (sowie dem verwandten Wunsch „Autorenangaben unter den Artikeln“) werden künftig hier dokumentiert.

Vorschlagende Person

Atamari (Diskussion) 02:02, 5. Jun. 2017 (CEST)

Diskussion

@Atamari: Bei mir funktioniert das Script einwandfrei. Ich habe allerdings anders als in der Beschreibung von Apper folgendes in der common.js stehen:

importScript('Benutzer:APPER/WikiHistory.js');

Nichtsdestotrotz befürworte ich deinen Vorschlag, das Script in die Wikimedia-Software zu übernehmen. --Das Robert .... gibs mir! 15:22, 6. Jun. 2017 (CEST)

@Das Robert: ja, das steht bei mir auch so drinnen. Aber die Anzeige wird seit einem Jahr ungefähr nicht mehr aktualisiert. Das siehtst du bei kürzlich angelegten Artikel, da erscheint die Anzeige „von ..“ unendlich. (Kannst auch diese Disk verfolgen. --Atamari (Diskussion) 15:32, 6. Jun. 2017 (CEST)

@Atamari: Wir hatten diesen Wunsch auch beim Berliner Tech-on-Tour-Termin besprochen und es kam raus, das XTools im Grunde die Aufgaben von WikiHistory erfüllt und weiterhin aktualisiert wird wie in diesem Artikel von Barnos beschrieben. --Charlie Kritschmar (WMDE) (Diskussion) 18:20, 6. Jun. 2017 (CEST)

Danke für Deinen Sachstandshinweis, Charlie; in Kopie ergänze dazu ich meine weiterführenden Vorschläge aus der Kurierdiskussion:

Unter den Seiteninformationen haben wir bei den Tools, wie ich jetzt erst bemerkt habe, nun bei Nr. 1 (Statistik) und Nr. 3 (Hauptautoren) ein nahezu identisches Informationsangebot, das sinnvollerweise an erster Stelle zusammengeführt werden sollte zu „Statistik und Hauptautoren“. Dann würden dort nur mehr drei Werkzeuge verbleiben, darunter an Nr. 2 die „Abrufstatistik“. Dieses wichtige Tool ist auch gesondert und direkt erreichbar ganz unten auf jeder Projektseite zu finden. Das als Arbeits- und Kommunikationsmittel ebenso wichtige Info-Tool zu den Autorenleistungen könnte und sollte unschwer daneben platziert werden können, vielleicht mit der Verlinkungsbezeichnung „Autoren“ oder eben „Hauptautoren“. Denkbar auch, den Informationsumfang des Tools in diesem Sinne noch zu straffen bzw. zuzuspitzen. Mit Grüßen in die Runde -- Barnos (Post) 08:00, 7. Jun. 2017 (CEST) / 09:31, 7. Jun. 2017 (CEST)

Wäre vllt als Helferlein sinnvoll? Da bräuchte man zumindest nicht mehr in der common.js rumwühlen. Viele Grüße --FNDE 00:00, 7. Jun. 2017 (CEST)

Atamaris Vorschlag betrifft nicht nur erfahrene Nutzer, sondern alle, die sich über Autoren von Artikeln informieren müssen. Deshalb wäre eine Integration als Standardwerkzeug der beste Weg. (Habt Ihr mal bitte einen Link zur Funktion bei xtools?) Viele Grüße --Thomas Wozniak (HSP) (Diskussion) 13:02, 7. Jun. 2017 (CEST)

Über Lösungsansätze diskutieren wir zwar noch nicht, ich sehe aber ganz deutlich das Problem gegeben, dass man die Hauptautorenschaft nicht einwandfrei ermitteln kann. Es gibt dazu ja verschiedene Ansätze, bei einer Integration als Hauptfunktion müsste sich aber die Community in irgendeiner Art dazu positionieren, auf welcher Grundlage dies berechnet wird. Beste Grüße --FNDE 13:58, 7. Jun. 2017 (CEST)

Es gibt zum WikiHistory wohl ein Tool [2], das auch scheinbar aktuell ist. Die Einbindung der Information auf die Artikelseite ist unterbrochen. Man kann dieses Tool als Basis nehmen, überarbeiten und als allgemeine Funktionalität in die Wikimedia-Software integrieren. --Atamari (Diskussion) 14:08, 7. Jun. 2017 (CEST)

Das ist eine Altausgabe, Atamari, und nicht der letzte Stand, wie ich auch nochmals geprüft habe, indem ich nach dem Gleichheitszeichen Robert_Musil eingegeben und dann gesehen habe, dass ich zwar als letzter Editor geführt werde, aber ohne nennenswerte Anteile. Einen längst überholten Stand zu vermelden, ist aber bald noch ungünstiger als gar keinen. Nur wird das Orientierungsmittel doch fraglos gebraucht... -- Barnos (Post) 17:09, 7. Jun. 2017 (CEST)

Hallo Atamari, lösen die XTools deinen Wunsch, und wenn nicht, könntest du erläutern was die XTools noch bräuchten, damit sie deinem Wunsch entsprechen würden und deinen Wunsch dahingehend umformulieren? Im Moment scheint der Wunsch eine Doppelung des Autorenlisten-Wunsches von 2013 zu sein, bei dem die Integration jedoch abgelehnt wurde. So wie der Wunsch jetzt steht würde ich ihn sonst morgen Abend nach Wünsche außerhalb des Projektrahmens verschieben. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 18:15, 15. Jun. 2017 (CEST)

Erstens: ich kenne XTools nicht und es wird nach meinen Erinnerungen auch nicht auf der Seite Helferlein angeboten. Zweitens beruht die "Ablehung" auf eine Fehleinschätzung, keiner der dieses Tool nutzt besteht bei einem 100kB-Text auf eine Zeichengenaue Auswertung der Autorenschaft. Da wurde wohl das Tool nicht richtig verstanden. So ein Tool/Script soll lediglich die Hauptautoren in der Mitarbeit des Artikels nennen. Drittens: es ist Ziel - darauf hat user:Raymond explizit wiederholt darauf hingewiesen - Ideen aus Tools und Scripte, die sich bewährt haben auch fest in die Mediawiki-Software zu integrieren. Damit wir nicht den Auswahl beklagen müssen wie hier im Beispiel wikihistory. Ein ständiges Wechsel von einem ausgefallenen Script zum nächsten möchte ich nicht weiter mitmachen. Viertens: kann ich Barnos Post (oben) auch verstehen, dass er ebenso wie ich auch die Funktionalität in die Software integriert haben möchte. --Atamari (Diskussion) 19:03, 15. Jun. 2017 (CEST)

Xtools, Atamari, ist jedenfalls besser als gar nichts halbwegs Aktuelles, sollte aber bedarfsgerecht optimiert werden (im Abschnitt ganz unten) und die unterdessen ja hoffentlich deutliche Kernproblematik nicht unter „ferner liefen“ abgetan werden. -- Barnos (Post) 21:07, 15. Jun. 2017 (CEST)

Hallo Atamari, ich würde vorschlagen die hilfreichen Erläuterungen und Hinweise aus der Diskussion in den Abschnitt "Anmerkungen" oder "Lösungsvorschlag" zu übertragen, da bei der Abstimmung die Diskussion eingeklappt wird, damit klar ist, worüber abgestimmt wird. Viele Grüße, --Charlie Kritschmar (WMDE) (Diskussion) 14:07, 17. Jun. 2017 (CEST)

Welche hilfreichen Erläuterungen?

@Atamari:Ich verwende das Skript Benutzer:Schnark/js/artikel-statistik, das zeigt einem auch die Hauptautoren an und darunter farbig markiert, was von wem stammt.  — Johannes Kalliauer - Diskussion | Beiträge 20:13, 21. Jun. 2017 (CEST)

Die Hauptautoren eines Artikels kann von MediaWiki bei entsprechender Konfiguration am Ende der Seite anzeigen. Es existiert also schon eine solche Funktion in der Software. -- Freddy2001 ^DISK 11:39, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Atamari (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:17, 19. Jun. 2017 (CEST)
3.  Pro DCB (Diskussion • Bewertung) 22:01, 19. Jun. 2017 (CEST)
4.  Pro --FNDE 00:57, 20. Jun. 2017 (CEST)
5.  Pro -- Barnos (Post) 07:58, 20. Jun. 2017 (CEST) In den Kernfunktionen unverzichtbar für die Zukunft des enzyklopädischen Projekts, auch im Sinne einer Anerkennungskultur für erbrachte Leistungen!
6.  Pro --Thomas Wozniak (HSP) (Diskussion) 15:12, 20. Jun. 2017 (CEST)
7.  Pro --HerrAdams (D) 15:13, 20. Jun. 2017 (CEST)
8.  Pro Zellmer (Diskussion) 15:14, 20. Jun. 2017 (CEST)
9.  Pro--grim (Diskussion) 15:59, 20. Jun. 2017 (CEST)
10.  Pro --Blik (Diskussion) 16:23, 20. Jun. 2017 (CEST)
11.  Pro --Abubiju (Diskussion) 16:51, 20. Jun. 2017 (CEST)
12.  Pro --  Sir Gawain Disk. 17:55, 20. Jun. 2017 (CEST)
13.  Pro --Nuhaa (Diskussion) 18:00, 20. Jun. 2017 (CEST)
14.  Pro --Frank Schulenburg (Diskussion) 18:35, 20. Jun. 2017 (CEST)
15.  Pro --Holder (Diskussion) 19:59, 20. Jun. 2017 (CEST)
16.  Pro -- - Majo Senf - ^{Mitteilungen an mich} 20:23, 20. Jun. 2017 (CEST)
17.  Pro --R.ganaus (Diskussion) 21:46, 20. Jun. 2017 (CEST)
18.  Pro --Orci Disk 22:01, 20. Jun. 2017 (CEST)
19.  Pro --Wikifreund (Diskussion) 22:56, 20. Jun. 2017 (CEST)
20.  Pro --Thomas Obermair 4 (Diskussion) 23:03, 20. Jun. 2017 (CEST)
21.  Pro --SkiFreak99 (Diskussion) 00:24, 21. Jun. 2017 (CEST)
22.  Pro Verbunden mit Wikipedia:Umfragen/Technische_Wünsche_2017/Lesen#Autorenangaben unter den Artikeln macht dies sehr viel Sinn. Also auch unter den Artikeln in Reihenfolge die (Haupt)Autoren, mit einer Zahl zur Einschätzung (evt. in Prozent, da leichter zu lesen, als Einheit in Tausenden von Zeichen) zu nennen. --rugk (Diskussion) 00:44, 21. Jun. 2017 (CEST)
23.  Pro --jcornelius  11:37, 21. Jun. 2017 (CEST)
24.  Pro --Carolus requiescat (Diskussion) 17:11, 21. Jun. 2017 (CEST)
25.  Pro --S. F. B. Morse^{ditditdadaditdit} 18:50, 21. Jun. 2017 (CEST)
26.  Pro --Louis ♫ Bafrance ☼ Schwätz halt mit m'r, wenn da ebbes saga witt 19:46, 21. Jun. 2017 (CEST)
27.  Pro --MGChecker – (📞| 📝| ) 19:55, 21. Jun. 2017 (CEST)
28.  Pro --Pelz (Diskussion) 22:24, 21. Jun. 2017 (CEST)
29.  Pro --Chrisandres (Diskussion) 22:47, 21. Jun. 2017 (CEST)
30.  Pro --Jossi (Diskussion) 12:24, 22. Jun. 2017 (CEST)
31.  Pro --HHill (Diskussion) 12:26, 22. Jun. 2017 (CEST)
32.  Pro --GodeNehler (Diskussion) 19:30, 22. Jun. 2017 (CEST)
33.  Pro --Daniel749 Disk. (ST–WPST) 21:07, 23. Jun. 2017 (CEST)
34.  Pro --Nichtich (Diskussion) 22:11, 23. Jun. 2017 (CEST)
35.  Pro --Frīheidasliova (FRĀGĀ) 08:49, 24. Jun. 2017 (CEST)
36.  Pro -- Freddy2001 ^DISK 11:37, 24. Jun. 2017 (CEST)
37.  Pro --Alva2004 (Diskussion) 13:56, 24. Jun. 2017 (CEST)
38.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
39.  Pro --DomenikaBo (Diskussion) 21:33, 25. Jun. 2017 (CEST)
40.  Pro --Menschpædia (Diskussion) 23:35, 25. Jun. 2017 (CEST)
41.  Pro --Chiborg (Diskussion) 18:22, 28. Jun. 2017 (CEST)
42.  Pro --Ak ccm (Diskussion) 00:21, 29. Jun. 2017 (CEST)
43.  Pro --Orgelputzer (Diskussion) 13:35, 29. Jun. 2017 (CEST)
44.  Pro --Stobaios 19:19, 29. Jun. 2017 (CEST)
45.  Pro --Sebastian Wallroth (Diskussion) 21:16, 29. Jun. 2017 (CEST)
46.  Pro —DerHexer (Disk., Bew.) 21:20, 29. Jun. 2017 (CEST)
47.  Kontra -gpf- (Diskussion) 09:23, 30. Jun. 2017 (CEST)
48.  Pro --Eisbaer44 (Diskussion) 11:34, 30. Jun. 2017 (CEST)
49.  Pro -- Hans50 (Diskussion) 12:44, 30. Jun. 2017 (CEST)
50.  Pro --Anima (Diskussion) 14:16, 30. Jun. 2017 (CEST)
51.  Pro -- Shoeper 18:25, 30. Jun. 2017 (CEST)
52.  Pro --Fixuture (Diskussion) 17:59, 1. Jul. 2017 (CEST)
53.  Pro --Whisker (Diskussion) 21:17, 1. Jul. 2017 (CEST)
54.  Pro -- Platte ^{∪∩∨∃∪} 22:28, 1. Jul. 2017 (CEST)
55.  Pro --Mabschaaf 22:40, 1. Jul. 2017 (CEST)
56.  Pro --Hnsjrgnweis (Diskussion) 14:21, 2. Jul. 2017 (CEST)
57.  Pro --Devotus (Diskussion) 15:10, 2. Jul. 2017 (CEST)
58.  Pro --Andrea014 (Diskussion) 15:17, 2. Jul. 2017 (CEST)
59.  Pro -- Carbidfischer Kaffee? 15:22, 2. Jul. 2017 (CEST)
60.  Pro -- Alinea (Diskussion) 15:46, 2. Jul. 2017 (CEST)
61.  Pro -- Wichtig bei diesem Tool ist aber, dass es nicht, wie es heute schon xtools macht, nur den hinzugefügten Text misst, sondern wie früher Wikihistory auch prüft, wieviel von dem hinzugefügten Text noch in dem Artikel steht, sonst führt das zu Verzerrungen.--PaFra (Diskussion) 16:54, 2. Jul. 2017 (CEST)
62.  Pro --Anselm Rapp (Diskussion) 17:48, 2. Jul. 2017 (CEST)
63.  Pro --PAB (Diskussion) 20:14, 2. Jul. 2017 (CEST)
64.  Pro -- Nwabueze 23:03, 2. Jul. 2017 (CEST)
    
    

WP-App: Suche in eingeklappten Tabellen

Was ist das Problem?

In der Wikipedia-App sind Tabellen immer eingeklappt. Wenn man die App-eigene Suche nutzt, werden Einträge in den eingeklappten Tabellen nicht gefunden. Erst wenn die Tabelle ausgeklappt ist, werde Tabelleneinträge gefunden

Wen betrifft das Problem besonders?

Nutzer der WP-App, die in Artikel suchen

Lösungsvorschlag

Die Suche auf den Inhalt der Tabellen erweitern.

Vorschlagende Person

 ^Thomas 08:14, 6. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro --Atamari (Diskussion) 12:34, 19. Jun. 2017 (CEST) ein Grund mehr, dieses Spielerei mit den Adventskalendern in Artikeln zu unterbinden
3.  Pro DCB (Diskussion • Bewertung) 22:02, 19. Jun. 2017 (CEST)
4.  Pro --Gnom (Diskussion) 16:34, 20. Jun. 2017 (CEST)
5.  Pro Zabia (Diskussion) 16:54, 20. Jun. 2017 (CEST)
6.  Pro --TheTokl -> Diskussion • E-Mail • Hilfe 16:55, 20. Jun. 2017 (CEST)
7.  Pro --Thomas Obermair 4 (Diskussion) 23:04, 20. Jun. 2017 (CEST)
8.  Pro --Christian (Diskussion) 19:38, 24. Jun. 2017 (CEST)
9.  Pro --Mushushu (Diskussion) 16:10, 25. Jun. 2017 (CEST)
10.  Pro --DomenikaBo (Diskussion) 21:34, 25. Jun. 2017 (CEST)
11.  Pro --Sophiston (Diskussion) 23:57, 26. Jun. 2017 (CEST)
12.  Pro --Merlin2001 (Diskussion) 00:21, 28. Jun. 2017 (CEST) Die Suche scheint generell nicht sehr zuverlässig zu sein :/
13.  Pro --Ailura (Diskussion) 12:00, 29. Jun. 2017 (CEST)
14.  Pro --Sebastian Wallroth (Diskussion) 21:17, 29. Jun. 2017 (CEST)
15.  Pro —DerHexer (Disk., Bew.) 21:20, 29. Jun. 2017 (CEST)
16.  Pro --Thomas Wozniak (HSP) (Diskussion) 14:19, 30. Jun. 2017 (CEST)
17.  Pro --Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST)
18.  Pro --X:: black ::X (Diskussion) 01:37, 1. Jul. 2017 (CEST)
    
    

WP:App: Bei Anker-Nutzung im Artikel bleiben.

Was ist das Problem?

Wenn man in der WP:App auf einen Anker zum Beispiel bei Buchstaben-Navis klickt, wird nicht zum Anker gesprungen, sondern es öffnet sich das Vorschaufenster für den selben Artikel.

Wen betrifft das Problem besonders?

Nutzer der WP-App

Lösungsvorschlag

Beim Anklicken eines Ankers soll innerhalb des Artikels gesprungen werden.

Vorschlagende Person

 ^Thomas 08:16, 6. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Z thomas (Einreichende Person)
2.  Pro DCB (Diskussion • Bewertung) 22:03, 19. Jun. 2017 (CEST)
3.  Pro Conny 14:54, 20. Jun. 2017 (CEST).
4.  Pro --Thomas Obermair 4 (Diskussion) 23:04, 20. Jun. 2017 (CEST)
5.  Pro --Merlin2001 (Diskussion) 00:22, 28. Jun. 2017 (CEST)
6.  Pro --Sebastian Wallroth (Diskussion) 21:18, 29. Jun. 2017 (CEST)
7.  Pro --Mr N (Diskussion) 19:43, 2. Jul. 2017 (CEST)
   
   

Handhabbarkeit von Spezial:Linkliste verbessern (kleine Statistik)

Was ist das Problem?

Die Spezialseite Spezial:Linkliste listet alle internen Links auf eine bestimmte Seite auf. Dort fehlen wichtige Infos, z.B. eine Zahlenausgabe wie "107 Verlinkungen im Artikelnamensraum". Diese Infos sind vor allem wichtig, wenn das Ergebnis über mehrere Seiten geht.

Beispiel von Sitacuisses: „Bahnhof“ – Links auf diese Seite. Man wird hier als Benutzer völlig im Unklaren darüber gelassen, wie viele Ergebnisseiten und wie viele Tausend Treffer es gibt und wie lange es folglich dauert, diese zu überprüfen, etwa im Umfeld einer Verschiebung. Die Sortierung ist nicht nachvollziehbar und man sieht keine Möglichkeit, über mehrere Ergebnisseiten hinwegzublättern.

Wen betrifft das Problem besonders?

Lösungsvorschlag

• Beim Benutzen der Funktion Spezial:Linkliste (Beispiel: [3]) könnte am Anfang eine kleine Statistik über Anzahl der Seiten eingeblendet werden. Am Besten aufgeschlüsselt nach Namensrasum.
• Sinnvoll wäre es auch, die Linkliste nach eigenen Kriterien sortieren zu können, insbesondere nach Alphabet. -- Sitacuisses
• Neben der Angabe der Trefferzahl wäre bei längeren Trefferlisten dann auch eine Direktnavigation zu bestimmten Seiten der Liste wünschenswert. -- Sitacuisses
  Anmerkungen

Bei Wikidata gibt es ein Helferlein ("Links count: Counts total number of pages linked to a specific page on Special:WhatLinksHere (and transclusion, for templates)"). Ist es aktiviert, erhält man über den Link "count" dann beispielsweise als Ergebnis: "(transclusions: 1, links: 437)". So etwa habe ich mir das vorgestellt.

Vorschlagende Person

Atamari (Diskussion) 12:38, 6. Jun. 2017 (CEST)

Diskussion

@Atamari: Mir ist das Problem noch nicht ganz klar. Könntest du unter „Was ist das Problem?“ noch ein bisschen beschreiben, wie/wozu du Spezial:Linkliste nutzt und welche Infos dir konkret fehlen? -- Danke und beste Grüße, Johanna Strodt (WMDE) (Diskussion) 13:56, 8. Jun. 2017 (CEST)

Welche Infos fehlen? Ja, eine Zahlenausgabe wie zum Beispiel 107 Verlinkungen im Artikelnamensraum. --Atamari (Diskussion) 13:58, 8. Jun. 2017 (CEST)

Vielleicht wird es bei einem Beispiel mit mehr Treffern offensichtlicher: „Bahnhof“ – Links auf diese Seite. Man wird hier als Benutzer völlig im Unklaren darüber gelassen, wie viele Ergebnisseiten und wie viele Tausend Treffer es gibt und wie lange es folglich dauert, diese zu überprüfen, etwa im Umfeld einer Verschiebung. Sinnvoll wäre es auch, die Linkliste nach eigenen Kriterien sortieren zu können, insbesondere nach Alphabet. Neben der Angabe der Trefferzahl wäre bei längeren Trefferlisten dann auch eine Direktnavigation zu bestimmten Seiten der Liste wünschenswert. Soll das in einen eigenen Vorschlag verlagert werden?.

Wie die Liste genutzt wird? Z. B. herausfinden, wie oft ein Artikel aus dem ANR verlinkt ist um im Rahmen von Wikipedia:Begriffsklärung zu klären, welches der geläufigste Artikel ist; herausfinden, ob es Links auf eine falsche gleichnamige Person gibt oder ob alle Filmartikel, aus denen ein Schauspieler verlinkt ist, in seiner Filmografie eingetragen und verlinkt sind. --Sitacuisses (Diskussion) 15:27, 8. Jun. 2017 (CEST)

Ich habe nichts dagegen, wenn die Idee umformuliert bzw. ergänzt wird.

Die Ausgabe ist standardgemäß auf 50 Elemente beschränkt. Danach muss man Blättern. Bei dem Lemma Wuppertal sind es schon mehr als 5000 Verlinkungen, da hat man mit Zählen - sei es nur um die Größenordnung von 150, 1500 oder 6000 heraus zu bekommen einen mühsamen Weg. --Atamari (Diskussion) 15:30, 8. Jun. 2017 (CEST)

p.s. das Gadget in Wikidata funktioniert wohl doch (man muss nur den Link "count" sehen). Als Ergebnis erhält man beispielsweise: (transclusions: 1, links: 437). So etwa habe ich mir das vorgestellt. --Atamari (Diskussion) 16:12, 8. Jun. 2017 (CEST)

@Atamari, Sitacuisses: „Ich habe nichts dagegen, wenn die Idee umformuliert bzw. ergänzt wird.“ - Okay, ich habe den Wunsch um die Angaben aus der Diskussion ergänzt und auch den Wunschtitel stärker als Problem formuliert. Ist es so für euch richtig? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 12:50, 9. Jun. 2017 (CEST)

Ganz nebenbei erschwert auch noch ein Bug das Blättern in der Spezialseite. Über den Link „nächste 50“ (bzw. 20/100/25/500) kommt man zwar mit jedem Klick einen Schritt weiter vorwärts, über den Link „vorherige 50“ (bzw. 20/100/25/500) aber nur einen Schritt zurück, bei weiteren Klicks auf diesen Link landet man immer auf derselben Seite. --X:: black ::X (Diskussion) 16:08, 30. Jun. 2017 (CEST), aktualisiert 16:13, 30. Jun. 2017 (CEST)

Unterstützung

1.  Pro Atamari (Einreichende Person)
2.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 13:24, 19. Jun. 2017 (CEST)
3.  Pro --FNDE 00:58, 20. Jun. 2017 (CEST)
4.  Pro Conny 14:55, 20. Jun. 2017 (CEST).
5.  Pro --Andropov (Diskussion) 16:05, 20. Jun. 2017 (CEST) sehr gute Idee.
6.  Pro --Gnom (Diskussion) 16:40, 20. Jun. 2017 (CEST)
7.  Pro --  Sir Gawain Disk. 17:56, 20. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 23:05, 20. Jun. 2017 (CEST)
9.  Pro --MGChecker – (📞| 📝| ) 19:51, 21. Jun. 2017 (CEST)
10.  Pro --Daniel749 Disk. (ST–WPST) 21:08, 23. Jun. 2017 (CEST)
11.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
12.  Pro --Gr1 (Diskussion) 16:27, 28. Jun. 2017 (CEST)
13.  Pro --Sebastian Wallroth (Diskussion) 21:19, 29. Jun. 2017 (CEST)
14.  Pro -gpf- (Diskussion) 09:24, 30. Jun. 2017 (CEST)
15.  Pro -- X:: black ::X (Diskussion) 16:08, 30. Jun. 2017 (CEST)
16.  Pro --MatthiasDD (Diskussion) 19:32, 1. Jul. 2017 (CEST)
17.  Pro --Sitacuisses (Diskussion) 12:47, 2. Jul. 2017 (CEST)
    
    

Differenzierte Darstellung von Name und Qualifikator bei Klammerlemmata

Was ist das Problem?

Bei mehrdeutigen Lemmabegriffen wird in Wikipedia ein Klammerzusatz als Qualifikator verwendet. Es gibt jedoch auch Fälle, in denen bereits zum eigentlichen Namen ein solcher Klammerzusatz gehört. Als Beispiele seien Begriffsklärungsseiten wie Feldberg genannt. Da stehen mehr als zehn Artikel der Form „Feldberg (Klammerzusatz)“ in der Liste. Dabei fällt nicht auf, dass Feldberg (Schwarzwald) ein offizieller Gemeindename ist. Ebenso in Halle: Halle (Saale) und Halle (Westf.) sind offizielle Namen, stehen jedoch ohne Unterscheidung zwischen identisch aufgebauten Bezeichnungen wie Halle (Belgien), deren Klammerzusatz nur eine interne Bedeutung hat.

Es besteht einerseits die Gefahr, dass bloß interne Klammerzusätze für offiziell gehalten werden, andererseits werden offizielle Namen nicht als solche erkannt. Indem wir es unnötig schwierig machen den eigentlichen Namen zu erkennen, tragen wir ungewollt zur Verbreitung falscher Varianten bei. Mit der über die Jahre enorm gewachsenen Bedeutung der Wikipedia hat dieses kleine Problem an Brisanz zugenommen.

Wen betrifft das Problem besonders?

Alle Leser, insbesondere diejenigen, die nicht über unseren internen Umgang mit Homonymen Bescheid wissen. Es sind alle Klammerlemmata betroffen, die theoretisch einen Klammerzusatz bereits als Namensbestandteil haben könnten, etwa auch Werktitel.

Lösungsvorschlag

Eine differenzierte Darstellung von Name und Qualifikator. Sowohl in der Hauptüberschrift der Artikel als auch auf Begriffsklärungsseiten und in automatisch erzeugten Seiten wie Suchergebnissen, Kategorie- und Linklisten sollten eigentliche Namensbestandteile und interne Qualifikatoren auf Anhieb unterscheidbar sein. Dies könnte durch einen leicht unterschiedlichen Schriftstil geschehen. Beispiel dafür gibt es viele. So sieht unser undifferenziertes Ca$h (2010) in der IMDb so aus; beachte den Haupttitel. In den Auflistungen der Begriffsklärungen würden Zusätze automatisch durch den Schriftstil gekennzeichnet, ohne dass der Benutzer mit CSS hantieren muss. Das folgende Beispiel soll daher nur ein mögliches Aussehen vorführen, nicht jedoch den genauen Quelltext. Der sollte bereits bei unmaskierter Schreibweise automatisch ein ähnliches Schriftbild erzeugen:

• Halle (Architektur), großer Raum oder Gebäude mit einem großen Raum
• Halle (Saale), kreisfreie Großstadt in Sachsen-Anhalt
• Halle (Belgien), Stadt in der Provinz Flämisch-Brabant, Belgien

Voraussetzung ist, dass die technische Möglichkeit geschaffen wird, diese Differenzierung innerhalb des Lemmas einzugeben und fest mit dem Lemma zu verbinden. Vom Arbeitsaufwand für die Benutzer her gesehen könnte es sinnvoll sein, die Differenzierung ab öffnender Klammer im Lemma als softwareseitige Default-Einstellung (auch bei Rotlinks) einzuführen und nur bei den wenigen Ausnahmen, wo die Klammer Namensbestandteil ist, einen Marker zu setzen, der die Differenzierung verhindert.

Vorschlagende Person

Sitacuisses (Diskussion) 05:21, 8. Jun. 2017 (CEST)

Diskussion

Unterstützung

1.  Pro Sitacuisses (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST)
3.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 22:03, 19. Jun. 2017 (CEST)
5.  Pro --HerrAdams (D) 15:15, 20. Jun. 2017 (CEST)
6.  Pro Kontrollstelle Kundl 18:26, 20. Jun. 2017 (CEST)
7.  Pro --Till.niermann (Diskussion) 20:45, 20. Jun. 2017 (CEST)
8.  Pro --Thomas Obermair 4 (Diskussion) 23:05, 20. Jun. 2017 (CEST)
9.  Pro --Wikifreund (Diskussion) 23:16, 20. Jun. 2017 (CEST)
10.  Pro Michi 19:13, 21. Jun. 2017 (CEST)
11.  Pro --Jossi (Diskussion) 12:28, 22. Jun. 2017 (CEST)
12.  Pro --Dominic Z. (Diskussion) 18:17, 22. Jun. 2017 (CEST)
13.  Pro --Karl432 (Diskussion) 20:36, 23. Jun. 2017 (CEST)
14.  Pro --Daniel749 Disk. (ST–WPST) 21:10, 23. Jun. 2017 (CEST)
15.  Pro --Mushushu (Diskussion) 16:10, 25. Jun. 2017 (CEST)
16.  Pro --DomenikaBo (Diskussion) 21:35, 25. Jun. 2017 (CEST)
17.  Pro --Wrev (Diskussion) 22:32, 25. Jun. 2017 (CEST)
18.  Pro --Menschpædia (Diskussion) 23:36, 25. Jun. 2017 (CEST)
19.  Pro --MikeTheGuru (Diskussion) 01:14, 26. Jun. 2017 (CEST)
20.  Kontra rentiert sich nicht wegen ein paar, wohl an der hand abzählbaren lemmata: das verhältnis interner klammerlemmta zu echten (von draussen) dürfte deutlich unter 1:10000 liegen: da baut man nicht die mehrheit um (und verschwendet enorme rechenleistung), sondern die ‰: das ist schlicht einer der fälle, wo "einfache" zeichen, die für wikisyntax reserviert worden sind, im lemma auftauchen: bei einem lemma mit "|" müsste man auch basteln, genau wie wirs mit einen kleinen anfangsbuchstaben und anderem tun: einfacher wärs da ja, die wenigen echten klammerlemmata etwa mit ❨❩ U+2768/69 oder （ ） U+FF08/09 zu lemmatisieren: Halle (Architektur) -- Halle ❨Saale❩ oder Halle （Saale） -- Halle (Belgien) -- klar anderes schriftbild, displaytititle im artikel mit der ascii-klammer, wenn gewünscht, WL von der form mit ascii-zeichen, und die sache dürfte passen. leider gibts mw. unter unicode keine andere einfache runde klammer, cf. [4]. noch einfacher erlaubt man in der BKS (die es als einziges betrifft) hierbei ausnahmsweise ein "kaschiertes" ziel ala [[Halle (Saale)|Halle '''('''Saale''')''']] -> Halle (Saale), denn im artikeltext steht die klammer ja sowieso offen da (im unterschied zu allen internen klammerungen). jedenfalls hört sich der vorschlag recht nach "warum einfach wenns kompliziert auch geht" an. --W!B: (Diskussion) 18:03, 27. Jun. 2017 (CEST)

    Es soll doch nicht wegen der relativ wenigen differenziert werden, bei denen die Klammer dazugehört, sondern wegen der vielen, wo sie nicht dazugehört, aber so aussieht als ob. Dabei finde ich alleine im Gemeindeverzeichnis für Deutschland über 220 Namen mit Klammerzusatz als offiziellem Bestandteil. Die stehen dafür, dass unsere Leser die Klammer nicht ohne Grund als Namensbestandteil annehmen. Ich wäre froh, wenn zunächst mal ein Problembewusstsein entsteht und eine Bereitschaft, dieses Problem anzugehen. Da du so ein Problembewusstsein auch signalisierst, finde ich das plakative Contra zum Gesamtvorschlag unpassend. Im übrigen sind neben BKL auch Kategorien (Beispiel), Linklisten (Beispiel) und Suchergebnisseiten betroffen, deren Gestaltung nicht nutzerseitig beeinflussbar ist. Deinen Vorschlag mit bloß anderen Klammern finde ich nicht selbsterklärend, zu unauffällig und damit unzureichend. Für den Seitentitel wäre z. B. auch eine kleinere Schrift für den gesamten (inoffiziellen) Klammerzusatz möglich, siehe IMDb-Beispiel. --Sitacuisses (Diskussion) 21:13, 27. Jun. 2017 (CEST)

    soweit ich weiß, sind gemeinden in deutschland der einzige fall überhaupt, in dem klammern öfter im lemma auftauchen, abgesehen von vereinzelten werktiteln ala How It Is (Wap Bap …): und es geht tatsächlich nur um die de-gemeinden, denn bei den anderen besteht kaum verwechslungsgefahr mit internen klammerungsschemata: und eben für diese 220 (was ich angesichts 2 mio artikel, davon sicher deutlich über 10 % geklammert, genau das nenn ich "an der hand abzählbar") rentiert sich der aufwand nicht. der fall ist ja bekannt, ich wollte es aber nicht explizit als wunsch der diskriminierten deutschen heimatkunde darstellen. cf. auch Wikipedia:Umfragen/Technische Wünsche 2017/Bearbeiten #Erweiterung des Funktionsumfangs von SEITENTITEL bzw. DISPLAYTITLE. --W!B: (Diskussion) 08:16, 28. Jun. 2017 (CEST)

    Ich wiederhole mich und würde mich freuen, wenn du es schaffst diesen Schritt nachzuvollziehen: Es geht nicht um die wenigen Fälle, in denen die Klammer offiziell dazugehört, sondern um die vielen anderen, die einen falschen Eindruck vermitteln. In Deutschland haben nach meiner Stichprobe 15 bis 20 % der über 10.000 Gemeindeartikel ein Klammerlemma mit Missverständnispotenzial, in Hessen und Sachsen-Anhalt sind es fast ein Viertel. Deutsche Gemeindenamen sind auch nicht irgendwelche Randlemmata, sondern die Bezeichnungen der Einheiten, in denen die große Mehrheit unserer Leser lebt und mit denen sie täglich zu tun hat. Dein Einwand klingt ein wenig so, als würde ein Sahara-Bewohner die Anschaffung von Regenschirmen in England ablehnen.

    Missverständnispotenzial sehe ich beispielsweise auch bei vielen Filmtiteln, die nur eine Jahreszahl in der Klammer haben. Zu oft erlebe ich, dass Anfänger solche Titel unmaskiert in den Artikeltext schreiben. Wo sonst noch direktes Verwechslungspotenzial besteht und wo nicht wäre zu untersuchen.

    Die Differenzierung dient darüber hinaus jedoch bei allen Klammerlemmata der Klarheit und raschen Erfassbarkeit des Wesentlichen. Es zählt nun mal der erste Eindruck, und für den sorgt die Titelzeile. Das Argument, man könne ja in der Einleitung nachschauen, ist schwach, denn wenn man erst noch einmal nachschauen muss, ist das Kind schon in den Brunnen gefallen. Unsere Darstellung von Klammerlemmata ist in jedem Fall verbesserungsfähig. Es geht dabei auch um die Verfeinerung und optische Modernisierung einer altbacken-zurückgebliebenen Darstellungsform. --Sitacuisses (Diskussion) 14:48, 28. Jun. 2017 (CEST) Mal von einer anderen Seite betrachtet: Kannst du mir andere an die Öffentlichkeit gerichtete Medien nennen, bei denen unsere undifferenzierte Darstellungsform etabliert ist? --Sitacuisses (Diskussion) 15:36, 28. Jun. 2017 (CEST)

    eben. und ich sag, wir haben uns dereinst für das klammern (rund) als qualifikator entschieden, irgendeine syntax mussten wir ja verwenden, und damit ists eine technische einschränkung, wie bei der wikimedia-syntax. zwang des mediums. wenn man jetzt über diese damalige entscheidung unglücklich ist, wäre es sinnvoller, statt einer nachträglichen behübschung schlicht per MB eine andere qualfikatorregelung einzuführen, und einmal im pausch die 100000enden geklammerten artikel zu verschieben, anstatt sie bis ans ende aller zeit milliardenfach mit einem tool immer wieder zu kaschieren. pure performancebremse, oder? vom mir aus könnten wir Halle ｟Architektur｠ oder Halle ｢Architektur｣ machen, oder sogar Halle @Architektur, Halle →Architektur, oder Halle ❤Architektur, Halle ⨁Architektur: ganz unicode steht uns heute offen ;) oder ganz was anderes, ala Halle (Bedeutung in der Architektur) und Halle, Ort in Belgien mit NK ala en:WP. die unselige NK "(Begriffsklärung)" könnten wir dann auch endlich mitsanieren: Halle, mehrere Bedeutungen von ―. all das wäre wesentlich einfacher. --W!B: (Diskussion) 12:41, 29. Jun. 2017 (CEST)

21.  Neutral (Vor Antwort Contra) Das wäre dann wieder Insiderwissen. Beispiel: Halle (Saale) heißt so, Halle [Belgien] heißt Halle. Oder wie auch immer man das Problem löst. Neulinge irritiert das nur. Die BKLs müssen besser formuliert werden. Halle steht für die Stadt Halle in Belgien, siehe Halle (Belgien). Im Artikel sieht man es ja sofort. Außerdem ist das keine technische Frage sondern eine Syntaxfrage, oder? --MannMaus (Diskussion) 20:22, 27. Jun. 2017 (CEST)

    Ich möchte eine graphische Gestaltung, die für sich selbst spricht und kein Insiderwissen erfordert. Darum beinhaltet mein Beispiel eine vom gesamten Text abgesetzte Farbe. Der zurückgenommene Grauton steht für die untergeordnete Bedeutung des nur internen Zusatzes. BKLs anders zu formatieren wäre ein erster Schritt in die richtige Richtung, aber so wie du es vorschlägst ist es aufgrund anderer Anforderungen nicht immer machbar, und eine vorgeschriebene manuell zu erzeugende abgesetzte Formatierung würde viele BKL-Bearbeiter zum Fluchen bringen. Darum mein Vorschlag einer Automatik. Sehe ich das richtig, dass sich auch dein Contra nicht gegen die Problembeschreibung richtet? --Sitacuisses (Diskussion) 21:13, 27. Jun. 2017 (CEST)

    Ich sehe gerade, dein Formatierungsvorschlag überzeugt mich noch am meisten. Ich weiß aber wirklich immer noch nicht, ob ich ihn als Anfänger hier gleich verstehen würde. Ich sehe auch das Problem, weiß aber nicht, wie die "Automatik" technisch funktionieren soll und dann bedient wird. Aber das muss bei mir nichts heißen. Wie willst du das umstellen, die entsprechenden Klammern finden? Kontra in "neutral" geändert. --MannMaus (Diskussion) 21:57, 27. Jun. 2017 (CEST)

    Ich sehe das Problem in den BKLs, in den (Ziel)artikeln stört mich der Ist-Zustand genauso wenig wie der Soll-Zustand, denn wenn der Artikel "Artikel (Zusatz)" anfängt mit "Artikel ist ein" oder "Artikel (Zusatz) ist ein", dann wird der Leser schon wissen, wie der Artikelgegenstand heißt. --MannMaus (Diskussion) 22:22, 27. Jun. 2017 (CEST)

    Bei der technischen Umsetzung muss ich auf das Expertenwissen anderer vertrauen und bin für Vorschläge offen. --Sitacuisses (Diskussion) 23:35, 27. Jun. 2017 (CEST)

22.  Pro --Merlin2001 (Diskussion) 00:25, 28. Jun. 2017 (CEST)
23.  Pro --Sebastian Wallroth (Diskussion) 21:20, 29. Jun. 2017 (CEST)
24.  Kontra Eine Software-seitige Lösung finde ich überflüssig. Eine Markierung wie sie W!B: oben vorschlägt reicht meiner Meinung nach aus. --Snurb3010 (Diskussion) 23:49, 29. Jun. 2017 (CEST)
25.  Pro -- X:: black ::X (Diskussion) 15:47, 30. Jun. 2017 (CEST)
26.  Pro -- Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST)
27.  Pro --ProloSozz (Diskussion) 15:26, 1. Jul. 2017 (CEST) Kommentarnachreichung: mit einer "anderen Art Klammern" wäre das theoretisch einfach möglich, nur ist die Praktikabilität infragegestellt, wenn das weder offensichtlich, noch bekannt ist. Zudem müßten sehr viele Artikel "umetikettiert" werden, damit das als anerkannt gelten kann. Prinzipiell aber sehr sinnvoll. --ProloSozz (Diskussion) 20:05, 1. Jul. 2017 (CEST)
28.  Pro Das Problem mit der von​MannMaus angesprochenen Bkl.-Formatierung ist, dass langfristig öfters entsprechende Formatierungen von anderen Mitautoren wieder in einen undifferenzierten Zustand überführt werden. -- Pemu (Diskussion) 19:06, 1. Jul. 2017 (CEST)
29.  Pro --PAB (Diskussion) 20:17, 2. Jul. 2017 (CEST)
    
    

Sortierschlüssel auch für Spezialseiten

Was ist das Problem?

Mit {{DEFAULTSORT}} kann man eine Standardsortierung für eine Seite angeben, jedoch funktioniert das nur bei Kategorien und nicht bei alphabetisch sortierten Spezialseiten.

Wen betrifft das Problem besonders?

Benutzer bestimmter Spezialseiten

Lösungsvorschlag

Der Sortierschlüssel soll auch für entsprechende Spezialseiten angewendet werden.

Anmerkungen

 

Vorschlagende Person

Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 17:27, 8. Jun. 2017 (CEST)

Diskussion

 

Unterstützung

1.  Pro Morten Haan (Einreichende Person)
2.  Pro --Thomas Obermair 4 (Diskussion) 23:05, 20. Jun. 2017 (CEST)
3.  Pro --Merlin2001 (Diskussion) 00:24, 28. Jun. 2017 (CEST)
4.  Pro klingt machbar -- hgzh 19:17, 29. Jun. 2017 (CEST)
5.  Pro --Sitacuisses (Diskussion) 12:49, 2. Jul. 2017 (CEST)
   
   

Nachtmodus

Was ist das Problem?

Die mobile App bietet bereits einen sehr gut funktionierenden Nachtmodus, dieser könnte doch auch in die Desktop Version übernommen werden. Der weiße Hintergrund ist gerade in der Nacht sehr ermüdend. Bei Desktop PCs kann die Bildschirmhelligkeit oft nicht variiert werden, hier ist es besonders störend.

Wen betrifft das Problem besonders?

Nachtaktive und Vielleser.

Lösungsvorschlag

Den Nachtmodus der mobilen App übernehmen. Dieser könnte sich auch abhängig von der Uhrzeit automatisch selbst aktivieren.

Vorschlagende Person

Chrfwow (Diskussion) 18:27, 2. Jun. 2017 (CEST)

Diskussion

Anmerkung: Für Windows und MacOS (sowie Jailbroken-iOS und Rooted-Android) kann ich unabhängig von MediaWiki nur f.lux empfehlen. — Speravir – 20:10, 2. Jun. 2017 (CEST)

Angemeldete Benutzer können eigene CSS-Files abspeichern. Z.B. kannst du hier das Vector-DarkCSS kopieren, und in deiner globalen CSS-Seite abspeichern: https://meta.wikimedia.org/wiki/User:DEIN_NUTZER_NAME/global.css. Es sieht aber nicht wirklich überzeugend aus. :( Eine bessere Lösung wäre durchaus wünschenswert. ..Jahobr (Diskussion) 21:42, 2. Jun. 2017 (CEST)

@Chrfwow: Hallo, ich hab den Wunsch mal in die Rubrik „Lesen“ gesteckt. Okay für dich? -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 13:07, 9. Jun. 2017 (CEST)

Nur zu deiner Info: auch bei Desktop-PCs kann die Helligkeit angepasst werden - bei jedem Computer kann die Helligkeit eingestellt werden. Und eine automatische Aktivierung bei einer gewissen Uhrzeit halte ich für problematisch - schon alleine wegen Lesern aus anderen Ländern (Zeitverschiebung). --TheTokl -> Diskussion • E-Mail • Hilfe 17:00, 20. Jun. 2017 (CEST)

Unterstützung

1.  Pro Chrfwow (Einreichende Person)
2.  Pro Schnark 11:26, 19. Jun. 2017 (CEST)
3.  Pro ProloSozz (Diskussion) 15:11, 19. Jun. 2017 (CEST)
4.  Pro DCB (Diskussion • Bewertung) 22:05, 19. Jun. 2017 (CEST)
5.  Pro --FNDE 00:59, 20. Jun. 2017 (CEST) (siehe Uhrzeit der Signatur)
6.  Pro Zellmer (Diskussion) 15:16, 20. Jun. 2017 (CEST)
7.  Pro--grim (Diskussion) 16:00, 20. Jun. 2017 (CEST)
8.  Pro Zabia (Diskussion) 16:55, 20. Jun. 2017 (CEST)
9.  Pro R.ganaus (Diskussion) 21:49, 20. Jun. 2017 (CEST) Eine automatische Aktivierung halte ich für keine gute Idee. Der Leser soll selbst entscheiden können!
10.  Pro Hermannh (Diskussion) 22:41, 20. Jun. 2017 (CEST)
11.  Pro --Thomas Obermair 4 (Diskussion) 23:06, 20. Jun. 2017 (CEST)
12.  Pro --Wikifreund (Diskussion) 23:18, 20. Jun. 2017 (CEST) Bitte ggf. auch ergänzen mit einem optionalen leichten Rotfilter.
13.  Pro --Maxian D-C (Diskussion) 21:56, 21. Jun. 2017 (CEST)
14.  Pro --Maaatze87 (Diskussion) 00:13, 22. Jun. 2017 (CEST)
15.  Pro --GodeNehler (Diskussion) 19:31, 22. Jun. 2017 (CEST)
16.  Pro --Konfressor (Diskussion) 22:17, 22. Jun. 2017 (CEST)
17.  Pro --Quiethoo (Diskussion) 13:28, 23. Jun. 2017 (CEST)
18.  Pro --Daniel749 Disk. (ST–WPST) 21:11, 23. Jun. 2017 (CEST)
19.  Pro -- Freddy2001 ^DISK 11:40, 24. Jun. 2017 (CEST)
20.  Pro Spart bei manchen Geräten auch Akkuleistung. --Rainald62 (Diskussion) 16:00, 24. Jun. 2017 (CEST)
21.  Pro --Mojoaxel (Diskussion) 14:26, 25. Jun. 2017 (CEST)
22.  Pro --DomenikaBo (Diskussion) 21:36, 25. Jun. 2017 (CEST)
23.  Pro Es gibt zwar allh. Browser-Erw. aber die die richtig funzen wollen nach einer weile Geld. -- User: Perhelion 12:47, 26. Jun. 2017 (CEST)
24.  Pro --Incabell (Diskussion) 17:28, 27. Jun. 2017 (CEST)
25.  Pro --Merlin2001 (Diskussion) 00:26, 28. Jun. 2017 (CEST)
26.  Pro --Ak ccm (Diskussion) 00:23, 29. Jun. 2017 (CEST)
27.  Pro —SDKmac (Disk., Bew.) 02:36, 30. Jun. 2017 (CEST) sehr gerne
28.  Pro -- Shoeper 18:32, 30. Jun. 2017 (CEST) Bezüglich der Bildschirmhelligkeit bei Nacht siehe https://justgetflux.com/
29.  Kontra -- Dunkler Hintergrund mit heller Schrift ist besonders Augen-ermüdend und unergonomisch. Nachtaktive können bereits jetzt einen dunklen Skin einstellen. PAB (Diskussion) 20:22, 2. Jul. 2017 (CEST)
30.  Kontra --PerfektesChaos 00:03, 3. Jul. 2017 (CEST) Nachtaktiv nach 00:00 und Abstimmungsende, mit Hinweis auf WP:TWS #Dark skin – daraus wird bei einer Website unserer Größe und bei unserem inhomogenem Content sowieso nix.
    
    

Bug beseitigen: Fehlender Abstand bei links angeordneten Bildern

Was ist das Problem?

Wenn sich neben Bildern, die am linken Seitenrand angeordnet sind, rechts entweder eine Liste (Zeilenanfang: *), eine nummerierte Aufzählung (Zeilenanfang: #) oder die Zählung der Einzelnachweise steht, „kleben“ diese direkt am Rahmen des Bildes, der übliche Weißraum fehlt. Beispiel:

Beliebiges Bild

Fließtext

Üblicher Fließtext

Listen

1. testtext
2. testtext
3. testtext
4. testtext

• testtext
• testtext
• testtext
• testtext

Einzelnachweise

Die Aufzählungszeichen/-nummern sind gegenüber den Überschriften und dem normalen Fließtext nach links verschoben.

Wen betrifft das Problem besonders?

Alle Leser (es sei denn, dieser Effekt wäre auf spezielle Browser/Skins beschränkt. Bei der Kombination Firefox/Monobook tritt er auf)

Lösungsvorschlag

Gibt bestimmt einen Phab-Task dazu, keine Ahnung, wie ich den finden kann

Vorschlagende Person

Mabschaaf 21:48, 9. Jun. 2017 (CEST)

Diskussion

@Mabschaaf: Danke für deinen Wunsch! Ich habe deine Zwischenüberschriften mal geändert, weil sie auch im Inhaltsverzeichnis zu sehen waren. Ansonsten: Ja, ich sehe den Bug auch, und ich nutze Chrome + Vector. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 17:17, 10. Jun. 2017 (CEST)

• Ich befürchte, das ist nicht WP-Spezifisch sondern ein genereller HTML/CSS-Bug beim Aufeinandertreffen von float und Text-paddings bzw. margins im umfließenden Text. Gut möglich, dass sich das mit float gar nicht oder nur mit wirklich fiesen Workarounds beheben lässt. // Martin K. (Diskussion) 18:48, 13. Jun. 2017 (CEST)

Man könnte natürlich list-style-position: inside setzen, aber dann hat man ohne Floats zu viel Abstand, den man zwar über den margin wieder zurücksetzen könnte, dann fehlt er aber in verschachtelten Listen, sodass man ihn dort wieder ergänzen müsste, und … am Ende der Code völlig unverständlich ist, es aber sicher immer noch Fälle gibt, in denen es nicht so aussieht, wie man es gerne hätte. –Schnark 09:29, 14. Jun. 2017 (CEST)

Unterstützung

1.  Pro Mabschaaf (Einreichende Person)
2.  Pro Rübenkopf 12:13, 19. Jun. 2017 (CEST)
3.  Pro --C₂₁H₂₂N₂O₂ (V • T • E) 13:26, 19. Jun. 2017 (CEST)
4.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
5.  Pro DCB (Diskussion • Bewertung) 22:05, 19. Jun. 2017 (CEST)
6.  Pro --FNDE 00:59, 20. Jun. 2017 (CEST)
7.  Pro --HerrAdams (D) 15:16, 20. Jun. 2017 (CEST)
8.  Pro --Rjh (Diskussion) 16:02, 20. Jun. 2017 (CEST)
9.  Pro --Blik (Diskussion) 16:25, 20. Jun. 2017 (CEST)
10.  Pro --  Sir Gawain Disk. 17:56, 20. Jun. 2017 (CEST)
11.  Pro --Claell (Diskussion) 19:18, 20. Jun. 2017 (CEST)
12.  Pro --Thomas Obermair 4 (Diskussion) 23:07, 20. Jun. 2017 (CEST)
13.  Pro Michi 19:14, 21. Jun. 2017 (CEST)
14.  Pro --MGChecker – (📞| 📝| ) 19:52, 21. Jun. 2017 (CEST)
15.  Pro --Thingol (Diskussion) 21:09, 21. Jun. 2017 (CEST)
16.  Pro --Furfur ^{⁂ Diskussion} 22:48, 21. Jun. 2017 (CEST)
17.  Pro --GodeNehler (Diskussion) 19:32, 22. Jun. 2017 (CEST)
18.  Pro --Atamari (Diskussion) 12:25, 23. Jun. 2017 (CEST)
19.  Pro mauriceKA (Diskussion) 13:36, 23. Jun. 2017 (CEST)
20.  Pro --Daniel749 Disk. (ST–WPST) 21:12, 23. Jun. 2017 (CEST)
21.  Pro --Frīheidasliova (FRĀGĀ) 08:58, 24. Jun. 2017 (CEST)
22.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
23.  Pro --DomenikaBo (Diskussion) 21:36, 25. Jun. 2017 (CEST)
24.  Pro --W!B: (Diskussion) 18:08, 27. Jun. 2017 (CEST) selbst wenns ein CSS-bug ist, machen wir halt einen CSS-hack, den man wieder wegtut, wenn das dereinst saniert ist. machen wir mit IE-bugs ua. auch. jdenfalls besser, als im quelltext jedes aufretens herumzubasteln.
25.  Pro --Merlin2001 (Diskussion) 00:26, 28. Jun. 2017 (CEST)
26.  Pro --Ak ccm (Diskussion) 00:24, 29. Jun. 2017 (CEST)
27.  Pro —DerHexer (Disk., Bew.) 21:22, 29. Jun. 2017 (CEST)
28.  Pro --Snurb3010 (Diskussion) 23:52, 29. Jun. 2017 (CEST)
29.  Pro --alexscho (Diskussion) 00:05, 2. Jul. 2017 (CEST)
30.  Pro --PAB (Diskussion) 20:25, 2. Jul. 2017 (CEST)
    
    

Artikel-Lesbarkeit: Zeilenlänge begrenzen

Was ist das Problem?

Da es in der Wikipedia keine Begrenzung der Spaltenbreite gibt, kommt es bei der Darstellung auf großen Monitoren zu sehr langen Zeilen von 200 und mehr Zeichen pro Zeile.

Es gehört zum typographischen Grunderkenntnissen, dass sowohl zu kurze als auch zu lange Zeilen das Lesen von Mengentexte in erheblichem Maße erschweren. Gerade bei viel zu langen Zeile hat man zunehmend Problem nach dem Zeilenende wieder den Anfang der nächsten Zeile zu finden, was insbesonder die Lesegeschwindigkeit deutlich reduziert.

Üblicherweise werden Zeilenlängen zwischen 50 und 75 Zeichen empfohlen. Diese Werte wurden in der Wikipedia nur auf den in der Entstehungszeit üblichen geringen Monitorauflösungen erreicht. Auf aktuellen Desktop- und Notebookmonitoren kommt es fast durchgängig zum beschrieben Problem.

Diese oft nur unterbewusst wahrgenommen Lesbarkeitsdefizite veringern die Attraktivität unserer Plattform und bringen mehr und mehr Leser dazu unsere Inhalte über andere Plattformen (wie die App, mobile Website oder Drittanbieterprogramme wie Wikiwand) zu nutzen, die einen deutlich schlechteren Zugang zum Editieren bieten. Wir verlieren dadurch also auch potentielle Editoren.

Wen betrifft das Problem besonders?

Lösungsvorschlag

• Responsive Begrenzung der Spaltenbreite für den Fließtext der ANR-Artikel.
• Responsive Begrenzung der Zeilenlänge der einzelnen Diskussionsabschnitte auf den Diskussionsseiten
  Vorschlagende Person

Martin K. (Diskussion) 15:52, 10. Jun. 2017 (CEST)

Diskussion

Hier möchte ich nochmal auf dasselbe hinweisen wie bei Benutzer Diskussion:Morten Haan/Skin-Entwurf: „Hinsichtlich der Darstellung des Texts könnten wir jedoch vom Firefox-Lesemodus eine Menge lernen: Dort kann man individuell die Schriftart (mit oder ohne Serifen), Schriftgröße, Satzbreite sowie den Durchschuss festlegen.“ Das ist beinahe alles, was es an individuellen typographischen Vorlieben zu berücksichtigen gäbe, und es wäre leicht umzusetzen.

Der Standard sollte natürlich sein, dass die Zeilenlänge begrenzt wird. Dabei muss bedacht werden, dass wir links und rechts Bilder und Infoboxen einbinden. Gedruckte Bücher lassen dafür teils extra Platz am Rand nur für Bilder, wir lassen den Text im Moment um das Bild herumfließen. Dabei verringert sich die Zeilenlänge. Würden wir eine „goldene“ Zeilenlänge wie 66 Zeichen festsetzen, ergäbe das plus Bild allerdings schon sehr kurze Zeilen. Andere gedruckte Publikationen verwenden von vornherein längere Zeilen von etwa 100 Zeichen, da kann man Bilder störungsfreier unterbringen. --Gorlingor (Diskussion) 16:08, 20. Jun. 2017 (CEST)

Eine begrenzte Zeilenlänge mag schon erstrebenswert sein. Ich löse dies ganz einfach durch Anpassen der Fenstergröße (Ein Klick -> Halber Bildschirm wird ausgenutzt.). Bitte erst einmal die Trennhilfe verbessern (Anderer technischer Wunsch, siehe dort …) und dann kann man über diesen Vorschlag nachdenken. Ich würde bei mir eine solche Begrenzung erst einmal ausschalten wollen. --Boehm (Diskussion) 16:21, 20. Jun. 2017 (CEST)

Du dürftest eben einer der wenigen Nutzer_innen / alten Nerds sein, die ihr Browserfenster anpassen, um einzelne Websites besser darstellen zu können. Alle Menschen, die ich kenne, haben das Browserfenster permanent maximiert. --Gorlingor (Diskussion) 16:49, 20. Jun. 2017 (CEST)

Gorlingor, ich glaube, das ist verbreiteter als du glaubst. Einerseits z.B. nutzen in der Schweiz über 25% der Privatanwender macOS und unter macOS ist Maximieren was exotisches / unter Windows ist das genau umgekehrt; und anderseits, wer grosse Bildschirme hat (so ab ca. 24" / 1920x1080) tendiert auch unter Windows eher dazu, zu "fensterln" (das sind v.a. Anwender an Unternehmensrechnern, also nicht 15"-Heim-Laptops). --Gr1 (Diskussion) 12:54, 30. Jun. 2017 (CEST)

@Sophiston, W!B, Boehm, Gpf, Gr1: Ein paar Verständnisfragen:

1. Welche Bildschirmauflösung nutzt Ihr? Ich hab hier einen 24 FukkHD-Monitor un mein Browserfenster so gut wie immer maximiert.
2. Verwendet Ihr Browser-Tabs?
   • Wieviele Tabs nutzt Ihr parallel? Bei mir sein es einige Dutzend. Und ich bin da vermutlich keine Ausnahme
   • Resized Ihr Euer Browserfenster bei jedem Tab-Wechsel?
3. Wie häufig verwendet Ihr den Lesemodus in der Wikipedia/generell?
   • Stört es Euch nicht, dass ihr da ständig wechseln müsst, um Selbstverständlichkeiten, wie das Suchfeld oder die Sprachlinks nutzen zu können?
   • Stört es Euch nicht, dass dabei viele Tabellen und Grafiken total zerhackt werden?
4. Könnt Ihr mir irgendwelche Websites mit vergleichbarer Reichweite nennen, die keinerlei Zeilenlängenbegrenzung für den Fließtext haben?

//Martin K. (Diskussion) 12:16, 30. Jun. 2017 (CEST)

Gerne:

1. Je nach Standort, entweder 27" mit 2560x1440 bzw. 3x24" mit je 1920x1200 (also kein HiRes)
2. Ja
   • Selten mehr als 10 (ich schliesse konsequent das was ich nicht mehr brauche und hol's mir übers Verlauf falls ich's doch noch brauche)
   • Nein (ausser der Entwickler der Site macht Murks, und dann ziehe ich das in ein neues Fenster rüber einfach um die Fenstergrösse des "Stamm-Browserfensters"nicht anpassen zu müssen, d.h. resize gar nicht)
3. Nie
   • -
   • -
4. In der Tat sind das wenige, doch genau dies führt dazu, dass man das Browserfenster gerne klein hält (wegen den leeren weissen (oder giftgrünen) Flächen rechts bzw. bei zentriertem Content links und rechts)

Im Allgemeinen würde ich eher ein echtes responsives Design wünschen (gleicher Skin für mobile, desktop, man kann bei extrabreiten Fenstern, wie hgzh vorgeschlagen hat, IB z.B. separat darstellen), denn der Vorschlag hier löst nicht alle Probleme. Ich meine: Wenn schon, dann richtig. --Gr1 (Diskussion) 12:54, 30. Jun. 2017 (CEST)

@Gr1: Auch wenn ich dazu auf die Schnelle keine Statistik gefunden habe, würde ich davon ausgehen, dass nur ein geringer Teil der Nutzer das Browserfenster aktiv auf eine lesefreundlich Breite runterskaliert. Die meisten dürften es entweder maximieren, oder (zumindest in Windows >=8) im Halbe/Halbe-Modus neben einer zweiten Anwendung nutzen.

Was den Wunsch nach einem echten responsiven Design angeht, bin ich ganz bei Dir. Aber auch dieses käme in den größeren Auflösungen nicht ohne einen Begrenzung der Zeilenlänge auf eine lesefreundliche Zeichenanzahl aus. // Martin K. (Diskussion) 11:39, 1. Jul. 2017 (CEST)

@Martin Kraft:

1. Welche Bildschirmauflösung nutzt Ihr? >> 1920x1080
2. Verwendet Ihr Browser-Tabs? >> Ja
   • Wieviele Tabs nutzt Ihr parallel? >> Zwischen 30 und 60 verteilt auf ca 4-7 Fenster.
   • Resized Ihr Euer Browserfenster bei jedem Tab-Wechsel? >> Selten, da drei Monitore vorhanden. Wenn nötig, dann neues Fenster.
3. Wie häufig verwendet Ihr den Lesemodus in der Wikipedia/generell? >> Nie
4. Könnt Ihr mir irgendwelche Websites mit vergleichbarer Reichweite nennen, die keinerlei Zeilenlängenbegrenzung für den Fließtext haben? >> Ja, MSDN bspw. VB-Paradise (eingeschränkt, weil rechts noch eine Spalte ist), office-loesungen, etc. Und wenn Du dann bspw. auf anderen Code-Seiten bist, bei denen eine Einschränkung vorhanden ist, kannst Du den Code viel schlechter lesen. Aber welche Relevanz hat die Frage denn überhaupt ? Ich frage wegen der 10 Milliarden Fliegen ;) --Sophiston (Diskussion) 17:12, 30. Jun. 2017 (CEST)

@Sophiston: Neben der Tatsache, dass die Specialinterest-Angebote MSDN und VB-Paradise was Reichweite und Zielgruppe angeht in einer deutlich kleineren Liga spielen als die Wikipedia, ist die Lesbarkeit von Quelltext ein ganz anderer Anwendungsfall als die Lesbarkeit von Fließtext. Code liest man ja nicht Wort für Wort von Anfang bis Ende, sondern scannt ihn strukturell, um sich dann näher mit einzelnen Teilen zu beschäftigen. Nicht umsonst kann man in vielen Code-orientierten Angeboten und Programmen den Zeilenumbruch sogar ganz ausschalten.

Da VB und .net nicht meine Baustelle sind, kenn ich mich in den Tiefen von MSDN nicht wirklich aus. Aber auf dee ersten Blick scheinen doch auch auf dieser Seite die Zeilenlängen der Lesetexte begrenzt zu sein, oder nicht?

10 Milliarden Fliegen können übrigens schon eine Referenz sein ... wenn man selbst eine Fliege ist ;) In Sachen Usability spielt es daher schon eine herausragende Rolle, welches Verhalten und welche Konventionen der Nutzer aus anderen Medien gewöhnt ist. Mal ganz davon abgesehen, dass sich die Länge gut lesbarer Textzeilen aus den physischen pysignionomischen Gegebenheiten ableitet. Wenn eine Zeile ein paar hundert Mal länger als hoch ist, dann steigt die Wahrscheinlichkeit, dass mal sich beim schwenken vom Zeilenende zum nächsten Zeilenanfang in der Zeile vertut einfach ungemein. // Martin K. (Diskussion) 11:39, 1. Jul. 2017 (CEST)

Mein Senf:

1. 10 Zoll, 14 Zoll, 19 Zoll: Unity für Laptops (Alles Maximiert), Unity (1-2 Fenster pro Desktop, 9 Desktops), KDE (2-4 Fenster pro Desktop, 4 Desktops)
2. Max. 4 Tabs pro Browser. 3 Browser parallel: Konqueror, Epiphany, Firefox; Ich arbeite mit Browserfenster und selten mit Tabs. Editor links, Browser rechts: dann kann man gut abschreiben.
3. Nie
4. Die Zeilenbegrenzung habe ich früher mit einem Plugin unter Firefox für die meisten Seiten, die meinen das haben zu müssen, deaktiviert. Ich habe mich aber an die neuen Layouts gewöhnt, auch wenn ich es persönlich nicht mag. Das schöne an der Markup-Sprache ist doch, dass es für alle Bildschirmbreiten gleich gut funktioniert. Warum sollte man sich dann auf nur geringe Breiten beschränken?

PS: Ich habe einen guten Vorschlag zwischen den Technischen Wünschen gelesen: Eine Spalte Text und eine Spalte Bilder, Tablellen, etc. Dann hat man nicht dieses dumme um die Bilder fließender Text und keine anderen Probleme. Ist die Seite zu klein für zwei Spalten, kann man das untereinander darstellen. Die engl. WP hat bspw. für viele Zitate bereits eine zweispaltige Option. Dann hat man keine zu großen Probleme mit der zugroßen Seitenbreite. Ich finde es nicht schön, wenn das halbe Browserfenster nur weiß bleibt. Das ist Platzverschwendung und als Default meiner Meinung nach ungeeignet. Aber wer das möchte soll sich das ruhig in einem Skin einstellen können. Insofern kann man eine solche Erweiterung schreiben und als Option zur Verfügung stellen. --Boehm (Diskussion) 23:01, 30. Jun. 2017 (CEST)

@Boehm: Nun ist das Zeitalter von reinem Markup (=HTML) ja schon etwas länger vorbei, und wir haben mit CSS(3) mittlerweile hervorragende Möglichkeiten Hypertext aus ansehnlich und lesefreundlich zu gestalten. Und da sollte man schon die Gestaltungskonventionen und Lesegewohnheiten in Betracht ziehen, die einigen hundert Jahre älter sind, als das, was irgendwann in den 90igern mal auf winzigen Röhrenbildschirmen erdacht wurde, auf denen die Zeilenlänge allein auf Grund der physischen Grenzen kein Problem war.

Natürlich wäre es sinnvoll, nicht einfach platt die Spaltenbreite zu begrenzen, sondern sich stattdessen ein paar grundlegende Gedanken über ein (teil-)responsives Layout zu machen, dass auch die Bilder, die Artikelnavigation und die Infoboxen mit einbezieht und für höhere Auflösungen eine Mehrspaltigkeit vorsieht. Das werden wir jedoch nicht hinbekommen, wenn wir dieses Problem nicht langsam mal angehen. Und der hiesiege Wunsch ist ein erster Schritt in diese Richtung. // Martin K. (Diskussion) 11:39, 1. Jul. 2017 (CEST)

Als das Internet erfunden wurde hatte ich einen 25 Zoll Röhrenbildschirm (wahrscheinlich bin ich jetzt verstrahlt). Meine Bildschirme sind immer kleiner geworden. Ist einfacher mit einem Schlepptop. Alle Seiten, die ich kenne, die ein modernes (bevormundendes) Erlebnis eingebaut haben haben sich meiner Meinung nach verschlimmbessert. Das Laden, Scrollen, Bearbeiten ist wesentlich träger. Es löst scheinbar Probleme (Zeilenlänge), die ich eigentlich nicht habe. Na toll. Welche Internetseite kennst Du denn, die Du als Vorzeigebeispiel dienen könnte? Vielleicht surfe ich immer nur auf den falschen Seiten. --Boehm (Diskussion) 12:24, 1. Jul. 2017 (CEST)

Meiner Erinnerung nach hat man selbst auf 25 Röhrenbildschirmen Anfang der 90er keine 1920px Breitauflösung verwendet (das gaben damals nämlich weder Monitor noch Grafikkarten her) sondern bestenfalls 1024px. Entsprechend groß und niedrigauflösend waren damals die Buchstaben der Texte und das Zeilenlängenproblem gab es in der heutigen Form nicht.

Mittlerweile gibt es doch praktisch kein einzige größere Website mehr, die ihre Zeilen bis in die Unendlichkeit läufen lässt. Von Google über die Nachrichtenwebsites bis hin zu Facebook und Twitter haben die doch schon alle seit Jahren die Breite ihrer Fließtexte auf eine lesbare Zeichenzahl begrenzt?! Von daher kannst Du Dir die Beispiele praktisch aussuchen. Aber nehmen wir doch mal die mMn herausragend gut lesbare Zeit. Würdest Du deren Artikel wirklich lesen wollen, wenn sie sich als homogene Bleiwüste von einem Ende des FullHD-Monitors bis zum anderen erstrecken würde?!

P.S.: Welchen Einfluss soll den eine Begrrenzung der Zeillänge auf die Ladezeit haben? // Martin K. (Diskussion) 12:39, 1. Jul. 2017 (CEST)

Na, wenn die Wikipedia in Richtung der zitierten Zeit Seite gehen soll, so kann ich nur sagen: Ich persönlich möchte das nicht. Es ist für mich schwerer zu lesen als den Artikel über Die Zeit. Wenn ich die Schriftgröße ca. gleich wähle, dann ist ein drittel des Bildschirms nur grau, noch ein großzügiger weißer Rand, und nur ca. 50% der Fensterbreite sind mit Test gefüllt und man muss doppelt soviel scrollen um den ganzen Text zu lesen. Das mögen andere anders empfinden.

Der Röhrenbildschirm war von HP. Die Auflösung weiss ich nicht mehr, aber ich hatte standartmässig 2 oder mehr Fenster nebeneinander.

Zusätzliche (unnötige) Features (CSS) haben immer einen Einfluss auf die Ladezeit und die Downloadmenge. Die Zeilenbegrenzung allein macht den Kohl nicht fett, aber in der Summe wird der Aufbau der Seiten schon langsamer.

Gruß --Boehm (Diskussion) 14:54, 1. Jul. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro Schnark 11:27, 19. Jun. 2017 (CEST)
3.  Pro ProloSozz (Diskussion) 15:13, 19. Jun. 2017 (CEST) Default-Einstellung sollte unbegrenzt sein; das soll in den eigenen Prefs eingestellt werden müssen, wenn das kürzer als "bidschirmbreit" sein soll.
4.  Pro DCB (Diskussion • Bewertung) 22:06, 19. Jun. 2017 (CEST)
5.  Pro --FNDE 01:00, 20. Jun. 2017 (CEST)
6.  Pro --Gorlingor (Diskussion) 16:13, 20. Jun. 2017 (CEST)
7.  Pro Gestumblindi 18:40, 20. Jun. 2017 (CEST)
8.  Pro --Claell (Diskussion) 19:19, 20. Jun. 2017 (CEST)
9.  Pro --Thomas Obermair 4 (Diskussion) 23:07, 20. Jun. 2017 (CEST)
10.  Pro --S. F. B. Morse^{ditditdadaditdit} 18:52, 21. Jun. 2017 (CEST)
11.  Pro --Chrisandres (Diskussion) 22:56, 21. Jun. 2017 (CEST)
12.  Pro --Konfressor (Diskussion) 22:19, 22. Jun. 2017 (CEST)
13.  Pro mauriceKA (Diskussion) 13:37, 23. Jun. 2017 (CEST)
14.  Pro --Nichtich (Diskussion) 22:13, 23. Jun. 2017 (CEST)
15.  Pro --Alva2004 (Diskussion) 13:58, 24. Jun. 2017 (CEST)
16.  Pro --Wrev (Diskussion) 22:35, 25. Jun. 2017 (CEST)
17.  Pro --Menschpædia (Diskussion) 23:38, 25. Jun. 2017 (CEST)
18.  Pro -- Sollte aber nach Möglichkeit individuell einstellbar sein! MikeTheGuru (Diskussion) 01:18, 26. Jun. 2017 (CEST)
19.  Pro --Smial (Diskussion) 14:38, 26. Jun. 2017 (CEST)
20.  Kontra Sophiston (Diskussion) 00:11, 27. Jun. 2017 (CEST) Total dagegen. Man kann doch einfach die Fenstergröße/Schriftgröße anpassen. Länge stört nicht jeden beim Lesen. Wichtiger ist für mich viel Text zu sehen und weniger scrollen zu müssen. Der Lesefluss wird durch das Scrollen doch auch gestört. Selbst die Wiki habe ich auf einem Widescreen-Monitor auf 80% reduziert. Ist halt Geschmackssache. Wäre bloß schade, wenn das nicht mehr so nutzbar wäre. Wie gesagt, einfach die Fenstergröße ändern und man hat seine gewünschte Breite. Andersherum wäre diese Wahlmöglichkeit nicht mehr vorhanden.

    Trotz Deiner Ablehnung hast Du Dich entschieden, Dich in die Unterstützerliste einzutragen. Vielen Dank! --Gorlingor (Diskussion) 14:02, 27. Jun. 2017 (CEST)

    Jups --Sophiston (Diskussion) 17:12, 30. Jun. 2017 (CEST)

21.  Kontra --W!B: (Diskussion) 18:18, 27. Jun. 2017 (CEST) technische fragen der benutzerhardware brauchen wir nicht lösen, das kann sich jeder auf seinem cinemascope-schirm selber machen (wie wärs schlicht fenster des browsers auf halbe bildschirmbreite ziehen? oder den schirm hochkant stellen, das mach ich: super zum lesen.. entsprechende bildschirmsteuerung für drehbare schirme hat inzwischen jedes desktop-betriebssystem an bord). ausserdem (nachdem sich die 800-px-schirme der mitt-2000er inzwischen erledigt haben) ebenfalls nurmehr minderheiten-technologie, die hacks für die superschmalen smartphone-schirme sind weitaus wichtiger, und selbst die wirds in 10 jahren nicht mehr geben ..

    (PS: wo/wie trägt man sich als nicht-unterstützer sonst ein?)

22.  Pro Simulo (Diskussion) 19:59, 27. Jun. 2017 (CEST)
23.  Pro --Merlin2001 (Diskussion) 00:33, 28. Jun. 2017 (CEST) Wow, danke für den Verweis auf Wikiwand - endlich ein modernes Kleid für Wikipedia und deutlich angenehmer zu lesen. (Viele Superuser (da zähle ich mich selbst dazu) scheinen auch zu vergessen, dass nicht alle PC-Benutzer überhaupt wissen, dass man Fenstergrößen ändern kann. Man kann ein die Sicherstellung eines lesefreundlichen Designs also nicht ohne Weiteres auf die Benutzer abschieben.)
24.  Pro --$traight-$hoota {#} 15:03, 28. Jun. 2017 (CEST)
25.  Kontra Dazu browsereigene Features (Lesemodus) nutzen, Browserfenster verkleinern usw. Wer einen 30"-Monitor hat der hat den Browser nicht maximiert (da nicht nur WP davon betroffen ist). ---Gr1 (Diskussion) 16:32, 28. Jun. 2017 (CEST)
26.  Pro --Ak ccm (Diskussion) 00:26, 29. Jun. 2017 (CEST)
27.  Kontra --Boehm (Diskussion) 10:13, 29. Jun. 2017 (CEST) Eine solche Erweiterung sollte nur mit einem ausdrücklichen Opt-In zur Verfügung stehen. Jeder kann sich mit nur einer Mausaktion die gewünschte Breite pixelgenau einstellen. Ohne eine automatische Silbentrennung ist es sowieso nicht sinnvoll (siehe Technischer Wunsch: Silbentrennung). Eine Anleitung für OMA kann man direkt auf der Startseite platzieren: Wie lese ich WP am Besten? Wie drucke ich das am Besten aus (Feste Seitenbreite)? Wie vergrößere ich die Schrift? etc. …
28.  Pro dazu am Besten Bilder und Infoboxen aus dem Textfluss nehmen und in einer zusätzlichen Spalte rechts oder links daneben anordnen, der Umfluss ist sowieso auf jedem Gerät anders. -- hgzh 19:20, 29. Jun. 2017 (CEST)
29.  Kontra -gpf- (Diskussion) 09:29, 30. Jun. 2017 (CEST)
30.  Pro --Whisker (Diskussion) 21:27, 1. Jul. 2017 (CEST)
31.  Kontra HTML ist kein PDF oder T_EX. Eine Artikelseite soll einem nicht vorschreiben wollen, bei ihrer Betrachtung Bildschirmplatz leer zu lassen (→ zu verschwenden). --Hanekomi (Diskussion) 01:18, 2. Jul. 2017 (CEST)
32.  Pro --Linopolus (Diskussion) 10:57, 2. Jul. 2017 (CEST)
33.  Pro Sollte Standard sein, zumindest aber als Skin auswählbar. --Sitacuisses (Diskussion) 13:00, 2. Jul. 2017 (CEST)
34.  Pro --Devotus (Diskussion) 15:28, 2. Jul. 2017 (CEST)
35.  Kontra --Mr N (Diskussion) Zur die Begrenzung der Zeilenlänge mache ich aktuell das Browserfenster schmaler. Eine Zwangsbreitenbeschränkung abzuschalten erscheint mir schwieriger - vor allem auf fremden Geräten auf denen ich mich nicht anmelden möchte.
36.  Pro -- Man könnte ja zumindest mal ein Skin entwickeln, welches auf besonders breiten Bildschirmen zwei- und mehrspaltigen Text (innerhalb jedes Kapitels?) darstellt. PAB (Diskussion) 20:31, 2. Jul. 2017 (CEST)
    
    

Neuer Standardskin

Was ist das Problem?

Die Skins Vector (derzeitiger Standard) und Monobook (ehemaliger Standard) sind zwar zum Lesen und Bearbeiten geeignet, aber nicht gerade für mobiles Arbeiten. Der mobile Skin Minerva ist zwar zum Lesen geeignet, allerdings weniger zum Bearbeiten. Außerdem hat man die Koexistenz eine klassischen und eines mobiles Aussehens, was gerade für Benutzer störend sein kann, die die sowohl zu Hause als auch unterwegs in der Wikipedia lesen/arbeiten. Die linke Seitenleiste ist vor allem bei breiten Tabellen oder Panoramabildern störend, das derzeitige Inhaltsverzeichnis nimmt ggf. viel Platz ein und erzeugt teilweise viel ungenutzten weißen Raum. Außerdem ist der Fließtext immer einspaltig, was sich gerade bei breiten Fenstern negativ auf den Lesefluss auswirkt. Der mobile Skin ist leider nur eingeschränkt zum Arbeiten geeignet, bspw. fehlt die Funktionalität zum Sichten.

Wen betrifft das Problem besonders?

Alle

Lösungsvorschlag

Ich habe einen neuen Skin entworfen, der sowohl für Desktop als auch für mobile Geräte zum Lesen und Bearbeiten geeignet sein sollte: Skin-Entwurf (Diskussion | Englisch) Dieser Skin soll für alle Geräte und alle Nutzer zum Standard werden.

Anmerkungen

• Vector und Monobook sowie natürlich die Druckansicht bleiben bestehen und sollen weiterhin gepflegt werden.
• Mittels __ToC__ kann ein klassisches Inhaltsverzeichnis eingefügt werden.
• Bei der Titelleiste hab ich mich von Wikivoyage auf Englisch inspirieren lassen: Beispiel
  Vorschlagende Person

Morten Haan 🎲 Wikipedia ist für Leser da 18:25, 10. Jun. 2017 (CEST)

Diskussion

Die Diskussionsseite freut sich auf euren Besuch.

Hallo Morten Haan, danke für deinen Wunsch! Zwei inhaltliche Rückfragen dazu:

1. Könntest du noch genauer darauf eingehen, was du unter Standardskin verstehst? Eine Skin für alle Geräte und alle Nutzer?
2. Um den Wunsch auf einen machbaren Rahmen einzugrenzen: Was sind aus deiner Sicht die drei Hauptprobleme, die die neue Skin lösen muss?

Könntest du das noch unter „Was ist das Problem?“ ergänzen? Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 13:33, 14. Jun. 2017 (CEST)

Zu 1: Korrekt, steht jetzt beim Lösungsvorschlag.

Zu 2: Hab ich jetzt gemacht, es sind vor allem (1) eingeschränktes Arbeiten mit dem mobilen Skin, (2) mMn störende linke Leiste, (3) ggf. störendes Inhaltsverzeichnis, (4) Text ausschließlich einspaltig möglich und (5) die Koexistenz von Desktop- und mobilem Skin. --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 17:35, 14. Jun. 2017 (CEST)

..und im Bezug auf Vector (und schlimmer noch Monobook) (6) kein zeitgemäßes Look'n'Feel und (7) nicht responsiv. // Martin K. (Diskussion) 17:51, 14. Jun. 2017 (CEST)

Zu diesem Thema gab es auf der letzten Wikimania eine Diskussionsrunde, wo einige Ideen gesammelt wurde: wm2016:Discussions/Mobile -- Freddy2001 ^DISK 11:47, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Morten Haan (Einreichende Person)
2.  Pro --Thomas Obermair 4 (Diskussion) 23:08, 20. Jun. 2017 (CEST)
3.  Pro --Quiethoo (Diskussion) 13:28, 23. Jun. 2017 (CEST)
4.  Pro --Sebastian Wallroth (Diskussion) 21:26, 29. Jun. 2017 (CEST)
5.  Pro Ich bin grundsätzlich für die Entwicklung und Einführung eines neuen responsiven Skins. Ob das auf basierend auf Morten Haans Vorschlag oder eher auf Basis des Winter-Prototypen geschehen sollte, wäre dann noch zu diskutieren. // Martin K. (Diskussion) 11:44, 1. Jul. 2017 (CEST)
6.  Kontra Default-Skin neu zu deklarieren, bevor dieser überhaupt steht, ist nicht die ricthige Vorgehensweise. Hingegen ist a) die Erarbeitung neuer Skins zu begrüßen; zudem b) auch später allenfalls neuen Default, aber erst, wenn alle Anforderungen erfülltund noch ohne Default bewährt und oft genutzt. @ProloSozz: (nicht signierter Beitrag von ProloSozz (Diskussion | Beiträge) 20:14, 1. Juli 2017)
7.  Kontra -- Zustimmung zu obiger Meinung, wenn auch die Unterschrift dort fehlt... PAB (Diskussion) 20:33, 2. Jul. 2017 (CEST)
   
   

Autorenangaben unter den Artikeln

Was ist das Problem?

• Vielen Leser der Wikipedia ist nicht bekannt/bewusst, dass die Artikel der Wikipedia von vielen Freiwilligen erstellt werden.
• CC-BY-SA (die Lizenz der Wikipedia) verlangt ausdrücklich eine Autorenangabe. Dies wird in der Wikipedia zwar mittels der Versionsgeschichte und der Bilddetailseiten gewährleistet, die für die Leser aber weitgehend unsichtbar bleiben.
• Bei der Nachnutzung von Wikipedia-Inhalten (Texten wie Bildern gleichermaßen) werden immer wieder die Autorenangaben vergessen, wo durch die Lizenz verlischt und einer Urheberrechtsverletzung entsteht. Auf Nachfrage heißt es dann oft, die Wikipedia mache es ja auch nicht. Es scheint also sinnvoll, dass die Wikipedia hier mit gutem Beispiel vorangeht.

Wen betrifft das Problem besonders?

Alle Autoren und alle Leser

Lösungsvorschlag

Unter jedem Artikel sollte (kleingedruckt) eine automatisch generierte Liste aller beteiligten Beitragenden (Autoren, Photographen, Kartographen, usw.) sowie die beteiligten Lizenzen angezeigt werden. So wird einerseits den Lesern bewusst gemacht, wie viele Menschen an dem Artikel mitarbeiten und andererseits könnte man den Artikel 1:1 lizenzsicher kopieren und nachnutzen.

Anmerkungen

 Info: Dieser Wunsch ist unter den Topwünschen. Neuigkeiten zu diesem Wunsch (sowie dem verwandten Wunsch „Bestimmung der Autoren eines Artikels“) werden künftig hier dokumentiert.

Vorschlagende Person

Martin K. (Diskussion) 12:55, 11. Jun. 2017 (CEST)

Diskussion

Den Code dafür gibt es bereits für die Erzeugung der PDF-Dateien, er müsste also lediglich für HTML angepasst werden. Die Autorenabgabe sollte unten im Footer neben der Lizenzangabe stehen und zwar in jedem Skin, auch in der Druckansicht. Beispiel von dieser Seite:
„AchimP, Atamari, Flor!an, Das Robert, Speravir, Martin Kraft, Barnos, H- stt, Schaffnerlos, Thgoiter, Sitacuisses, Ulanwp, Z thomas, Wikiwal, Schnark, Reise Reise, Schniggendiller, Morten Haan, Mabschaaf, Helium4, Debenben, KnorxThieus, Rdengler, Menner, Lómelinde, Thomas Wozniak (HSP), Partynia, GodeNehler, BergePur, Der-Wir- Ing, Andrea014, FNDE, Cedrichoyer, KPFC, Hgzh, Wi-luc-ky, Rübenkopf, Charlie Kritschmar (WMDE), Lea Voget (WMDE), Michael Schönitzer (WMDE), Johanna Strodt (WMDE) und Anonyme: 1“
--Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 17:31, 11. Jun. 2017 (CEST)

@Martin Kraft: Hallo! Als Hinweis: Einen sehr ähnlichen Wunsch gibt es schon unter den Topwünschen: „Autorenliste“, s. den Abschnitt „Einblendung der Autoren direkt am Artikeltext bzw. auf einer Credit-Seite“. Dieser Wunsch ist zzt. geblockt, weil noch eine Communityentscheidung dazu aussteht, ob Autorennamen generell sichtbarer gemacht werden sollen, oder nicht. Dein Wunsch hier könnte vielleicht eine gute Gelegenheit dazu sein, Leute zu finden, die gemeinsam so ein Meinungsbild starten wollen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 21:09, 16. Jun. 2017 (CEST)

Ich hoffe doch sehr, dass die Autoren, die nur Vandalismus zu einem Artikel beitragen nicht auch noch die Ehre bekommen als Autor, des Artikels zu gelten. Eine wichtige Besonderheit ist es, dass man bei der WP auch anonym beitragen kann (IP oder Pseudonym). Diese Personen wollen vielleicht gar nicht genannt werden. Müssen sie dann auf die Liste, oder können Sie das bewußt vermeiden? Ein opt-in wäre vielleicht sinnvoll. --Boehm (Diskussion) 21:59, 22. Jun. 2017 (CEST)

Solch eine Funktion gibt oder gab es schon in MediaWiki, sie wurde auf WMF-Servern aus Performancegründen deaktiviert. -- Freddy2001 ^DISK 11:48, 24. Jun. 2017 (CEST)

Unterstützung

1.  Pro Martin Kraft (Einreichende Person)
2.  Pro -- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST)
3.  Pro Schnark 11:27, 19. Jun. 2017 (CEST)
4.  Pro -- Thomas Wozniak (HSP) (Diskussion) 11:48, 19. Jun. 2017 (CEST)
5.  Pro --ProloSozz (Diskussion) 15:14, 19. Jun. 2017 (CEST)
6.  Pro --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 19:50, 19. Jun. 2017 (CEST)
7.  Pro DCB (Diskussion • Bewertung) 22:08, 19. Jun. 2017 (CEST)
8.  Pro --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 22:49, 19. Jun. 2017 (CEST)
9.  Pro Rübenkopf 10:09, 20. Jun. 2017 (CEST)
10.  Pro --Tkkrd (Diskussion) _{(Neulingshilfe)} 14:46, 20. Jun. 2017 (CEST)
11.  Pro --Adnon (Diskussion) 14:53, 20. Jun. 2017 (CEST)
12.  Pro --HerrAdams (D) 15:19, 20. Jun. 2017 (CEST)
13.  Pro --Andropov (Diskussion) 16:08, 20. Jun. 2017 (CEST)
14.  Pro --Abubiju (Diskussion) 16:55, 20. Jun. 2017 (CEST)
15.  Pro Zabia (Diskussion) 16:56, 20. Jun. 2017 (CEST)
16.  Pro --Smial (Diskussion) 17:28, 20. Jun. 2017 (CEST)
17.  Pro --  Sir Gawain Disk. 17:57, 20. Jun. 2017 (CEST)
18.  Pro --Stepro (Diskussion) 17:58, 20. Jun. 2017 (CEST)
19.  Pro --Frank Schulenburg (Diskussion) 18:36, 20. Jun. 2017 (CEST)
20.  Pro -- Hans50 (Diskussion) 18:39, 20. Jun. 2017 (CEST)  sortieren nach Grösse und Anzahl der BearbeitungenHans50 (Diskussion) 10:34, 21. Jun. 2017 (CEST)
21.  Pro Gestumblindi 18:41, 20. Jun. 2017 (CEST)
22.  Pro --Claell (Diskussion) 19:20, 20. Jun. 2017 (CEST)
23.  Pro aber bitte eine ausklappbare Liste, die zunächst eingeklappt ist. Sonst beansprucht sie bei vielen Artikeln mehr Platz als der Artikel selbst. Und die Liste der Autoren sollte selbstverständlich keine Duplikate enthalten. --Till.niermann (Diskussion) 20:51, 20. Jun. 2017 (CEST)
24.  Pro --Gelber kaktus (Diskussion) 21:56, 20. Jun. 2017 (CEST)
25.  Pro aber bitte nicht nur eine beliebige Aufzählung, sondern abgestuft nach beigetragener Menge (Vorbild Benutzer:APPER/WikiHistory). --Orci Disk 21:58, 20. Jun. 2017 (CEST)
26.  Pro --Thomas Obermair 4 (Diskussion) 23:08, 20. Jun. 2017 (CEST)
27.  Pro --Wikifreund (Diskussion) 23:23, 20. Jun. 2017 (CEST) Information sollte aber nur optional aufklappbar sein. Sortierung der Benutzer nicht alphabetisch sondern nach anteiliger Textmenge bzw. Datenmenge.
28.  Pro --MSchnitzler2000 (Diskussion) 00:23, 21. Jun. 2017 (CEST)
29.  Pro --SkiFreak99 (Diskussion) 00:25, 21. Jun. 2017 (CEST)
30.  Pro Verbunden mit Wikipedia:Umfragen/Technische_Wünsche_2017/Lesen#Autorenbestimmung_eines_Artikel_.28.E2.86.92_WikiHistory.29 macht dies sehr viel Sinn. Also auch unter den Artikeln in Reihenfolge die (Haupt)Autoren, mit einer Zahl zur Einschätzung (evt. in Prozent, da leichter zu lesen, als Einheit in Tausenden von Zeichen) zu nennen. --rugk (Diskussion) 00:46, 21. Jun. 2017 (CEST)
31.  Pro --Nordlicht↔ 07:39, 21. Jun. 2017 (CEST)
32.  Pro --abgestuft nach beigetragener Menge (Vorbild Benutzer:APPER/WikiHistory) TypeZero (Diskussion) 09:54, 21. Jun. 2017 (CEST)
33.  Pro sortieren nach Grösse und Anzahl der Bearbeitungen --Uranus95 (Diskussion) 09:59, 21. Jun. 2017 (CEST)
34.  Pro --jcornelius  11:37, 21. Jun. 2017 (CEST)
35.  Pro sk (Diskussion) 16:47, 21. Jun. 2017 (CEST)
36.  Pro --Carolus requiescat (Diskussion) 17:12, 21. Jun. 2017 (CEST)
37.  Pro --S. F. B. Morse^{ditditdadaditdit} 18:55, 21. Jun. 2017 (CEST)
38.  Pro --Louis ♫ Bafrance ☼ Schwätz halt mit m'r, wenn da ebbes saga witt 19:47, 21. Jun. 2017 (CEST)
39.  Pro --MGChecker – (📞| 📝| ) 19:52, 21. Jun. 2017 (CEST)
40.  Pro --Pelz (Diskussion) 22:28, 21. Jun. 2017 (CEST)
41.  Pro --HHill (Diskussion) 12:28, 22. Jun. 2017 (CEST)
42.  Pro mauriceKA (Diskussion) 13:39, 23. Jun. 2017 (CEST)
43.  Pro --Lesendes Okapi (Diskussion) 20:16, 23. Jun. 2017 (CEST) Ich erinnere mich noch an meine erste Entdeckung, dass jeder Artikel auch noch eine Diskussionsseite enthält... der Standardleser bemerkt die oberen Reiter nicht mal.
44.  Pro --Daniel749 Disk. (ST–WPST) 21:16, 23. Jun. 2017 (CEST)
45.  Pro --Chiborg (Diskussion) 23:18, 23. Jun. 2017 (CEST)
46.  Pro --Crazy1880 11:07, 24. Jun. 2017 (CEST)
47.  Pro --Alva2004 (Diskussion) 14:00, 24. Jun. 2017 (CEST)
48.  Pro Aber nur falls strikt auf Übersichtlichkeit geachtet wird! Das könnte inflationär viel Text werden! Vielleicht als ausklappbaren Block oder so, also dass nur die 5 wichtigsten genannt werden, und der Rest dann eingeblendet werden kann. Divof (Diskussion) 19:51, 24. Jun. 2017 (CEST)
49.  Pro --Varina (Diskussion) 14:04, 25. Jun. 2017 (CEST)
50.  Pro --Mojoaxel (Diskussion) 14:22, 25. Jun. 2017 (CEST)
51.  Pro --DomenikaBo (Diskussion) 21:38, 25. Jun. 2017 (CEST)
52.  Pro --MikeTheGuru (Diskussion) 01:26, 26. Jun. 2017 (CEST)
    Gute Idee… nur wo trifft man die Grenze zwischen Kleinigkeiten (wenn ich einen Tippfehler ausbessere betrachte ich mich nicht als Autor) oder echter Schöpfung (wenn ich zB. einen 2-Zeilen-Artikel zu einem brauchbaren erweitere)?
53.  Neutral --Rainald62 (Diskussion) 13:17, 26. Jun. 2017 (CEST) Mit Filterung nur dann, wenn das Tool wirklich funktioniert, was kaum möglich ist. Ein Benutzer, der hundertfach richtig entschieden hat, Änderungen zu behalten oder zu revertieren, ist imho eher Hauptautor als einer, der in guter Absicht große Teile sprachlich überarbeitet und dabei inhaltlich verschlimmbessert hat. Und wie soll das Tool bei Übersetzungen aus anderen Wikis die dortigen Autoren selektieren? Es müsste Quell- und Zielartikel inhaltlich vergleichen können. Das wird nichts.
54.  Pro --Uj1405 10:37, 27. Jun. 2017 (CEST)
55.  Pro --Merlin2001 (Diskussion) 00:35, 28. Jun. 2017 (CEST)
56.  Pro --Kein Einstein (Diskussion) 15:03, 28. Jun. 2017 (CEST)
57.  Pro --Ak ccm (Diskussion) 00:29, 29. Jun. 2017 (CEST)
58.  Kontra: Auch bei der Weiternutzung reicht ein Link zur Liste der Autoren ohne explizite Nennung. Zudem sind viele Details zur Nennung hier nicht geklärt. Außerdem steht die Umsetzung meiner Ansicht nach im Widerspruch zu dieser Umfrage (Mir ist bewusst, dass es nur eine Umfrage und kein Meinungsbild war). (nicht signierter Beitrag von Doc z (Diskussion | Beiträge) )
    • @Doc z: Mal abgesehen davon, dass Weiternutzung eh dringen überarbeitungsbedürftig ist halte es für fragwürdig, ob diese Empfehlung Bestand hätte, wenn einer der Autoren mal einen Nachnutzer vor Gericht bringen würde. In der Lizenz gibt es jedenfalls keine solche Ausnahmeregelung und bei CC-BA-SA-Bildern ist das Fehlen einer Lizenzangabe im Nutzungsmedium definitiv eine Urheberrechtsverletzung. // Martin K. (Diskussion) 12:23, 30. Jun. 2017 (CEST)
      • Zum einen war dies nur ein Punkt in meiner Contra-Begründung und zum anderen sollte man dann erst einmal die Weiternutzungseite ändern (vorausgesetzt Du hast Recht, was ich nicht beurteilen kann), die der erste und wichtigste Anlaufpunkt für Nachnutzer ist. Zu den Bildern: Hätte Dein Änderungswunsch nur auf die Bilder gezielt, so hätte ich nicht mit Contra gestimmt. --Doc ζ 13:30, 30. Jun. 2017 (CEST)
        • Da CC-BY-SA im Hinblick auf die Namensnennung eine Gleichbehandlung aller beteiligten Urheber verlangt, kann man nach meinem Rechtsverständnis das eine leider nicht vom anderen trennen. // Martin K. (Diskussion) 12:42, 1. Jul. 2017 (CEST)
59.  Pro --Ailura (Diskussion) 12:02, 29. Jun. 2017 (CEST)
60.  Pro --Flo Beck (Diskussion) 12:50, 29. Jun. 2017 (CEST)
61.  Pro —DerHexer (Disk., Bew.) 21:24, 29. Jun. 2017 (CEST)
62.  Pro --Sebastian Wallroth (Diskussion) 21:27, 29. Jun. 2017 (CEST)
63. Enthaltung Eine Liste aller Autoren wird bei einigen Artikeln zu lang. Ein Link zur Liste aller Autoren ist da praktikabler. Aber die gibt es ja schon in Form der Versionsgeschichte. --Snurb3010 (Diskussion) 23:58, 29. Jun. 2017 (CEST)
64.  Pro ---Anima (Diskussion) 14:29, 30. Jun. 2017 (CEST) wie zuvor Apper History
65.  Pro --Häuslebauer (Diskussion) 17:54, 30. Jun. 2017 (CEST) Jedoch mit Einschränkung auf die fünf Autoren, die den meisten Text zur Artikelversion beigesteuert haben (Hauptautoren) oder eine prozentuale Hürde an beigetragenem Text zur aktuellen Artikelversion. Schlicht und ergreifend, damit die Liste nicht viel zu lang wird.
66.  Pro -- Berlinschneid (Diskussion) 00:57, 1. Jul. 2017 (CEST) Aber wirklich nur die Hauptautoren und nicht jeder, der ein Komma korrigiert hat.
67.  Kontra Das wird viele Probleme mit sich bringen, die Hauptautoren sind schwierig bzw. schlecht ermittelbar und es sind für den Leser unnötige bzw. zu viele Informationen, die man des Weiteren bereits über die Versionsgeschichtenseite und Tools wie WikiHistory erhalten kann. Wenn ihr unbedingt immer euren Namen überall kreditiert haben wollt, nehmt doch bitte gar nicht erst teil und schreibt stattdessen ein Buch oder so. (Das erscheinen des eigenen Usernamens weit oben in der Liste als Motivation für [neue] Editoren ist problematisch, da sie versuchen würden den Ratingalgorithmus auszunutzen z.B. durch self-reverts etc. -> wie gesagt sehr problematisch.) MikeTheGuru hat oben einen guten Punkt gemacht und ich würde es sehr befürworten, wenn dieser Punkt erst mal zurückgestellt wird und zunächst wichtigere und unproblematischere Sachen angegangen werden. --Fixuture (Diskussion) 18:08, 1. Jul. 2017 (CEST)
68.  Pro --Whisker (Diskussion) 21:30, 1. Jul. 2017 (CEST) Mit der von Benutzer:Berlinschneid vorgeschlagenen Einschränkung. Ich bin selbst jemand, der recht viel "Wartung" in Artikeln betreibt, und wegen Ergänzungen von ein paar fehlenden Kommata oder ähnlichem Kleinkram gleich als Autor genannt zu werden, wäre meiner Meinung nach zuviel der Ehre. Als Autor genannt zu werden sollte mMn Benutzern vorbehalten bleiben, die wirklich substantielles zu einem Artikel beisteuern.
69.  Pro -- Platte ^{∪∩∨∃∪} 22:34, 1. Jul. 2017 (CEST)
70.  Pro --Mabschaaf 22:41, 1. Jul. 2017 (CEST)
71.  Pro: Zumindest Artikelautoren mit einem Mindestprozentsatz an Textanteilen (z. B. alle Autoren mit mind. 10%) sollten auch ohne Versionsgeschichte erkennbar sein. Alle Autoren zu nennen, wird bei vielen Artikeln allerdings zu einer viel zu langen Liste führen.--Devotus (Diskussion) 15:08, 2. Jul. 2017 (CEST)
72.  Kontra -- Wer nicht realisiert, dass man unter "Versionsgeschichte" ganz oben rechts sehen kann, wer was beigetragen hat, dem wird auch kaum weiterhelfen, wenn man diese Information in ellenlangen Autorenangaben unter dem Artikel präsentiert. PAB (Diskussion) 20:35, 2. Jul. 2017 (CEST)
73.  Pro -- Mr N (Diskussion) 20:52, 2. Jul. 2017 (CEST) Ja, das wäre echt praktisch. Zumindest in der Bildschirmanzeige könnte man auch einen Hinweis auf die Versionschronik unterbringen
74.  Pro -- Michi 23:08, 2. Jul. 2017 (CEST) Zumindest auf einer Credit-Seite
75.  Pro --Ghilt (Diskussion) 09:26, 4. Jul. 2017 (CEST)