Wikipedia:Umfragen/Technische Wünsche 2017/Lesen
Umfrage Technische Wünsche 2017
Lesen • Suchen • Bearbeiten • Wartung • Beobachten & Benachrichtigen • Soziales • Schwesterprojekte • Mediendateien • Projekte ehrenamtlicher Entwickler • Sonstiges
Vorschau von Einzelnachweisen
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)
Lesende im Allgemeinen. (10:36, 2. Jun. 2017 (CEST)) Unangemeldete Benutzer sind (siehe oben) noch stärker betroffen.
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.
Rübenkopf 10:31, 29. Mai 2017 (CEST)
@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.
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)
- 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)
- Ich verstehe zwar Dein Technik-Sprech nicht, Schnark, aber das klingt mir nicht gut.
- 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)
- 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)
- @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)
- @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)
- @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 (Einreichende Person) Pro
Sortierbare Tabellen in der Mobilversion ermöglichen
- 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.
- Leser und Autoren
phab:T49858 behandelt dieses Problem
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)
- Hgzh (Einreichende Person) Pro
- Rewo (Diskussion) 11:06, 19. Jun. 2017 (CEST) Pro
Bei Mehrfachreferenzierung Fußnoten-Link-Buchstaben hervorheben
- 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.
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.
Es wäre viel getan, wenn der zutreffende Link-Buchstabe hervorgehoben würde: Fettschreibung, Unterstreichung, Rahmung o. dgl. Danke!
Wi-luc-ky (Diskussion) 14:57, 29. Mai 2017 (CEST)
- Wi-luc-ky (Einreichende Person) Pro
- Marcus Cyron Reden 10:15, 19. Jun. 2017 (CEST) Pro --
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.
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 />
Alle.
Generelles und globales Opt-in.
AchimP (Diskussion) 18:48, 29. Mai 2017 (CEST)
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)
- 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)
- @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)
- AchimP (Einreichende Person) Pro
(automatische) Silbentrennung für lange Wörter
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.
![](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Justice_and_law-wikinews.png/220px-Justice_and_law-wikinews.png)
Mobilbenutzer und Leser nicht trivialer Artikel
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.
Man kennt dies beispielsweise aus LaTeX.
ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 20:56, 29. Mai 2017 (CEST)
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)
![](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Justice_and_law-wikinews.png/220px-Justice_and_law-wikinews.png)
- 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)
- erledigt --ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 11:04, 13. Jun. 2017 (CEST)
- Flor!an (Einreichende Person) Pro
Bessere Darstellung von Einrückungen in der mobilen Wikipedia
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.
Alle Benutzer der mobilen Wikipedia
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.
KPFC 💬 21:16, 29. Mai 2017 (CEST)
@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)
- KPFC (Einreichende Person) Pro
Follow-up zu dem Wunsch Schriftgröße mathematischer Formeln vereinheitlichen
- so wäre es perfekt
- und so
- oder so
- oder so
- sieht es meistens aus
Mathematische und naturwissenschaftliche Artikel
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 sollten möglichst so aussehen wie die Buchstaben ohne math, erscheinen aber fett obwohl sie nicht sind. (Betrifft SVG?)
- Die Baseline und Schriftgröße der sollte passen und sich z.B. für Bildunterschriften der Schriftgröße anpassen . (Betrifft PNG?)
- Etwas wie ein Pfeil bei einem Vektor sollte (mit \textstyle) keinen zusätzlichen Zeilenabstand erfordern. (Betrifft SVG und PNG?)
- Zeichen wie ü in oder (Ångström) sollten etwa so aussehen wie für alle oder Å bzw. workaround oder . (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.
Debenben (Diskussion) 23:37, 29. Mai 2017 (CEST)
- Debenben (Einreichende Person) Pro
"Seitengröße in Bytes" der Versionen und ihre Veränderung besser vermitteln
- In "Versionsgeschichte": Den Erläuterungstext instruktiver gestalten
- In "Gewählte Versionen vergleichen": Den Änderungswert auch zur Detailanzeige eines Versionsunterschieds darstellen
- Im "Artikel": Am Kopf der Seite die Seitengröße anzeigen
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.
Wer sich in die Versionsgeschichte vertieft
siehe oben
–
Helium4 (Diskussion) 06:16, 30. Mai 2017 (CEST)
@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)
- Helium4 (Einreichende Person) Pro
Einbindung der Beacon-Datei in Personenartikeln
Ich wünsche mir eine prominentere Präsentation der Beacon-Datei in biografischen Artikeln.
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.
- Unangemeldete Nutzer
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)
![](https://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/Beacon_AKS-Link.jpg/220px-Beacon_AKS-Link.jpg)
Das Robert .... gibs mir! 10:47, 30. Mai 2017 (CEST)
@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)
- Das Robert (Einreichende Person) Pro
Gallery Darstellung in der Mobilansicht vergrößern
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.
Mobil Nutzer
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.
ℱℒ𝒪ℛℐ𝒜𝒩 (Diskussion) 09:49, 31. Mai 2017 (CEST)
@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)
- Flor!an (Einreichende Person) Pro
- Rewo (Diskussion) 11:08, 19. Jun. 2017 (CEST) Pro
Maschinengesteuertes vorlesen von Wikipedia-Artikeln unter Berücksichtigung der Vorlage Lang
Ä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.
Erblindete und sehbehinderte Menschen sowie ältere Menschen
Der Sreenreader 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.
Ulanwp (Diskussion) 23:33, 31. Mai 2017 (CEST)
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)
- Die Vorlage an sich ist nicht das Entscheidende, wichtig ist das HTML, das die Vorlage erzeugt. Dort setzt sie korrekt das
- Ulanwp (Einreichende Person) Pro
SVG-Dateien sollten direkt in Artikel und andere Seiten eingebunden werden anstatt Pixelgrafiken einzubinden.
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.
Alle Leser, insbesondere solche mit Touchscreens
Ü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.
Morten Haan 🍱 Wikipedia ist für Leser da • Skin-Entwurf 00:41, 1. Jun. 2017 (CEST)
- 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)
- Morten Haan (Einreichende Person) Pro
Suche im Volltext bei Mobile Leser
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.
Mobile Leser
Volltextsuche im Artikel, auch in den eingeklappten Kapiteln
Suche im Text gibt es zumindest in der Android-App und der iOS-App, aber nicht in der nativen mobile-Web-Version.
h-stt !? 21:57, 1. Jun. 2017 (CEST)
- H-stt (Einreichende Person) Pro
klassische Tabs als Menu im Mobile Skin
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.
Power-Leser auf mobilen Geräten.
Änderung der Menu-Struktur im mobile Skin. "Start, Zufall und In der Nähe" sing ganz sicher nicht die wichtigsten Optionen, die man in der Menustruktur suchen würde. Auch das "Beobchatungslisten"-Sternchen ist völlig sinnlos bei nicht angemeldeten Benutzern. Da muss die Disk rein und die History sollte auch nach oben ins Menu.
h-stt !? 21:58, 1. Jun. 2017 (CEST)
@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)
- H-stt (Einreichende Person) Pro
Autorenbestimmung eines Artikel (→ WikiHistory)
Der erfahrende Wikipedianer möchte auf einen Blick erkennen, wer der Hauptautor eines Artikels ist. Damit man bei Problemen jemanden gezielt ansprechen kann.
Erfahrende Wikipedianer
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.
Atamari (Diskussion) 02:02, 5. Jun. 2017 (CEST)
@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 [1], 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)
- Ü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)
- 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)
- 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?
- 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)
- Atamari (Einreichende Person) Pro
- Marcus Cyron Reden 10:17, 19. Jun. 2017 (CEST) Pro --
WP-App: Suche in eingeklappten Tabellen
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
Nutzer der WP-App, die in Artikel suchen
Die Suche auf den Inhalt der Tabellen erweitern.
Thomas 08:14, 6. Jun. 2017 (CEST)
- Z thomas (Einreichende Person) Pro
WP:App: Bei Anker-Nutzung im Artikel bleiben.
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.
Nutzer der WP-App
Beim Anklicken eines Annkers soll innerhalb des Artikels gesprungen werden.
Thomas 08:16, 6. Jun. 2017 (CEST)
- Z thomas (Einreichende Person) Pro
Handhabbarkeit von Spezial:Linkliste verbessern (kleine Statistik)
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.
- Beim Benutzen der Funktion Spezial:Linkliste (Beispiel: [2]) 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
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.
Atamari (Diskussion) 12:38, 6. Jun. 2017 (CEST)
@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)
- Atamari (Einreichende Person) Pro
Differenzierte Darstellung von Name und Qualifikator bei Klammerlemmata
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.
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.
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.
Sitacuisses (Diskussion) 05:21, 8. Jun. 2017 (CEST)
- Sitacuisses (Einreichende Person) Pro
- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST) Pro --
Sortierschlüssel auch für Spezialseiten
Mit {{DEFAULTSORT}} kann man eine Standardsortierung für eine Seite angeben, jedoch funktioniert das nur bei Kategorien und nicht bei alphabetisch sortierten Spezialseiten.
Benutzer bestimmter Spezialseiten
Der Sortierschlüssel soll auch für entsprechende Spezialseiten angewendet werden.
Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 17:27, 8. Jun. 2017 (CEST)
- Morten Haan (Einreichende Person) Pro
Nachtmodus
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.
Nachtaktive und Vielleser.
Den Nachtmodus der mobilen App übernehmen. Dieser könnte sich auch abhängig von der Uhrzeit automatisch selbst aktivieren.
Chrfwow (Diskussion) 18:27, 2. Jun. 2017 (CEST)
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)
- Chrfwow (Einreichende Person) Pro
Bug beseitigen: Fehlender Abstand bei links angeordneten Bildern
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:
![](https://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Dortmund_Florianturm_nachts_IMGP8456.jpg/150px-Dortmund_Florianturm_nachts_IMGP8456.jpg)
- Fließtext
Üblicher Fließtext
- Listen
- testtext
- testtext
- testtext
- testtext
- Einzelnachweise
Die Aufzählungszeichen/-nummern sind gegenüber den Überschriften und dem normalen Fließtext nach links verschoben.
Alle Leser (es sei denn, dieser Effekt wäre auf spezielle Browser/Skins beschränkt. Bei der Kombination Firefox/Monobook tritt er auf)
Gibt bestimmt einen Phab-Task dazu, keine Ahnung, wie ich den finden kann
Mabschaaf 21:48, 9. Jun. 2017 (CEST)
@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 denmargin
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)
- Man könnte natürlich
- Mabschaaf (Einreichende Person) Pro
Artikel-Lesbarkeit: Zeilenlänge begrenzen
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änig 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.
- Responsive Begrenzung der Spaltenbreite für den Fließtext der ANR-Artikel.
- Responsive Begrenzung der Zeilenlänge der einzelnen Diskussionsabschnitte auf den Diskussionsseiten
Martin K. (Diskussion) 15:52, 10. Jun. 2017 (CEST)
- Martin Kraft (Einreichende Person) Pro
Neuer Standardskin
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.
Alle
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.
- 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
Morten Haan 🎲 Wikipedia ist für Leser da 18:25, 10. Jun. 2017 (CEST)
Die Diskussionsseite freut sich auf euren Besuch.
Hallo Morten Haan, danke für deinen Wunsch! Zwei inhaltliche Rückfragen dazu:
- Könntest du noch genauer darauf eingehen, was du unter Standardskin verstehst? Eine Skin für alle Geräte und alle Nutzer?
- 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)
- Morten Haan (Einreichende Person) Pro
Autorenangaben unter den Artikeln
- 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 verlicht 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.
Alle Autoren und alle Leser
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.
Martin K. (Diskussion) 12:55, 11. Jun. 2017 (CEST)
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)
- Martin Kraft (Einreichende Person) Pro
- Marcus Cyron Reden 10:18, 19. Jun. 2017 (CEST) Pro --