Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2011

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2011#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests/Archiv/2011#Thema_1

Vorschau für andere Seiten (bei Vorlagen)

Ja, das wäre äußerst praktisch. Anwendungsbeispiel: AdT-Aktualisieren und gleich auf der HS sehen, wie es ausschauen wird. --Hæggis 09:47, 19. Feb. 2011 (CET)

Nun ja, der MediaWiki-Parser kann nur gespeicherte Vorlagen einbinden und testen. Ich bin aber bereits mit einem JavaScript-Parser beschäftigt, der das dann können wird. -- ✓ ^Bergi 18:34, 19. Feb. 2011 (CET)

• 
• 

:-) Hæggis 20:12, 19. Feb. 2011 (CET)

Vielleicht hilft dir auch schon soetwas: Benutzer:P.Copp/scripts#/templateutil.js Der Umherirrende 20:48, 19. Feb. 2011 (CET)

Vielen Dank für den Link! Ich hab’ am Anfang nicht realisiert, dass 2 Vorschaufenster erzeugt werden, und manchmal ratlos auf das untere geschaut.

Bergi bekommt seinen Kaffee + Schokolade aber trotzdem :-) Hæggis 01:09, 2. Mär. 2011 (CET)

Ist die Anfrage damit erledigt? --Leyo 18:18, 8. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 18:18, 8. Jul. 2011 (CEST)

Bilder/Dateien Bildkategorien zuordnen?

Durch Zufall bin ich mal auf eine Seite "Bildtafel xxxx" gestoßen. Das hat mich auf eine grundlegende Idee gebracht: Könnte man nicht die Bilder auch Kategorien zuordnen? Wenn ich z.B. beim Spazierengehen einen bestimmten Busch gesehen habe, aber nicht weiß, wie er heißt, könnte man einfach die "Bildkategorie:Gehölze" aufrufen, darin alle Bilder aller Gehölze finden und dann wissen, es ist der Busch XY. Das könnte man sogar automatisieren: vom Bild X die Dateiverwendungen durchgehen, und dann die Kategorien der verwendeten Artikel dem Bild zuordnen--Hlambert63 13:12, 29. Mai 2011 (CEST)

Bildkategorien sollten im Normalfall auf Commons zu finden sein. Allerdings sind sie nicht so besonders gepflegt (etwa im Vergleich zu den Bildtafeln), was durch mangelnde Regeln bei der Dateibenennung auch schwierig ist. --W. Kronf *@* 08:24, 30. Mai 2011 (CEST)

Siehe Kategorie:Datei: und Wikipedia:WikiProjekt Dateikategorisierung. Der Umherirrende 21:00, 30. Mai 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 18:02, 8. Jul. 2011 (CEST)

suche steht in artikel

Wenn das Suchfeld mithilfe javascript links angezeigt wird, steht das Suchfeld seit heute bis in den Artikel. --CennoxX 15:06, 16. Feb. 2011 (CET)

Screenshot und die Angabe des Browsers wären den Programmierern in jedem Fall hilfreich. --93.213.158.37 21:28, 16. Feb. 2011 (CET)

Wärst du beim Import des Originalscriptes geblieben, hättest du die Probleme heute nicht. Wenn du den Quelltext schon unbedingt substituieren musst, füge bitte einen [[Link]] zum Original (in einem Kommentar) ein, damit a) nicht andere Nutzer deine evtl. veraltete Kopie einbinden, sondern das echte Skript, und b) damit ich über die Funktion „Links auf diese Seite“ erkennen kann, wer mein Skript benutzt (zum Hinweis auf Updates etc). Danke, -- ✓ ^Bergi 22:46, 16. Feb. 2011 (CET)

Das scheint dann wohl durch Verwendung der aktuellen Version (→Layer-8-Problem) erledigt zu sein. ;) --Saibo (Δ) 12:07, 27. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Saibo (Δ) 12:07, 27. Jul. 2011 (CEST)

keine neue Nachricht bei Archivierung

Wenn ein Bot (vor allem Archivbot) die Diskussionsseite bearbeitet, sollte keine Neue-Nachricht-Meldung gemacht werden.--CENNOXX 03:15, 28. Jul. 2011 (CEST)

Eigentlich gibts dann keine Nachricht, da Bots das Benutzerrecht nominornewtalk haben. Wenn sie eine Benutzerdisk. bearbeiten und das als kleine Änderung markieren, wird kein Kackbalken angezeigt. Sollte das bei dir anders sein, ist das ein technischer Fehler. XenonX3 - (☎:✉) 03:18, 28. Jul. 2011 (CEST)

Hab mal bei dir geguckt und bin dann über Umwege da drauf gestoßen:

• Klein: Wird dieser Parameter auf Ja gesetzt, werden Archivierungen als kleine Bearbeitungen markiert. Bei Benutzerdiskussionsseiten führt das dazu, dass bei der Archivierung keine Nachricht (die sogenannten Kackbalken am oberen Bildschirmrand) für den Benutzer erzeugt wird (Standardwert: Nein).

Danke, danke :Archivierung dieses Abschnittes wurde gewünscht von: --CENNOXX 04:10, 28. Jul. 2011 (CEST)

trim on every tag function

Mich nervt seit einiger Zeit, dass ich ständig Leerzeichen und Zeilenumbrüche in sämtlichen Text-umschließenden Funktionen (der Werkzeugleiste wie der Sonderzeichenleiste) eigentlich völlig nutzlos (oder nicht?) mit eingeschlossen bekomme. Was ich technisch meine: http://api.jquery.com/jQuery.trim/ Ich meine auch dass eine zeitlang eine solche Funktion vorhanden war. -- Perhelion 12:37, 2. Feb. 2011 (CET)

Ja, in der alten Toolbar (Editbuttons) gabs die. phab:T29116 (Bugzilla:27116) -- ✓ ^Bergi 21:04, 2. Feb. 2011 (CET)

Bug ist gefixed. Könnte mit dem nächsten Software-Update kommen. Der Umherirrende 22:48, 4. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:48, 4. Aug. 2011 (CEST)

Gallery-Funktion in der Druckversion

Anscheinend gab es eine Änderung in der Gallery-Funktion, die die Breite der Galerie an die Breite des Browser-Fensters anpasst. Schön und gut, doch nun werden die Bilder in der Druckversion platz- und papierverschwendend einzeln untereinander angeordnet. --JPF ''just another user'' 08:24, 25. Feb. 2011 (CET)

Problem bekannt (phab:T29506 (Bugzilla:27506)), behoben (rev:82748), verkündet (Wikipedia:NEU#Ausstehende Bugfixes für 1.17wmf1) und geht voraussichtlich heute noch live. --Fomafix

Nur eine kleine Rückfrage nach dem Stand der Dinge, da nochkeine Veränderung zu sehen ist. --JPF ''just another user'' 15:49, 27. Feb. 2011 (CET)

Ich hatte schon vor einen Monat gefragt und da war es angeblich schon kurz vor der Lösung: Wenn man Artikel mit Gallerien ausdrucken will, werden die Bilder untereinander, statt nebeneinander weiterhin ausgedruckt. --JPF just another user 20:36, 28. Mär. 2011 (CEST)

Ein Monat ist bei den Entwicklern noch gar nix, wenn die von "kurz" reden. SteMicha 20:44, 28. Mär. 2011 (CEST)

Ach so, ich dachte nur, weil es hieß: "Problem bekannt (Bug 27506), behoben (rev:82748), verkündet (WP:NEU#Ausstehende Bugfixes für 1.17wmf1) und geht voraussichtlich heute noch live." ;-) --JPF just another user 09:39, 29. Mär. 2011 (CEST)

Es stehen anscheinend noch umfangreiche Tests aus. Am 20. März wurde es dem nächsten Entwickler zum Testen gegeben: rev:82748#code-changes. --Fomafix 10:07, 29. Mär. 2011 (CEST)

Danke. Ich melde mich in einemMonat wieder. ;-) --JPF just another user 11:33, 29. Mär. 2011 (CEST)

Du Optimist! ;-) SteMicha 11:50, 29. Mär. 2011 (CEST)

Mit rev:85354 ist am 4. April der Patch in REL1_17 integriert worden. 1.17wmf1 für hier fehlt aber noch. --Fomafix 23:42, 10. Apr. 2011 (CEST)

Ich wollte das Thema mal wieder in Erinnerung bringen. Es macht sich ja auch bei der Buchfunktion nicht gut. --JPF just another user 22:16, 6. Mai 2011 (CEST)

Ja genau, wo liegt denn jetzt noch das Problem? Der Fehler ist ja jetzt schon lange genug bekannt. Grüße --Franz Xaver 13:40, 8. Jul. 2011 (CEST)

Der Codereview ist am 5. Juli erfolgt: rev:82748#code-changes. Jetzt fehlt nur noch die Übernahme in 1.17wmf. --Fomafix 18:11, 8. Jul. 2011 (CEST)

Na, ich hoffe, das dauert jetzt nicht noch einmal ein paar Monate. Grüße --Franz Xaver 21:54, 9. Jul. 2011 (CEST)

Sollte seit heute da sein: Wikipedia:NEU#16. Juli. Der Umherirrende 10:28, 16. Jul. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:46, 4. Aug. 2011 (CEST)

Export von Wikipediaartikeln als EPUB

Hallo, ich möchte anregen Wikipediaartikel neben PDF auch als EPUB exportieren zu lassen (links in der Leiste: Artikel exportieren/drucken). Das bringt viele Vorteile für offline-Leser. Zunächst könnte man auch neben dem RSS-Feed die Artikel des Tages per EPUB zur Verfügung stellen. --Ergom 10:21, 27. Jul. 2011 (CEST)

Wird unter Hilfe:Buchfunktion/Feedback#EPUB behandelt. Der Umherirrende 23:15, 4. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:15, 4. Aug. 2011 (CEST)

Verschlüsselung von „Passwort-Vergessen“-Mails

Hallo,

ich sehe es kritisch, dass die Passwörter in den Passwort-Vergessen-Mails im Klartext versandt werden. Nun lautet mein Vorschlag, eine Verschlüsselung wie z.B. GNU Privacy Guard wahlweise zu implementieren, sodass jeder Benutzer in seinem Menü auswählen kann, ob er verschlüsselte Mails empfangen möchte oder nicht.

MfG --Esperosoph 18:45, 5. Jan. 2011 (CET)

Eingabe von Unicode-Zeichen per Codepoint

In Microsoft Word kann mit Alt + C ein Unicode-Zeichen in dessen Codepoint als Hexadezimalzahl umgewandelt werden und umgekehrt. Damit können über die Tastatur problemlos beliebige Unicode-Zeichen eingegeben werde, sofern deren Codepoint bekannt ist. Mit JavaScript müsste sich diese Funktionalität für das Bearbeitungsfester nachprogrammieren und auf eine frei Tastenkombination legen lassen. --Fomafix 22:45, 7. Jan. 2011 (CET)

Werbebanner

Seit einiger Zeit erscheint bei mir immer so ein lästiges Banner oben auf der Wikipediaseite. Erst hiess es, ich soll spenden, dann hiess es, ich habe genug gespendet und jetzt heisst es, ich soll feiern. Aber eigentlich wollte ich doch nach Informationen suchen. Aber damit ich diese finde, muss ich erst mal tüchtig runterscrollen. Abgesehen davon wäre ein platzsparenderes Layout der Seiten sowieso wünschenswert. Früher gabs das mal, es hiess Monobook. (Und wenn ich mich einlogge, dann erscheint es sogar wieder *freu*) --Tobias dahinden 12:35, 13. Jan. 2011 (CET)

Kategorien entwirren

Artikel, welche die Kategorie Kategorie:Wikipedia:Temporärkopie besitzen und Benutzer-unterseiten sollten nicht in andere Kategorien aufgenommen werden.--CennoxX 16:21, 16. Jan. 2011 (CET)

Beobachtungsliste für Unterabschnitte

Ich fänd es sinnvoll eine Beobachten-Funktion auch für einzelne Abschnitte zu haben. Somit kännte man (vor allem auf Portalseiten) immer dann informiert werden, wenn beim eigenen Abschnitt was passiert ist.--CennoxX 16:28, 16. Jan. 2011 (CET)

Gerade bei Portalen kann man es i.d.R. anders erreichen: indem man die einzelnen Unterseiten beobachtet, aus denen ein Portal normalerweise besteht. Wenn es das nit tut, dann muss vielleicht die Konzeption des Portals besprochen werden. -jkb- 16:32, 16. Jan. 2011 (CET)

Wurde schon oft gefordert, siehe die Ergebnisse hier. Hier (Antwort von Umherirrender) steht, warum es nicht geht. XenonX3 - (☎:±) 16:35, 16. Jan. 2011 (CET)

Benutzer:DrTrigonBot bietet diesen Dienst, siehe z.B. Benutzer:Flominator/DrTrigonBot --Flominator 10:07, 1. Feb. 2011 (CET)

Auch Nicht-Sichter sollen im Logbuch das Patrol-Log ausgeblendet bekommen

Für Nicht-Sichter ist lediglich das Versionsmarkierungslog rausgefiltert, aber für das Patrol-Log hats noch nichtmal die passende Option. Beispiel: Das Log dieser Seite, notfalls abgemeldet.--141.84.69.20 14:12, 18. Jan. 2011 (CET)

Seitenschutzhinweis in der Versionsgeschichte

Seit einiger Zeit wird bei gesperrten Benutzern ein Auszug aus dem Sperrlog bei seinen Beiträgen gezeigt → "Dieser Benutzer ist derzeit gesperrt. Es folgt der aktuelle Eintrag aus dem Benutzersperr-Logbuch:". Es wäre praktisch wenn es diesen Hinweis auch bei gesperrten Artikeln geben würde. Sowas wie: "Dieser Artikel ist derzeit gesschützt. Es folgt der aktuelle Eintrag aus dem Seitenschutz-Logbuch: [letzter Log-Eintrag]" -- chatter^Disk 00:59, 22. Jan. 2011 (CET)

Gibt es doch seit Jahren. Sowohl für halbgesperrte als auch für vollgesperrte, wobei bei letzteren der Auszug nur Admins angezeigt wird, da alle anderen Benutzer dort nicht auf [Bearbeiten] klicken können (mangels entsprechendem Reiter, den bekommen nur Admins angezeigt). Nicht-Admins müssen bei vollgesperrten Seiten auf den Link zum Seitenschutzlog klicken. Dass das unpraktisch bzw. ungerecht ist, wurde letztens schon einmal bemängelt. Keine Ahnung, ob sich da was getan hat. XenonX3 - (☎:±) 10:04, 22. Jan. 2011 (CET)

Nicht-Admins haben denselben Reiter, er heißt bloß [Quelltext anzeigen]. -- ✓ ^Bergi 16:24, 22. Jan. 2011 (CET)

So mein ich das

Dass einem beim [Bearbeiten] eines gesperrten Artikels ein sehr knapper Hinweis auf den Seitenschutz angezeigt wird, weiß ich. Gemeint war aber in der Versionsgeschichte ganz oben (siehe Bild), wie bei der Beitragsseite bei gesperrten Benutzern. Weder wird beim versuchten Bearbeiten der Sperrgrund, die Dauer noch die Art der Sperre angezeigt, dafür aber der gesamte Quelltext mit dem man während der Sperre meist sowieso nichts anfangen kann. So würden auch halbgesperrte Artikel besser gesehen werden, da der Hinweis bisher nur irgendwo weit hinten in der Versionsgeschichte und im Log auftauchen oder wenn man als unangemeldeter Bearbeiten will. -- chatter^Disk 23:02, 22. Jan. 2011 (CET)

Neue Option beim Verschieben: Weiterleitung erstellen für Diskussionsseite

In Bugzilla nicht gefunden, daher einfach mal hier vorgeschlagen: Wenn ich einen Artikel verschiebe, erhalte ich inzwischen die Möglichkeit, das Erstellen der Weiterleitung zu unterdrücken. Schick wäre es, wenn dies auf für die Diskussionsseite gelten würde. Benötigt wird also eine weitere Checkbox mit "Weiterleitung für Diskussionsseite". --Flominator 10:06, 1. Feb. 2011 (CET)

Kleine Info: Dieses Recht besitzen nur Admins und Bots (nicht das sonst jemand vergeblich nach der Box sucht).

Müsstest du in Bugzilla einstellen. Das Recht heißt suppressredirect, die Option wpLeaveRedirect. Merlissimo 12:09, 1. Feb. 2011 (CET)

Die Weiterleitung der Diskussionsseite wird auch unterdrückt. Die Checkbox bezieht sich also auf beide Seiten. Für deinen Wunsch ist es vermutlich einfacher, zwei getrennte Verschiebungen zu machen und bei der ersten Verschiebung den Haken bei "Die Diskussionsseite mitverschieben, wenn möglich" herausnehmen. Der Umherirrende 17:50, 26. Mär. 2011 (CET)

Referenzen in Überschriften

Oft werden Referenzen auch in Überschriften angegeben. Dabei erscheint die Schrift der Ref-Nr. fast ebenso groß wie die Überschrift selbst. es wäre nicht schlecht, wenn die Schriftgröße bzw. -art gleich wäre wie die übrigen ref-Noten im Fließtext. Es handelt sich zwar um reine Optik, die aber etwas schöner wirken würde. --K@rl (Verbessern ist besser als löschen) 22:22, 19. Feb. 2011 (CET)

Wenn ich allerdings eine Referenz in einer Überschrift sehe, so kommt sie einfach raus - mit etwas Nachdenken kann man sie gleich im nächsten umgebauten Satz einbringen und es wirkt besser. -jkb- 22:32, 19. Feb. 2011 (CET)

Wie machst du es aber da dass es gscheit ausschaut ;-) --K@rl (Verbessern ist besser als löschen) 22:56, 19. Feb. 2011 (CET)

Ja ganz einfach, Refs und Links gehören nicht in Überschrift Wikipedia:WSIGA#Überschriften und Absätze -- Perhelion 23:36, 19. Feb. 2011 (CET)

Dann gib mir ganz einfach die Antwort auf die Frage drüber - auf Regeln berufen und keine Alternative bieten ist leicht - glaub mir ich bin auch schon so lang dabei, dass ich das auch kenn. --K@rl (Verbessern ist besser als löschen) 23:56, 19. Feb. 2011 (CET)

provisorisch gemacht, ist jedenfalls besser als ref in der Überschrift, denke ich. Gruß -jkb- 00:18, 20. Feb. 2011 (CET)

Ja ok, (K@rl Du hast dein Link zerstört Vorlage:Smiley/Wartung/8p ). AW: mit <sup class="reference"><ref>...</ref></sup> was wiederum gegen Formatierung verstößt Vorlage:Smiley/Wartung/:p  -- Perhelion 00:31, 20. Feb. 2011 (CET)

WP-Plugin für Bilderstapel (CT, MRT...)

bitte unter Wikipedia:VV#WP-Plugin für Bilderstapel (CT, MRT...) diskutieren. -- ✓ ^Bergi 18:11, 27. Feb. 2011 (CET)

Bei Verschiebung einer Seite nur noch einen Eintrag in Beobachtungsliste.

Wenn eine Seite verschoben wird, hat man zur Zeit vier vollkommen redundante Einträge in der Beobachtungeliste: einen für den alten Namen, einen für die alte Diskussionsseite und je einen für neuen Namen und neue Diskussionsseite. Insbesondere bei gehäuften Versionsarchivverschiebungen ist die Beobachtungsliste recht voll - ohne Mehrwert. Eigentlich müsste es recht einfach sein, drei der Einträge in der Anzeige zu unterdrücken. Entweder direkt, mit CSS (wenn es für alle drei Typen eine Klasse gäbe) oder zumindest mit javascript. syrcro 09:04, 24. Mär. 2011 (CET)

Auf meiner Beobachtungsliste werden nur zwei Verschiebe-Einträge angezeigt, einen für die normale Seite und ein für die Diskussion. (Übrigens ist Java != JavaScript, du kannst JavaScript auf JS verkürzen, wenn du möchtest) Der Umherirrende 16:57, 25. Mär. 2011 (CET)

Fragenzeichen neben Reitern

Moin. Ich möchte vorschlagen, dass jeweils rechts (oder alternativ auch links) neben den Reitern "Diskussion", "Bearbeiten" und "Versionsgeschichte" kleine Fragezeichen platziert werden, die bei einem Mausklick auf Hilfe:Diskussionsseiten, Hilfe:Bearbeiten bzw. Hilfe:Versionen führen. Das würde es Neulingen um einiges leichter machen, mit dem Interface und den Grundfunktionen von Media-Wiki umgehen zu lernen, und wäre gleichzeitig aber auch kein großer Eingriff in die Benutzeroberfläche. SteMicha 14:31, 28. Mär. 2011 (CEST)

Wie schon andernorts vorgeschlagen wurde, sollten die Fragezeichen aber abschaltbar sein. -jkb- 14:35, 28. Mär. 2011 (CEST)

Wenn man die Fragezeichen hinkriegt, sollte das Abschalten auch keine große Sache mehr sein. SteMicha 14:51, 28. Mär. 2011 (CEST)

Ich halte das für eine unnötige Verschlechterung. Statt dessen sollten die Links zu den Hilfeseiten nach dem Klicken einheitlich und gut auffindbar sein. Allenfalls könnten möglicherweise beim Positionieren des Mauszeigers auf einem Reiter ein Kontextmenü erscheinen. Falls sich jeman fragt was nachteilig am Vorschlag ist: eng und unübersichtlich! Die Veränderung würde genau das Gegenteil erreichen von dem was beabsichtigt wird.--Diwas 20:51, 28. Mär. 2011 (CEST)

Externe Tools unter Reiter Versionsgeschichte

Hey, bei Wikimedia habe ich grad gesehen, dass da unter Versionsgeschichte diese Zeile steht: "External tools: Revision history statistics · Revision history search · Page view statistics · Number of watchers" Diese fänd ich auch für die Wikipedia absolut sinnvoll, größere Umwege über Helferlein und Co. würden somit wegfallen. Die aufgeführten Externen Tools sind vor allem an dieser Stelle sinnvoll plaziert. Hier ein Beispiel--CENNOXX 14:10, 17. Apr. 2011 (CEST)

Sowas wird seit einiger Zeit mittels der Vorlage:Artikel-DC auf den Artikeldiskussionsseiten platziert. SteMicha 16:48, 17. Apr. 2011 (CEST)

Das steht in meta:MediaWiki:Histlegend, kann jeder Admin auch bei uns eintragen. Ich weiß nur nicht, ob bei den Nicht-Toolserver-Seiten dann der Traffic für die Seiten zu groß wird, da erstmal jeder drauf klickt (was ist das?). Fair wäre es, die Betreiber vorher zu fragen. Noch besser, wenn die Werkzeuge in MediaWiki sind, aber ist ein anderes Thema. Der Umherirrende 20:30, 18. Apr. 2011 (CEST)

Bzgl. des Traffics sehe ich zumindest bei meinem Server kein Problem. -- Gruß, aka 07:57, 7. Jun. 2011 (CEST)

Das hört sich gut an. Flominator hat auch kein Einwand. Nur weißt er auf darauf hin, sinnvolle Defaultwerte zu wählen. Bei stats.grok.se würde ich nicht nachfragen, da die Seite nicht so etwas aufwändiges macht, wie bei den andern beiden. Somit steht aus meiner Sicht dem nichts mehr im Weg. Müsste jemand mal einen Quelltextvorschlag für die Zeile machen, den man dann anpassen oder direkt umsetzen kann. Der Umherirrende 21:47, 7. Jun. 2011 (CEST)

Klarere Unterscheidung von Zurücksetzen und Entfernen

Hallo, bin schon mehrfach über diese "Fußangel" gestolpert; denn unter beiden Begriffen könnte man sich dasselbe vorstellen. Zusätzlich: Wenn man sich der Wirkung nicht bewusst ist, können alte Einträge versehentlich mit gelöscht werden, was aber kaum bemerkt wird.

Unter Benutzer Diskussion:VÖRBY#Zurücksetzen / entfernen hat mich Benutzer:Diwas auf den Unterschied aufmerksam gemacht. Dort ist auch ein Vorschlag diskutiert, wie man diese Missverständnisse (die sicher schon viele Benutzer hatten), aus dem Weg räumen könnte:

• für das Stornieren der (letzten) Änderungen des Benutzers: das 'Zurücksetzen' bei den Benutzerangaben positionieren: "<Benutzer> (Diskussion|Beiträge|Zurücksetzen)"
• für die einzelne Änderung: (Entfernen) - Ort wie bisher.

Mit dieser Lösung wäre (zusätzlich zu den unterschiedlichen Bezeichnungen) klarer, zu welchem Objekt diese Anweisungen gehören. Dass mit Zurücksetzen nicht der ganze Benutzer betroffen ist, müsste man (wie bisher) entweder wissen oder aus der 'Hilfe' nachlesen. Alternativ: Bei 'Zurücksetzen' die Anzahl <n> der dabei betroffenen Änderungen durch 'Zurücksetzen-n' anzeigen; wenn n=1 wäre, das ganze 'Rücksetzen' weglassen, es entspricht dann dem Entfernen.
Viele Grüße von --VÖRBY 17:37, 12. Mai 2011 (CEST), ursprünglich unter IP erfasst am 13:07, 6. Mai 2011.

Eigentlich heißt die Funktion "rückgängig" aber irgendwann hat mal ein Admin das auf de.wp umbenannt, da rückgängig auch nicht so ganz passt. Die beiden Funktionen werden übrigens durch einen Tooltip erklärt (bei der aktuellen Version in der Versionsgeschichte), den man aber auch übersehen kann. Eine Umpositionierung kann natürlich helfen. Wobei der Link auch noch in anderen Listen auftaucht (Spezial:Beiträge), wo man das nicht zum Benutzer zuordnen kann. Der Umherirrende 17:12, 6. Mai 2011 (CEST)

Dass in Spezial:Beiträge das 'Entfernen' mit 'Rücksetzen' bezeichnet wird, ist erst recht ein Grund, hier eine Verbesserung vorzunehmen: Gleiche Funktionen sollten auch gleich benannt sein. Dort wäre dann (beim Benutzer) eben kein 'rücksetzen' aufgeführt, sondern nur zu einzelnen Beiträgen gehörend (wo dies noch möglich ist) ein 'Entfernen'. Ein kleiner Beitrag zur Q-Verbesserung in WP! --VÖRBY 12:30, 12. Mai 2011 (CEST)

Nein, die Bezeichnungen passen immer und sind einheitlich, nur gibt es auf Spezial:Beiträge auch ein "Zurücksetzen", aber es gibt keinen Benutzernamen wo man es dran schreiben könnte, das wollte ich sagen. Der Umherirrende 21:08, 12. Mai 2011 (CEST)

Dann bedeutet 'Zurücksetzen' auch in dieser Liste 'alle Beiträge des Benutzers bis zu Beiträgen eines anderen Benutzers'!? Ich habe da meine Zweifel - denn zB in meiner Beiträge-Liste steht überall nur 'zurücksetzen' - wahrscheinlich aber mit der Bedeutung 'diesen Beitrag stornieren' (weil vor meinen Beiträgen andere Benutzerbeiträge erfasst wurden). Dagegen wird in der Versionsgeschichte stets nur 'entfernen' verwendet.

Diese beiden Begriffe scheinen also schon unterschiedlich verwendet zu werden. Auch wenn es in Beiträge keine Position für 'Benutzer' gibt: Besonders in diesem Fall wäre mein erweiterter Vorschlag, ("Zurücksetzen-n" bzw. "Entfernen") zum besseren Verständnis nützlich, d.h.: 'Zurücksetzen-1' entspricht 'Entfernen' und 'Entfernen' bedeutet immer 'nur diesen Beitrag'. --VÖRBY 09:51, 13. Mai 2011 (CEST), berichtigt: --VÖRBY 14:05, 13. Mai 2011 (CEST)

Zurücksetzen in der Beiträgsliste heißt, alle Änderungen des betrachteten Benutzers auf dieser Seite zurückzusetzen. Es hat also die gleiche Funktion wie ein Aufruf aus der Versionsgeschichte, daher gibt es den Link auch nur wenn es sich um eine aktuelle Version handelt, wie in der Versionsgeschichte. Der Umherirrende 14:15, 13. Mai 2011 (CEST)

---

Nachdem ich mich etwas näher mit dem Thema befasst habe (Hilfe-Artikel, Ausprobieren), bin ich der Ansicht, dass diese beiden Aktionskürzel von so vielen Gegebenheiten - Seitenart ('Umherirrender', in der Versionsgeschichte gibt es bei mir immer nur 'entfernen'), Rolle des Benutzers, eigene oder fremde Seiten, ...) abhängig sind, dass ich da leider nicht mehr durchblicke. Da ich also hier nur max. 'Halbwissen' habe, ziehe ich meinen Vorschlag zurück. Mögen ihn andere evtl. aufnehmen. 'Intuitiv', wie das z.B. in Grafische Benutzeroberfläche (mit 'selbstbeschreibend' und 'erwartungskonform') beschrieben ist, kann ich das allerdings nicht nennen. Jedenfalls Danke für die Mitdiskussion.--VÖRBY 14:29, 13. Mai 2011 (CEST)

Zurücksetzen ist immer nur bei der aktuellen Version möglich und setzt auf die Version zurück, die nicht vom Benutzer der aktuellen Version kommt. Da du Sichter bist, sollte es auch bei dir in der Versionsgeschichte angezeigt werden. Entfernen wird nur in der Versionsgeschichte oder Versionsunterschiede angezeigt. Der Umherirrende 14:38, 13. Mai 2011 (CEST)

In anderen Sprachen – lokale Fremd-Bezeichnungen anzeigen

Beim Suchen einer bestimmten Seite in einer anderen Sprache ist das Suchen nach Eigenbezeichnung teils unnötig zeitaufwändig. Wenn ich das Kürzel kenne, z.B. fr oder zh, kann ich mich natürlich am (lateinischen) Alphabet orientieren, also fr weit vorn und zh ganz am Ende der Liste finden.

Suche ich aber z.B. die Entsprechung in chinesisch, ausgehend von einer de- oder en-Seite, ohne das Kürzel zh zu kennen, bin ich erstmal aufgeschmissen. Das Verstehen der Sprache (→ Selbstbezeichnung) ist imho keineswegs ein „KO-Kriterium“, um schnell mit Interwikis arbeiten zu können/„dürfen“.

Daher die Anfrage:

• Standardversion von In anderen Sprachen – jeweilige Selbstbezeichnung (erleichtert auch den „Rückweg“ in Sprach(version)en, die man besser versteht, wenn man vorher aufgrund von xyζ in einer schlecht verständlichen Sprachversion unterwegs war)

• Per Klick umschaltbar – (Fremd-)Bezeichnung der Sprache in der Wikipedia, in der man den Button betätigt, sprich die Interwikis zur ruWP heißt dann nicht mehr Русский, sondern Russisch (in der enWP entspr. Russian usw.). Nach dem erneueten Klick auf den Button isses wieder wie vorher (Selbstbezeichnung). Bin gewiss nicht der Erste, der das anfragt. --Hæggis 02:40, 7. Mai 2011 (CEST)

Es gibt als Benutzerskript ein Interwiki-Übersetzer. Das Problem ist, das die Sprachnamen in der jeweiligen Sprache nicht im Standardumfang von MediaWiki enthalten sind. Eine solche Liste zu erstellen und zu Pflegen ist ein gewisser Aufwand, der durch eine MediaWiki-Erweiterung abgedeckt ist, aber die steht hier nicht zur Verfügung. Der Umherirrende 21:37, 8. Mai 2011 (CEST)

Ah, vielen Dank für den Link (ohne erfahrene Leute mit mind. a bissl Gedächtnis wäre viel frühere Müh & Lösungsarbeit für die Katz oO).

So aufwändig wär die Liste imho gar nicht. Laut Spezial:Liste der Wikimedia-Wikis gibt es zwar 281 Wikipedia-Projekte, was stattliche 78.680 lokale Fremdsprachenbezeichnungen erfordet (n²-n, vgl. 1 Sprachversion → 0 lok. Fremdspr.-Bez., 2 → 2, 3 → 6, 4 → 12 …), die aber im jew. WP-Projekt recht schnell erstellt ist, für die deWP gibt es sie ja schon im Skript von Revolus. Die Listen bzw. Funktion insgesamt wären auch in Wikiquote, -news usw. nutzbar.

Bzgl. Pflege: Soviel ändert sich doch nicht, selbst im Laufe von Jahr(zehnt)en. Vielleicht gibt’s mal eine Rechtschreipreform, oder eine bisher alternative Bezeichnung setzt sich durch (im Deutschen z.B. Persisch|Farsi|Dari, Chinesisch|Mandarin, Mazirisch|Tamazight oder Spanisch|Kastilisch gegenüber Katalanisch). Sowas kann ja im jew. Projekt geregelt werden.

Aber was red’ ich, vmtl. gibt’s ja keinen prinzipiell Einwänd, dass es gemacht wird, es hängt nur bei der Umsetzung.

Wen bzw. welche Seite schreibt man da am ebsten an? --Hæggis 01:47, 14. Mai 2011 (CEST)

Leider hat selbst auf dewiki nicht jede Sprache mit einem Wikipedika-Projekt einen eigenen Sprach-Artikel. Gerade wenn neue Wikipedias erstellt werden, ist es manchmal für die Meldung auf Wikipedia:NEU bzw. beim Eintrag auf Wikipedia:Sprachen schwierig den korrekten deutschen Namen herauszubekommen. Ich hatte eben z.B. rej überprüft, ob es für WP:Sprachen relavant sein könnte (was nicht der Fall ist). Vermutlich hätte ich eine Münze geworfen, ob ich "Rejang" oder "Redjang" nehme. Ähnlich fiel die Entscheidung für "Achinesisch", wo man mit "Aceh" näher an der nativen Bezeichnung hätte bleiben können. Das wird noch lustig wenn, wie geplant, irgendwann die Interwikis auf incubator-Projekte dazukommen. (Incubator ist seit kurzem nicht mehr nur Entstehungsort neuer Wikipedias, sondern soll zukünftig offiziell ständige Heimat für kleine Wikipedias ohne ausreichende Community bleiben. Die bekommen dann sogar eine eigene Subdomain, die nach incubator weiterleitet.) Merlissimo 13:43, 29. Mai 2011 (CEST)

Autoren-Datenschutz in Wikipedia

Hallo WP-Community und -Entwickler,

WP bietet jedem Benutzer die Möglichkeit, alle Beiträge eines bestimmten Autors auszuwerten.

Ich schlage vor, dass jeder Benutzer diese Möglichkeit für seine Beiträge (zumindest optional) ausschalten kann. Damit könnte nur er selbst und eine bestimmte (wäre noch zu regeln) Admin-Kategorie diese Auswertung abrufen.

Die Möglichkeit, anonym (über IP) zu bleiben, existiert zwar, doch halte ich die Anonymität aus dem Blickwinkel einzelner Beiträge für kontraproduktiv - und auch aus Datenschutz-Gesichtspunkten nicht für erforderlich. Dagegen liefert ein Überblick über ALLE Beiträge des Benutzers in erster Linie ein sehr individuelles Bild (Profil) vom Autoren, nicht über einzelne WP-Themen.

Ich könnte mir vorstellen, dass diese Schutzmaßnahme, würde sie öffentlichen Datenschutz-Gremien bekanntgegeben werden, nicht nur unterstützt, sondern von Wikipedia gefordert werden.

Schließlich sschreibt Wikipedia unter Datenschutz selbst: "Sind (dennoch) Daten einmal angefallen, so sind technisch-organisatorische Maßnahmen zur Gewährleistung des Datenschutzes zu treffen (Datensicherheit). Hierzu gehört insbesondere die Beschränkung des Zugriffs auf die Daten durch die jeweils berechtigten Personen. Für automatisierte Abrufverfahren (Online-Verfahren) sind besondere Regeln zu beachten."

In Wikipedia:Datenschutz selbst wird dieses Problem zwar kurz (unter 'Benutzerbeiträge') behandelt. Ob die dortige Aussage "Benutzerbeiträge werden ebenfalls zusammengestellt und öffentlich zugänglich gemacht. Dabei werden Benutzerbeiträge gemäß der Registrierung und des Anmeldestatus zusammengefasst. Daten über diese Benutzerbeiträge, wie die Zeiten, zu denen Benutzer Bearbeitungen vorgenommen haben oder die Anzahl ihrer Bearbeitungen, sind öffentlich über die Beitragsliste aufrufbar und werden in aggregierter Form von anderen Benutzern (müsste wohl heißen "für andere Benutzer") veröffentlicht." rechtskonform ist, möchte ich aber bezweifeln.
Viele Grüße von --VÖRBY 09:55, 7. Mai 2011 (CEST)

Nachträgliche Ergänzung - nach etwas intensiverer Sichtung dieses WP-Artikels: Das Kapitel 'personenbezogene Daten' beschreibt die Restriktionen des Zugriffs, d.h. nennt die Benutzergruppen, denen diese Daten zugänglich sind. Die Frage wäre, ob die Benutzerbeiträge (nach Benutzer aggregiert) als 'personenbezogen' gelten. --VÖRBY 15:14, 11. Mai 2011 (CEST)

Und wie stellst du dir das vor? Jemandem, der nicht die betreffenden Rechte hat, wird nur deine IP angezeigt? Das würde bedeuten, dass alle mit diesen Rechten deine IP-Adressen deinem Benutzernamen zuordnen könnten (wie schon jetzt Oversighter), und das wäre imho ein viel größerer Eingriff in die Datenschutzrechte. -- ✓ ^Bergi 22:09, 8. Mai 2011 (CEST)

Ich glaube, das hast du missverstanden. Vörby möchte, soweit ich das verstanden habe, dass ganz einfach Spezial:Beiträge für bestimmte, nicht explizit berechtigte Leser/Benutzer nicht abrufbar ist, wenn der zugehörige Benutzer dies in seinen Einstellungen auswählt. Mit einer Anzeige der IP-Adresse hat das nichts zu tun. Die Idee ist meiner Meinung nach nicht schlecht, und falls technisch machbar sicherlich zu befürworten. --W. Kronf *@* 23:01, 8. Mai 2011 (CEST)

Du meinst also, in der Versionsgeschichte eines Artikels ist der Benutzername (und in allen Versionsgeschichten derselbe) schon zu sehen, nur die Übersicht nicht? Fände ich befremdlich, und wenn ich's wirklich wissen will muss ich halt suchen (lassen). Technisch gesehen würden wohl manche Dienste (Bots, TS) kaputtgehen (oder die Einschränkung missachten müssen). Zudem kann jeder „Prangerseiten“ erstellen, auf denen deine Arbeit an verschiedenen Themenbereichen (so zufällig aufgefunden) aufgelistet wird; das einfachste Beispiel wäre deine Diskussionsseite auf der du zu verschiedenem angesprochen wirst. -- ✓ ^Bergi 12:01, 9. Mai 2011 (CEST)

---

Danke für die Mitdiskussion: Eure letzten beiden Beiträge erkennen meine Absicht korrekt: Es geht mir darum, "0-8-15-Benutzern" nicht meine gesamte Historie auf die Nase binden zu müssen. Wer das gerne täte, dürfte es ja zulassen. Nochmal: Es ist ein gewaltiger Unterschied, ob mein Kürzel in einzelnen Themen in Erscheinung tritt - oder ob meine ganze Wikipedia-Historie "brettlbreit" und bis auf die Minute erkennbar jedem präsentiert wird. Ersteres gehört zu einer Information über ein Leamma (wer partout will, darf ja auch anonym texten), Zweiteres ist in allererster Linie eine Information über MICH - und das sollte verhindert werden können. Ich würde der Wikipedia-Datenbank schon zutrauen, nur die Abfragen zu verarbeiten, die direkt über die WP-GUI angestoßen werden, sodass man an die selbe Info wie über 'Beiträge' (also alles) nicht so ohne Weiteres dran kommt. Wenn jemand alle WP-Themen nach meinem Namen manuell durchsuchen will, so soll er meinetwegen damit glücklich werden. Aber Wikipedia selbst sollte hier schon umfassenderen Schutz bieten oder ermöglichen.--VÖRBY 19:13, 9. Mai 2011 (CEST)

Technische Definition von 08/15-User? Wenn das alle sind, die keine andere Möglichkeit als Spezial:Beiträge kennen, ist das möglich. Willst du auch so Sachen wie die API sperren lassen wirds kompliziert (also alle Infomöglichkeiten, nicht nur die „GUI“). -- ✓ ^Bergi 19:29, 9. Mai 2011 (CEST)

Ich kenne mich mit diesen Begriffen nicht so gut aus. Wenn die von mir vorgeschlagene Funktion realisiert und (vom Benutzer) auf 'restricted' gesetzt wäre, sollte die Gesamtübersicht über 'meine Beiträge' nur ich selbst und die Admins abrufen können, die irgendwie für Wikipedia als verantwortlich definiert sind. Was das genau ist, müsste sicher noch genauer definiert werden; ich kenne leider das Benutzer- und Rechtekonzept von WP kaum. Wer z.B. nur 'Sichter' ist, sollte da noch nicht dazu gehören, erst recht nicht, wer kein Sichter ist und überhaupt nicht, wer nur mit IP arbeitet. Der unter API gezeigte Inhalt sagt mir fast nichts; tendenziell denke ich aber, dass diese Liste was Ähnliches ist (gesammelte Infos über MICH) - und deshalb genauso geschützt sein sollte. Wenn ich das richtig sehe, ist das eine DBK-Query (außerhalb WP-GUI); solche Möglichkeiten dürfen in keinem Fall 'öffentlich' ausführbar sein, sondern nur durch die WP-Betreiber. Alles andere wäre m.E. ein Skandal!!! Es sollte der Grundsatz gelten: WP informiert frei über 'Informationen' (Lemmas) und die dazu gehörenden Diskussionen - und zwar über die GUI; 'gesammelte Werke' über Benutzer sind geschützt oder schützbar; Datenbank-Kommandos können nur von technischen Admins des Betreibers (!) aufgesetzt werden. --VÖRBY 21:19, 9. Mai 2011 (CEST)

Das Grundkonzept der Wikipedia verunmöglicht es wohl, dein Anliegen effektiv umzusetzen. Man könnte zwar theoretisch sicher einführen, dass Spezial:Beiträge für Nutzer, die das wünschen, nur z.B. von Admins oder einer anderen definierten Nutzergruppe genutzt werden kann. Jedoch: Die Versionsgeschichten der Artikel existieren weiterhin, und jeder Version ist ein Nutzername zugeordnet, das wird nur schon aus Lizenz- bzw. urheberrechtlichen Gründen so bleiben müssen. Nun kann sich aber jeder, der das will, die ganzen Daten der Wikipedia runterladen, inklusive Versionsgeschichten (das sind halt die freien Inhalte, die Versionsgeschichten müssen lizenzbedingt zur Verfügung stehen) und die dann auch mit einem externen Tool auswerten. Du wirst es also nicht verhindern können, dass sich Nutzer mit entsprechenden technischen Kenntnissen ihr eigenes "Spezial:Beiträge" basteln und dies auch anderen zur Verfügung stellen können. Wenn du nicht willst, dass die Allgemeinheit deine Beiträge zur Wikipedia verfolgen kann, wird dir wohl nichts anderes übrig bleiben, als mit wechselnden IPs oder "Wegwerf-Accounts" zu arbeiten, wobei ich das nicht empfehlen möchte (verboten ist es nicht, solange damit kein Missbrauch getrieben wird). Oder du ziehst dich aus der Wikipedia zurück... Gestumblindi 21:37, 9. Mai 2011 (CEST)

Hallo, wie schon mehrfach gesagt: Es geht NICHT darum, die Userkennung i.Z. mit einzelnen Artikeln, z.B. auch der Versionsgeschichte darzustellen, sondern ganz gezielt vom Benutzer auszugehen und alle dessen Beiträge (d.h.: themenunabhängig dessen Aktivitäten) auszuwerten. Ob jemand die ganze Wikipedia mit eigenen Tools auswerten kann, weiß ich nicht - ich würde auch dies für datenschutzrechtlich bedenklich halten. Das Schutzbedürfnis ist vergleichbar mit der (vorhandenen) Option, sich per e-Mail ansprechen zu lassen oder nicht. Viele Grüße von --VÖRBY 08:38, 10. Mai 2011 (CEST)

Ich glaube, Gestumblindi hat schon verstanden, was du meinst. Um das Ganze noch mal anders zu formulieren: Es gibt bereits mehrerer Editcounter/auswerter, z.B. auf dem Toolserver. Es dürfte daher - mit entsprechenden Kenntnissen - ein leichtes sein, ein Tool zu programmieren, das alle Beiträge eines Autors auflistet, da die Verbindung Beitrag <--> Account wegen der Lizenz zwingend erhalten bleiben muss. Wenn eine derartige Auswertung möglich ist, wird sie früher oder später auch irgendwo zur Verfügung stehen. Und externen Seiten wie z.B. wiki-watch kann man solche Auswertungen wg. der Lizenz auch nicht verbieten. Dein Vorschlag würde es einem 0-8-15-Nutzer also wesentlich erschweren, an eine Auflistung aller Beiträge eines Autors zu kommen, für regelmäßig Nutzer (unter denen auch jetzt schon viele mit externen Tools wie CatScan arbeiten) stellt das kein Hindernis dar. Viele Grüße, Nothere 10:36, 10. Mai 2011 (CEST)

---

Danke für die WP-Aufklärung. Bedeutet das denn, dass es für die Wikipedia keinerlei Schutzmechanismen für das Auswerten der Datenbanken gibt? Dann kann also Jeder (mit Toolkenntnis) die ganze Datenbank auslesen, gesamt oder ggf. über beliebige Keys? Wie gesagt, die Verbindung 'Beitrag --> Account' halte ich nicht für problematisch, wohl aber die umgekehrte Richtung (für Unbefugte). Genau das, was Nothere mit 'wesentlich erschweren' beschreibt, möchte ich verhindern können. Und zwar unabhängig davon, ob die Benutzer technisch versiert sind oder nicht. Kann mir jemand einen Grund nennen, warum "X-beliebige Leute" (s.o.) sehen sollten, WER (als mengenbildender Begriff!) genau wann und genau in welcher Reihenfolge welche Beiträge verfasst oder sonstige Aktionen durchgeführt hat?

Kompromiss: Im Übrigen denke ich, dass es auch schon eine Verbesserung wäre, wenn man diese Möglichkeit nicht jedem Benutzer "auf die Nase binden" würde. Für die 'Technikfreaks' wäre doch der Aufwand zum Finden der Beiträge eines bestimmten Autors (alle Daten downloaden) wohl derart hoch, dass dies eine gewisse Hemmschswelle wäre. Allerdings bin ich mir sicher, dass das unkontrollierte Auswerten der ganzen Datenbank durch Jedermann massiv gegen Datenschutzregeln verstoßen würde - wie auch immer das Grundkonzept von Wikipedia ist. Ich will aber hiermit kein "Fass aufmachen", sondern lediglich einen 'Verbesserungsvorschlag' einreichen. --VÖRBY 13:49, 10. Mai 2011 (CEST)

Was Nothere und Gestumblindi schon gesagt haben wollte ich gestern auch antworten, bin bloß nicht mehr dazugekommen. Dienste wie [1] oder [2] können direkt auf einen Datenbank-Klon zugreifen, und die Betreiber zum Berücksichtigen einer derartigen Einstellung (an die sie eigentlich nicht einmal herankommen sollten, die sind schließlich nicht öffentlich) zu bewegen ist schwierig. Wenn du die Zuordnung Beitrag->Account für unproblematisch hälst, lies dir doch bitte mal Bijektive Funktion und Umkehrfunktion. Einzige Möglichkeit wird wohl sein, GUI-Seiten wie Spezial:Beiträge/VÖRBY oder Spezial:Logbuch/VÖRBY nicht auszugeben und einen Auswertungs-Opt-Out anzulegen, der per API abrufbar ist und von Diensten repektiert werden muss.
meint -- ✓ ^Bergi 15:48, 10. Mai 2011 (CEST)

---

Hallo liebe Mitdiskutanten,

ich hätte ja niemals gedacht, dass meiner 'trivialer' Vorschlag eine solche Diskussion auslösen würde.

Leider kann ich mit euch nicht auf der technischen Ebene diskutieren, denn ich bin ein 'ganz normaler' Wikipedia-Benutzer, der die Anwendung einfach über die angebotene Benutzeroberfläche benutzt und sonst nichts kennt. Allerdings haben mich eure Aussagen über die (offensichtlich unkontrollierten) Zugriffe auf die Daten einigermaßen schockiert. Die Aussagen unter Umkehrfunktion ... mögen mengentheoretisch korrekt sein, datenschutzrechtlich sind die beiden Auswertungsrichtungen total unterschiedlich zu beurteilen.

Ihr habt mehrfach argumentiert, warum dieser Vorschlag nicht umsetzbar sein sollte, und habt dabei auf technische Gegebenheiten (API, Dienste ...) verwiesen. Diese Diskussionen halte ich aber derzeit für unangebracht.

Vielmehr müsste zunächst der Status des Vorschlags überprüft werden. Demnach sollte

• festgestellt werden, ob dieser Vorschlag nützlich ist (z.B. ob ihn auch andere Benutzer für gut halten)
• festgestellt werden, ob er vielleicht sogar im Zusammenhang mit datenschutzrechtlichen Regeln ein 'must' ist.
• Wenn nur 1.) zutreffen würde, hat man mehr Entscheidungsfreiheit - und könnte sich z.B. eine einfache Lösung (mit 'Löchern') vorstellen.
• Bei Zutreffen von 2.) hieße das, es kommt nicht darauf an, ob irgendwelche Dienste oder Funktionen so oder so funktionieren oder nicht funktionieren oder ob Betreiber eine derartige Einstellung berücksichtigen. Vielmehr müsste die Anforderung schlicht und einfach erfüllt werden. Wie dies geschieht, wäre tatsächlich eine Frage der technischen Implementierung.

Mein Fazit wäre:

• Wir beenden auf dieser Ebene die Diskussion.
• Ein Auftrag zur datenschutzrechtlichen Betrachtung wird an in diesem Thema kompetente Leute erteilt.
• Dabei sind auch die umfangreichen Zugriffsmöglichkeiten auf Wikipedia-Daten in die Betrachtung einzubeziehen.
• Ggf. wird danach nur die einfache Lösung implementiert - oder alles bleibt wie es ist.

Vielen Dank für eure engagierte Mitarbeit --VÖRBY 18:09, 10. Mai 2011 (CEST)

Der Hauptgrund dafür, dass dein Vorschlag nicht umsetzbar ist, ist nicht technischer, sondern lizenzrechtlicher Art, das hast du wohl überlesen. Die Inhalte der Wikipedia stehen unter einer freien Lizenz, die unter anderem verlangt, dass die Autoren jeder Version genannt werden. Und wenn die Autoren jeder Version genannt sind, kann man das halt notwendigerweise auch technisch auswerten, da die Daten frei zur Verfügung stehen. Wenn du das ändern wolltest, müsstest du die Wikimedia Foundation in den USA davon überzeugen, eine neue Lizenz zu wählen, was ein riesiges Unterfangen von mindestens jahrelanger Dauer und vermutlich überhaupt unmöglich wäre. Da man hier unter beliebigen und wechselnden Pseudonymen arbeiten kann, die keine Zuordnung zu einer Person erlauben (wenn man sich nicht selbst identifiziert; man muss bei der Anmeldung ja noch nicht einmal zwingend eine E-Mail-Adresse angeben), zweifle ich daran, dass es hier unter datenschützerischen Aspekten ein Problem gibt. Gestumblindi 21:40, 10. Mai 2011 (CEST)

Danke nochmal. Die zuletzt von dir angeführten Möglichkeiten sind sicherlich Gegenargumente zur Existenz eines Datenschutzproblems. Wie schon gesagt, eine einfache Lösung (parameterabhängiges Ausführen der Spezialfunktion) würde aber sicher für 95% aller WP-Benutzer 'greifen' - und das wäre auch schon ein Erfolg. Trotzdem bitte ich dich, mir nochmal die folgenden Fragen kurz zu beantworten:

1. Kann tatsächlich jeder Benutzer (mit entsprechender Toolausstattung) ohne besondere Berechtigungen die ganze WP-Datenbank auslesen? (Was ich ja schon aus Volumensgründen für irre halte).
2. Kann - alternativ - jeder Benutzer eine Selektion auf den gesamten WP-Datenbankinhalt formulieren, durch die er nur eine bestimmte Ergebnismenge (z.B. nur für einen bestimmten Autorennamen) erhält?
3. Wenn ja: Bedeutet das, dass nahezu alle Datenbankkommandos von beliebigen Benutzern aufgesetzt werden können? Oder zumindest alle 'auswertenden' Kommandos (SQL oder ähnlich)? Könnte man damit z.B. auch feststellen, welche Artikel Benutzer X in seiner Beobachtungsliste hat?
4. Welche Voraussetzungen müssen für die Ausführung solcher Funktionen gegeben sein?

Durch Deine Antworten hilfst du mir, mein 'Bild' von der Wikipedia klarer zu machen - in welche Richtung auch immer. Vielen Dank.--VÖRBY 10:46, 11. Mai 2011 (CEST)

Auf dem Toolserver liegt eine Kopie der gesamten Wikimedia-Datenbank, ausgenommen einige private Daten (z.B. gelöschte Versionen und vermutlich auch Sachen wie Beobachtungslisten). Welche Daten jetzt genau nicht gespiegelt werden, weiß ich nicht, da werden sich sicherlich andere Leute mehr dazu sagen können. Außerdem können Dumps heruntergeladen werden, die fast die gesamte (ohne die privaten Daten, s.o.) Datenbank enthalten, z.B. hier. Der Dump mit der gesamten Datenbank ist komprimiert 5GB groß; ihn herunterzuladen und zu verarbeiten ist also für moderne Rechner mit Breitbandinternet eigentlich keine große technische Hürde. Grüße, -- ChrisiPK (Disk|Beiträge|Bewerten) 11:04, 11. Mai 2011 (CEST)

1, 2: ja. 3: eine Auswertung öffentlicher Inhalte ja, schreiben in die Datenbank nein da nur mit (mehr oder weniger Live-) Dumps gearbeitet wird. Öffentlich sind sämtliche (nicht durch Löschung versteckte) Versionen und Logbücher sowie Nutzer-Rechte-Listen: meta:Data Dumps#What's available?

zu 4: nur die Serveradmins haben direkten Zugriff auf die Datenbank und können, wenn sie gebeten werden und wollen, eine statistische Analyse durchführen; einzelne Einstellungen werden sie keinem verraten. Auf dem Toolserver wird die gesamte Datenbank gespiegelt, auch dessen Nutzer können SQL-Queries durchführen (Nutzerdaten sind aber versteckt, da brauchts einen echten Serveradmin). Es gibt beispielsweise ein Tool, welches die Zahl von Beobachtern ermittelt; es wird aber kein Tool geben, das die BEO eines bestimmten Nutzers ausspuckt. -- ✓ ^Bergi 16:36, 11. Mai 2011 (CEST)

PS: Eine Übersicht der auf dem TS verfügbaren Daten gibt es unter tswiki:Database schema, siehe aber auch tswiki:Rules#Special Cases unter der tswiki:Rules#Privacy Policy. -- ✓ ^Bergi 17:24, 11. Mai 2011 (CEST)

---

Hallo zusammen, und Danke für Eure Mithilfe.
So sieht das ja schon mal ganz ordentlich aus:

• Serveradmins gehören nicht zu den Leuten, denen ich den Zugriff verwehren wollte; sie sind berechtigt.
• Auf die Toolserver-Daten hat wohl nicht jeder Wikipedia-Benutzer automatisch Zugang, sondern man muss sich vorher speziell anmelden. Insofern scheint mir die Ja-Antwort zu 1. und 2. relativiert zu sein.

Vielen Dank für die wertvollen Links. Mein "Schutzanliegen" scheint auch in tswiki:Rules#Special Cases die Grundlage gewesen zu sein - wenn dort steht "Counting edits per person per time of day requires consent, because it may lead to conclusions about the user's location or lifestyle." Die Spezial:~Liste je Benutzer sollte eigentlich noch 'privater' sein als so ein Count, aber das könnte man m.E. (wegen des eingeschränkten Benutzerkreises) vernachlässigen.
Insofern reduziert sich mein Verbesserungsvorschlag wieder auf das, was er ursprünglich wollte: Für die "normalen" Wikipedia-Benutzer soll es nur bedingt (Option) oder nicht möglich sein, diese "Spezial:Beiträge" für fremde Benutzer abzurufen. Wenn andere Benutzertypen mit anderen Mitteln an diese Info rankommen, ist das entweder berechtigt oder ein Rest, den man m.E. veranachlässigen kann.*)
(*) Bestätigen könnte man diese Annahme noch mit statistischen Mitteln, z.B.: Wieviele WP-Benutzer gibt es insgesamt? Wie viele davon gehören zu den o.g. 'privilegierten' Benutzern? Wie oft wird Spezial:Beiträge (für sich selbst / für fremde Benutzer) abgerufen? Vielen Dank und Servus von --VÖRBY 19:30, 11. Mai 2011 (CEST), aktuell: --VÖRBY 08:53, 12. Mai 2011 (CEST)

Die Beitragsliste kann schon sehr hilfreich sein, wenn jemand vandaliert, kann man darüber auch die anderen vandalierten Seiten wieder zurücksetzen. Außerdem ist die Beitragsliste auch interessant um herauszufinden, warum jemand eine Bearbeitungen in einer geschützen Vorlage oder Systemnachricht gemacht hat, weil man so die umliegenden Bearbeitungen sieht, und damit auch die Bitte eines Benutzers oder so (Gerne werden Permalinks vergessen).

Statische Fragen lassen sich auf Spezial:Statistik oder auch Wikipedia:Statistik klären. Ich meine, das es eine solche Diskussion schonmal gab, kann sie aber leider nicht wiederfinden. Der Umherirrende 21:14, 12. Mai 2011 (CEST)

Wird aber Vandalismus nicht immer von irgendwie administrativ tätigen Leuten bearbeitet? Vielleicht sollte auch 'Sichtern' diese Funktion erlaubt sein, ich denke, das wäre immer noch ein nur begrenzter Personenkreis, dem seine besonderen Rechte schließlich individuell zugeteilt wurden.

Vielleicht sehe ich aber das ganze Thema 'Beitragsliste' zu kritisch, habe aber in ähnlichen Fällen schon einschlägige Erfahrungen gemacht: Profilaussagen dürfen nicht (unkontrolliert) ableitbar sein.--VÖRBY 10:03, 13. Mai 2011 (CEST)

Nein, Vandalismus kann von jedem Benutzer entfernt werden. Ich glaube, es gibt auch IPs die Vandalismus entfernen. Der Umherirrende 14:39, 13. Mai 2011 (CEST)

"Letzte Änderungen" in tabellarischer/spaltenorientierter Darstellung

Salute zusammen, ich wünsche mir sehr, daß die "Letzten Änderungen" in tabellarischer Darstellung erscheinen, sodaß Artikelname, Änderungszeit, Änderungsautor, Änderungsmenge, Zusammenfassung und die Tags ("Neu", "K", "ungesichtet") jeweils untereinanderstehen. Kann man das vielleicht auch in den persönlichen .js- oder .css-Einstellungen hinbekommen? Wo im MediaWiki-Code wird die Seite angelegt? Grüßken --Robb 16:18, 13. Mai 2011 (CEST)

Schon mal weiterhelfen sollte die Option „Erweiterte Darstellung der „Letzten Änderungen“ (benötigt JavaScript)“ in Spezial:Einstellungen#preftab-4. Ein Javascript, dass die Liste in eine Tabelle umbaut müsste relativ einfach sein. Per CSS gehts auch, aber m.W. nur unter der Bedingung feste Breite und Abschneiden von zu langem. Zur letzten Frage: Glaub mir, das willst du lieber nicht wissen. -- ✓ ^Bergi 19:38, 13. Mai 2011 (CEST)

Diese JS-Einstellung nutze ich schon lange, aber das einzige, was es tabelliert, ist die Uhrzeit. Die Zusammenfassung der Artikel hilft natürlich auch, aber dat isset noch nich so janz. Und: Ja, das will ich wissen. Ich überlege mir schon, ob ich für meine privaten Wikis den Programmieraufwand auf mich nehme. Daher …

Das ganze passiert in SpecialRecentchanges.php. So eine tabellarische Darstellung kann aber schon hilfreich sein, wenn man Spezialseite Spezial:Liste der Sperren in der überarbeiteten Version anschaut, sieht es schon übersichtlicher aus. Der Umherirrende 19:49, 13. Mai 2011 (CEST)

… danke ich Dir für die Quelldatei. Vielleicht können mir ein paar Leute helfen, dann mache ich mich vielleicht an die Arbeit. Grüße zusammen --Robb 00:07, 14. Mai 2011 (CEST)

Nein, das ist bloß die Source die die RC abruft und in eine Liste stecken lässt. Die Liste selbst wird irgendwo hier zusammengebaut (wobei sich m.W. von 1.17 auf trunk einiges geändert hat), vielleicht hilft das hier weiter. Die „erweiterte“ Liste ist als EnhancedChangesList implementiert. Wenn du also nicht gerade HardCore-Entwickler bist, würde ich dir raten einfach einen weiteren Bug aufzumachen. JavaScript bastele ich gerne mit. -- ✓ ^Bergi 18:50, 14. Mai 2011 (CEST)

Scheint phab:T30446 (Bugzilla:28446) zu sein. Der Umherirrende 21:46, 15. Mai 2011 (CEST)

Mehr englische artikel auch auf deutsch zeigen.

Meine bitte ist es, Artikel wie zum Beispiel "Magic: The Gathering storylines" auch auf deutsch zu zeigen, da durch zb. google Übersetzer die Artikel Grammatikalisch so falsch werden, dass sie kaum zu verstehen sind und in Englisch viel mehr Artikel über "Magic: The Gathering" existieren als in Deutsch. Es würde mich freuen, denn sonst sitze eich unzählige Abende daheim und übersetze mir selbst jene Artikel. (nicht signierter Beitrag von 84.145.192.100 (Diskussion) 23:25, 9. Aug. 2011 (CEST))

Sorry, aber auf dieser Seite bist du mit deinem Anliegen falsch. --Leyo 23:38, 9. Aug. 2011 (CEST)

Genau. Sag ihm nicht, auf welcher Seite er mit seinem Anliegen richtig wäre. --Sunks 08:38, 10. Aug. 2011 (CEST)

Wenn du die Artikel dann übersetzt hast, darfst du sie gerne bei uns veröffentlichten, damit auch andere etwas davon haben. Gruß, --Flominator 09:12, 10. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 17:27, 12. Aug. 2011 (CEST)

Zusätzlicher Link auf Diskussionsseiten – Abschnitt neu

Vorschlag: Auf Diskussionsseiten sollte statt [Bearbeiten] neben der letzten oder allen Überschriften erscheinen: (Abschnitt: [Bearbeiten] [Neu]) oder: [Bearbeiten] [Neuer Abschnitt]

Das vermeidet viele unpassende automatische Bearbeitungskommentare, übernommen vom letzten Abschnitt. Oft wird der letzte Abschnitt bearbeitet, um einen neuen Abschnitt zu erstellen. --Diwas 18:39, 22. Jul. 2011 (CEST)

Mich stört das auch sehr, vor allem wenn ich meine Beobachtungsliste unterwegs via Smartphone als RSS-Feed abrufe. Eine Alternative wäre vielleicht, einen entsprechenden Markierungfilter einzurichten (Beispiel aus der en-WP). --Leyo 19:08, 22. Jul. 2011 (CEST)

Ich finde es auch immer verwirrend, wenn das passiert. Vorallem verstehe ich nicht so ganz, was die Benutzer machen: Sie gehen auf die Diskussionsseite, scrollen händisch/per Tastatur nach unten und klicken dann auf Bearbeiten der letzten Überschrift, setzten die == == selber und speichern. Schneller sollte es eigenltich gehen, wenn man nur auf die Seite geht und oben das +/Abschnitt hinzufügen klickt. Aber falls ich mal wirklich am Ende der Seite bin, weil ich dort gelesen habe, habe ich mir per JavaScript links unter der Sidebar (Monobook) auf höhe der Kategorien einen entsprechenden Link gesetzt. Sehr praktisch. Der Umherirrende 19:36, 22. Jul. 2011 (CEST)

Ausnahmsweise editiere ich auch den letzten Thread und schreibe neue Überschrift, dann aber mache ich mir schon die Mühe und ersetze in der Zusammenfassung die alte durch die neue Überschrift - machen aber wohl die wenigsten. -jkb- 19:47, 22. Jul. 2011 (CEST)

Ich habe das auch schon mal gemacht, wohl eher versehentlich, aber den Kommentar sollte man dann korrigieren. Oft wird sogar ein Kommentar eingegeben, aber die falsche Abschnittsangabe übersehen – oder für unabänderlich gehalten? Standardmäßig ein Link links neben den Kategorien oder unter dem Seiteninhalt könnte auch helfen. Oder eine nach unter gespiegelte Wiederholung der ganzen Registerkarte, was wohl zum Teil auf deutliche Ablehnung stoßen würde.--Diwas 00:33, 23. Jul. 2011 (CEST)

Hmmm, was ist eigentlich ein Thread? Muss ich mich schämen, wenn ich das nicht weiß?--der Pingsjong 22:21, 23. Jul. 2011 (CEST)

Strossenbau im Braunkohlentagebau

sorry, s. Thread (Internet), Gruß -jkb- 23:35, 23. Jul. 2011 (CEST)

Lach, ich hätte das Strossenbau genannt. Glückauf--der Pingsjong 11:04, 24. Jul. 2011 (CEST)

Redirects automatisch purgen

Ich finde es sehr störend wenn ich mit Smartphone unterwegs bin und bei Disks oder Organisationsseiten Abkürzungen benutze. Denn da ist (ich bin da ja unangemeldet) die Zielseite ja immer uralt. Selbst wenn ich immer alles purge und beim nächsten Mal reingehe erwische ich einen uralten Servercache und muss alles purgen. Mein Vorschläg wäre bei Redirects automatisch Redirect und Zielseite aus dem Servercache zu löschen und wie immer auf die nun gepurgte Zielseite geleitet werden. --IWorld – @ 10:02, 24. Jul. 2011 (CEST)

Dem ist eigentlich so, aber da gibt es noch ein Problem, siehe phab:T31552 (Bugzilla:29552). Der Umherirrende 13:20, 24. Jul. 2011 (CEST)

Ich verstehe nicht den Sinn/Frage des Bugs. Vorlage:Smiley/Wartung/:s  --IWorld – @ 14:29, 24. Jul. 2011 (CEST)

Der Bug wird erst ab comment 4 interessant, wo die Ursache für das beschriebende Verhalten genannt ist. Das beschriebende Verhalten ist meiner Meinung nach das gleiche wie bei dir, daher habe ich ihn verlinkt. Der Umherirrende 18:34, 25. Jul. 2011 (CEST)

Anzeige von Referenzen/Fussnoten beim Bearbeiten von Abschnitten

Beim einzelnen Bearbeiten von Abschnitten/Unterkapteln werden keine Referenzen angezeigt - es sei denn, man fügt für die Vorschau manuell den Referenzen-Tag ein, den man vor dem Abspeichern natürlich wieder zu entfernen hat.

Frage: liesse sich das nicht besser so einrichten, dass bei der Vorschau eines Abschnitts automatisch die im Abschnitt eingebundenen Referenzen angezeigt werden, ohne manuell für die Vorschau den Tag einzufügen, der vor Abspeichern wieder zu entfernen ist? --ProloSozz 13:03, 12. Feb. 2011 (CET)

Es gibt VirtualReferences.js von ParaDox, das genau das macht. -- ✓ ^Bergi 18:37, 19. Feb. 2011 (CET)

Ich fände es begrüßenswert, wenn dieses, prinzipiell jeden Nutzer betreffende, Problem auch für jeden Nutzer gelöst würde. Das VirtualReferences JavaScript ist keine solche Lösung, da nur angemeldete Benutzer es verwenden können (ich als angemeldeter Nutzer habe es mir nun installiert und bin sehr zufrieden, aber eine IP, oder Nutzer die es nicht finden oder mit der Installation nicht klarkommen schauen in die Röhre -bzw. nicht auf die Fußnoten in der Vorschau). Weitere Kritikpunkte sind die eingeschränkte Browser-Kompatibilität, eingestelle (Weiter-) Entwicklung und die Abhängikeit von der Existenz dieser Benutzer-Seite. Grüße, --Qaswed 17:07, 7. Jun. 2011 (CEST)

Ich wollte gerade den selben Vorschlag wie ProloSozz machen, da mir hier öfter mal vermeidbare Fehler passieren. Auch ich wünsche mir ein Feature, dass zumindest allen registrierten Benutzern als Helferlein zur Verfügung steht, welches über die Benutzereinstellungen aktiviert werden kann. --TETRIS L 10:47, 27. Jul. 2011 (CEST)

Automatisches <references />

Es gibt ja die Fehlermeldung Referenzfehler: Einzelnachweisfehler: <ref>-Tags existieren, jedoch wurde kein <references />-Tag gefunden. Warum setzt diese Meldung nicht gleichzeitig ein dynamisches <references />?--131.159.0.7 01:18, 12. Jul. 2011 (CEST)

Kennzeichnung von animierten Bildern

Symbol für Animation?

Aus Gründen der Performance zeigt MediaWiki in den Vorschaubildern (auch bekannt als Miniatur) nicht mehr alle Animationen an. Damit nun der Leser erkennen kann, das es sich um ein animiertes Bild handelt, sollte es auch irgendwie markiert werden. --217.94.119.79 20:27, 14. Feb. 2011 (CET)

Ich habe mal phab:T30253 (Bugzilla:28253) erstellt. Der Umherirrende 17:48, 26. Mär. 2011 (CET)

Gemeint sind wohl jene in commons:Category:Animated_gifs_exceeding_the_12.5MP_limit die mehr als 12.5 MP total (width x height x number of frames) haben, aber kleiner, als die Standardvorschaugröße (800×600) sind, so dass sie auf der Vorschauseite nicht skaliert werden müssen. Ich denke nicht, dass hier eine Aktion nötig ist - gifs sollten soweit wie möglich vermieden werden, lenken sie doch maßlos vom Text ab, weil sie direkt loslaufen - finde ich zumindest. → Commons:Video. Übrigens ist in der Mache, dass auch gifs größer als 12.5 MP skaliert werden können, soweit ich das mitbekommen habe. Viele Grüße --Saibo (Δ) 12:03, 27. Jul. 2011 (CEST)

Eine Sicherheitsabfrage vor dem Speichern einer Seite wäre vielleicht sinnvoll.

Mir fehlt beim Speichern einer Seite (Artikel oder Diskussion) eine zusätzliche "obligatorische" Sicherheitsabfrage oder Bestätigung nach dem "Drücken" des Befehls "Seite speichern" Eine Sicherheitsabfrage könnte beispielsweise wie folgt sein: "Bist du dir sicher? Deine Bearbeitung wird (fast) unwiderruflich gespeichert oder willst du nochmal zurück zur Bearbeitung der Seite?" Bei der Seite Diskussion könnte – gegebenenfalls - auch noch folgender Warnhinweis gezeigt werden: "Deine Unterschrift am Ende deines Beitrags fehlt. Bitte füge deine Unterschrift ein, ansonsten kann dein Beitrag nicht gespeichert werden" Ich vermute mal, mit diesen Sicherheitsabfragen könnte jede Menge Datenmüll vermieden werden. Insbesondere würde dadurch die "Versionsgeschichte" möglicherweise weniger aufgebläht.--Corvax 22:27, 5. Jun. 2011 (CEST)

Hallo Corvax, das wäre aber sofern standardmässig extrem aufwändig für Bearbeiter, die viel mitarbeiten. Die Sache mit der Signatur wäre zudem schwer implementierbar, denn man ergänzt ja oft einen bereits bestehenden Kommentar, setzt nur einen Hinweisbaustein oder Ähnliches. Grüße, —Pill (Kontakt) 22:34, 5. Jun. 2011 (CEST)

"Extrem aufwendig" wäre eine Sicherheitsabfrage kaum. Bis jetzt erfordert die Ausführung des Befehls "Seite speichern" einen einzigen linken Mausklick. Bei meinem Vorschlag wären es zwei Mausklicks, wobei beim zweiten Mal der Mauszeiger noch auf die entsprechende Befehlsschaltfläche bewegt werden müsste. Davon bekommt noch niemand einen Tennisarm! Ob das Problem mit der Unterschrift bei einem Edit beim Beitrag:Diskussion zu lösen wäre, kann ich – mangels Softwarekenntnis – nicht beurteilen

Ich persönlich halte die Hemmschwelle für das endgültige Absenden einer Seite für zu gering. Eine höhere Hemmschwelle würde ungewolltes Speichern verhindern und zusätzlich würde so mancher vielleicht nochmal ins Grübeln kommen, ob sein Beitrag nicht doch noch etwas besser werden könnte. Ich denke, der Mausaufwand mit einem zusätzlichen zweiten Klick wäre noch angemessen und ertragbar.

Mir wird übrigens der direkt davorstehende Beitrag (Pill, 22:34, 5.Jun. 2011) nicht angezeigt. Erst in der Versionsgeschichte kann ich den Beitrag erkennen. Vielleicht hat Wiki sogar selber ein Problem mit der Verstopfung durch Datenmüll.--Corvax 19:15, 6. Jun. 2011 (CEST)

Hallo Corvax, wenn man wie eine nicht geringe Zahl von Nutzern 50 und mehr Beiträge an einem Tag tätigt, ist das, finde ich, schon auch ein "Aufwandsfaktor". Insbesondere ist es aber ein Störfaktor. Persönlich gesprochen würde es mir sehr auf die Nerven gehen, wenn ich, nachdem ich meinen Beitrag nochmal durchgelesen habe und ggf. die Vorschau bemüht habe, noch einmal bestätigen müsste, dass ich auch wirklich den Beitrag absenden möchte. Und wenn das von dir angeregte Feature implementiert wäre, würde ich ganz sicher meinen Beitrag nicht noch einmal überprüfen, sondern stattdessen einen Weg suchen, die Zwischenabfrage schnellstmöglich "wegzuklicken"; der erhoffte Effekt bliebe vollends aus. Zudem sehe ich das von dir angesprochene Problem des Datenmülls nicht wirklich. Wenn ein Nutzer auf einer Diskussionsseite oder auch in einem Artikel zwei oder drei Versionen braucht - wen stört das denn? Hinsichtlich des Speicherplatzes bestehen keine Schwierigkeiten und mittels entsprechender Bearbeitungskommentare ("korr.", "präziser" etc.) ist auch in der Versionsgeschichte der Hintergrund ersichtlich. Und "übertreibt" es ein Nutzer damit doch einmal, kann er mit einem Hinweisbaustein (, dessen Namen ich leider vergessen habe,) auf seiner Diskussionsseite auf die Vorschaufunktion hingewiesen werden. Grüße, —Pill (Kontakt) 19:58, 6. Jun. 2011 (CEST)

Hi Pill, zunächst mal sind wir nur zu zweit, die hier Interesse zeigen. Wenn das Thema hier nicht mehr Beachtung findet, wird es sowieso verdursten. Wir gehen von unterschiedlichen Anforderungen aus. Du bist ein "Vielnutzer" und dir deiner Sache anscheinend sicher. Doch es gibt auch jede Menge Gelegenheitsnutzer (so wie ich), die ohne es zu wollen oder unüberlegt schnell mal was speichern. An die habe ich eher gedacht. Ein Vorschlag zur Güte: Die "Sicherheitsabfrage" sollte zunächst obligatorisch sein und für Benutzer mit einem bestimmten Level (beispielsweise 100 Bearbeitungen) optional in den Benutzereinstellungen abschaltbar sein. --Corvax 20:37, 6. Jun. 2011 (CEST)

In den Einstellungen existiert doch bereits die Möglichkeit, sich auf alle Fälle eine Vorschau anzeigen zu lassen. Den Hinweis auf die fehlende Signatur kann man sich per Helferlein zuschalten (Benutzerskript), es gibt aber auch hier Edits bei denen das stören würde. Eine Verpflichtung würde ich ablehnen.--✓ ^Bergi 22:02, 6. Jun. 2011 (CEST)

Ganz abgesehen davon, dass es schon häufig diskustiert - und abgelehnt wurde. -jkb- 22:06, 6. Jun. 2011 (CEST)

Kann mich nur anschließen in der Beurteilung, dass dies bei Arbeiten, die über einer Korrektur hier und da hinaus gehen, stören würde. Es gibt ja Sprachversionen, die standardmäßig dies haben. Und da nervt es! ;-) --JPF just another user 23:30, 6. Jun. 2011 (CEST)

Gibt es schon eine Sprachversion mit so einer Abfrage? Ich glaube du verwechselst das mit der leeren Zusammenfassungszeile, die beim Speichern gefüllt werden sollte (WP:EZ). Ansonsten wäre ein Link hilfreich, um mal zu schauen. Der Umherirrende 21:49, 7. Jun. 2011 (CEST)

Was spricht hier dagegen: die "Sicherheitsabfrage" ist in der Grundeinstellung vorhanden und kann jederzeit über die Benutzereinstellung ausgeschaltet werden. Dadurch wird niemand bevormundet und jeder kann das wählen was er persönlich für seine Bedürfnisse am geeignetsten hält. PS: Ich kann die letzten Beiträge immer erst nach dem Aufruf der Versionsgeschichte sehen!!!--Corvax 18:50, 7. Jun. 2011 (CEST)

Dafür! (einstellbar) --Diwas 12:48, 27. Jul. 2011 (CEST)

MathML

Gibt es noch Hoffnung, dass sich die absolut unwürdige TeX-Umsetzung hier mal ändert, und zwar in MathML? -Engeltr 17:12, 26. Jul. 2011 (CEST)

Nein, siehe auch [3] ff. --Schnark 10:17, 28. Jul. 2011 (CEST)

Bis dahin kannst du MathJax verwenden; wurde auch in dem Kommentar erwähnt. --✓ ^Bergi 11:47, 28. Jul. 2011 (CEST)

MediaWiki Light

Ich bin langzeitarbeitslos und lebe von Hartz 4. Das bedeutet: Ich habe wenig Geld, aber viel Zeit. Letzteres ist ja eine gute Voraussetzung für die Mitarbeit an Wikipedia, aber ersteres leider nicht.

Ich habe zuhause einen alten Computer ohne Internetanschluss. (Irgendwo muss man ja sparen.) Ich gehe einmal in der Woche für eine halbe Stunde ins Internetcafe. Damit mein Aufenthalt dort nicht zu teuer wird, bereite ich ihn zuhause vor. Ich schreibe meine E-Mails zuhause, so dass ich sie im Cafe nur noch kopieren, einfügen und abschicken muss. Wenn ich bei Wikipedia Informationen suchen will, mache ich mir zuhause eine Stichwortliste, die ich im Cafe abarbeite. Wenn ich einen Artikel gefunden habe, der mich interessiert, kopiere ich ihn und lese ihn zuhause.

Nun würde ich gerne bei Wikipedia aktiv mitarbeiten, und zwar in der beschriebenen Arbeitsweise.

Dafür wäre es günstig, wenn es ein Programm geben würde, das einem beim Formatieren des Quelltextes hilft und das eine Vorschaufunktion hat. Ist es für die Programmierer möglich, aus dem riesigen MediaWiki-Programm diese wenigen Programmteile herauszunehmen und daraus ein eigenes Programm zu machen? Es wäre also sozusagen ein MediaWiki Light, es wäre ein kleiner Quelltexteditor. Wäre das machbar?

(Irgendwo in der Hilfe wird beschrieben, wie man die gesamte Datenbank herunterlädt, seinen Computer zuhause in einen Server umfunktioniert usw. usf. Das kommt hier nicht infrage, denn die Hardware und Software, die mir zur Verfügung steht, sind viel zu alt. Ausserdem ist das auch alles viel zu kompliziert.)

Allerdings stellt sich die Frage, ob es für so ein Programm eine Zielgruppe gibt. Vielleicht gibt es ja zuwenige Leute in meiner Lage, so dass es sich schon deshalb nicht lohnt, so einen Offline-Editor zu machen. Was meint ihr?

-- 93.205.181.156 17:35, 8. Jul. 2011 (CEST)

Sooo riesig ist das komplete MediaWiki nun auch nicht, schlappe 300 MB. Bietet dann allerdings eine komplette Umgebung wie hier - etwaqs wie"light" gibt es von MediaWiki nicht. Die Installation, falls man nur das Wiki will, nicht hier die ganze Datenbank (unsinnig), ist auch nicht schwierig - schau mal unter Hilfe:MediaWiki lokal und einfach (und sage Bescheid, falls da irgendwo unsinn steht). Gruß -jkb- 17:48, 8. Jul. 2011 (CEST)

Hat dann allerdings den Nachteil, dass Wikipedia-spezifische Vorlagen nicht funktionieren bzw. erst ins lokale Wiki importiert werden müssen. --Church of emacs D B 11:54, 16. Jul. 2011 (CEST)

Der OpenOffice Writer bietet den Export ins MediaWiki-Format an, das habe ich mal angetestet, ist aber schon länger her. Vielleicht hilft das? --Benutzer:Usquam ^Disk.vormals Atlan da Gonozal 21:29, 14. Jul. 2011 (CEST)

Du könntest übrigens mal bei Wikimedia Deutschland anfragen. Die wollen afaik demnächst in Berlin und ggf. auch anderen Städten Community-Spaces einrichten, wo sich regelmäßige Wikipedia-Autoren treffen können um an Artikeln zu arbeiten. Vielleicht gibt es so eine Möglichkeit mitzuarbeiten. Grüße, --Church of emacs D B 11:58, 16. Jul. 2011 (CEST)

Hier gibts ein leeres Wiki zum Download. Ganz einfach zum installieren. Da brauchst du keinen Server einrichten oder so. Wenn du die "Education"-Version nimmst, ist alles schon vorkonfiguriert. SteMicha 12:01, 6. Aug. 2011 (CEST)

Position der Kategorielinks auf Kategorieseiten

In einer Kategorie werden ja Unterkategorien in einem eigenen Bereich vor den Artikeln aufgeführt. Kategorielinks, die ja faktisch die Oberkategorien sind, werden wie in Artikeln in einer Fußzeile geführt. Für Leser und Neulinge ist das aber nicht intuitiv, Katlinks sollten stattdessen lieber einen äquivalenten Bereich "Oberkategorien" oben zwischen Kategoriebeschreibung und Unterkategorien erhalten.--141.84.69.20 16:02, 7. Aug. 2011 (CEST)

Verschiedene Artikelversionen (Länge/Anspruch)

Moin!

Kurzbeschribung des Vorschlages: Es existieren beispielsweise neun Versionen eines Artikels, die über eine 3x3-Matrix abgerufen werden können, wobei die Spalten die Artikellänge bestimmen (sehr kurze Version für schnellen Überblick / normale Version / sehr ausführliche, lange Version), und die Zeilen den Anspruch (Laien- und kinderfreundliche Version / normale Version / Expertenversion).

Motivation: Wenn ich beispielsweise nur einen schnellen Überblick über die wesentlichen Grundmerkmale von etwas ansehen will, empfinde ich es demotivierend, einen seitenlangen Artikel vorzufinden. Der Einleitungsabschnitt ist jedoch in den wenigsten Fällen zur Informationsbeschaffung ausreichend gestaltet. Eine weitere störende Sache fällt mir oft bei mathematischen Artikeln auf: Diese sind in der Regel so gestaltet, dass man sie als Nichtmathematiker nur schwer verstehen kann, auch von mir als Ingenieursstudenten.

Beispielausführung:

Zu diesem Artikel existieren verschiedene Versionen:

	Kurz	Normal	Ausführlich
Kinderversion	Link zu Version 1	Link zu Version 2	Link zu Version 3
Normale Version	Link zu Version 4	Link zu Version 5	Link zu Version 6
Expertenversion	Link zu Version 7	Link zu Version 8	Link zu Version 9

Natürlich wird es bei einer Vielzahl der Artikel aufgrund des Arbeitsaufwandes nicht möglich sein, alle neun Versionen zu erstellen, und bei einigen Themen (z.B. Musikgruppen) machen Versionen verschiedenen Anspruchs wenig Sinn, aber bei wissenschaftlichen Themen durchaus. Standardmäßig sollte die "mittlere" Version angezeigt werden, um das unkomplizierte Erlebnis der Informationsbeschaffung nicht zu beinflussen.

Was haltet ihr von dem Vorschlag? Gruß, JeanBier 00:35, 16. Aug. 2011 (CEST)

Das wäre selbst mir viel zu aufwändig in der Pflege und Erstellung. Selbst falls eine Software und entsprechender Syntax dem Ganzen viele Redundanzen nehmen würde, müsste vieles neunfach erstellt werden. Und dann gibt es Diskussionen was wie in welche der neun VersionenVarianten kommen soll. Dann werden Sätze von Variante zu Variante verschoben. Eine Kinderversion wurde vor einem Jahr im Wikipedia:Meinungsbilder/Kinderseiten abgelehnt. Überlegen könnte man, ob es zu sehr langen Artikeln oder welchen deren Inhalte nicht umfassend, kurz und verständlich dargestellt werden können, einen Einfach-Artikel geben soll, der inhaltlich verschlankt, möglichst kürzer, (Es muss ja mehr erklärt werden) aber unbedingt allgemeinverständlicher wäre. --Diwas 01:22, 16. Aug. 2011 (CEST)

Ich halte den Ansatz für eine gute Idee. Ich würde das aber nicht mit unterschiedlichen Artikeln machen, sondern einfach Teile der Seite ausblenden oder austauschen. Damit könnte man auch das Oma Problem erschlagen. Es sollte also alles innerhalb der Seite bleiben. Es müssen ja nicht Kinder sein, sondern auch Fachfremde. Mir schwebt vor, das sich jeder in WP so etwas wie Skilllevel geben könnte. Ja nachdem wie er Alterstufe und Erfahrungen in einiger Gebieten (so was wie die Schulnoten) hat, bekommt er als Basis nur den Rumpfartikel zu sehen und kann dann weitere Informationen/Abschnitte/Details ausklappen. Rjh 07:26, 16. Aug. 2011 (CEST)

Bei kurzen Artikeln könnte man stattdessen einfach eine einfache Erklärung vorweg und eine tiefergehende fachsprachliche darunterschreiben. Lange Artikel werden dabei so oder so noch umfangreicher und aufwändiger und schwieriger zu bearbeiten. Wichtiger finde ich, dass das Fachbegriffe übersetzt und oder verlinkt werden und dort alle Einleitungen das Lemma allgemeinverständlich grob erklärt werden. Wie gesagt, eine zusätzliche Variante könnte klappen. Habt ihr euch mal überlegt, was es bedeutet zu jedem Artikel 8 – in Worten: Acht – zusätzliche Artikeltexte zu erstellen und vor allem zu pflegen? Sollen die Diskusionen dazu dann auf einer Diskussionsseite oder auf neun einzelnen Diskussionsseiten geführt werden? --Diwas 11:59, 16. Aug. 2011 (CEST)

Neun Versionen halte ich für erheblich zu viel und unmöglich zu pflegen. Aber 2 Versionen, eine ausführliche und eine gekürzte "Überblicksversion", könnte ich mir vorstellen. --Kronf @ 15:44, 16. Aug. 2011 (CEST)

Völlig unabhängig davon was ich vom Vorschlag (nicht) halte: Falsche Seite. Da es kein technischer Wunsch ist, gehört die Diskussion entweder auf die Projektdiskussion oder die Verbesserungsvorschläge. Solltet ihr also weiterdiskutieren wollen, verschiebt doch bitte erst den Thread. --✓ ^Bergi 21:41, 17. Aug. 2011 (CEST)

Als Abwandlung früherer Ideen erinnere ich an die Notwendigkeit, die Artikeltiefe (Kurz/Normal/Ausführlich) so einzurichten, daß Lösch-Blockwarte nicht länger Inhalte rausschmeißen dürfen, die nach deren egozentrischen Bewertungen nicht in die Wikipedia gehören. Anders gesagt: Diese Artikel-Einteilung sollte so beschaffen sein (durch Kriterien oder ein zusätzliches Level), daß von Lösch-Profis bekämpfte Inhalte eine Chance haben. Außerdem ist zu überlegen, ob man diese Funktion nicht mit folgender Überlegung verknüpft: [4]. --Robb 22:41, 17. Aug. 2011 (CEST)

Signatur abhängig vom Namensraum

Lange, mit Bildern oder CSS aufwendig gestaltete Signaturen oder solche mit irgendwelchen Statements oder einem mehrere Zeilen ausfüllen Quelltext können Leser, Neulinge umd OMAs verwirren. Daher sollte auf direkt enzyklopädierelevanten Seiten IMHO nur die einfache Signatur verwendet werden. Dies betrifft Artikel und Kategorien (innerhalb von Bausteinen wie QS, LA, …) oder Dateibeschreibungsseiten. Diskussionsseiten aller Art wären nicht betroffen.
Daher schlage ich vor, die Möglichkeit zu schaffen, dass je nach Namensraum ~~~~ durch die individuelle Signatur oder die Standardsignatur ([[Benutzer:{{subst:REVISIONUSER}}|]] ~~~~~) ersetzt wird. --Leyo^± 21:18, 14. Jul. 2011 (CEST)

Besser fände ich zwei Maßnahmen: a) Signaturen unauffälliger gestalten (vgl. auch MB). b) Im ANR sparsam mit Signaturen umgehen. SLAs, LAs und QS dürfen meinetwegen Signauren enthalten, längerfristige Bausteine wie Vorlage:Lückenhaft oder Vorlage:Redundanz sollten eher nicht. --Church of emacs D B 11:51, 16. Jul. 2011 (CEST)

Auf das MB kann man natürlich immerwieder hinweisen. Aber prinzipiell ist eine Signatur bei Wartungsbausteinen im ANR recht sinnvoll, und die sollte inder Tat möglichst einfach sein, sprich standard/default. +1, -jkb- 11:55, 16. Jul. 2011 (CEST)

 Pro -- πϵρήλιο(℗) 13:52, 16. Jul. 2011 (CEST)

Die Möglichkeit gibts doch: Signatur-Vorlage im BNR anlegen, die gesubstet wird. Da kannst du per VP nach Seiten filtern. @perelion: deine sig ist übrigens optisch seeehr kräftig und ziemlich unleserlich, das solltest du vielleicht ein bisschen zurückfahren. --✓ ^Bergi 17:51, 16. Jul. 2011 (CEST)

Bergi, das beruht aber auf Einsicht und Freiwilligkeit. Eine Standard-Unterschrift im ANR sollte per Software erzwungen werden, nur so funktioniert es. -jkb- 17:59, 16. Jul. 2011 (CEST)

Alles klar, ich persönlich habe das jetzt skriptmäßig gelöst (ist mir gar nicht aufgefallen dass meine sig zu krass sein soll, jedenfalls jetzt entkräftet). -- πϵρήλιο (℗) 22:06, 16. Jul. 2011 (CEST)

Danke, viel besser :) --✓ ^Bergi 19:17, 19. Jul. 2011 (CEST)

Revisionuser wäre machbar. wenn es dafür einen Konsens gibt. Alles was Änderungen in der Software verlangt halte ich eher für unrealistisch. --Church of emacs D B 10:57, 17. Jul. 2011 (CEST)

Magst du die Aussage im ersten Satz noch etwas genauer erläutern? Meinst du, dass je nach NR ~~~ beim Speichern dadurch ersetzt wird oder dass beim Klick auf den Signaturbutton oben genannter Code eingesetzt wird? --Leyo 11:02, 17. Jul. 2011 (CEST)

Man könnte bei einzelnen Vorlagen, die im ANR verwendet werden, eine manuelle Signatur einbinden. Diese wird automatisch zu einem schlichten Benutzername + Zeitstempel, unabhängig davon was die konfigurierte Signatur des Benutzer ist. Probier mal {{subst:Benutzer:Church of emacs/Testseite}} aus (Vorlagencode), diese Vorlage sollte das erledigen. Grüße, --Church of emacs D B 11:25, 24. Jul. 2011 (CEST)

Ich gehe hier natürlich als gutes Beispiel voran. Jetzt noch die angesprochene IF-Abfrage(n) für die Namensräume rein und die Vorlage ist fertig!? -- πϵρήλιο ℗ 15:38, 24. Jul. 2011 (CEST)

Der entsprechende Code lässt sich nicht einfach für ganze Namensräume aktivieren. Man muss ihn in jede Vorlage einzeln einfügen, also z.B. in Vorlage:Löschantrag, in Vorlage:QS, usw. Problematisch ist dabei, dass sich dabei die Vorlagenparameter ändern (da die Signatur nicht mehr manuell im Parameter angegeben werden muss), was etliche User-Skripte kaputt machen würde. (z.B. haben einige Benutzer ein Skript, was automatisch den QS-Baustein in einen Artikel einfügt. Würde man die Vorlage ändern, dann müsste man auch sämtliche Skripte anpassen) --Church of emacs D B 15:51, 24. Jul. 2011 (CEST)

Danke. Ja, das ist der Grund, weshalb ich eine Mediawiki-Lösung für am zuverlässigsten halte. --Leyo 14:50, 25. Jul. 2011 (CEST)

Eigentlich müsste es funktionieren, wenn man als Signatur etwas wie {{ers:#if:{{ers:NAMESPACE}}|aufwändige Signatur|schlichte Signatur}} (ich hoffe, die ers: reichen aus, damit das Zeug nicht im Quelltext auftaucht) einstellt. --Schnark 09:17, 19. Jul. 2011 (CEST)

Ja, das habe ich auch schon vorgeschlagen. Hier wird aber diskutiert, ob das eine Softwarefunktion werden soll, die für alle gilt. Ich sehe drei Möglichkeiten:

• Anpassen der Vorlagen mit automatischer Unterschrift, was natürlich nur mit subst-Bausteinchen funktioniert
• Anleiern einer MediaWiki-Funktionalität, deren Umsetzung ich aber wie Church of emacs für wenig realistisch halte (zu viel Widersprüche, v.a. von anderen Wikis) und die zu lange dauert
• Common.js mit entsprechender Funktionalität ausstatten. Ist aber ebenso häßlich gelöst wie einfach aushebelbar.

--✓ ^Bergi 19:17, 19. Jul. 2011 (CEST)

Ich hatte mir am ehesten die Option mit der MediaWiki-Funktionalität vorgestellt… --Leyo 19:22, 19. Jul. 2011 (CEST)

Daran glaube ich auch nicht, siehe phab:T10458 (Bugzilla:8458) (Rob Church, schon etwas her) dort äussert man, dass Signaturen eine relative Nebensächlichkeit sind und keinerlei Erweiterungen möchte (wobei mw:Liquid Thread bald kommt?). Hier gab es auch schonmal einen ähnlichen Ansatz: phab:T7645 (Bugzilla:5645). -- πϵρήλιο ℗ 03:13, 20. Jul. 2011 (CEST)

Wäre es denn aufwändig zu implementieren? --Leyo 11:13, 27. Aug. 2011 (CEST)

Vorlage Fjorde

Könnte jemand etwa nach dem Muster der "Vorlage Flüsse" eine Vorlage für Fjorde kreieren? Wäre fein. Danke.Reykholt 11:08, 14. Aug. 2011 (CEST)

Das ist der falsche Ort, richtig wäre die Vorlagenwerkstatt. Zum Lemma: Bitte Vorlage:Infobox Fjord (Singularregel). Zum Kreieren: Das schaffst du auch selbst! Wenn du vom Quelltext der Vorlage:Infobox Fluss ausgehst, Hilfe:Vorlagen und die Anleitung zum Erstellen einer Infobox durchliest sollte das kein Problem sein. Bei Schwierigkeiten sowie bei Fertigstellung kannst du dich natürlich trotzdem an die Werkstatt wenden, dann können wir falls nötig eingreifen. --✓ ^Bergi 12:14, 14. Aug. 2011 (CEST)

Bei neuen Infoboxen bitte grundsätzlich vorher in einem geeigneten Projekt (z.B. Wikipedia:WikiProjekt Geographie) diskutieren, ob das überhaupt gewünscht wird. Ansonsten kann es leicht zu einer Löschung einer mühsam erstellten Box kommen. Viele Grüße --Orci Disk 16:53, 31. Aug. 2011 (CEST)

Einzelnachweise / Referenzen mit CSS3 spaltenweise anzeigen

Bei der englischen Wikipedia werden die Einzelnachweise mit der CSS3-Angabe column-count spaltenweise angeordnet. Besonders bei einer VIelzahl von Einzelnachweisen ist diese Art der Darstellung einfach übersichtlicher. -- Nightfly85 _Disk 12:31, 31. Aug. 2011 (CEST)

Das problem ist, dass der IE9 (und früher) dieses CSS3-Ding noch nicht unterstützen. Aktuell ist es nur mit Firefox möglich, wenn .references { -moz-column-width: 35em; -webkit-column-width: 35em; } in die common.css eingebunden wird. Die Darstellung ist nicht immer 100% perfekt (überschneidungen), aber sehr gut. --Engeltr 13:44, 31. Aug. 2011 (CEST)

Das ist mir bewusst, aber ältere Browser interpretieren diese Eigenschaft dann eben nicht und zeigen die altbekannte Version ohne Spalten an. Stichwort progressive enhancement :) // Edit: Webkit kann die Colums ebenso gut darstellen wie der FF, hängt ja im Endeffekt nur vom vendor prefix ab. -- Nightfly85 _Disk 14:36, 31. Aug. 2011 (CEST)

Natürlich richtig. Aber dazu gab es vor Urzeiten irgendwo schonmal ne Anfrage die angelehnt wurde (glaube aber damals wegen eben nur Mozilla), auf die bin ich auch schonmal gestoßen als ich die en:WP gesehen habe. Von mir aus eine sinnvolle Forderung. --Engeltr 15:18, 31. Aug. 2011 (CEST)

Und wer entscheidet, ob der Vorschlag umgesetzt wird? -- Nightfly85 _Disk 15:23, 31. Aug. 2011 (CEST)

Dass die Einzelnachweis-Angabe in Spalten übersichtlicher ist, ist falsch. Dann gibt es einfach einen Haufen Zeilenumbrüche innerhalb eines Einzelnachweises, was die Sache deutlich unübersichtlicher macht. Hier ist übrigens der falsche Ort für eine solche Diskussion, das gehört auf Hilfe Diskussion:Einzelnachweise (wo es allerdings schon gefühlte 15 mal diskutiert worden und jedes Mal abgelehnt worden ist). --Orci Disk 16:50, 31. Aug. 2011 (CEST)

Danke. Werde die Diskussion nun an der Stelle fortführen :) -- Nightfly85 _Disk 17:49, 31. Aug. 2011 (CEST)

Du kannst das für dich selber erreichen, siehe Hilfe:Einzelnachweise#Mehrspaltigkeit und alternative Formatierungen. Ansonsten siehe auch Wikipedia:Spaltensatz, warum man es nicht machen sollte. Der Umherirrende 19:42, 31. Aug. 2011 (CEST)

Editnotice für Spezial:E-Mail

Ich fände es sinnvoll, für Spezial:E-Mail/Benutzername eine Editnotice zu ermöglichen. So könnte man beispielsweise neue Benutzer darauf hinweisen, in welchen Fällen man eine Benachrichtigung per Email wünscht und wann die Benutzung der Benutzerdiskussionsseite sinnvoller ist. --Leyo 14:05, 31. Aug. 2011 (CEST)

Alle Artikel einer Kategorie einschlieslich von Unterkategorien anzeigen

In der Redaktion Chemie bzw. Mineralogie wird gerade über die Doppeleinstufung von Artikeln in die Haupt-Kategorie und eine Detail-Kategorie diskutiert (also das ist der aktuelle Stand). Grund dafür ist, das man Artikel in der Hauptkategorie im Überblick haben möchte, aber auch eine detaillierte Einstufung in Unterkategorien haben möchte. Die Einstufung in die Hauptkategorie könnte man sich sparen, wenn die Möglichkeit bestehen würde alle Artikel die in einer Kategorie bzw. der dazu gehörenden Unterkategorien auftauchen, gemeinsam auf einer Seite zu sehen. Also so etwas wie eine flache Hierarchie oder eine Art Superkat. Natürlich könnte man das per Bot in eine Liste machen, aber eine einfache Softwarefunktion wäre besser. Gibt es diese Möglichkeit oder könnte man sie nachrüsten ? Rjh 18:32, 14. Aug. 2011 (CEST)

Wäre das in etwa diese Anfrage leider noch nix dazu gehört. --K@rl (Verbessern ist besser als löschen) 18:59, 14. Aug. 2011 (CEST)

Merlissimo erzeugt für einige Portale Index-Seiten auf Basis der Kategorien, das scheint ja hier gefragt zu sein, ich weiß allerdings nicht, ob er noch neue Portale aufnimmt. Spezial:Kategoriebaum hilft euch wahrscheinlich auch nicht. Eine Software-Funktion dazu kenne ich auch nicht. Der Umherirrende 22:46, 14. Aug. 2011 (CEST)

Nützlich wäre die Spezialseite, wenn sie nicht auf eine (ziemlich niedrige) Anzahl limitiert wäre (Beispiel). --Leyo 23:02, 14. Aug. 2011 (CEST)

Und der Mineral-Catscan hilft nicht? --Diwas 23:45, 14. Aug. 2011 (CEST)

Nein (sonst wäre die Anfrage nicht gestellt worden), da zu langsam/unzuverlässig. Zudem werden Sortierungsschlüssel nicht berücksichtigt. --Leyo 23:59, 14. Aug. 2011 (CEST)

OK unzuverlässig/-Sortierung sind Argumente, ob catscan zu langsam ist, bei einer so übersichtlichen Kategorie weiß ich nicht. Ansonsten finde ich ja auch, dass eine richtige Mediawiki-Lösung überfällig ist und zwar auch verwendbar in der Suche, nur fehlt mir das dann eher bei umfangreicheren Abfragen. --Diwas 00:22, 15. Aug. 2011 (CEST)

jedenfalls sollte die Redaktion Chemie bzw. Mineralogie unbedingt keine workaround-lösung für ihren bereich machen, da wir

1. jeden dringlichen grund für die lobby brauchen, das wikimedia-software-seitig implementieren
2. und wenn es dann kommt, die Redaktion Chemie bzw. Mineralogie sowieso alles wieder rückgängig machen muss

ist nie gut, einen "hack" für einen mangel in der wikimedia-plattform im quelltext der artikel umzusetzten, das macht langfristig immer mehr probleme als es löst

die optimale lösung wäre imho übrigens die, die wir jetzt bei {{All Coordinates}} für kategorien haben: sie erlaubt: nur diese kategorie | mit unterkategorie 1. Ebene | alle unterkategorien - wenn das dort geht, sollte es prinzipiell gehen (Benutzer:Herzi Pinki hat seinerzeit gesagt, das interface wäre sowieso vorhanden, und die implementierung in die vorlage ganz einfach gewesen, soweit ich das verstanden hab)--W!B: 14:36, 15. Aug. 2011 (CEST)

@Karl: ja, um so was dreht es sich, das wäre sinnvoll (wenn auch für andere Bereiche wichtiger als ausgerechnet für die Minerale). Bot-erstellte Seiten sind uninteressant, die müssen nicht aktuell sein (Mineral-Listen gibt es zudem schon genug, aber dann eben mit allen und nicht nur mit den in WP vorhandenen Mineral-Artikeln). Die jetzige Lösung mit allen Mineral-Artikeln in der Haupt-Kategorie fuktioniert gut, für die Minerale besteht erstmal kein großer Handlungsbedarf. Groß was rückgängig zu machen wäre auch nicht, es geht nur um eine Kategorie in derzeit etwa 700 Artikeln. --Orci Disk 15:02, 15. Aug. 2011 (CEST)

Ja, aber es trifft eben nicht nur auf die Minerale zu, an denen sich jetzt gerade die Diskussion entzündet hat. Es tauchen auch in regelmäßiger Folge immer wieder Listen von Säuren, Alkanen, ... auf, die irgendjemand erstellt hat, weil er in der Kategorie anscheinend wegen dem oben angeprochenen Problem nicht fündig geworden ist. Rjh 07:31, 16. Aug. 2011 (CEST)

Kann man da jetzt was machen ? Rjh 20:46, 30. Aug. 2011 (CEST)

Wichtig fände ich es jedenfalls. Ob es was bringen würde, wenn jemand einen Bug Report schreibt? --Leyo 14:01, 1. Sep. 2011 (CEST)

Nach oben / go to Top

Ich bin dafür bei jedem Absatzende ein "Nach oben" Button/Link einzufügen. Vor allem auf langen Diskussionsseiten und langen Abschnitten bei Artikeln ist es mühsam immer wieder zu scrollen (oder den Scrollbalken zu packen, was die wenigsten machen) --binningench1 ■ Bumerang 10:57, 7. Sep. 2011 (CEST)

Das gibts bereits so ähnlich (dann ist der Button neben jeder Überschrift): Spezial:Einstellungen → [Helferlein] → Navigation → Häkchen bei "Das „Pfeil-hoch-Helferlein“ fügt zu Kapitelüberschriften einen Rücksprunglink zum Anfang der Seite hinzu." setzen. XenonX3 - (☎:✉) 13:26, 7. Sep. 2011 (CEST)

Ups das ist mir jetzt peinlich... Ich hatte die schon aktiviert. Allerdings sind die Icons so dünn dass ich diese komplett übersehen habe *lach* Ausserdem hab ich nach denen auf der rechten Seite gesucht. xD

Wärs möglich dass man da wählen kann ob diese links/rechts vom Titel oder rechts am Fensterrand platziert werden könnten so wie die bearbeiten Links? --binningench1 ■ Bumerang 13:43, 7. Sep. 2011 (CEST)

Nee, der Pfeil lässt sich nicht umplatzieren. Falls du Firefox nutzt, kannst du alternativ Back to Top installieren, dann hast du so einen Button für jede Internetseite. Ist sehr praktisch! XenonX3 - (☎:✉) 13:47, 7. Sep. 2011 (CEST)

Natürlich lässt sich der Pfeil umplatzieren. Dazu deaktivierst du das Gadget und kopierst den Inhalt von MediaWiki:Gadget-Pfeil-hoch.js nach Benutzer:Binningench1/common.js sowie den Inhalt von MediaWiki:Gadget-Pfeil-hoch.css oder noch besser nur die Zeile @import "/w/index.php?title=MediaWiki:Gadget-Pfeil-hoch.css&action=raw&ctype=text/css"; nach Benutzer:Binningench1/common.css (oder auch die skinspezifischen Anweisungen ins jeweilige skin.css). Dein Js kannst du jetzt nach Lust und Laune bearbeiten, also die Platzierung des Top-Links z.B. hinter den Editsectionlink. Wenn du mir sagst, wo du ihn hinhaben willst, kann ich dir den Schnipsel auch genau schreiben.

Alternativ und ganz anspruchslos ein .toparrow { float:right; } in Benutzer:Binningench1/common.css einfügen, dann stehen sie rechts am Rand. --✓ ^Bergi 14:16, 7. Sep. 2011 (CEST)

Teilsperrung für nicht stimmberechtigte Benutzer

Angesichts des derzeit laufenden Meinungsbildes und der erstaunlich hohen Anzahl an abgegeben Stimmen von nicht stimmberechtigten Nutzer bin ich am überlegen, wie man dem begegnen könnte. Wäre es möglich, eine Teilsperrung solcher Abstimmungsseiten für alle nicht stimmberechtigten Benutzer einzuführen, d.h. dass die Admins beim Sperren der Seite jeweils festlegen können, wieviele Bearbeitungen die Benutzer bereits haben müssen, um die Abstimmungsseite zu bearbeiten? --Wkpd 21:02, 6. Sep. 2011 (CEST)

Den Vorschlag kann ich nur Unterstützen. --binningench1 ■ Bumerang 12:20, 7. Sep. 2011 (CEST)

Dazu braucht es kein neues Feature, das lässt sich schon jetzt durch Hilfe:Missbrauchsfilter realisieren. --Schnark 10:10, 8. Sep. 2011 (CEST)

Spezial:Anmelden - "Global anmelden" erläutern

Zitat: "Was mit Global anmelden gemeint ist wird nicht erläutert. Da sollte ein Erläuterungstext stehen oder ein Link auf eine erklärende Seite vorhanden sein."

Diskussionen dazu gab es bereits unter Wikipedia:IQS#Spezial:Anmelden und Wikipedia:Administratoren/Anfragen/Archiv/2011/Februar#Spezial:Anmelden (sowie mw:Special:Code/MediaWiki/84352).

Zwei Fragen dazu:

• Ist es wirklich nicht möglich, an der entsprechenden Stelle der Anmeldeseite einen Link zu setzten? Schließlich ist "Hier legst du ein Konto an" und andere Sprachversionen ebenfalls verlinkt.
• Falls ein Link technisch nicht möglich ist, ließe sich vielleicht eine aussagekräftigere Formulierung finden?

Grüße --Wkpd 21:31, 24. Sep. 2011 (CEST)

Der Text wird sich mit dem nächsten Software-Update ändern, testweise zu sehen ist er schon unter de.labs.wikimedia.org. Der Umherirrende 09:57, 25. Sep. 2011 (CEST)

Danke für die Info! --Wkpd 12:16, 25. Sep. 2011 (CEST)

Ist jetzt da. Der Umherirrende 23:18, 7. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 23:18, 7. Okt. 2011 (CEST)

Auswahl der Namensräume auf Benutzerbeitragsseiten

Ich wünsche mir ein Kontrollkästchen „Auswahl umkehren“ neben der Namensraumwahl auf der Seite Spezial:Beiträge wie auf der Seite Spezial:Beobachtungsliste. --Komischn 15:56, 12. Sep. 2011 (CEST)

Dann habe ich eine ganz schlechte Nachricht für dich: Auf WMF-Wikis können die Benutzerbeiträge nicht länger [sobald die Software auf Version 1.19 aktualisiert ist] nach Namensräume gefiltert werden --Schnark 09:16, 13. Sep. 2011 (CEST)

Bleibt wohl nur der Logs Filter… --Leyo 09:27, 13. Sep. 2011 (CEST)

Spezial:Weblink-Suche

Ich würde mir wünschen, diese Spezialseite auf Namensräume, zumindest auf den Artikelnamensraum filtern zu können. Derzeit findet man in dem ganzen Wust gar nichts mehr. Performance kann doch wirklich kein Grund sein, das zu deaktivieren. Wie soll man denn hier effizient arbeiten?? SteMicha 21:20, 1. Okt. 2011 (CEST)

phab:T12593 (Bugzilla:10593): Make namespace filter in Special:Linksearch efficient enough to enable on WMF wikis --Fomafix 19:37, 4. Okt. 2011 (CEST)

Das Problem dürfte aber nicht eine Einschränkung auf Namensräume mit vielen Seiten sein, sondern eher eine Einschränkung auf Namensräume mit wenigen Seiten. Wenn man beispielsweise die Letzten Änderungen von MediaWiki-Namensraum haben möchte, merkt man schon, das der Aufruf der Seite etwas länger dauert.

Ich denke aber nicht, das es mit der aktuellen Datenbankstruktur möglich ist, das effizient zu machen. Mit dem Update auf MediaWiki 1.18 wird auch der Namensraumfilter auf Spezial:Beiträge wegfallen, was einem schon zeigt, das es wohl nicht so einfach ist. Der Umherirrende 20:01, 4. Okt. 2011 (CEST)

CSS- und JavaScript-Definition bei Weiterleitungen

Die Vorlage:Weiterleitungshinweis erzeugt eine Hinweiskasten, der verwendet werden soll, wenn eine BKL III vorliegt und auf einen weiteren Artikel verwiesen werden soll. Beispiel: Westerwelle ist eine Weiterleitung auf den Artikel Guido Westerwelle. Dort steht ein Weiterleitungshinweis auf den Artikel Stefan Westerwelle.

Wenn jemand direkt den Artikel Guido Westerwelle angesprungen hat, ist dieser Weiterleitungshinweis nicht gerade passend. Verbesserungsvorschlag: Der Weiterleitungshinweis wird nur angezeigt, wenn die Weiterleitung Westerwelle aufgerufen wurde. Derzeit ist so etwas nicht sauber realisierbar. Es muss dazu die Erkennung der Weiterleitung per JavaScript aus dem HTML vorgenommen werden. Eine serverseitige Unterstützung wäre da sinnvoll.

Derzeit enthält der erzeugte HTML-Code am body-Element die CSS-Klasse page-Guido_Westerwelle. Zusätzlich kann der Seitentitel per JavaScript ausgelesen werden: mw.config.get ( 'wgTitle' ) enthält "Guido Westerwelle". Ich könnte mir dazu bei der Anzeige von Westerwelle folgende Erweiterung vorstellen: Eine zusätzliche CSS-Klasse redirect-Westerwelle und eine zusätzliche JavaScript-Variable mw.config.get ( 'wgRedirect' ) mit dem Inhalt "Westerwelle".

Die eigentliche Ausblendung ist damit noch nicht realisiert, aber sie könnte damit zuverlässiger mit JavaScript realisiert werden oder zukünftig vielleicht mit CSS-Selektoren im Artikeltext sogar direkt mit CSS. --Fomafix 09:27, 18. Okt. 2011 (CEST)

phab:T34230 (Bugzilla:32230) :-) -- ✓ ^Bergi 20:00, 6. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: -- ✓ ^Bergi 20:00, 6. Nov. 2011 (CET)

"Zugeordneter Namensraum" auch auf der Beobachtungsliste

Hallo. Mir ist aufgefallen, daß es bei den Letzten Änderungen jetzt "Zugeordneter Namensraum" gibt. Warum gibt es dies eigentlich nicht auf der Beobachtungliste? Gruß --Tlustulimu 20:05, 14. Okt. 2011 (CEST)

Vermutlich hat kein Entwickler die Notwendigkeit gesehen und somit wurde es nicht sofort mit 1.18 miterledigt. Ich habe aber phab:T33704 (Bugzilla:31704) erstellt. Dadurch könnte es in einer der nächsten Versionen enthalten sein. Der Umherirrende 21:49, 14. Okt. 2011 (CEST)

Cursor im Suchfeld

Ist ja schön, dass es diese Möglichkeit gibt, habe sie auch bei mir eingestellt. Mich stört nur, dass der Cursor auf das untere statt auf das obere Suchfeld gesetzt wird. Dadurch verschwinden dann die eingeblendeten Suchvorschläge im Nirvana...--Hlambert63 15:22, 13. Nov. 2011 (CET)

Unteres und oberes Suchfeld? Ah, cologneblue. Dann bräuchte es bitte einen Admin, der MediaWiki:Gadget-Suchfokus-Hauptseite.js durch

// Dieses Gadget sorgt dafür, dass sich der Fokus des Cursors auf der Hauptseite immer in der Suchbox befindet. Siehe auch {{Phab|Bugzilla=1864}}.

if (wgPageName == wgMainPageTitle) {
   if (skin == 'vector')
      addOnloadHook(function() {
         $j(document).ready( function() {
            $j("#searchInput").focus();
         });
      });
   else
      addOnloadHook(function() {
         document.getElementById(skin == 'cologneblue' ? "searchInput2" : "searchInput").focus();
      });
}

ersetzt. -- ✓ ^Bergi 19:50, 13. Nov. 2011 (CET)

Ja, diese Änderung scheint notwendig und richtig zu sein. In diesem Zuge könnte die Programmierung auch noch deutlich vereinfacht werden. Alle Skins haben inzwischen jQuery und die globalen Variablen wg* und addOnloadHook() sind veraltet. --Fomafix 11:17, 14. Nov. 2011 (CET)

Hier der modernisierte JavaScript-Code:

// Dieses Gadget sorgt dafür, dass sich der Fokus des Cursors auf der Hauptseite immer in der Suchbox befindet. Siehe auch {{Phab|Bugzilla=1864}}.

if ( mw.config.get( 'wgPageName' ) == mw.config.get( 'wgMainPageTitle' ) ) {
	jQuery( function( $ ) {
		$( mw.config.get( 'skin' ) == 'cologneblue' ? "#searchInput2" : "#searchInput" ).focus();
	});
}

--Fomafix 13:01, 14. Nov. 2011 (CET)

Achtung, nein! Vector benötigt tatsächlich den doppelten ready(), da am Suchfeld so viele Listener herumgedoktert werden dass es den Fokus wieder verliert, wenn man nicht am Ende der ready-Queue erst den Fokus setzt. Und die alten Skins hatten m.W. auch Probleme, wenn man nicht aOH verwendet sondern den davor ausgeführten jQuery-Ready. Dieses Gadget muss man also wirklich crossbrowser- crossskin testen und dabei den Code auch wirklich an der Stelle eines Gadgets ausführen lassen.

Daher habe ich vorsichtigerweise so wenig wie möglich geändert, mw.config.get kann man natürlich verwenden. -- ✓ ^Bergi 13:55, 14. Nov. 2011 (CET)

en:MediaWiki:Gadget-searchFocus.js verwendet auch nur ein einfaches ready(). Gibt es dort Probleme mit Vector? Ich kann dort keine Probleme mit Vector feststellen. --Fomafix 13:59, 14. Nov. 2011 (CET)

Keine Ahnung, vielleicht hat sich dort nur noch niemand beschwert… Es gab zumindest mal Probleme in älteren Browsern wegen der placeholder-emulation, siehe Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 46#Cursor nicht im Suchfeld und Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 36#Eingabe Suchfeld. Allerdings scheint sich da mittlerweile was an placholder.js geändert zu haben, sodass es mittlerweile funktionieren dürfte. @nächsten Admin: Bitte unteres Skript nach MediaWiki:Gadget-Suchfokus-Hauptseite.js kopieren! -- ✓ ^Bergi 14:38, 14. Nov. 2011 (CET)

Änderung umgesetzt. Es scheint bei allen Skins zu funktionieren. Ich kann keine Probleme feststellen. --Fomafix 11:28, 18. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Fomafix 11:28, 18. Nov. 2011 (CET)

Danke, das ist echt ne Erleichterung! Ich hätte nicht gedacht, dass das so viel Arbeit macht, ich hatte zwar ne Ahnung, dass im JavaScript was gemacht werden muss (bin selbst Informatiker), aber ich kenne Euren Code natürlich nicht!

--Hlambert63 13:33, 19. Nov. 2011 (CET)

Benutzerspezifische Systemtexte

Im Namensraum MediaWiki befinden sich die Systemtexte, die angezeigt werden. Beispiel: MediaWiki:Rollbacklink mit dem Inhalt „kommentarlos zurücksetzen“. Die Systemtexte gelten für alle Benutzer und können nur von Administratoren bearbeitet werden.

Es wäre von Vorteil, wenn sich angemeldete Benutzer ihre eigenen Systemtexte einstellen könnten. Diese benutzerspezifischen Systemtexte müssten sich in einem Bereich befinden, der nur vom Benutzer und von Administratoren bearbeitet werden darf. Es würde sich dazu folgendes anbieten: Benutzer:Benutzername/MediaWiki:Rollbacklink. Dieser Bereich müsste wie die benutzerspezifischen CSS- und JS-Dateien automatisch gegen Bearbeiten von anderen Benutzeren geschützt werden, bleibt aber öffentlich zum Lesen. Alternativ wäre auch ein eigener Namensraum denkbar: Benutzereinstellung:Benutzername/Rollbacklink

Gibt es in Bugzilla bereits einen solchen Vorschlag? Gibt es Sicherheitsbedenken? --Fomafix 19:41, 21. Sep. 2011 (CEST)

Eher Performancebedenken… -- ✓ ^Bergi 20:11, 21. Sep. 2011 (CEST)

Gibt es eine Bug-Nummer? --Fomafix 22:40, 21. Sep. 2011 (CEST)

Nein, das nicht (heißt: ich habe keine gefunden), waren nur meine Bedenken. Was das mit dem Cache anstellen würde… Eine personalisierbare Skindatei wäre natürlich auch nicht schlecht :) -- ✓ ^Bergi 21:17, 22. Sep. 2011 (CEST)

phab:T10377 (Bugzilla:8377) beschreibt ungefähr eine ähnliche Idee und ist vor knapp fünf Jahren mit WONTFIX abgelehnt worden. Mit der Mehrsprachigkeit haben wir prinzipiell bereits diese Funktionalität der individuellen Systemtexte. Die Unterschiede sind, dass neue Sprachen nicht beliebig angelegt und nur von Administratoren bearbeitet werden können und dass es im Vergleich zu der Anzahl der Benutzer nur sehr wenig Sprachen gibt. --Fomafix 14:50, 23. Sep. 2011 (CEST)

Das wäre mal sehr sinnvoll. Kein JS-Gefummel mehr. Am besten natürlich auch so, dass es Normalsterbliche bearbeiten können - also als Tab in den Einstellungen. --Saibo (Δ) 19:34, 24. Sep. 2011 (CEST)

Besser in Spezial:MediaWiki-Systemnachrichten neben Standardtext und Systemtext noch ein Benutzertext. --Fomafix 16:20, 27. Sep. 2011 (CEST)

Hat jemand Lust einen neuen Bugzilla-Eintrag zu schreiben? --Fomafix 08:46, 24. Okt. 2011 (CEST)

Gibt doch schon einen Bugreport, phab:T10377 (Bugzilla:8377), siehe oben. Man könnte allerdings nach fünf Jahren durchaus noch mal nachfragen. Außerdem noch den hier beschriebenen Anwendungsfall in Bugzilla beschreiben. --Church of emacs D B 09:09, 24. Okt. 2011 (CEST)

Automatische Konvertierung von Video-Dateien zu *.ogg

Ich bin mir nicht sicher, ob mein Vorschlag besser bei Wiki Commons diskutiert werden müsste, aber da habe ich kein entsprechendes Portal gefunden.

Wiki Commons akzeptiert Video-Dateien nur im ogg-Format. Das ist beim Einbringen von Videodateien (die prinzipiell ja wohl wünschenswert ist) eine zusätzliche Hürde. Die wenigsten Aufnahmegeräte speichern jedoch im ogg-Format ab. Eine vorhandene Video-Datei muss also zunächst manuell konvertiert werden. Dazu muss man (häufig) erst ein zusätzliches Konvertierungsprogramm installieren. Es gibt zwar entsprechende Anleitungen, aber das Einlesen in die Technik und der Vorgang des Konvertierens an sich kosten Aufwand und Zeit, die den ein oder anderen vielleicht davon abhalten, Inhalte einzubringen.

Ich schlage deshalb vor, Videos zwar in unterschiedlichen Formaten zu akzeptieren, diese aber beim Hochladen automatisch ins ogg-Format zu konvertieren. --XXLRay 12:05, 21. Nov. 2011 (CET)

Auf Commons gibt es das deutschsprachige Commons:Forum. Commons akzeptiert nur "freie" Formate, wo keine Patente hinterstehen oder wo die Patente abgelaufen sind, weil solche Formate sehr gut mit den freien Lizenzen zusammen passen (So habe ich es zumindestens verstanden). Siehe dazu auch das Intro von Commons:Media help. Das Problem bei diesem Vorgehen ist allerdings die Verbreitung dieser Formate, da stimme ich zu. Der Umherirrende 13:31, 21. Nov. 2011 (CET)

Commons würde ja gar kein unfreies Format speichern, das ist ja der Sinn der Sache. Es ist nur die Frage, ob unsere freie Software Konvertierungsprogramme enthalten darf/kann, die in Teilen proprietär sind.

Das wäre sicher eine super Sache, doch glaube ich nicht dass der Konverter das völlig alleine und automatisch kann. Es gibt viele Konfigurationsmöglichkeiten für eine De-/encodierung, die sich imho kaum automatisch auswählen lassen (von fehlerhaften Datein mal ganz zu schweigen) – der Benutzer müsste sich dann doch wieder einlesen oder zumindest informieren und ausprobieren. -- ✓ ^Bergi 13:45, 21. Nov. 2011 (CET)

Also technisch sollte es umsetzbar sein. Die (kostenlosen) Format-Konverter, die ich bisher genutzt habe, haben mit herkömmlichen Videos keine Probleme. Da muss man nichts einstellen. Falls man ein ganz exotisches Format hat muss man halt doch manuell konvertieren. Für den Großteil der Uploads ließe sich eine automatische Umwandlung aber sicher umsetzen. Die Frage ist aber tatsächlich, wie das Lizenzrechtlich aussieht.

Ich tendiere dazu, die Diskussion ins Wiki-Commons-Forum zu transferieren. Darf ich eure Beiträge dafür "mitnehmen"?

--XXLRay 13:52, 21. Nov. 2011 (CET)

gerne Links schon agepasst. Dann werd aber ich keinen Bugzilla-Antrag mehr stellen. -- ✓ ^Bergi 14:12, 21. Nov. 2011 (CET)

Dann geht es bitte im Beitrag bei Wiki Commons weiter. Hier warte ich nur noch auf die Authorisierung von Der Umherirrende. --XXLRay 14:36, 21. Nov. 2011 (CET)

Mein Beitrag kann man gerne kopieren, am besten in der Zusammenfassungszeile einen Permalink auf diesen Abschnitt setzen, dann weiß man, wo er her kommt. Der Umherirrende 14:40, 21. Nov. 2011 (CET)

Klasse, die Diskussion hier ist dann meiner Meinung nach abgeschlossen und darf im Beitrag bei Wiki Commons weitergeführt werden. --XXLRay 14:53, 21. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: XXLRay 14:53, 21. Nov. 2011 (CET)

Kleine Nachbesserungen nur auf Verlangen zeigen

Sollte man nicht den Autoren erlauben, kleine Nachbesserungen einer frischen Änderung so zu kennzeichnen, daß sie in der Versionenliste (und beim Versionenvergleich) zusammen mit den eigenen unmittelbar vorangehenden Änderungen als _ein_ Eintrag erscheinen und nur dann aufgeteilt werden, wenn man einen Knopf "Zwischenversionen zeigen" drückt, der dann im Eintrag in der Versionenliste erscheint? Dafür böte sich an, während der Bearbeitung eine Option "Mit unmittelbar vorangehenden eigenen Änderungen zusammenfassen" anzubieten. Drückt man den, sollte zwangsweise die _gesamte_ Änderung als Vorschau erscheinen, damit der Autor in der neuen Zusammenfassung _alle_ wichtigen Änderungen erwähnen. -- Ich sehe, das wird kompliziert, könnte aber lohnen. -- Wegner8 16:18, 4. Nov. 2011 (CET)

In dem Zusammenhang: Wikipedia:Verbesserungsvorschläge#Eigene Beiträge/Änderungen zusammenfassen --Diwas 23:52, 4. Nov. 2011 (CET)

Default von "Speichern" nach "Vorschau" ändern

Als ich meinen Browser neu hatte, habe ich manchmal den Auftrag "auf dieser Seite suchen" mit der Enter-Taste abgegeben -- da hat aber Wikipedia die unfertige Änderung gespeichert, gegen meine Absicht. Noch heute komme ich manchmal versehentlich auf die Enter-Taste, wenn auch selten. Ich schlage vor, beim Bildschirm "Bearbeiten von Wikipedia" den Default für die Enter-Taste von der Schaltfläche "Speichern" auf die Schaltfläche "Vorschau zeigen" zu verlagern; da kann ein versehentliches Drücken der Enter-Taste nichts Unbeabsichtigtes speichern. -- Wegner8 16:25, 4. Nov. 2011 (CET)

Schau mal Wikipedia:Verbesserungsvorschläge/Archiv/2011/Juli#Option unter Einstellungen-Bearbeiten: Speichern nur mit Mausklick an. Hab das gemacht. (Dank Benutzer:✓) --Diwas 23:22, 4. Nov. 2011 (CET)

Es gab übrigens schon Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2006#Default-Button [Seite speichern] ändern und Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2011#Eine Sicherheitsabfrage vor dem Speichern einer Seite wäre vielleicht sinnvoll. --Diwas 23:36, 4. Nov. 2011 (CET)

Statt Kackbalken den Menüpunkt „Eigene Diskussion“ grün hinterlegen

Der Kackbalken sollte softwareseitig durch eine grüne Hinterlegung des Menüeintrags „Eigene Diskussion“ ersetzt werden. Falls möglich sollte der Tooltip dann „Du hast neue Nachrichten auf deiner Diskussionsseite“ lauten. Alternativ oder zusätzlich könnte der Hinweis oberhalb des Seitentitels, ähnlich den Aufrufen zu Metaaktionen eingeblendet werden. --Diwas 22:11, 7. Nov. 2011 (CET)

Zu unauffällig. Wenn du das aber persönlich gerne so hättest, geht das ganz leicht mit etwas JavaScript. Wenn du willst, schau mal auf Wikipedia:TSW vorbei, da kann ich dir den nötigen Codeschnipsel präsentieren. -- ✓ ^Bergi 22:33, 7. Nov. 2011 (CET)

glaub ich nicht - ich hab in meiner monobook auch nur ein kleines ☏ neben dem diskseitenlink, das auf den letzten diff verlinkt. reicht vollkommen. -- ∂ 23:05, 7. Nov. 2011 (CET)

dieser Edit auf meiner Beobachtungsliste, die Tatsache, dass der Hinweis nicht zum Seiteninhalt gehört und die Erfahrung, dass gefakte Kackbalken wirklich nerven können, trieb mich zu diesem Vorschlag, obwohl ich fürchte, dass man auch dies mit etwas Fummelei wieder nachäffen könnte. Tja, für mich persönlich? Nur wenn es dir keine Arbeit macht. Vielleicht wär das aber eine Lösung, die alle Genervten entnervt, ähm, entspannt, sobald die Konditionierung auf den gelben Balken nachlässt, weil jetzt grüner Menüpunkt angesagt ist. Andererseits sind diese Fakes wirklich sehr selten und ich muss ja nicht jede Benutzerseite nutzen. --Diwas 02:26, 02:58 8. Nov. 2011 (CET)

Auf keinen Fall als Standard für alle. Es haben schon genug Benutzer gemosert, als bei der Vector-Einführung der Balken zeitweise blau und nicht gelb war, dass er nun zu unauffällig sei (wurde daraufhin wieder revertiert). Da scheidet eine noch unauffälligere Lösung mit Sicherheit aus. Wer eine unauffällige Lösung möchte, kann sich das ja per eigenem .js einrichten. --Orci Disk 10:38, 8. Nov. 2011 (CET)

Wer einfach nur einen deutlichen Unterschied zwischen echten und gefälschten Neue-Nachrichten-Balken haben will, der schaut in meine Benutzer:Schnark/vector.css und kopiert sich den entsprechenden Code (ist kommentiert, sollte daher zu finden sein, Farben, Rahmen und sonstiges Aussehen können natürlich je nach Geschmack angepasst werden). --Schnark 10:52, 8. Nov. 2011 (CET)

oh, elegant gelöst. die idee klau ich mir für mein JS, danke! -- ∂ 14:42, 8. Nov. 2011 (CET)

Mein Gedanke war, das Meinungsbild zweifelsfrei obsolet zu machen. --Diwas 15:41, 8. Nov. 2011 (CET)

Einblendung der fremdsprachigen Versionsgeschichte bei Übersetzungen

Hallo,
Für Übersetzungen aus anderen Sprachversionen gibt es bisher keine zufriedenstellende Lösung.

• Hinweis auf der Diskussionsseite oder Kopieren der Versionsgeschichte in den Artikel samt Hinweis in der Zusammenfassungszeile: Äußerst unschöne Notlösungen, extrem nutzerunfreundlich. Wir haben einen Reiter Versionsgeschichte, und dort sollte diese auch erscheinen, komplett.
• Versionsimport: Dies ist oberflächlich betrachtet eine saubere Lösung, weist aber bei genauerem Hinsehen erhebliche Schwächen auf:
  • Bei zwei gleichlautenden, aber unterschiedlichen Benutzerkonten in den beiden Sprachversionen werden die Edits vermischt, z. B. bei Spezial:Beiträge/Joy. Langfristig wird zwar auf globale Eindeutigkeit von Benutzernamen hingearbeitet, aber diese Altfälle würden dennoch verbleiben, und außerdem kann das Erreichen dieses Ziels noch dauern. Andererseits wäre eine bloße Abschaltung der Vermengung auch nicht ideal, da ja die meisten gleichnamigen Benutzerkonten durchaus demselben Benutzer gehören.
  • Importieren ist immer eine heikle Sache, und wenn etwas schiefgeht, ist das nicht so leicht wieder geradezubiegen.
  • Die Software kommt teilweise völlig durcheinander, ich nehme an wegen der Metadaten wie Versions-IDs etc. Ein noch relativ harmloses Beispiel bei Position der Erde im Universum: beim manuellen durchklicken durch die Versionsunterschiede passieren solche Sachen.
  • Versionen müssen für jede weiternutzende Sprachversion neu gespeichert werden. Auch wenn das speicherplatzmäßig so gut wie gar nicht ins Gewicht fallen mag, doof ist es trotzdem. Benutzer haben global plötzlich mehr Edits, weil ihre Artikel in andere Sprachen exportiert wurden. Beim Betrachten der übernommenen Versionsgeschichte trifft man auf lokal nicht vorhandene Vorlagen, Kategorien usw.

Daher ist mir während dieser Diskussion bei den Adminanfragen die Vorstellung eines besseren Systems für Übersetzungs-Versionsgeschichten ins Hirn geschwebt. Die Versionsgeschichte der Übersetzungsgrundlage wird einfach am Ende der lokalen Versionsgeschichte eingeblendet, das heißt, es wird auf die Datenbank der anderen Sprachversion zurückgegriffen. Die Versionen müssen nicht lokal gespeichert werden, sondern es wird eine Art mystisches Portal heraufbeschworen, durch das der Betrachter in eine andere Sprachversion blicken kann. Sämtliche Links in diesem Abschnitt werden als externe Links dargestellt, und beim Klick auf den Zeitstempel oder den Versionsvergleich wird man dann auch in die andere Sprachversion geschickt. Natürlich nicht ungewarnt, am Anfang dieser eingeblendeten Versionsgeschichte steht ein Hinweis, dass dies die Versionsgeschichte der Übersetzungsgrundlage aus der Sprachversion XY ist.
Ergänzende Einzelheiten:

• Es soll natürlich möglich sein, einzustellen, aus welchem Zeitraum Versionen angezeigt werden sollen, sodass nur die übersetzungsrelevanten Versionen angezeigt werden. (Also meistens: Alle Versionen bis zum Übersetzungszeitpunkt.)
• Wenn ein Artikel im Original verschoben wird, ändert das ein Bot oder teilt es zumindest einem Änderungsbefugten mit.
• Wenn ein Artikel im Original zur Löschung vorgeschlagen wird, warnt dort ein Bot, dass zuvor die Versionen in die Sprachversion(en) exportiert werden sollten, die sie als Übersetzungsgrundlage nutzen (Idee von Port(u*o)s).

Ich weiß nicht, ob und mit welchem Aufwand dies tatsächlich machbar wäre, aber mir erscheint es nicht sonderlich unrealistisch. Ich freue mich auf Meinungen dazu. Gruß, Kronf @ 11:28, 17. Nov. 2011 (CET)

Klingt gut. Die technischen Einschränkungen, die ich sehe, dürften allerdings dazu führen dass es nicht umgesetzt wird: funktioniert doch wie es ist.

• Es ist eine Datenabfrage aus fremden Wikis nötig. Dies kann nicht vorrausgesetzt werden. Führt zu a) die alte Möglichkeit muss erhalten bleiben, es wird ein „Zusatzfeature“ und b) die Wikis müssen (sollten) dazu möglichst stark aneinander gekoppelt werden, wie die Wikimedia-Wiki-Familie (Interwikitable etc). Eine "lose" Kopplung durch Abfrage einer vielleicht existierenden, vielleicht offenen API halte ich für fragwürdig.
• Bots sollten nicht notwendig sein. Eine potenzielle Extension mit starker Kopplung stellt ein Interface bereit, das Versionensgeschichten veröffentlicht (geht theoretisch auch "nur" über die API), kann Versionsgeschichten von "verbundenen" Seiten anzeigen und speichert auch, wenn eigene Versionen von anderen Wikis gebunden werden. Dieser Speicher verhindert dann sämtliche Frickeleien an markierten Versionen, insb. deren Löschung – eine Seite kann erst gelöscht werden, wenn alle Bindungen zurückgenommen werden. BTW: Kann sie überhaupt gelöscht werden, wenn sie doch nicht in x Wikis importiert werden soll? Würde die Seite in eines der sie "nutzenden" Wikis importiert (händisch kopiert), und von diesem aus in den anderen eingebunden, also nicht aus dem Wiki in dem sie eigentlich entstanden ist? Das gibt noch größere Probleme als heute, wenn die französiche Wikipedia der deutschen Versionen (mit Links auf französiche Autoren) anbietet, die eigentlich von englischen geschaffen wurden? *Schüttel* Einzige strikte Lösung: Eine Seite kann erst dann gelöscht werden, wenn die sie benutzenden auf gelöscht wurden. Und wie gehen wir überhaupt mit Versionslöschungen um, soll sich die Importmarkierung nur auf bestimmte "erzwungene" Versionen beschränken?
• Verschiebungen sind kein Problem, an der Seite ändert sich ja nur das Titelattribut. Referenziert würde sie selbstverständlich über Pageid (oder gleich die Versions-ids).

Eine derartig starke Kopplung wäre wünschenswert, sowohl urheberrechtlich wie konsistent. Zurzeit ist die Situation ja so, dass sobald die Seite gesichert (ex- und importiert) ist, mit dem Original alles mögliche gemacht werden kann (Benutzerumbenennungen, Löschen/Verstecken einzelner Versionen, Löschen aller Versionen) etc. Wäre sinnvoll, ja (vor allem für einen einfachen Übersetzen-Button, mit dem jeder autoconfirmede Wikipedianer eine Seite erstellen kann, die die Import-Markierung besitzt, und dazu die aktuelle fremdsprachige Version im Editfenster gezeigt bekommt), aber kann ich mir auf WMF leider nicht vorstellen. -- ✓ ^Bergi 19:55, 17. Nov. 2011 (CET)

nach Bearbeitungskonflikt: oben-unten Darstellung ist schlechter als der übliche Versionsvergleich links-rechts

Ergänze ich einen längeren Artikel „am Stück“ und erscheint am Ende der Bearbeitungskonflikt, weil irgendwer irgendwo eine Änderung gemacht hat, muss ich meine Version in meinem Textprogramm sichern, zurückgehen und neu beginnen, oder ich klaube meine Änderungen mühselig heraus und tippe alles was ich „unten“ geändert habe, „oben“ mühselig wieder hinein (mit der Gefahr wieder in einen weiteren Bearbeitungskonflikt zu geraten, weil der/die Andere jede Minimaländerung einzeln abspeichert).

Damit ich nicht von einem Bearbeitungskonflikt überrascht werde, mache ich deshalb öfter eine Zwischenspeicherung. Dass dabei unnötig viel Speicherplatz verschwendet wird, ignoriere ich. MEINE Vorteile sind mir wichtiger.

Ich fände es sinnvoller, wenn

• A) bei einem Bearbeitungskonflikt ein Versionsvergleich erscheint und ich erkenne, ob „der Andere“ ein Leerzeichen vor einen „ref“ entfernt hat oder mehr Text verändert hat;

• B) oder bei der herkömmlichen Anzeige „unten“, dort von mir gelöschter und neu getippter Text in andersfarbiger Schrift erscheinen würde.

• C) eine Hinweiszeile oben bei der Versionsgeschichte in der Art von:

Dieser Artikel wird gerade von den Benutzern Name1, Name2, Name3 betrachtet und wurde in der letzten Stunde geändert/nicht geändert.

So das technisch möglich ist, um zu signalisieren, dass an diesem Artikel eventuell gearbeitet wird.

Ich hoffe, hier ist die richtige Seite, dies zu diskutieren.--Ohrnwuzler 04:07, 9. Nov. 2011 (CET)

Im Rahmen der Coding Challenge hat mw:User:Johnduhart etwas in diese Richtung programmiert, wenn man in seinem Testwiki auf "Bearbeiten" klickt, dann wird dies anderen Benutzern angezeigt. --Schnark 09:11, 9. Nov. 2011 (CET)

Und sowas, wie bei A) beschrieben, geht das?--Ohrnwuzler 14:07, 17. Nov. 2011 (CET)

Bei einem Bearbeitungskonflikt wird auch ein Versionsunterschied zwischen der nun aktuellen Version und der eigenen Version dargestellt. Dieser befindet sich bei mir immer zwischen den beiden Textareas. Der Umherirrende 15:03, 19. Nov. 2011 (CET)

Button zum Ausdrucken eines Artikels

Moin, es gab eine Anfrage ans Support-Team (Ticket:2011111010011749) mit dem Vorschlag, einen Button zum direkten Ausdrucken von Artikeln einzurichten (damit man nicht über die Browser-eigene Funktion gehen muss). Ist das bei Mediawiki technisch umsetzbar? XenonX3 - (☎:✉) 15:43, 10. Nov. 2011 (CET)

Wie soll MediaWiki den Drucker ansprechen können? Soll man auf einem Wikimedia-Netzwerkdrucker drucken können? Es gibt die Javascript-Funktion window.print();, die aber auch nicht mehr machen kann als den Druckdialog des Browsers (Strg+P) aufzurufen. Oder geht es um die Druckversion (printable=yes), die imho nur noch für nicht @media-css-fähige Browser da ist? -- ✓ ^Bergi 03:33, 11. Nov. 2011 (CET)

So genau wurde die gewünschte Funktion nicht beschrieben. Es wird um ein Druckersymbol gebeten, das "[…] den (teilweisen) Ausdruck von Artikeln vereinfachen […]" würde. Wenn sich das nicht umsetzen lässt, kommt der Leser sicher auch mit der browsereigenen Druckfunktion aus. XenonX3 - (☎:✉) 14:07, 14. Nov. 2011 (CET)

Teilweiser (abschnittsweiser) Ausdruck wäre sicher interessant. Ist aber ein typisches Anwender-Entwickler-Problem: Bitte vereinfachen! – Ist doch schon so einfach wie wir es uns vorstellen! :-) Was habt ihr denn geantwortet, Verweis auf den Drucken-Link in der Toolbar? -- ✓ ^Bergi 14:45, 14. Nov. 2011 (CET)

Einen Verweis auf die Druckversion gegeben. Dass die Anfragende die normale Druckfunktion des Browsers kennt, habe ich mal vorausgesetzt. XenonX3 - (☎:✉) 14:51, 14. Nov. 2011 (CET)

Es gibt doch im Internet, abseits von Wikipedia häufiger mal die Option, die pdf-Version eines Artikels zum Ausdruck herunterzuladen. Wäre das nicht, evtl sogar Abschnittweise, machbar?--XXLRay 12:14, 21. Nov. 2011 (CET)

Guckstu links, „Drucken/Exportieren“ → „Als PDF herunterladen“? Abschnittsweise ist ziemlich kompliziert, da im PDF die Autoren mit angegeben werden – welche sich nicht für einzelne Abschnitte ermitteln lassen. -- ✓ ^Bergi 12:39, 21. Nov. 2011 (CET)

Automatisches Drehen von Bildern zurücknehmen

Bei Wikipedia:Projektneuheiten#Version 1.18 liest sich „(Softwareneuheit) Die Orientierungsangabe in den EXIF-Daten wird erkannt. Fotos werden beim Hochladen automatisch (der Klassiker: 90°) gedreht, so dass sie lagerichtig auf dem Bildschirm erscheinen. Bereits früher hochgeladene Bilder können mit ?action=purge gerichtet werden“.
Was soll der Schwachsinn? Da kommt es dann zu solch lustigen Ergebnissen wie bei File:Marie Curie birthplace.jpg – jeder, der das Bild sieht, wird denken dass es seit zwei Jahren unerkannt falsch herum im Artikel eingebunden wird. Das verwirrt den Durchschnittsleser doch nur! Siehe auch die IP, die sich gestern auf meiner Diskussionsseite darüber beschwert hat, dass das erwähnte Bild gedreht gehört. Ich sehe in dieser Neuerung absolut keinen Nutzen, sie wirft nur bereits existierende und in die richtige Position gedrehte Bilder wieder um. Und ganz ehrlich: Ein hochkant aufgenommenes Bild noch geschwind zu drehen bevor man es hochlädt, ist ein Akt, der je nach Vorgehensweise mit einem bis drei Mausklicks erledigt ist. Das ist kein Zeitaufwand, der es rechtfertigen würde, hier tausende z.T. seit Jahren verwendete Bilder unbrauchbar zu machen (Ja, ich weiß, man kann auf Commons den Rotatebot beauftragen – aber das sind doch wirklich unnötige Edits…). Diesen „Aufwand“ kann man dem hochladenden Benutzer IMHO durchaus zutrauen. -- Memorino ^(D) _{Mentorenprogramm?} 17:34, 5. Dez. 2011 (CET)

Ich würde sagen, da ist die Formulierung nicht ganz richtig. Fotos werden m.W. nicht beim Hochladen gedreht und anders gespeichert, als sie hochgeladen wurden, sondern beim Rendern (auf Thumb-Größe) anhand ihrer Metadaten „richtig“ herum angezeigt. Hat ein Bild falsche Metadaten, wird es falsch angezeigt. -- ✓ ^Bergi 18:09, 5. Dez. 2011 (CET)

Hilft auch nicht wirklich, wie man hier sieht, bei kreativen Formaten geht das halt schief. Irgendwie eine blöde Funktion. Gruß --Pitlane02 _disk 15:24, 6. Dez. 2011 (CET)

Habe gerade die Lachnummer gefunden: http://commons.wikimedia.org/wiki/File:Gotland-Källunge_kyrka_Seitenportal_02.jpg Gruß --Pitlane02 _disk 15:34, 6. Dez. 2011 (CET)

Mittlerweilen sehe ich das deutlich entspannter, das wächst sich anscheinend doch relativ schnell aus. Gruß --Pitlane02 _disk 09:03, 13. Dez. 2011 (CET)

Parameterfelder

Bei Vorlagen gibt es benannte und unbenannte Parameter. Beiden Arten können gemischt verwendet werden.

{{Meine Vorlage
|      Alpha
|      Beta
| A  = Gamma
|      Delta
|      Epsilon
| B  = Zeta
|      Eta
}}

Die einzelnen Werte lassen sich dann folgendermaßen abrufen:

{{{1}}} == Alpha
{{{2}}} == Beta
{{{A}}} == Gamma
{{{3}}} == Delta
{{{4}}} == Epsilon
{{{B}}} == Zeta
{{{5}}} == Eta

Bei Vorlagen mit vielen Parametern werden meist ausschließlich benannte Parameter verwendet, weil sich unbenannte Parameter schwer zuordnen lassen. Wenn ein Parameter mehrfach verwendet werden soll bzw. aus mehreren Teilen besteht, dann wird er häufig mit durchnummerierten Parametern verwendet:

{{Meine Vorlage
| Alpha    = A
| Beta     = B
| Gamma1   = C
| Gamma2   = D
| Gamma3   = E
| Gamma4   = F
| Delta1   = G
| Delta2   = H
| Delta3   = I
}}

Wenn gleichartigen Parameter in eine Zeile geschrieben werden, sieht das so aus:

{{Meine Vorlage
| Alpha    = A
| Beta     = B
| Gamma1   = C | Gamma2 = D | Gamma3 = E | Gamma4 = F
| Delta1   = G | Delta2 = H | Delta3 = I
}}

Bei kurzen Werten sind hier die Parameter länger als die Werte.

Mit {{#titleparts:…}} können Strings an Schrägstrichen zerlegt werden. Damit können die zusammemgehörigen Parameter zu einem String zusammengehängt werden und in der Vorlage wieder getrennt werden.

{{Meine Vorlage
| Alpha    = A
| Beta     = B
| Gamma    = C / D / E / F
| Delta    = G / H / I
}}

Allerdings ist die Vorlagenprogrammierung dann entsprechend aufwändig. Außerdem sind bei titleparts nicht alle Zeichen erlaubt. Es können keine Links verwendet werden und der Schrägstrich selbst entfällt auch als Nutzzeichen.

Eleganter wäre es, wenn wie bei unbenannten Parametern der senkrechte Strich verwendet werden könnte:

{{Meine Vorlage
| Alpha    = A
| Beta     = B
| Gamma    = C | D | E | F
| Delta    = G | H | I
}}

Wie eingangs erwähnt sind das aber bereits unbenannte Parameter der gesammten Vorlage und werden von Anfang durchnummeriert.

Verbesserungsvorschlag: Unbenannte Parameter, die nach einem benannten Parameter sind, bekommen zusätzlich zu der Variablen {{{<Zahl>}}} eine weitere Variable {{{<benannter Parameter><Zahl>}}}.

Bei dem eingangs erwähnten Beispiel sähe das folgendermaßen aus:

{{{1}}}             == Alpha
{{{2}}}             == Beta
{{{A}}}             == Gamma
{{{3}}} == {{{A1}}} == Delta
{{{4}}} == {{{A2}}} == Epsilon
{{{B}}}             == Zeta
{{{5}}} == {{{B1}}} == Eta

Eventuell wäre auch {{{<benannter Parameter>[<Zahl>]}}} denkbar:

{{{1}}}               == Alpha
{{{2}}}               == Beta
{{{A}}}               == Gamma
{{{3}}} == {{{A[1]}}} == Delta
{{{4}}} == {{{A[2]}}} == Epsilon
{{{B}}}               == Zeta
{{{5}}} == {{{B[1]}}} == Eta

Vor- und Nachteile

• Abwärtskompatible Syntaxerweiterung
• Syntaktischer Zucker
• Alle Tools zur Vorlagenauswertung müssen um die zusätzlichen Vorlagenparameterbezeichner erweitert werden

Diskussion

Meinungen zu diesem Vorschlag? --Fomafix 13:04, 19. Dez. 2011 (CET)

Keep it simple.--141.84.69.20 14:36, 21. Dez. 2011 (CET)

Variable einführen, die das Bearbeiten einer Vorlage in einem Abschnitt verhindert

Moin, bitte mal [5] lesen. Lässt sich eine Variable für den Vorlagenquelltext einführen, die sowas verhindert? XenonX3 - (☎:✉) 00:06, 31. Dez. 2011 (CET)

gudn tach!

sowas laesst sich mittels [6] verhindern, oder verstehe ich dich falsch?

ansonsten gibt's noch sowas: mw:Extension:ProtectSection, mw:Extension:ProtectText. -- seth 22:49, 4. Jan. 2012 (CET)

Nein, er sucht Wikipedia:IV#Exkurs: Section-Edit. Der neue Parser von 2008 wird zwar schon bald der alte sein, aber es funktioniert so wie es dargestellt ist. Ich habe mal der Überschrift einen „diese-Seite-Bearbeiten“-Bearbeitenlink hinzugestellt [7], allerdings fällt so die Überschrift aus dem Inhaltsverzeichnis. Sollte aber selten stören, hoffe ich. -- ✓ ^Bergi 21:09, 8. Jan. 2012 (CET)

Auto-Zusammenfassung für neue Diskussionsabschnitte mit irreführendem Bearbeitungskommentar

Leider ist es ziemlich verbreitet, einen neuen Diskussionsabschnitt zu beginnen, indem der bis dahin unterste Abschnitt bearbeitet wird und dort manuell eine Überschrift und der Text eingegeben wird. Wird die automatisch generierte Zusammenfassungszeile nicht geändert, steht dort dann der Titel des Abschnitts, der gar nicht verändert wurde. Solche Bearbeitungskommentare in der Beobachtungsliste sind irreführend, weil man glaubt, dass zu einem anderen Abschnitt beigetragen wurde. Besonders nervig ist es, wenn man die Beobachtungsliste über langsames mobiles Internet abruft und die Bedienung des Smartphones weniger komfortabel ist als eines Computers. Am Ende merkt man, dass einem der Bearbeitungskommentar in die Irre geführt hat und man die u. U. lange Ladezeit umsonst in Kauf genommen hat.
Nun zum Vorschlag: Könnte man es nicht so einrichten, dass in solchen Fällen eine Auto-Zusammenfassung ergänzt wird, also beispielsweise /* Überschrift anderer Abschnitt */ AZ: Neuen Abschnitt angefügt? Eine ähnlich gelagerte Diskussion befindet sich übrigens hier. --Leyo 10:42, 22. Dez. 2011 (CET)

Quetsch: Wikipedia:Verbesserungsvorschläge#Neuer Abschnitt / Abschnitt hinzufügen behandelt ebenfalls Ähnliches. --Diwas 01:57, 23. Dez. 2011 (CET)

Wenn dann schon gleich eine Erkennung, dass am bearbeiteten Abschnitt (oder auch einfach am Rest der Seite) nichts geändert wurde und gleich /* Neu: Abschnitt XAZ */. Gerne, klar, stell einen Bugantrag - ich bin aber eher pessimistisch dass sich ein Entwickler findet der das umsetzt. -- ✓ ^Bergi 15:18, 22. Dez. 2011 (CET)

Wie funktioniert denn überhaupt die Erkennung und Anwendung der Auto-Zusammenfassung? --Leyo 16:15, 22. Dez. 2011 (CET)

Die aktuell vorhandenen Auto-Zusammenfassungen sind im Gegensatz dazu sehr einfach gehalten. Sie greifen auf die Größe der Seite, oder auf andere Merkmal zurück, aber den Wikitext der Seite zu interpretieren macht die Sache wieder schwierigier. Ich finde es auch unschick und habe mir extra auf den Seiten mit dem '+' auch am Seitenende einen solches plus gemacht, um erst garnicht in Versuchung zu kommen, den letzten Abschnitt zu bearbeiten. Der Umherirrende 17:58, 23. Dez. 2011 (CET)

Fände das auch gut. Vielleicht bastel ich mal ein Script. Ähnliches Script ist das für automatische Unterschrift, da ist eine neue Überschrift am Ende einfacher zu erkennen. -- πϵρήλιο ℗ 17:38, 27. Dez. 2011 (CET)

Das Script befindet sich nun zum offenen Betatest unter Benutzer:Perhelion/sectionSummary.js. Wobei Abschnittsveränderungen mittendrin noch nicht unterstützt werden. -- πϵρήλιο ℗ 11:20, 7. Jan. 2012 (CET)

Danke! Das heisst mittendrin bzw. was passiert in einem solchen Fall? --Leyo 13:39, 7. Jan. 2012 (CET)

Das Script setzt in dem Fall einfach aus. An einer Erkennungsroutine arbeite ich gerade. Wenn es ein Gadget werden soll, muss es sehr sicher werden, jedoch vom Umfang trotzdem einfach gehalten. Ich benötige weitere Ideen für das Skript. Eine ist gerade hier erwähnt. -- πϵρήλιο ℗ 22:58, 8. Jan. 2012 (CET)

@Perhelion: Wirklich gut scheint die Abschnittserkennung leider noch nicht zu funktionieren: [8][9]. Da wäre mir kein Abschnittslink deutlich lieber als ein falscher :-)

BTW: Eine Überschrift muss nicht mit mit einem Gleichheitszeichen enden, es kann ein Kommentar dahinter folgen: Bug 28642#c5 – auch wenn ich das noch nie in freier Wildbahn gesehen habe. -- ✓ ^Bergi 01:40, 9. Jan. 2012 (CET)

Aja, danke der Hinweise, setze mich morgen daran. Eigentlich sollte das Skript sein Tun schon in der Vorschau oder Diff-Ansicht zeigen. Beim Revertieren sollte natürlich gar nichts passieren. Ziemlich Beta noch... -- πϵρήλιο ℗ 01:56, 9. Jan. 2012 (CET)

erledigtErledigt Habe das Skript um die erweiterte Erkennungsroutine mit Änderungen mitten im Text ergänzt. Es wird (erst) nach der Zeilenanzahl-Prüfung der Abschnitte (falls dort kein Treffer erzielt wurde) die Zeilenlänge überprüft. Man könnte es noch dahin erweitern, dass der Abschnitt mit den meisten Zeilenänderungen als Betreff genommen wird. Das Skript setzt jetzt nur an wenn es sich wirklich um einen eindeutigen Edit handelt (also mindestens ein Zeichen in der Textlänge geändert hat). Die erweiterte Erkennungsroutine setzt dann ein, wenn nichts an den Überschriften geändert wurde. (ein wenig optimieren könnte ich das Skript noch). Bitte mal testen. Lieben Gruß -- πϵρήλιο ℗ 15:17, 9. Jan. 2012 (CET)

Es läuft augenscheinlich immer noch schief: [10] -- ✓ ^Bergi 14:28, 10. Jan. 2012 (CET)

Das sollte mit dem letzten Update (0.41) behoben sein, oder es war eine noch ältere Version im Cache (danke). Am besten ihr bindet es selber mal ein. Doku Benutzer:Perhelion/sectionSummary, oder sollte es besser ThreadSummary heißen!?: -- πϵρήλιο ℗ 22:56, 11. Jan. 2012 (CET)