Wikipedia:Technische Wünsche/Reparaturhilfe

• Über das ProjektStartseite
• Aktuelle ProjekteWoran wird gerade gearbeitet?
• UmfrageAbstimmung zum nächsten Themenschwerpunkt
• TreffenTriff das Projektteam
• NewsletterBleib auf dem Laufenden

Reparaturhilfe
für Helferlein, Tools, Bots und Benutzerskripte

Du hast ein defektes Helferlein, Tool, Benutzerskript oder einen defekten Bot entdeckt oder benötigst Hilfe bei der Reparatur? Da das alles Werkzeuge sind, die in Community-Hand liegen, findest du auch die beste Unterstützung bei den Aktiven hier in den Wikis. Je nachdem, worum es geht, sind das deine Anlaufstellen:

Links: Technikwerkstatt, Helferlein, Benutzerskript, Bot, externes Tool

Links: Wikipedia:WikiProjekt_Vorlagen/Werkstatt, Wikipedia:Lua/Werkstatt, Vorlage, Lua-Modul,
Wieso repariert das Team keine Vorlagen und Module?

vom Projekt
Technische Wünsche

Was macht die Reparaturhilfe?

Solltest du mit deinem Anliegen rund um Helferlein, Tools, Bots und Benutzerskripten innerhalb der Community nicht weiterkommen, kannst du dich an das Team der Technischen Wünsche wenden und wir können als Hauptamtliche versuchen zu unterstützen. Das Team bietet an, im 2-Wochen-Rhythmus die eingereichten Probleme anzuschauen und auf ihre Machbarkeit zu überprüfen. Unsere Hilfe kann dabei wie folgt aussehen:

• Zuständige finden
• mit den zuständigen Community-Mitgliedern: Beratung, Austausch, gemeinsam Problemlösungen entwickeln
• Ursachen für Probleme ausfindig machen
• Alternativen für defekte Community-Werkzeuge finden

Das Team verändert nichts ohne Austausch mit den verantwortlichen ehrenamtlichen Aktiven.

So kannst du deine Probleme platzieren.

Trag dein Problem hier ein

Du erhältst in bis zu zwei Wochen eine erste Rückmeldung.

Bring dein Problem mit in die Reparatursprechstunde

Tausch dich mit den Entwickler*innen des Teams Technische Wünsche in der Reparatursprechstunde aus.

Was macht die Reparaturhilfe nicht?

Der Fokus des Teams liegt auf der Arbeit im gewählten Themenschwerpunkt. Die Reparaturhilfe ist ein zusätzliches Angebot. Daher gibt es folgende Einschränkungen:

• Wir unterstützen bei Community-Werkzeugen. Für Probleme, die von der MediaWiki-Software verursacht werden, melde dich bitte in der Technikwerkstatt.
• Wir arbeiten nicht an übermäßig aufwändigen Reparaturen.
• Wir arbeiten nicht an Reparaturen, von denen letztlich nur einzelne Menschen profitieren würden.
• Wir bauen Helferlein, Benutzerskripte, Bots und Tools nicht grundlegend um.
• Wir ergänzen keine neuen Funktionen in bestehenden Helferlein, Benutzerskripten, Bots und Tools.
• Wir erstellen keine neuen Helferlein, Benutzerskripte, Bots und Tools.
• Wir reparieren keine Vorlagen und Lua-Module. (Warum?)
• Wir arbeiten nicht an Code, mit dem wir uns nicht sicher fühlen – u.a. um nicht zu riskieren, ihn zu verschlechtern.
• Die Zuständigkeit für reparierte Helferlein, Benutzerskripte, Bots und Tools bleibt in der Community und geht nicht ans Team Technische Wünsche über.

Wieso, weshalb, warum?

Wieso repariert das Team keine Vorlagen und Module?
Bei Vorlagen und Modulen gibt es in den Wikis eine Menge Expert*innen, an die man sich wenden kann (siehe Grafik oben). Das bestätigte auch der Reparatursommer, in dem keine Anfragen bezüglich Vorlagen und Modulen gestellt wurden. Hinzu kommt, dass Vorlagen und Module im Unterschied zu Bots, Benutzerskripten, Helferlein und Tools auch den Inhalt der einzelnen Wikis beeinflussen (Infoboxen, Navigationsleisten in Artikeln, etc.), und in den Inhalt der Wikis greifen Hauptamtliche generell nicht ein.

Weshalb reparieren die Technischen Wünsche überhaupt Community-Werkzeuge?
Das Team Technische Wünsche arbeitet seit 2015 an Verbesserung von MediaWiki, auf Basis großer Umfragen, die hier in der deutschsprachigen Wikipedia durchgeführt werden. Zusätzlich gab es in der Vergangenheit immer mal wieder den Wunsch nach Reparatur von Community-Werkzeugen. Als das Team 2023 kurzfristig eine Pause an der Arbeit im Themenschwerpunkt „Wiederverwendung von Einzelnachweisen vereinfachen“ einlegen musste, hatte es die Kapazität, dieser Bitte nachzukommen. Daraus entstand, als temporäres Angebot, der Reparatursommer. Dieses Format diente als Versuch, um eine bessere Einschätzung dafür zu bekommen, ob und in welchem Umfang das Team auch zukünftig bei der Reparatur von Community-Werkzeugen unterstützen kann. Die Erfahrung hat gezeigt, dass eine Unterstützung community-seitig gewünscht ist und im oben skizzierten Umfang vom Team machbar ist. Die Reparaturhilfe ist weiterhin ein Versuch, und wir freuen uns über Rückmeldungen, Fragen, Hinweise usw. auf der Diskussionsseite.

Aktuelle Reparaturanfragen

Archiv für erledigte oder abgelehnte Reparaturanfragen

Neue Diskussionsbeiträge in der Wartungsstube

Gemeldet in Phabricator
Task T341862

Dokumentation

Es gibt den Benutzer:Wartungsstube, über den von verschiedenen Bots Wartungslisten für Kategorien erzeugt werden. In diesen Wartungslisten gibt es einen Abschnitt „Neue Diskussionsbeiträge“.

Problembeschreibung

Dieser Abschnitt wurde früher von einem Benutzer:DrTrigonBot gewartet, dessen Eigentümer ist jedoch verstorben. Andere Botbetreiber haben es abgelehnt, diese Aufgabe zu übernehmen. Mittels diesem Abschnitt kann man überhaupt erst sehen, was in einem Kategorienbaum diskutiert wird, ohne dass man jede einzelne Seite beobachten muss. Ich habe einmal für den Kategorienbaum Stolpersteine dies per Hand durchgeführt, aber die Server sind dann unwillig, alle Unter- und Diskussionsseiten schnell auszuliefern und ich musste alle Einzelschritte abschnittsweise per Hand ausführen. Da es zahlreiche derartige Wartungslisten gibt, und diese Aufgabe regelmäßig durchgeführt werden müsste, zwar nicht unbedingt täglich, eignet sich diese Aufgabe besser für einen Bot.

Weder kann ich einen Bot programmieren (meiner einer (Bot) würde vermutlich eher Amok laufen als was vernünftiges tun), noch könnte ich ihn hier bei mir laufen lassen (mickrige alte Technik). --GeorgDerReisende (Diskussion) 13:30, 29. Jun. 2023 (CEST)

(Zwischen-)Ergebnis

Mit PetScan ist es möglich, eine Liste von Seiten einer Kategorie zu erzeugen, sortiert nach ihren letzten Diskussionsbeiträgen (Beispiel). Um auch die Seiten der Wartungsstube zu aktualisieren, wird aktuell noch der Bot angepasst (siehe Diskussion im zugehörigen Bot).

Diskussion

Eine spontane Idee, die mir hierzu kam: wenn die Tabellen der Discussiontools-Erweiterung auf Toolforge zur Verfügung stehen würden, könnte man mglw. daraus die erforderlichen Informationen zu neuen Diskussionsbeiträgen ziehen. -- hgzh 21:12, 19. Jul. 2023 (CEST)

Lieber GeorgDerReisende, danke für deine Anfrage. Das Tool catscan2, das in der Wartungsstube verwendet wurde, scheint nicht mehr zu existieren. Aber es gibt einen Nachfolger: PetScan. Damit ist es möglich, eine Liste von Seiten einer Kategorie zu erzeugen, sortiert nach ihren letzten Diskussionsbeiträgen (Beispiel). Vielleicht hilft dir das bereits etwas weiter? Aktuell schauen wir noch, wie wir die Diskussionsbeiträge selbst darstellen können (hgzhs Vorschlag oben klingt interessant). Wir schreiben dann nochmal. Beste Grüße, Svantje Lilienthal (WMDE) (Diskussion) 18:08, 20. Jul. 2023 (CEST)

Vielen Dank. Das hilft mir schon deutlich weiter. Und ich sehe den Unterschied zu meinen früheren Abfrageversuchen. Aber es wäre schön, wenn es als Ergebnis in die Wartungsstuben-Seiten eingebunden wird wie die anderen Abschnitte auch. --GeorgDerReisende (Diskussion) 09:51, 21. Jul. 2023 (CEST)

Schön, dass es schon hilft. Ich habe das Ergebnis oben ergänzt. --Svantje Lilienthal (WMDE) (Diskussion) 15:24, 21. Jul. 2023 (CEST)

@GeorgDerReisende Wir haben geschaut, wie die Wartungsstuben-Seiten aktualisiert werden können und haben den zugehörigen Bot-Betreiber angefragt. Der will sich jetzt freundlicherweise darum kümmern. --Svantje Lilienthal (WMDE) (Diskussion) 15:12, 16. Aug. 2023 (CEST)

Ich freu mich schon drauf. --GeorgDerReisende (Diskussion) 20:04, 16. Aug. 2023 (CEST)

@GeorgDerReisende: Ich denke, es ist sinnvoll, diese Diskussionsbeitragsliste auf die letzten 10 Tage zu beschränken, nicht weiter zurück. Was meinst Du? – Doc Taxon • Disk. • 13:13, 3. Okt. 2023 (CEST)

Aus dem Bauch heraus würde ich für 30 Tage plädieren. Früher waren es die letzten 100 Artikeldiskussionen. Aber ich kann es jetzt nur im Bereich Stolpersteine sehen, ich weiß nicht, wie intensiv die Diskussionen in den anderen Wartungsbereichen sind. Ein bisschen ist dabei auch zu sehen, wie sehr die einzelnen Bearbeiter jeweils ihre Bearbeitungszeiten oder -intervalle setzen. Vielleicht kommt jemand aus dem Urlaub zurück und möchte sehen, wie die Diskussionen in seiner Abwesenheit verlaufen sind. Oder so. (Im Bereich Stolpersteine entsprechen 100 Artikeldiskussionen im Moment rund einem halben Jahr, einschließlich Botmeldungen.) --GeorgDerReisende (Diskussion) 13:46, 3. Okt. 2023 (CEST)

---

baglama2

Dokumentation

https://glamtools.toolforge.org/baglama2/#gid=920&month=202301&giu=enwiki&server=en.wikipedia.org

Baglama2 zeigt die Zahl der Seitenaufrufe von Seiten, die ein Bild enthalten, das in einer bestimmten Kategorie ist. Ein GLAMtool mit dem Museen usw nachweisen können, dass Bilderspenden an Wikipedia sinnvoll sind, weil die entsprechenden Medien auch PageViews bekommen (und nicht nur SocialMedia-Beiträge für Museen PageViews generieren)

Problembeschreibung

Seit Januar kein monatlicher Update mehr. Vermutlich ist eine bengalische Kategorie mit einem neuen Medium mit Namen in bengalischer Sprache daran Schuld, dass der Update abstürzt.

Ich finde das Tool wichtig und unterstütze den Wunsch (den C.Suthorn eingebracht hat, wie ich der History entnehme). Gestumblindi 21:29, 28. Jul. 2023 (CEST)

Bin dran. --Magnus Manske (Diskussion) 11:15, 1. Aug. 2023 (CEST)

Danke, Magnus Manske! Ich verschiebe das mal nach in Umsetzung, weil Magnus daran arbeitet. -- Svantje Lilienthal (WMDE) (Diskussion) 14:57, 14. Aug. 2023 (CEST)

Das Tool zeigt jetzt Werte bis August an, die sind aber für fast alle Kategorien jeweils 0 und manche Monate fehlen. Vielleicht ist das ja nur ein Aktualisierungsproblem und das regelt sich noch ein. Aber so wie es im Moment ist, ist es sehr seltsam. --C.Suthorn (@[email protected] - p7.ee/p) (Diskussion) 06:38, 9. Okt. 2023 (CEST)

Es hat sich nichts verbessert. Da muss nachgearbeitet werden. --C.Suthorn (@[email protected] - p7.ee/p) (Diskussion) 17:24, 7. Dez. 2023 (CET)

@Magnus Manske @Svantje Lilienthal (WMDE) Ist das Tool tot? Die neuesten Einträge sind 2023-09, die meisten 2023-08, aber alle seit 2023-01 lauten auf null. --C.Suthorn (@[email protected] - p7.ee/p) (Diskussion) 09:35, 16. Jan. 2024 (CET)

@C.Suthorn: Aus Sicht des Teams Technische Wünsche können wir im Augenblick leider nichts weiter tun. Wir stehen in Kontakt mit Magnus und bieten ihm weiterhin unsere Hilfe an. Im Sinne von Magnus' Wunsch "Dinge [nicht] über ein halbes Dutzend Diskussionsseiten [zu] verteilt" würden wir diese Meldung gern ins Archiv verschieben und statt dessen auf https://bitbucket.org/magnusmanske/glamtools/issues verweisen. --Thiemo Kreuz (WMDE) 13:55, 27. Mai 2024 (CEST)

Ich bin bei BitBucket nicht registriert und habe das auch nicht vor. Ich habe aber auch nichts neues vorzubringen. Seit über einem Jahr lauten alle Einträge auf "Null". Es wäre natürlich schön zu erfahren, ob das Tool überhaupt noch repariert wird und wenn ja, dann wann damit zu rechnen ist. MagnusManske hat irgendwann gesagt, er nehme sich der Sache an. Dann hat sich auch wirklich was getan. Und dann waren die neuen Einträge auf einmal alle null. Dann hat MagnusManske "wikiflix" gemacht und ist damit in Publikumsmedien interviewt worden. Für mich macht es den Eindruck er hat das Interesse and dem Tool verloren, aber niemand anders kümmert sich darum. Selbst ein Hinweis auf der Seite von Baglama2 "Dies ist eine historische Seite, sie wird seit 1/23 nicht mher mit neuen Daten upgedatet" wäre besser als der Ist-Zustand. Wenn ihr diesen Eintrag ins Archiv verschieben wollt, dann werdet ihr das wohl tun. Aber ich werde nicht schreiben, das wäre aus meiner Sicht ok. --C.Suthorn (@[email protected] - p7.ee/p) (Diskussion) 14:17, 27. Mai 2024 (CEST)

---

Portal- bzw. Projekt-Index anhand von Kategorien

Gemeldet in Phabricator
Task T346986

Dokumentation

Aufgrund einer Diskussion im Jahr 2009 (Automatische Index-Erstellung) auf Wikipedia:Bots/Anfragen übernahm Merlissimo mit seinem MerlBot den Job von Benutzer:Srbauer und seinem SrbBot, Indexe für Portale bzw. Projekte zu erstellen.

Der MerlBot indizierte regelmäßig alle Seiten unterhalb einer gewünschten Kategorie (sowie auf Wunsch eines zugehörigen Wikiprojekts). Dadurch weiß man, wieviele Artikel es gibt, Weiterleitungen werden mit angezeigt und ein Link zur Diskussionsseite. Mit der Spezialseite für Änderungen an verlinkten Seiten, konnte man (theoretisch) alle Artikel einer Kategorie von seiner Beobachtungsliste nehmen. Die Konfiguration erfolgte durch Kriterien im Quelltext.

Konkretes Beispiel:

• Portal:Mittelhessen/Index bindet
• Portal:Mittelhessen/Index/Kopf für die Zusammenfassung und
• Unterseiten Portal:Mittelhessen/Index/0A-E, Portal:Mittelhessen/Index/F-K, Portal:Mittelhessen/Index/L-R, Portal:Mittelhessen/Index/S-Z, und Portal:Mittelhessen/Index/Sonstiges für die einzelnen Buchstabenbereiche ein.

Weitere Betroffene:

• Index Hund, Index Raumfahrt, Index Ostfriesland, Index Marxismus, Index Wirtschaft (keine Ahnung, welche es noch gibt)

Problembeschreibung

• Im Dezember 2011, gab es eine Datenbankänderung bzw. API-Änderung (Rückfrage und Antwort bei Merlissimo zum Portal Marxismus), der keinen Ersatz dafür hatte)
• 2013 gab es auf Wikipedia:Bots/Anfragen die Bitte (#Themenliste aktualisieren), aufgrund der Benutzer:Reinhard Kraasch die Themenliste Alter Orient von Hand(?) aktualisierte, er meinte aber damals, das sei »eher ein Job für einen serverbasierten Bot.«
• 2018 gab es auf auf Wikipedia:Bots/Anfragen einen weiteren Versuch Wikipedia:Bots/Anfragen/Archiv/2018-1#(Seiten)Index für Portale anhand von Kategorien erstellen und aktualisieren (Merlbot-Ersatz), der 2020 ohne Ergebnis archiviert wurde
• Bis 2021 hat Benutzerin:TaxonBota wenigstens Portal:Wintersport/Index/0–9 und die Folgeseiten aktualisiert, doch auch das hörte dann auf.

Die Lösung wäre, diese Index-Seite(n) für Wikipedia-Projekte und Portale wieder zu aktualisieren.

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

--emha ^d℩^b 12:05, 12. Sep. 2023 (CEST) Ich habe keinerlei Ahnung von der Technik, ich bin reiner User. Stehe aber gerne als Ansprechperson zur Verfügung.

Vielen Dank für die Meldung. Ich versuche, TaxonBota den Job wieder aufnehmen zu lassen. – Doc Taxon • Disk. • 18:57, 12. Sep. 2023 (CEST)

Das wäre ja die schnellste (und vielleicht beste) Lösung, @Doc Taxon. Kann Dir vielleicht (hier) jemand helfen? Woran ist es denn beim letzen Mal gescheitert? Viele Grüße, --emha ^d℩^b 23:34, 15. Sep. 2023 (CEST)

@Emha: Gescheitert war es an der riesigen Datenmasse und zu große Seitengrößen, sowie sehr lange Datenabfragezeiten, egal ob mit SQL oder ohne. Ich krieg das aber trotzdem hin. – Doc Taxon • Disk. • 00:21, 21. Sep. 2023 (CEST)

Hi @Doc Taxon, hast Du für uns in dieser Sache einen Stand? Ich wäre wirklich froh, wenn die Seite aktualisiert werden könnte ... beste Grüße, --emha ^d℩^b 14:38, 7. Dez. 2023 (CET)

Es gibt da noch ein Performance-Problem mit der Masse an Daten, ich will das aber ganz dringend im Dezember fertig kriegen. – Doc Taxon • Disk. • 19:58, 7. Dez. 2023 (CET)

Hi @Doc Taxon, gibt's mal wieder einen Zwischenstand, der uns Hoffnung schöpfen lässt? Viele Grüße, --emha ^d℩^b 01:43, 31. Mär. 2024 (CET)

Sind das hier die gewünschten Seiten? Bei Mittelhessen lief die Abfrage nicht besonders lang, mag sein, dass sie bei größeren Kategorien auch mal in ein Timeout kommt und das die oben angesprochenen Performance-Probleme sind. -- hgzh 19:49, 14. Mai 2024 (CEST)

Mit der Wintersport-Kategorie und 51.000 Artikeln lief es auch in unter einer Minute, scheint mir also beherrschbar zu sein. -- hgzh 19:53, 14. Mai 2024 (CEST)

Hi @Hgzh, dazu müsstest Du das Portal:Wintersport befragen bzw. Deine Liste mit der o.g. vergleichen. Kann es sein, dass es mehr mittelhessische als Wintersport-Artikel gibt? Ehrlich gesagt kann ich das kaum glauben. Ping an @Doc Taxon, viele Grüße und Dank für Deinen Versuch, --emha ^d℩^b 15:10, 16. Mai 2024 (CEST)

Ich habe die Query nochmal mit Mittelhessen als Basis laufen lassen, sind ca. 10.000 Mittelhessen-Artikel -- hgzh 15:13, 16. Mai 2024 (CEST)

@Emha: Oh, ich guck mir das diese Nacht noch an. Versprochen, – Doc Taxon • Disk. • 17:36, 16. Mai 2024 (CEST)

@Hgzh: Eigentlich wird dazu auch noch der DEFAULTSORT benötigt, da z.B. ein Aaron Kostner auf die Seite Portal:Wintersport/Index/K und nicht auf Portal:Wintersport/Index/A gehört. Kannst Du das in der Abfrage noch hinzufügen? Liebe Grüße, – Doc Taxon • Disk. • 21:01, 16. Mai 2024 (CEST)

Erledigt. -- hgzh 21:26, 16. Mai 2024 (CEST)

@Hgzh: Wow, aber als Spalte wird das im Ergebnis nicht angezeigt, oder? Also, die Ergebnisliste ist lese ich zweispaltig in Deinem Link. – Doc Taxon • Disk. • 21:37, 16. Mai 2024 (CEST)

Ah, die Tabelle ist auf der rechten Seite abgeschnitten. – Doc Taxon • Disk. • 21:38, 16. Mai 2024 (CEST)

@Emha, Hgzh: Zunächst einmal die Indexseiten 0–9 – Z habe ich bei Wintersport wieder hingekriegt. Besten Dank auch an hgzh wegen seines Inputs, den ich noch leicht modifiziert habe. Die Zusammenfassungen im Kopf und die Sonderseiten kommen noch. Was Mittelhessen betrifft, schau ich jetzt mal. – Doc Taxon • Disk. • 15:50, 17. Mai 2024 (CEST)

@Emha: 0-Z für Mittelhessen wurden generiert, das Framing kommt noch – Doc Taxon • Disk. • 13:30, 18. Mai 2024 (CEST)

So, dann schau ich jetzt mal nach den "Nichtartikel-Seiten". – Doc Taxon • Disk. • 08:47, 22. Mai 2024 (CEST)

---

LrMediaWiki-Plugin

Dokumentation

c:Commons:LrMediaWiki/de

Problembeschreibung

Ich nutze es zum Upload von Fotos nach Commons. Bisher habe ich knapp 30.000 Fotos mit diesem Plugin nach Commons geladen, auf alle Nutzer summiert sind es etwa 320.000 Fotos. Allein von mir befinden sich mehrere tausend Fotos in der "Warteschleife".

Probleme bzw. Wünsche:

1. ganz akut: jemand, der bei Nichtfunktionieren des Tools hilft, siehe aktuell c:Commons_talk:LrMediaWiki#interner Fehler
2. Dauerproblem: der Upload bricht wegen schlechter Serverantworten sehr oft ab, man muss dann jedes Mal den Upload neu starten. Bei mehreren hundert Fotos wird das schnell eine Tagesaufgabe. Da der VicuñaUploader sehr stabil läuft (siehe weiter oben), ist dieser offenbar deutlich fehlertoleranter programmiert. Nach meiner Vorstellung müssten nun die Upload-Routinen des Plugins entsprechend angepasst werden, dass diese ähnlich fehlertolerant arbeiten und der Upload nicht mehr ständig abbricht.
3. perspektivisch: das Tool braucht mehrere Menschen, die sich darum kümmern. Es ist inzwischen viel zu wichtig, um dem Zeitbudget und der Interessenlage nur eines Freiwilligen ausgeliefert zu sein.

wichtiger Hinweis: das soll keinesfalls als Kritik am aktuellen Entwickler verstanden werden, sondern als objektive Beschreibung unabhängig von handelnden Personen

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

Ich stehe sehr gern zur Verfügung. Auch für eine Einarbeitung in das Tool bin ich offen, um zukünftig selbst mithelfen zu können. Ich weiß von mindestens einer Nutzerin, die ebenfalls interessiert ist. --Stepro (Diskussion) 06:22, 5. Jul. 2023 (CEST)

Tritt der Fehler denn aktuell noch auf? In den den letzten 30 Tagen liefen die Server, bis auf sechs Stunden, wieder recht stabil. [1] --GPSLeo (Diskussion) 17:06, 19. Jul. 2023 (CEST)

Ich hatte bei meinen letzten Uploads zwar erfreulich wenige Abbrüche, aber sie waren vorhanden. Das Problem sollte aber generell gelöst werden, und ich denke, dass eine Lösung vielleicht gar nicht allzu kompliziert sein wird. Vermutlich muss nur die "Abwartetoleranz" bei ausbleibenden Serverantworten irgendwie hochgesetzt werden.

Davon unabhängig halte ich Punkt 3 für extrem wichtig. --Stepro (Diskussion) 23:33, 20. Jul. 2023 (CEST)

Vielleicht würde es helfen, wenn das Plugin chunked uploads verwenden würde. Wenn ich das richtig sehe, wird derzeit versucht, immer das ganze Bild auf einmal hochzuladen, was natürlich schneller mal in die Hose gehen kann. -- hgzh 07:54, 21. Jul. 2023 (CEST)

Hallo @Stepro. Es wird uns leider nicht möglich sein, im Rahmen dieses Projekts direkt Maintainer anzuwerben, noch können wir diese Arbeit übernehmen. Im Moment sieht es so aus, als wenn Hasenläufer der einzige halbwegs aktive Entwickler dort ist. Eventuell lassen sich durch uns aber ein zwei Punkte identifizieren, die wir direkt lösen können. Um die Probleme besser einzugrenzen, wäre es nötig die Log-Datei einzusehen, nachdem ein Upload fehlgeschlagen ist. Eventuell gibt es dort Hinweise, was genau schief läuft. Die Anleitung, wie das Logging aktiviert wird und wo du die Datei findest siehst du bei den Settings des Plugins LrMediaWiki#Plugin_settings. Christoph Jauera (WMDE) (Diskussion) 17:08, 9. Aug. 2023 (CEST)

Hallo @Christoph Jauera (WMDE), in diesem Phabricator-Task ist auch ein Logfile von mir. Leider ist es nicht sehr aussagekräftig, aber mehr kann ich nun mal nicht bieten.

Was weitere Maintainer betrifft: Es gibt ja Personen (inkl. mich selbst) mit Interesse. Was es m. E. bräuchte, wäre ein Tag Einarbeitung in die Entwicklungsumgebung. --Stepro (Diskussion) 17:35, 9. Aug. 2023 (CEST)

Ja die Datei hatte ich auch gerade gefunden. Ist wirklich nicht aussagekräftig. Ein Blick in den Code zeigt mir auch, dass gerade an dieser Stelle kein Logeintrag erzeugt wird...

Bezüglich der Wartung würde ich dich gerne zu unserer nächsten Reparatursommer Sprechstunde einladen. Wir testen das gerade auch als Format und richten uns explizit an Entwickler die Unterstützung brauchen. Ich oder einer meiner Kollegen werden dann dort sein und wir können gemeinsam schauen, was du brauchst. Christoph Jauera (WMDE) (Diskussion) 16:03, 10. Aug. 2023 (CEST)

Update: Nachdem es in letzter Zeit einigermaßen ging, habe ich letzte Nacht wieder 7 Anläufe für den Upload von 128 Fotos gebraucht. Fehlermeldung war immer das nichtssagende "http-Status erhalten". Das nervt einfach. --Stepro (Diskussion) 16:37, 4. Sep. 2023 (CEST)

Hey @Stepro, ich hab einen Fork der aktuellen Version von @Hasenläufer erstellt und dort den Versuch gestartet, etwas mehr Logging in die Log Datei zu schreiben, falls etwas schief geht in der Kommunikation mit Commons. Da ich vom Maintainer nichts weiter gehört habe, könntest du versuchen diese Version selbst in Lightroom zu benutzen. Eventuell lässt sich dadurch besser herausfinden, was das Grundproblem ist.

Der Fork ist auf GitHub unter WMDE-Fisch/LrMediaWiki. Die .zip Datei mit dem Plugin und den Änderungen hab ich auf Phabricator hochgeladen [email protected]. Die Änderungen am Original Code sind minimal, das Plugin sollte also arbeiten wie sonst, nur die Log Datei ist hoffentlich aufschlussreicher. Viele Grüße Christoph Jauera (WMDE) (Diskussion) 15:53, 22. Sep. 2023 (CEST)

Hallo @Christoph Jauera (WMDE),

danke, dass Du dich der Sache annimmst. Die von Stepro beschriebenen Probleme kann ich für mich 1:1 bestätigen. Leider ist es jedoch inzwischen noch schlimmer: Seit dem Lightroom-Versionsupdate auf 13.0 (und inzwischen 13.0.1) brechen bei mir Uploadversuche grundsätzlich unmittelbar mit der Fehlermeldung "Export nicht möglich: Ein interner Fehler ist aufgetreten: ?:0: attempt to perform arithmetic on field 'fileSize' (a nil value)" ab. Es scheint, dass der Upload gar nicht erst versucht wird. Einzige Ausnahme ist c:Special:Diff/812091194. Hier hat das hochladen einer neuen Version über "Update only" einmalig funktioniert. In anderen ähnlichen Versuchen schlug jedoch auch das hochladen neuer Verionen zu bestehenden Dateien auf Commons mit o. g. Fehlermeldung fehl.

Auf Anfrage kann ich Dir gerne Logs zukommen lassen.

Viele Grüße --MB-one (Diskussion) 11:53, 17. Okt. 2023 (CEST)

Nachtrag: der gleiche Fehler triit auch mit der modifizierten Version von Phabricator auf. :-( --MB-one (Diskussion) 23:15, 17. Okt. 2023 (CEST)

Hi @MB-one, ja damit war zu rechnen. Die modifizierte Version verbessert lediglich das Logging, um das Problem einzugrenzen. Momentan tappen wir da nämlich im Dunkeln. Wenn du mir also Logs vom Fehlgeschlagenen Upload zukommen lassen kannst wäre das hilfreich. Die Datei LrMediaWikiLogger.log müsste irgendwo beim Plugin zu finden sein.

Vor dem Teilen solltest du jedoch deine Passwörter aus der Datei entfernen. Sie kommen da im Klartext drin vor! --Christoph Jauera (WMDE) (Diskussion) 09:41, 18. Okt. 2023 (CEST)

---

wikihistory von APPER

Problembeschreibung

Das Wekzeug wird von sehr vielen Benutzern per Skript eingebunden und zeigt die Hauptautoren eines Artikels an. Sie werden zur Laufzeit aus der Versionsgeschichte ermittelt und zwischen Seitentitel und Artikelinhalt eingeblendet.

Dokumentation

Es handelt sich um Benutzer:APPER/WikiHistory.js.

Am 19. März 2024 haben wir festgestellt, dass das Skript nicht mehr funktioniert wie erwartet. Eine baldige Reparatur wäre sehr wünschenswert, so dass das Skript dauerhaft bereitsteht. Das wäre super!  

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

Herzlichen Dank für eure Mühe im Voraus! Viele Grüße, Aschmidt (Diskussion) 00:06, 20. Mär. 2024 (CET)

Eingereicht von Aschmidt (Diskussion) 00:06, 20. Mär. 2024 (CET)

Diskussion

Hier ist Platz für Diskussionen, weitere Hinweise usw. zu diesem Wunsch.

Hallo Aschmidt. Für mich scheint das Werkzeug in einem ersten Test normal zu funktionieren. Ich fürchte, hier werden mehr Informationen benötigt. Wahrscheinlich ist Benutzer Wurgl auch der bessere Ansprechpartner. Wir haben auf den relevanteren PHP-Teil des Werkzeugs keinen Zugriff. --Thiemo Kreuz (WMDE) 10:12, 20. Mär. 2024 (CET)

Das Problem ist hier die Umstellung auf diese neue Umgebung mit "Kubernetes". Ich brauch hier so ein Dings mit Mono und php. Das Problem ist das "und" und da bin ich aus der Beschreibung nicht schlau geworden. So richtig Hilfe hab ich von den Entwicklern auch nicht bekommen. Mein Ärger muss sich mal legen, bis ich wieder Energie hab und mich durch die lückenhafte Beschreibung durchackere, momentan hab ich die nicht. --Wurgl (Diskussion) 10:22, 20. Mär. 2024 (CET)

Lieber @Thiemo Kreuz (WMDE), danke fürs schnelle Kümmern! Wende dich gerne an den Kollegen @Wurgl, ich bin tatsächlich vor allem der Überbringer der Nachricht. Das Tool ist übrigens auch für enwiki wichtig, ich kann mich erinnern, dass James Heilman damals darauf gedrungen hatte, dass es dort auch funktioniert, als er noch im Board der WMF war. Und dann ging es da auch. :) --Viele Grüße, Aschmidt (Diskussion) 10:23, 20. Mär. 2024 (CET)

Das wäre schön, wenn die WikiHistory wieder funktionierte! Immer runterscrollen und auf "Authors" klicken und dann wieder hochscrollen zu müssen ist im Alltag tatsächlich eins der größten Ärgernisse. Viele Grüße, Grueslayer 09:01, 22. Mai 2024 (CEST)

Seit heute Morgen funktioniert WikiHistory wieder. Ein bisschen langsam, aber es werden wieder aktuelle Autorenanteile berechnet und zu Beginn des Artikels eingeblendet. Wer immer da gezaubert haben mag: Danke schön! :) --Viele Grüße, Aschmidt (Diskussion) 06:52, 3. Jul. 2024 (CEST)

Auch schon gesehen. Großartig! Vielen Dank!! Und viele Grüße, Grueslayer 07:06, 3. Jul. 2024 (CEST)

Wer auch immer das repariert hat: DANKE! mit Blümchen, Kuchen und Keksen. --Alraunenstern۞ 15:58, 5. Jul. 2024 (CEST)

---

Croptool

Problembeschreibung

Mit dem Croptool kann man von Bilder den Rand abschneiden und Bilder drehen. Eine Zusatzfunktion ist der "magic border locator", der gleichmäßige Ränder erkennt. Solche Ränder sind meist mir Software hinzugefügt, um Bilder „hübscher“ zu machen. Der Magische Randerkenner platziert den Bearbeitungsrahmen pixelgenau an der Innenseite des Rahmens, sodass man den Rahmen einfachen abschneiden kann.

Der "magic border locator" funktioniert seit einigen Monaten nicht mehr.

Dokumentation

c:Commons:CropTool/de

Eingereicht von Sebastian Wallroth (Diskussion) 08:31, 30. Mär. 2024 (CET)

Diskussion

Wie viele andere Tools auch ist das CropTool von der Infrastruktur-Umstellung der Wikimedia Foundation betroffen. Zum Glück ist der Großteil davon schon erledigt. Die (optionale) Funktionalität des "magic border locator" ist dabei möglicherweise durchgerutscht. Wir hoffen, wir können dabei helfen, und warten momentan auf eine Reaktion des Autors. --Thiemo Kreuz (WMDE) 16:59, 16. Apr. 2024 (CEST)

Uns sind hier leider die Hände gebunden. Obwohl der einzige Maintainer zumindest auf GitHub noch aktiv zu sein scheint, reagiert er nicht auf Ansprachen. Andere haben das Warten nach einem Jahr aufgegeben. Ich habe es hier noch einmal mit einem Ping versucht. --Thiemo Kreuz (WMDE) 17:34, 7. Jul. 2024 (CEST)

@Sebastian Wallroth: So weit ich das erkennen kann, scheint der "magic border locator" endlich wieder zu funktionieren. Ist es dir möglich, das zu überprüfen? Danke! --Thiemo Kreuz (WMDE) 10:10, 17. Okt. 2024 (CEST)

Hallo @Thiemo Kreuz (WMDE), ich kann bestätigen, dass der Magic Border locator wieder funktioniert. --Sebastian Wallroth (Diskussion) 10:20, 17. Okt. 2024 (CEST)

Dieser Abschnitt kann archiviert werden. Thiemo Kreuz (WMDE) 10:10, 17. Okt. 2024 (CEST)

---

XTools Edit Counter

Problembeschreibung

Xtools macht eine guten Auflistung inklusive der Logbucheinträge/Adminaktionen (block/delete/wasweißich). Dies funktoniert gut solange man lokale Administratorechte in einen Projekt hat oder hatte. Es gibt aber auch globale Gruppen die entsprechende Aktionen durchführen. XTools beachtet diese aber nicht z.B. https://xtools.wmcloud.org/ec/am.wikipedia.org/WikiBayer hier war ich Administrativ sehr aktiv, jedoch zeigt Xtools keie Aktionen an, da meine Rechte nicht lokal sind.

Eingereicht von ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Rechte ︱ boarische Wikipedia} 18:48, 14. Mai 2024 (CEST)

Diskussion

@WikiBayer: Vielen Dank für die Einreichung. Bitte entschuldige, dass wir uns erst jetzt melden. So weit wir das verstehen handelt es sich nicht um eine Reparatur im Sinne unseres Projekts sondern eine technische Einschränkung des Tools, die nur mit größeren Aufwand zu umgehen ist. XTools wird aktiv betreut. Wir schlagen vor, den Änderungswunsch auf Phabricator einzureichen. --Thiemo Kreuz (WMDE) 17:38, 25. Jun. 2024 (CEST)

---

OSM4Wiki neue Version

Gemeldet in Phabricator
Task T367044

Problembeschreibung

Ich habe kein Problem, und es muss auch nichts repariert werden. Ich habe mein Tool OSM4Wiki gründlich überarbeitet und suche jetzt Leute, die es genau so gründlich testen möchten. Näheres auf der Dokuseite:

Dokumentation

Benutzer:Plenz/OSM for Wiki v.2

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

Besonders hilflos stehe ich der Anzahl von Vorlagen gegenüber, die mein Tool benutzen. Ich hatte das Tool damals vor 13 Jahren vor allem für die Vorlage AllCoordinates geschrieben. Seitdem hat sich viel geändert. Parameter sind veraltet, verändert, hinzugekommen, es gibt neue Vorlagen... da stecke ich leider überhaupt nicht drin.

Eingereicht von Plenz (Diskussion) 17:14, 16. Mai 2024 (CEST)

Diskussion

Ich muss wohl den Tatsachen ins Auge schauen: total tote Hose hier - und auch anderswo. Nun gut. Mein Tool läuft unter Firefox und Edge, das muss dann wohl reichen. --Plenz (Diskussion) 16:26, 22. Mai 2024 (CEST)

Hallo @Plenz:, es hat etwas gedauert, da wir mit unserer Projektarbeit stark eingebunden sind, aber wir werden das Tool in den nächsten Wochen einmal im Rahmen der Reparaturhilfe kurz unter die Lupe nehmen. Ich habe dazu ein Ticket auf Phabricator erstellt. - Falls du denkst, dass es zusätzlich hilfreich sein kann, wenn wir kurz einen Blick auf den Quellcode werfen, bräuchten wir natürlich einen Link dafür. - viele Grüße -- Christoph Jauera (WMDE) (Diskussion) 13:57, 10. Jun. 2024 (CEST)

@Plenz: Wir haben unter T367044 ein paar Hinweise hinterlassen. Wir hoffen, das hilft dir weiter. Verschiedene Datenquellen können wir leider nicht testen da wir keine aktiven Nutzenden des Tools sind und nicht wissen, was es alles können muss. Eine gute Möglichkeit für andere Nutzende, dir Feedback zu geben, wäre ein "report an issue"-Link am Fuß der Seite, wie es beispielsweise die XTools machen. --Thiemo Kreuz (WMDE) 18:44, 25. Jun. 2024 (CEST)

---

Bearbeiten eines zu sichtenden Artikels im VisualEditor

Gemeldet in Phabricator
Task T365334

Problembeschreibung

Seit einigen Wochen bis Monaten gibt es einen etwas anderen und störenden Ablauf beim Sichten eines Artikels. Nach einer eigenen Bearbeitung eines zu sichtenden Artikels hat eine Sichterin oder ein Sichter zusätzliche Arbeit:

Durch das Bearbeiten eines zu sichtenden Artikels im VisualEditor und nur dort - im Quelltext klappt es wie "früher" - entsteht eine zusätzlich separat zu sichtende Version beim zu sichtenden Artikel.

Bis vor einiger Zeit konnte von einer Person mit Sichtungsrechten in folgender Situation ein Häkchen gesetzt werden:

• Bearbeitungen von Artikeln im VE, zu denen es ungesichtete Versionen gibt.

Dies war (und ist) unabhängig von weiteren dort möglichen Häkchen ("K." oder "auf Beo setzen"). Aktuell werden trotz gesetztem "Häkchen" bei "Sichte vorherige (bisher ungesichtete) Versionen" und Klick auf Veröffentlichen die vorherigen Versionen nicht gesichtet. Anschließend ist nun zunächst die Versionsgeschichte aufzurufen, um dann die Sichtung durchführen zu können.

Es wäre arbeitserleichternd, wenn die Funktionsfähigkeit auch im VE wieder hergestellt werden würde.

Dokumentation

? Vermutlich gibt es hier etwas, was nützlicherweise einzutragen wäre. Ich verbringe bereits deutlich mehr Zeit als von mir vermutet damit, diesen Wunsch überhaupt auf dieser Seite hier so einzutragen, wie es die Vorlage offenbar erwartet. Daher schicke ich das jetzt erst mal so als Wunsch ab und beobachte diese Seite.

Eingereicht von

Grüße von Iva; (Diskussion) 17:23, 19. Mai 2024 (CEST)

Diskussion

Danke für die Einreichung Iva. Wie umseitig erläutert liegt das Problem leider eigentlich außerhalb unseres Wirkungsbereich (Community-Werkzeuge), aber über den Phabricator-Task, den mein ehrenamtliches Ich erstellt hat phab:T365334, scheint das Problem in den nächsten Tagen hoffentlich behoben zu werden. --Johannes Richter (WMDE) (Diskussion) 18:02, 21. Mai 2024 (CEST)

Dankeschön! Ist dadurch zumindest sehr klar in Bewegung gekommen. Grüße von Iva; (Diskussion) 16:41, 8. Jun. 2024 (CEST)

@IvaBerlin: Die oben erwähnte Reparatur ist inzwischen auf allen Wikis aktiv. Kannst du das Problem noch nachvollziehen oder ist es damit behoben? --Thiemo Kreuz (WMDE) 13:22, 27. Mai 2024 (CEST)

Jein. Das Sichten scheint jetzt wieder auch aus dem VE zu funktionieren. Ich bekomme nach dem Setzen des Sichtens (und Drücken des Veröffentlichen-Buttons) die Info, dass meine Bearbeitung veröffentlicht wurde. Das Register "Ungesichtete Änderungen" bleibt erhalten. Wenn ich dann vorsichtshalber mal in die Versionsgeschichte schaue, kann ich sehen, dass alle Versionen als gesichtet gekennzeichnet stehen. Erst zu diesem Zeitpunkt verschwindet das o.g. Register. Ich bin nicht ganz sicher, ob das vorher auch schon so war. Ich wollte es auf jeden Fall erw#hnt haben, wo ich schon mal die Stelle gefunden habe, wo so etwas offenbar bearbeitet/geklärt/behoben wird. 8-)

Grüße von Iva; (Diskussion) 16:41, 8. Jun. 2024 (CEST)

Danke für die Rückmeldung. Das verbliebene Problem ist sehr wahrscheinlich älter und auch außerhalb unseres direkten Aufgabenbereichs. Wir haben es unter phab:T367052 an das VisualEditor-Team weitergereicht. --Thiemo Kreuz (WMDE) 14:53, 10. Jun. 2024 (CEST)

---

Geschlechtergerechte Sprache in Benachrichtigungen

Gemeldet in Phabricator
Task T368249

Problembeschreibung

Einige Benachrichtigungen zum Beispiel über die Verleihung von Rechten nutzen in ihren deutschsprachigen Übersetzungen pauschal die männliche Form. Das fällt besonders deshalb auf, weil die Benachrichtigungsfunktion seit langem geschlechtergerechte Sprache unterstützt und an den meisten Stellen auch verwendet.

Eingereicht von IvaBerlin via Thiemo Kreuz.

Diskussion

Übersetzungen werden von der Translatewiki-Community gepflegt. Die englischsprachigen Nachrichten und wie flexibel sie lokalisiert werden können (z. B. ob eine Nachricht überhaupt gegendert werden kann) sind jedoch Teil der Software, in diesem Fall Echo. Insofern handelt es sich vielleicht nicht um die „Reparatur“ eines „Werkzeugs“, aber doch um ein Problem an der Schnittstelle zwischen Softwareentwicklern und Community. Wir haben unter T368249 angefangen, die offenkundigsten Problemstellen zu sammeln. --Thiemo Kreuz (WMDE) 18:20, 25. Jun. 2024 (CEST)

---

Mapframe

Gemeldet in Phabricator
Task T305121

Problembeschreibung

Es geht um das Werkzeug mapframe. Als seinerzeit das Projekt zu Mapframe lief, hatte ich mich intensiver damit beschäftigt und mapframe in zahlreichen Artikeln erfolgreich eingefügt. Ein Problem blieb aber offen und konnte bisher nicht geklärt bzw. gelöst werden. Auf meiner Testseite https://de.wikipedia.org/wiki/Benutzer:Ulanwp/Testseite wird der öffentliche Park in Auckland nicht dargestellt. Geht man in den Editmodus oder zoomt man über das Symbol oben rechts wird Mapframe korrekt abgearbeitet und der Park dargestellt.

Ich finde keine Lösung für das Problem.

Eingereicht von Ulanwp (Diskussion) 15:26, 27. Jun. 2024 (CEST)

@Ulanwp: Danke für die Erinnerung. Das Problem ist bekannt, siehe phab:T305121. Leider ist das Team Technische Wünsche augenblicklich nicht in der Position, darauf Einfluss zu nehmen. Ich habe hier und hier aber zwei alternative Vorschläge hinterlassen, wie sich das Problem aktuell schon umgehen lässt. Ich hoffe, das hilft. --Thiemo Kreuz (WMDE) 14:40, 1. Jul. 2024 (CEST)

Hallo Thiemo Kreuz (WMDE); vielen Dank für deine Antwort; die alternative Verwendung von geoshape statt geomask hatte ich in dem originalen Artikel auch schon vollzogen. Das mit der Koordinatenangabe in geomask zur Lösung des Problems war mir neu. Vielen Dank für deine Info und Lösungsansätze hierzu. zu dem anderen Problem warten wir dann mal auf phab:T305121 Gruß -- Ulanwp (Diskussion) 11:33, 2. Jul. 2024 (CEST)

---

Automatisierte Abfrage der Google-Books-ID zu einem Hathitrust-Item

Problembeschreibung

1) Gibt es eine Möglichkeit, die Google-Books-ID eines Bandes, der in Hathitrust vorhanden ist, automatisiert abzufragen?

Wenn ich z.B. einen Band in Hathitrust aufrufe wie diesen Band 43.1874 der Allgemeine medicinische Central-Zeitung

unter https://babel.hathitrust.org/cgi/pt?id=hvd.32044097070866&seq=10

aufrufe, so kann ich dort durch Klicken auf die Option „Get this item / Hol dir diesen Band“ auf der linken Seite des Menüs und anschließendes Klicken auf die Option „Download at Google Books / Buch auf Google Books herunterladen“ im linken Menü abgerufen werden.

Wenn man auf der Google Books-Seite des Bandes landet, muss man durch einen finalen Klick auf „Voransicht des Buches“ den Band wirklich öffnen und dann aus der URL oben die Google Books-ID (=die Zeichenfolge zwischen "?id= " und dem hinter der ID stehenden "&printsec=" extrahieren.

Diese ID von Google-Books ist permanent und kann in der Folge in die auf Wikisource etablierte Vorlage für Google Books = Guinea-Bissau Guinea-Bissau = eingefügt werden.

In dem obigen Beispiel landet man also durch Klicken auf die Option "Get this item" und dann "Download at Google Books" auf die Seite https://books.google.de/books?vid=Harvard:32044097070866&redir_esc=y und von dieser nach Klicken auf "Voransicht des Buches" auf https://books.google.de/books?id=a78AAAAAYAAJ&printsec=frontcover, wovon also "a78AAAAAYAAJ" die ID ist, die man in die Google Books-Vorlage einfügt => Guinea-Bissau Guinea-Bissau

Dokumentation

Mit diesem Tool können Bände, die auf Hathitrust hochgeladen sind und von Google Books digitalisiert wurden, auf Google Books wiedergefunden und ihre ID automatisiert ermittelt werden.

Ein den Prozess des dreimaligen Klickens automatisierendes Tool kann viel Zeit sparen.

Eingereicht von

--Haendelfan (Diskussion) 00:31, 10. Okt. 2024 (CEST)

Diskussion

Hier ist Platz für Diskussionen, weitere Hinweise usw. zu diesem Wunsch.

Lösung mit Greasemonkey

Hallo @Haendelfan: und danke noch einmal für deine Einreichung hier. Wie wir schon kurz auf der WikiCon besprochen haben, gibt verschiedene Möglichkeiten, dass einem der Browser solche repetitive "Klickarbeiten" etwas abnimmt. Ich werde hier eine Lösung vorstellen, die die Erweiterung Greasemonkey für den Firefox Browser benutzt. Für Greasemonkey kann man kleine Scripte in JavaScript schreiben, die dann auf den gewünschten Seiten ausgeführt werden, um zum Beispiel Aktionen dort auszuführen oder Änderungen an der Oberfläche vorzunehmen.

Im folgenden eine kurze Anleitung um Greasemonkey zu installieren und das Script einzurichten:

• Das Addon für Firefox installieren über [2]addons.mozilla.org
• In der Symbolleiste von Firefox sollte nun ein Knopf mit dem Greasemonkey-Logo erscheinen, ein Klick darauf öffnet das Menü des Addons
• Dort einfach auf "Neues Benutzerskript" gehen um ein neues Script anzulegen
• Nun öffnet sich ein Tab im Browser wo man den Quelltext des Scripts eingeben kann

Folgenden Inhalt kannst du dort hineinkopieren:

// ==UserScript==
// @name     Google Book ID
// @version  1
// @grant    none
// @match *://books.google.de/*
// @match *://books.google.com/*
// @match *://babel.hathitrust.org/*
// ==/UserScript==
  
// Wait 3 seconds to give the pages time to finish loading
window.setTimeout( () => {
  
  if ( window.location.host.includes( 'babel.hathitrust' ) ) {
    // Find and click the link to the Google Books page 
    document.querySelector("a[href^='https://books.google.com/books']")
      .click();
  }
  
  
  if ( window.location.host.includes( 'books.google' ) ) {
    // Find the preview link and extract the book id from it
    const id = document.querySelector("#preview-link a")
    .href
    .match( /(id=)([^&]+)/ )[2];

    if ( id ) {
      // Echo the id using an alert box
      window.alert( 'Greasemonkey Script\n\nGoogle Book ID: ' + id );    
    }
  }
    
}, 3000);

Wenn du das Script speicherst sollte es aktiv sein. Sobald du jetzt mit dem Browser auf eine babel.hathitrust.org Seite gehst ( siehe Zeile 61 ), sollte er automatisch den Google Link finden und klicken ( Zeilen 63-64 ). Im Anschluss sucht das Script auf books.google.com ( Zeile 68 ) den Link zur Vorschau, extrahiert die Google ID aus der URL ( Zeilen 70-72 ) und zeigt sie in einer kleinen Infobox an ( Zeile 76 ).

Im Greasemonkey Menü kannst du das Script übrigens auch ggf. ausschalten, falls es mal im Weg steht.

Ich hoffe das hilft und viele Grüße ;-) -- Christoph Jauera (WMDE) (Diskussion) 14:26, 29. Okt. 2024 (CET)

hallo Christoph, ich bedanke mich ganz herzlich für das Skript und die Hilfe. Das klappt wunderbar und nimmt mir einiges an Arbeitsaufwand.

Liebe Grüße --Haendelfan (Diskussion) 11:15, 30. Okt. 2024 (CET)

---

Tooltip für Temporäre Konten

Problembeschreibung Ich bin gerade dabei, einen Skript zu schreiben, der bei den temporären Konten unterstützt. Leider schaffe ich es nicht die IP-Adressen abzurufen.

Dokumentation (Nur Codesnippet, wenn das mit der IP-funktioniert mache ich den Rest) test2:User:𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫/TempAccountTooltip.js

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

Eingereicht von ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 08:29, 27. Okt. 2024 (CET)

Diskussion

Hat sich erledigt, ich habe den Netzwerkverkehr analysiert und die apiabfrage der Mediawikoberfläche im Skript nachgebaut. Falls jemand das selbe Problem hat hier ist eine Lösung die funktioniert gitLab:wikibayer/TempAccountInfoTooltip ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 18:52, 27. Okt. 2024 (CET)

Ich benötige doch Hilfe. Ich kann jetzt zwar IPs abrufen jedoch nicht in Logbüchern. z.B. https://cs.wikiversity.org/wiki/Speci%C3%A1ln%C3%AD:Z%C3%A1znam_filtr%C5%AF_zneu%C5%BEit%C3%AD. Da Logbucheinträge keine Revid haben funktioniert in diesen nicht. --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 13:23, 1. Nov. 2024 (CET)

Ich habe jetzt gesehen, das es möglich ist die IPs ohne revid abzufragen und gemacht. Jetzt habe ich, allerdings noch das Problem z. B. Missbrauchsfilter Logbuch bekomme ich aufgrund der Einschränkung keine IP Informationen z.B. Land. --ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 17:48, 1. Nov. 2024 (CET)

---

Commons Upload Wizard bzw. Wiki Uploader - zur Nutzung mit iOS-Geräten

Problembeschreibung

Es gibt offenbar immer noch keine einfache Möglichkeit, mit dem iPhone aufgenommene Fotos samt Geodaten auf Commons hochzuladen.

Der "Upload Wizard" akzeptiert (trotz bislang anderslautender Dokumentation) zwar die HEIF-Bilddateien des iPhones, übernimmt dabei aber den Aufnahmeort nicht. In selteneren Fällen wird gelegentlich auch das Aufnahmedatum nicht übernommen.

Ein Hochladeassistent bzw. eine Smartphone App für iOS/ iPhone war bereits vor 2014 angekündigt worden. Aktuell gibt es aber anscheinend lediglich die Commons Mobile app die wohl nur mit Android-Geräten funktioniert.

Der im AppleAppStore verfügbare Wiki Uploader ist im Prinzip ziemlich toll, aufgrund einiger kleinerer Problemchen, die ich hier beschrieben habe, aber nur sehr eingeschränkt nutzbar.

Ich stelle mich als Ansprechperson für diesen Vorschlag zur Verfügung

Ich hatte auch bereits einen entsprechenden "technischen Wunsch" auf dem Wunschparkplatz eingetragen, doch wurden sämtliche bisherigen Wünsche offenbar kürzlich ins Archiv verschoben.

Betroffen ist wohl im Grunde jeder Besitzer eines iPhones, der mit dem Telefon aufgenommene Bilder in Commons hochladen möchte.

Der "Wiki Uploader" wurde ursprünglich von Lyudmyla Ivanova entwickelt.

Eingereicht von

kai kemmann Verbessern statt löschen 10:08, 14. Nov. 2024 (CET)

Diskussion

@KaiKemmann: Dies hier ist der falsche Ort du musst dich hier an die Mediawiki Entwickler wenden, die dafür zuständig sind. Wikimedia Deutschland entwickelt die App nicht. Die Reparaturhilfe ist für Benutzerskripte oder Tools da. Dein Anliegen gehört entweder auf Phabricator oder auf die Wunschliste im metawiki.-ᵂᶦᵏᶦᴮᵃʸᵉʳ 👤💬 _{Skripte ︱ Rechte ︱ GitLab} 19:35, 18. Nov. 2024 (CET)

Hi @KaiKemmann wir haben deine Einreichung beim WP:Technische Wünsche/Wunschparkplatz wahrgenommen und in unsere Planungen für die kommende Technische-Wünsche-Umfrage einbezogen, deshalb wurden die Wünsche dort archiviert [3]. @WikiBayer hat recht, dass Apps in die Zuständigkeit der Wikimedia Foundation fallen, das Thema also außerhalb unserer Zuständigkeit liegt. Die meta:Community Wishlist könnte in der Tat ein guter Ort sein, den Wunsch einzureichen. Wir haben deinen Wunsch aber sinngemäß interpretiert und werden mehrere Themenschwerpunkte zu Commons zur Wahl stellen. --Johannes Richter (WMDE) (Diskussion) 10:26, 19. Nov. 2024 (CET)

---