Benutzer Diskussion:Brackenheim/export.js

Internationalisierung

Gudn Tach @Brackenheim!
Ich denke, man könnte den Abschnitt Wikipedia:Importwünsche/Versionsimport#Aus_Schwesterprojekten deutlich vereinfachen, indem man dieses Script etwas modifiziert und dann direkt in die global.js packen kann:

mw.loader.using('mediawiki.util', function () {
	$(function () {
		const export_url = 'https://' + mw.config.get('wgServerName') + mw.config.get('wgScript')
			+ '?title=Special:Export' + '&pages=' + mw.config.get('wgPageName') 
			+ '&dir=desc&limit=5&wpDownload&history=1';
		// add export button to the page tools menu
		mw.util.addPortletLink('p-cactions', export_url, 'export');
		// add export button to the toolbar menu
		mw.util.addPortletLink('p-namespaces', export_url, 'export');
		// add link to enwiki to the toolbar menu
		mw.util.addPortletLink(
			'p-namespaces', 
			'https://en.wikipedia.org/wiki/' + mw.config.get('wgPageName'), 
			'enwiki');
	});
});

Zur Kenntnis: @M.ottenbruch.
-- seth 10:25, 28. Mär. 2023 (CEST)

Ich würde übrigens einen der beiden redundanten Export-Buttons (am besten den zweiten) eher rausnehmen, es gibt so schon zu viele Buttons, Redundanz macht es dann nur noch unübersichtlicher.

Den Sinn des enwiki-Links verstehe ich nicht (aber ich bin auch kein Importeur). Wenn er nicht für Im-/Export besonders nützlich sein sollte, sollte er vielleicht besser in ein eigenes Script. -- seth 10:34, 28. Mär. 2023 (CEST)

Hi, Du darfst Dich da gerne nach Lust und Laue austoben. Ich habe keine Ahnung mehr, wie das Script funktioniert. Ich freue mich immer nur, wenn es noch klappt :-) --Brackenheim 15:07, 28. Mär. 2023 (CEST)

Was bewirkt das denn? Brauche ich dann nur noch diesen einen Eintrag in meiner global.js und kann die separaten Einträge in den lokalen commons.js löschen? Oder habe ich (anderenfalls) zwei Reiter – einen aus global.js und einen aus der lokalen commons.js? Gibt es dafür irgendwo Tutorials für „technische Analphabeten“? Auf jeden Fall schon mal vielen Dank, daß überhaupt jemand reagiert! LG -- M.ottenbruch ^{¿⇔! RM} 22:12, 28. Mär. 2023 (CEST)

Gudn Tach!

Der umseitige Code erstellt drei Buttons mit derselben Beschriftung "export". Zwei haben dieselbe Aufgabe, aber sind an verschiedenen Stellen platziert. Der dritte verlinkt die englischsprachige Wikipedia mit dem Wortgleichen Lemma (also nicht die Übersetzung), konkret:

1. Füge einen Button "export" bei den Tools hinzu (je nach Skin kann das an unterschiedlichen Stellen sein, im neuen Vector ist es z.B. in der rechten Marginalie). Dieser Button verlinkt in dewiki auf der Seite yyy die Seite https://de.wikipedia.org/w/index.php?title=Spezial:Exportieren&pages=yyy&dir=desc&limit=5&wpDownload&history=1.
2. Füge einen Button "export" neben dem Diskussionsbutton ein, der dieselbe Aufgabe hat wie der unter 1. beschriebene Button.
3. Füge einen weiteren Button "export" neben dem Diskussionsbutton ein, der allerdings auf enwiki verlinkt. Der Button verlinkt z.B. auf der Seite "Studium der Medizin" die Seite https://en.wikipedia.org/wiki/Studium_der_Medizin.

Den unter 2. beschriebenen Button halte ich für eher überflüssig. Bei dem unter 3. beschriebenen Button erschließt sich mir der Sinn gar nicht. Ich würde beide entfernen, es sei denn, es gibt hinreichend viele Leute, die diese Buttons gebrauchen. In dem Fall macht es vielleicht Sinn, ein separates Script zu erstellen, damit man den Leuten die Wahl überlässt.

Der obige Code-Schnipsel von mir in diesem Thread sollte funktionsäquivalent mit dem umseitigen Code sein mit zwei Unterschieden:

• Obiger Code funzt auch außerhalb von dewiki.
• Der unter 3. beschriebene Button wird mit "enwiki" statt "export" beschriftet. (Das halte ich zumindest für weniger verwirrend.)

Um das ganze in der global.js einzubinden kann man entweder den Code direkt dort reinkopieren, wovon ich jedoch aus wartungstechnischen Gründen abrate. Besser ist es, in der global.js den zentralen (also z.B. umseitigen) Code dynamisch zu laden, das sollte z.B. mit

mw.loader.load('https://de.wikipedia.org/w/index.php?title=user:Brackenheim/export.js&action=raw&ctype=text/javascript&smaxage=2678400');

gehen. -- seth 00:54, 29. Mär. 2023 (CEST)

Bis zum letzten Absatz hatte ich gedacht, ich hätte es verstanden, dann allerdings wieder nicht. Es scheint aber sowieso vorerst müßig zu sein, weil ich beim Aufruf meiner global.js folgende Rückmeldung erhalte:

„User:M.ottenbruch/global.js
There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page.“

Ich versuche aber trotzdem mal zusammenzufassen, was ich glaubte, verstanden zu haben:

1. In der ersten Zeile des obigen Skriptes (das ich mal das „Seth-Skript“ nennen werde) wird aus verschiedenen Parametern eine URL zusammengesetzt, und zwar – wie ich vermute – die URL der lokalen Exportseite des aktiven Wikis, vorausgefüllt mit dem aktuell ausgewählten Lemma und den Parametern für den Export incl. Versionsgeschichte als XML-Datei. Diese URL wird der Variablen „export_url“ zugewiesen. Der Clou – und der entscheidende Unterschied zum umsetigen „Brackenheim-Skript“ – besteht dabei darin, daß das „aktive Wiki“ nicht explizit im Quellcode definiert, sondern durch Auslesen der Umgebungsvariablen „wgServerName“ ermittelt wird, weswegen das Skript ohne Quelltext-Änderungen in jedem MW-Wiki einsetzbar ist – sei es, durch Einfügung in die dortige commons.js des Verwenders oder durch Einfügung in seine global.js.
2. In den nächsten beiden Zeilen werden Buttons erzeugt, die diese URL aufrufen, wobei der jeweils dritte Parameter des Funktionsaufrufes die Beschriftung des Buttons – hier jeweils „export“ – enthält. Würde ich diese Parameter in bsplsw. „Export-Toolbar“ und „Export-Menüleiste“ umbenennen, würde ich schnell erkennen, welche Zeile wohin „beknopft“. Ich nutze den Skin Monobook und verwende nur den „Button "export" neben dem Diskussionsbutton“. Wo ich ich dort das Pendant zur „rechten Marginalie“ im „neuen Vector“ finde, weiß ich nicht. Ich weiß nicht einmal, was das ist.
3. Die vierte Zeile erzeugt einen Link-Button in die en-wp, den ich bisher ebenfalls nicht gefunden habe, und dessen Sinn mir aber auch nicht erschließt. Beim Importieren habe ich ihn bisher nicht vermißt. Einen Link-Button auf WikiData schon eher.

Was ich allerdings im letzten Absatz dann nicht mehr verstehe, ist Folgendes: Wenn ich die dort angegebene Quelltext-Zeile in eine *.js-Datei einbinde, dann rufe ich damit doch das umseitige, also das „Brackenheim-Skript“, anstatt des obigen „Seth-Skriptes“ auf. Ich binde also gerade nicht das Skript mit dem „Clou“ der internationalen Einsetzbarkeit ein, sondern das, welches ich in jedem Wiki anpassen muß. Oder habe ich da etwas falsch verstanden?

Wenn ich das hier durchschaue, werde ich jedenfalls versuchen, einen MW-Admin zu finden, der mir die Rechte verleiht, die nötig sind, um seine eigene global.js bearbeiten zu dürfen. Admin und Importeur auf de-WP reicht ja offensichtlich nicht. LG -- M.ottenbruch ^{¿⇔! RM} 18:51, 29. Mär. 2023 (CEST)

Gudn Tach!

Oha, das ist wirklich zum Mäuse-Melken. Ich hab jetzt mal auf meta nachgefragt: m:Meta:Babel#How_to_edit_global.js?

Ich finde es nicht gut, dass das so kompliziert ist. Vermutlich stecken da aber berechtigte Sicherheitsbedenken dahinter, die keine allzu bequeme Lösung (mehr) zulassen. Mal schauen, was da herauskommt.

Zu den drei Punkten:

1. Exakt!
2. Zur ersten Hälfte: auch richtig. Die zweite Hälfte hängt mit 3. zusammen.
3. monobook würde ich versuchen abzustreifen. Der Mensch ist bekanntlich ein Gewohnheitstier und findet sich auch damit zurecht, wenn er Jahrelang in einen Käfig eingesperrt wird, und will anschließend gar nicht mehr heraus. ;-)
   vector ist schon deutlich lesefreundlicher, indem etwas mehr Whitespace verwendet wird. Allerdings ist das versteckte ausklappbare Menü ein totaler Usability-Fehlgriff. Das wurde in vector-2022 ausgebessert, indem alle seitenspezifischen Buttons in die neue rechte Marginalie (also das Menü rechts vom Hauptbereich) gewandert sind. Außerdem ist die Zeilenlänge in vector-2022 endlich schmaler und damit deutlich lesefreundlicher geworden. Und zu guter letzt ist ein weiterer Vorteil der vector-Skins, dass beim Runterscrollen Inhaltsverzeichnis und (bei der -2022-Variante auch) die Tools ebenfalls mitwandern, man also nicht immer hochscrollen muss, um einen der Knöpfe zu drücken. Zum Vergleich:
   • monobook
   • vector
   • vector-2022

Dort siehst du auch, wo die Buttons jeweils auftauchen. In monobook wird anscheinend nur der erste Button angezeigt (was erklärt, dass du meine Verwirrung bzw. meine Kritik an den beiden anderen Buttons gar nicht nachvollziehen konntest).

In vector und vector-2022 werden alle drei Buttons angezeigt, wobei in vector der erste Button in dem besagten ausklappbaren Menü versteckt ist.

Dass du den letzten Teil nicht verstanden hast, liegt nur an einem Missverständnis: Ich ging davon aus, dass der umseitige alte Code durch den oben vorgeschlagenen ersetzt wird. Wenn das passiert ist, würde es Sinn machen das umseitige Script in deiner global.js einzubinden.

Wenn ich Brackenheim richtig verstanden habe, dürfte ich diesen Teil einfach schon mal umsetzen. Ich bin so frei, das schon mal zu tun (vorerst noch ohne Bottons zu entfernen, denn sonst machen die obigen Ausprobier-Links weniger Sinn). Die Sache mit der global.js bekommen wir dann auch noch irgendwie hin. -- seth 23:46, 29. Mär. 2023 (CEST)

@M.ottenbruch: Kannst du, um sicherzugehen, nochmal auf m:Special:MyPage/global.js gehen, dich vergewissern, dass du eingeloggt bist und schauen, ob die Fehlermeldung immer noch da ist? -- seth 01:38, 30. Mär. 2023 (CEST)

Daran muß es gelegen haben: Wie die o.g. Fehlermeldung ja ausweist, war ich zwar auf der richtigen Seite, aber wohl nicht eingeloggt, obwohl die Seite mich mit Namen begrüßt hat. Beim nächsten Aufruf hat sie mich als IP-Ardresse begrüßt, woraufhin ich mich gründlich eingeloggt habe, und nun konnte ich auch meine global.js editieren. Der Teil ist also gelöst. thx -- M.ottenbruch ^{¿⇔! RM} 09:57, 30. Mär. 2023 (CEST)

Das mit der global.js hat ja jetzt funktioniert. Ich habe dort erstmal das „Seth-Skript“ incl. der beschriebenen Veränderungen der Button-Beschriftungen eingesetzt und beginne jetzt, die Ergebnisse zu verstehen (das mit dem Skin-Wechsel gehe ich an, wenn ich ein bißchen mehr Zeit habe).

Du schreibst oben: „Um das ganze in der global.js einzubinden kann man entweder den Code direkt dort reinkopieren, wovon ich jedoch aus wartungstechnischen Gründen abrate. Besser ist es, in der global.js den zentralen (also z.B. umseitigen) Code dynamisch zu laden [...]“ Ich spekuliere jetzt mal wild herum: Es böte sich für mich vielleicht an, mir eine Unterseite User:M.ottenbruch/globalscript.js anzulegen, dorthin eine – ggflls. modifizierte – Kopie des Skriptes zu stellen, und dieses dann mit

mw.loader.load('https://de.wikipedia.org/w/index.php?title=user:M.ottenbruch/globalscript.js&action=raw&ctype=text/javascript&smaxage=2678400'); // [[:de:user:M.ottenbruch/globalscript.js]]

in meiner global.js einzubinden. (Was bewirkt in diesem Zusammenhang eigentlich der Parameter „smaxage“? Daß der Wert des Parameters die Länge eines 31-Tage-Monats in Sekunden ist, ist mir klar. Aber was soll passieren, wenn was älter ist als einen Monat?)

Wenn ich das alles richtig verstanden habe, würde ich so vorgehen und Wikipedia:Importwünsche/Versionsimport#Aus_Schwesterprojekten dahingehend verkürzen, daß ich auf die hiesige Vorderseite mit dem Quellcode nur noch verlinke (kopiert und angepaßt muß ja nichts mehr werden), und ansonsten erläutere, daß man entweder das Skript durch den Aufruf unverändert in eine oder mehrerere lokale commons.js oder eben für alle WP-Wikis zentral in der global.js einbinden kann. Korrekt so? LG & thx -- M.ottenbruch ^{¿⇔! RM} 09:57, 30. Mär. 2023 (CEST)

Die Anpassung der Anleitung habe ich zwischenzeitlich vorgenommen. Ich bitte um kritische Durchsicht und gegebenenfalls Feedback. TIA -- M.ottenbruch ^{¿⇔! RM} 19:11, 30. Mär. 2023 (CEST)

Gudn Tach!

• smaxage: "Set the s-maxage HTTP cache control header to this many seconds." (Quelle: https://www.mediawiki.org/wiki/API:Main_page)
  So wie ich es verstehe, wird damit also das Script zwischengespeichert (und nicht bei jedem Seitenaufruf neugeladen), was den Server etwas entlasten sollte.
• Ob du das Script auf meta in der global.js speicherst oder hier auf dewiki in einer Datei globalscript.js, halte ich für egal. Da sehe ich semantisch keinen Unterschied und auch keine Redundanz-Vermeidung. Ich bin eher der Ansicht, dass Scripts modular und nicht-redundant sein sollten. Das heißt: Der Name des Scripts sollte besser nicht "globalscript.js" sondern "export.js" oder sowas sein. Und um die Wartung gering zu halten, macht es mehr Sinn, das umseitige Brackenheim-Script anzupassen (und dieses dann in der jeweils eigenen global.js zu nutzen) und kein eigenes zu erstellen, es sei denn, du vermutest, dass du nicht-massenkompatible Änderungen vornehmen möchtest.
• Ich werde jetzt mal den zweiten export-Button und den enwiki-Link umseitig noch entfernen.
• Deine Änderungen am Import-Artikel schaue ich mir gleich noch an und werde so frei sein, direkt dort drin herumzukritzeln.

-- seth 23:43, 30. Mär. 2023 (CEST)