Wikipedia:Technik/Archiv/Baustellen/editsection

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Neuentwicklung von aufeinander abgestimmtem JS/CSS-Code im Zusammenhang mit Abschnittsüberschriften. Durch Benutzer konfigurierbar und an unterschiedliche Skins angepasst.

Problem

  • Die verschiedenen JS-Codes für die Links zur Bearbeitung von Abschnittsüberschriften sind über fünf MediaWiki-Seiten verstreut und kaum noch zu durchschauen; außerdem programmierungstechnisch veraltet.
  • Die Bezeichnungen der Benutzereinstellungen stimmen vorn und hinten nicht und sind (nach Änderungen weltweiter Implementierungen?) inzwischen teilweise unwirksam. MediaWiki:Gadget-editsection-right.js scheint wirkungslos.
  • Benutzer sollen von einer Umstellung nichts bemerken.
    • Gadgets müssten ihre Namen behalten, damit differenzierte Benutzeroptionen wirksam bleiben.
  • Vor einigen Jahren gab es wohl mal hitzige Debatten um das Erscheinungsbild dieser Links. Inzwischen haben sich die Gemüter abgekühlt; sofern sich durch Reorganisation das gewohnte Layout nicht drastisch ändert, würden Kleinigkeiten wohl hingenommen.

Lösungsansätze

Gadgets

Fomafix schlägt vor, den Code aus den festen Skin-Implementierungen für alle Benutzer in ein skinübergreifendes Gadget zu übertragen. Damit kann die Verschiebung von ganz rechts auf hinter die Überschrift realisiert werden. Dieses Gadget kann dann standardmäßig aktiviert werden, um den bisherigen Zustand zu erhalten.

  • Angemeldete Benutzer haben dann die Möglichkeit des opt-out.
  • Die für alle Leser und angemeldeten Benutzer ausgeführten Codes werden reduziert; teils auf Null gebracht.
  • Gadgets lassen sich mittels ResourceLoader elegant mit benötigten Modulen ausstatten.

Code

Es sollte ein zentrales Anwendungsobjekt gebildet werden. 

mw.libs.dewiki.editsection  =  {
};
  • Gadget-JS mag dann nur noch aus Konfiguration bestehen, wie zurzeit MediaWiki:Gadget-editsection-left.js.
  • Gadget-JS können .using(["site", "user"]) abwarten bzw. als dependencies deklarieren (CSS wäre aber ggf. sofort zu laden).
  • DOM wie bisher, oder jQuery? DOM H1...H6 ./. class .editsection?
  • Tests: de.wikipedia.beta.wmflabs.org
  • Anregungen: en:User:Drilnoth/lefteditlinks.js

Gestaltung und „Abschnitt hinzufügen“

Unterschiedliche Gestaltungen von Links im Zusammenhang mit Abschnittsüberschriften sollen zentral und aufeinander abgestimmt durch Benutzer und Skins konfiguriert werden können.

margin Überschrift1 [Bearbeiten]
Überschrift2 [Abschnitt hinzufügen * Bearbeiten]
adjacent Überschrift1 □ [Bearbeiten]
Überschrift2 □ [Bearbeiten * Abschnitt hinzufügen]
  • Die Vokabeln „Links“ und „Rechts“ werden nicht benutzt, um ggf. einmal i18n zu können; dann soll es auch auf RTL zu sehen sein.
  • Das ausgelieferte (möglicherweise Skin-spezifische?) HTML ist durch geeignete Klassen/ID zu ergänzen.
  • Pfeil hoch ist passend anzuschließen:
    [Bearbeiten] □ [↑]
  • Von Benutzern definiertes oldEditsectionLinks ist zu unterstützen, soll aber als deprecated→undokumentiertes Feature auslaufen.
  • Gleichzeitiges margin+adjacent (left+right) unterbinden, indem eine boolean definiert gesetzt wird.

Betroffene Ressourcen

MediaWiki:Common.js
MediaWiki:Common.css (#content skin-spezifisch, aber wurscht)
MediaWiki:Monobook.js
MediaWiki:Vector.js
MediaWiki:Gadget-editsection-left.js
MediaWiki:Gadget-editsection-left.css
MediaWiki:Gadget-editsection-right.js
MediaWiki:Gadget-editsection-right.css
MediaWiki:Gadget-Einleitung-bearbeiten.js
MediaWiki:Gadget-Pfeil-hoch.js
MediaWiki:Gadget-Pfeil-hoch.css

Diskussionen

Vorlaufdiskussion: Umherirrender März 2012

Kopiert von BD:Umherirrender --PerfektesChaos 22:51, 9. Mär. 2012 (CET)

Hi,

ich beziehe mich auf diese Verbesserung und rege folgende Verfeinerung der Gestaltung an:

Abschnittsüberschrift [Bearbeiten * Abschnitt hinzufügen]

Gründe:

  • „Bearbeiten“ unmittelbar an der Überschrift wie bei allen anderen
  • „Abschnitt hinzufügen“ verweist an das Ende
  • Optische Trennung der beiden Wortgruppen nur durch „|“ ist zu mager; mit Leerzeichen und einem breiteren Platzhalter als „|“ besser als zwei unterschiedliche Links wahrnehmbar.

Ich hoffe, dass jetzt die lästige Angewohnheit mancher Bearbeiter aufhört, an den letzten Abschnitt mit == einen neuen dranzuknallen – woraufhin das in der Summary die Bezeichnung des letzten, bekannten und schon abgegessenen Abschnitts erhält, und niemand auf der Beo mitbekommt, dass ein neues Thema begonnen hat.

LG --PerfektesChaos (D) 13:56, 8. Mär. 2012 (CET)

+1, insgesamt eine sehr gute Idee, aber die Langfassung wäre noch besser. --Krd 17:43, 8. Mär. 2012 (CET)
Ich habe den Bearbeitenlink rechts am Rand stehen, da ist es besser, wenn die Bearbeiten untereinander sind und das neue links davon. Über den Trenner lässt sich sicher streiten. Das Skript kopiert den Link von oben nach unten, das bedeutet bei Monobook ein "+", aber bei Vector gibt es dann die Langform, weil oben der Reiter auch mit langtext beschriftet ist. So gibt es zumindestens keine Probleme mit der Lokalisierung. Der Umherirrende 18:03, 8. Mär. 2012 (CET)
  1. Zur Langfassung:
    • Für den Anfang sollte das HTML-Element, das ja in der deutschsprachigen WP auf deren MediaWiki:Common.js definiert ist, als festkodiertes jQuery-Element gebaut werden, und die Zeichenkette "Abschnitt hinzufügen" ohne Spielkram benutzt werden.
    • Wenn es lokalisiert/i18n werden soll, müsste man ein internationales Gadget daraus machen. Dann steht die Beschriftung ja sicher in irgendeiner Systemnachricht, und die kann mit mw:ResourceLoader/Version 2 Design Specification #Implementation proposal für mw.message() verfügbar definiert werden. Das ist Zukunftsmusik und bedarf des RL2; darauf können wir gerne zurückkommen.
  2. Zur Links/rechts-Frage:
    • Über mw.user.options.get("gadget-editsection-left") oder mw.user.options.get("gadget-editsection-right") oder keines von beiden lässt sich herausfinden, ob sie am Fensterrand stehen oder nicht. Wobei ich keines von beiden habe, aber in der Wirkung offenbar gadget-editsection-right sehe; dies liegt wohl an mw.config.get("skin") = "vector".
Stets der Benutzerfreundlichkeit verpflichtet --PerfektesChaos (D) 19:02, 8. Mär. 2012 (CET)
Wenn ich es richtig verstehe, dann wird in der Monobook.js/Vector.js das ganze hinter die Überschrift gebracht. Mit Gadget-editsection-left kann man sie vor die Überschrift bekommen, mit Gadget-editsection-right oder oldEditsectionLinks an den rechten Rand. Wäre vermutlich besser, wenn man das Umdrehen mit in die Gadgets einbaut, dafür muss aber sicher gestellt sein, das site bereits gelaufen ist. Der Umherirrende 20:30, 8. Mär. 2012 (CET)
Wobei ich mich gerade frage, ob die beiden Gadgets überhaupt noch funktionieren.
  • editsection-right: Trifft erst nach site ein und kann dann nicht mehr wirken, es wirkt nur noch das CSS
  • editsection-left: Die Überschriften stehen rechts, außer der Bearbeiten-Link des Einleitungshelferlein
Einen richtigen Unterschied sehe ich da irgendwie nicht (mehr). Sehr verwirrend (war es aber auch wohl unter 1.18) Der Umherirrende 20:47, 8. Mär. 2012 (CET)
Das ist machbar. Ich beginne mal Richtung Wochenende, mir Gedanken zu machen, wie man robust und effizient mit den Einzelteilen und den aus dem vorhandenen Dokument und von ca- geerbten Verlinkungen eine geeignete Jonglage zaubert. Wenn ich das richtig deute, wäre nur editsection-right von einer Vertauschung betroffen, während die Standard-Reihenfolge für alle Benutzer (erst „Bearbeiten“, danach „Abschnitt hinzufügen“) auch bei editsection-left gilt, damit am linken Rand alle „Bearbeiten“ untereinander stehen. Wenn mir jemand zuvorkommt, bin ich auch nicht böse. Danke schon mal für die optische Trennung der beiden Links. --PerfektesChaos (D) 20:59, 8. Mär. 2012 (CET)
Jetzt bin ich auch verwirrt.
  • Die Beschreibung in editsection-right.js stimmt nicht mit dem überein, was sowieso schon passiert. Der Name von editsection-left passt überhaupt nicht zu dem, was tatsächlich stattfindet.
  • oldEditsectionLinks wird anscheinend nur von MediaWiki:Monobook.js/MediaWiki:Vector.js benutzt, nicht aber von MediaWiki:Common.js. Das sollte aus der globalen Variablerei verschwinden, etwa als mw.libs.dewiki.editsectionLinksLeft. „old“ gibt es sowieso nicht; wie viel Jahre alt ist ein old? Auf benutzerdefiniertes oldEditsectionLinks kann man weiterhin reagieren; wenn jemand sich seinen eigenen Namensraum zukleistert, ist das okay.
  • Die ganze Angelegenheit sollte im Paket aufgearbeitet werden; zusammen mit Einleitungshelferlein ggf. auf jQuery und den Skin-Skripten geschlossen gelöst werden.
  • Zuerst sollte mal präzise beschrieben werden, was eigentlich wann mit/ohne welchem Gadget unter welcher Skin passieren soll.
Oje. --PerfektesChaos (D) 21:50, 8. Mär. 2012 (CET)

Ich benutze zwar fast immer die Tastatur, um einen neuen Abschnitt zu erzeugen, möchte mich aber trotzdem für die Idee und die Umsetzung bedanken. Coole Sache, das. Dankeschön und Gruß von --Schniggendiller Diskussion 01:39, 9. Mär. 2012 (CET)

Ein herzliches Dankeschön auch von meiner Seite! Sobald davon ausgegangen werden kann, dass es keine Änderungen am neuen Feature mehr gibt, kann dann auch die Vorlage:Hinweis neuer Abschnitt angepasst werden. --Leyo 10:17, 9. Mär. 2012 (CET)
Ich gehöre zu denjenigen, die der Ansicht sind, dass der Bearbeiten-Link zuerst kommen sollte; außerdem gibt es durch den Code einen doppelten Accesskey, sodass ein Alt-Shift-+ erst noch durch Enter bestätigt werden muss (zumindest im Firefox). Ich schlage daher diese Änderungen vor, sie sind auch getestet (im Debug-Mode wegen des grandiosen Cache-Verhaltens). --Schnark 11:25, 9. Mär. 2012 (CET)
Und eine Stunde später ist der Cache sogar im normalen Modus aktuell! Hat da womöglich jemand inzwischen den Bug behoben? --Schnark 12:26, 9. Mär. 2012 (CET)
Doppelter Acesskey ist natürlich ungünstig. Über die Reihenfolge lässt sich, wie schon angedeutet, streiten. Ich habe es aber trotzdem gemacht. Die Idee war aber nicht von mir, siehe Wikipedia:Verbesserungsvorschläge#Zusammenfassung. Der Umherirrende 16:03, 9. Mär. 2012 (CET)

@Leyo (Null-Edit-BK: „sollte der Abschnitt ev. besser nach MediaWiki Diskussion:Common.js verschoben werden?“):

  • Ich bereite derzeit die Einrichtung von Wikipedia:Technik/Baustellen/editsection vor. Grund: Es sind drei Gadgets (einschließlich Pfeil-hoch) betroffen, dazu mindestens drei CSS-Seiten und MediaWiki:Common.js, MediaWiki:Monobook.js, MediaWiki:Vector.js. Das sind ca. 8 Seiten, die alle irgendwie an dieser Abschnittsüberschrift herumbasteln, und die allmählich mal unter den neuen Bedingungen koordiniert werden müssten.
  • Die Disku sollte nicht auf einer Einzelseite davon, sondern zentral erfolgen – und es sollte eine Gesamtlösung herauskommen, die auch langfristig i18n/RTL/RL2 ist.

Grüße --PerfektesChaos (D) 11:46, 9. Mär. 2012 (CET)

Vorlaufdiskussion: Umherirrender Februar 2013

Kopiert von BD:Umherirrender --PerfektesChaos 10:30, 7. Mär. 2013 (CET)

Hi, ich nochmal,

ich hatte soeben die Hilfe:Bearbeiten-Links in der Mache, weil die bisherige Version nun völliger Kokolores war.

  • Dabei fiel ich über eine wirre Formulierung unter Einstellungen, die weder unter monobook noch vector hinkommt. Richtig ist:
    • left – Links erscheinen am rechten Fensterrand
    • right – Links erscheinen unmittelbar neben der Abschnittsüberschrift, bloß bei vector kleiner. Braucht man das noch?
  • Ich habe die Dingsdas nicht aktiviert, und auf vector stehen sie immer in Normalschrift unmittelbar neben der Abschnittsüberschrift.
  • Was da momentan auf Spezial:Einstellungen #mw-prefsection-gadgets steht, ist so falsch, dass noch nicht einmal das Gegenteil stimmt.

Ich kapier es nicht. --PerfektesChaos 22:17, 19. Feb. 2013 (CET)

Ich auch nicht. Man sollte mal die Ersteller der beiden Gadgets fragen, ob das noch wie gewünscht funktioniert. Es hatte aber mal jemand unter Wikipedia:Technik/Baustellen/editsection angefangen, das aufzulösen, was aber noch nicht geglückt ist. Der Umherirrende 18:50, 20. Feb. 2013 (CET)
Ach das Dings war das. Ich hatte nicht drauf geachtet.
  • Dann schließe ich hier und tauche mit einer Kopie in den nächsten Tagen an dem Werkstatt-Abschnitt wieder auf.
  • Mein Eindruck ist, dass es vor Jahren mal ein anderes CSS gab; dewiki oder weltweit. Das hatte man irgendwie zu erben versucht. Wenn es in allen (mindestens gängigen) Skins heutzutage von selbst geht, dann kann right raus und das left kann ggf. als Gadget einen sinnvolleren Namen bekommen; als Option muss dieser Bezeichner aber ohnehin erhalten bleiben.
  • Vielleicht lesen Fomafix oder andere alte Kämpen mit und können sich noch erinnern.
Schönen Abend --PerfektesChaos 23:02, 20. Feb. 2013 (CET)
Ja, hier müsste mal zuerst der Code aufgeräumt werden. Was damals mal schnell als Gadget angelegt wurde, hat mir noch nie gefallen. Meiner Meinung sollte der ganze bisherige Code entfernt werden, damit die Standardeinstellungen von MediaWiki aktiv werden. Anschließend kann mit einem skinübergreifenden Gadget die Verschiebung von ganz rechts auf hinter die Überschrift realisiert werden. Dieses Gadget kann dann standardmäßig aktiviert werden, um den bisherigen Zustand zu erhalten. --Fomafix (Diskussion) 08:40, 21. Feb. 2013 (CET)

Änderung MediaWiki: Verschiebung des Bearbeitenlink hinter den Header

Mit gerrit:49364 wird es wohl von .editsection nach .mw-editsection gehen und der Link steht hinter der Überschrift. Der Umherirrende 20:40, 29. Apr. 2013 (CEST)

Die Änderung ist bereits live. Mit dieser Änderung vereinfacht sich unsere Baustelle extrem. Durch die Änderung ist die bisherige dewiki-Standardeinstellung zum globalen Standard geworden. Aller JavaScript-Code und alle CSS-Definitionen können daher entfernt werden.
Wir können ein neues Gadget anlegen, das die Bearbeitungsknöpfe wieder an den rechten Rand verschiebt. Dafür kann die einfach CSS-Definition von meta:Change to section edit links#If you don't like this change genutzt werden:
.ltr .mw-editsection {
	float: right;
	font-size: 13px;
}
.rtl .mw-editsection {
	float: left;
	font-size: 13px;
}
Die beiden bestehenden Gadgets editsection-right und editsection-left können meiner Meinung nach ersatzlos entfallen.
Das Gadget Einleitung-bearbeiten.js muss angepasst werden.
Die CSS-Klasse editsection wird in vielen anderen Vorlagen verwendet. Es muss geprüft werden, ob die neue Definition aus dem Core ausreicht. --Fomafix (Diskussion) 08:32, 30. Apr. 2013 (CEST)
+1
Die bisherigen beiden Benutzer-Einstellungen können wirkungslos werden.
Wer das überhaupt noch zu seinem Lebensglück braucht, muss sich dann eben einmalig zu einem opt-in bequemen.
Der neue Name sollte intern unmissverständlich und seitenneutral sein, etwa editsection-align-margin.
font-size in px oder relativ zu einer Basis-Schriftgröße machbar (nicht die wechselnde Größe der Überschriften erben!)?
Ich hab das noch nie gebraucht; wenn das Link mit gehörigem Abstand (mehr als ein oder zwei Leerzeichen) auf die Abschnitts-Überschrift folgt, bin ich glücklich. Rechtsbündige Anordnung mag hübscher sein, aber bei manchen systematischen Ein-Zeilen-Abschnitten geht die Zuordnung flöten.
Nur zu --PerfektesChaos 09:19, 30. Apr. 2013 (CEST)
Die Änderung ist aktuell auf test.wikipedia und mediawiki.org zu sehen, aber hier wohl erst am 8. Mai. Der Umherirrende 19:57, 30. Apr. 2013 (CEST)
Ich habe inzwischen auch festgestellt, dass diese Änderung hier noch nicht aktiv ist. Seltsamerweise wirkt vermutlich seit heute die Zeile var oldEditsectionLinks = true; in meiner Benutzer:Fomafix/monobook.js nicht mehr auf MediaWiki:Monobook.js aus, denn bei mir sind die Bearbeitungsknöpfe wieder direkt hinter der Überschrift. --Fomafix (Diskussion) 22:15, 30. Apr. 2013 (CEST)
Ist bei mir genauso: var oldEditsectionLinks = true; in meiner common.js wirkt nicht mehr (weder in Monobook noch in Vector, es sollte aber in beiden Skins wirken). Nebenbei wirkt auch mw.config.set('dontShowTopicons', true); in meiner vector.js nicht mehr. Was ist da kaputt? --Entlinkt (Diskussion) 08:57, 1. Mai 2013 (CEST)
Es muss wohl die Ladereihenfolge geändert worden sein, so dass erst die Funktion innerhalb $() in MediaWiki:Monobook.js ausgeführt wird, bevor die Benutzer-Scripte ausgeführt werden. --Fomafix (Diskussion) 09:21, 1. Mai 2013 (CEST)
Nicht die Ladereihenfolge, aber es wird seit Kurzem am Ende des <body> $.ready() aufgerufen, womit aller Code, der auf per $() auf das ready-Event wartet früher aufgerufen wird (so wie in der Vergangenheit addOnLoadHook). In meinen Augen ein furchtbarer Hack, der (und das macht das Ganze nur noch schlimmer) eingeführt wurde um die document.write behalten zu können. --Schnark 10:29, 1. Mai 2013 (CEST)
dontShowTopicons sollte unter Vector-Skin auch wieder funktionieren. Der Umherirrende 18:24, 1. Mai 2013 (CEST)
  • Sowas Ähnliches hatten wir schon mal.
  • Das oldEditsectionLinks kann gerne weiterhin als legacy unterstützt werden; aber parallel und für neue Benutzer sollte es editsectionMargin=true heißen. In dem ganzen Wirrwarr findet sich ja keiner mehr durch, welche Wirkung Variablen haben mögen mit Namen wie oldOption, newOption, newerOption, olderOption, oldNewOption.
    • Während die Konfiguration per Häkchen in den Einstellungen mit Wegfall der alten Helferlein-Namen ein neues opt-in erfordert, können wir die alte globale Variable weiterhin unterstützen.
    • Eine Abfrage nach window.editsectionMargin || window.oldEditsectionLinks bedarf keiner Verrenkungen hinsichtlich undefined.
    • Falls ich die Beschreibung richtig gelesen habe, würde MediaWiki:Monobook.js perspektivisch das neu zu erstellende Helferlein aufrufen; bzw. seinen CSS-Code aktivieren.
    • Die Implementierung in den Standard-Ressourcen Common.js und Monobook.js sollte so kurz wie möglich gehalten werden und die konkreten Implementierungsdetails sollten zentral im Gadget verwaltet werden; dem wäre notfalls auch die aktuelle Skin bekannt (CSS wie JS).
  • Unsere MW:*.js sollten dann bereits jetzt ansatzweise in diesem Sinn geändert werden.
Schönen Feiertag --PerfektesChaos 13:41, 1. Mai 2013 (CEST)
Ich wäre dafür, weder oldEditsectionLinks legacymäßig weiter zu unterstützen noch editsectionMargin neu einzuführen, sondern den JavaScript-Kram bei dieser Gelegenheit so weit wie möglich schlicht abzuschaffen und den Benutzern zu sagen, dass sie einmalig ein Gadget aktivieren müssten, um das alte Aussehen zurückzubekommen. Das Gadget ließe sich wohl allein mit CSS realisieren (es sieht dann zwar nicht in allen Fällen gleich aus wie bisher, aber in fast allen).
Da sich ohnehin die Schriftgröße ändern wird (die Links sind per CSS neu standardmäßig x-small), wird die Änderung schon genug Staub aufwirbeln, so dass ich es vertretbar fände, bei dieser Gelegenheit gleich möglichst viel Ballast wegzuwerfen. --Entlinkt (Diskussion) 14:31, 1. Mai 2013 (CEST)
Was mich bei der Ausführungsreihenfolge nur wundert, das es so plötzlich kommt, ohne das es einen Softwareupdate gab. Sieht eher so aus, das die Bearbeitung der Common.js dazu geführt hat. Der Umherirrende 17:24, 1. Mai 2013 (CEST)
Verzögerungstaktik funktioniert (nur der Cache ist so hartnäckig - Nein! Er hat seine 5 Minuten ;-) Jetzt als Bug 47941 Der Umherirrende 18:24, 1. Mai 2013 (CEST) ). Der Umherirrende 17:30, 1. Mai 2013 (CEST)
Es war ein Software-Update: gerrit:61494, vermutlich wurde das direkt aus dem master übernommen, damit WikiLove und ähnliches wieder funktioniert. Der Umherirrende 18:24, 1. Mai 2013 (CEST)
Die Änderungen an der Ausführungsreihenfolge werden übrigens in bugzilla:47872 thematisiert. --Schnark 10:13, 2. Mai 2013 (CEST)
  • Den ehrwürdigen Oldgedienten können wir noch soviel Service angedeihen lassen, dass wir das oldEditsectionLinks stillschweigend weiter unterstützen.
    • Manche tun sich halt schwer mit sowas.
    • Es muss ja nicht prominent dokumentiert und empfohlen werden; eine unauffällige Erwähnung als deprecated unter Ferner liefen reicht.
    • Auf keinen Fall sollte der JS-Code eigenen CSS-Code enthalten, der wieder gepflegt werden müsste. Vielmehr etwa in .using("user"):
if (window.oldEditsectionLinks) {
   mw.loader.load("//de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-*******.css&action=raw&ctype=text/css",
                  "text/css");
}
  • Mich selbst interessiert das nicht; ich habe das nie gebraucht, bei mir steht das hinter der Überschrift; und wenn das nicht sein soll, wüsste ich wie die Kollegen andere Wege.
  • Ich habe nie eine Spezifikation gesehen; insofern weiß ich auch nicht, was geleistet werden soll und mit welchen möglichen Optionen? Offenbar irgendwas am Rand ausrichten, und vielleicht auch mit Schriftgröße?
    • Wenn es nur eine feste Alternative anschließend/rechtsbündig sein soll, reicht CSS pur und ein Häkchen. Wenn noch Optionen hinzukommen sollen, bräuchte es mehr. Dann können sich die Leute aber auch Schnipsel auf MyPage/ kopieren.
    • Gibt es Unterschiede in den Skins? Was soll das existierende Monobook-Gerödel?
  • Ist für alle Benutzer die Schriftgröße x-small recht?

Baldiges Wochenende --PerfektesChaos 09:16, 3. Mai 2013 (CEST)

Font-size wurde auf small geändert (gerrit:62072). Wenn du ein Gadget irgendwo laden möchtest, reicht ein mw.loader.load( 'gadget.****' ), da jedes Gadget auch ein Modul ist. Der Umherirrende 09:24, 3. Mai 2013 (CEST)
oldEditsectionLinks ist eine Variable zum Deaktivieren von JavaScript-Code. In Zukunft benötigen wir für diese Darstellungsform kein JavaScript mehr. Die folgende einfache CSS-Definition reicht:
.ltr .mw-editsection {
	float: right;
}
.rtl .mw-editsection {
	float: left;
}
Die Zeilen font-size: 13px; sind entfernt worden. Die CSS-Definition kann ganz einfach als neues Gadget realisiert werden. Jetzt extra zusätzlichen JavaScript-Code hinzuzufügen, nur um oldEditsectionLinks weiterhin zu unterstützen, würde ich unbedingt vermeiden. --Fomafix (Diskussion) 09:46, 3. Mai 2013 (CEST)
Zustimmung zu Fomafix. Wenn oldEditsectionLinks plötzlich nicht mehr unterstützt wird, geht nichts kaputt, nichts verschwindet und nichts wird plötzlich ungewollt aktiv. Die Bearbeiten-Links wandern nur von der einen Seite zur anderen, das ist alles. Das bieten wir als reines CSS-Gadget für diejenigen an, die es unbedingt wieder haben wollen. Fertig. Extra Code, der ein Gadget nachlädt, obwohl man es gar nicht aktiviert hat, stiftet nur Verwirrung. Üblicherweise ist es sowieso so, dass die meisten Benutzer mit so einer Einstellung eine Änderung einfach hinnehmen, weil sie gar nicht mehr wissen, dass sie irgendwann mal etwas daran geändert hatten. --TMg 10:23, 3. Mai 2013 (CEST)
+1 zu oldEditsectionLinks einfach sterben lassen. Es kann nämlich auch sein, dass ein Benutzer diese Variable gesetzt hat, weil ihm die JavaScript-Lösung zu langsam war (alte Rechner kamen auf Seiten mit vielen Abschnitten schwer ins Keuchen), aber prinzipiell damit einverstanden ist, die Links zu verschieben. --Schnark 10:58, 3. Mai 2013 (CEST)
Dann sollten wir uns nur noch auf einen Namen für das Gadget einigen. Dann kann es direkt am 8. Mai auch aktiviert werden. Man kann es vermutlich auch vorher schon aktivieren, nur funktioniert es dann nicht. Ich wundere mich aber, das hier noch ltr und rtl extra abgefragt werden. Wird user-css oder gadget-css nicht automatisch geflippt? Der Umherirrende 11:03, 3. Mai 2013 (CEST)
Automatisch geflippt wird auf Basis der Benutzersprache (wgUserLanguage). Hier wird aber die Seiteninhaltssprache (wgPageContentLanguage) benötigt. Möglicherweise muss daher noch ein /* @noflip */ hinzugefügt werden. Ich würde mich eigentlich auch eher an https://gerrit.wikimedia.org/r/#/c/49364/37/skins/common/shared.css orientieren:
/* @noflip */
.mw-content-ltr .mw-editsection,
.mw-content-rtl .mw-content-ltr .mw-editsection {
	float: right;
}
/* @noflip */
.mw-content-rtl .mw-editsection,
.mw-content-ltr .mw-content-rtl .mw-editsection {
	float: left;
}
Als Name für das Gadget schlage ich mal editsection-float-right vor, bin aber nicht so ganz glücklich. --Fomafix (Diskussion) 11:25, 3. Mai 2013 (CEST)
Ich nannte oben bereits editsectionMargin.
  • Heißt: Schiebe an den Rand, wo immer der sein mag.
  • In editsection ist bereits enthalten, dass man über ein Link zu editieren wünscht; was sonst? editsectionLink wäre doppelt.
VG --PerfektesChaos 11:43, 3. Mai 2013 (CEST)
Mir gefällt editsection-align-margin besser (so wie oben). Oder man überschreibt einfach das jetzt überflüssige editsection-align-right, schließlich haben wir hier LTR-Text und somit ist der Link rechts. --Patrick87 (Diskussion) 13:09, 3. Mai 2013 (CEST)
editsection-float, also ohne Richtung wäre auch möglich. Margin erinnert mich immer an CSS und den Abstand zum Rand, nicht direkt den Rand. Der Umherirrende 13:39, 3. Mai 2013 (CEST)
Nur das "float" wie du schon sagst sowohl links als auch rechts bedeuten kann und damit schlussendlich gar nichts aussagt, wenn man nicht schon weiß was gemeint ist. "Margin" heißt übrigens auch einfach "Seitenrand" (ganz ohne an CSS-Ränder zu denken) und genau das wollen wir doch aussagen, oder? --Patrick87 (Diskussion) 14:19, 3. Mai 2013 (CEST)
float gehört buchstäblich zum Fließtext und bedeutet: „Die umgebenden Zeilen sollen das Element umfließen.“ Das ist nicht wirklich das, was wir für die nächsten Jahre zum Ausdruck bringen wollen. VG --PerfektesChaos 23:35, 3. Mai 2013 (CEST)
editsection-position. --TMg 16:32, 4. Mai 2013 (CEST)
Ja – und wie entnehme ich dem Wort position im Lauf der Jahre, ob der Benutzerwunsch heißen soll: Direkt folgend; oder am äußeren Rand, oder wo immer? Dieses Theater mit -left und -right in wechselndem Skin-bezogenem Kontext war ja gerade der Auslöser für das obige Wirrwarr. VG --PerfektesChaos 16:43, 4. Mai 2013 (CEST)
Dann halt editsection-alternative-position oder was weiß ich. Hauptsache, es steht nicht mehr links oder rechts drin. Wurde in dieser Diskussion nicht festgestellt, dass das abhängig von der eingestellten Sprache falsch wäre? --TMg 16:53, 4. Mai 2013 (CEST)
alternative-position sagt mir wiederum nicht, wo die Benutzer die Links haben möchten.
  • Bei diesem Gadget geht es darum, dass sie die bündig am Rand ausgerichtet haben möchten; völlig egal, wo die momentane Standard-Einstellung gerade liegt. Dieser Wunsch ist im Namen des Gadget abzubilden.
  • Im Lauf der Jahre wurde mal weltweit, mal deWiki-lokal, mal pro Skin unterschiedlich positioniert; alle paar Jahre anders.
    • alternative-position sagt mir wieder nur, dass es irgendwie anders als die momentane Systemkonfiguration sein soll. Das ist aber nicht der Benutzerwunsch; zumindest nicht auf Dauer.
    • Alle Namen mit old, new, left, right, alternative, change sagen mir aber nicht, welches der Benutzerwunsch ist.
  • Es kann daher nur um editsectionMargin gehen, wie oben bereits zweimal dargestellt.
VG --PerfektesChaos 17:30, 4. Mai 2013 (CEST)
Namen mit left oder right sind nicht treffend, denn bei RTL-Text ist das eben vertauscht. Wie wäre es stattdessen mit start und end? CSS3 sieht diese Werte bei text-align vor: http://dev.w3.org/csswg/css-text/#text-align. Als Name für das Gadget würde sich daher editsection-align-end-margin anbieten. --Fomafix (Diskussion) 19:24, 4. Mai 2013 (CEST)
Um dieses ganze Theater mal auf das Wesentliche 'runter zu brechen (ich kann es kaum glauben, dass wir uns hier ernsthaft um den Namen streiten, schließlich ist der Inhalt doch das Entscheidende):
  • Möglichkeit 1: Wir verwenden das Stichwort "right". Das ist zwar streng genommen nicht ganz richtig, da es in RTL-Text nicht stimmt, aber wir sind doch verd*** nochmal die deutsche Wikipedia. Und die deutsche Wikipedia wird doch wohl auf absehbarer Zeit ausschließlich LTR-Text enthalten? Vorteil von dieser Benennung ist eindeutig, dass jeder sofort weiß worum es geht: Bearbeiten-Links nach rechts! (Mein) bevorzugter Name in diesem Fall ganz klar editsection-align-right.
  • Möglichkeit 2: Wir lassen "left" und "right" raus. Dann müssen wir beschreiben was der Code macht, nämlich den Bearbeiten-Link an den Seitenrand verschieben. Dann würde ich vorschlagen editsection-align-margin oder (falls jetzt jemand damit kommt, dass damit ja auch der linke Seitenrand gemeint sein könnte) editsection-align-end. Mit letzterem wären wir auch absolut mit der CSS Eigenschaft text-align:end; im Einklang, und Ausrichtung am Zeilenende ist nun wirklich unmissverständlich. --Patrick87 (Diskussion) 02:40, 5. Mai 2013 (CEST)
  • Der jetzt gewählte Name (für Anwender unsichtbar) ist für viele Jahre unveränderlich. Während wir in den Benutzer-JS-Seiten zumindest noch sehen können, wie oft welcher Variablenname gewählt wurde, sind die gewählten Benutzereinstellungen privat. Eine Umbenennung ist nicht möglich, nur eine Löschung der Option.
  • Der Name muss zweifelsfrei den Benutzerwunsch zum Ausdruck bringen, der da lautet: Richte mir die editsection (=Links) am Rand bündig aus; und das über Jahrzehnte wirksam und für zukünftige Programmierer noch nachvollziehbar.
  • Der Kontext ändert sich alle zwei Jahre; sei es weltweit, in der deWP, oder durch Bastelei an existierenden oder zukünftigen Skins. In der Vergangenheit wurde häufig sehr kurzsichtig und „pragmatisch“ gehandelt und auch ungenügend dokumentiert, was gerade in diesem Fall hier zu einem unentwirrbaren Durcheinander geführt hatte; siehe weiter oben.
  • Wenn wir schon mit Englisch umherschmeißen, sollten wir uns auch angewöhnen, internationalisiert zu denken und zu handeln.
  • Benutzer haben teils große Schwierigkeiten, mit der Systemkonfiguration klarzukommen. Sie sollen guten Artikelinhalt produzieren und so selten wie möglich mit irgendwelchem Technik-Kram belästigt werden. Aufgabe der „Skriptbastler“ ist es, sie dabei so gut als möglich zu unterstützen.
Schönen Sonntag --PerfektesChaos 10:17, 5. Mai 2013 (CEST)
MediaWiki:Gadget-editsection-align-end und MediaWiki:Gadget-editsection-align-end.css sind angelegt und auch eingetragen und somit auswählbar. Die beiden bestehenden Helferlein habe ich auch mit einem Hinweis versehen. Jetzt müsste man nur die verlinkte Hilfeseite Hilfe:Bearbeiten-Links noch aufarbeiten. Der Umherirrende 18:59, 5. Mai 2013 (CEST)
Ist OK, ich fänd’s aber cool, wenn das wikiübergreifend einheitlich ist. Falls also in der englischen Wikipedia oder auf Commons oder sonst irgendeinem bedeutenden Wiki auch so ein Gadget angelegt wird (bislang habe ich keines gesehen) und es dann noch nicht zu spät ist, könnte man sich überlegen, dem zu folgen. --Entlinkt (Diskussion) 19:27, 5. Mai 2013 (CEST)
Damit hätte ich auch kein Problem, an den Seiten darf sich gerne jeder Admin vergreifen, wollte nur nicht, das es bis Mittwoch verschlafen wird. Der Umherirrende 19:29, 5. Mai 2013 (CEST)
Kein Problem, sollte keine Kritik sein; ich hatte deshalb noch abgewartet, aber das muss man ja nicht (vielleicht macht ja auch kein anderes Wiki ein Gadget).
Ein Anliegen hätte ich aber noch. Durch die Softwareumstellung werden sich für Monobook-User die Schriftgrößen ändern (bisher: x-small ~ 10px, Beispiel, zukünftig small ~13px, Beispiel).
Ich gehe davon aus, dass viele Benutzer wünschen werden, dass das wieder zurückgeändert wird. Es sollte dann aber – wenn überhaupt – nur für Monobook zurückgeändert werden (Vector hat seit Beginn die größere Schrift und ich sehe keinen Grund, das zu ändern). --Entlinkt (Diskussion) 22:24, 5. Mai 2013 (CEST)
Die Schriftgröße ändert sich aber nur für Benutzer, die aktuell Monobook, aber nicht oldEditsectionLinks verwenden. Man könnte die Größe jetzt schon an das größe anpassen, oder in Monobook.css etwas dagegen steuern, nur müsste man das im Gadget wieder überschreiben, weil man im css nicht erkennen kann, ob das Gadget aktiv ist. Da habe ich keine Idee zu. Der Umherirrende 20:45, 6. Mai 2013 (CEST)
Ja, die Monobook-User ohne oldEditsectionLinks meinte ich, das dürfte die Mehrheit der Poweruser sein, aber nur eine kleine Minderheit der Gesamtnutzer der Wikipedia.
Ich meinte das jetzt auch gar nicht als Aufforderung, etwas zu tun, sondern nur als Mutmaßung „es könnte gut sein, dass …“ und würde einfach abwarten, was wirklich passiert … Mir geht es vor allem darum, dass am Mittwoch nicht überstürzt .mw-editsection { font-size: x-small; } in der Common.css landet. Gruß --Entlinkt (Diskussion) 21:17, 6. Mai 2013 (CEST)
PS: In der englischen Wikipedia ist die Änderung seit heute bereits aktiv, aber es wurde bislang noch kein Gadget angelegt.
Hier bei uns sind die neuen Links auf Dateibeschreibungsseiten von Commonsbildern bereits zu sehen (bspw. Datei:Coelodonta antiquitatis .jpg#Beschreibung), und zwar riesengroß, weil die Styles zur neuen Klasse mw-editsection noch fehlen. Das wird sich aber am Mittwoch legen. --Entlinkt (Diskussion) 22:47, 6. Mai 2013 (CEST)
PPS: Ich muss das präzisieren – das Problem mit Beschreibungsseiten von Commonsbildern wird sich morgen nur in Bezug auf die Schriftgröße automatisch lösen. Das neue Gadget wird auf diesen Seiten so nicht funktionieren, weil die Klasse .mw-content-ltr auf Beschreibungsseiten von Commonsbildern nicht existiert. Ich würde zwecks Konsistenz mit der Deklaration von margin-left in shared.css einfach eine Regel .mw-editsection { float: right; } hinzufügen. (Die Deklaration von margin-left ist allerdings auch wieder fehlerhaft/unvollständig – wenn man den Abstand auf einer Seite setzt, sollte man ihn natürlich auf der anderen Seite zurücksetzen.) --Entlinkt (Diskussion) 19:02, 7. Mai 2013 (CEST)
Richtig erkannt. Die Bildbeschreibungsseiten sind in Benutzersprache und nicht in Content-Sprache. Die folgende zusätzliche Definition in MediaWiki:Gadget-editsection-align-end.css sollte das beheben.
.mw-editsection {
	float: right;
}
Diese Definition wird automatisch entsprechend der Benutzersprache geflippt und wird durch die bereits bestehenden Definition überschrieben, wenn eine Content-Sprache existiert. --Fomafix (Diskussion) 22:52, 7. Mai 2013 (CEST)
Ist aufgenommen. Sobald die Änderung morgen live ist, sollte dann noch aus Vorlage:Dokumentation die Klasse editsection entfernt werden, um Wechselwirkungen zu vermeiden. --Entlinkt (Diskussion) 23:33, 7. Mai 2013 (CEST)
Das ist vermutlich ein größeres Thema, weil in weiteren Vorlagen die CSS-Klasse editsection verwendet wird. Ich mache hier eine separate Überschrift auf. --Fomafix (Diskussion) 11:24, 8. Mai 2013 (CEST)
Mittlerweile ist en:MediaWiki:Gadget-righteditlinks.css angelegt worden – und zwar ziemlich zeitgleich mit der Aktivierung der Änderung hier bei uns. Schade, dann gibt’s halt keinen international einheitlichen Namen … --Entlinkt (Diskussion) 02:38, 9. Mai 2013 (CEST)

Entfernung der CSS-Klasse editsection

Mit gerrit:61075 wird voraussichtlich ab 7. Juni 2013 die bestehende CSS-Klasse editsection entfernt. Diese Klasse wird in einigen Vorlagen verwendet:

Bitte weitere Vorlagen hier eintragen.

Bis dahin muss geklärt werden, was an den Vorlagen angepasst werden muss. --Fomafix (Diskussion) 11:24, 8. Mai 2013 (CEST)

Vorlage:Dokumentation ist meiner Meinung nach erledigt, der Link sieht nun in allen Skins mit und ohne Gadget wie ein „normaler“ Original-MediaWiki-Bearbeitenlink aus, nachdem er ein paar Jahre lang in diversen Skin-Gadget-Kombinationen ganz anders aussah. --Entlinkt (Diskussion) 02:38, 9. Mai 2013 (CEST)

Probleme mit der neuen mw-editsection

Bearbeiten-Link wird zu hoch angezeigt

Ist sonst noch jemandem aufgefallen, dass der Bearbeiten-Link zu hoch angezeigt wird, wenn man ihn wie gehabt an den rechten Seitenrand rückt? Die Grundlinie des "Bearbeiten"-Textes sollte doch bündig mit der Grundlinie der Überschrift sein? Tatsächlich ragt er jedoch sogar über oberen Rand der Überschrift hinaus. --Patrick87 (Diskussion) 19:26, 9. Mai 2013 (CEST)

Ja, der Link wird jetzt innerhalb der content-box der Überschrift obenbündig angezeigt (vorher untenbündig). Das vorherige Verhalten ist also genau wie von dir beschrieben (und wie es m. E. auch sein sollte), das jetzige nicht ganz (der Link ragt tatsächlich nicht nach oben über die Überschrift hinaus, das sieht nur ein bisschen so aus, weil die Schrift der Bearbeitenlinks kleiner als der Text der Überschrift ist).
Das ist nicht wirklich zufriedenstellend und war wohl auch einer der Gründe, weshalb die Links bis jetzt im HTML-Quelltext vor den Überschriften standen. Nun hat man entschieden, die Reihenfolge im Quelltext zu ändern, weil es für die „Flattersatz-Darstellung“ günstiger ist, und ich kenne ehrlich gesagt auch keinen einfachen CSS-Workaround. --Entlinkt (Diskussion) 19:42, 9. Mai 2013 (CEST)
Oh doch, zumindest bei mir im Vector Skin ragen die Bearbeiten-Links über die Überschrift hinaus. Zwischen der Oberkannte des "B"s in der Überschrift dieses Abschnitts und der Oberkannte des "B"s im zugehörigen Bearbeiten-Link liegen zwei Pixel (das ist viel wenn das "B" selbst nur 10 Pixel hoch ist). --Patrick87 (Diskussion) 19:52, 9. Mai 2013 (CEST)
Ich meinte das CSS-technisch auf die Boxen bezogen (kann man mit Firebug, Chrome DevTools, Opera Dragonfly & Co. nachprüfen), was die Optik betrifft, hast du aber natürlich Recht, und das liegt wohl insbesondere an der Zeilenhöhe (die Überschrift hat nach oben und unten mehr Raum wegen 1,5-facher Zeilenhöhe). --Entlinkt (Diskussion) 20:25, 9. Mai 2013 (CEST)
OK, dann haben wir aneinander vorbeigeredet. Ich habe mir jetzt zwischenzeitlich mit dem CSS
.mw-editsection {
    padding-top: 0.34em;
}
beholfen. Ziemlich hässlich und funktioniert auch nur näherungsweise, da die unterschiedliche Schriftgröße unterschiedlicher Überschriften-Ebenen nicht berücksichtigt wird, aber besser als gar nichts. Wenn jemand noch eine Idee hat wie man das richtig lösen kann, dann immer her damit! --Patrick87 (Diskussion) 15:35, 10. Mai 2013 (CEST)
Genau das meinte ich mit „keinen einfachen CSS-Workaround“.
Mit 
.mw-editsection { line-height: inherit; }
wird es schon mal etwas besser, aber ich bin nicht sicher, ob das irgendwelche negativen Konsequenzen hat. --Entlinkt (Diskussion) 05:50, 11. Mai 2013 (CEST)
Danke, funktioniert ähnlich gut (oder schlecht) wie mein Code. Auch mit deinem Code wandert der Berabeiten-Link bei größer werdenden Überschriften leider nach oben. Eine Möglichkeit im CSS auf die Schriftgröße oder ähnliche Eigenschaften des Schwesternelements (.mw-headline) zuzugreifen gibt es nicht oder? --Patrick87 (Diskussion) 17:26, 11. Mai 2013 (CEST)
Noch ein Vorschlag, so passt das mit der Grundlinie ziemlich genau, aber dafür gibt es bestimmt andere Nachteile:
h2 {
	display: table;
	width: 100%;
}
.mw-headline {
	display: table-cell;
	width: 100%;
}
.mw-editsection {
	display: table-cell;
}
Ist nur in Firefox 20 ganz kurz getestet, Tabellen-CSS könnte etwas schwierig sein mit den Browsern. --Entlinkt (Diskussion) 22:54, 12. Mai 2013 (CEST)
So etwas hatte ich mir auch schon überlegt, das <h2> Tag – ohne Angabe jeglicher Klasse oder ID – anzupassen ist aber (wie du schon schreibst) bestimmt keine gute Idee. Insbesondere haben wir ja noch einen ganzen Haufen weiterer Überschriftenebenen, die ebenfalls angepasst werden müssten. So kommen wir befürchte ich nicht zum Ziel.
Meinst du es wäre möglich statt CSS auf JavaScript zu setzten und das ganze irgendwie in ein <div> zu packen? Dann müsste die vertical-align Eigenschaft doch wieder korrekt funktionieren? --Patrick87 (Diskussion) 23:29, 12. Mai 2013 (CEST)
Ich verstehe ehrlich gesagt nicht ganz, was du mit „in ein <div> […] packen“ genau meinst. Die 3 Elemente müssten zum Stylen eigentlich ausreichen. (Auch wenn sie semantisch fragwürdig sind – der Bearbeiten-Link ist nicht Teil der Überschrift und gehört deshalb m. E. nicht ins <h#>, aber das ist ein anderes Thema, vgl. Bug 11555 und Bug 31932.)
Wenn man schon auf JavaScript setzt, könnte man natürlich auch einfach die gesamte Änderung rückgängig machen und die Elemente wieder vertauschen. Sähe ich als Gadget im MediaWiki-Namensraum aber eher ungern, weil das alte Skript viele Probleme bereitet hat, die jetzt erfreulicherweise weggefallen sind. (Auch im Hinblick darauf, dass wegen o. g. Bugs weitere Änderungen an der Struktur der Überschriften zu erwarten sind – da ist es optimal, keine oder nur minimale lokale Anpassungen zu haben, damit bei Änderungen auch nur möglichst wenig kaputtgehen kann.)
Ich habe jetzt seit 4 Tagen die zu hoch stehenden Links und finde, das Auge gewöhnt sich auch daran. Von den bisherigen Workarounds gefällt mir der mit line-height: inherit noch am besten (er erhöht allerdings die Zeilenhöhe der Überschriften, deshalb wurde wohl das line-height: 1em eingefügt). --Entlinkt (Diskussion) 00:31, 13. Mai 2013 (CEST)
Den line-height-Hack habe ich ins Gadget übernommen. Dazu hätte ich aber eine Frage: Gadgets werden standardmäßig vor den allgemeinen CSS-Dateien geladen, mit [ResourceLoader] in MediaWiki:Gadgets-definition kann man erzwingen, dass sie erst nachher geladen werden, dann aber wird der zeitliche Unterschied durch Verrutschen der Seite sichtbar, gibt es dafür eine elegante Lösung? Bis auf Weiteres habe ich das durch eine künstliche erhöhte Spezifität im Gadget umgangen (durch Vergleich mit der Wirkung von en:MediaWiki:Gadget-righteditlinks.css kann man vielleicht sehen, was ich meine). --Entlinkt (Diskussion) 07:44, 1. Jun. 2013 (CEST)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Archiv/Baustellen/editsection&oldid=228782325“