:* Ein „Sichten und Aufräumen“ ist gleich gar nicht an Externe delegierbar, denn das ist ja gerade die Zielvorstellung der Community, die sie zuvor selbst erarbeiten müsste. Und „Aufräumen“ heißt Gadgets abschalten und nicht mehr anbieten, und das gibt vorhersehbar jeweils einen <s>Sh</s>-Proteststurm. Wofür es auch keinen Anlass gäbe, denn das was Community-Gadget ist wurde bereits (fast durchgängig durch mich) modernisiert, oder es ist bekannt wodurch es zu ersetzen wäre, oder wird irgendwann unrettbar eingehen; ist aber bis dahin mindestens auf dem Stand von 2011. Der Zustand aller Community-Gadgets und deren Prognose ist zumindest mir sehr exakt bekannt.
:* Ein „Sichten und Aufräumen“ ist gleich gar nicht an Externe delegierbar, denn das ist ja gerade die Zielvorstellung der Community, die sie zuvor selbst erarbeiten müsste. Und „Aufräumen“ heißt Gadgets abschalten und nicht mehr anbieten, und das gibt vorhersehbar jeweils einen <s>Sh</s>-Proteststurm. Wofür es auch keinen Anlass gäbe, denn das was Community-Gadget ist wurde bereits (fast durchgängig durch mich) modernisiert, oder es ist bekannt wodurch es zu ersetzen wäre, oder wird irgendwann unrettbar eingehen; ist aber bis dahin mindestens auf dem Stand von 2011. Der Zustand aller Community-Gadgets und deren Prognose ist zumindest mir sehr exakt bekannt.
:: Jemand der nicht selbst mit einem Tool/Gadget/Helferlein arbeitet oder wenigstens mit der vom Tool/Gadget/Helferlein abgedeckten Problematik vertraut ist, wird nix Sinnvolles auf die Reihe bekommen. Und mit einer ganzen Palette von Tools sind Leute von außerhalb einfach restlos überfordert. --[[Benutzer:Wurgl|Wurgl]] ([[Benutzer Diskussion:Wurgl|Diskussion]]) 16:47, 9. Okt. 2020 (CEST)
== Meldungen und Mitteilungen ==
== Meldungen und Mitteilungen ==
Version vom 9. Oktober 2020, 16:47 Uhr
WP:TW ist eine Weiterleitung auf diese Seite. Die technischen Wünsche befinden sich unter Wikipedia:Technische Wünsche.
Vermutete Software-Fehler: Ist die deutschsprachige Wikipedia schuld oder die weltweite Software? Ggf. Weiterleitung mittels Phabricator (ehemals: „Bugzilla“).
Möglich ist alles, was zur Unterstützung der Mitarbeit an den Wiki-Projekten der WMF dient.
Sachdienliche Antworten können von allen gegeben werden; siehe ansonsten Wikipedia:Werkstätten zu den Gepflogenheiten.
Geeignete Fragen sind beispielsweise:
Mein CSS an dieser Stelle stellt nicht das dar, was ich möchte; warum nicht?
Ich will diese spezielle Aufgabe mit JavaScript automatisieren oder unterstützen. Auf Skin/Benutzerskripte habe ich nichts dazu gefunden. Gibt es dafür schon irgendwo etwas Fertiges?
Mein JavaScript geht nicht! Warum? Damit wir dir helfen können, benötigen wir von dir Angaben mit maximal möglicher Präzision:
Welche Funktion und Wirkung erhoffst du dir?
Welche Wirkung erfolgt im Moment?
Welchen JS-Code hast du schon? Wikilinks angeben, ggf. darin bei längerem Code charakteristische Zeichenketten zum Suchen und Finden.
Tritt das Problem nur in bestimmten Situationen auf? Nur bei bestimmten Artikeln: Wikilinks? Bei einem Browser geht es, mit dem anderen nicht – dann Versionsnummern!
Gibt es Fehlermeldungen, insbesondere mit Zeilennummer? Copy&Paste + oldid/Uhrzeit dieses Skripts!
Soll das Seitenlayout (Skin, Bedienungselemente) verändert werden? Dann diese Skin nennen.
Du hast einen mutmaßlichen Software-Fehler entdeckt, magst das aber nicht auf Phabricator melden? Wir prüfen gern, ob dies ein weltweiter Fehler ist oder ein in der deutschsprachigen Wikipedia hausgemachtes Problem (für das Phabricator nicht zuständig wäre), und leiten das Ergebnis geeignet weiter.
Ich möchte mit einem Skript Daten über die API abfragen, komme aber weder mit der Dokumentation noch mit der API-Spielwiese zurecht. Kann mir jemand sagen, welche Parameter ich senden muss, um diese Daten zu erhalten?
Es geht um „CSS in Vorlage“ – und du kannst dich nicht entscheiden, ob du hier oder in der Vorlagenwerkstatt richtig bist? Das ist völlig egal; in beiden Werkstätten werden dieselben Leute antworten. Weil aber unterschiedliche Kreise mitlesen und spezifisch archiviert wird, sollten reine Vorlagen-Angelegenheiten in der Vorlagenwerkstatt geklärt werden, also speziell zur Vorlagen-Systematik, Vorlagen-Parameter, Kategorien, Programmierung.
Technisch ist es nicht möglich, dass jemand anders deine .css- oder .js-Benutzerseiten verändert; auch wer besondere Rechte dazu hat, wird dies nicht tun.
Oder vielleicht doch vorher mal in die Anleitung gucken?
Nebenbei: Wenn dir so gut geholfen wurde, dass es ein paar Tage in diversen Situationen einwandfrei funktioniert, ist es gern gesehen, wenn du selbst einen Baustein {{Erledigt|1=~~~~}} setzt, damit die automatische Archivierung tätig wird.
Nur mal drübergeschaut: Mir fehlt da noch ein loader.using mit mediawiki.util und jquery.cookie. Mit Großbuchstaben beginnende Variablennamen sind mir persönlich nicht so lieb. Der dritte Parameter undefined wirkt überflüssig. Man könnte das CSS auch vereinfachen, wenn man die Rules kombiniert und dann nur noch ein display:none hat. Vielleicht komplett auf jQuery umsteigen? Du nutzt einmal setAttribute mit style und einmal obj.style. Auch wenn das letzter für nur ein Attribut einfacher ist, könnte man es einheitlich gestalten. Alles unverbindlich und nur wenn du es auch sinnvoll findest. Der Umherirrende 19:54, 11. Apr. 2012 (CEST)
Ja, wenn das inzwischen möglich ist, wäre das eine feine Sache. Vielleicht lässt sich das auch mit der neuen Funktion der Änderungen seit dem letzten Besuchen auch realisieren. Das wäre noch eleganter, denn das kommt ohne zusätzliche Speicherung von persistenten Daten aus und ist universeller. --Fomafix (Diskussion) 10:27, 29. Mai 2012 (CEST)Beantworten
Kann über die API angefragt werden, was die letzte besuchte Revision einer Seite ist? Wenn ja wie? Den Besuchszähler kann man auf die aktuelle Revision setzten, indem man eine Seite besucht. Geht das auch über die API? --Fomafix (Diskussion) 09:51, 31. Mai 2012 (CEST)Beantworten
Die Hilfe zu action=query&list=watchlist führt unter wlprop den Wert notificationtimestamp an: Adds timestamp of when the user was last notified about the edit, ein Update ist wohl über $.get('/w/index.php?title=...') möglich. Allerdings müsste man dazu alle Benutzer zwingen, eine bestimmte Seite zu beobachten; da man außerdem auf die Antwort der API warten müsste, würde es zudem zu sichtbaren Verzögerungen beim Ausblenden kommen. (Außer man blendet erst mal auf Verdacht aus, und dann je nach Antwort der API wieder ein.) --Schnark10:08, 31. Mai 2012 (CEST)Beantworten
Soviel habe ich inzwischen auch herausbekommen. wl_notificationtimestamp existiert nur, wenn die Seite in mw:Manual:Watchlist table ist. Zuerst müsste die Seite per API auf die Beobachtungsliste gesetzt werden, um das notificationtimestamp verwenden zu können. Das bringt mich auf eine andere Idee. Wäre es möglich das Einblenden und Ausblenden der Nachrichten über Einträge in der Beobachtungsliste zu steuern? Ich mache mir ein paar Gedanken. Auch das verzögerte Ein- oder Ausblenden ist ein wichtiges Thema. Derzeit geschieht Ausblenden auch etwas verzögert, weil JavaScript erst nach dem vollständigen Laden der Seite ausblendet. Ein zusätzlicher Request ist aber eine deutliche längere Verzögerung. --Fomafix (Diskussion) 16:05, 31. Mai 2012 (CEST)Beantworten
Über notificationtimestamp wird das "Fette" auf der Beobachtungsliste oder die E-Mail-Benachrichtigung gesteuert. Dort steht der Timestamp der ersten Änderung, die man noch nicht gesehen hat. Per API kann man das aktuell nicht zurücksetzen (Bug 18758). Der Umherirrende 16:18, 31. Mai 2012 (CEST)
Egal, was wir tun, wir müssen es bald tun, denn in Kürze wird die Funktion getElementsByClassName entfernt, die in dem Skript noch verwendet wird. Ich bin dafür, Fomafix Variante zu übernehmen, ob wir von den Cookies auf etwas anderes umsteigen wollen oder können, kann ja immer noch diskutiert werden. Wobei ich inzwischen von meinem eigenen Vorschlag nicht mehr so ganz überzeugt bin, Cookies haben den Vorteil, dass sie automatisch entfernt werden und Benutzer, die eine Meldung versehentlich weggeklickt haben, eine (ihnen vermutlich bekannte) Möglichkeit besitzen, sie wieder hervorzuholen, nämlich einfach die Cookies zu löschen. --Schnark09:41, 4. Nov. 2013 (CET)Beantworten
Wenn es nur darum geht, das ist leicht rauszupatchen, indem man getElementsByClassName(docobj, 'div', 'watchlist-message') durch $('div.watchlist-message', docobj).get() ersetzt (getestet, funktioniert). --TMg21:49, 5. Nov. 2013 (CET)Beantworten
Ich hab mir die Version von Fomafix nochmal angesehen. So ganz funktioniert sie aktuell nicht. Zum einen ist .watchlist-message aktuell eine Klasse, keine ID. Vor allem sind die aktuell zwei Kästen in MediaWiki:Watchlist-summary per display:none standardmäßig ausgeblendet. Ich halte das für eine sehr gute Idee. Wer JavaScript abgeschaltet hat, hätte sonst überhaupt keine Möglichkeit, die Meldungen verschwinden zu lassen. Dass die Seite beim Einblenden der Kästen kurz hüpft, halte ich für kein Problem. Der Benutzer nimmt die Kästen auf diese Weise sogar besser wahr, liest sie kurz und klickt sie weg. Danach stört (dank des hart kodierten display:none) garantiert nie wieder ein Hüpfer den Seitenaufbau. --TMg22:16, 5. Nov. 2013 (CET)Beantworten
Ich habe auf beta einen kleinen Test gestartet: Das ready-Event tritt schon vor dem Laden des /watchlist.js-Skripts auf, sodass es für den Seitenaufbau keine Rolle spielt, ob die gelesenen Boxen gleich beim Laden per CSS (wie bei Fomafix) oder wie bisher per JavaScript nach dem Auftreten des ready-Events ausgeblendet werden. --Schnark10:22, 6. Nov. 2013 (CET)Beantworten
Erweiterung der Signatur-Zeitstempel auf Diskuseiten
Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ich ärgere mich immer mal wieder, wenn auf Artikeldiskussionsseiten Mängel angemerkt worden sind, die nie kommentiert wurden. Es ist mitunter relativ mühsam, die Artikelversion zu suchen, die zum Zeitpunkt des Diskuseiten-Eintrags gültig war und diese mit der aktuellen Version zu vergleichen. Ich würde mir daher eine Erweiterung in der Form wünschen, dass auf Artikeldiskuseiten hinter jeder Signatur zwei Links auftauchen in der Form:
Anmerkung -- Signatur Zeitstempel ([Link zur zugehörigen Artikelversion|Version], [Difflink dieser Version zur aktullen Version|Diff])
Es ist nicht nur prinzipiell denkbar; es ist ganz konkret technisch lösbar.
Scheint mir ein sinnvolles und wünschenswertes Hilfsmittel zu sein.
Es geht nicht nur auf Artikel-Disku, sondern auf jeder seitenbezogenen Diskussionsseite.
Zwar sind Diskussionsseiten seit Jahren ein Auslaufmodell, LiquidThreads gerade beerdigt und mw:Flow noch in der Konzeptionsphase, aber auch da gibt es den Bezug zu einer spezifischen Version einer Seite im Namensraum.
Konkret würde das so aussehen:
Dass es in der Werkzeugbox einen Knopf gibt [Diese Disku mit Versions-Links ausstatten] – auf besonderen Wunsch immer schon so ausgerüstet, aber das bringt die Ladezeit in die Kniee und wäre nur opt-in.
Wenn ausgelöst, werden alle Verlinkungen auf href="/wiki/Benutzer(in)? gesucht; blinkende Signaturen mit Bildchen dabei ignoriert werden müssen; irgendwann würde aber ein Datumsformat 11:01, 27. Feb. 2013 (CET) oder CEST (Gadget-Zeitzonenkonverter beachten) folgen. (Vorlage:Unsigniert usw. auch noch bedenken)
Hinter dem Zeitstempel wäre ein Button einzufügen.
Dieser Zeitstempel, der leider von MediaWiki nicht speziell als ~~~~~/~~~~~~ klassifiziert wird, lässt sich semantisch auslesen und in formales Datum überführen.
Mittels der API kann man zum aus dem Seitennamen der Diskussionsseite leicht erratbaren Seitennamen der SUBJECTPAGE (Vorsicht: Verschiebung, curid nötig?) eine API-Abfrage generieren. Sie würde aber erst gestartet werden, wenn auf diesen Button draufgeklickt wird.
Beim ersten Klick würde per API die Revisionsliste abgerufen werden:
api.php?action=query&prop=revisions&titles=
Mit dem Parameter rvend= auf ein Zeitfenster eingegrenzt. rvstart= ist nicht sinnvoll; es findet sich beim Ende-Zeitpunkt schließlich die Version, die zur Zeit des Diskussionsbeitrags gültig war.
Dabei ist zu beachten, dass diese Zeitstamps in der lokalen Server-Zeit ablaufen, auch die Umstellung auf Sommerzeit mitmachen, mutmaßlich den gleichen angezeigten Nennwert haben und nicht in UTC oder Winterzeit vorliegen. Die Speicherung kann ein paar Sekunden abweichen. Das Intervall sollte ein paar Stunden weiter gefasst sein als akut benötigt; etwa begrenzt auf rund 50 Einträge rückwirkend.
Die API-Ergebnisse sollte man im JS-App-Objekt dieser Disk cachen als von/bis/RevID-Array; bei einem Klick auf einen anderen Disku-Beitrag wäre zu klären, ob nicht für das neuerlich gesuchte Zeitintervall bereits ein Eintrag bekannt ist. Bei mehrfachen Abrufen wird nach und nach die ganze Versionsgeschichte der SUBJECTPAGE hinterlegt.
In dem Moment, in dem festgestellt wird, dass der Zeitpunkt in einem Zeitintervall liegt, ist die RevID bekannt.
Nun kann diese RevID angezeigt werden in einem separaten Fenster/Tab; konfigurierbar
immer in demselben Zweitfenster
dasselbe Zweitfenster für jede Version dieser SUBJECTPAGE
jede RevID in einem Zweitfenster, dies aber möglichst wiederverwendbar. Das ist über die Hinterlegung des window.open() im von/bis/RevID-Array und seine momentane Eigenschaften (closed, URL) möglich.
Ist die RevID bekannt, kann auch das Difflink gebaut werden. Würde also (zur besseren Unterscheidbarkeit zwischen Signatur-Klickibunti und ursprünglichem Seiteninhalt) auf eine Ausstattung mit einem Anforderungs-Button nach jedem Beitrag hinauslaufen (sowas wäre unmöglich auf einer normalen Seite), der sich beim Anklicken nach Eintreffen des API-Ergebnisses/Cache in zwei Buttons oder eine Fehlermeldung wandelt. Der erste Button wird mit menschenlesbarer Zeitangabe der SUBJECTPAGE beschriftet, auf dem zweiten steht dann schlicht „Diff“.
Alle weiteren (zumindest unmittelbar vorangegangenen) Disku-Beiträge können dann mit etwas Glück von dem mitgelieferten Schwung an 50 Einträgen der Versionsgeschichte profitieren und würden sich sofort wandeln.
Letzter Kommentar: vor 11 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo Skin-Werker, unter Hilfe Diskussion:Signatur#Benutzernamen aus Verlinkung anzeigen? fragte ich nach einer Möglichkeit bei Signaturen, die nicht den Benutzernamen anzeigen, dies mittels CSS oder JS einzublenden. Ist jetzt nicht so, dass ich ohne das nicht leben könnte, aber manchmal rätsele ich zunächst, weil ich etwas nicht auf Anhieb nachvollziehen kann. Sei es, dass ich beim Nachvollziehen diskutierter Änderungen in einer Versionsgeschichte nach einem Phantom gesucht habe, weil der Signatur-Name nicht der Benutzername ist oder dass auf Benutzerbeiträge in einer Diskussion mit dem Benutzernamen Bezug genommen wird, dieser aber dort nicht auftaucht. Da es offensichtlich mehrere Benutzer gibt, die sich mit verdeckten Benutzernamen schwer tun, könnte das ein nützliches Gadget sein. Ob das Gadget den Benutzernamen nur ergänzt oder die Signaturveränderung in der Anzeige weitgehend unwirksam macht, wäre offen. Hat jemand von euch Interesse das umzusetzen? Grüße --Diwas (Diskussion) 23:28, 17. Apr. 2013 (CEST)Beantworten
Ah, stimmt, danke, diesen Baukasten haben wir ja auch noch. Das ist so das Problem mit Schnipseln ohne Doku-Seite; zumal nur der nicht mehr aktive Ce2 Werbung für sich machen sollte.
Für eine Benutzerin: ist das allerdings blind. Dafür kann Ce2 nichts; 2006 gab es in der Wikipedia noch keine Benutzerin.
Eine Neukodierung nach sieben Jahren wäre trotzdem mal eine Überlegung wert; auch mit benutzerdefinierten Optionen, was genau mit maskierten Benutzernamen geschehen solle, und auf welchen Seiten. Im WP:K sind Autorenkürzel Standard. Im ANR (-QS) und auf Spezialseiten wäre der momentane Aufruf hingegen nur selten sinnvoll.
@Diwas: Wenn du das gelegentlich ausprobiert haben solltest, kannst du ja schildern, ob es dich bereits glücklich macht.
Danke, um den (einen oder anderen) sonnigen Tag nicht zu verpassen ... hab ich es erst jetzt ausprobiert. Tut eigentlich was ich meinte. Viele Benutzerinnen, noch dazu mit der Angabe und noch dazu abweichender Signatur, wird es wohl nicht geben. Da ich mir beispielsweise Administratoren kennzeichnen lasse, hab ich jetzt hinter dem (A) nochmal den Benutzernamen, auch wenn er schon davor offen steht, aber das macht ja nichts. Grüße --Diwas (Diskussion) 21:36, 27. Apr. 2013 (CEST)Beantworten
Das HTML-Attribut class="metadata" in den Zellen der rechten Spalte blendet die rechte Spalte aus, aber nichts, was im erzeugten HTML außerhalb dieser Zellen steht. Die mit <ref> erzeugten Fußnoten stehen zwar im Wikitext innerhalb der Tabelle, aber nicht im erzeugten HTML (dort stehen sie im unteren Abschnitt, wo man sie auch sieht).
Hinweis auf diesen Edit, der m. E. zurückgesetzt werden sollte.
An der Sache selbst hat sich aber nichts geändert: <element class="metadata">…<element> blendet nur aus, was innerhalb des Elements steht, und dazu gehören Fußnoten nun einmal nicht. Es wird sich auch niemals etwas daran ändern, da die Fußnoten ein Feature der MediaWiki-Software sind, während class="metadata" ein lokaler CSS-Hack ist, mit dem die MediaWiki-Software nicht rechnet. Es ist technisch unmöglich, diese Konstellation durch eine Erweiterung des lokalen CSS-Hacks zu erkennen, da CSS hierfür nicht ausdrucksstark genug ist.
Für die CSS/Chrome-Experten: Wenn ich in den Developer Tools von Chrome, wenn man das QS-Bild auswählt, die CSS-Regel .content img { max-width: 100% !important; } (von [1]) deaktiviert, sieht es wieder ganz normal aus. Und wenn man die Fensterbreite auf weniger als ungefähr 475px verkleinert, springt das sonst verzerrt mitschrumpfende Bild aus seiner Tabellenzelle raus und wird "normal" dargestellt in der Zelle daneben. --se4598 / ?15:13, 16. Mär. 2014 (CET)Beantworten
nochmal in Bugzilla gesucht: könnte bugzilla:62460 sein. Der vorgestellte Fix (an einem leicht anderen CSS-Selektor wegen Less?) dort löst laut meinem Test gerade das auf eine spezielle Weise: Das (QS-)Bild wird nicht verzerrt. Es wird einfach nur bis nur Nichterkennbarkeit kleiner. Jemand mehr Durchblick? --se4598 / ?15:23, 16. Mär. 2014 (CET)Beantworten
Moin Moin @Mabschaaf und se4598, da Benutzer Impériale augenscheinlich nicht mehr im Projekt unterwegs ist, mal an euch beide. Ich würde den Absatz für erledigt ansehen, mag das jemand von euch gegenprüfen? Bugzilla ist geschlossen, meine Mobil-Version zeigt allerdings kein Icon. mfg --Crazy188021:55, 8. Jun. 2019 (CEST)Beantworten
@Crazy1880: Auf meinem Mobilphone sehe ich (beobachtet in Guanidiniumcarbonat) zwar kein verzerrtes Bild wie oben beschrieben, dafür das Icon in geschätzter Größe von 5x5px. Es stört nicht wirklich, weil es so klein ist, aber erfüllt natürlich auch nicht seinen Zweck. Aus meiner Sicht daher nicht erledigt.--Mabschaaf19:03, 9. Jun. 2019 (CEST)Beantworten
Der Medizin-QS-Baustein zeigt das linke Bild in gleicher Weise extrem verkleinert, den rechten Wikiball dagegen gar nicht (Chiroskop). Der Baustein der Biologen (Tuberkel) und der Physiker (Gequetschtes Licht) ist anders aufgebaut (Piktogramm wird vom Text umflossen), dort gibt es das Problem so nicht. Falls es hilft: iOS 12.2, Monobook.--Mabschaaf10:04, 10. Jun. 2019 (CEST)Beantworten
Hinweis: Da spielt der Skin mit rein! Unangemeldet (Browser-Ansicht mit Vector) beginnt der Text der QS-Box sich unter einer Breite (des Browserfensters) ca. 485 Pixel mit dem Rahmen zu überschneiden, außerdem wandert die Infobox zu weit nach rechts und überschneidet sich mit der Leiste links. Das Icon is QS-Box behält konstante Größe.
Angemeldet mit Monobook wird unter einer Breite ca. 550 das Icon plötzlich winzig und die Leiste links verschwindet. Und bei kleinerer Breite als ca. 390 Pixel wandert die Infobox links aus dem Fenster und ich auch per Scrollbar nicht zu erreichen.
In der mobilen Ansicht ist das Icon in der QS-Box immer recht klein, wird aber je nach Fensterbreite noch kleiner. Bei ca. 1070 Pixel Fensterbreite ist IMHO der erste Verkleinerungsschritt des Icons. Dafür skaliert die Infobox brav, da wird nix abgeschnitten und auch das QS-Fenster skaliert ganz nett, das bekommt eine hor. Scrollbar.
Ich rate erstmal zur syntaktischen Entrümpelung und Modernisierung, und wenn mit aktueller Syntax das Problem weiter besteht, dann mag es näher untersucht werden. Ist aber Angelegenheit der Chemiker; denen ihr Design und Dings. Mängelliste:
align:center;
Ist falsche Syntax; deshalb komplett ignoriert.
Gemeint war: text-align:center;
Wirkung trotzdem fraglich bei Block-Elementen auf Seitenbreite. Worauf soll es überhaupt wirken, wenn es nioht ohnehin unwirksam wäre?
Kann für den Block eigentlich niemals auftreten, es sei denn, der Text wird auf einer Kinoleinwand in einer einzigen Zeile dargestellt.
Wenn überhaupt, dann class="center" oder class="centered"
Tabelle: Schreiben wir in der Vorlagenprogrammierung vollständig mit |- nach {|
Jedoch kein Effekt betreffend Problematik.
<noinclude>
Schreiben wir nicht mehr, sondern <onlyinclude>.
Jedoch kein Effekt betreffend Problematik.
Datei:...|zentriert
Inhaltlich sinnlos.
Wäre in der Tabellenzelle ohnehin am gleichen Ort, weil Text-Zelle sich maximal ausbreiten wird.
Möglicherweise ursächlich.
Barrierefreiheit
Gegenüber blinden Benutzern blenden wir nicht weiterhelfende Dekoration aus. Heißt: Icon nur für Sehende.
Druckausgabe
Da zeigen wir eigentlich keine Management-Kästen.
{{Dokumentation/ruler}}
Damit deuten wir den Beginn der Doku und das Ende der Demo an.
Tabelle in div
Vielleicht mal was Hochmodernes: Gar keine Wikisyntax-Tabelle mehr, dafür responsives Design.
Mal mit den fraglichen Geräten deren Einbindungen ausprobieren. Wenn dort Problem futsch, dann in der syntaktischen Struktur der Statistik die Chemie mit deren Texten und Icon und Farben neu aufbauen, und gut ist.
Fehlfunktion des Linksymbols oben im Bearbeitungsfenster
Letzter Kommentar: vor 9 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Wenn ich beim Artikelschreiben eingeloggt bin und einen Begriff mit Hilfe des Linksymbols oben im Bearbeitungsfenster verlinke, fliege ich beim weiteren Schreiben bei der nächsten Betätigung der Zeilensprungtaste aus meinem Wikipediakonto raus. Der eingegebene Text ist verschwunden und das Bearbeitungsfenster des Lemmas geschlossen. Wie kann das sein? Ich habe gestern beim Erstellen eines Textes 10 Versuche gebraucht, den Text fertigzustellen, wobei mir der Text jedesmal gelöscht wurde.--Orik (Diskussion) 00:00, 4. Mai 2015 (CEST)Beantworten
Da empfehle ich Dir: Erstelle Deinen Beitrag in einem externen Editor, schreibe die links von Hand aus, und kopiere das fertige Projekt anschließend in das Bearbeitungsfenster. Da geht Dir der geschriebene Text nicht mehr verloren. J. K. H. Friedgé (Diskussion) 09:49, 4. Mai 2015 (CEST)Beantworten
Wenn ich mit solch laienhaftem Vorgehen, das ich auch versucht habe, zufrieden waere, haette ich mich nicht an die technische Nothilfe gewendet. Waere es nicht passender, die Verlinkungssymbol ( eine Kette) aus dem oberen Rand des Bearbeitungsfensters zu nehmen, um nicht dieses jeden Tag zig-tausendfach auftretende Problem zu vermeiden? Oder man kann ja auch diesen Befehl, der oben am Bearbeitungsfenster sitzt, neu programmieren. Das schöne an dem Werkzeug im Bearbeitungsfenster ist doch, dass ich bereitstehende Symbole verwenden kann und nicht jeden Befehl voll ausschreiben muss. Man kann die Verlinkung auch mit dem Werkzeug am unteren Ende des Berabeitungsfensters machen, das ist nicht ganz so komfortabel, aber geht ohne Probleme. Das obere fehlerhafte Symbol ermöglicht gleichzeitiges Schreiben von Linkziel und einen abweichenden Linktext - - also eigentlich eine gute Einrichtung. --Orik (Diskussion) 10:43, 4. Mai 2015 (CEST)Beantworten
Dass das Problem "jeden Tag zig-tausendfach" auftritt, darf wohl bezweifelt werden, dann gäb's längst jede Menge Beschwerden dazu. Bei mir scheint es jedenfalls nicht aufzutreten. Gerade hier im Abschnitt testweise gemacht: Text eingegeben, Link mit der Bearbeitungsfenster-Funktion gesetzt, Text weitergeschrieben,
Enter gedrückt, weitergeschrieben, Vorschau, alles gut, weitergeschrieben, Speichern, immer noch eingeloggt. Ist das bei dir hier heute noch reproduzierbar? Mit welchem Browser? --YMS (Diskussion) 11:22, 4. Mai 2015 (CEST)Beantworten
Ich habe den Assistenten wieder demontiert, mal sehen ob es, Zeilensprung
klappt. Ja, ich bin nicht rausgeflogen. Es funkioniert. Danke für den Tip. Ich habe einen Mac, Syst 10.6.8 und den Safaribrowser 5.1.10 ( alles neuestmögliche Software). Gruss --Orik (Diskussion) 17:36, 4. Mai 2015 (CEST)Beantworten
Weil aus mir unerfindlichen Gründen ich bei der mobilen Anwendung ein paar Abschnitte höher bearbeiten muss, damit es am eigentlichen Ziel ankommt. Frag die Software-Entwickler, warum das so ist.--Gruß KriddlBitte schreib mir etwas.09:03, 4. Jun. 2015 (CEST)Beantworten
Letzter Kommentar: vor 9 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
Ich benutze Schnarks kombiniertes PD&ND-Skript derzeit extrem oft. Seit gestern nachmittag kann ich aber plötzlich nur noch die ND bearbeiten, aber nicht mehr die PD. Ich habe zwar Schnark gestern abend auf seiner Seite gefragt, woran es liegen könnte, aber bisher keine Antwort bekommen (auch kein Wunder, so lange ist das ja noch nicht her). Trotzdem frage ich hier nach, weil es für meine derzeitige Arbeit sehr wichtig ist. Ich habe gehört, dass immer Donnerstags Wikipedia-Patchday sei, kann es damit zusammenhängen? MfG --Informationswiedergutmachung (Diskussion) 11:09, 26. Jun. 2015 (CEST)Beantworten
Es wird möglicherweise an der Änderung von Modul jquery.mwExtension zu Modul mediawiki.RegExp liegen. Schnark verwendet zwar mw.loader.using('jquery.mwExtension'), aber vielleicht ist irgendwo etwas vergessen. Hast Du unter Spezial:Einstellungen#mw-prefsection-editing die Option „Erweiterte Bearbeiten-Werkzeugleiste aktivieren“ aktiviert. Der WikiEditor lädt derzeit noch jquery.mwExtension. Vielleicht hilft das übergangsweise. --Fomafix (Diskussion) 11:28, 26. Jun. 2015 (CEST)Beantworten
Ich hatte gestern Abend für einige Stunden ein vergleichbares Problem, das sich heute morgen entmaterialisert hatte (phab:T103891).
Browser-Cache heftig löschen.
Wenn du kannst, mal vorübergehend mw.loader.store.clear(); vorn in deine common.js einbauen.
Wenn du kannst, WP:JS#Fehlerkonsole nutzen und uns mögliche Details benennen.
Schnark schaut erfahrungsgemäß morgen früh rein.
Um die Ausgangsfrage zu beantworten: Ja, kann es. Der Plan von Fomafix ist nachvollziehbar.
"Erweiterte Bearbeiten-Werkzeugleiste aktivieren" war schon aktiviert, den Cache habe ich geleert, den mw.loader.store.clear(); eingebaut. Funktioklappt aber trotzdem nicht. Und mit WP:JS#Fehlerkonsole kenne ich mich so gut wie gar nicht aus. Nun ja, muss ich auf Schnark warten, danke für die Antworten. MfG --Informationswiedergutmachung (Diskussion) 12:20, 26. Jun. 2015 (CEST)Beantworten
Es liegt daran, dass das Modul 'jquery.mwExtension' verwendet wird, bevor es geladen ist. Das Modul war vor der Änderung wohl standardmäßig bei jedem Artikel geladen, so dass die fehlende Abhängigkeit nicht aufgefallen ist. Jetzt wird das veraltete Modul nicht mehr geladen und dann gehen teilweise Skripte kaputt. Ich vermute aber, das alle diese Skripte auch schon vorher die Abhängigkeit nicht eindeutig deklariert hatten. (gerrit:219570, Abhängigkeit war sonst über 'mediawiki.util.js' immer gegeben, weil das Modul immer da ist). @Schnark: müsste migrieren oder die Abhängigkeit ergänzen (oder beides). Der Umherirrende16:39, 26. Jun. 2015 (CEST)Beantworten
so wie es jetzt ist, ist es jedenfalls unbrauchbar. Mit Hand PD nachtragen oder sie zu überprüfen führt zu einem viel zu hohen Arbeitsaufwand. Gestern habe ich Gustav Laddey erstellt, üblicherweise brauche ich für einen Artikel (ohne Schreibfehlerkorrektur) genau zwei Edits: einen, um ihn neu reinzustellen und einen, um ihn mit PD & ND zu ergänzen. Das dauert keine Minute, gestern habe ich dafür fünf Minuten gebraucht. Die Bitte geht daher an Schnark das nach Möglichkeit schnell zu ändern, u.a. weil ich diese Liste (4.587 Fehler, noch) schnellstmöglich abarbeiten will. Zwar funktioniert das ND-Tool, aber oft genug sind die PD auch ungenügend und zweimal alles abarbeiten wäre reine Zeitverschwendung. --Informationswiedergutmachung (Diskussion) 17:36, 26. Jun. 2015 (CEST)Beantworten
@Umherirrender: Verwende ich es denn irgendwo ohne die Abhängigkeit korrekt zu deklarieren? Für mich sieht es so aus, als handle es sich nur um Fehler in anderen Skripten, die dann halt auch meine beeinträchtigen. (Was nicht heißt, dass ich die Funktion nicht dringend ersetzten sollte, mein Testskript, das mich über Deprecations unterrichtet, dreht gerade durch und spuckt 8825 Warnungen aus.) --Schnark09:52, 27. Jun. 2015 (CEST)Beantworten
@Schnark: Ich bin gestern auf eine Artikelseite einer Person gegangen und habe in der Konsole importScript( 'Benutzer:Schnark/js/personendaten.js' ); geschrieben, damit dein Skript geladen wird. Anschließend gab es "Das Objekt unterstützt die Eigenschaft oder Methode "escapeRE" nicht" in der Funktion wo staatenRe aufgebaut wird. Daraus habe ich geschlossen, dass die Funktion dann nicht zur Verfügung steht, wenn sie gebraucht wird. Du lädst die Funktion, aber anscheinend wird sie auch schon bei der Initialisierung benötigt und stand dann nicht zur Verfügung. IE11. Nach deiner Änderung funktioniert wieder alles ohne Fehler. Der Umherirrende10:28, 27. Jun. 2015 (CEST)Beantworten
Letzter Kommentar: vor 8 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo,
die obengenannte Systemnachricht wird benutzt, um auf einigen Spezialseiten (insbesondere Special:Logs) einen Hilfe-Link in der Ecke oben rechts anzuzeigen, wo kein MediaWiki-eigener Hilfe-Link vorhanden ist.
Die Implementierung verlässt sich auf einen skinabhängigen CSS-Hack (nämlich auf denselben wie die Koordinaten), der ohnehin problematisch ist.
Ein Ersatz durch das „offizielle“ Softwarefeature <indicator> ist nicht möglich, da dies nicht in allen betroffenen Systemnachrichten funktioniert.
Ein Ersatz durch MediaWiki-eigene Hilfe-Links (wie man sie auf einigen Spezialseiten wie Spezial:Letzte Änderungen sieht) wäre optimal, ist aber durch uns nicht zu leisten.
Die durch unsere Systemnachricht implementierten Hilfe-Links sehen anders aus als die MediaWiki-eigenen (kleiner, am oberen Rand klebend).
Es ist zu erwarten, dass die gegenwärtige Lösung durch den Umschrieb aller Spezialseiten auf OOUI in absehbarer Zeit zumindest auf manchen Spezialseiten überhaupt nicht mehr funktionieren wird.
Ich habe daher eine JavaScript-Lösung entworfen und bitte um Beurteilungen, ob wir diesen Weg gehen sollten. Die Systemnachricht wäre durch den folgenden Inhalt zu ersetzen:
Dazu käme (sinngemäß) das folgende JavaScript, das natürlich ggf. auch in ein Gadget verpackt werden kann:
/** * Unterstützung für [[MediaWiki:Specialpage-helplink]] * Simuliert das Aussehen und Verhalten derjenigen Hilfe-Links, die durch * OutputPage::addHelpLink() erzeugt werden */if(mw.config.get('wgNamespaceNumber')===-1){mw.loader.using(['mediawiki.helplink'],function(){mw.hook('wikipage.content').add(function($content){$content.find('.specialpage-helplink').prependTo('.mw-indicators').show().children('a').addClass('mw-helplink').attr('target','_blank').removeAttr('title');});});}
Der Code ist von dem ehemals in MediaWiki:Vector.js vorhandenen Code für „Top-Icons“ abgeleitet (Permalink). Ein offensichtlicher Nachteil dieser Lösung wäre, dass sie nur bei aktiviertem JavaScript funktioniert; dies halte ich aber für verschmerzbar, da die Implementierung bis vor kurzem noch an die „Top-Icons“ gekoppelt war, die im Vector-Skin ebenfalls nur bei aktiviertem JavaScript funktionierten.
Die „Design-Ziele“ meines Entwurfs sind folgende:
Die Lösung soll möglichst einfach (und insbesondere nicht skinabhängig) sein.
Das Resultat soll so exakt wie möglich das Aussehen und Verhalten der MediaWiki-eigenen Hilfe-Links simulieren (daher die vielleicht etwas merkwürdig anmutenden Manipulationen von Attributen).
Die Lösung soll keine „kreativen“ Missbrauchsmöglichkeiten in der Seitengestaltung eröffnen (daher sollte das Skript nur auf Spezialseiten laufen).
Statt prependTo fände ich appendTo logischer (auch wenn es in der Praxis keinen Unterschied machen sollte). Der Form halber wäre es zudem schön, wenn es zumindest ein Phabricator-Ticket gäbe, in dem darum gebeten wird, die indicator-Methode überall möglich zu machen, dieses beim Code erwähnt wird und dann natürlich auch die Seiten umgestellt werden, wo kein JS zur korrekten Anzeige mehr notwendig ist. Ansonsten volle Zustimmung von meiner Seite. --Schnark09:32, 12. Mai 2016 (CEST)Beantworten
Der Beweggrund für prependTo war folgender: Die <indicator>-Elemente sind ja rechtsbündig ausgerichtet und das Skript würde den Hilfe-Link dort hinzufügen. Wenn eine Spezialseite aus irgendeinem Grund ein „echtes“ <indicator>-Element enthält, würde ein appendTo des Hilfe-Links dazu führen, dass das „echte“ <indicator>-Element während des Ladevorgangs wahrnehmbar nach links rutscht. Mit prependTo wird dieser Effekt vermieden. In der Praxis tritt so eine Konstellation aber derzeit eh nirgends auf.
Ein Phabricator-Task wäre sicher gut, aber ich bin nicht sicher, was drin stehen sollte. Man könnte anregen, dass die <indicator>-Methode in den betroffenen Systemnachrichten verfügbar gemacht wird, aber man könnte auch anregen, dass jede betroffene Spezialseite einen MediaWiki-eigenen Hilfe-Link erhält (was gemäß phab:T45591 vermutlich prinzipiell erwünscht ist). Beides würde unsere Probleme lösen, aber ich fände es etwas dreist, gleich beides anzuregen.
Was mich noch interessieren würde, wäre die Sicherheit. Ist der konkret vorgeschlagene Code dahingehend problematisch? Es werden ja Elemente ungeprüft verschoben, was bei benutzergenerierten Inhalten grundsätzlich problematisch sein kann, allerdings kenne ich benutzergenerierte Inhalte auf Spezialseiten nur auf Special:ExpandTemplates.
Bei appendTo vs. prependTo war meine Überlegung, was passiert, wenn auf einer Spezialseite dynamisch Inhalt hinzugefügt wird, der .specialpage-helplink-Elemente enthält. Das sollte zwar auch nirgendwo vorkommen, aber in dem Fall wäre es logischer, die neuen Elemente anzuhängen.
DOM-Elemente zu verschieben sollte keine Sicherheitsprobleme erzeugen. Da sehe ich keine Probleme. Die ISBN-Suche kann übrigens auch von autoconfirmed-Benutzern bearbeitet werden.
Zu Gadget vs. Common.js: Der Code muss ohnehin auf allen Seiten geladen werden (die Abfrage, ob man sich auf einer Spezialseite befindet vom eigentlichen Code zu trennen, wäre wohl zu ineffizient), da der Code aber immer auf das mediawiki.helplink_Modul warten muss, gäbe es selbst mit einem im Seitenkopf geladenen Gadget keinen flackerfreieren Aufbau. Damit spielen die beiden Hauptgründe für eine der beiden Methoden keine Rolle. Wenn es ein Gadget wird, dann sollte in Common.js zumindest ein Kommentar, der darauf hinweist, damit Benutzer, die an der klassischen Stelle nach dem Code suchen ihn auch finden. --Schnark10:37, 13. Mai 2016 (CEST)Beantworten
OK, vielen Dank soweit. Aber noch eine Frage:
Eigentlich muss der Code gar nicht immer auf das Modul mediawiki.helplink warten, da dies nur CSS enthält, das nur gebraucht wird, wenn ein .specialpage-helplink-Element vorhanden ist. Ist es überhaupt korrekt, diese Beziehung durch eine Abhängigkeit auszudrücken? Man könnte auch (analog zu dem Nachladen von jquery.ui.button in MediaWiki:Common.js) zuerst die Seite analysieren und es nur laden, wenn mindestens ein .specialpage-helplink-Element da ist. Oder wäre dann ein FOUC zu befürchten?
@Umherirrender: Vielleicht kannst du auch noch etwas dazu sagen, da du die Systemnachricht erstellt hattest? Vor allem würde mich interessieren, warum <indicator> an manchen Stellen nicht geht, wie aufwendig es wäre, das zu ändern und ob es überhaupt sinnvoll ist, diesbezüglich eine Änderung anzuregen.
Mit einem Nachladen statt der Abhängigkeit hätte man (vermutlich, ausprobiert habe ich es nicht) einen en:FOUC, was vermutlich (auch das habe ich nicht probiert) wesentlich störender wäre, als ein leicht verzögertes Auftauchen. --Schnark11:11, 13. Mai 2016 (CEST)Beantworten
Angefangen hat es hier, als es mehr wurde habe ich eine Vorlage raus gemacht, damit es überall gleich aussieht.
Technische Hintergrund: Das indicator-tag gehört (wie auch ResourceLoader-Module) zu den Metadaten des Output-Objects in MediaWiki. Beim parsen von Systemnachrichten werden diese Metadaten nicht verwendet, sondern nur der Text. Das führt dazu, dass die indicator-Tags in Systemnachrichten nicht funktionieren. Beim TOC ist es ähnlich, da das JS-Modul für das ausblenden zu den Metadaten hinzugefügt wird, ist es auf Spezialseiten nicht vorhanden (T66969). Meine Lösung war mal gerrit:196626, es gibt aber zu viele Bedenken wegen Seiteneffekte.
Am besten wäre es, wenn der generische Systemnachricht-Name zum überschreiben der Helplinks auf allen Spezialseiten funktionieren würde und standardmäßig nur leer ist, dann braucht es kein JS. Dies werde ich mal ausprobieren. Der Umherirrende15:30, 13. Mai 2016 (CEST)Beantworten
Das weiß ich mittlerweile selber. Aber diese Arbeitserleichterung war vor einiger Zeit sogar mal Tipp des Tages. Man sollte den Bug mal langsam abstellen - es wird mehr werden und die wenigstens der Fehler sind von mir. Übrigens: nettes Nerd-Kauderwelsch: In einer Extension erfolgt kein Reparsing des Wikitextes mehr, und der Pipe-Trick war schon vorher dran gewesen. :) --Informationswiedergutmachung (Diskussion) 15:30, 17. Okt. 2016 (CEST)Beantworten
Ich kann nichts dafür, dass jemand solch brisantes Zeugs auch noch zum Tdt macht.
Mir wäre es lieber, dass auch auf der Hilfeseite nicht für sowas Reklame gemacht werden würde.
Bei den Extensions wird der Inhalt zwischen den H:Tags herausgeschnitten, von dieser intern verarbeitet und das Resultat hinterher in die ansonsten fertige Wiki-Seite einkopiert. Alles, was ansonsten noch auf der Seite passiert, bekommt eine Extension grundsätzlich nicht mit, so auch nicht diesen gefährlichen Trick. Aussicht darauf, dass sich hieran etwas ändert, gibt es wenig, weil der Pipe-Trick zum Kern gehört und die Extension eben gerade außerhalb des Kerns liegt und ihr eigenes Ding macht. Die Architektur der Seitenaufbereitung wird zwar in diesen Jahren grundlegend umprogrammiert, aber das betrifft nur den Kern.
Eher für MediaWiki. Auch wenn man es schaffen würde diesen Bug zu fixen, würde das viele Seiteneffekte haben, die dann wieder als Bug aufgenommen werden sollen, obwohl es Features sind. Alle Tags (also alles mit spitzen Klammern was nicht HTML ist) wird identisch verarbeitet, aber bei pre oder nowiki will man vielleicht kein Pipe-Trick, da sie die Texte so darstellen sollen wie man sie übergeben hat. Man muss also Sachen die identisch behandelt werden, so trennen das es weiterhin das gewünschte Ergebnis liefert. Diesen Fix muss man dann noch ganz tief ins Herzstück der Wikitext-Verarbeitung platzieren. Da traut sich keiner der Freiwilligen dran und den bezahlten ist es vielleicht auch zu heikel. Der Umherirrende18:49, 17. Okt. 2016 (CEST)Beantworten
Ich versuche mal noobverständlich zu formulieren, was das Problem ist, weil ich's bis eben auch noch nicht verstanden hatte und einen ganz offensichtlichen Vorschlag machen wollte: Wenn der Benutzer auf "Änderungen speichern" drückt wird der Artikelquelltext an den Server gesendet. Dort wird dann der Pipe-Trick (genauso wie {{subst:) schon aufgelöst, und erst danach die Seite gespeichert. Wenn die Seite danach aufgerufen wird, liest der Server die gespeicherte Seite und verarbeitet die ganze restliche Wikisyntax, also u.A. Vorlagen, solche Tags wie <ref>, <gallery> oder <math>, und die Links selbst. --nenntmichruhigip (Diskussion) 21:21, 17. Okt. 2016 (CEST)Beantworten
Du hast schon ein Beispiel geliefert warum man nicht einfach subst und pipe-Trick vor dem Speichern auflösen kann. Nowiki würde nicht mehr funktionieren. Aus diesem Grund wird bereits vor dem Speichern (bzw. vor dem pst - pre-save-transform - "Vor-Speichern-Umwandlung") die Tags interpretiert und das führt zu diesem Ergebnis. Der Umherirrende22:08, 17. Okt. 2016 (CEST)Beantworten
Oh, stimmt, ich habe beim Schreiben ein paar Sätze vergessen :-) Ich versuche mal sie noch zu retten, wird jetzt evtl leider nicht ganz so noobfreundlich. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST)Beantworten
Die Inhalte der Mediawiki-Tags müssen bei der Transformation vor dem Speichern ignoriert werden, weil es bei deren Inhalt sehr wahrscheinlich ist, dass er anders interpretiert werden muss (z.B. <nowiki>, <math>). Wenn dann beim verarbeiten der restlichen Wikisyntax die Mediawiki-Erweiterung, die für die Verarbeitung dieser Tags zuständig ist, sagt "übersetze mir diesen Quellcode" wird er genauso verarbeitet wie der sonstige Quellcode nach dem Speichern. --nenntmichruhigip (Diskussion) 22:22, 17. Okt. 2016 (CEST)Beantworten
Die Analyse ist allerdings hochkomplex, muss nowiki, syntaxhighlight und HTML-Kommentare sowie Vorlagensyntax berückschtigen. Mal so eben regexpen wird nix.
Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Es wäre schön, bei der Ansicht von Änderungen direkt aus einem Änderungsblock heraus an die entspr. Stelle des erzeugten Texts springen zu können - vor allem dann, wenn der Quelltext z.B. mir Referenzen durchsetzt und deshalb schwer zu erfassen ist. Klar - noch toller wär's, wenn man auch eine Referenz direkt anspringen könnte. Momentan nutze ich die Suchfunktion des Browsers dafür, aber das könnte wirklich bequemer gehen. Danke für Hinweise! --Karsten Meyer-Konstanz (D)11:27, 20. Nov. 2016 (CET)Beantworten
Interaktive Karten auf Wikipedia
Letzter Kommentar: vor 5 Jahren10 Kommentare5 Personen sind an der Diskussion beteiligt
Diese neue Funktion ermöglicht es den Editoren, interaktive Karten in jede Wiki-Seite einzubetten. Diese Funktion ähnelt der <maplink> Funktion; aber anstelle eines Links zu einer Karte, die in einem Fenster geöffnet wird, sehen Sie ein schön formatiertes Bild der Kartendarstellung. Dieses Bild kann durch Klicken mit ihm interagiert werden.
Videos, die diese Funktionen demonstrieren, können auf Commons gefunden werden. [2][3]
Die <mapframe> in Vorlagen und andere mehr technische Implementierungen. Die <mapframe> Funktion kann mit anderen Projekten (wie der Sandkasten auf Mediawiki.org) experimentiert werden, um die Funktion zu erleben und Reaktionen zu geben.
Wir möchten diese Funktion von Anfang bis Mitte Januar aktivieren, wenn wir die Unterstützung der Community hier haben. Bitte informieren Sie uns über irgendwelche Gedanken oder Interessen.
erstmal ist es gut, wenn das Feature aktiviert wird. Ob es dann genutzt wird, ist ja nochmals eine andere Frage. Meine Punkte
In Polnähe bietet Kartographer keinen Ersatz für die bisher verwendeten Postionskarten, vergleiche [[4]] (dort den Link folgen) und Südpol / Lage der verschiedenen Südpole. An einigen Stellen (z.B. Infoboxen) wird nicht nach Breitengradregionen unterschieden, d.h es würde die Einsetzbarkeit von Kartographer erst ermöglichen, wenn in den Polregionen die entsprechenden Projektionen verwendet würde und nicht die dort unsinnige (vermutlich) Zylinderprojektion.
Kartographer unterstützt keine beliebigen labels, nur einfache ASCII-Zeichen.
In WP:de werden je nach Anwendungsfall politische oder topographische Karten (relief) eingesetzt. Um das abzubilden bräuchte Kartographer eine Möglichkeit das zu steuern und je nach Kontext andere Basis-Kartentypen einzublenden bzw. einen einfache Umschaltmöglichkeit in der Karte selbst.
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hi Wiki-Team,
hoffe bin hier mit meinem Anliegen richtig, sowie hoffe ich, dass die Anmerkung nicht schon aufkam, hab aber über die Suchfunktion nichts gefunden.
Ich habe folgendes Problem (und dachte ich sei damit alleine) und musste letztens feststellen, dass das wohl kein ungewöhnliches Problem ist.
Wenn man sich Artikel auf Android anschaut, so werden mehrheitlich die LaTeX-Formeln nur in minimaler Größe dargestellt und es ist notwendig diese erst heranzuzoomen, um sie lesbar zu gestalten.
Mal einen Beispielartikel aus der englischen Wikipedia, da dort amüsanter Weise beides auftritt: Lesbarkeit und gleichzeitig Unlesbarkeit.
https://en.m.wikipedia.org/wiki/Mean_value_theorem
Kann leider keine Bilddatei hochladen um das Problem zu Visualisieren und hoffe es ist reproduzierbar.
(Was man sehen sollte: Einleitungsformel ist Normalgröße. Formeln in "Formel statement" sind nicht lesbar, da zu klein)
Ich selbst nutze ein Samsung S5 mit der aktuellsten Android Software und das "normale Interneticon" von Samsung "Internet Version 4.0.20-17".
Auf Wunsch kann ich noch einen Link beisteuern, in dem das Problem in einem anderen Forum (wiki-unabhängig) schon angemerkt wurde, sowie ein Beispielbild dort zur Verfügung stellen, weiß aber nicht inwiefern das hier gern gesehen ist, fremde Links zu setzen.
Bei mir auf dem Desktop-Firefox sind die Formeln in der Einleitung ganz normal, und die dartuner (die bei dir zu klein sind) werden erst sehr viel später, also wohl per Javascript, nachgeladen. Möglicherweise besteht da irgendein Zusammenhang. Wegen Links auf externe Bilder oder Foren: Bei solchen Einträgen zur Problembehebung ist das idR in Ordnung :-) --nenntmichruhigip (Diskussion) 12:19, 28. Jan. 2017 (CET)Beantworten
Danke für die Hinweise. Dann füge ich auch gerade mal die Links bei, mit Bild :).
Standardtext beim Verwerfen von ungesichteten Änderungen bei IPv6 ist zu lange
Letzter Kommentar: vor 7 Jahren12 Kommentare7 Personen sind an der Diskussion beteiligt
Wenn man eine ungesichtete Änderung verwerfen und wieder auf die bisherige Version eines Artikeltexts zurücksetzen will, so erscheint ein Standardtext, der den Benutzernamen übernimmt:
(Die letzte Textänderung von ÄÄÄÄÄÄÄÄ wurde verworfen und die Version 000000000 von ZZZZZZZZ wiederhergestellt.)
Ist einer (oder gar beide) dieser Benutzernamen aber eine IPv6-Adresse, so wird der gesamte Text zu lange und man muss manuell kürzen, damit der Text nicht länger als 200 Zeichen wird. Bitte den Standardtext kürzen (z.B. Artikel entfernen gem. Beispiel):
(Änderung von ÄÄÄÄÄÄÄÄ verworfen und Version 000000000 von ZZZZZZZZ wiederhergestellt.)
Ich habe noch nie was mit Modulen in solchen Systemnachrichten zu tun gehabt, aber wenn Parserfunktionen gehen, dann gehen Lua-Aufrufe vielleicht auch. Falls nicht, käme eine JavaScript-Nachbereitung des BK-Vorschlags in Frage; die geht mit Sicherheit.
{{#if: {{#invoke:URLutil|isIPv6|1=$2}} | Dies | Das }}
Für JavaScript würde in der URL wohl irgendwas mit &undo= stehen; das ließe sich abfangen und in dieser Situation der Inhalt des BK nach einem gewissen Schema transformieren.
Ein Opt-Out-Gadget, und wenn eines Tages das Limit für BK-Länge erhöht wird, dann kann das auch wieder aus dem Angebot genomen werden.
Die IP-Verlinkung sollte schon funktionstüchtig bleiben und nicht gekürzt werden.
Konkrete Textvorschläge für den IPv6-Text?
@ProloSozz: Es braucht einen Techie aus dieser Werkstatt, einen Admin zum Live-machen, und WP:BETA zum Erproben.
Naja, wenn JavaScript eh abgeschaltet bleibt, dann bringt eine "Lösung" mit JS eh nix. Nun: ich würde momentan nicht mehr machen als wie im Beisipel oben ausgeführt. D.h.: "Die letzte Text..." entfernen und auf "Änderung" verkürzen (ob das erste oder letzte war, kann doch eh an der Nummer ersehen werden), "wurde" entfernen, "die" entfernen"; damit hat sich's vorläufig. Das wird sich dann weisen, ob das ausreicht oder immer noch zu lang ist. --ProloSozz (Diskussion) 17:03, 5. Mär. 2017 (CET)Beantworten
Also, „das wird sich dann weisen“ ist dieser Werkstatt nicht der Brauch. Das kann man sich ja vorher ausrechnen, wie viele Bytes dabei herausspringen werden, und es soll ja auch noch was übrigbleiben, um noch eine kleine Anmerkung dranzuhängen.
Und wenn ich mir Spezial:Diff/163237508 mal genauer anschaue, dann scheinen sich mir folgende Kürzungsmöglichkeiten auf Kosten der Schönheit zu ergeben:
Änderungen von [[Spezial:Beiträge/2003:75:8F17:B801:789F:728F:5D2C:79F7|2003:75:8F17:B801:789F:728F:5D2C:79F7]] ([[Benutzer Diskussion:2003:75:8F17:B801:789F:728F:5D2C:79F7|Diskussion]]) auf die letzte Version von [[Benutzer:Regi51|Regi51]] zurückgesetzt
Die Diskussionsseite einer IPv6 scheint mir kein unmittelbar dringendes Ziel zu sein.
Die Maskierung der Beitragsliste mag entfallen.
So auch die vornehm gekürzte Linkbeschriftungeiner Versionsnummer.
Warum „wenn JavaScript eh abgeschaltet bleibt“ der Fall sein solle, habe ich jetzt nicht verstanden.
a) "Wird sich weisen ..." Die Textlänge ist auch von der Namenslänge des Vorschreibers abhängig. Und da i.d.R. auf eine Version eines namentlich angemeldeten Benutzers revertiert wird, dessen Name nicht so überlang ist wie eine IPv6-Adresse, ist vorerst mal eine Länge einzuhalten, die für eine (einzige) IPv6-Adresse erträglich ist; und das dürfte mit der bestehenden Feldlänge noch zutreffend sein. Klar wäre es sicher nicht zu verachten, wenn genügend Platz da wäre, um zwei IPv6-Adressen unterbringen zu können. Aber das würde dann wohl nicht ohne Feldlängenvergrösserung gehen; und die könnte jetzt noch zurückgestellt werden. Sollte sich aber trotz Systemtextkurzform das Problem weiterhin zeigen, dann müsste die Feldlänge dann doch erhöht werden. Und genau _das_ wird sich weisen, ob das dann doch nötig würde.
b) Ich hab' JS eigentlich immer abgeschaltet und schalte das nur dann ein, wenn es nicht anders geht. Auf die kleinen Zusatzdetails (wysiwyg etc.) kann ich gerne verzichten, wenn ich es nicht ausdrücklich mal einsetzen will (und dann wird kurzzeitig JS eingeschaltet und nach der Aktion wieder aus). Und das werden hier viele auch so handhaben. Deshalb sollte es eine Lösung sein, die ohne JS auskommt.
c) Als Text würde "Änderung(en) von ÄÄÄÄÄÄÄÄ auf letzte/erste Version(en) 000000000 von ZZZZZZZZ zurückgesetzt." ausreichen; da wäre dann sogar das "erste"/"letzte" noch mit dabei (das "die" kann auch entfallen). --ProloSozz (Diskussion) 19:17, 5. Mär. 2017 (CET)Beantworten
@ProloSozz
Ich schrieb oben: möglichst Lua; notfalls JavaScript („gehen Lua-Aufrufe vielleicht auch. Falls nicht“).
Wenn Lua nunmal nicht geht, dann bleibt eben nur JavaScript – wenigstens für die weitaus überwiegende Mehrheit der Benutzer.
Erfreulicherweise konnte ich jedoch erproben, dass Lua hier einsetzbar ist.
Wenn also eine IPv6 eine andere IPv6 revertiert, kommen 315 Bytes für die IDs sowie 131 Bytes zusammen; 446 Bytes würden benötigt.
Ein Nick darf für die WMF wohl 32 Zeichen lang sein (mw:Manual:user table meint 255 varchar?) und wenn dafür nur altchinesische Schriftzeichen benutzt werden, dann braucht das nach meiner Kenntnis von UTF 128 Bytes je Nennung. Unser Standard-BK würde 771 Bytes lang.
Die Summary ist wohl weiterhin auf 255 Bytes begrenzt.
Ideen, das auszudehnen, gehen auf 2006 zurück.
Auch in jüngerer Zeit stand man seitens MW einer WMF-weiten Ausdehnung der zulässigen Länge sehr skeptisch entgegen.
Ich selbst halte überhaupt nichts von einer Aufblähung des BK. Ich will auf Beo und in der VG keine mehrzeiligen Gedichte zu lesen bekommen, sondern in knappen Schlagworten und ggf. mit Links das Ziel der Aktion zusammengefasst bekommen. Detailfragen sind erst im Diff zu erschließen.
Die Vorstellung aus Kindertagen der WP, man könnte im BK die vollständigen Literaturangaben für den Edit unterbringen (weshalb das noch Hilfe:Zusammenfassung und Quellen genannt wird), ist Quatsch. Allenfalls kann da mal eine IP den ungesichteten Edit untermauern. Aber über anderthalb Jahrzehnte alle URL in der Versionsgeschichte durchzuprobieren, damit jedes Mal jeder Leser herausfinden könne, welcher der Beleg für eine bestimmte Aussage sein soll, ist Unfug; dazu haben wir leserfreundliche Einzelnachweise mit direktem Bezug.
Eine Lösung über längere BK ist nicht zu erwarten (wir konnten leider ihre Bremsen nicht reparieren – deshalb haben wir ihnen eine lautere Hupe eingebaut).
Welche von den rollback-undo-Dingenskirchen werden denn noch produktiv eingesetzt? Die Tabelle oben ist nix.
Statt „Contributions“ dann natürlich offen „Spezial:Beiträge“.
Müsste man sich mal die genauen Limits für $1 und $2 ausrechnen; 2×$1 + 3×$2 < 120 oder so irgendwie.
Nix mit „es wird sich weisen“; vorher denken.
Benutzerskripte für rollback, die eine summary generieren, müssten analoge Überlegungen anstellen.
Übrigens gibt es auch doofe Logbucheinträge, in denen nicht anklickbare URL stehen; wobei oft anklickbare Wikilink-Syntax möglich wäre. Ließen sich vermutlich ebenfalls in geeigneten Systemnachrichten auffischen und verlustfrei umwandeln.
Ich würde es begrüßen, das in php für alle Wikis zu haben, nicht nur hier. Für FlaggedRevs gibt es bereits Ansätze dazu, daher gibt es "revreview-reject-summary-cur" und "revreview-reject-summary-cur-short". Der Umherirrende20:10, 10. Mär. 2017 (CET)Beantworten
Lupenfunktion für große Bilder (vor allem Landkarten)
Letzter Kommentar: vor 5 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
In etlichen Webshops wird für Abbildungen eine Lupe zum Vergrößern der Ansicht angeboten. Wenn man sie auswählt und damit über das Bild in Kleinformat fährt, bekommt man in einem PopUp-Fenster einen Ausschnitt des Bildes in Originalgröße angezeigt. Das wäre doch eine hervorragende Lösung für große Karten, um nicht zu Commons (oder zu meiner „Hilfslösung“ wie etwa bei Vegetationszone) wechseln zu müssen und gleichzeitig bei der Ansicht die Legende immer im Blick behalten kann. Hier ein Beispiel aus einem Webshop, dass meinen Vorschlag sicherlich sofort verständlich macht: Lupenfunktion auf Bild.
Wie ich die hiesigen Pappenheimer kenne, ist die Idee bestimmt nicht neu, es hatte halt noch keiner Lust sie zu programmieren. Aber ich lasse mich gerne überaschen.... 129.13.72.19812:36, 16. Mär. 2017 (CET)Beantworten
Ich lade das Bild (bei Bedarf) herunter und öffne es mit der Windows-Vorschau; damit kann ich nach Belieben zoomen. Bei Landkarten Screenshot machen und in der Vorschau zoomen ... :D --ProloSozz (Diskussion) 16:42, 25. Mär. 2017 (CET)Beantworten
Das ist zwar nett, aber doch keine Wiki-Lösung! Dabei kannst du die Legende nicht sehen und musst etliche Schritte vollführen, die viele User überhaupt nicht können/kennen. Meine Frage bleibt offen: Wie wäre es mit einer Lupenfunktion? --Fährtenleser (Diskussion) 07:19, 27. Mär. 2017 (CEST)Beantworten
Gerade für Landkarten bietet es sich an, dass in der Lupe nicht nur vergrößert sondern auch mit mehr Details dargestellt wird. Bin aber kein Fan von Schnickschnack auf WP. --Rainald62 (Diskussion) 14:07, 23. Sep. 2018 (CEST)Beantworten
Herunterladen einer zweispaltigen pdf-Datei bei Artikel "Bankhaus Friedrich Schmid & Co." nicht möglich
Letzter Kommentar: vor 7 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, ausschließlich bei dem Artikel "Bankhaus Friedrich Schmid & Co." ist das Herunterladen einer zweispaltigen pdf-Datei nicht möglich. Ich habe es mit verschiedenen PCs und Einstellungen probiert. Es erscheint immer die Fehlermeldung:
"Rendering fehlgeschlagen / Die Erstellung der Dokumentendatei ist fehlgeschlagen. / Status: Bundling process died with non zero code: 1"
Wer kann Abhoilfe schaffen? Vielen Dank im Voraus und Grüße --Salisburgensis (Diskussion) 08:14, 30. Mai 2017 (CEST)Beantworten
Wahrscheinlich niemand. OCG hat viele sehr aehnliche Fehlerberichte und wird soweit ich weiss von niemandem gewartet. Eine andere Software zum Erstellen von PDF-Dateien (namens Electron) ist in Arbeit. --Malyacko (Diskussion) 09:42, 30. Mai 2017 (CEST)Beantworten
Letzter Kommentar: vor 7 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn ich mich bei Wikipedia einlogge, erscheint wie gewohnt mein Benutzername oben in der Statuszeile.
Klicke ich anschließend auf irgendeinen Link und eine andere Wikipediaseite wird geöffnet, erscheint in der Statuszeile "nicht angemeldet". Ich kann mich dann zwar erneut anmelden, aber beim nächsten Wechsel auf eine andere Seite "vergisst" das System, dass ich bereits eingeloggt bin. Auch wenn ich beim Einloggen "Angemeldet bleiben" anklicke.
Auch diesen Beitrag kann ich nicht eingeloggt abspeichern, weil das System mich beim Speichern ausloggt. Meine Browser (Firefox, Google Chrome) akzeptieren Cookies.
Wo könnte der Fehler liegen? --gruhland
Letzter Kommentar: vor 7 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo allerseits,
es gibt ein Problem mit der Suchfunktion, das kürzlich (wieder) unter WP:FzW#Wasserfälle aufkam:
Seit Cirrus ignoriert die Artikelsuche diakritische Zeichen - wozu auch die Punkte über Umlauten zählen. So führt zum Beispiel die Eingabe von Bälle auf die Seite Balle, direkt, ohne Umweg über die Volltextsuche. Dieses Verhalten ist auf deWP leider in praktisch allen Fällen sinnlos und in vielen Fällen störend, wie die Anfrage auf FzW zeigt. Dort wurde das Problem mit einer (regelwidrigen) Weiterleitung als Workaround gelöst, was aber nicht als flächendeckende Lösung taugt.
Hmmm. Das ist IMO kein einfach zu loesendes Problem. Wie man an meinen Beitraegen unschwer erkennen kann, benutze ich eine Tastatur ohne deutsche Umlaute. Da finde ich es richtig gut, dass die aktuelle Suchfunktion mir einzelne Buchstaben ersetzt. Und das gilt auch fuer anderssprachige Sonderzeichen, z.B. Jørgensen (findet die Suche per "Jorgensen"; koenntest Du, Katimpe, problemlos ein "ø" produzieren? - und, falls "ja", koennte das die Mehrheit der Benutzer?). Dass in Einzelfaellen sic! dabei auch "falsche" Ergebnisse erhalten werden stellt mMn kein echtes Ausschlusskriterium dar. Just $0.02 von -- Iwesb (Diskussion) 03:58, 18. Jul. 2017 (CEST) PS: Waere ein entsprechender Schalter unter "Einstellungen" moeglicherweise eine Loesung?Beantworten
In meinen o.g. Beispielen gilt ja gerade das Umgekehrte: ä wird zu a, ø wird zu o und so weiter. Das braucht ganz sicher niemand. Und ansonsten:
Jørgensen hast du nur über die Autovervollständigung gefunden, sonst wärst du auf Jorgensen gelandet. Das Problem besteht ja vor allem darin, dass man direkt auf den falschen Artikel geführt wird, wenn der richtige nicht existiert.
Das Problem betrifft natürlich im Wesentlichen die Umlaute, mit denen der Durchschnittsbenutzer eben kein Problem hat. Aber auch für Zeichen wie ø haben wir bereits ein Instrument, es nennt sich Weiterleitung. Gäbe es Jorgensen nicht, würde man dort eine Weiterleitung auf Jørgensen einrichten. (btw, wieso muss ich dir das erklären?)
Wie ich sehe, ersetzt du das ä nicht durch a, sondern durch ae, was ja auch allgemein üblich ist. Diese Funktion bietet die Software gerade nicht! Könnte man natürlich einrichten - bloß, die Community hat sich meines Wissens vor langer Zeit gegen solche Weiterleitungen entschieden. Aber darum geht es hier nicht.
Was auch immer das Verhalten der Suchfunktion für Vorteile haben mag, sie lassen sich durch Weiterleitungen genauso herstellen, wenn man das denn will. Was man in den Einstellungen einrichten kann, weiß ich nicht, es geht um das Standardverhalten. Und das mag für einen Anglophonen in dieser Form Sinn ergeben, in der deutschen Wikipedia ist es einfach nur fehl am Platz. --Katimpe (Diskussion) 05:08, 18. Jul. 2017 (CEST)Beantworten
Hi everyone,
Sorry for replying in English, and for the very long message. I can get translation help if needed, but it will take a lot of time. I've been following the conversation with the help of Google Translate. Please forgive any misunderstandings.
There are multiple search-related issues here. I will try to identify them and explain them. Then maybe we can find the best course of action for each problem.
First, it is good to know that (1) searching from the input box in the upper right of the window (sometimes called the "Go" feature) and (2) full-text searching use different search methods with different language processing.
(1) The "Go" feature tries to match titles and does not break up words. If it cannot find an exact match, it will remove diacritics and try again. It actually does more than remove diacritics; it will also "fold" many Unicode characters into "simpler" or "more standard" characters. This includes removing diacritics, but also converting "ß" to "ss", Greek final sigma "ς" to regular sigma "σ", fullwidth numbers and letters "012ABC" to "normal" halfwidth "012ABC", halfwidth CJK characters "メ" to fullwidth "メ", and much more.
As a result, you can search in the "Go" (upper right) input box for ℬªɬĹɇ and you will land on the page Balle, because there is not page called "ℬªɬĹɇ". This is a more extreme case than Bälle taking you to the page Balle, but it is the same idea.
I believe that text processing for the "Go" feature is currently configured exactly the same on all wiki projects. It does not currently allow for customization.
(2) Full-text searching does language-specific processing of the text. This language-specific processing is provided by Elasticsearch and Lucene. These are the open-source technologies that CirrusSearch is built on. For many languages—like German, English, and French—we initially used with the language-specific processing provided by Elasticsearch without making any changes. We have customized English, French, and others, but German is using the original default configuration. The configuration for German full-text search could be changed. I would like to change it to include general character folding (except possibly ß, ä, ö, and ü), which the default language processing does not do. The extra folding in full-text search has been helpful on English and French wiki projects.
For whatever reason, the German language processing includes a step called "German Normalization" that does the following:* 'ß' is replaced by 'ss'
'ä', 'ö', 'ü' are replaced by 'a', 'o', 'u', respectively.
'ae' and 'oe' are replaced by 'a', and 'o', respectively.
'ue' is replaced by 'u', when not following a vowel or q.
This could be disabled, or possibly replaced with something different.
I often work on language-specific configuration changes. I have a general guideline that I use for configuring character folding for a given language: my first suggestion is that everything should be folded, except for characters used by the language of the project. So, in English projects, I would fold everything. In German projects, I would not fold ß, ä, ö, or ü, but I would fold å, é, î, ø, ÿ, all the letters in "ℬªɬĹɇ" and all the others. I would of course modify the list of exceptions based on feedback from German speakers!
There also seems to be some problem with the way that ß is treated by Elasticsearch that may make it difficult to treat it correctly in the near future. See phabricator ticket T87136 for more information.
I agree with Iwesb that in general character folding is a good thing, especially for characters that are hard to type. I support maximum character folding for titles, too. Redirects can solve a lot of problems, but they can't cover everything. Many pages don't have redirects without diacritics, and finding them would be a lot of effort that could be spent doing more productive things. It is also impossible to include every potentially useful redirect.
For example, there is an Icelandic band called Sigur Rós. I found a playlist of their music online, which spells the band name Sigür Ròs. Without character folding in the "Go" feature, this would not be a match.
The side effect of this is the situation with Balle/Bälle, and Wasserfälle/Wasserfall/Wasserfalle. I noticed that the Wasserfälle problem has been solved with a redirect. That makes perfect sense, because there isn't any other way to handle it.
Regardless of my preferences, if there is consensus that some set of letters (probably ß, ä, ö, and ü) should not be folded in either the "Go" feature search or in full-text search, I would be happy to try to implement those changes and see what the effect is.
Unfortunately, changing the "Go" feature would be more work and would take longer, because it would require adding the capability to configure how the "Go" feature does character folding. We already have the ability to do that for full-text search.
Because the changes would affect a lot of users, especially inexperienced users who don't have any knowledge of searching, or the Help Desk, etc., I would suggest reaching a consensus among a larger group of users. I don't see the German Wikipedia equivalent of an RfC, but there must be something similar.
Feld "Grund" in Special:Import hat ein Problem mit kaufmännischem Und-Zeichen
Letzter Kommentar: vor 6 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo zusammen, keine Ahnung, ob es dazu schon etwas im Phabricator gibt, gefunden habe ich gerade nichts. Wenn ich einen Grund eingebe, der ein Und-Zeichen enthält, und dann auf "Datei hochladen" klicke, funktioniert der Import nicht, sondern ich lande wieder auf einer unausgefüllten Import-Seite. Gruß, --Flominator 18:16, 23. Sep. 2017 (CEST)Beantworten
Quelltextbearbeitung teilweise in englischer Sprache
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Bei der Quelltextbearbeitung steht unten teilweise (d.h. nicht immer) statt "Vorschau" "Preview" und statt "Änderungen" "Changes". Stört zwar nicht sehr, sollte aber bei Gelegenheit doch korrigiert werden. Mein Browser: Google Chrome, Version 62.0.3202.94 --Rita2008 (Diskussion) 11:53, 19. Nov. 2017 (CET)Beantworten
Nein. Alles andere, auch links das "Änderungen veröffentlichen" erscheint ja in Deutsch und es passiert auch nicht immer. Übrigens habe ich inzwischen festgestellt, dass es nicht nur beim Google Chrome auftritt. --Rita2008 (Diskussion) 18:01, 22. Nov. 2017 (CET)Beantworten
Positionskarte zeigt im mobilen Skin falsche Positionen, wenn die Bildunterschrift zu lang ist
Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 6 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo
Ich versuche seit einiger Zeit alle Seiten der BLS Triebfahrzeuge als Buch bei PediaPress drucken zu lassen.
Aber das Rendern dieser Seiten will einfach nicht gelingen. Ich bekomme immer die Meldung es bestehe ein Fehler mit
diesen Seiten. Andere Bücher funktionieren richtig, wie es sein soll. Was kann das sein, und wie kann man dieses Problem Lösen? Ist vielleicht eine Artikel-Seite defekt?
Ich hoffe auf eine anwendbare Lösung.
Mit freundlichen Grüssen, Herbert Häuselmann / Traktor-Katze (nicht signierter Beitrag vonTraktor-Katze (Diskussion | Beiträge) 16:09, 8. Jan. 2018 (CET))Beantworten
Ja genau, diese 2 Links gehen nicht. Und ausserdem geht es mit anderen Büchern, somit ist klar, PediaPress druckt diese Bücher auch noch!
Ich stehe sogar in kontakt mit PediaPress und habe den Link per E-Mail zu ihnen geschickt. Mal sehen was da raus kommt. (nicht signierter Beitrag vonTraktor-Katze (Diskussion | Beiträge) 18:23, 11. Jan. 2018 (CET))Beantworten
sum_cat_disc.py hat ein Login-Problem
Letzter Kommentar: vor 6 Jahren3 Kommentare1 Person ist an der Diskussion beteiligt
OperationalError: (1044, "Access denied for user 's51312'@'%' to database 's51312__u_s51312'")
DocTrigon scheint relativ inaktiv zu sein. Eine der Ideen hinter toollabs war es m.E., dass andere Benutzer als der Hauptentwickler Tools warten könnten. Geht das in diesem Fall? Wer kann das? Wo muss ich das einpipen? Danke und Gruß, --Flominator19:30, 11. Jan. 2018 (CET)Beantworten
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Im Skin Timeless werden die Streckenbänder bei Bahnstreckenartikeln nach WP:FVBS unterbrochen dargestellt. Das liegt daran, dass dort Inline-Bilder nicht vertical-align: middle; erhalten. Was ist der richtig Ort, das zu beheben? Die Ergänzung von .bs-icon a img{vertical-align: middle;} in MediaWiki:Timeless.css? --nenntmichruhigip (Diskussion) 10:01, 18. Jan. 2018 (CET)Beantworten
Muss ja nicht nur .bs-icon betreffen, sondern andere Themen genauso.
Wir könnten bis zur Lösung von T183827 eine temporäre CSS-Regel durch Admin bereitstellen, falls jemand den richtigen kollateralschadenfreien Selektor für img ausguckt.
phab:T175890 (wovon das oben genannte ein duplicate war) wurde jetzt vor zwei Jahren als resolved geschlossen und die dort genannte Änderung hat es auch etwas abgemildert, aber das Problem besteht weiterhin (auch in Minerva, wo außerdem teilweise gar keine Symbole angezeigt werden). --nenntmichruhigip (Diskussion) 21:45, 22. Jun. 2020 (CEST)Beantworten
Wo in MediaWiki talk:Common.css gerade Minerva erwähnt wurde hänge ich hier mal einen weiteren Darstellungsfehler in der FVBS mit der selben Frage („Wo beheben?“) dran: Mit dem Skin Minerva sind die div.bs-icon 0.6 px zu hoch. Mit kleineren Werten für font-size lässt sich das behoben, aber ohne Anpassung ist es genauso wie in Vector 100%; scheint also noch einen anderen Lösungsweg zu geben. --nenntmichruhigip (Diskussion) 11:03, 19. Jan. 2018 (CET)Beantworten
Zeilenumbruch nach «schweizbezogen» vor einer Vorlage für Mouse-over notwendig
Letzter Kommentar: vor 6 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
Kopie von Wikipedia Diskussion:Schweizbezogen#Zeilenumbruch nach «schweizbezogen» Hallo, nach dem Hinweis «schweizbezogen» muss wohl ein Zeilenumbruch vor einer Vorlage erfolgen; sonst wird in der Mouse-over-Vorschau mit meinem Helferlein (vmtl. nicht dieses) nicht der Artikelanfang, sondern nur der Quellcode }} (= Ende der Vorlage?) angezeigt. Habe mit dieser einschlägigen Änderung eine funktionierende Vorschau auf die erste der hier aufgeführten Personen erreicht. Ob das auf weitere Vorlagen oder auf Vorlagen insgesamt zutrifft, kann ich nicht sagen. Falls das so ist, wäre umseitig ggf. ein Hinweis auf eine notwendige Zeilenschaltung angebracht. Gruß, --Wi-luc-ky (Diskussion) 18:09, 23. Jan. 2018 (CET)Beantworten
Deine Entdeckung trifft unabhängig der Infobox zu, jedoch seltsamerweise nicht bei allen Artikeln:
Wenn die sogenannten „Hovercards“, dann kann die TWS maximal einen Phab-Bericht schreiben und in den richtigen Briefschlitz stecken.
In jedem Fall braucht ihr eine tabellarische Analyse, in genau welchen Situationen immer genau was passiert und in genau welchen was nicht; und dazu möglichst zwischendurch nicht mehr umgestrickte Seiten, an denen einige Zeit später ein Entwickler das auch mit der aktuellen Seitenversion nachvollziehen kann.
Grundsäzlich sollte ob Quelltextverständlichkeit der Kommentar auf einer eigenen, allerersten Zeile stehen.
Danke, Perfektes Chaos, es ist wohl die Hover-Card-Funktion. [Korrektur: das Navigation-Popups-Helferlein. --Wi-luc-ky.] (Vllt. kannst Du mal in meinem „Uhrwerk“ nachsehen. Kann bitte auch Leyo schreiben, mit welchem Tool er diese Fehler reproduzieren konnte.)
Vorläufige Zusammenfassung: Es gibt neben der „Normalvorschau“ drei Arten fehlerhaften Vorschauen, seltsamerweise bei anscheinend immer gleichem oder vergleichbarem Quellcode-Anfang:
Letzter Kommentar: vor 6 Jahren14 Kommentare6 Personen sind an der Diskussion beteiligt
Moinsen! Wenn man sich in der mobilen WP einen Versionsunterschied ansieht, kann man ganz einfach ablesen, wie viele Edits der Editor hat und welchen Benutzergruppen er angehört und somit auch ob er erfahren ist. Könnte man das nicht auch für die Desktopversion machen? Immer erst im Benutzerverzeichnis zu gucken ist umständlich.
LG Girwidz→Hinterlasse mir hier eine Nachricht01:44, 11. Feb. 2018 (CET)Beantworten
Das scheint mir ein relativ neues Feature. Lustig ist, dass es auch als "Desktop-Version" benutzt werden kann.[7] Man müsste eine entspr. Anfrage auf Phab. stellen. -- User: Perhelion12:50, 11. Feb. 2018 (CET)Beantworten
Wenn du unter deinen Einstellungen das Helferlein Navigation-Popups (unter Navigation) aktivierst und mit dem Mauszeiger über den Benutzerlink fährst, wird eine Vorschau zur Benutzerseite eingeblendet und ganz unten im Pop-Up-Fenster werden die Infos zum Benutzer angezeigt. Vielleicht wäre das eine Möglichkeit? --Diwas (Diskussion) 21:30, 11. Feb. 2018 (CET)Beantworten
@Phab:T187011 @Popups ist nichts von WM, es ist ein verhältnismäßig riesiges User-Gadget mit insgesamt 1/4 MB. Ich persönlich empfinde es als nervend (jeglicher unnötige Mouseover und dann schließt es nicht). -- User: Perhelion23:57, 11. Feb. 2018 (CET)Beantworten
ich weiss, ich habe das auch aktiviert, aber es muss sich ja jeder einstellen um es zu sehen. Es geht, wie oben gennant, darum, dass man die Info (ähnlich wie in der Mobilen Version) auch in der Desktopversion sehen kann (also bei der Versionsgeschichte)...
Der Status der Phab-Anfrage ist immernoch ungesichtet (Needs Triage, nur der Volunteer TheDJ hat das Project Community-Tech entfernt). Es kann sich nur um Jahre handeln (leider kein Scherz). -- User: Perhelion13:30, 19. Feb. 2018 (CET)Beantworten
Einleitung wp:vm
Letzter Kommentar: vor 6 Jahren7 Kommentare6 Personen sind an der Diskussion beteiligt
Er fordert auch ein Layout ein, bei dem entweder zwei Kästen rechts von unserer Mobil-Software als breite Infoboxen eingestuft und über den Artikel gestellt werden, oder aber der gesamte Kasten links in voller Höhe die Breite der Kästen rechts anzeigt.
Modernes Seitenlayout machen wir aber anders:
Es kommt zu allererst ein Einleitungsabschnitt wie bei einem enzyklopädischen Artikel.
Das erklärt dann in der Mobil-Ansicht zuerst, worum es in der Seite geht.
Auch in den Vorschau-Popups erscheint zunächst die Zweckbeschreibung der Seite.
Die Kästen ordnen wir erst später an, ggf. vor oder nach der ersten Abschnittsüberschrift.
Die späteren Intro-Absätze können dann auch die volle Fensterbreite nutzen.
Heißt: Kasten drumrum grundsätzlich weg, hat null Informationswert.
Ggf. Abgrenzung zum inhaltlichen Teil ab TOC durch ein anderes optisches Gestaltungsmittel sicherstellen.
Du hast genug Know-How und Nervenstärke, um dies auf BETA zu erproben und dann den Admins vorzuschlagen; ggf. eher auf WP:A/N.
Der Weg von Ló ist nur Notlösung und leider nur Krücke für die Symptome, beseitgt jedoch nicht die beschriebene Ursache.
Zu große Klick-Area für die Editorwechsel-Icons des Bearbeitungsfensters
Letzter Kommentar: vor 6 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
In meiner Konfiguration (Monobook unter Linux) kann man den ganz oben platzierten Rollbalken des Bearbeitungsfenster nie mit der Maus erhaschen, weil der darüber befindliche Doppelicon-Umschalter zwischen visueller und Quelltextbearbeitung den Ḱlick abfängt. Seine Klick-Area ragt anscheinend bis etwa einen Zentimeter unterhalb des als hellgrauer Balken eingefärbten Kopfmenüs herab, sollte aber wohl „in fremden Gefilden“ grundsätzlich nichts verdecken. --SilvicolaDisk01:25, 8. Mai 2018 (CEST)Beantworten
Ich habe den Fehler als phab:T194120 gemeldet, bin mir aber nicht sicher, wie sehr sich die Programmierer für den Monobook-Skin interessieren. Mit Vector oder anderen Skins, die ich probiert habe, tritt das Problem nämlich nicht auf. –Schnark09:23, 8. Mai 2018 (CEST)Beantworten
Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hilf bitte mit, in deine Sprache zu übersetzen
You may have heard that the Foundation’s Collaboration Team has been working on a project to improve maps. We’re planning to release the mapframe feature, which embeds maps in wiki pages, to most Wikipedias. I’m writing this note to clarify that nine Wikipedias are not scheduled to get mapframe as part of the release, including this Wikipedia. The reason is Flagged Revisions.
The nine Wikipedias that are not getting mapframe at this time are wikis that use the strict version of Flagged Revisions. At these wikis the latest changes to a page are not shown by default until they can be approved. This protocol causes problems with mapframe. When an approved version of a mapframe map exists on the page and someone edits the map, the approved page displays a blank frame where the map should be.
We’ve looked into the issue (T151665) and may have a solution (T192695). It’s not simple. At this time we can’t promise that we’ll be able to fix the incompatibility of Flagged Revisions and mapframe as part of our current maps project. The current maps project has specific goals and a limited time-frame. We will keep an eye on the task, though, and if we can find time, it’s something we’d like to take care of. If you have thoughts or ideas about this, please leave them on the project talk page or in the tasks I’ve linked to.
Miniatur Vorschau der Wiki Artikel auf eigener Website (Wordpress)
Letzter Kommentar: vor 6 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo liebe Wiki Mitglieder,
bin ein Anfänger, was das aufsetzen von Websites angeht.
Habe eine kleine Website angefertigt, über Wordpress wo ich diverse Links von Websites einfüge.
Nun würde ich gerne einige auserwählte Wiki Websites verlinken, mit der Besonderheit,
dass ich gerne eine Miniatur Vorschau angezeigt bekommen würde, wenn man über den Hyperlink fährt, so wie sie in einigen Wiki Seiten angezeigt wird.
Wie kriege ich das hin? Würde mich über jegliche Lösungsansätze sehr freuen.
Beste Grüße und einen schönen Tag wünsche ich euch.
--DerPförtner (Diskussion) 19:53, 26. Mai 2018 (CEST)(nicht signierter Beitrag von2001:4dd5:a9b9:1:5571:c0ae:c087:ff3e (Diskussion) 10:15, 26. Mai 2018 (CEST))Beantworten
Hi DerPförtner, ich vermute mal, dass es dir nicht unbedingt um eine Live-Vorschau geht. Wie wäre es denn mit Screenshots zB der Artikel-Einleitung oder soweit vorhanden der Infobox eines Artikels, die vlt dauerhaft auf deiner Seite eingeblendet sind (und diese somit vermutlich sogar noch interessanter aussehen lassen) und in denen der Hyperlink zum entsprechenden WP-Artikel integriert ist--Ciao • Bestoernesto • ✉02:28, 27. Mai 2018 (CEST)Beantworten
Hallo bestoernesto, genau diese Option würde ich Erwägung ziehen, wie würde ich es dann umsetzen? Geht das komplett über HTML? Dort habe ich bereits einige Erfahrungen gesammelt, bei JavaScript noch gar keine. Freue mich auch über Anhaltspunkte, welche ich nutzen kann um mein Wissen zu erweitern, sodass ich meine Idee umsetzen kann. Gruß --DerPförtner (Diskussion) 02:35, 27. Mai 2018 (CEST)Beantworten
Komplett mit HTML und ohne JavaScript geht es nicht. Bei nicht-Live geht Folgendes (Keine Funktionsgarantie!):
Edits mit Tablet / Ipad wieder erschwert. 9.9.2018
Letzter Kommentar: vor 3 Jahren13 Kommentare4 Personen sind an der Diskussion beteiligt
DENN seid neuestem HABE ICH IMMER großbuchstaben, auch wenn ich die dauerhafte GROSSSCHREIBUNG PER FESTSTELLTASTE NICHT EINGESCHALTET HABE? . das ist nur beim SCHREIBEN VON ARTIKELn IN WIKIPEDIA? ERBITTE hilfe. --Orik (Diskussion) 13:32, 30. Jul. 2018 (CEST)Beantworten
SORRY! DASS ICH MICH SO SPÄT MELDE, @Malyacko: ICH BIN IN ferien mit nicht so gutem Iternetanschluß. ich benutze den SAFARIBROWSER AUF EINEM IPAD MIT DEM (Betriebssystem für mobile GERÄTE) IoS 10.33. DIE VERSION von SAFARI IST NICHT ERSICHTLICH UND WIRD jeweils MIT DEM BETRIEBSSYSTEM ERneuert. DEr FEHLER MIT DER Klein- und GRossschreibung tritt nur beim editieren in Wikipedia auf. gruß --Orik (Diskussion) 00:48, 5. Aug. 2018 (CEST) PS: Den Editor kann ich nicht benennen.Beantworten
Seit heute funktioniert die Groß- und Kleinschreibung mit dem Tablet wieder. Ebenso funtioniert das Löschen längerer Texte wieder, weil die Rückschrittaste nach einem bestimmten Anlauf wieder ganze Worte löscht.Orik (Diskussion) 01:50, 5. Sep. 2018 (CEST)Beantworten
Leider ist die Zeit des Funktionierens wieder vorbei.Die Regelung für Groß- und Kleinschreibung meines Tablets ist durch Wikipedia im Quelltextmodus ausgeschaltet, ebenso das schnelle Löschen mit der Rückschritttaste. Hilfe erbeten. Orik (Diskussion) 22:18, 9. Sep. 2018 (CEST)Beantworten
Heute geht die Groß- und Kleinschreibung auf zwei Tablets wieder. Hat das was mit den Änderungen von Wikipedia zu tun, die Montag morgen bekannt gemacht werden? --Orik (Diskussion) 12:05, 10. Sep. 2018 (CEST)Beantworten
SEIT DONNERSTAG FUNkTIONIEREN MEINE EDITS MIT MEINEM TABLET NICHT MEHR. ICH kann praktisch NUR NoCH GROSS SCHREIBEN? KANN das nicht mal aufhören? Orik (Diskussion) 09:08, 5. Nov. 2018 (CET)Beantworten
Hast du es mal mit einem anderen Tablet, einem anderen Browser und/oder unangemeldet versucht? Ich bin mir ziemlich sicher, dass das Problem auf deiner Seite liegt. --Magnus(Diskussion)09:12, 5. Nov. 2018 (CET)Beantworten
danke der Nachfrage. Das Problem hat sich erledigt. Ich weiß nicht mehr, was der Grund für die Fehlfunktion war. Ich hatte das übrigens mit mehreren Tablets versucht. Gruß --Orik (Diskussion) 23:11, 6. Sep. 2020 (CEST)Beantworten
Wäre es einfach möglich, noch nie gesichtete Artikel von der Suchmaschinen-Indexierung auszuschliessen?
Letzter Kommentar: vor 6 Jahren12 Kommentare5 Personen sind an der Diskussion beteiligt
Ich habe auf WP:FzW diese Frage gestellt: WP:FzW#Warum werden ungesichtete Artikel von Suchmaschinen indiziert?. Dazu gab es bisher keine Verweise auf Projektdiskussionen, etc. Bevor ich jetzt eine solche anstoße, um hoffentlich einen Konsens für den Ausschluss von noch nie gesichteten Artikeln zu finden, meine Frage an Euch: Wäre das einfach technisch umzusetzen?
Die dort verwendete Programmierung schließt offenkundig alle Artikel jünger als (90) Tage von der Indexierung aus, völlig egal ob diese „patrouilliert“ sind oder nicht.
Das würde heißen, dass auch bei uns ein Artikel zu einem aktuellen Ereignis, der noch nicht ein Alter von x Tagen erreicht hätte, von Suchmaschinen nicht erwähnt werden soll. Dabei ist es völlig egal, ob er gesichtet wäre oder nicht.
Das wird wohl kaum auf breite Zustimmung stoßen.
Um die Frage im Sinne der Überschrift zu beantworten: Technisch möglich schon, auch diese Bedingung in der Programmierung einzubauen; aber da es nur sehr wenige Wikis beträfe, die Programmierung deutlich verkomplizieren und schwerer zu pflegen macht und der allgemeine Trend eher zu Vereinfachung und Entschnörkelung geht, werden die Entwickler kaum mitspielen.
Eine lokale Alternative wäre es, dass du einen Bot-Betreiber überredest, ein NOINDEX (ggf. in auffindbarer Vorlage, mit Kategorisierung als „Neuer Artikel“) in die noch nie gesichteten Artikel einzubauen, und der erste Sichter oder ein späterer Bot-Lauf diese Vorlage dann wieder herauseditiert, wobei Entfernung durch den anlegenden Nicht-Sichter zwecklos wäre, weil der Bot immer wieder kommt.
Danke für die schnelle Antwort! Ein kurzer Einwand: In der enWP werden patroullierte Seiten durchaus schon früher freigegeben („Articles younger than 90 days are not indexed, unless they have been patrolled and do not have the {{NOINDEX}} template on them (or a template that transcludes the {{NOINDEX}} template, such as the speedy deletion templates).“ Fettung von mir), siehe auch en:WP:NPP: „Only New Page Reviewers can mark pages as 'Reviewed' or 'Patrolled' which releases them for indexing by search engines.“ Das mit dem Bot ist aber eine gute Idee! --Count² (Diskussion) 17:26, 8. Aug. 2018 (CEST)Beantworten
Bei einem Bot gibt es eine Race-Condition zwischen dem Crawler der Suchmaschine und unserem Bot. Wer schneller ist, gewinnt. Das wäre dann so eine halbe Sache, die nicht gar so toll funktioniert. --Wurgl (Diskussion) 17:35, 8. Aug. 2018 (CEST)Beantworten
Stimmt auch wieder inbesondere da neue Artikel extrem schnell von Google indexiert werden. Da das aber in der enWP so ähnlich funktioniert (nur mit "patrolled" anstelle von "flagged revisions") wäre das ja vielleicht doch gar nicht so schwer zu implementieren? --Count² (Diskussion) 17:38, 8. Aug. 2018 (CEST)Beantworten
In der fraglichen Server-Programmierung steht bis heute nur eine Abhängigkeit vom Alter der Seite, egal was sonst noch für ein Status vorläge. Mechanismen, die das übersteuern würden, etwa durch temporären Einbau eines INDEX, sind bei der enWP nirgendwo konkretisiert worden. Es sind erstmal einfach nur Behauptungen auf der Projektseite.
Wer das race gewinnen würde, unser lauschender Bot oder ein lauschender Crawler, ist offen. Wenn beide das Ohr am selben Kanal haben, klar. Aber wenn wir einführen würden, dass für 24 oder 48 Stunden nach Anlage im ANR das serverseitige NOINDEX automatisch greifen würde, dann wäre Zeit genug für SLA und erste QS, und auch ein Bot könnte ganz in Ruhe eine entsprechende Vorlage einbauen, falls nicht von Sichter angelegt, und könnte damit auch noch ein sichtbares Kästchen mit einem grünen Bäumchen generieren: „Dieser Artikel ist noch ganz jung, wir kennen den selbst noch nicht richtig.“
Auch nur ein kurzer Hinweis: Google crawlt (fast) keine Seiten in Wikipedia, sondern verwendet verschiedene andere Quellen wie die Letzten Änderungen, ORES, Wikidata, RESTBase (Parsoid), Action-API, etc. –Schnark11:58, 9. Aug. 2018 (CEST)Beantworten
Neue, noch nie gesichtete Artikel, findet Google jedenfalls schnell und indexiert sie auch umgehend. Soweit mir bekannt, beachtet Google aber meta noindex und könnte damit von einer Indexierung abgehalten werden. --Count² (Diskussion) 18:18, 9. Aug. 2018 (CEST)Beantworten
Koordinaten verdecken erste Zeile in Infoboxen
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
In der Benutzeroberfläche Modern verdecken die Koordinaten die erste Zeile der Infobox bei Artikeln, die sowohl Koordinaten als auch Infoboxen haben, z.B. Flughafen Berlin-Tegel. XGA-Auflösung, Windows 7 Professional, Opera und Firefox. Dies ist als Fehlermeldung gedacht, falls dies der falsche Ort dafür ist, bitte um eine entsprechende Meldung. Der Fehler ist mir nur in der deutschen Wikipedia aufgefallen, die englische, französische und schwedische Wikipediaversionen sind nicht betroffen. --K1812 (Diskussion) 16:40, 20. Sep. 2018 (CEST)Beantworten
Letzter Kommentar: vor 5 Jahren20 Kommentare4 Personen sind an der Diskussion beteiligt
Ich bekomme seit ein paar Tagen beim Editfenster in Safari keine Werkzeugleiste mehr und dazu folgende Fehlermeldung:
Vorlagenmeister 0.593 * BETA * 2018-08-25:
init()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')
Ein Abspeichern eines Edits ist auch nicht möglich und wird mit derselben Fehlermeldung quittiert. Bei Firefox tritt das Problem nicht auf. Dennoch nutze ich auch gern Safari für meine Wikiarbeit. --Fährtenleser (Diskussion) 08:35, 23. Sep. 2018 (CEST)Beantworten
Hallo Fährtenleser, getAttribute ist "relativ" spät (in Jahren gerechnet) von allen großen Browsern unterstützt (obwohl es dieses schon ziemlich lange gibt). Daher würde ich eher jQuery oder eine andere Möglichkeit im Code des Vorlagenmeisters benutzen. Es kann natürlich auch an etwas ganz anderem liegen, allerdings lässt die Benutzung schon auf modernen Code schließen. Welche Version des Safari hast du denn? -- User: Perhelion09:04, 23. Sep. 2018 (CEST)Beantworten
Der Aufruf getAttribute steht bereits seit 2009 im Vorlagenmeister-Code; so simpel und neu ist dieser DOM-Zugriff aus dem letzten Jahrhundert ohnehin nicht.
Ich weiß von keinen Änderungen mit dieser Auswirkung, nicht 2018-08-25 und nicht zuvor (2016).
Möglicherweise gab es mit Safari oder MediaWiki in den letzten Tagen eine Veränderung?
Gab es in den gut zwei Wochen zwischen dem 3. September und vergangenem Donnerstag erfolgreiche Bearbeitungen mit Vorlagenmeister unter Safari?
Ich habe ein Debugging-Problem, da ich keinerlei Safari so in Reichweite hätte, dass ich darunter sinnvoll Software-Entwicklung betreiben könnte.
Du würdest dich vermutlich mit einer geänderten Einbindungs-URL (unter WP:BETA) statt Einstellungs-Häkchen anfreunden müssten; dort kann ich Einkreisungs-Testversionen zum genaueren Eingrenzen der Ursache einbauen.
Danke euch Beiden für die schnelle Reaktion! Ich habe jetzt mal den Haken bei meiner Einstellung "VisualEditor während der Beta-Phase deaktivieren" rausgenommen ... und siehe da, ich kann wieder mit Safari arbeiten :-) Falls das Problem dennoch erneut auftritt, melde ich mich wieder hier. VG --Fährtenleser (Diskussion) 10:04, 23. Sep. 2018 (CEST)Beantworten
Guten Morgen, da bin ich leider schon wieder. Es hat offenbar doch nicht an der Einstellung gelegen, denn das Problem ist heute morgen wieder unverändert vorhanden. Schlimmer noch: Jetzt kann ich auch die "Glocke" nicht mehr aufrufen. (Zugegebenermaßen ist es ein älterer Safaribrowser, nämlich 5.1.10 Mac. Neuere laufen auf meinem Rechner leider nicht) --Fährtenleser (Diskussion) 07:36, 24. Sep. 2018 (CEST)Beantworten
Dann lag ich mit meiner Vermutung nicht so verkehrt, denn (wie oben verlinkt) wird getAttribute erst von Safari 6 unterstützt. Ein kleines Update sollte also jetzt angebracht sein!? VG -- User: Perhelion13:27, 24. Sep. 2018 (CEST)Beantworten
Wir brauchen zu jeder deiner Beschwerden auch die Fehlermeldung aus der Konsole.
Zum Problem „Glocke“ fehlt diese; und daran hat der Vorlagenmeister keine Schuld.
Zurzeit zieht jemand durch die MediaWiki-Software und modernisiert bestehende JavaScript-Aufrufe dahingehend, dass auf modernere JavaScript-Eigenschaften zugegriffen wird, die jedoch in älteren Installationen noch nicht verfügbar sind. Dabei vermurksen die schon mal was, wie bereits geschehen.
Safaribrowser 5.1 liegt ausweislich mw:Compatibility #Browsers voll im aktuell zu unterstützenden Bereich.
Um die Vorlagenmeister-Problematik einzukreisen, nimm bitte das Häkchen aus den Einstellungen raus und füge den nachstehenden Code in deine Benutzer:Fährtenleser/common.js ein:
Es gibt dann konkreter eingrenzende Fehlermeldungen.
@Perhelion: getAttribute in dem von Vorlagenmeister verwendeten Kontext ist Teil des DOM von 1997 und ich erinnere mich dunkel, bereits im letzten Jahrhundert damit gearbeitet zu haben. Vorlagenmeister verwendet es seit 2009, und da das ja die ganze Zeit schon mit dem bisherigen Safari funktioniert hatte, kann das mit Safari 5 und 6 nicht stimmen; viele andere haben fast ein Jahrzehnt mit allen möglichen Safari-Versionen und Vorlagenmeister gearbeitet.
Okay, danke für die Mühe! Alldieweil hat sich nach dem Rausnehmen des Häkchens, Einsetzten des Codes und Cache-Löschen in Safari leider nichts an der Fehlermeldung geändert. Sie sieht jetzt wie folgt aus:
Vorlagenmeister 0.593009901 * BETA* 2018-09-24:
init() equipGUI()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')
Allerdings kann ich Edits wieder absenden, wenngleich die Werkzeugleiste fehlt. In der Konsole finde ich keine Meldung von Safari. Hilft das? Habe ich alles richtig gemacht? (Ich kenne mich da nicht sonderlich gut aus in der Technik) --Fährtenleser (Diskussion) 19:34, 24. Sep. 2018 (CEST)Beantworten
leider nichts an der Fehlermeldung geändert – Oooh doch. Sie sieht für mich deutlich anders aus; trägt nämlich wichtige Informationen über den Ablauf, wenn du es mal mit oben vergleichst.
Ich hatte die in Frage kommende Region gedrittelt, und es ist ein bestimmtes Drittel angesprungen.
Innerhalb dieses Drittels habe ich nun auf potentielle Aktivitäten erneut gedrittelt, kann das jetzt teilweise auf einzelne Anweisungen eingrenzen, die dann verraten, wo der Fehler läge.
Wenn du jetzt einfach wieder den Vorlagenmeister betätigst, dann müsste eine andere Meldung mit 593009902 passieren.
Die trägt wieder eine Einkreisungs-Info in sich, und dann schaun wir mal weiter.
Schön! Da ich nicht genau weiß, was du mit „Vorlagenmeister betätigen“ meinst, habe ich einmal mit und einmal ohne entsprechendes Häkchen in den Einstellungen ein Edit unter Safari versucht. In beiden Fällen kam folgende identische Fehlermeldung heraus:
Vorlagenmeister 0.593009902 * BETA * 2018-09-24:
tm_init().buttonWikiEditor()
'undefined' ist not a function (evaluating
'elem.getAttribute("type")')
@Fährtenleser:
Sodele, und es stand die Einkreisungs-Info mit bei, die ich benötigte, um die Chose auf eine einzige verdächtige Anweisung einzukreisen.
Nun bau doch mal nachstehende Anweisung zusätzlich vor dem Vorlagenmeister in deine common.js ein:
Wenn du dann irgendwas zur Quelltextbearbeitung öffnest, dann müsste das auf der Fehlerkonsole aufschlagen. Damit wäre der Nachweis erbracht, mit dem ich dann höheren Ortes antanzen kann.
Mit anderen als Safari sollte hingegen ein Button mit Safari-Logo als blauer Kreis und Kompassnadel in der Werkzeugleiste 2010 erscheinen, der sich anklicken lässt.
@PerfektesChaos:
Wow, ich fühle mich wie eine Marionette :-) Danke jedenfalls! Das Ergebnis ist diesmal allerdings wohl nicht befriedigend: In Firefox sehe ich jetzt tatsächlich das Safari-Logo in den Tools, aber der Aufruf des Fehlers in Safari führt (bei identischer Fehlermeldung zu gestern) zu keinem Eintrag in der Konsole – zumindest finde ich keinen Eintrag, in dem Safari vorkommt. Was mache ich falsch? Darüber hinaus werden meine Probleme mit Safari gefühlt von Tag zu Tag größer: Die Glocke klappt (wie schon erwähnt) gar nicht, der Klick auf "Benachrichtigungen" führt zu einer Seite mit endlos laufender Schraffur (wohl eine Art Ladebalken), die Reiter der Einstellungen lassen sich nicht mehr öffnen und bei der Suchworteingabe werde ich jetzt immer zuerst zu der Seite mit den weiteren Suchergebnissen geleitet und nicht mehr direkt zum Artikel. Uff! --Fährtenleser (Diskussion) 06:49, 26. Sep. 2018 (CEST)Beantworten
Morgen, Marionette, dann zieh ich mal wieder am Fädchen: Nimm mal den Vorlagenmeister-Aufruf komplett raus. Der reißt vermutlich die neue Diagnostik-Meldung vorher mit in den Abgrund. Die hätte ich aber gern als definitive Bestätigung, dass es nur an genau dieser Anweisung liegt. Bis dann --PerfektesChaos10:15, 26. Sep. 2018 (CEST)Beantworten
Hallo Fädenzieher, habe ich gemacht. Jetzt kommt keine Fehlermeldung mehr und ich kann Edits abspeichern; allerdings habe ich keine Werkzeugleiste. In meiner Konsole findet ich auch jetzt keinen Eintrag mit "Safari". Allein das zur entsprechenden Uhrzeit:
26.09.18 13:33:34 SIMBL Agent[203] warning: failed to get scripting definition from /Applications/Utilities/Console.app; it may not be scriptable.
Ich vermute, das hilft dir/uns nicht weiter. Übrigens: Edits mit Firefox zeigen zur Zeit ein seltsames Verhalten: Die Eingaben sind viel langsamer als meine Finger auf der Tastatur und kommen entsprechend verzögert. Safari mach dahingehend keine Zicken. Ich muss das nicht verstehen, oder? --Fährtenleser (Diskussion) 13:47, 26. Sep. 2018 (CEST)Beantworten
Hallo „großer Kopp“ :-) Das Häkchen für die erweiterte Werkzeugleiste habe ich entfernt.
ACHTUNG: Jetzt könnte es wirr werden: Ich habe dann das Script eingebaut, in dem unten ( "afari" ) steht. In Firefox habe ich ja eine Werkzeugleiste, nur nicht mehr in Sarafi – da du oben von Firefox sprachst. Die Leiste in Firefox änderte sich daraufhin in eine viel umfangreichere – die ich jedoch nicht benötige. In Safari blieb alles beim alten. Auch nachdem ich den String zu ( "Safari" ) geändert habe. Ich habe das Script also wieder entfernt, um in Firefox wieder die alte Leiste zu haben (die reicht, wenn man nur im Quelltext arbeitet und für viele Formatierungen bereits eigene Makros hat) --Fährtenleser (Diskussion) 14:48, 27. Sep. 2018 (CEST)Beantworten
@Fährtenleser:: beim Durchlesen dieses Threads bin ich gerade über folgende Deiner Bemerkungen gestolpert (eher gefallen): (Zugegebenermaßen ist es ein älterer Safaribrowser, nämlich 5.1.10 Mac. Neuere laufen auf meinem Rechner leider nicht). Meine 50¢ dazu: mit einem Mac auf dem nur Safari 5.1 und das entsprechende Betriebssystem läuft – offenbar Snow Leopard – sollte grundsätzlich vermieden werden im Jahr 2018 noch eine Internetverbindung aufzubauen. Im geschäftlichen Bereich (Datenverarbeitung, Netzwerk et al.) darf der auf alle Fälle nicht mehr in Betrieb genommen werden. mit gruessen von VINCENZO149212:40, 16. Nov. 2018 (CET)Beantworten
Das kommt schon falsch in die Nachricht rein, denn {{urlencode:Coincoin et les z'inhumains|PATH}} Coincoin%20et%20les%20z%27inhumains sieht gut aus. MediaWiki:Searchmenu-new. Im MediaWiki-Code wird wfEscapeWikiText verwendet, bin aber gerade unsicher welche Ersetzung besser ist. Lua-Module? Der Umherirrende19:59, 28. Sep. 2018 (CEST)Beantworten
Schön, dich zu sehen.
Wir werden hierzuwiki wenig Sinnvolles machen können:
Wir können per Lua eine provisorische Reparatur machen und alle an MediaWiki:Searchmenu-new gelieferten Entities wieder zurückbauen, wobei es aber Absicht sein könnte, dass jemand nach einem Entity sucht, namentlich mittels insource (wobei das dann ungültig würde, und escaped werden müsste).
Da hatte wohl jemand zu viel Angst vor Apostroph-Zeichen gehabt.
Es scheint nur Apostroph und & zu betreffen; ich habe mal systematisch die üblichen Verdächtigen durchprobiert, aber kein anderes lieferte Entity.
Aufruf der Systemnachricht, wenn korrekt angesprochen:
MediaWiki ruft hier wfEscapeWikiText auf, damit eventuelle Wiki-Syntax (zwei Apostrophe für Kursiv/Fett etc.) im Suchwort nicht die Nachricht kaputtmachen. Ich habe zwar schon viele Message-Aufrufe gemacht, aber bei den Feinheiten muss ich auch nochmal ausprobieren ob man darauf verzichten kann. Der Umherirrende20:32, 30. Sep. 2018 (CEST)Beantworten
Breite Formeln und Tabellen werden im mobilen Skin abgeschnitten
Letzter Kommentar: vor 5 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Abgeschnitten wird bei mir nichts. Die breite Formel ragt über die Seite hinaus, ja, ist aber durch horizontales Scrollen komplett lesbar. -- hgzh21:16, 5. Okt. 2018 (CEST)Beantworten
You have enabled both this script and the MediaViewer.
Letzter Kommentar: vor 5 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn ich z.B. in der englischen Wikipedia ein Bild öffne, steht dieser Text darunter: "You have enabled both this script and the MediaViewer. You should decide for one script and disable the other." Ich gebe zu, dass ich mit der Lösung überfordert bin, weiß ich doch nichtmal, was mit "this script" gemeint ist. Mag und kann mir jemand helfen? Vielen Dank.
PS: Den MediaViewer (ich kann mich noch gut an viel Ablehnung erinnern) finde ich gut. --Karsten Meyer-Konstanz (D)10:55, 29. Nov. 2018 (CET)Beantworten
Klicke bitte mal ein Bild an und gehe dann auf das Zahnrad. Dort kannst du den Mendienbetrachter an- oder abschalten. Oder schau mal ob es in deinen Einstellungen aktiviert ist.
Ändert sich etwas wenn du das umschaltest?
Ist bei “this skript” ein Link dem du folgen könntest? Ich sehe diese Meldung nicht. Vermutlich müsstest du mal in der englischsprachigen Wikipedia danach fragen, ich weiß nicht was es dort so alles für Gadgets geben mag. Scheinbar ist eines dabei, was nicht gleichzeitig mit dem Medienbetrachter angeschaltet sein sollte. --Liebe Grüße, LómelindeDiskussion12:30, 29. Nov. 2018 (CET)Beantworten
Wenn ein Beitrag versteckt wird, bricht die Versionsgeschichte ab
Letzter Kommentar: vor 5 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Wird ein Beitrag (z.B. aus rechtlich relevanten Gründen) unsichtbar gemacht, so kann die Versionsgeschichte nicht mehr Änderung für Änderung durchgegangen werden. Beispiel: Versionsgeschichte Microsoft Windows 8; am 24.12.2018 um 10:18 wurde ein Beitrag geschrieben, der laut Logbuch wegen Gewaltaufruf versteckt wurde. Klickt man nun auf "gewählte Versionen vergleichen" (mit den letzten beiden) und danach mehrmals jeweils auf "zum vorherigen Versionsunterschied", so kommt man bis zum genannten Beitrag, landet aber auf einer Fehlerseite - und dann nirgendwo mehr hin (ohne "zurück im Browser"). In so einem Fall sollte mindestens auch die Fehlerseite (die ja theoretisch die Änderung zeigen sollte - die ist aber unsichtbar gemacht worden) den Link auf die vorangegangene und auf die nachfolgende Änderung zeigen, ohne aber den Inhalt zu zeigen. D.h. in so einem Fall sollte nur kein eigentlicher Inhalt angezeigt werden (resp. als "Änderungstext" jeweils eine leere Seite) - die Metadaten hingegen sollten mitgeschleppt und nicht auch unsichtbar gemacht werden. --ProloSozz (Diskussion) 18:24, 24. Dez. 2018 (CET)Beantworten
Wenn Du jetzt nochmals auf "Zum nächsten Versionsunterschied" anklickst, dann erscheint nur noch eine Fehlerseite - ohne wieder zum vorhergehenden oder nächsten Fehler kommen zu können. Da steht dann nur noch folgender Text: Fehler: Eine Version dieser Unterschiedsanzeige (183991817) wurde nicht gefunden. Dieser Fehler wird normalerweise von einem veralteten Link zur Versionsgeschichte einer Seite verursacht, die zwischenzeitlich gelöscht wurde. Einzelheiten sind im Lösch-Logbuch vorhanden. Lösch-Logbuch ist verlinkt - das ist aber auch alles. Mehr steht da nicht mehr - insbesondere kommt man weder zur vorhergehenden, noch zur nächsten Versionsänderung. Genau gleich sieht's von nachfolgenden Versionen aus, wenn man zurück geht. --ProloSozz (Diskussion) 02:09, 25. Dez. 2018 (CET)Beantworten
Jetzt bin ich nicht sicher, ob ich das richtig verstanden habe. Nochmal: geht man von den beiden Beispielen (diff=next und diff=prev) nochmals eins weiter resp. zurück (jeweils hin zur durchgestrichenen Version), dann kommt der Fehler. Ich sag's mal so: daß der gelöschte Text nicht anzuzeigen ist, ist klar und nicht zu beanstanden - dennoch sollten aber die Metadaten angezeigt werden (es besteht ja kein Grund, diese nicht zeigen zu dürfen; nur der Text darf nicht gezeigt werden). Da aber mit der Unsichtbarmachung offenbar auch darauf kein Zugriff mehr besteht, erscheint dann eben der Fehler. Oder anders formuliert: es sollte "normal durchgeklickt" werden können - bei der unsichtbaren Version sollte aber nur kein Text erscheinen (einfach auf der gelöschten Hälfte alles leer), die Metadaten dazu aber schon. --ProloSozz (Diskussion) 14:38, 28. Dez. 2018 (CET)Beantworten
Ich habe in meiner Antwort nur das fragwürdige Verhalten genauer erläutert und eine mögliche technische Erklärung angegeben. Meiner Meinung nach gibt es technisch keinen zwingenden Grund dafür, es so zu implementieren, wie es im Moment implementiert ist, und ich sehe es ebenfalls als Nachteil, da man – wie von dir schon dargestellt – sich deshalb nicht von Diff zu Diff hangeln kann. Wenn ich Zeit habe, erstelle ich einen Bug Report/Feature Request im Phabricator. --Count Count (Diskussion) 14:54, 28. Dez. 2018 (CET)Beantworten
Buchfunktion / Sammlungen
Letzter Kommentar: vor 5 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo,
seit einiger Zeit ist die Erstellung von PDF Versionen für Sammlungen hier ausser Betrieb. Ich biete daher diese Funktion auf einem Server an:
Leider musste ich die maximale Buchgröße, wegen begrenzter Rechenkapazitäten, auf ca. 200 Seiten beschränken. Auf meinem privaten Rechner konnte ich bereits ein Buch mit 5000 Seiten erstellen.
Ich denke nun darüber nach einen Server aufzubauen, der Bücher bis zu 25000 Seiten erstellen kann. Da mich der Spass ca. 3000 EUR kosten würde, ist es für mich interessant zu wissen ob es hier Menschen gibt die ein PDF von Sammlungen haben wollen welches zwischen 5000 und 25000 Seiten lang wäre. Diese mögen sich entweder hier eintragen oder mich andersartig kontaktieren.
Danke, aber ich denke, du solltest dein Geld sinnvoller einsetzen.
Der Trick bei den Wikis ist ja, dass sie permanent aktualisiert und verbessert und erweitert werden, und seien es nur die URL von externen Verweisen.
Das ist bei einem PDF ziemlich statisch, und deshalb kommt man schon seit einem Jahrzehnt relativ weit ab von umfangreichen PDF.
Für den armen Nutzer, der sich 10.000 Seiten in einer einzigen Datei herunterladen solle, sehe ich schwarz. Ich persönlich hätte ohnehin keine Verwendung für ein PDF, vielleicht mal einen einzelnen Artikel zum Verschenken, aber ich würde mich grundsätzlich auf Zusammenstellungen zu weniger als 100 PDF-Blätter beschränken wollen, weil das weder als Datei noch zum Download noch zur kontinuierlichen Aktualisierung sonst noch zu handhaben wäre.
Der Trend geht eigentlich eher zum Online-Lesen wild ausgewählter Artikel-Anfänge auf einem Smartphone, denn ein statisches 1000-Seiten-Buch zu einem Thema.
Auf wmflabs.org für dich ohne Geldmittel mit PDF-Generierung zu experimentieren ist sicher eine bereichernde Erfahrung. Dort mag für 24 Stunden ein PDF bereitgehalten werden, und dann ist es halt futsch, dann langt auch der Platz.
Hi,
im Moment werden die PDFs nur eine Stunde gehalten. Deine Idee Inhalte länger zu speichern ist eigentlich ganz gut. Immerhin kann man mit einem Rechner für 1000 EUR in einem Jahr alle Artikel der deutschen Wikipedia in PDFs verwandeln und kann sie dann innerhalb von Sekunden zusammen tackern. Aber du hast natürlich recht: aktuell ist das dann nicht. Aber es wurde mir bereits von Zeitgenossen berichtet die sich 3000 Seiten gedruckte Wikipedia Artikel in ihren Schrank stellen und aktuell sind die dann auch nicht. Aber im Moment habe ich eh keine Zeit soetwas zu starten. Aber das kann ja noch kommen.--Dirk Hünniger (Diskussion) 18:00, 27. Dez. 2018 (CET)Beantworten
NichtAnzeige bildartiger Elemente in der HomePage
Letzter Kommentar: vor 5 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Bei mir wird in Eurer Homepage links oben Einiges nicht angezeigt. Dass da etwas ist bzw. sichtbar sein sollte, erkenne ich an dem Zeigefinger-Symbol, zu dem der MausZeiger in dieser Ecke wird.
Ich würde mir in der Hilfe als oberste Rubrik eine Überschrift wie etwa: "Einstellungen im Browser als Voraussetzungen für die vollständige Anzeige der Website" (es darf auch kürzer sein) wünschen.
Ich habe z.Z. noch keine E-Mail-Adresse und kann also nur ab und zu nachschauen, ob es in der Hilfe so etwas, inzwischen, gibt.
Des weiteren vermisse ich eine bereits in der Homepage sichtbare Möglichkeit zum Mitteilen von Hinweisen, die: keine Frage beinhalten/darstellen UND auch keine bestimmte Stelle in einem Text betreffen, also etwa: zum Layout oder zur Funktionalität und BenutzerFreundlichkeit.
Soweit es vorhandenen Text betrifft, wäre es ideal, wenn der Benutzer einfach: den MausZeiger in diese Stelle schieben könnte und dann über ein ContextMenü so etwas wie: "Mitteilung", "Kommentar" oder "Verbesserungsvorschlag" auswählen könnte, was sich dann automatisch auf diese Stelle im Text beziehen müsste.
Bei mir ist die Zeile mit den MenüElementen: "Lesen Quelltext bearbeiten Versionsgeschichte" und das SuchFeld von ober her in die Überschrift "Wikipedia Technikwerkstatt neuen Abschnitt hinzufügen" gerutscht.
Das ist aber nicht nur in dieser Seite, sondern in allen Seiten so.
Möglicherweise liegt das daran, dass Eure Website die bei mir (in meinem Windows 8.1) vom Standard abweichend eingestellten Größen von Überschriften nicht berücksichtigt.
Zu den Verrutschten Menüpunkten: Kann es sein, das du auf einem Mobilgerät ohne JavaScript-Unterstützung unterwegs bist? Normalerweise wird nähmlich Mittels JavaScript so viele von diesen Reitern im Dropdownmenü versenkt, bis das ganze eben nicht in die Überschrift rutscht, weil sonst kein Platz ist. Wenn du auf einem Mobilgerät unterwegs bist, empfehle ich dir , die Mobile Version von Wikipedia unter https://de.m.wikipedia.org zu benutzen. Diese ist extra für Bildschirme mit kleiner Breite wie auf Smartphones entwickelt worden. Victor SchmidtWas auf dem Herzen?19:57, 16. Jan. 2019 (CET)Beantworten
Edittextfeld beim Sichten zu kurz?
Letzter Kommentar: vor 5 Jahren7 Kommentare2 Personen sind an der Diskussion beteiligt
Zusammenfassung: Es gibt eine Längenbegrenuzung von 200 Zeichen für das Zusammenfassungsfeld, welches im Zusammenhang von Rücksetzungen beim Sichten angeboten wird. Wenn man aus der Versionshistorie heraus zurücksetzt, wird über den Quellcode-Editor das übliche 500 Zeichen lange Feld angeboten. Dies führt dazu, dass man beim Zurücksetzen aus dem Sichten heraus keine ergänzenden Worte zu dem vorgeschlagenen Text hinzufügen kann, da Limit durch den Vorschlag bereits überschritten. Kann die Länge des Feldes beim Sichten auf 500 Zeichen angepasst werden? Danke und VG --Bicycle Tourer (Diskussion) 21:58, 21. Jan. 2019 (CET)Beantworten
Beim Sichten eines Artikels bzw. der Rücksetzung der Änderung(en) aus dem Sichten heraus lässt das Editierfeld für die Zusammenfassung viel weniger Zeichen zu als bei "normalem Rücksetzen". Dieses Phänomen lässt sich mit folgendem Ablauf herbeiführen:
Man klicke auf "x Änderungen" im Text "x Änderungen dieser Version sind noch nicht gesichtet. Die gesichtete Version wurde am TT. MONAT JJJJ markiert.", der oberhalb des Artikels angezeigt wird (Im Beispiel führt dies auf diesen Link)
Man klicke auf den Button "Änderungen verwerfen" im neuen Kasten über dem Artikeltext (im Beispiel sollte dies nach hier führen, aber nur im Kontext der vorangegangenen Schritte, aus dieser Diskussion heraus kommt leider eine Fehlermeldung)
Es erscheint eine Spezialseite mit der Überschrift "Versionen markieren" (Link im Beispiel, der aus dieser Diskussionseite wieder zu der Fehlermeldung führt)
Dort gibt es rechts neben dem Text "Zusammenfassung" ein Editierfeld, in dem bereits ein Textvorschlag eingesetzt ist.
Für diese Feld treten folgende Phänomene auf
Man kann häufig gar nichts mehr hinzufügen, insbes. wenn eine IP V6 zur Identifikation genutzt wird (der vorgegebene Text ist dann schon recht lang).
Wenn man den Text (dramatisch) kürzt, kann man wieder Zeichen hinzufügen.
Der vorgeschlagene Text ist u.U. deutlich länger als das was eingegeben werden kann: Man muss u.U. 30 und mehr Zeichen löschen, bevor man ein Zeichen hinzufügen kann.
Wenn man stattdessen die betreffende Version des Artikels nicht über den Sichten Prozess, sondern z.B. aus der Versionsgeschichte heraus "rückgängig macht" (im Beispiel führt der Link ), führt das in das übliche Fenster "Quelltext editieren" mit einem vergleichbaren vorausgefüllten Feld "Zusammenfassung und Quellen". In diesem Feld kann man (bei gleichem Textvorschlag) noch sehr sehr viele Zeichen hinzufügen.
Ich interpretiere das (ohne den dahinterstehenden Code zu kennen) so, dass beim Sichten das Zusammenfassungs-Editierfeld eine Längenbegrenzung hat, die erheblich kleiner ist als für das vergleiche Feld auf der Seite "Quelltext editieren". Diese Längenbeschränkung scheint erst beim Editieren zu greifen, der vorgeschlagene Text kann durchaus schon länger sein als das, was man über Tastatur-Eingabe in dieses Feld hineinbringt.
Jetzt die Frage(n):
Ich habe kein Gefühl, wo man dieses Problem am besten meldet (deshalb erst mal in "Fragen zu Wikipedia".). Für jeden Hinweis dafür ein Dankeschön im Voraus, ich würde die Verschiebung des Themas übernehmen.
Ist dieses Problem bereits bekannt?
Gibt es einen anderen effizienteren "Workaround" als über die Artikelhistorie zu gehen (sehr mühsam, wenn mehrere zu sichtende Edits in einem Rutsch zurückgesetzt werden sollen)
Hinweis: Ich hatte dieses Thema schon mal aufgebracht, aber damals zurückgezogen, weil ich es für einen Bedienfehler meinerseits gehalten hatte.
Danke für die Information. Könnte man diese Längenbegrenzung heraufsetzen, um gleichartiges Verhalten zu bekommen, oder gibt es einen Grund, warum dieses unterschiedliche Verhalten gewünscht wird? Ich frage nach, weil eine Eintragung in diesem Feld auch für mich selber als Gedächtnisstütze dient, warum ich zurückgesetzt habe. Danke und VG --Bicycle Tourer (Diskussion) 20:39, 21. Jan. 2019 (CET)Beantworten
Letzter Kommentar: vor 5 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Grundsätzlich ist es sinnvoll, daß diverse per Skript hinzugefügte Sonderinformationen mitgedruckt werden, aber bei 65 Versionen seit 2007-02-26 (+168 Tage), 39 Autoren, 318 Seitenaufrufe (30 Tage), erstellt von: Skipper69 (112.099) · Alle Seitenstatistiken (ich weiß gerade nicht, welches Skript das erzeugt, aber ihr werdet das schon wissen ;-) ) ist es ziemlich nutzlos, daß Alle Seitenstatistiken mit ausgedruckt wird. Bitte ändern oder an der geeigneten Stelle Änderung herbeirufen.
Genauso nutzlos ist, daß vor dem Lemma (H1-Überschrift) die verlinkten Worte Zur Navigation springen und Zur Suche springen mitgedruckt werden. Auf Papier kann man nirgends hinspringen, und selbst beim Klicken, wenn man es auf dem Bildschirm hat, sind die Links ohne sichtbare Reaktion. Kann das lokal ein Admin machen, oder braucht es dazu einen Bugreport?
Ebenfalls nutzlos ist dann am Ende das verlinkte Wort "Entwickler". Kann man zwar in der Bildschirmansicht anklicken, aber das wird wohl keiner auf diesem Umweg tun. Hier gilt dasselbe wie eins drüber. (Den Link zur Cookie-Belehrung wird man da wohl aus rechtlichen Gründen behalten wollen, obwohl die Linkbeschriftung ausgedruckt auch nix bringt.)
Das meiste liegt in unseren lokalen Händen und lässt sich konfigurieren. Ist ggf. völlig unser eigenes Zeugs.
Falls etwas nicht in der Macht unserer Admins stehen sollte, werde ich darüber nachdenken, welche globalen Ansätze es gäbe und inwieweit diese Unterdrückungsmechanik in der Druckausgabe eine globale Software-Eigenschaft wäre, und geeignete Anregungen weiterleiten.
Muss ich mir Detail für Detail ansehen, kann etwas dauern.
Bei den meisten Punkten haben wir nur den Text der Linkbeschriftung in unserer Hand. Mit dem könnte man zwar per üblem Hack das Ziel erreichen, aber sowas mache ich nicht.
Vielmehr per phab:T214413 zur globalen Lösung weitergereicht; dann haben alle Wikis irgendwann etwas davon und es kann sauber gelöst werden.
Eine Verbesserung habe ich mir vorgemerkt, um sie im Paket mit anderen Sachen an A/A weiterzuleiten.
65 Versionen seit 2007-02-26 (+168 Tage), 39 Autoren, 318 Seitenaufrufe (30 Tage), erstellt von: Skipper69 (112.099) · Alle Seitenstatistiken
@Matthiasb: Musst du schon selbst wissen, welches Hilfsmittel du da benutzt. Ich habe sowas nicht aktiviert und kann auch keine charakteristischen Textfragmente finden.
@Mitleser: Weiß jemand, was das für ein Dings ist?
Da es nachträglich in die Seite injiziert wird, kann nur ein Maintainer von dem Teil verhindern dass es angezeigt würde. Nebenbei haben wir ziemlich viele nachträglich durch Skripte eingefügte Boxen, die über irgendwas informieren; müsste dann notfalls abgeschaltet werden, wenn man davon eine Druckversion generiert. Wobei es überhaupt seltsam ist, wie in ein PDF ein Skript-Output hineinkommen sollte.
@Matthiasb: Auf genau welche Weise generierst du überhaupt diese „Druckversion“, und in was für einem Gebilde erscheint das dann? PDF oder HTML?
Letzteres ist wohl die HTML-Version. Jedenfalls die, wenn man in der Seitenleiste auf Druckversion (rechts)klickt und beim Öffnen im neuen Tab oder Fenster sieht. In der PDF-Version werden diese zusätzlichen Angaben komplett weggelassen; das betrifft beispielsweise auch die Angabe des zugehörigen Wikidataeintrags.
„Zur Navigation springen“, „Zur Suche springen“ und „Entwickler“ werden nur in Monobook (und vielleicht noch anderen alten Skins) mitgedruckt, in Vector werden sie ausgeblendet. Das sind halt so die Probleme, die man hat, wenn man einen Uralt-Skin verwendet, für den sich niemand mehr richtig interessiert. –Schnark08:56, 23. Jan. 2019 (CET)Beantworten
Ist die Druckversion wirklich skinabhängig? Eigentlich geht es ja genau darum, nichts zu „skinnen“. Und zumindest die Infos zum Springen zu Navigation und Suche habe ich immer, auch als Vector-Nutzer. -- hgzh10:07, 23. Jan. 2019 (CET)Beantworten
Bearbeitungsbildschirm lädt nicht zu ende - wenn angemeldet
Letzter Kommentar: vor 5 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Als angemeldeter Benutzer bin ich bei der Wikipedia normalerweise bei der Wikipedia aktiv. Seit einigen Tagen hängt das Laden des Bearbeitungsbildschirms (egal ob Wikitext oder Oberflächenbearbeitung) immer öfter. Komme nun aber überhaupt nicht mehr in den Bearbeitungsmodus als angemeldeter Benutzer. Seitenunabhängig. Der Ladebalken bleibt immer an derselben Stelle stehen (ca. 1/3 vor dem Ende kommt er zum Stehen).--95.91.31.12409:13, 26. Jan. 2019 (CET)Beantworten
Letzter Kommentar: vor 5 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn man Scores mit der Vorbis-Funktion in Wiki hörbar machen will, schiebt sich (zumindest in meiner Ansicht) der doofe Midi-Player in die Textzeile. Das sieht nicht gut aus. Gibt es dafür Abhilfe? Wer kennt sich aus? Mit wurde in der Auskunft diese Seite empfohlen. --Krächz (Diskussion) 23:15, 26. Jan. 2019 (CET)Beantworten
Ungesichtete Seiten | Seiten mit unmarkierten Änderungen | Deep sight | PetScan | Cirrus
PetScan aufrufe, wird dorthin der Kat-Name encodiert als
Benutzer%3Aaus D%C3%A4nemark
übergeben. PetScan "versteht" dies aber nicht und findet folglich 0 Ergebnisse. Liegt das Problem hier oder muss da der Tool-Maintainer ran?--Mabschaaf09:56, 2. Feb. 2019 (CET)Beantworten
Du müsstest mal ein wenig an den URL rumspielen, und gucken, was das PetScan-Formular selbst als URL generiert.
Wenn sich eine funktionierende URL ermitteln ließe, wäre unser Encoding-Algorithmus ggf. anders zu programmieren.
D%C3%A4nemark ist normales Zeichen-Encoding im Textbereich.
Benutzer%3A ist tückisch. Der Doppelpunkt ist wie der Schrägstrich ein syntaktisches Zeichen, und wird ggf. anders erwartet (unkodiert) als normale Textzeichen.
Leerzeichen als %20 oder _ müssten unproblematisch sein, wären sonst schon vor Jahren aufgefallen. Im Wiki-Kontext ist + als Leerzeichen tückisch. Oben steht ein unkodiertes Leerzeichen, aber da machen die meisten Browser %20 draus.
Wenn sich keine funktionierende URL konstruieren lässt, müsste das Tool irgendwas abfangen.
Namensraum:Namensraum: könnte für Verwirrung sorgen.
Ich erinnere mich aber, in den Kategorie:Vorlage: erfolgreich gePetScant zu haben.
Ich habe keine Ahnung, wo ich da was rumspielen und ausprobieren sollte - deshalb bin ich hier aufgeschlagen und hoffe weiterhin auf eine Lösung des Problems.--Mabschaaf10:18, 24. Mär. 2019 (CET)Beantworten
Kann schon sein, dass das dann okay ist; aber es ist dann irgendwie seltsam.
Es ist leider nirgendwo dokumentiert, in welcher Syntax dieses $1 die Systemnachricht erreicht.
Aus dem Verhalten rückgeschlossen, wird offenbar an die Systemnachricht übergeben: Benutzer%3Aaus+D%C3%A4nemark
Dabei kodiert das + das Leerzeichen in Query-Syntax.
Normalerweise erhalten Systemnachrichten jedoch: Benutzer:aus Dänemark und in diesem Fall würde die Petscan-URL nach Benutzer:aus abbrechen und das Dänemark stünde in der Linkbeschriftung.
Nebenwirkungen sind keine zu befürchten.
@Mabschaaf: EIn interessierter Admin kann gern die BETA-Änderung übernehmen.
nutzen. Es funktionierte bei Admin, CU, OS und B-Kandidaturen.
Seit einigen Tagen kommt nichts mehr. Das Tool hat eine Übersicht über die Stimmabgaben ausgegeben, inkl. rotem Hinweis, wenn es doppelte Stimmen gab und im Kopf noch freundlicherweise eine Zusammenfassung inkl. prozentualer Auswertung.
Könnt ihr das zurück ans laufen bringen, oder etwas ähnliches zaubern? Vielen Dank --Itti08:32, 27. Feb. 2019 (CET)Beantworten
Tabellenende in div in Chrome unsichtbar
Letzter Kommentar: vor 5 Jahren9 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo! Mir ist gerade aufgefallen, dass das Ende sehr breiter Tabellen, die mittels div style="overflow... mit Scrollbalken versehen werden, in Chromium-Browsern offenbar nicht sichtbar ist. Also zB in URL-Encoding#Relevante ASCII-Zeichen in Prozentdarstellung – wenn ich ganz nach rechts scrolle, ist die Tabelle nicht abgeschlossen (fehlt wohl der Bruchteil eines Millimeters). Ist das ein MediaWiki-Fehler oder macht Chrome das allgemein falsch? In Firefox ist alles okay, soweit ich das sehe. Gruß--XanonymusX (Diskussion) 16:09, 5. Mär. 2019 (CET)Beantworten
Nachtrag: Außerhalb der Wikipedia konnte ich das Problem nicht nachvollziehen. Dürfte wohl was mit Abständen vom rechten Bildrand zu tun haben. Interessant auch, dass die Tabellen in der Vorschau des 2017-Quelltext-Modus sehr wohl abgeschlossen sind, nicht aber im Bearbeitungsmodus des VE. Gruß–XanonymusX (Diskussion) 16:19, 5. Mär. 2019 (CET)Beantworten
Ist bei mir gleiche Version und gleiches Betriebssytem, ja (gleiches Verhalten aber auch beim von mir präferierten Fork Iron). Könnte dann noch mit der Bildschirmauflösung zusammenhängen … Gruß–XanonymusX (Diskussion) 17:10, 5. Mär. 2019 (CET)Beantworten
(BK)Hm, interessant: Bei gleichbleibender Auflösung (1920×1080, wie empfohlen), aber veränderter Skalierung (125% vs. 150%) lässt sich das Problem beheben. Nur sehe ich bei 125% auf diesem Bildschirm fast nichts, ist viel zu klein. Warum jetzt aber eine 150%-Skalierung in Wikipedia und nur über Chrome das Tabellenende schluckt, bleibt ein Rätsel.–XanonymusX (Diskussion) 17:18, 5. Mär. 2019 (CET)Beantworten
Und wenn ich im Browser auf 125% rauf- oder auf 90% runtergehe, sehe ich das Tabellenende wieder. Hm, scheint dann doch eher eine Unzulänglichkeit von Chromium zu sein, oder? Gruß–XanonymusX (Diskussion) 17:23, 5. Mär. 2019 (CET)Beantworten
Letzter Kommentar: vor 5 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen, zufällig ist mir aufgefallen, dass das Timeline-Diagramm in Boeing 787#Bestellungen und Auslieferungen nach Jahr in der mobilen Version nicht angezeigt wird (getestet mit Chrome, sowohl unter Windows 10 als auch unter Android 7.1.1 sowie 8.0). Eigentlich bin ich ziemlich sicher, dass das vor wenigen Monaten noch funktioniert hat. Unter Hilfe:Zeitleisten habe ich dann erfahren, dass diese Funktionalität sowieso nicht mehr lang unterstützt wird. Allerdings tritt beim „Nachfolgemodell“ offenbar durchgängig derselbe Fehler auf (siehe etwa mw:Extension:Graph/Demo in der mobilen Ansicht). Insofern ist meine Hoffnung gering, dass ein Umbau auf diese Erweiterung Abhilfe schaffen würde, selbst wenn mir der gelänge. Hat jemand eine Idee dazu? Vielen Dank im Voraus --Monow (Diskussion) 22:07, 13. Feb. 2019 (CET)Beantworten Nach mehr als einem Monat ist das Problem unverändert. Es wäre sehr nett, wenn mir immerhin jemand bestätigen könnte, dass der Anzeigefehler nicht nur bei mir auftritt. Danke! --Monow (Diskussion) 21:06, 17. Mär. 2019 (CET)Beantworten
Letzter Kommentar: vor 5 Jahren8 Kommentare4 Personen sind an der Diskussion beteiligt
(Verschoben von der Rückseite)
Hallo,
ich bin von Hilfe Diskussion:Vorlagen hier hergeschickt worden und werde es auch bei Wikipedia Diskussion:Bots/Anfragen schreiben.
ich wollte die Vorlage mit den "Feld" Vollständigkeit der Einbindungen prüfen test, bekam aber eien seltsame antwort raus ..
Four hundred and four!
The URI you have requested, /templatetransclusioncheck?lang=de&name=Vorlage:Navigationsleiste_Luftrettung_in_%C3%96sterreich, doesn't seem to actually exist.
Perhaps the webserver has temporarily lost its mind, or the link you've followed doesn't actually lead somewhere useful?
You might want to looks at the list of tools to find what you were looking for, or one of the links on the sidebar to the left. If you're pretty sure this shouldn't be an error, you may wish to notify the project administrators about the error and how you ended up here.
Bitte mal schauen.
Festegestellt bei Vorlage:Navigationsleiste Luftrettung in Österreich
Das scheint mir auch eher ein Bug als ein Feature. An dem Namen des Tools kann der normale Nutzer ja nichts ändern. Außerdem ist das Tool bis vor ein paar Wochen einwandfrei gelaufen, der obrige Fabrikator-Faden ist aber von 2016. Hat jemand das Tool extra umbenannt, damit es nicht mehr läuft? Außerdem sagt die Fehlermeldung ja nicht "cannot start", sondern "doesn't seem to actually exist", da scheint der Fehler doch woanders zu liegen. --bjs15:37, 13. Mai 2019 (CEST)Beantworten
Ich hab mal ein bisschen auf dem Toolserver rumgesucht, da findet man https://tools.wmflabs.org/admin/tool/templatetransclusioncheck. Wenn man dort auf den Link klickt, heißt es dann "is not currently serviced". Auf der Nutzerseite des Betreibers, der anscheinend seit 2015 nicht mehr editiert hat, ist ein Hinweis darauf, dass jemand Adoption des Tools beantragt hat. Das war aber schon am 6.4. Wie das jetzt weitergeht, wieß ich auch nicht, aber es wäre schön, wenn das Tool bald wieder funktionieren würde. --bjs15:56, 13. Mai 2019 (CEST)Beantworten
Hab mal im IRC-Channel gefragt. Das scheint irgendwie durchgerutscht zu sein. Jedenfalls wird noch auf eine zweite Meinung gewartet und dann wird das Tool geeinantwortet(okay so ähnlich, ich mag dieses Wort aber). --Wurgl (Diskussion) 17:42, 13. Mai 2019 (CEST)Beantworten
Aktualisierung der Startseite der alswiki
Letzter Kommentar: vor 3 Jahren11 Kommentare5 Personen sind an der Diskussion beteiligt
Die Startseite der alswiki hängt bei der Aktualisierung regelmäßig mehrere Tage nach, wenn man nicht angemeldet ist. Wir haben die Seite etwas kompliziert aufgebaut, da wir die Sprache der Seite (Begrüßung usw.) wöchentlich wechseln. Dazu kommt der tägliche Wechsel der entsprechenden Vorlage zu Was geschah am ...? Deswegen gibt es es rund 30 Vorlagen, aus denen die Seite aufgebaut ist. Wenn ich angemeldet bin, werden jeweils die aktuellen Vorlagen angezeigt, aber ohne Anmeldung bekomme ich heute immer noch Was geschah am 16. Mai? angezeigt. Kann sich das bitte jemand mal anschauen, ob wir z. B. im Quelltext irgend einen Bug drin haben, der die Aktualisierung verzögert? Danke und liebe Grüße --Holder (Diskussion) 18:30, 22. Mai 2019 (CEST)Beantworten
Mittlerweile wird bei mir auch 22. Mai angezeigt. Kann es sein, dass das ein Cache-Problem ist? Wobei ich grundsätzlich beim Schließen des Browsers automatisch den Cache löschen lasse. Vielleicht schauen wir mal, wie es morgen aussieht. --Holder (Diskussion) 20:24, 22. Mai 2019 (CEST)Beantworten
Es ist eine Caching-Angelegenheit, aber nicht in deinem Browser, sondern bei den Servern.
Angemeldete und unangemeldete Benutzer werden von unterschiedlichen Servern bzw. Servergruppen bedient, und jeder Server hat einen eigenen Cache.
Angemeldete Benutzer sind weitaus überwiegend Autoren und werden bevorzugt und mit besonders schneller Cache-Politik bedient, auf weniger ausgelasteten Servern.
Nicht angemeldete Benutzer, die nach irgendeiner Statistik 99 % der Zugriffe ausmachen würden, sind zu irgendwelchen 99,99 % reine Leser, keine Bearbeiter, und werden ob des Massenandrangs mit einer gemächlicheren Cache-Politik abgefertigt, auf stark frequentierter Hardware.
Mir ist so, als ob es früher mal irgendwelche Bots gab, oder sogar heute noch gibt, die bestimmte Seiten zu bestimmten Uhrzeiten purgen, um eine Aktualisierung zu erzwingen.
Angemeldet siehst du immer eine möglichst frische Version; nicht angemeldet kann es dauern, bis eine Veränderung in einer Vorlage sich bis zur einbindenden Seite rumgesprochen hat.
Ein häufig frequentiertes großes Wiki löst durch viele Seitenbesuche implizite Cache-Aktualiserungen der Unterseiten aus; das könnte ein gewisser Vorteil von dewiki gegenüber alswiki sein.
Es wird allen immer der aktuellste Cache-Inhalt geliefert, egal was dein Browser will.
Meine letzte tiefer gehende Befassung mit den Cache-Prozeduren liegt ein Jahrzehnt zurück, und zwischenzeitlich sind Serverfarmen und Strategien mehrfach umgemodelt worden. Ich habe nur noch schemenhafte Vorstellungen von den aktuellen Algorithmen.
@Holder: Die phab-Geschichte liest sich so, als ob sich eine definitive Lösung noch Jahre hinziehen kann und einer komplexen Lösung und Gesamtstrategie für die gesamte Farm bedürfe; sicher nicht trivial. Ich zähle dir mal eine Reihe von Lösungswegen auf, die von unten nach oben als am ehesten praktikabel durchzuprobieren wären.
Müsste von den PC einiger als-Benutzer alle 3 oder 6 Stunden zyklisch abgefeuert werden, die einen 24/7 laufenden Rechner mit permanentem Netz haben.
Es gibt für Linux, MS Windows (oder aber in Java) Hunderte und Tausende von kleinen Shell-Hilfsmitteln, mit denen sich ein 10-Zeilen-Skript schreiben ließe, oder entsprechend konfigurierbare komplexere Anwendungsprogramme für sowas. Oder ein hiesiger Bot-Betreiber lässt das nebenbei laufen.
Danke! Das ist schonmal gut. Einziger Unterschied ist, dass nun ausschließlich Seiten angezeigt werden, auf denen beide Benutzer Bearbeitungen durchgeführt haben, vorher wurden alle bearbeiteten Seiten zeitlich chronologisch angezeigt. -- Toni (Diskussion | Hilfe?) 12:17, 12. Jun. 2019 (CEST)Beantworten
Mouse-over-Vorschau bei Image-Karten
Letzter Kommentar: vor 5 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo zusammen,
In Bezug auf das "Mouse-over-Vorschau mit Karte" Thema wollte ich nachfragen, ob man eine solche Mouse-over Funktion nicht auch bei Interaktiven-Bildern einbauen könnte. So wäre es z.B. sehr wertvoll, wenn man bei der Vorlage Sitzordnung Nationalrat nicht nur den Name sondern auch ein Bild der Person einblenden könnte wenn man mit der Maus über die gewünschte Person fährt. Das gleiche wünschte ich mir auch, wenn man bei der Karte Schweizer SAC Hütten auf einen roten Punkt fährt, dass dann ein Bild der SAC-Hütte erscheinen würde. Gruss --Tschubby (Diskussion) 07:58, 10. Jul. 2019 (CEST)Beantworten
Technisches Problem
Letzter Kommentar: vor 4 Jahren17 Kommentare8 Personen sind an der Diskussion beteiligt
Hallo! Ich habe mal zwei Fragen: seit heute kann ich für LA die Vorlage {{ers:Löschantrag|1=Deine Begründung. -- ~~~~}}
nicht benutzen, weil sie im Artikel nicht sichtbar wird. Grüße--Nadi2018 (Diskussion) 13:24, 13. Jul. 2019 (CEST)Beantworten
Danke vielmals, LA funktioniert wieder. Bleibt nur noch folgendes Problem: Seit längerem Probleme mit der Quelltext-Bearbeitung. Z. B. erscheint z. B. beim Klicken auf die Schaltfläche „NOWIKI“ oder „Seite (Link)“ oder „Signatur“ nicht an der Cursorposition im Text, sondern oben in der Betreffzeile oder auch unten in der Zusammenfassungszeile. Oder die Befehle funktionieren gar nicht. Wenn ich dann erst auf Vorschau zeigen klicke und dann weitermache, geht es. Wenn ich in der Betreffzeile mit dem Artikel verlinken will, erscheint das unten im Text. Wenn ich Text markiere und dann ausschneide, scrollt der Text nach oben. Das beansprucht viel Zeit und Nerven. Ich benutze den Microsoft Edge-Browser. Bei Google Chrome passiert das mit dem Scrollen nicht, Verlinkung und ähnliches klappt nicht immer. Ich arbeite allerdings auch lieber mit Edge (für mich übersichtlicher) und möchte nicht wechseln. Könnt Ihr mir da bitte helfen oder einen Tipp geben? Grüße,--Nadi2018 (Diskussion) 17:34, 13. Jul. 2019 (CEST)Beantworten
Das ist jetzt das 3. vollkommen unterschiedliche Problem unter diesem vollkommen allg. Topic, da kommt hier drunter gleich das 4. Problem. So kommt für jeden Freude auf. Grüße -- User: Perhelion15:36, 12. Aug. 2019 (CEST)Beantworten
Hauptsächlich die Schaltflächen Edittools, kam aber auch schon bei der Bearbeitungswerkszeugleiste oben vor (signieren und verlinken). Ich nutze den herkömmlichen Editor. Soweit ich weiß keine Browser-Erweiterungen (was meinst Du konkret?) --Nadi2018 (Diskussion) 20:33, 12. Aug. 2019 (CEST)Beantworten
Sodele, das Schlagwort „Edittools“ (mittlerweile abgelöst durch „editMenus“, aber sieht genauso aus) ruft nunmehr mich auf den Plan.
Eigentlich läuft das seit Ewigkeiten recht robust und beschwerdefrei. Das muss aber nicht ausschließen, dass es bei dir ein spezielles Problem gäbe.
Grundsätzlich arbeiten alle diese Einfüge-Werkzeuge so, dass sie die Einfügung im zuletzt aktiv gewesenen Textfeld vornehmen („Focus“ nennt sich das auch).
Bei einer Quelltextbearbeitung hast du meist zwei Felder: Das große mit dem Wikitext, und noch ein kleines, einzeiliges mit dem Bearbeitungskommentar bzw. der Überschrift eines neuen Abschnitts.
Die Einfügewerkzeuge ermöglichen dir, in das aktive Feld Sonderzeichen oder Wikisyntax wie etwa für eine Verlinkung einzugeben; egal welches. Damit kannst du auch im Bearbeitungskommentar einfach verlinken.
Zumindest „editMenus“ beginnt, wenn noch kein Feld ausdrücklich aktiviert wurde, mit dem großen Feld.
Aktivieren kannst du ein Feld, indem du einfach mit der Maus hineinklickst, oder gar dort einen Doppelklick machst (passiert meistens nichts weiter, oder wenn es schon Text gab, dann wird der markiert).
Wenn du nun mit der Maus dieses aktive Feld verlässt und dann eine Zeicheneinfügung anklickst, dann geht die dorthin, wo du zuletzt die Maus positioniert hattest, oder einen Bereich markiert hattest.
Danke, ich kapier jetzt aber gar nichts mehr. Ich hab im Quelltext nur ein großes Fenster und unten die Zusammenfassungszeile. Wenn ich ein Wort markiere und es dann meinetwegen verlinken will, oder in Anführungszeichen, geht das z. T. nicht. Wenn ich dann auf Vorschau zeigen gehe und dann zurück in den Quelltext, dann geht es wieder. Wenn ich was ausschneide, scrollt alles nach oben und ich muss die Stelle wieder mühsam suchen...--Nadi2018 (Diskussion) 22:51, 12. Aug. 2019 (CEST)Beantworten
Tjaja, dann müssen Mitleser mit Edge versuchen das nachzustellen.
Trotzdem bleiben zwei Rückfragen: 1.: Welche „Skin“? 2.: Irgendwas aktiviert, das die Wikisynax bunt macht?
Das von PerfektesChaos erwähnte kleine, einzeilige Feld mit dem Bearbeitungskommentar bzw. der Überschrift eines neuen Abschnitts ist das von Dir Zusammenfassungszeile genannte Fenster, Nadi2018.
Prima, jetzt kommen wir der Sache näher: ich arbeite mit der farbigen Syntaxhervorhebung. Wenn ich die ausschalte, passiert das nicht, geht einwandfrei. Ich brauche allerdings die bunte Hervorhebung.--Nadi2018 (Diskussion) 00:14, 13. Aug. 2019 (CEST)Beantworten
Tja, und die bunte Syntax („CodeMirror“) ist nicht so richtig integriert.
Sie geht je nach Browser mal besser, mal nicht so gut.
Die editMenus arbeiten mit einer globalen Funktion der Wiki-Software zusammen, die solches Einfügen und Aktualisieren der Darstellung vereinheitlichen und ermöglichen sollen, und ihrerseits mit externen Paketen wie dem CodeMirror zusammenarbeiten soll.
Vielleicht wird das eines Tages mal besser, aber CodeMirror ist seinerseits eine externe (fremde) freie Software und die Schnittstellen sind nicht so richtig sauber von unsrer Seite gebaut, obwohl das eigentlich technisch möglich wäre.
Über unser eigentliches Textfeld oben drüber legen sich die verschiedenen bunt-Anmal-Dingse und verdecken die schwarzweiß-Darstellung. Manche Browser wissen trotzdem, wo die Maus ist, manche nicht.
Soweit ich das verstanden habe, wissen manche Browser, wenn das große Textfeld aktiv sein soll, und andere bemerken das nicht.
Wenn mir keiner mitteilt, in welchem Feld die Maus geklickt hatte, weil der Browser das verschluckt, bin ich machtlos.
Ganz herzlichen Dank an Euch alle - wenigstens weiß ich jetzt, woran es liegt. Dann muss ich halt zwischendurch mal die Syntaxhervorhebung abschalten. Wegen mir kann das hier archiviert werden, aber Benutzer Wi-luc-ky hatte noch eine Frage zugefügt, die ich mal drunterkopiere, damit das Chaos wirklich perfekt ist...Viele Grüße,--Nadi2018 (Diskussion) 18:41, 13. Aug. 2019 (CEST)Beantworten
Nun, aber auch eine Anschlussfrage von mir an PC: Das mit dem Fokussieren funktioniert bei mir mit FF nicht, genauer: ich kann nur in die ZQ Symbole, Zeichen, Verlinkungen usw. eintragen. Von dort aus muss ich ggf. das Zeichen in das Bearbeitungsfeld kopieren. Vor dem letzten größeren workaround konnte ich nur ins Bearbeitungsfeld Zeichen einfügen, nicht direkt in die ZQ, also gerade umgekehrt. Ideal wären natürlich beide Möglichkeiten. Ich habe Sonderzeichenauswahl usw. unter dem Quelltext-Bearbeitungsfeld aktiviert, zudem Bearbeiten-Werkzeugleiste aktivieren. Die Erweiterte Bearbeitungswerkzeugleiste zeigt sich auch unergründlich nur sporadisch.
Letzter Kommentar: vor 5 Jahren12 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo! Mittlerweile ist es nun bei mehreren aber nicht allen Admins der Fall, dass beim Öffnen von Special:Import das Transwiki-Formular nur kurz aufblitzt und dann verschwindet. Ich bin mir unsicher, aber bei Importeuren ist das so wohl nicht der Fall. Wisst Ihr, was da los ist? Hat es Software-Änderungen gegeben? Was ist zu tun? Danke, – Doc Taxon • Disk. • Wikiliebe?! • 21:49, 13. Jul. 2019 (CEST)Beantworten
Wenn von den routinierten Importeuren mit dem importUtility-System gearbeitet wird, für die dieses Verfahren konzipiert ist, dann ist es entscheidend, dass in dem auf Spezial:Import usw. angebotenen Feldern nichts verändert wird – was irrtümlich mal passieren kann.
Falls auf der Spezialseite Informationen verändert würden, dann erfährt die Antragsseite im WP-Namensraum nichts von diesen Änderungen.
Im weiteren Verlauf werden anhand der Antragsseite aus Benutzer über Importe informiert usw.; ggf. auch Protokolle erstellt.
Wenn jetzt ein importUtility-Importeur auf der Spezialseite im Formular die Aktion manipulieren würde, bekäme der beantragende Benutzer falsche Informationen.
Heißt:
Wer massenhaft mit importUtility automatisiert Wünsche der Antragsseiten abarbeiten möchte, kann auf der Spezialseite nichts verändern.
Wer nicht die importUtility-Automatik verwenden möchte, sollte auch das Gadget nicht aktivieren.
Das wurde sogar ganz ausdrücklich von den mit importUtility automatisiert Anträge abarbeitenden Importeuren so gewünscht und erst nachträglich hinzugefügt, nachdem es zu Verwechslungen kam und auf der falschen Seite Angaben verändert wurden.
Wer massenhaft mit importUtility automatisiert Wünsche der Antragsseiten abarbeiten möchte, kann auf der Spezialseite nichts verändern.
Wer nicht die importUtility-Automatik verwenden möchte, sollte auch das Gadget importUtility nicht aktivieren.
wo gab es Verwechslungen, auf welcher falschen Seite wurden Angaben verändert und wie? Wer manuell mit importUtility arbeitet (es gibt ja hübsche click-Buttons), kann also zunächst erst mal keinen manuellen Transwiki-Import mehr durchführen, weil zuvor erst mal was in den Einstellungen ausgeschaltet werden muss? Und hinterher wieder eingeschaltet werden muss. Was soll denn der Quatsch? – Doc Taxon • Disk. • Wikiliebe?! • 00:31, 14. Jul. 2019 (CEST)Beantworten
Die Kernaufgabe und der Hauptzweck von importUtility ist die automatisierte Antragsbearbeitung; „um Routineaufgaben beim Import zu automatisieren“ – ein anderer Verwendungszweck als die automatisierte Antragsbearbeitung ist nicht vorgesehen.
Dabei kam es zunächst wiederholt zu Bedienfehlern durch die Importeure, weil sie versehentlich auf dem Spezialseiten-Formular Angaben änderten, ohne das in genau gleicher Weise auf der Antragsseite auch zu ändern, oder sonstige Fehlklicks passierten.
Auf Wunsch und Anregung wurde deshalb im importUtility-Modus das Spezialseiten-Formular ausgeblendet, wenn von Antragsbearbeitung ausgegangen werden muss.
Mit Aktivierung von importUtility schaltest du den automatisierten Modus der Antragsbearbeitung ein.
Wenn du keine automatisierte Antragsbearbeitung vornehmen möchtest, dann aktiviere importUtility auch nicht.
Die Qualifizierung „Quatsch“ verbitte ich mir ausdrücklich.
Die verbitte ich mir auch, sorry. Aber danke für die Erklärung,
um es bei weiteren Admins gar nicht erst zu dieser Verwirrung kommen zu lassen, fände ich es gut, bei Aktivierung von importUtility auf der Seite Special:Import eine Notiz anzubringen, dass bei eben dieser Aktivierung Formulare ausgeblendet sind. Ich hielte das für sehr sinnvoll. @PerfektesChaos: kriegst Du das bitte noch eingebaut?
Falls ich da auch nochmal beispringen darf? Ich hatte ja eigentlich angenommen, der Fall wäre mit der Klärung, dass man mit dem Abschalten des Helferleins "importUtility" wieder die komplette Spezialseite für Importe sehen kann, erledigt.
@PerfektesChaos: Ich denke auch, dass der Vorschlag von Doc Taxon mit der Notiz nicht schlecht wäre, damit man als Admin weiß, warum Teile auf der Spezialseite Importieren ausgeblendet sind. Vorausgesetzt so eine Notiz (vermutlich meint der Doc eine Editnotice) ist auf einer Spezialseite überhaupt möglich. Gruß -- Ra'ikeDisk.P:MIN00:51, 15. Jul. 2019 (CEST)Beantworten
Die Funktion mit dem Ausblenden wurde damals, soweit ich mich erinnern kann, daher eingefügt, dass man am Formular nichts mehr ändern kann, da doch immer wieder mal etwas schief gegangen ist oder gerade Neulinge mit all den Auswahlmöglichkeiten überfordert waren. Von daher find eich die Funktion nach wie vor nützlich. Den Vorschlag mit dem eingeblendeten Hinweis gefällt mir allerdings ganz gut - aber keine Ahnung, wie man den einblenden kann ... Grüße --Brackenheim10:43, 23. Jul. 2019 (CEST)Beantworten
Werden Kategorien von der Suche-Funktion nicht angezeigt ?
Letzter Kommentar: vor 5 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
Ich habe die hiesige Suchfunktion wohl bislang noch nie genutzt, um eine Kategorie zu finden.
Darum fiel mir erst jetzt auf, dass nach der Suche nach "Fassadenschmuck" nicht anzeigt wird, dass eine Kategorie:Fassadenschmuck existiert (obwohl das entsprechende Schaltfeld "Kategorie" ja standardmäßig ausgewählt ist).
Auf Commons würde in diesem Fall ja wohl ein Hinweis auf eine entsprechende Kategorie in einem gesonderten Balken oberhalb der eigentlichen Suchergebnisse angezeigt, glaube ich.
Werden Kategorienamen bei uns bei der Suche nicht berücksichtigt?
Ups, ich muß mich korrigieren: Die Kategorie wird doch angezeigt, allerdings erst ungefähr an 265. Stelle der Suchergebnisse!
Also so weit unten, das man dies im Regelfall wohl gar nicht bemerken würde. Vielleicht wäre ein besonderer Hinweis auf Kategorien wie bei WikimediaCommons auch bei uns wünschenswert?
Gerade wenn wie beim obigen Beispiel kein gleichnamiger Artikel existiert, ist es ja wohl oft sehr hilfreich zu erfahren, dass es stattdessen eine Kategorie gibt, die nach dem Suchwort benannt ist. (nicht signierter Beitrag vonKaiKemmann (Diskussion | Beiträge) 10:40, 17. Jul. 2019 (CEST))Beantworten
InvalidArgumentException
Letzter Kommentar: vor 3 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
Ich hab das mal an phab:T225366 drangehängt. Ist nicht ganz die identische Konstellation, aber die Fehlermeldung hat zumindest denselben Typ.
Seit einigen Monaten laufen immer wieder vereinzelte unerklärliche Ereignisse dieser Art auf. Ein eindeutiges Prinzip ist noch nicht erkennbar, und damit keine Identifikation der Ursachen und keine Behebungsmöglichkeit.
Die Vorfälle sind dauerhaft und auch reproduzierbar. Manchmal gibt es irgendeine Störung, gerade Donnerstag Abend, und eine Viertelstunde später ist die wieder weg. Das ist kein behebbarer Software-Bug, sondern vorübergehendes Überlastungs- oder Umstellungsproblem.
Aber Meldungen dieser Art, also die Notfallseite der Software, ohne das Projektportal drumrum, sollten niemals auftreten.
Wenn, dann diese Nummer (und Zeitstempel) [XVBv5wpAADsAAGy2lboAAACV] 2019-08-11 19:43:36 InvalidArgumentException deshalb immer angeben; daran kann im Server-Logbuch das Problem identifiziert werden, um einen detaillierten Absturz-Report ergänzt werden, und Zeitstempel mit Fehlertyp helfen auch ohne Logbuch bei der Einordnung.
Ich habe heute den selben Fehler bekommen, als ich einen Artikel verschieben wollte (Dagbani (Sprache) → Dagbani). Die WL im Ziellemma hat ein Problem mit den Sichtungen, zweimal bekam ich die Angabe, Vorlagenänderungen seien noch nicht gesichtet, 0 Versionen müssten noch gesichtet werden, nach erneutem Sichten war der Hinweis jeweils wieder weg (und einmal kurz nanach wieder da). Vielleicht gibt es da einen Zusammenhang? --androl☖☗19:01, 4. Okt. 2020 (CEST)Beantworten
Eine weitere Merkwürdigkeit: In der Linkliste erscheint die Weiterleitung nur, wenn man die Links ausblendet (26 Links (16 im ANR), 1 Einbindung, 3 Weiterleitungen, insgesamt nur 29 angezeigt). Nach einem Nulledit wird sie jetzt richtig angezeigt, dafür ist ein Link aus einem Nichtartikelnamensraum verschwunden, da wurden vorher 10 angezeigt, jetzt sind's noch 9. --androl☖☗22:46, 4. Okt. 2020 (CEST)Beantworten
einziger Bearbeiter?
Letzter Kommentar: vor 4 Jahren16 Kommentare6 Personen sind an der Diskussion beteiligt
Dabei habe ich noch nie einen Fehler gesehen. Meine Vermutung, dass das aus deinem Browsercache kommt, hat sich anhand deines Löschlogs nicht bestätigt. --Leyo09:28, 14. Aug. 2019 (CEST)Beantworten
Bei den Links auf das Rotlink-Klammerlemma sollte man IMHO nicht zuwarten. Als Zwischenlösung könnte man sie auf die Aspirin-BKS umbiegen. --Leyo10:53, 14. Aug. 2019 (CEST)Beantworten
@Raymond: alles ohne Script, ich habe nur in der Vorauswahl der Löschbegründungen diese mit der Löschdisk genommen. "Einziger Bearbeiter" wird dann wohl irgendwie automatisch dahinter geschrieben, wenn es zutrifft. @PerfektesChaos: Du kennst Dich doch auch bei solchen Sachen aus, weißt Du da was? – Doc Taxon • Disk. • Wikiliebe?! • 10:48, 14. Aug. 2019 (CEST)Beantworten
Generiert wird die Beschreibung von getAutoDeleteReason() in ContentHandler.php. Im Quelltext sieht man, dass nur die letzten 20 Versionen geprüft werden („Only scan the last 20 revisions“). Waren die letzten 20 Bearbeitungen vor der Löschung von Zxmt? --Count Count (Diskussion) 11:06, 14. Aug. 2019 (CEST)Beantworten
Hmm, im Code fehlt für die Datenbankabfrage eine „ORDER BY“-Klausel, so werden jedenfalls nicht die letzten 20 Bearbeitungen abgefragt, sondern irgendwelche 20. Also stimmt der Quelltextkommentar auch nicht. Das ist doch Murks. Die englische Wikipedia hat den Text durch ein „–“ ersetzt, siehe en:MediaWiki:Excontentauthor, und damit der automatischen Kommentar „only contributor...“ komplett ausgeschaltet. --Count Count (Diskussion) 11:20, 14. Aug. 2019 (CEST)Beantworten
mir ist offen gestanden völlig egal, ob hier ein Bug oder eine Fehlbedienung vorlag. Ich gehe davon aus, dass sich ein Log-Eintrag nachträglich nicht mehr verändern lässt - ist das korrekt? Falls ja, besteht dann wohl nur eine Möglichkeit der Reparatur: wiederherstellen und mit klarem Kommentar und ohne technischen Firefanz neu löschen. Alternativen dafür? --Zxmt Ist das Kunst?11:16, 14. Aug. 2019 (CEST)Beantworten
Wir schauen erst mal, worin der Fehler begründet ist und ob und wie wir das beheben können. Diesen Logbucheintrag nehmen wir als Beispiel zur Bugbearbeitung. Daraufhin wird das dann korrigiert werden. – Doc Taxon • Disk. • Wikiliebe?! • 14:20, 14. Aug. 2019 (CEST)Beantworten
wenn der ursprüngliche Log-Eintrag nicht mehr verändert werden kann, dann kann er nicht mehr verändert werden. (und wenn er verändert werden könnte, dann bräuchten wir keine Logs, denn dann wären die ohnehin zu nichts mehr nütze). --Zxmt Ist das Kunst?14:25, 14. Aug. 2019 (CEST)Beantworten
Extras der Graph-Erweiterung
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Wo steht die Dokumentation zu den Features der Graph-Erweiterung, welche wohl nicht zum Standard von Vega gehören (zumindest nicht in der dortigen Doku zu finden), weil sie wohl MW-eigene Extras sind? Konkret: "treeify" ist keine dort beschrieben Transformation. ÅñŧóñŜûŝî(Ð)23:37, 30. Aug. 2019 (CEST)Beantworten
Abschaffung der Buchfunktion / Leerung der Vorlage Gespeichertes:Buch
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Es gibt derzeit auf der englischen Wikipedia eine Diskussion über die Abschaffung der Buchfunktion. Diese könnte in einem ersten Schritt durch vollständige Leerung der Vorlage:Gespeichertes Buch realisiert werden. Hintergrund ist die Tatsache, dass diese Funktion im wesentlichen überhaupt nicht mehr funktioniert, sowie die offizielle Bekanntgabe das keinerlei Maßnahmen mehr ergriffen werden um die Funktionsfähigkeit in irgendeiner Weise wieder herzustellen.
Die Diskussion befindet auf der englischen Wikipedia befindet sich hier. Ich möchte euch hiermit einladen, an der Diskussion teilzunehmen, gerne auch auf dieser Seite der deutschen Wikipedia. Ich denke, es ist sinnvoll euch frühzeitig einzubinden, was ich hiermit getan habe. Viele Grüße --Dirk Hünniger (Diskussion) 12:17, 4. Sep. 2019 (CEST)Beantworten
Hilfe bei JavaScript Benutzer:Boshomi/externalURLform.js gesucht
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Das Script Benutzer:Boshomi/externalURLform.js stammt zu 99% von Benutzer:TMg/weblinkChecker, einige kleinere Änderungen habe ich selbst geschafft, etwa eine zusätzlich Farbe für InternetArchiveBot-Änderungen.
Derzeit würde mich interessieren wie man veraltete Parameter durch modernere Parameter ersetzt. Ein Kandidat dafür wäre der Parameter zugriff der gegen abruf ersetzt werden könnte. Ich wär für jede Hilfe dankbar. Ich würde dass in mein Script einbauen, das gründlich testen, und selstverständlich an TMg weitergeben, wenn es richtig funktioniert.
Ein weiterer Wunsch, aber das ist liegt für mich noch etwas weiter weg, wäre eine Anpassung an den neunen Quellcode-Editor.
Frohes Schaffen — Boshomi⌨00:35, 5. Sep. 2019 (CEST)Beantworten
Zeilenumbruch und Fußnoten
Letzter Kommentar: vor 4 Jahren9 Kommentare4 Personen sind an der Diskussion beteiligt
Die Software bricht bisher zwischen Text und Fußnoten um (siehe Screenshot), was offensichtlich unsinnig ist. Könnte man das nicht einfach softwareseitig verhindern (zum Beispiel durch Einfügen eines zero-width no-break space ähnl. wie beim %-Zeichen)? Grüße hugarheimur11:58, 6. Sep. 2019 (CEST)Beantworten
Genau, ein solches Steuerzeichen gehört dann vor jedes einzelne ref, wie eben auch vor jedes einzelne Prozent-Zeichen. Die „Von-Hand“-Lösung ist ja gerade zu vermeiden – schließlich kann man ja nur schwer absehen, wo von der individuellen Bildschirmbreite abhängige Zeilenumbrüche stattfinden werden. Wenn es natürlich eine elegantere Software-Lösung gibt … Schöne Grüße hugarheimur (ohne (gültigen) Zeitstempel signierter Beitrag vonTorana (Diskussion | Beiträge) 12:50, 6. Sep. 2019 (CEST))Beantworten
Es wäre eine Browser-spezifische Besonderheit; klingt nach uraltem Opera oder IE.
Die Browser sind für den Umbruch verantwortlich.
Die allermeisten Browser, die ich kenne, und sämtliche modernen, machen in der bei uns vorliegenden Situation den Umbruch korrekt.
Das Einfügen irgendwelcher Zauberzeichen würde nichts ändern, und es gibt sie auch nicht.
Das Einzige, was bei den beschriebenen Browsern sicher und wirksam helfen würde, wäre der Rücksprung zum Beginn des letzten vorangehenden Wortes, und dort der Beginn eines nowrap span bis hinter das letzte ref. Das könnte aber damit kollidieren, dass die Phrase vor dem ref bereits in ein span eingeschlossen sein könnte, und es dann zu einer unerlaubten Verschachtelung von Elementbereichen käme.
Im Übrigen sind unsichtbare Steuerzeichen hochgefährlich, falls jemand per C&P diesen Text irgendwo anders hinkopiert und überhaupt nicht weiß, was dann mit diesen Zeichen weiter passiert, und noch nicht einmal weiß dass sie vorhanden wären. Sie gehören ausschließlich in bestimmte Texte asiatischer Schriften und haben ansonsten in modernen Texten nix mehr am Suchen.
Am %-Zeichen steht kein unsichtbares „zero-width no-break space“.
Ändere mal die Breite des Fensters so, dass der Zeilenumbruch genau an der Stelle ist. Mit Firefox Quantum 60.8.0esr (64-Bit) / openSUSE Leap kann ich das wunderschön reproduzieren. --Wurgl (Diskussion) 09:32, 20. Sep. 2019 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Bei mir funktioniert in den letzten Wochen immer häufiger die automatische belegfunktion nicht mehr. Bin ich der Einzige, bei dem dieses Problem gerade auftritt bzw. habt ihr vor meiner Nachricht schon die gleiche Anfrage erhalten?
Wenn ich editiere, sind das meistens Informationen von den gängigen Nachrichtenseiten, faz.de, spiegel.de, sowelche Quellen. An diesen kann es also nicht liegen. LennBr (Diskussion) 19:17, 9. Sep. 2019 (CEST)Beantworten
Im Visual-Editor, wie auch im Quelltext-Editor, gibt es ja in der Kopfzeile die Toolleiste. Wenn ich mit dem Belegen-Feld arbeiten will, kommt es bei mir gelegentlich Errormeldungen, wenn ich die Belege automatisch einfügen will. zwar hat es eben funktioniert, aber bei manchen Artikeln sträubt er sich. Mal sehen, was die bei Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen dazu sagen... Anfrage hier beendet :). Gruß, LennBr (Diskussion) 20:11, 9. Sep. 2019 (CEST)Beantworten
Seltsamer "Link" "News:+" in Datenbanktabelle externallinks
Letzter Kommentar: vor 4 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Siehe quarry:query/38919 … ich möchte die Bedeutung dieses Eintrags "News:" herausfinden. Die Ursache scheint irgendwie mit der Vorlage Internetquelle verknüpft zu sein. Wenn dort im Parameter Autor am Ende das Wort News steht, dann gibt es wohl einen Eintrag, also z.B. "BBC News". Aber was steckt da dahinter, warum diesen Eintrag? Zu den Newsgruppen, wie am Ende der Tabelle in Hilfe:Links#Bearbeitungshilfe beschrieben, wird es ja wohl kaum gehen.
So nebenbei: Könnte man nicht mal auf diese Newsgruppen verzichten? Vor 20+ Jahren hab ich dort ein paar mal was geschrieben und auch gelesen … lang ist es her! --Wurgl (Diskussion) 11:26, 12. Sep. 2019 (CEST)Beantworten
news: scheint schon auszureichen, um einen Newsgruppen-Link zu erzeugen. Das ist in Vorlage:Internetquelle in Zeile 6 der Fall (Autorenangabe wird Doppelpunkt angefügt). Wo das Pluszeichen dann herkommt, kann ich nicht sicher sagen, vermutlich kodiert RemexHTML das folgende Leerzeichen, da er es als Teil einer URL erkannt hat. -- hgzh12:11, 12. Sep. 2019 (CEST)Beantworten
Das Problem scheint zu sein, dass das Leerzeichen als Entity kodiert ist (was nötig ist, weil die Parserfunktionen Leerzeichen am Anfang und Ende trimmen: news:+A vs. news: A. Ein nowiki scheint das Problem zu beheben. -- hgzh12:21, 12. Sep. 2019 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
In Staatsgerichtshof für das Deutsche Reich (Einzelnachweis 2) und Publikation von Gerichtsentscheidungen (Einzelnachweis 9) ist innerhalb der Ref-Tags eine Tabelle. Bei Mouse-Over wird ein Kasten angezeigt, doch die Tabelle ragt über den rechten Rand des Kastens hinaus. Das finde ich nicht so prickelnd. In der mobilen Ansicht muss man auf die hochgestellte Referenz klicken, dann kommt ein Kasten und dort muss man dann sowohl waagerecht (weil zu schmal) als auch senkrecht scrollen, auch nicht so schön. Und die Wikipedia-App steigt komplett aus, die verschluckt die Definitions-Elemente der Tabelle und zeigt den Rest als Textwurst an, siehe Screenshot. Aus der Zeile für die Spaltenüberschriften ! RGZ !! Lammers/Simons !! Datum !! Register-<br />nummer !! Gegenstand wird "RGZLammers/SimonsDatumRegister-nummerGegenstand102, …". Gruselig.
Ist das jetzt eine Sache für die Technik oder für Portal:Recht?
Gaaaanz ehrlich haben Tabellen rein gar nichts in Belegangaben verloren, Das zumindest ist meine Meinung ich würde so etwas entweder in den Fließtext setzen oder es komplett entfernen. Was genau soll daran ein Beleg sein? --Liebe Grüße, LómelindeDiskussion11:04, 19. Sep. 2019 (CEST)Beantworten
In Gewerkschaftliche Monatshefte ist bei den drei Referenzen "A 1", "A 2", "A 3" sowas ähnliches, eine Tabelle um eine Liste herum. Dort sieht man in der App nur einen Teil der Einträge (nur die ersten 12), aber wenigsten ist das keine Textwurst. Waagerecht scrollen muss man in der mobilen Ansicht auch nicht und der Rahmen passt. Also da geht das schon besser.
In Haltverbot ist Einzelnachweis 16 eine aufklappbare(!) Liste. Die wird wiederum kaputt angezeigt.
ref sind nur für kurzen Fließtext vorgesehen, die auch als Pop-Up oder kleiner Tooltip darsgestellt werden könnten.
Block-Elemente, etwa Tabellen oder Blockzitate, haben in ref grundsätzlich nix am Suchen und das Layout und die Weiterverarbeitung sind auch nicht darauf eingestellt.
Im Übrigen ist es gaga, zweimal derart umfangreiches Datenmaterial identisch in zwei Artikeln parallel zu halten, zu korrigieren, zu vervollständigen und die Weblinks zu pflegen.
Informationen gehören in den Hauptteil der Artikel.
Es ist Angewohnheit mancher Wissenschaftler, bei denen regelmäßig zwei Drittel der Seite aus Fußnote besteht, und an eigentlichem Text oft nur noch eine Zeile pro Seite übrigbleibt, und bei denen alles Unwichtige und Nebensächliche als Kleingedrucktes den überwiegenden Text ausmacht.
Wenn die Tabelle über den rechten Rand des Kastens ragt, dann liegt das Problem im Gadget „Fußnoten-Tooltip“. Das hat noch wesentlich größere Probleme, ist also kein echtes Thema. Dass die Tabelle in der mobilen Ansicht gescrollt werden muss, liegt an der Größe der Tabelle, nicht daran, dass sie in einem Einzelnachweis steckt. Dass die App damit gar nicht klarkommt, ist ein Fehler der App, der gemeldet werden sollte, dass er korrigiert werden kann.
Die ref-Syntax wird eben nicht nur für Einzelnachweise verwendet, sondern auch für Anmerkungen etc. und ist damit selbstverständlich für alles von einem kurzen Fließtext bis hin zu langen Auflistungen einschließlich Tabellen vorgesehen.
Ob in einem konkreten Fall eine Tabelle in einem Einzelnachweis sinnvoll ist, ist eine inhaltliche Frage, keine technische. Wenn ein Weiterverarbeiter damit nicht klarkommt, dann liegt das Problem beim Weiterverarbeiter. Wir schreiben hier aber erst einmal für normale Leser. Der hat mit einer Tabelle in einem Einzelnachweis nur wenig Probleme, weil er auf dem Desktop das Gadget nicht verwendet und mobil ohnehin scrollen muss. –Schnark09:15, 20. Sep. 2019 (CEST)Beantworten
Daten innerhalb API nicht konsistent
Letzter Kommentar: vor 4 Jahren3 Kommentare1 Person ist an der Diskussion beteiligt
Vorhin war der replag bei 2 Stunden, die engl. Wikipedia sogar bei 5 Stunden und wikidata bei 7 Stunden. Bin mir nicht sicher, ob die deutsche Wikipedia bei 2 oder 3 Stunden war. Jedenfalls gruselig lange. Grund war möglicherweise ein Crash eines Servers. https://phabricator.wikimedia.org/T233766
Ich hole mir für meine Vorlagen-Datenbank per API (→ Spielwiese) die Daten ab (eingeloggt als APPERbot). Da ist der Timestamp und die Revision dabei. In meinem Log-File steht folgende Zeile:
2019-09-25 09:42:05 Process Page Id:365531 Rev Id:192573058 Timestamp:20190925093700 Title:Liste der konsularischen Vertretungen in Hamburg
Die Zeiten im Logfile sind UTC, also lokale Zeit ist 11:42 und das stimmt mit meiner Datenbank überein, dort steht auch 20190925093700 als Timestamp und 192573058 als Revision.
Dann zerleg ich den Text in einzelne Vorlagen und lege in meiner Datenbank div. Informationen ab, unter anderem das Byte-Offset ab welchem die Vorlage beginnt und deren Länge (inkl. der öffnenden und schließenden Klammern). Jetzt steht "lustigerweise" in meiner Datenbank jeweils das Offset der vorherigen Revision, so als hätte ich zwar Timestamp & Revision der aktuellen Version bekommen, aber den Text von der Version davor.
Die letzte Vorlage "All Coordinates" hab ich angeblich bei Offset 28321 / Länge 19 gefunden, das ist in der vorherigen Revision 190277374 genau der Text "{{All Coordinates}}", in der aktuellen aber ein Teil der ersten Zeile des Abschnitts Handelsvertretungen, nämlich das Fragment "burg]]) – Außenw" (16 Character, aber 19 Byte Länge).
Ich hol mir jetzt per API auch den sha1-Wert, berechne aus dem Inhalt ebenfalls einen Hash und vergleiche die beiden und falls die beiden ungleich sind, dann murmle ich was in mein Logfile. So hab ich dann auch gleich einen Testfall zum Nachvollziehen, auch wenn das nur sporadisch auftritt. --Wurgl (Diskussion) 11:04, 27. Sep. 2019 (CEST)Beantworten
Hab tatsächlich einen Fall gehabt, wo der Hash ein anderer war.
2019-10-03 11:18:30 Process Page Id:7645820 Rev Id:192815153 Timestamp:20191003111824 Title:MTV Eintracht Celle
2019-10-03 11:18:30 *** SHA1 does not match computed: da39a3ee5e6b4b0d3255bfef95601890afd80709 API: 628e76e06f3d101ee48121a03cfd10195f9dd784
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Ein Benutzer hatte die Bearbeitung von jemand anders zurückgesetzt auf die letzte Version, die zufällig ich zuletzt bearbeitet hatte, und mit dem Bearbeitungskommentar meine Benutzerseite verlinkt. Das hat einen Ping bei mir ausgelöst, den ich als Belästigung empfinde, und das geht anderen vermutlich genauso. Auf Anfrage habe ich die Auskunft bekommen, es solle die offizielle Wiki-Software sein. Als ich das jedoch nochmals ausprobierte, hatte der Bearbeitungskommentar bei mir immer noch ganz anders ausgesehen. Ist das wirklich offiziell oder ein veraltetes Benutzerwerkzeug? Danke für Weiterhelfendes --Frau Nilsson (Diskussion) 06:14, 4. Okt. 2019 (CEST)Beantworten
Soweit ich weiß, wird der Bearbeitungskommentar auch bei einer normalen Rücksetzung automatisch erzeugt. siehe →MediaWiki:Revertpage = Änderungen von Beispielnutzer (Diskussion) auf die letzte Version von XYZ zurückgesetzt
Mich „erschrecken“ solche Pings auch manchmal. Der Sinn dahinter mag ja sein, dass ein Benutzer, der an einem Artikel zuletzt gearbeitet hatte informiert wird, dass hier nach seinem Edit eine Änderung erfolgte, die jemand anderes als nicht sinnvoll erachtet hat. Aber es kann ja auch vorkommen, dass man damit in einem Editwar landet und dann mehrfach angepingt würde, weil hin- und wieder zurück revertiert wird. Das wäre schon mehr als eine Belästigung. Du könntest es zwar abstellen, indem du in deinen Einstellungen generell die →Erwähnung abwählst, dann aber erhältst du keinerlei Benachrichtigungen mehr, wenn dich jemand gezielt rufen sollte. Ich denke es wäre sinnvoll das aufzusplitten.
Erwähnung per Link auf einer Seite (mit Signatur des Auslösers)
beabsichtigte Erwähnung in einem Bearbeitungskommentar (Zusammenfassungszeile)
Erwähnung in einem automatisch erzeugten Bearbeitungskommentar (Zusammenfassungszeile) durch eine Wiederherstellung (Revertfunktion). Info: Nachtrag: Entfällt, wenn die Systemnachricht MediaWiki:Revertpage geändert wird. (--Lómelinde13:54, 4. Okt. 2019 (CEST))Beantworten
Zudem verwenden manche Benutzer das (Punkt 2) zusätzlich zu einem Link im Textbereich einer Diskussion (Punkt 1), was dann doppelte Pings erzeugt.Auch das empfinde ich als Störung, denn einmal Anbimmeln reicht wohl. Alles andere ist in meinen Augen unnötig aufdringlich. Hätte man also diese Optionen zur Auswahl, könnte man das Pingen über die Zusammenfassung für sich einzeln unterdrücken, je nachdem wie man es selbst gern haben möchte. Allerdings denke ich, dass es in dem Fall den du hier beschreibst aus einem Benutzerskript Benutzer:PDD/addEditAndRevertLinks.js (vermutlich die optionale Funktion Benutzer-Link in Revertinfo über var revlinkshowuser) stammt (siehe auch diese Suche), wie man das abstellen kann, weiß ich auch nicht, es sieht aus als wäre das durch den Verwender anwählbar, also doch nicht automatisch, wie in der „normalen“ Revertfunktion.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Das hat jetzt mit Wikipedia nicht unbedingt was zu tun. Beim Tool Wikipedia-Personensuche bekomm ich recht viele (80 Fälle im Monat Oktober, also in 4 Tagen) Aufrufe mit kaputt kodierten Umlauten bzw. Akzent-Buchstaben.
Alle diese Urls kommen von Android (um genau zu sein: Android 5.1.1 und Android 7). Ich hab da jetzt so einen Würgherum gebaut und werfe rotzfrech die Sequenz "%83%c2" raus, es würde mich aber trotzdem interessieren, wo diese falsche Kodierung herkommt. Probiert hab ich selber auf einem Android 9 und Android 4-Gerät und zwar von der mobile Webseite zu dem Tool und von der Wikipedia-App zu dem Tool, aber ich habs nicht geschafft. Das funktioniert, so wie es soll. Keine fehlerhafte Prozent-Kodierung.
Leider ist kein Referrer im Log-File, daher weiß ich nicht wie das zustande kommt.
Also woher kommt die berechnete Autorenschaft mit "24.122 Bytes: 50,6 %" für Kontrollstellekundl?
Kann es sein, dass hier unnütze Entfernungen von Zeilenumbrüchen und Syntaxzeichen in den langen Tabellen (3 × 200 Länder) eine Hauptautorschaft bewirkt?
Meine Bearbeitungen umfassten bisher 9.907 Bytes: 20,8 %.
Warum werden hier 0 Unterkategorien angezeigt, wenn doch eine besteht? Das ist übrigens nicht der einzige Fall. In der Datenbank ist das übrigens auch nicht zu finden: SELECT cat_subcats FROM category WHERE cat_title = 'Vestfoldberge'; ergibt 0. Dafür werden dort aber 87 Seiten angezeigt, während nur 86 kategorisiert sind. Die Unterkategorie wird demnach wahrscheinlich als Seite erkannt. – Doc Taxon • Disk. • Wikiliebe?! • 00:47, 23. Okt. 2019 (CEST)Beantworten
Google Code-In will soon take place again! Mentor tasks to help new contributors!
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec08:28, 5. Nov. 2019 (CET)Beantworten
BK-Meldung beim Seitenschutz für Admins möglich?
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo zusammen, das wurde bestimmt schon mehrfach gefragt, ich habe allerdings nichts im Archiv dazu gefunden:
Wäre es möglich, eine BK-Meldung beim Seitenschutz für Admins anzeigen zu lassen, wie beim Sperren? Dort kommt es, wenn eine IP bzw. ein Benutzer bereits gesperrt ist, ich ihn aber gerade sperren will, ja der Hinweis im Sinne von "Dieser Benutzer ist bereits gesperrt: [Logbucheintrag]".
Wäre dies nicht auch beim Seitenschutz möglich? Das führt in der Praxis sonst häufig dazu, dass sich mehrere Seitenschütze nacheinander gegenseitig überschreiben (was in der Regel kein Problem ist, aber ja vielleicht technisch vermieden werden könnte?). Danke euch und Gruß, -- Toni (Diskussion) 19:24, 14. Nov. 2019 (CET)Beantworten
Hi Count Count, danke dir für deine Rückmeldung! Kenne mich leider mit dem Phabricator nicht aus und die Verläufe dort sagen mir nicht so viel. Könnte man vielleicht nach all der Zeit nochmal einen Entwickler fragen, ob er sich das Problem anschaut? Gruß, -- Toni (Diskussion) 21:56, 14. Nov. 2019 (CET)Beantworten
Ja klar, ich habe bei dem Bug Report mal nachgefragt. Es ist immer gut Interesse zu zeigen, dann wissen die Entwickler, die diesen Feature Request beobachten, dass es Leute gibt, denen das fehlt. Allzu viel Hoffnung würde ich mir trotzdem nicht machen, denn es gibt eine Unmenge an offenen Feature Requests im Phabricator.
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo!
Mir erscheinen die Sichtungen bei Vorlagen wertlos. In Vorlage:CAParlbio sind momentan 4 Versionen ungesichtet, aber ob angemeldet oder nicht, man sieht das selbe. Das ist ein Unterschied zu gesichteten/ungesichteten Versionen bei Artikeln, wo der unangemeldete Leser die gesichtete Version sieht, der angemeldete hingegen die ungesichtete. Daher frag ich mich, ob das so gewollt ist, bereits gemeldet ist und sich irgendwann ändern wird oder hat das tatsächlich noch niemand benörgelt?
Die Darstellung für die Leser hatte wohl immer schon die aktuellste Version der eingebundenen Seiten berücksichtigt, egal ob diese gesichtet wären oder nicht.
Das System müsste sonst im Cache zwei Versionen des HTML-Rumpfes vorhalten; eine mit nur gesichteten Versionen von Vorlagen berücksichtigt, und diese expandiert, und dann eine zweite mit dem HTML, das sich ergibt, wenn die aktuellsten Versionen unabhängig vom Sichtungsstatus eingebunden würden.
Der Cache zeigt aber nur die tatsächlich angefragte Seite an, und zwar entweder basierend auf der in der Versionsgeschichte der angefragten Seite letzten oder zuletzt gesichteten Version, und hat zu dieser oldid eine Version im Cache.
Wenn sich jetzt an Vorlagen oder Dateien was ändert, dann merkt der Cache davon sichtungsmäßig nichts und würde auch keine Versionen anders aufbauen.
Es ist aber trotzdem nicht sinnlos: Die Vorlagenseite selbst zeigt eine Meldung, dass sie von irgendwem verändert worden wäre, und fragt nach der Sichtung der von unbekannter Seite vorgenommenen Veränderungen. Damit kann nicht leise und unauffällig Murks in die Programmierung infiltriert werden.
Mir ist so, als ob es früher™ mal auch auf dem Artikel einen Hinweis gegeben hätte, dass er ungesichtete Bilder oder Vorlagen einbinden würde; aber vielleicht war das irgendwann irgendwem zu nervig und es wurde rausgenommen.
@Wurgl, das stimmt so nicht ich hatte zwischenzeitlich die Vorlage umgebaut, so dass sie auch auf Seiten funktionierte die nicht der Artikelgegenstand waren, funktioniert hatte, nun aber ist sie seit den Änderungen des IP-Users wieder defekt, also nur direkt im WPartikel zu besagter Person verwendbar, ich mach aber nichts mehr daran, das ist mir zu doof, wenn meine Arbeit so verhuntzt wird. Und wenn das jetzt jemand sichtet dann wird es offiziell als korrekt gewertet, obwohl die Vorlage nicht mehr richtig funktioniert. --Liebe Grüße, LómelindeDiskussion17:56, 17. Nov. 2019 (CET)Beantworten
Vermutlich(!) ist die Änderung von Herzi Pinki vom 01:57, 19. Jul. 2018 die Ursache. Die Versionen davor werden recht flott angezeigt, die danach dauern oder liefern den Fehler. Durch die Änderung sind ca. 80 EWZ-Vorlagen reingekommen. --Wurgl (Diskussion) 19:16, 21. Nov. 2019 (CET)Beantworten
Wobei die Abfrage zur Verteilung in die Untervorlagen in Vorlage:Metadaten Einwohnerzahl AT ungeschickt ist. Das erste if schlägt grad bei 10 Treffern zu, muss daher ziemlich immer ausgewertet werden, das zweite bei 90, auch fast immer. Das könnte man kippen und statt auf "kleiner" auf "größer" abfragen. So Kleinigkeiten sind egal, wenn das einmal ausgewertet wird, aber bei 80 Stück und soweit ich gesehen hab nur 4- und 5stellige Ortskennzahlen … 80 #if könnte man da einsparen, vielleicht reicht das schon? --Wurgl (Diskussion) 19:50, 21. Nov. 2019 (CET)Beantworten
Okay, das ist wirklich ein Monster. Aber ich denke, sowas sollte die Software cachen, also nicht bei jeder Einbindung parsen. Und wenn sie das schon tut, dann könnte man wohl am Switch-Statement ein wenig an der Performance feilen. --Wurgl (Diskussion) 23:27, 21. Nov. 2019 (CET)Beantworten
Habe die Disk und das Problem nicht mitbekommen. Danke an alle, die sich an der Lösung beteiligt haben. Ich war übrigens nur der Vorlagen-Einbinder, und ich habe den Ersteller auf die ev. Performanceprobleme aufmerksam gemacht, ist dort nicht angekommen. MoM. Da hat es auch immer wieder Sperrinterventionen von dritter Seite gegeben. Deine Änderung @Count Count: hilft, macht aber den Update aufwendiger. Die Einwohnerzahlen-Metadatenvorlagen sind ein altes Konzept, mit Limits. Die Liste der Ortschaften im Bezirk Feldkirchen ist unkritisch, ein nichtartikelchen, die EW-Zahlen sind leicht auch wieder entfernt. Abgesehen von den ungeklärten Lizenzfragen würde es auch nicht helfen, die EW-Zahlen aus Wikidata zu beziehen, jeder Zugriff auf ein WD-Objekt ist ein teurer (insgesamt mit 500 limitiert). lg --Herzi Pinki (Diskussion) 15:17, 22. Nov. 2019 (CET)Beantworten
@Herzi Pinki: Ich habe ein einfaches Skript geschrieben, dass den normalen #switch in einen zweistufigen konvertiert. Wenn ihr die nächste Version (im nächsten Jahr?) einstellt, kann ich es gerne wieder laufen lassen. --Count Count (Diskussion) 15:21, 22. Nov. 2019 (CET)Beantworten
das ist der Plan, die Daten werden einmal im Jahr von der Statistik Austria veröffentlicht. So um den Mai. Danke für das Skript, ich komme auf dich zurück. BTW: Bei den EW-Zahlen der Gemeinden erfolgt der Switch nach Bundesländern nach der Gliederung im Nummernschema, aber bei den Ortschaften gibt es kein offensichtliches Nummernschema, das eine Aufteilung auf Bundesländer erlauben würde (wenn ich mich recht entsinne). lg --Herzi Pinki (Diskussion) 15:31, 22. Nov. 2019 (CET)Beantworten
Fehler in PetScan
Letzter Kommentar: vor 4 Jahren7 Kommentare5 Personen sind an der Diskussion beteiligt
Das liegt aber denke ich daran, dass das Schlüsselwort korrekt hastemplate heißt, oder irre ich mich? Ansonsten finde ich den Vorlagenlink auch bei manueller Datenbankabfrage, es scheint also wirklich ein Problem von Petscan zu sein. -- hgzh18:44, 22. Nov. 2019 (CET)Beantworten
Auch mich interessiert, welche Immunresistenz die 2 Biografien entwickelt haben: Nachdem Andim schon vor Wochen darauf hingewiesen hat, habe ich mir Wolfgang Häntsch angeschaut und mit wstm durchgecheckt – das Problem bleibt weiterhin bestehen. Gruß --Chiananda (Diskussion) 18:56, 22. Nov. 2019 (CET)Beantworten
In solchen Fällen von Datenbankfehlern hilft es, einfach die Vorlage zu entfernen und neu einzufügen. Hab ich gemacht, und die Artikel werden jetzt bei mir auch nicht mehr in PetScan aufgeführt. 92.75.198.1823:18, 22. Nov. 2019 (CET)Beantworten
Ja, danke IP :) Aber bitte beim nächsten Mal mit einer Begründung in der Zusammenfassungszeile, denn unkommentierte Edits wirken grundsätzlich verdächtig… erst recht, wenn ein Hin-und-Her sinnlos erscheint. Gruß --Chiananda (Diskussion) 14:56, 23. Nov. 2019 (CET)Beantworten
Letzter Kommentar: vor 4 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
Ich hab versucht, meinen JavaScript-Hack auch für die Skin "Timeless" zum Fliegen zu bringen, aber irgendwie klappt das nicht... Mag da mal jemand drüber schauen, ich sehe grad den Wald vor lauter Bäumen nicht mehr. --Reinhard Kraasch (Diskussion) 20:33, 22. Nov. 2019 (CET)Beantworten
Wi-luc-ky Beim Posten AUF Facebook gibt es Probleme, da der Link abgeschnitten wird, also jeder "." als Link-Ende interpretiert wird. Das ist also eher ein FB-Problem. Ich dachte, WP könnte hier vllt anders verfahren wollen, wenn sich andere nicht darum scherten. --Clemens.Ratte-Polle
Magnus Danke für den Kurz-Link. Wi erstellt man diesen? Aha: URL Shortener www.w.wiki :)
„Vllt könnte unter JEDEM Artikel der Kurzlink automatisch stehen“
Das ist ausdrücklich unerwünscht.
Kurzlinks auf unsere Seiten sind innerhalb unserer eigenen Seiten ausdrücklich unerwünscht, weil dann niemand mehr anhand des Seitennamens sehen kann, wohin das führen würde, und sowieso weiß was auf der Zielseite stehen würde. Damit wäre jeder gezwungen, eine riesige Zielseite aufzurufen, um herauszufinden, wohin diese Verlinkung führen würde.
Innerhalb unserer eigenen Seiten sind diese auch deshalb ausdrücklich unerwünscht, weil es nicht das Wikilink- sondern das URL-Format ist und wir damit auch nicht rückwärts verfolgen können, wohin das zielt.
Deshalb bieten wir die nicht allzu aufdringlich an, machen sie auch nicht einfach zugänglich, und für die Außenwelt ist das auch doof. Wenn die Klarnamen dort stehen, weiß jeder welcher Artikel gemeint ist. Short-URL sind nur was für Leute, die das manuell in fremde Geräte eintippen müssten, aber keinem Link auf einer Seite folgen können.
Wer es für seinen Mobilkram regelmäßig brauchen würde, kann sich das gern irgendwie auf ausdrücklichen Wunsch irgendwomit sichtbar machen lassen; als Standardangebot für jeden Leser wäre dies katastrophal.
{{Indication de format
|infobulle=Document au format Portable Document Format (PDF) d'Adobe
|format=PDF
}}
{{Documentation modèle sans paramètre|thème=une indication quant au [[Extension de nom de fichier|format d'un fichier]] lié depuis un article}}
War vor meiner kl. Korrektur in Ksar Hellal zu sehen.
Der Text stand wohl in Vorlage:Pdf, nur ist die gestern um 21 Uhr (also vor 12 Stunden) gelöscht worden. Die Server haben das nach 12 Stunden immer noch nicht mitbekommen? Wenn ich jetzt ein ganz gemeiner, fiese und übler Troll wäre, dann würde ich jetzt eine Vorlage mit einem ganz üblen Gerücht, z.B. "(Klein-Hansi stinkt)" schreiben, diese Vorlage in ein paar Artikel versteckt einbauen, danach die Vorlage wieder löschen. Bisschen auf den Google-Crawler warten und dann findet man dieses üble Gerücht in der Wikipedia. --Wurgl (Diskussion) 09:43, 10. Dez. 2019 (CET)Beantworten
Hab mal touch.py drüberlaufen lassen. Das Problem existiert schon seit Jahren. Auf Commons haben wir gelegentlich Seiten, die via Vorlage kategorisiert sind und die viele Wochen nach einer Vorlagenänderung noch nicht aktualisiert wurden. Gruß, --Achim (Diskussion) 19:56, 10. Dez. 2019 (CET)Beantworten
Möglicherweise ein verwandtes oder zumindest verschwägertes Problem, hier geht es um Änderungen von Vorlagen (im ANR), die von Einbindern der Vorlage nicht mitbekommen werden:
⇒ Folge: Durch Datenbankabfragen bekommt das olle APPERscript nicht mit, dass jene Person bereits auch eine BKL-Seite zum Familiennamen steht, damit bekommt Graphikus diese Person Woche für Woche auf seine Wartungsliste und ich bin schuld Benutzer_Diskussion:Wurgl#Peter_Winkelnkemper_(Politiker) :-(
Hinweis auf ungesichtete Versionen in Beobachtungsliste
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo! Wie ich auf Phabricator erfahren durfte, rührt die in Minerva leicht kaputte Warnungsbox zu Beginn der Beobachtungsliste, die mich über ungesichtete Versionen beobachteter Seiten informiert, von MediaWiki:Flaggedrevs-watched-pending her. Ein Vorschlag zur Reparatur (1) wäre, das für collapse zuständige JavaScript auch mobil explizit zu laden. Ist das so umsetzbar? Ich habe mir vorerst die Box per CSS mobil ganz ausblenden lassen. Gruß–XanonymusX (Diskussion) 00:45, 14. Dez. 2019 (CET)Beantworten
VisualEditor räumt automatisch auf?
Letzter Kommentar: vor 4 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
In der Vorlage wurde eine 12 auf eine 13 geändert. Die wurde also angefasst. Und laut templatedata/Dokumentation ist diese Blockformatierung erwünscht. Ich sehe da nix falsches. ---Wurgl (Diskussion) 21:18, 17. Dez. 2019 (CET)Beantworten
Beziehung zwischen Datenbanktabelle revision und page
Letzter Kommentar: vor 4 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
Bisher bin ich davon ausgegangen, jeder Eintrag in der Tabelle "revision" hätte auch einen Eintrag in der Tabelle "page". Aber wie man bei dieser Quarry sehen kann, gibt es wohl 32701 Änderungen, aber kein zugehöriges Record zu einer Seite. Für einige dieser Einträge hab ich etwas mehr Details extrahiert: quarry:query/40741, es sind oft, aber nicht immer, irgendwelche Verschiebungen und offenbar hat das Ende August 2016 aufgehört. Weiß da jemand was? Waren das echte Aktionen oder ist das einfach Käse? --15:39, 19. Dez. 2019 (CET) (unvollständig signierter Beitrag vonWurgl (Diskussion | Beiträge) )
Zu deiner detaillierten Liste: nach ein paar Stichproben bei den Verschiebungen scheint es sich immer um Erstverschiebungen zu handeln, die anschließend mit Überschreiben einer Weiterleitung zurückverschoben wurden. -- hgzh15:51, 19. Dez. 2019 (CET)Beantworten
Von Kolja21: "Ansetzungsform in GND" das passt nicht so ganz in die Verschiebungen. Interessanterweise ist es das einzige Record mit dieser ID in rev_page?
Ist definitiv ein Bug, darf in einer sauberen Datenbank nicht vorkommen.
Produzierender Bug mag 2016 behoben worden sein.
Es gibt phab:T212428 mit gewissen Ähnlichkeiten, aber anderem Hintergrund.
Wir haben auch hier in der Werkstatt wohl eine oder mehrere Meldungen gehabt, dass zu bestimmten revisions aus der History nur Absturz dargestellt wurde, oder Diffpage damit fehlschlug. Kann auch FZW gewesen sein. Sind vermutlich alle auch Phab-gemeldet worden.
Müsste unter corrupted relations in neuer Phab-Task gemeldet werden; konnte keinen Vorgänger mit vergleichbarem Problem finden.
Wenn man ein Diff/1001/1002 macht, oder sich oldid=42 anzeigen lassen will, dann muss die revID auf ihre beheimatende pageID zeigen, etwa um den Seitennamen anzeigen zu können. Wenn da solche Klopse drin sind, muss das eigentlich schief gehen. Zumindest wenn bei der weiteren Abarbeitung mit der Tabelle "page" weitergearbeitet wird, und sinnvollerweise angenommen wird, dass diese revID dort ebenfalls eingetragen sind.
Kannst ja erstmal deine Waisenkinder an solchen Aufgaben testen.
Sollte per globalem Serverskript überall bereinigt werden, aber da zieren die sich immer mächtig.
Das stellt jedem nachfolgenden Programmierer ein Bein, der in MediaWiki, Quarry oder sonstwo von der einen in die andere Tabelle wechselt und als gesichert annimmt, dass es dort auch einen solchen Eintrag gäbe. Ansonsten könnte man sich nämlich die Zweitversion in page komplett sparen.
Kannst ja mal dein Glück versuchen, aber Geschenke gibt es da nicht mal zu Weihnachten.
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo! Schon seit langem nutze ich die Funktion, Seiten per Doppelklick zu editieren. Bislang konnte ich dann auf der Editierseite im Textfenster problemlos Wörter per Doppelklick markieren, wie in jedem Eingabefeld, hier hatte der Doppelklick darüber hinaus keine Wirkung. Jetzt auf einmal kommt dann aber die Frage, ob ich die Seite wirklich verlassen will. Was ist denn da los? Der Doppelklick als Linkersatz soll nur auf der Seite selbst aktiv sein, nicht auf der Editierseite... Betrifft FF 71. Gruß --MdE✉01:19, 23. Dez. 2019 (CET)Beantworten
Ich habe es gerade nochmal überprüft: Wenn ich die o. g. Option abschalte, kann ich per Doppelklick im Editfenster markieren. Wenn die Option eingeschaltet ist, wird auch im Editfenster der Seitenaufruf „?action=edit“ ausgeführt :-( Gruß --MdE✉14:15, 23. Dez. 2019 (CET)Beantworten
Deutsch-Englisch-Mischmasch im Menu des Timeless-Skins
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Menü unter Timeless
Ich hoffe, ich bin hier an der richtigen Stelle. Seite einigen Tagen wird mir im "Seiten-Menü" des Skins Timeless ein Mischmasch aus Einträgen in Englisch und Deutsch angezeigt (siehe Screenshot). Da fehlen wohl noch die Übersetzungen einiger Menüpunkte (und ihrer Unterpunkte) ins Deutsche.
Muss halt jemand auseinanderdröseleln, was die Ursache ist; fehlende deutsche Übersetzungen können hiesige Mitarbeiter freihändig auf dem kleinen Dienstweg auf die Reise schicken; Lücken in der Software öffnen ein etwas größeres Fässchen und die Meldung sollte dann schon möglichst direkt für Programmierer aufzuarbeiten sein.
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
I have connected 160 000 objects/creators in Europeana to Wikidata see T240290. I think this can be useful also on de:Wikipedia to have an template using this information see T241677
First, it is great that you ask first and not start to implement something in an unknown environment, with local policies over a dozen years possibly violated.
Second, you are not exactly right in this maintenance area, but that is nothing you are supposed to know.
Please drop this issue again at our partner maintenance area, which is focussing on templates: WP:VWS.
The current maintenance area (WP:TWS) is also dealing with technical issues, but more things like browser, JavaScript gadgets, MediaWiki API queries, server access.
Just to get the right audience and archive.
One will execute implementation and documentation there according to your desires.
You might refer to this section.
Third, to give an assessment in advance:
Basically it is no problem to have a template which is wrapping an external link to anything.
However, we made the experience with academic registers that they are often not exciting. That will say: They do not tell anything more than a person with this name is registered at this number.
To insert such template into encyclopedic articles about a person we do expect that the external link is providing additional value: either biographic details (CV) or exhaustive publication list.
If the template is providing access to contents, e.g. book scan, photographs etc. it is most welcome. Metadata alone might be a problem; a painting might have a height of 60 centimetres and 40 centimetres width, but that is not challenging if no image is visible.
Basically we prefer to insert registration identifiers hard-coded into our article sources, since this is a reviewing wiki and every change of data needs review of experienced users. That is sufficiently preventing vandalism, which might happen easily and unobserved on Wikidata.
For the time being if there is no checked ID we can use Wikidata entry as fallback.
@PerfektesChaos: Thanks I will do. I see Europeana as museums Wikicommons were museums can upload material and also group them per creator. If the museums do a good work we in Wikipedia just need to link the Europeana creator id (agent same as Wikidata Qnumber e.g. Wikidata entity Q44007 same as "agent/base/60816") and not every museum PLUS the museums by uploading to Europeana easier get found. What I see is that the quality differ I guess per country and as we in Wikipedia tries to understand Wikidata museums/archives has just started this learning and I hope Wikipedia <-> Wikidata <-> Europeana can learn from each other to make cultural information easier to access see complains oin Europeana at en:Wikipedia link
Hardcoded id or Wikidata
The interesting thing with Europeana is that they have started to use Entities link (same as Wikidata Qnumber) and to get starting they used dbpedia as a source and dbpedia use Wikidata as a source i.e. we are always correct as they use same as Wikidata. I see this as a biproduct that the Wikiproject is moving in the right direction of quality, trust and technology.... If we find an error then the error is in Europeana that has matched an object to the wrong creator. I have written down my experience of this and advice Europeana to get better change management see GLAM/Newsletter/December 2019 - Europeana Entity P7704 - Salgo60 (Diskussion) 13:49, 6. Jan. 2020 (CET)Beantworten
Nach Bearbeitung wird zum falschen Anker gesprungen
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Servus!
Wenn man einen Artikel bearbeitet und dann speichert, springt Mediawiki ja immer auf diese Überschrift. Wenn man jedoch mehrere gleich benannte Überschriften hat, dann springt Mediawiki immer auf die erste Überschrift.
Hui, fast 14 Jahre schon. Soweit bin ich bei meiner Fehlersuche nicht zurück gegangen. Also kann man wohl nicht auf eine zeitnahe Behebung hoffen. Noch eine Folgefrage: Wäre der Fehler grundsätzlich schwer zu korrigieren? Also würde es sich lohnen, wegen einem kleinen Problem kurz in die Mediawiki-Programmierung einzusteigen? --37.251.226.21420:25, 19. Jan. 2020 (CET)Beantworten
Extrem mühsam.
Das Grundproblem ist, dass HTML zum ersten Anker mit dieser id= springt.
MediaWiki vergibt deshalb bei gleichlautenden Überschriften eine interne Zählung; hängt also _2_3 usw. oder so ähnlich dran, bis alle Überschriften eindeutige id= zugewiesen bekamen.
Damit kann MediaWiki in der momentanen Textversion die Verlinkungen zwischen Inhaltsverzeichnis und Überschriften sicherstellen.
Wenn jedoch ein Abschnitt bearbeitet wird, dann ist das section=42 und der weiß nicht welche interne Zählung seine Überschrift im Gesamt-Dokument erhielt.
Der Mechanismus, der aus Überschriften das Inhaltsverzeichnis generiert, befindet sich jedoch an einer völlig anderen Stelle als der Abspeicherungsvorgang; der verwendet seine jetzt generierte und vielleicht veränderte Abschnittsüberschrift zur Verlinkung.
In dem Moment, in dem die Abspeicherung vorgenommen wird, wird bereits die Verlinkung auf das spätere Gesamt-Dokument als URL gebildet; das spätere Gesamt-Dokument mit seiner möglicherweise veränderten internen Zählung ist aber noch nicht bekannt, weil der neue Text noch nicht Teil des Gesamt-Dokuments ist, und das wird erst generiert, nachdem die Textbearbeitung abgeschlossen wurde, die deshalb nicht wissen kann, wo zu diesem Zeitpunkt der ursprüngliche section=42 hingekommen ist und welche id= diesem jetzt zuzuordnen wäre. Wobei sogar andere Abschnitte parallel von anderen bearbeitet werden dürfen.
Die neue Zählung mit Inhaltsverzeichnis wird erst dadurch generiert, dass der abspeichernde Benutzer die URL aufruft, um die veränderte Seite angezeigt zu bekommen. Dabei verwendet die URL das, was sie weiß, nämlich die möglicherweise veränderte Abschnittsüberschrift. Dadurch, dass eine Anfrage-URL den Server erreicht, diese Seite anzuzeigen, wird der Prozess angestoßen, der die neue Seite generiert und das Inhaltsverzeichnis generiert. Erst danach wäre die aktuelle _2_3 usw. bekannt.
Da wird sich deshalb auch keiner auf die Socken machen wollen.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, es scheint, daß in letzter Zeit kleingeschriebene Wörter bei der Suche nach Lemmata nicht mehr gefunden werden. Ging mir (der ich manchmal aus Bequemlichkeitsgründen klein schreibe) manchmal so. Konkret soeben: "kerstin hensel" führte mehrfach auf "Seite nicht vorhanden". "Kerstin Hensel" wurde gefunden.--217.70.135.6006:51, 3. Feb. 2020 (CET)Beantworten
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Verehrte Redaktion,
ich möchte auf der Seite https://de.wikipedia.org/wiki/Liste_der_ungerichteten_Funkfeuer_(NDBs) die aufgeführte Liste als PDF-Datei speichen/drucken in der Sortierung nach Frequenz. Wenn ich es versuche, wird immer wieder die Sortierung ignoriert und die Liste wird in der "Urform" nach Rufzeichen sortiert dargestellt.
Wie kann ich die Sortierung dauerhaft für den PDF-Ausdruck übernehmen?
Welchen Browser benutzten sie? Wenn sie Firefox benutzen, ist es warscheinlich am einfachsten, Firefox Screenshots zu benutzen. (Die Drei Punkte in der Adressleiste -> Bildchirmfoto aufnehmen und dann dasa Bild auszudrucken. Wie das in anderen Browsern aussieht, weiß ich leider nicht. Victor SchmidtWas auf dem Herzen?08:00, 6. Feb. 2020 (CET)Beantworten
Falscher Link in Email-Benachrichtigung
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ohne die E-Mail gesehen zu haben, würde ich sagen, das ist ein Problem des entsprechenden E-Mail-Programms. Ich selber habe im Outlook oft das umgekehrte Problem, nämlich, dass der Punkt am Ende des Satzes noch als Teil des Links interpretiert wird, den ich angegeben habe. Mein Workaround ist dann immer ein Leerzeichen vor dem Punkt zu machen. Ich kann mir gut vorstellen, dass Thunderbird genau diese Problematik bekannt ist und sie deswegen Punkte am Ende von Links grundsätzlich entfernen. DestinyFound (Diskussion) 11:50, 16. Feb. 2020 (CET)Beantworten
Das ist ein teuflisches Dilemma. Sowas in der Art passiert auch mit schließender Klammer am Ende. Lösungsmöglichkeit wäre: HTML-formatierte Mail … kann sein, dass der Benutzer dann auch die Mail im HTML-Format angucken muss, was bei so manchem Mail-Client ein Einfallstor für tolle Windows-Verbesserungsprogramme (Viren, Trojaner, etc.) sein könnte oder Prozentkodierung verwenden. --Wurgl (Diskussion) 12:11, 16. Feb. 2020 (CET)Beantworten
keine Interwiki-Links im Editfenster
Letzter Kommentar: vor 4 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Ich spioniere gerne mal bei meinen Edits in anderssprachigen Wikis um dort nach Referenzen für Unterschiede zu suchen. Solange ich den Artikel selbst anstarre, sehe ich die Interwikilinks, aber beim bearbeiten der Seite ist diese Liste leer (egal ob Quelltext- oder Visual Editor). Kann man die nicht auch beim Bearbeiten anzeigen? --Wurgl (Diskussion) 11:38, 16. Feb. 2020 (CET)Beantworten
In der Diff-Ansicht wird ausschließlich der Unterschied zwischen dem alten und dem neuen Quelltext dargestellt.
Heißt: Beim Vergleich gibt es auch keine Kategorien und Vorlageneinbindungen und Verknüpfungen mit Wikidata und was auch immer.
Was der Quelltext bedeuten soll wird nicht untersucht.
Das hat Performance-Gründe, und wird wohl auch niemand anfassen wollen.
Das gilt genauso für die Erstbearbeitung&action=edit wenn per Benutzereinstellung auf nacktes kurzes Anzeigen konfiguriert.
Im Vorschau-Modus erfolgt ein komplettes Rendering des neuen Textes. Hier werden neue Kategorien den bisherigen hinzugefügt, die jetzt aktuellen Vorlageneinbindungen usw. angezeigt, und auch die Interlanguages sind die bisherigen zuzüglich solcher die durch geänderten Quelltext hinzugekommen sein werden gehättet gesollt.
Fehlermeldung "Fehler bei der Kontaktaufnahme mit dem Parsoid-/RESTBase-Server (HTTP 400)"
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Guten Tag, ich habe relativ lange an meiner neuen Seite "gebastelt" und wollte sie in meinem Benutzerkonto hochladen, um sie zu speichern. Es kommt die Fehlermeldung oben. Auch wenn ich auf "Quelltext bearbeiten" gehe, kommt die gleiche Meldung. Was kann ich tun, um nicht alles zu verlieren? Danke für die Hilfe! (nicht signierter Beitrag vonBwieBasel (Diskussion | Beiträge) 15:14, 19. Feb. 2020 (CET))Beantworten
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hier schlug vorhin ein Problem auf, bei welchem Wikipedia zu einer Porno-Webseite verlinkte, weil die Vorlage die Adresse von Wikidata anzeigte, obwohl sie auf Wikidata als "deprecated" markiert ist. Ich hab da erst bemerkt, dass das Wikidata-Modul auch deprecated Werke zurück liefert und auch keine Option zum ändern davon anbietet. Als "hotfix" hab ich eine solches Argument eingebaut. Bevor ich das Argument dokumentiere, würde ich gerne diskutieren, ob wir die Logik nicht umdrehen sollten. Also Standardmäßig die 'deprecated' Werte nicht anzeigen und einen Parameter anbieten, wenn man das will.
Vorteile:
deprecated heißt immer, dass der Wert falsch und nicht mehr gültig ist, es wird daher praktisch nie in der Wikipedia gebraucht und ist meist unerwünscht.
Wir haben eine große Anzahl an Vorlagen die (nicht beabsichtigt) die Funktion ohne das Argument nutzen und potentiell falsche Werte anzeigen. Alle um einen Parameter zu ergänzen wäre sehr viel Arbeit.
Jetzt sind wir noch früh genug dran um es richtig zu machen und uns nicht noch-einen Klotz ans Bein binden.
Nachteile:
Restrisiko, dass das Modul irgendwo verwendet wird, wo deprecated Werte erwünscht sind und durch die Änderung etwas temporär kaputt geht.
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo, viellleicht wisst ihr das (auf FZW erfolglos): ich bereite gerade eine Umfrage Wikipedia:Umfragen/Zukunft des Sichtens vor und will die mit einer gründlichen Analyse vorbereiten. In dem Zusammenhang hab ich die Frage, ob man vom linken Seitenmenue "intelligent" verlinken kann.
Also zB. ein Menuepunkt "Sichten", der für Sichter und Nichtsichter jeweils eine andere Seite aufruft (also abhängig von den Benutzergruppen). Das gäbe die Möglichkeit, Nichtsichtern das einfach zu erklären - Sichtern die Statistiken und Werkzeuge anzuzeigen. Danke. --Brainswiffer (Disk) SICHTET!12:54, 2. Mär. 2020 (CET)Beantworten
Andreas M. Fleckner
Letzter Kommentar: vor 4 Jahren18 Kommentare5 Personen sind an der Diskussion beteiligt
Wie kommst du darauf? Von allen Anzeigen her könnte ich das - würde es aber ungern. Dem Artikel fehlen vor allem Quellen. Wenn er vom MPI weg ist, wird die einzige auch bald nur noch Archiv sein? --Brainswiffer (Disk) SICHTET!14:05, 3. Mär. 2020 (CET)Beantworten
PS: Ich konnte meine Änderungen nur ohne Haken bei Sichten speichern, da mit Haken ein fataler Ausnahmefehler angezeigt wurde (habe mir leider die Nr. nicht notiert). Info: Der Art. wurde zweimal verschoben. --Wi-luc-ky (Diskussion) 18:22, 3. Mär. 2020 (CET)Beantworten
Ein Klick auf Sichten führt zu einer internen Fehlermeldung beim API-Aufruf, die aber nicht angezeigt wird:
The given Title (Andreas M. Fleckner) does not belong to page ID 11184614 but actually belongs to 11184613
Update: heute erscheint auch Georg Pahl als 2. Artikel mit über 1000 Tagen in der Liste. diese WL wurde ebenfalls noch nie gesichtet. Bei der Dauer hätte der auch gestern da sein müssen, war er aber nicht. Anders als früher (ich hatte das für meine Befragung geprüft) basteln die wohl dran, dass nun auch die erstzusichtenden Artikel in der Arbeitsliste erscheinen? Das wäre keine schlechte Idee - wenn es denn funktionieren würde. Durchgängig ist das aber auch nicht, Bozena Anna Badura wartet 44 Tage auf Erstsichtung und müsste in der Arbeitsliste Platz 3 haben, ist da aber nicht. --Brainswiffer (Disk) SICHTET!08:35, 5. Mär. 2020 (CET)Beantworten
Und wer bastelt da dran? Bei WMF rührt sich in die Richtung schon lange nichts mehr, und WMDE hat wohl aktuell auch keine Kapazitäten dafür, außer wir bringen entsprechende Anliegen bei den nächsten Technischen Wünschen höher.—XanonymusX (Diskussion) 09:06, 5. Mär. 2020 (CET)Beantworten
Das ist bei Informatik oft so: etwas ist plötzlich anders und keiner will's gewesen sein :-) Dass die am nicht funktionerenden Erstsichten basteln, hoffe ich aber doch stark, da gibts zumindest eine Ticketnummer. Und das sieht wie ein Kollateralschaden aus. --Brainswiffer (Disk) SICHTET!09:28, 5. Mär. 2020 (CET)Beantworten
Also, auf Phabricator ist das ganze FlaggedRevs-Projekt schon lange ohne aktiven Betreuer. Das ist natürlich bekannt, finden alle blöd, aber kümmert sich doch keiner drum (betrifft ja enWP nicht). Ab und zu könnte sich etwas (quasi als Kollateralschaden) zum Besseren ändern, aber eher nicht gezielt; und je länger die FlaggedRevs nicht betreut werden, desto größer ist die Chance, dass die Erweiterung irgendwann mit neuen MediaWiki-Versionen überhaupt nicht mehr funktioniert und schlicht abgestellt werden muss. Das würde die eh schon prekären Wartungsprozesse in diesem Projekt ganz schön durcheinanderbringen … –XanonymusX (Diskussion) 12:49, 5. Mär. 2020 (CET)Beantworten
Mal ne dumme Frage: Bei Wikimedia gibt es angeblich viele Angestellte, auch für Programmierung. Gibt es da eigentlich einen verantwortlichen Koordinator, der die Ressourcen kennt und gezielt ansprechen kann? --Brainswiffer (Disk) SICHTET!13:09, 5. Mär. 2020 (CET)Beantworten
Danke für die Info. Ich hab mich da mal eingeschaltet. Denn hier gehts nicht um eine Weiterentwicklung, die sich anstellen muss, sondern um eine möglichst schnelle Reparatur von etwas, was offenbar immer mehr kaputtgeht ;/) --Brainswiffer (Disk) SICHTET!14:21, 5. Mär. 2020 (CET)Beantworten
Frage zur load.css bezgl unterstrichener links in erzeugten pdfs
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hi,
Ich lese Wikipedia Artikel gerne im pdf format. Dazu drucke ich die Artikel mit einem pdf printer.. Foxit, nitro oder Microsoft in Firefox. Die im Dezember 2019 gedruckten Artikel enthalten keine unterstrichenen links, die im Februar 2020 gedruckten pdfs schon. Ich empfinde die unterstriche als störend und ich vermute, die Datei load.css ist dafür verantwortlich. Gibt es die Möglichkeit die unterstreichungen zu unterbinden? Zumal die unterstriche im Browser auch nicht zu sehen sind. Sie erscheinen erst im pdf.
Letzter Kommentar: vor 4 Jahren10 Kommentare7 Personen sind an der Diskussion beteiligt
Im neuen Tool, um Bearbeitungskonflikte zu lösen, scheint ein Fehler zu stecken. Nachdem ein Bearbeitungskonflikt entstanden war, werden bestimmte Zeichen in HTML-Code umgewandelt und so (Code, nicht Zeichen) im Wikipedia-Artikel angezeigt. Dies betrifft zum Beispiel <, > und ", wie sie etwa bei <references /> und <br /> verwendet werden. Im Folgenden ist dann eine händische Korrektur nötig.
Mit der Suche nach insource:/<ref/ gibt es noch ein paar Treffer (9 momentan).
Und ja, man kann das abdrehen (ich hab das schon länger weggemacht). Wer schreibt diese an: 5.860 Benutzer testen diese Funktion?(das war eine fiktive Frage) --Wurgl (Diskussion) 11:45, 12. Apr. 2020 (CEST)Beantworten
Hilfreich wäre zumindest, wenn alle mit diesem neuen Werkzeug gelösten Editkonflikte eine Markierung erhalten würden. Das ist doch bei anderen vergleichsweise neuen Edit-Tools wie dem Visual Editor auch üblich.--Mabschaaf11:48, 12. Apr. 2020 (CEST)Beantworten
Mir ist das gestern auch passiert, bei Collonil. Da dachte ich, jemand hat das absichtlich zerschossen. - Aber bitte: wie kann ich das abschalten? Schönen ostermontag noch allerseits. 44pinguine☕09:41, 13. Apr. 2020 (CEST)Beantworten
Eine schnelle Quarry-Abfrage zeigt, dass das Werkzeug diese Zahl korrekt aus der flaggedrevs_promote-Tabelle entnommen hat. Nur stehen dort komplett unplausible Werte für den Benutzer, wie die 469 ANR-Bearbeitungen. Der Benutzer hat keine gelöschten Bearbeitungen.
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo,
habe die Seite "Tongrubengelände von Bensheim und Heppenheim" neu angelegt. Ein netter Kollege hat dann die Infobox ergänzt, die sich auch auf vielen weiteren Seiten findet.
Aber: der Link in der Info-Box zur Natura-2000ID "DE-63-17-305" führt auf allen diesen Seiten zu einem Fehler. Wie kann das korrigiert werden?
Zudem die Frage: wo gibt es Infos zur Nutzung der Infobox? Woher kommt z.B. der Eintrag Einrichtungsdatum 1988; das Naturschutzgebiet wurde 1977 eingerichtet.
Viele Grüße
Heinz-Vale (nicht signierter Beitrag vonHeinz-Vale (Diskussion | Beiträge) 09:44, 20. Apr. 2020 (CEST))Beantworten
Hmm, auch seitens Andrew Bogott keine Reaktion; kann sonst jemand anders die Server des petscan clusters neu starten? Zuletzt hat das anscheinend ein User namens Krenair am 4.April gemacht, auch damals schon wegen Gateway-Timeouts . . .
Gibt es irgendwo einen offiziellen Weg, wo man auf einfache Weise (ohne allzu viel Ahnung von Systeminterna) ein Ticket wegen disfunktionaler Wikipedia Infrastruktur aufmachen kann? --Wikipeter-HH (Diskussion) 10:37, 29. Apr. 2020 (CEST)Beantworten
PS: die Symptome (laut Monitoring) sind ziemlich klar. Der eine Server im Cluster (petscan4) dreht durchgehend auf 100%, während der andere fast durchgehend idle ist. Da scheint etwas mit dme Load-Balancing nicht zu klappen, oder ein User-Prozess ist in einer Loop und belegt den kompletten Server. --Wikipeter-HH (Diskussion) 10:43, 29. Apr. 2020 (CEST)Beantworten
Anthony Kaldellis
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo! Wenn ich über mein Handy etwas in eine Diskussion hinzufügen will, landet es oft leider an einem anderen Punkt in der Diskussionsseite. [11] Siehe z.B da. Der Beitrag wird also an der falschen Stelle hinzugefügt. Das habe ich korrigiert indem ich das auf der alten Art und Weise über den Wikitext gemacht habe. Grüße --Wolsberg (Diskussion) 23:44, 1. Mai 2020 (CEST)Beantworten
IP-Benutzern danken
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Leider wurde 2015 der Technische Wunsch – Dankesfunktion für IPs (aus IMHO nicht nachvollziehbaren Gründen) nicht erfüllt. Meines Erachtens bietet fr:MediaWiki:Gadget-RevertDiff.js diese Funktion, also mit wenigen Klicks einem IP-Benutzer für eine Bearbeitung danken zu können, auch wenn es noch gewisses Optimierungspotential gäbe. Mag jemand das Script für die de-WP anpassen? Um die auf die IP-Diskussionsseite gepostete Vorlage würde ich mich kümmern? --Leyo00:05, 3. Mai 2020 (CEST)Beantworten
Nicht abgeschlossene Kommentare in Referenzen
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Wenn innerhalb von <ref> … </ref> ein HTML-Kommentar <!-- begonnen, aber nicht abgeschlossen wird, dann sind zwar im Fließtext die Referenzen brav mit [123] markiert und auch anklickbar, aber im entsprechenden <references />-Abschnitt fehlen sie. Beim Artikel Wachsblumen (Hoya) war das ganz extrem, nur 34 der 76 Einzelnachweise waren im Artikel aufgeführt.
Die Syntax ist mehrdeutig, und es ist pure Glückssache, wie welche Version des Parsers dies interpretiert.
Die ref-Extension geht ohnehin eigene Wege und interpretiert den Wikitext, den sie abbekommt, nur begrenzt und als abgeschlossene Einheit.
Je nachdem ob eine Parserversion zu einem anhängigen <ref> nun zu allererst das schließende </ref> sucht oder aber nach einem anhängigen geöffneten Kommentar das Ende des Kommentars sucht passiert mal dies, mal jenes.
Das ist der Grund, warum seit drei Jahren der Linter läuft und fehlerhafte Verschachtelungen aufzuspüren versucht. Muss man halt eindeutig notieren.
Linter befasst sich allerdings mit inhaltlichen Elementen, also benannten Tags; eher wäre fehlerhaftes Nesting mit Kommentaren ein neues Feld für Linter.
Das prinzipielle Problem ist jedoch uralt und keine Neuigkeit.
Die Fehler kommen bei meiner Liste raus, zwar nicht unbedingt als Verschachtelungsfehler, aber ich finde die. Muss ja nicht doppelt gemoppelt werden. War nur die Frage, ob schon Phab-Eintrag oder nicht. Bzw, jetzt offenbar: Einfach ignorieren. --Wurgl (Diskussion) 13:52, 8. Mai 2020 (CEST)Beantworten
Kein Suchvorschlag bei neu erstelltem Artikel
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Ich habe vor rund drei Wochen die Seite Feel Good Inc. erstellt, allerdings taucht diese nicht als Suchvorschlag auf, wenn man den Begriff in die Suchleiste eingeben will. Ich weiß, es dauert normalerweise ein wenig, bis ein neuer Artikel bei der Suche vorgeschlagen wird, aber nach drei Wochen sollte das doch eigentlich erledigt sein, oder nicht? Kann da ein technisches Problem vorliegen oder dauert das wirklich so lange?--DJNevage (Diskussion) 02:18, 24. Mai 2020 (CEST)Beantworten
Auf- und Ab-Zappeln der Links der 2. Zeile
Letzter Kommentar: vor 4 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo Freunde von der Technik
Ich habe in meinem Rechner: Windows 8.1 und FireFox 76.0.1 (64-Bit).
Wenn ich die Wikipedia öffne, taucht bei mir jedes mal die
Gruppe von Links:
[Lesen] [Quelltext bearbeiten] [Abschnitt hinzufügen] und [Versionsgeschichte]) einschließlich des Such-Eingabe-Feldes,
zuerst 1 Zeile unterhalb der endgültigen Position auf, und
springt nach einigen Sekunden in die endgültige Position, das ist: die selbe Zeile, in welcher links [Artikel] und [Diskussion] sind.
Das ist zwar etwas irritierend, aber daran habe ich mich gewöhnt.
Als ich in dem Artikel Sarah Bernhardt zur Diskussions-Seite wechselte, erlebte ich ein endloses auf und ab Zappeln der genannten Gruppe von Links: immer wieder zwischen diesen beiden beschriebenen Stellen/Zeilen/Positionen hin und her. Das Gleiche geschah, unter den gleichen Umständen, aber auch beim Artikel Fedora (Filzhut). Es scheint also nicht an einem bestimmten Artikel zu liegen.
Dabei war das Auftreten dieses Zappelns von 3 Umständen abhängig:
A: dem Zoom-Faktor des Browsers,
B: ob ich bei der Wikipedia angemeldet war oder nicht und
C: ob Artikel-Seite, oder Diskussions-Seite.
Nachfolgend eine kleine Art Tabelle (ohne Trenn-Striche):
Nicht angemeldet:
Bei einer Artikel-Seite beim Zoom-Faktor: 133 %.
Bei einer Diskussions-Seite beim Zoom-Faktor: 120 %.
Angemeldet:
Bei einer Artikel-Seite beim Zoom-Faktor: keinem.
Bei einer Diskussions-Seite beim Zoom-Faktor: 120 %
Zur Technik kann ich nichts sagen, möchte aber WP:?#Versionsgeschichte nicht abrufbar und WP:?#Oben die Leiste spinnt verlinken und ich vermute, dass der Zoom-Faktor (oder Browser?) nur mittelbaren Einfluß hat. Es hängt nach meiner Wahrnehmung, davon ab, inwieweit die Menüpunkte in die Zeile passen. Wenn ich mich unter einem neuen Account anmelde, muss ich (um das Gewackel zu provozieren) das Fenster etwas breiter machen, als wenn ich unangemeldet bin, weil ich angemeldet noch den Stern fürs Beobachten in der Zeile habe. --Diwas (Diskussion) 04:20, 31. Mai 2020 (CEST)Beantworten
+1 Kann dieses Verhalten bestätigen, wollte grade selbst eine Meldung für die Freunde aus der Technik hier hinterlassen. Beobachte es heute zum ersten Mal.
Die genannte Zeile springt um Sekundentakt auf und ab, die Gruppe der Reiter fahren hin und wieder zurück. Zoomfaktor 133%, nicht angemeldet, auf beliebiger Artikelseite. Man hat auch keine Chance, irgend einen Link davon anzuklicken. Bei einer Seite mit ungesichteten Änderungen tritt der Effekt bei 100% Zoomfaktor auf. Ein Wechsel des Zoomfaktors beendet den Spuk. Es scheint die Gesamtbreite der Links im Verhältnis zum zur Verfügung stehenden Platz eine Rolle zu spielen. Ich tippe mal darauf, daß sich die Logik nicht darauf festlegen kann, ob das Menu nun eingeklappt oder ausgeklappt bleiben soll. Gab es in den letzten Tagen Änderungen an diesem Teil der Wiki-Software?
Ergänze die Auftrittsbedingungen also um einen Punkt:
D: Ob es ungesichtete Änderungen auf der Seite gibt.
System: antiX 17.4.1 auf Athlon XP 1,4 GHz, Auflösung: 96dpi, Browser: Firefox_68.8.0_esr_(32bit)
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hä?
Was zur Hölle? Warum spinnt die Leiste oben so rum? Aktualisieren bringt übrigens nichts. Das bleibt so. Ist jetzt nicht bei jeder Seite, aber irritiert mich trotzdem.
Letzter Kommentar: vor 4 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
Zufälliger Artikel: Pinguin-Effekt Unangemeldet sehe ich links in der Leiste unter Werkzeuge den Link auf Wikidata: d:Q2095675 Angemeldet mit MonoBook ist nix zu sehen. MonoBook dem zusätzlichen Parameter ?useskin=Vector (alle, außer monobook zeigen den Wikidata-Link) zeigt den Link wieder an. Ist das nur bei mir so? --Wurgl (Diskussion) 06:41, 5. Jun. 2020 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo! Apologies for writing in English. It would be appreciated if somebody could translate this message into German. We have noticed that the community of German-language Wikipedia is currently using technology that was deprecated 3 years ago that optimizes the main page for mobile users. This code will be removed in 1 months time and without any action the main page will look like this test link (notice the squished columns on a mobile screen). Given the importance of German-language Wikipedia we are keen to ensure that this project is not impacted. Luckily the fix for German-language Wikipedia is minimal. Instructions have been added to phab:T254287 which include an option that requires copying 1 line to the main page and creation of a single template(style). Please reach out to me if you have any questions either here or on Phabricator. Thank you! Jdlrobson (Diskussion) 20:58, 16. Jun. 2020 (CEST)Beantworten
Ah, @Jdlrobson: just to make sure there won’t be a clash with our new mobile styling: will the Minerva pageHeading for the main page (Willkommen, USERNAME! when logged in) stay as it is or is it affected as well? I have no idea where that one is coming from. Best regards, XanonymusX (Diskussion) 00:59, 17. Jun. 2020 (CEST)Beantworten
it will stay. that said I am not a fan of it and various projects have complained about it. I would support a phabricator ticket asking to remove it or at least asking for it to be configurable. Jdlrobson (Diskussion) 04:47, 17. Jun. 2020 (CEST)Beantworten
I just wanted to check in here to see how I can help. The deadline is approaching (next week) and I noticed that the main page has still not been updated. I understand that these changes take time but is a short term solution being considered in the event that the more ambitious technical changes have not been completed? Thanks in advance for your answer. Jdlrobson (Diskussion) 19:08, 8. Jul. 2020 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
Es gibt (unter MonoBook im Firefox auf PC) zu kleine Zeilenabstände von Vorlagen, wenn sie direkt oder nach einer Leerzeile unter einer Aufzählung stehen:
Es gibt aber einen klitzekleinen Unterschied: Bei Verwendung von importScript erscheint das in der mobilen Version Helferlein nicht, bei mw.loader.load ist die Funktion auch in der mobilen Version zu finden. Ist das bekannt?
Erstmal wäre überhaupt seltsam, dass /common.js in der mobilen Version Wirkung hätte, weil dies nur auf Desktop-Skins ausgeführt wird.
Dazu wäre die Situation mal genauer zu rekonstruieren.
Der beschriebene Unterschied ist nicht bekannt, aber importScript auch nur ein allmählich auslaufendes Modell aus den frühen Jahren. Selbst wenn die Beobachtung zutreffen würde, hätte das keine Konsequenzen.
Für „Commons verschieben“ sind die Commons-verschieben-Leutchen zuständig.
Hab es gerade getestet: Doch, ist echt so! Mit importScript hab ich WikiHistory mobil (Minerva, m-Domain) nicht, mit mw.loader.load schon. Seltsam.
Und zu m/Minerva: Ich wüsste zumindest keinen Weg, mit der m-Domain einen anderen Skin zu erzwingen. Was dort verwendet wird, ist ja auch nur eine reduzierte Fassung von Minerva, nicht die sonst auch installierbare. Gruß–XanonymusX (Diskussion) 18:05, 25. Jun. 2020 (CEST)Beantworten
Wie auch immer. Ich hab ja da so ein Dingens, nennt sich Smartphone. Dort hab ich mich eingeloggt. Zufällige Seite aufgerufen. WikiHistory blendet mir die Autoren ein. Zurück auf Google. Merkel eingetippt. Irgendwo unter den Treffern war Wikipedia. Angetippt. WikiHistory blendet mir die Autoren ein. Ich hab auf Meta nix, ich hab keine minerva.js, ich hab nur common.js. Allerdings ist es so, dass einige Ids vom HTML-Elementen in dem Skin nicht existieren, daher diese Änderung: Spezial:Diff/200379311/201289632, möglicherweise ist man deshalb zum Schluss gekommen, die global.js würde nicht gesaugt. --Wurgl (Diskussion) 21:59, 25. Jun. 2020 (CEST)Beantworten
Vorlage:Coordinate und Vorlage:Infobox_Tunnel kollidieren bei der Textanzeige
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Dabei wird es sich um eine nicht spontan lösbare Folge eines 2006 zusammengepfuschten Hack von handeln, der seit vielen Jahren als hochproblematisch bekannt ist.
Man hatte damals naiv und blauäugig gedacht, dass es die damaligen Skins auf ewige Zeiten und nur diese und immer genauso geben würde. Also hatte man dort ein leeres Plätzchen ausgeguckt, und beamt über die vermutlich freie Stelle obendrüber die von dir benannten Beschriftungen, ohne dabei wissen können, ob der Platz dort tatsächlich frei wäre, und sich mit anderen Elementen koordinieren zu können.
Jetzt stehen da also zweie. Naja, müssten die Leutchen mit dem Artikel sich halt koordinieren, welche von beiden dargestellt werden solle; die wissen nix voneinander.
Zur grundsätzlichen Lösung wende dich bitte an WD:GEO.
Ich werde mir ansehen, was da los ist, aber ich komme nicht sofort dazu. Allerdings die Frage: Das meiste der Funktionalität des Tools wird inzwischen von eingebauten MW-Tools und von Nutzer-JS-Skipten erledigt, ich habe den Eindruck, dass mein Tool kaum noch verwendet wird. Eine angefangene Überarbeitung (mit neuer Funktionalität) ruht deshalb seit längerem. Wie sehr wird das Tool überhaupt noch verwendet? (auch @Fano:) --𝔊 (GradzeichenDiſk) 04:59, 11. Jul. 2020 (CEST)Beantworten
Danke, 𝔊, für die Rückmeldung. Ich nutze Dein Tool gern und häufig und würde mich über eine einfache Instandsetzung freuen. Eine Erweiterung bräuchte ich derzeit nicht (ohne natürlich die erweiterten Funktionalitäten zu kennen, die Dir vorschweben). An welche MW-Tools hast Du gedacht? JS-Skripte haben den Nachteil, dass sie ohne Vorkenntnisse und Installation nicht nutzbar sind. Im allgemeinen Interesse wäre also ein einfach handhabbares Tool. Gruß, --Wi-luc-ky (Diskussion) 11:32, 11. Jul. 2020 (CEST)Beantworten
@Wi-luc-ky: kommst Du mit dem Template Literatur erstmal klar? Ich werde mich um die 404 kümmern, aber ich muss erst wieder meinen ssh-zugang in Betrieb bringen, das kann schnell gehen oder langwierig. (die zugangsdaten sind auf einem defekten Rechner eingerichtet). --𝔊 (GradzeichenDiſk) 18:34, 12. Jul. 2020 (CEST)Beantworten
@°: Mit der VL Lit. in Vollform hatte ich schon gearbeitet; und die Lösung von Lómelinde ist bestechend einfach. Damit kann ich aber leider keine leichte Umrechnung vornehmen, d. h.: Wenn Du das Tool wieder zum Laufen bringen könntest, wäre es optimal. Viel Erfolg! Danke, --Wi-luc-ky (Diskussion) 19:05, 12. Jul. 2020 (CEST)Beantworten
Wahrscheinlich bin ich zu doof, um mit diesem Tool zurechtzukommen :-( Egal was ich eingebe, ich bekomme immer wieder diesen Hinweis: "If you need an entire prefix of ISBNs converted, visit our inquiry page to get started." Was bitte soll ich dort wo und genau wie eingeben??? Das leider ausgefallene ISBN-Formatierer Tool war hingegen absolut Narrensicher! -- Muck (Diskussion) 23:46, 13. Aug. 2020 (CEST)Beantworten
Nachtrag: Oder liegt es etwa daran: "This ISBN Converter Tool only supports ISBNs allocated inside the USA and Australia." Wenn ja, was soll ich denn dann mit derartigem Mist ? -- Muck (Diskussion) 23:52, 13. Aug. 2020 (CEST)Beantworten
In des Eingabefeld ISBN (10 or 13) gibt man, wie es dort steht, die 10- oder 13-stellige Ziffernfolge ein (Beispielsweise 978-3-608-93977-4 mit oder ohne Bindestriche).
Dann klickt man auf convert und erhält das entsprechende Ergebnis als 13- oder 10-stellige Ziffernfolge. Converted ISBN = 3-608-93977-6 = Der Hobbit, oder, Hin und Zurück : [das Original zum Film]. Klett-Cotta, Stuttgart 2012. (deutsch), sollte aber doch 13-stellig bleiben.
@Lómelinde: Vielen Dank für deine Rückmeldung, die mir Ansporn war, bei meinem Browser nach der Fehlerursache zu suchen. Und siehe da, tatsächlich hatte ich übersehen, dass bei mir per Noscript standardmäßig alle Scripte zunächst einmal blockiert sind. Habe sie dann auch für diese URL temporär zugelassen und schon klappte es problemlos. War also mein dummer Fehler. Die Möglichkeiten dieses Tools werden mir also wieder sehr hilfreich sein :-) auch liebe Grüße -- Muck (Diskussion) 11:16, 14. Aug. 2020 (CEST)Beantworten
@Muck, schön, dass Du es selbst gefunden hast; hatte Dir gerade von NoScript schreiben wollen.
@alle Interessierte: Die Einschränkung – „This ISBN Converter Tool only supports ISBNs allocated inside the USA and Australia.“ – scheint nicht mehr zu bestehen, da ja auch solche ISBNs, die anderen Ländern zugewiesen sind, verarbeitet und umgewandelt werden. Gruß, --Wi-luc-ky (Diskussion) 11:42, 14. Aug. 2020 (CEST)Beantworten
Ja, mit Suche hätte man etwas finden können. Aber das scheinen dann Spezialtools für bestimmte Länder zu sein, was die Nutzung schon wieder schwieriger macht (man muss aufpassen und selektieren). Und den Workaround mit Vorlage:Literatur hatte ich auch schon in Notfällen genutzt. Wenn man aber viel im ISBN-Korrekturbereich arbeitet, dann ist IsbnCheckAndFormat schon alleine deshalb mit Abstand die Nummer 1, weil man feste Tastaturfolgen hat, um sehr effizient die Eingaben zu erledigen. Ich weiß, kann man auch als „Wünsch Dir Was“ sehen, aber eine Ehrenrunde mit Vorlage:Literatur-Workaround dauert 2 Minuten (Achtung, Aufräumen anschließend nicht vergessen), IsbnCheckAndFormat 5 Sekunden (mit Copy&Paste). Lange Rede kurzer Sinn, ich schließe mich Wi-luc-ky an und würde mich freuen, wenn das Tool möglichst schnell in der bisherigen Funktionalität wieder arbeitet. Danke im Voraus und VG --Bicycle Tourer19:23, 10. Aug. 2020 (CEST)Beantworten
Nachtrag: Ein weiterer Workaround, wenn es nur um das richtige Format der ISBN geht (Striche an der richtigen Stelle): Man kann in der DNB die korrekte Formatierung abrufen. VG --Bicycle Tourer22:47, 11. Aug. 2020 (CEST)Beantworten
Wo kann man den Replag ablesen?
Letzter Kommentar: vor 4 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
Bisher bin ich auf https://toolforge.org gegangen und dann gabs einen Menüpunkt um zu gucken, wie lange die Datenbank hintennach ist. Jetzt gibts die Seite nicht mehr, es geht nach wikitech :-(
Hintergrund:
MariaDB [dewiki_p]> select max(rev_timestamp) from revision;
+--------------------+
| max(rev_timestamp) |
+--------------------+
| 20200718202619 |
+--------------------+
1 row in set (0.00 sec)
Merci! Hab erst auf dem Weiterleitungsziel bei Wikitech gesucht und nix gefunden, danach hatte ich die Idee mit der Textsuche auf Wikitech und wurde fündig. Mir geht diese Seite ab, von dort gab es so einiges zu erreichen, zum Beispiel konnte man die Prozesse in der Cloud angucken, oder eine Übersicht über die Tools. Muss ich da jetzt für jeden Punkt ein Bookmark setzen? Vorher reichte mir die Übersichtsseite :-( --Wurgl (Diskussion) 10:01, 19. Jul. 2020 (CEST)Beantworten
Fehler beim Speichern eines Artikels
Letzter Kommentar: vor 4 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
Wenn ich versuche, den Artikel Bloodywood zu speichern, erscheint folgende Fehlermeldung:
Fehler:
Achtung! Deine Änderung wurde nicht gespeichert.
Diese Aktion wurde automatisch als möglicherweise schädlich erkannt und deshalb nicht ausgeführt.
Kurzbeschreibung der verletzten Regel: „Im Moment keine Bearbeitungen durch un-/neuangemeldete Benutzer“
Für weitere Informationen oder wenn du Fragen hast, gehe bitte auf WP:Bearbeitungsfilter/306.
Das gleiche passierte letzte Nacht schon bei zwei Artikeln, die sich aber heute morgen wieder speichern ließen.
Der Filter war etwas zu scharf eingestellt, sollte nun behoben sein. Bitte bedanke dich bei denjenigen, die ursächlich für diese Maßnahmen sind. -- hgzh10:41, 20. Jul. 2020 (CEST)Beantworten
Virtual editor
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Der Virtual Editor schreibt in den Quellcode beispielsweise statt des [[Tempel]]s immer des [[Tempel|Tempels]]. Kann man ihm das abgewöhnen? --bjs13:43, 20. Jul. 2020 (CEST)Beantworten
Der Visual Editor hat da schon länger Probleme, vgl. u.a. phab:T39939 und phab:T128060 in dieser Stoßrichtung. Scheint nicht allzu hohe Priorität zu genießen (und der hier dargestellte Fall ist ja auch nicht soo schlimm). Gruß, -- hgzh15:58, 20. Jul. 2020 (CEST)Beantworten
Bearbeitung nicht mehr möglich
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo zusammen,
ich habe folgendes Anliegen:
Ich kann seit einigen Tagen nichts mehr zur Wikipedia beitragen, da sobald ich in einem Artikel auf den Reiter "Bearbeiten" klicke, der Quelltext zwar für eine Sekunde erscheint, dann aber komplett verschwindet. Die Seite ist dann leer. Ich kann zwar jetzt neuen Text hinzufügen, aber alles was vorher im Artikel stand ist weg.
So passiert in meinem Artikelentwurf: https://de.wikipedia.org/wiki/Benutzer:DieNummer9/Ibrahim_Abu_al-Yaqzan
Ich wollte ihn vor der Verschiebung in den Namensraum nochmal prüfen, habe abgespeichert. Jetzt zeigt die Versionsgeschichte an "die Seite wurde geleert".
Ich habe natürlich sofort versucht, die Änderung rückgängig zu machen, leider ohne Erfolg. Die Seite bleibt leer und ich kann die Änderung nicht zurücksetzen.
Was ist hier passiert??
Auch bei anderen Artikeln, die nicht von mir erstellt wurden, passiert dies. Ich kann also quasi nichts mehr bearbeiten, da alles vorherige verschwindet.
Auch ein und ausloggen hat nicht funktioniert. Dieses Phänomen tritt trotzdem weiter auf.
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo! Wenn man im Suchfeld etwas eingibt, zudem es noch keinen Artikel gibt, kommt ja der allseits bekannte Hinweis Der Artikel „...“ existiert in der deutschsprachigen Wikipedia nicht. Du kannst den Artikel erstellen (Quelltext-Editor, Anleitung). Ich nutze ja mit meinem Benutzerkonto den Quelltext-Editor und komme, wenn ich auf Quelltext-Editor klicke auch darauf. Wenn ich jedoch nicht angemeldet bin, gelange ich über beide Schaltflächen (also sowohl erstellen als auch Quelltext-Editor) auf den Visual-Editor. Lässt sich das beheben? --Ameisenigel (Diskussion) 14:58, 26. Jul. 2020 (CEST)Beantworten
Seitenvorschau und geklammerte Terme
Letzter Kommentar: vor 4 Jahren13 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo zusammen, bei der Seitenvorschau des Artikels (((echo))) ist mir aufgefallen, dass dort das Wort (((echo))) fälschlicherweise durch () ersetzt wird. Bei anderen Lemmata, z. B. Angela Merkel werden nur die Geburtsdaten versteckt, aber andere eingeklammerte Bezeichnungen, z. B. (CDU) bleiben erhalten. Kennt jemand die Logik dahinter, wann geklammerte Begriffe verschwinden und wann nicht? Wie kann der erste Artikel korrigiert werden, gibt es da einen Trick wie {{SEITENNAME}} oder <nowiki>? --2A02:908:1464:B00:A5D1:7634:B7FA:590515:40, 30. Jul. 2020 (CEST)Beantworten
Ja, ist bekannt; das ist ein Feature, das für in mehreren Schriftsystemen vorliegende Textfragmente in chinesischer Sprache innerhalb derselben Wikipedia vorgesehen ist, usw.
nowiki hilft: (((echo))) durch ''<nowiki>(((echo)))</nowiki>'' deaktiviert das.
Wobei das eigentlich auf geschweifte Klammern ansprechen soll; mit doppelten runden kam es mir auch noch nicht unter.
Wir haben mehrere „Seitenvorschau mit Mouse-Over“, aber die sind irgendwas in JavaScript und da kann es schon sein dass die Programmierer einen unglücklichen Hack angewendet hatten und mit solch einer Syntax, die es ja „niemals im Text geben kann“ sich irgendwelche Markierungen eingebaut haben. Sowas macht man ja auch nicht.
Also verstehe ich richtig, unser Wikitext und auch die HTML-Seitenvorschau ist korrekt, aber im Pop-Up fehlt an genau welcher Stelle (Wörter davor, dahinter) genau was, das im Quelltext wie hinterlegt wäre? Die ersten 16 Bytes in Fettschrift?
Es geht wohl um Spezial:Einstellungen#mw-prefsection-rendering und dort um "Leseeinstellungen" → "Seitenvorschaubilder (ruft schnelle Vorschaubilder zu einem Thema ab, während du eine Seite liest):"
statt "(((echo))) und dreifache Klammern …" steht das "() und dreifache Klammern …"
Wenn man unseren Text vergleicht, dann fehlt der Einschub (englisch: triple parentheses) – ich meine mich daran erinnern zu können, dass zur Straffung des Textes eingeklammerte Zusätze weggelassen würden. Ich habe mit diesem Feature nichts zu tun, aber in meinem Hinterkopf meint irgendwas, dass es auch Beschwerden gab, weil bei uns die Lebensdaten (von wann bis wann gelebt) auch futsch wären und das nun aber eine ziemlich wesentliche Info sei und wir sollten das Format von 750.000 biografischen Artikeln umstellen damit dieses Tool sowas anzeigt. VG --PerfektesChaos17:26, 30. Jul. 2020 (CEST)Beantworten
JavaScript-Werkzeuge arbeiten auf den geparseten Inhalten, also auf dem, was im HTML-Dokument zwischen den Tags steht. Zeichencodes werden bei der Generierung des Dokuments normalisiert.
Wie ist denn das jetzt mit den eingeklammerten Lebensdaten einer Person?
Also mich stören die ausgelassenen Lebensdaten überhaupt nicht, ganz im Gegenteil. Manchmal sind da drölfzig Schreibweisen in unterschiedlichen Schriftsystemen/Sprachen in der Klammer und die muss ich in der Vorschau nun wirklich nicht sehen. Beispiele: Georgische Sozialistische Sowjetrepublik oder Dawit Tschubinaschwili
Mit den Lebensdaten habe ich auch kein Problem. Das ist gewollt, dass diese nicht angezeigt werden, ebenso. Aber ich vermute, irgendwo muss es wohl einen regulären Ausdruck in der Wikimedia-Software geben, der steuert, dassz. B. das Wort (CDU) bei der Mouse-over-Vorschau von Angela Merkel oder das Wort (Oder) bei Kliestow angezeigt werden, aber die Worte (geb. Kasner; * 17. Juli 1954 in Hamburg) und (Anhören?/i) nicht. --95.223.106.24214:09, 31. Jul. 2020 (CEST)Beantworten
Das wird wohl so sein, bei der von Wurgl angegebenen API.
Aber das ist globale Software, für 300 Sprachen, in 500 Wiki-Kulturen mit unterschiedlichen Darstellungen für dies und das und jenes, und das voller Ausnahmeregeln zu basteln weil in enWP+deWP = 8 Millionen Artikel es 2 Artikel gibt, bei denen das dann mal schiefgeht, wird niemanden dazu motivieren da lauter Ausnahmeregeln einzubauen für exotische Fälle.
Spannender ist, warum da () überbleibt und nicht (()) – lässt vermuten, dass die Eliminierung zweimal läuft, um irgendwie Klammern in Klammern auch noch auszublenden.
Nö, dieses Pop-Up hat dann halt Pech gehabt; wird wohl kaum ein Entwickler viel investieren wollen und die Performance der API eine Millisekunde runterdrücken. Wenn es der echte Artikeltext wäre, sicher, aber das ist nur eine Blase.
Anmeldung in Firefox-Android führt zu leerer Seite
Letzter Kommentar: vor 3 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Seit einiger Zeit habe ich jetzt schon Probleme, Wikipedia auf meinem Handy in der mobilen Ansicht angemeldet zu öffnen.
Was funktioniert:
mobile Ansicht ohne Anmeldung
klassische Ansicht
Was nicht funktioniert:
mobile Ansicht mit Anmeldung
Das Problem sieht so aus: Ich bin in der mobilen Ansicht, gehe auf die Anmeldeseite und melde mich an. Die Anmeldung funktioniert, eine neue Seite wird geladen, und kurz bevor sie fertig ist, wird die Seite blank (weiß). Auch wenn ich jetzt einen Artikel per URL aufrufe, sehe ich ihn beim Laden kurz, und dann ist er wieder weg. Wenn ich im Browser (Firefox für Android) die Desktop-Ansicht auswähle, bleibt der Effekt trotzdem, bis ich das m aus der URL rauswerfe.
Ich habe mich bereits sowohl ab- und wieder angemeldet als auch die Cookies/aktive Logins gelöscht. Erste Anmeldung dann, sofort gleiches Problem. Woran kann das liegen? Was kann ich tun? Danke und Gruß --MdE✉15:18, 7. Aug. 2020 (CEST)Beantworten
Falls jemand noch einen Tipp für mich hat, bitte anpingen, ich schau erst mal nicht mehr hier vorbei. Auch wenn der Desktop-Modus auf dem kleinen Handyschirm ätzend ist... Gruß --MdE✉16:27, 22. Aug. 2020 (CEST)Beantworten
Auf einen Verdacht hin habe ich nochmal alle Helferlein/Modifikationen der Oberfläche abgeschaltet – ohne Erfolg, daran liegt es auch nicht. Inzwischen hat der FF für Android ein großes Update gemacht, auch das hat nichts geändert. Es ist immer, sobald die Kombination de.m.wikipedia.org und Anmeldung als MdE auftritt. In einem privaten Browsertab keine Probleme trotz mobiler Ansicht. Hab ich irgend eine Einstellung übersehen? Gruß --MdE✉11:50, 27. Aug. 2020 (CEST)Beantworten
@FriedhelmW: Danke für den Tipp! Cache leere ich ohnehin bei solchen Tests und stets beim Beenden des Browsers. Aber der Safemode funktioniert! Wie finde ich dann den Übeltäter? Alle Helferlein etc. über die Einstellungen abzuschalten hatte ja nicht geklappt. Gruß --MdE✉20:21, 2. Okt. 2020 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. MdE✉ 21:38, 2. Okt. 2020 (CEST)
Suche und Lesbarkeit verbessern
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Es wäre sehr angenehm, wenn bei Suchworteingaben Buchstabendreher "automatisch" verarbeitet würden.
Besonders die Möglichkeit die Schriftgrösse zu verändern (vergrößern) würde ich sehr begrüssen (vielleicht nicht nur ich)
Hallo, Buchstabendreher werden (nach kurzem Selbsttest) eigentlich in den Suchvorschlägen aufgelöst. Die Schriftgröße lässt sich im Browser mittels Strg++ vergrößern. -- hgzh19:33, 13. Aug. 2020 (CEST)Beantworten
Fehler beim Importieren von Templates
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Ich habe aus der der deutschen Wikipedia mir mehrere Templates exportiert und diese dann in mein privates Wiki importiert. Alls Templates erzeugen folgende Fehlermeldung:
Die Vorlage:Dokumentation wird im Artikelnamensraum verwendet. Wahrscheinlich fehlt <onlyinclude> in einer eingebundenen Vorlage oder die Kapselung ist fehlerhaft. Bitte Vorlage:Bearbeiten.
Ich bin Anfänger hinsichtlich Mediawiki, aber trotzdem überrascht über die bereits erzielten Fortschritte, aber diese Fehlermeldung überfordert mich.
Hallo, die Vorlage:Dokumentation (also {{Dokumentation}} muss in einem <noinclude>-Block eingeschlossen sein, bzw. der Rest der Vorlage in einen onlyinclude-Block. Gruß, -- hgzh19:31, 13. Aug. 2020 (CEST)Beantworten
WikiSyntaxTextMod im Benutzernamensraum
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Warum stellst du denn deine Frage nicht an den Betreiber des Tools? Es gibt dort doch extra eine →Diskussionsseite Ich sehe keinen Fehler in deiner Einbindung, oder hast du es möglicherweise auf deiner Benutzerseite selbst versucht? Dann müsstest du vermutlich den Slash hinten ":dewiki:Benutzer:M-B/" weglassen, damit dieses auch aktiviert wird. @PC? --Liebe Grüße, LómelindeDiskussion18:37, 15. Aug. 2020 (CEST)Beantworten
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo. Gibt es einen Trick (Aufrufparameter, Javaskript etc), mit dem ich erreichen kann, dass beim Start des Quelltexteditors via "Quelltext bearbeiten" nicht die "Edittools-Standardleiste", sondern die "Edittools-WikiSyntax-Leiste" ausgewählt ist (in der Combobox)? Die benötige ich viel häufiger. ÅñŧóñŜûŝî(Ð)19:04, 2. Sep. 2020 (CEST)Beantworten
Banner wegen Servertest am 01.09.20 jetzt (03.09.20) z.T. immer noch sichtbar
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Guten Morgen, das o.g. Banner ("Am Dienstag, dem 1. September, wird ab 16:00 Uhr MESZ das Bearbeiten der Wikipedia und ihrer Schwester-Projekte für bis zu eine Stunde lang nicht möglich sein. Hintergrund ist die Einrichtung eines zweiten Datenzentrums.") ist teilweise - nach jetzt fast zwei Tagen - immer noch bei manchen Artikeln sichtbar; z.B. bei Donald Trump oder auch Hilfe:Übersicht. Vielleicht lassen sich die Seiten ja zeitnah aktualisieren. Danke und VG --46.114.2.9106:00, 3. Sep. 2020 (CEST)Beantworten
Das ist auch im API (Per Browser nach "Benutzer alles im" suchen) nicht zu unterscheiden, die UTF-Zeichen sind als \u... kodiert. Ich dachte erst, das ist so eine seltsame Sache mit UTF-8, wo man Umlaute als einen Codepunkt oder als Komposition aus dem Grundbuchstaben und einem Kombinationszeichen darstellen kann. Ganz seltsam. --Wurgl (Diskussion) 11:36, 5. Sep. 2020 (CEST)Beantworten
Was auffällt: Die Siggi von Valanagut schaut nach Thai-Einfügung aus.
Da ich selbst einmal einen Neuschrieb des Diff-Code vorgestellt hatte, weiß ich, dass Thai in der veränderten Zeile eine andere Behandlung erfordert, und die jetzt aktive, seit damals veränderte Implementierung (angeregt durch meine, aber nicht 1.1 übernommen) ist dann wohl von Nicht-ASCII überfordert. Wobei ich nicht mehr mit Gewissheit sagen kann, ob meine damalige Programmierung pfiffiger war und das ignoriert hätte, glaube aber schon, auch so auf den ersten Blick fast ein Jahrzehnt später, weil ich nicht immer die gesamte Zeile vergleiche, sondern separat die Nur-Thai-Sequenzen als einzelne Wörter. Die zuvor und bis heute wirksame Implementierung wendet hingegen den Thai-Diff-Algorithmus auf die gesamte Zeile an, sofern Thai irgendwo darin vorkäme, und versagt deshalb bei Nicht-ASCII.
All-in-one-Diff wie Schnark sehen keinen Unterschied an den Umlauten.
Danke, FriedhelmW, für Deine Antwort hier und den Service im Lemma. Genau so sollte es sein; die Navigation ist so bequemer. (Hatte es wohl nur vergessen und in den Anleitungen nicht mehr gefunden.) Gruß, --Wi-luc-ky (Diskussion) 14:47, 5. Sep. 2020 (CEST)Beantworten
Anscheinend deaktiviert die Vorlage:TOC das automatische Inhaltsverzeichnis. Dann sollte das und die Lösung auch in die Vorlagendokumentation eingebracht werden. --Diwas (Diskussion) 00:28, 6. Sep. 2020 (CEST)Beantworten
Letzter Kommentar: vor 3 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt
In Hilfe:TeX gibt es die Empfehlung (genauer: die Verdonnerung)
<math>\text{für} oder \mbox{für}</math>
zu schreiben – mit dem bekannten äußerst hässlichen Ergebnis:
oder .
Dies wurde schon vielfältig beklagt, z.B. in mehreren Abschnitten in Hilfe_Diskussion:TeX sowie auf dieser Seite hier.
Diese Eingaben gehen mindestens bis ins Jahr 2014 zurück, sind also seit ≥ 6 Jahren überfällig.
Dabei gibt es Fonts wie den in cmunrm.pdf beschriebenen Font "Computer Modern Unicode Serif Roman", der das alles wunderbar draufhat.
Ist das alles viel komplizierter, als Otto Normalverbraucher sich das vorstellt, oder muss man an der WP-Demokratie schlichtweg verzweifeln ?? –Nomen4Omen (Diskussion) 11:25, 9. Sep. 2020 (CEST)Beantworten
Nein, das weiß ich natürlich nicht. Ich weiß nur, dass es eine Lösung (einen Font) gibt. Implementieren, also den Aufruf etc. durchziehen, muss jemand von „Wikipedia:Technik/Werkstatt“.
Hallo Nomen4Omen, du hast dich bei obigem Task als "Assigned To" eingetragen. Das solltest du nur tun wenn du in der Lage bist das Problem zu lösen. Sonst hindert es evtl. andere daran sich zu kümmern. --FriedhelmW (Diskussion) 14:21, 10. Sep. 2020 (CEST)Beantworten
@FriedhelmW: Ich bedanke mich sehr. Natürlich bin ich nicht der, der das dann macht. Ich finde die Sprechweise (assigned to? was geht das mich an? muss ich das mitkriegen?) und Schaltflächenangebote im phabricator extrem gewöhnungsbedürftig. Z.B. finde ich nicht mehr den Knopf zum Upload. Ich hoffe, dass dem "Physikerwelt" der eine Screenshot von MS edge reicht. An das cmunrm.pdf müsste er per Google selbst rankommen. (Ich hätte noch einen Screenshot davon und einen von MS IE11.) Auch sonst läuft so Vieles anders und wird anders dargestellt, als man es als Editor gewohnt ist. Zur Sache: Nach meinen Beobachtungen scheint die Darstellung dieser \mathrm-Umlaute vom Browser abzuhängen. Und habe keine Ahnung, wie sich das vom Portal aus beeinflussen lässt. Auf jeden Fall vielen Dank für deine Hilfe. Gruß, –Nomen4Omen (Diskussion) 16:26, 10. Sep. 2020 (CEST)Beantworten
"Aktionsanzahl limitiert"
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hallo Technikwerkstatt,
ich habe heute mal wieder aus heiterem Himmel bei einer völlig harmlosen Bearbeitung die Fehlermeldung "Aktionsanzahl limitiert" bekommen. Da ich dies für eine beabsichtigte Beschränkung hielt, habe ich heute und neulich auch schonmal bei den Admins nachgefragt, aber die wussten auch keinen Rat. Die limitierenden 8 Edits pro Minute habe ich ganz sicher niemals erreicht. Ist es möglich, dass das irgendein Bug ist? Danke, --217.239.3.14319:21, 17. Sep. 2020 (CEST)Beantworten
Navigationsleisten und Kategorienleisten anpassbar, im Falle einer Änderung der Benutzeroberfläche?
Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Technik!
Angenommen die deutschsprachige Wikipedia würde per MB entscheiden, Kategorien zwecks höherer Wahrnehmung über die Einzelnachweise zu setzen, wäre dies technisch für Euch insoweit machbar, dass sich Navigationsleisten und die Kategorienzeilen bei kurzen Artikeln (die zugleich Infoboxen und/oder Bilder am rechten Rand haben) anpassen würden, sodass es nicht zu einer überdeckung der Flächen am rechten Rand kommt? Bei etwas längeren Artikeln, bei denen bspw. die Bilder am rechten Rand bis über den Abschnitt der Einzelnachweise hinausreichen, wird der Quellen-Abschnitt automatisch visuell komprimiert. Zu sehen bspw. im Artikel Parker Solar Probe. Bei Navigationsleisten und Kategorienleisten findet diese Anpassung/Komprimierung derzeit (auch bei längeren Artikeln) nicht statt. Das kann man bspw. sehen, wenn man über die Bearbeitung des eben erwähnten Artikels, den Fließtext aus dem Artikel rausnimmt und sich das Ergebnis über die Vorschau ansieht: So folgen erst nachdem die Infoboxen und Bilder am rechten Rand enden, die Navigationsleisten und Kategorienleisten.
Gruß, --LennBr (Diskussion) 03:55 (Nacheditiert um 18:27), 18. Sep. 2020 (CEST)
Theoretisch für Benutzer mit aktiviertem JavaScript schon.
Das Ganze ist in Desktop gedacht; in den Mobildarstellungen nicht umsetzbar.
Global steht das auf allen Seiten in jedem Wiki an der gleichen Stelle, und auch die hiesige Lesersachaft ist es an dieser Stelle gewohnt.
Wenn, dann passiert das auf allen Seiten, und auch Wartungskategorien würden dann mitten im Artikel auftauchen. Irgendwas wie „kurze Artikel“ gibt es nicht. Es gibt auch keine einheitliche Überschrift „Einzelnachweise“, oberhalb so bezeichneten Abschnitts etwas dargestellt werden könnte.
Für Autoren, neue und altgediente, ist die Darstellung ziemlich verwirrend und bedürfte Umlernens, und die Darstellung wäre nicht mehr vorhersagbar. Momentan ist das sehr simpel: Das, was ich als Wikitext angebe, wird in einem einheitlichen Block in genau dieser Reihenfolge auch in der Seite dargestellt. Außerhalb dessen stehen die Kategorien, in allen Namensräumen, immer an der gleichen Stelle. Auch die Leser suchen es in allen Namensräumen in allen Wikis dort und nur dort. Wenn es dort unten nicht zu sehen ist, dann gibt es auch keine Kategorisierung, basta.
Der Artikel sieht Mobil anders aus als Desktop, mit JavaScript gibt es andere Abschnitte als ohne, bei Artikeln ohne „Einzelnachweise“ mit Navigationsleisten ist es wieder anders. Ziemlich konfus.
Die Richtlinien zur Anordnung von Abschnitten in Artikeln müssten umgeschrieben werden.
Performancemäßig katastrophal: Um ein oder zwei Dutzend Seiten umzubauen, die optisch in Frage kämen und auch einen „Einzelnachweise“ überschriebenen Abschnitt hätten, müssten zweieinhalb Millionen Artikel analysiert werden, für jede Darstellung.
Ein MB würde ich persönlich als chancenlos einschätzen, aber das ist nicht meine Aufgabe.
@PerfektesChaos: Sind alle diese Punkte in der Annahme geschrieben, dass nur bestimmte Artikel von einer solchen (hypothetischen) Änderung nach positiven MB betroffen sind? Im Ausgangspost oben habe ich nicht klar genug gemacht, dass ich über ein Verschieben der Navi- und Kategorienleiste bei allen Artikeln nachdenke, sodass diese Leisten besser zur Geltung kommen. Würde also deine Einschätzung/Antwort nun anders ausfallen (unter der Annahme, dass Du dachtest, ich beziehe mich nur auf kurze Artikel)? --LennBr (Diskussion) 18:25, 18. Sep. 2020 (CEST)Beantworten
Ich ging von deiner Darstellung zum Platz sparen bei kurzen Artikeln und viel Infobox aus, und irgendwas mit Layout und Bildern am rechten Rand. Das Gesamtziel oder ein Konzept habe ich ohnehin nicht verstanden.
Auch übertragen auf alle Artikel bleiben aus rein technischer Sicht die nachstehenden Knackpunkte:
Kategorien lassen sich nur mit aktiviertem JavaScript woanders hin mitten in den Artikel verschieben, mit dem Problem des FOUC und bei anderer Artikelstruktur in einer Mobil- und Desktopdarstellung.
Im Inhaltsverzeichnis taucht dein eingefrickelter Kategorien-Abschnitt grundsätzlich nicht auf, soll aber wohl eine Abschnittsüberschrift bekommen.
Was haben die Wartungskategorien im enzyklopädischen Text zu suchen?
Heißt: Der Artikel wird für viele Leser aus unerfindlichen Gründen dauernd anders strukturiert aussehen.
Das muss überhaupt erstmal eine Mehrheit der MB-Teilnehmer befürworten, und die sehe ich nicht.
Mit Navigationsleisten wird das noch abenteuerlicher.
Verschieben der Navileiste bei allen Artikeln – das klingt nicht wie gründlich durchdacht.
Navigationsleisten stehen nach dem Artikeltext, nachdem alle enzyklopädischen Inhalte zu diesem Lemma erschöpfend behandelt wurden. Sie verweisen dann auf benachbarte enzyklopädische Artikel und stehen genau dort goldrichtig wo sie heute stehen.
Im Anschluss an die Navigationsleisten, sofern vorhanden, kommen nur noch Verwaltungsinformationen und Angelegenheiten außerhalb des enzyklopädischen Inhalts selbst; ggf. eine Gespochene Version oder Auszeichnungen als Lesenswert, Exzellent oder dergleichen.
Dorthin, also zum Verweis auf andere Artikel mit thematischer Nachbarschaft gehören auch die Kategorien.
Ich habe nicht verstanden, was das werden soll, aber diese Werkstatt ist auch definitiv der völlig falsche Ort für diese Frage. Hier war nur nach Darstellung der Kategorien an anderem Ort zu beantworten gewesen.
Am besten baust du Beispiel-Layouts in deinem BNR auf, stellst deine Absichten auch in Extremalfällen dar und diskutierst auf Basis anschaulicher Demonstrationsbeispiele irgendwo anders darüber.
Deine Adresse ist syntaktisch schon okay; geprüft würde Irgendwas@arcor.de daraufhin, ob es ein @ gibt (gibt es), ob danach eine syntaktisch korrekte Domain folgt (gibt es), ob in dem Zeugs davor keine verbotenen Zeichen oder Leerzeichen stünden (gibt es nicht).
Ich vermute, dass beim Copy&Paste irgendwelche unerlaubten unsichtbaren Zeichen davor oder dahinter hineingeraten sind. Leerzeichen drumrum müsste die Software eigentlich selbst entfernen; normalerweise ist die so schlau.
Einfach nochmal probieren, und insbesondere am Anfang und am Ende die Adresse nach dem Einkopieren nochmals mit händischen Buchstaben überschreiben.
Danke für die Tipps, aber die beschriebenen Probleme sind leider noch vorhanden.
Habe 2x die E-Mail-Adresse gelöscht (leeres Eingabefeld „freigegeben“), anschließend 1x die E-Mail-Adresse komplett händisch eingeben sowie 1x mittels Copy&Paste und, wie vorgeschlagen, Anfang und Ende jeweils einige Buchstaben überschrieben. Erhielt aber keinen „Bestätigungscode per E-Mail“.
Letzter Kommentar: vor 3 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
Hallo
Ich komme kurz nach meiner letzten technischen Anfrage, zu einem neuen/nicht-verwandten Anliegen. Ich war vor kurzem in einen Edit-War verwickelt, bei dem ich strittige Meldungen in der Nachrichtenbox auf der Hauptseite revertierte und dafür für wenige Stunden gesperrt wurde. In der Sperrzeit habe ich keinen Entsperrwunsch eingereicht (u.a. weil ich keine Zugriffsrechte, weder auf meine Benutzerseite, noch auf Wikipedia:Entsperrwünsche (nachtrag: gemeint ist eigtl. Wikipedia:Sperrprüfung) hatte...Von der Möglichkeit einer E-Mail-Anfrage habe ich in dann gestern Abend keinen gebrauch mehr gemacht. Wie dem auch sei; ich beabsichtige, die Löschung des Sperreintrags einzufordern...Möchte aber mit dieser Anfrage sicher sein, dass dies auch technisch umgesetzt werden kann. --LennBr (Diskussion) 18:05, 19. Sep. 2020 (CEST)Beantworten
Technisch ist das sowohl eine Versionslöschung des Logeintrags (dann können nur noch Admins den Sperrlogeintrag lesen) als auch eine Unterdrückung per Oversight (dann können nur noch Oversighter den Eintrag lesen) möglich. Beides wird hier aber nicht zur Anwendung kommen, da die Voraussetzungen für ein Oversighting oder eine Versionslöschung nicht vorliegen. Allenfalls könntest du einen 0-Sekunden-Sperrlogeintrag erreichen, in dem erklärt wird, dass die Sperre nicht korrekt war. --Count Count (Diskussion) 18:17, 19. Sep. 2020 (CEST)Beantworten
Danke soweit an Count Count für die Beantwortung. Ich konnte während der Sperrzeit meine Benutzerseite nicht bearbeiten. Ich habe es mehrmals versucht: dabei kam jedes mal der Hinweis, dass mein Konto gesperrt sei. --LennBr (Diskussion) 18:35, 19. Sep. 2020 (CEST)Beantworten
Aus dem Sperrlogeintrag geht hervor, dass du deine eigene Benutzerdiskussionsseite hättest bearbeiten können. Das ist die Standardeinstellung beim Sperren. Das Verbot, die eigene Benutzerdiskussionsseite zu bearbeiten, muss man dagegen als Parameter beim Sperren extra anwählen und dann würde im Sperrlogeintrag „darf eigene Diskussionsseite nicht bearbeiten" stehen. --Count Count (Diskussion) 19:08, 19. Sep. 2020 (CEST)Beantworten
Danke an dieser Stelle für die Fettmarkierung und Klarstellung. Die Benuterdiskussionsseite zu bearbeiten, die ja für den Entsperrwunsch eigentlich vorgesehen ist, habe ich nicht versucht. --LennBr (Diskussion) 19:25, 19. Sep. 2020 (CEST)Beantworten
Hier sollte erst einmal geklärt werden, ob die Sperre unberechtigt war. Ist das der Fall, kann der User durchaus verlangen, dass der Eintrag nicht mehr für jeden sichtbar ist. ÅñŧóñŜûŝî(Ð)01:17, 20. Sep. 2020 (CEST)Beantworten
Weiterentwicklung Softwaretool
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Es ist einige Monate her, da war ich berufsbedingt gezwungen programmieren lernen, in C++. Als es darum ging ein Übungsprojekt zu finden grub ich eine alte Idee aus, ein Tool das politische Weltkarten automatisch einfärbt, so was wird ja hier sehr oft gemacht. Das Tool wurde während des Kurses auch soweit fertig das es benutzbar ist, es fehlt noch gewisser Feinschliff und Komfortfunktionen. Nun kam es aber anders, aus der angedachten Stelle wurde virusbedingt nichts, und ich nun habe nun mit derartigen Themen (wieder) nur ganz selten was zu tun (und wenn, dann mit Python), lerne also nicht "automatisch" dazu. Lange Rede, kurzer Sinn, "fertigzustellen" geht vllt. noch, Pflegen oder gar Weiterentwicklung des ganzen aber nicht. Frage: Gibt es hier einen Programmierer, der das Tool mitübernehmen könnte?--Antemister (Diskussion) 13:59, 20. Sep. 2020 (CEST)Beantworten
Translatable modules
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hi,
Very sorry about writing in English. I hope somebody can translate this. Thanks in advance.
There's a new proposal to localize Lua modules in a more modern, safe, and convenient manner: mw:Translatable modules. In the foreseeable future it will only affect multilingual sites, such as Wikidata, Commons, Meta, and mediawiki.org, but at a later time it may also be deployed on Wikipedias and other projects.
Letzter Kommentar: vor 3 Jahren9 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo, das in FzW geschilderte Problem ist nicht gelöst, wurde dort jedoch nicht weiter verfolgt. Ich habe heute mal einen Screenshot gemacht. Kann ich gern hochladen: Wo? Danke, --Wi-luc-ky (Diskussion) 19:13, 25. Sep. 2020 (CEST)Beantworten
Danke, Count Count, den Screenshot findest Du nun hier (bitte Beschreibung nachbessern, falls erforderlich). Die obere Zeile ist zwar bearbeitbar, wird aber bei weiterer Vorschau nicht übernommen; stellt also eine Kopie der unter ZQ dar. Tritt auch bei anderen Benutzern auf, verwirrt und führt zu ZQ-Fehlern.
Ich denke mal, ich erkenne charakteristisches Design von wikEd wieder, und das ist meines Wissens ungepflegt, maintainerlos, und der Entwickler, der es geschaffen und ein Jahrzehnt weitergebaut hatte ist inaktiv oder macht nichts mehr daran.
Die duplizierten Teile sind im wikEd-Design, also von diesem hinzugefügt, und wahrscheinlich wegen veränderter Selektoren-Struktur werden die Original-MediaWiki-Felder nicht mehr ausgeblendet.
Dank euch beiden, Count Count und PerfektesChaos. Nachfolgend die permutierten Möglichkeiten mit Ergebnissen im ANR (mit kleinem Bsp.-lemma durchgeführt) zur Interpretation:
Kombi div. Benutzereinstellungen
Nr.
Zusätzliche Karteireiter für externe Werkzeuge
wikEd
Sonderzeichenauswahl (SZA)
Bemerkung
1
Nein
Ja
Ja
2 ZQs, 1 SZAs
2
Nein
Nein
Ja
1 ZQ, 1 SZA
3
Nein
Ja
Nein
2 ZQs, 0 SZA
4
Ja
Ja
Ja
2 ZQs, 1 SZA
5
Ja
Nein
Ja
1 ZQ, 1 SZA
6
Ja
Ja
Nein
2 ZQs, 0 SZA
Die doppelte Sonderzeichenauswahl konnte ich im ANR nicht mehr reproduzieren, jedoch auf dieser Disku bei Vorschau – jeweils bei zugleich drei zugeschalteten Features. (Hinweis: Gestern gab es zwei Änderungen in commons.js seitens WMF.) Gruß, --Wi-luc-ky (Diskussion) 01:23, 30. Sep. 2020 (CEST)Beantworten
Wie leicht zu sehen ist, sind 2ZQs synchron mit wikEd – was nicht erstaunt, weil die eine ist von MediaWiki und die andere von wikEd; und der wikEd-Mechanismus, der bislang die MediaWiki-ZQ ausgeblendet hatte, funktioniert nicht mehr.
Nur mit wikEd kommt es zu einer Kollision mit den „SZA“ (heißen „editMenus“); warum auch immer.
Die „Karteireiter“ bieten ja nur Werkzeuge an, greifen aber nicht ein, und sind deshalb eher unbeteiligt.
Die bearbeitete Seite ist relativ egal. Mag aber etwas enthalten, was das Fass zum Überlaufen brächte.
Vielen Dank, PerfektesChaos, für die nachvollziehbare Analyse. Es bleibt nun an den Betroffenen, ihre Einstellung zu ändern oder – die Bugs erduldend – zu belassen. Gruß, --Wi-luc-ky (Diskussion) 23:52, 30. Sep. 2020 (CEST)Beantworten
Klick auf die Bearbeitungsleiste führt zu Änderung nicht im Bearbeitungsfenster, sondern in der ZuQ-Zeile
Letzter Kommentar: vor 3 Jahren12 Kommentare4 Personen sind an der Diskussion beteiligt
Immer häufiger passiert es mir, dass wenn ich auf die Bearbeitungsleiste klicke, ich damit eine Änderung nicht im Bearbeitungsfenster, in der mein Cursor gerade steht, bewirke, sondern in der ZuQ-Zeile. Zuletzt ist mir das hier passiert, als ich unterschreiben wollte. Das ist schon reichlich nervig, vor allem wenn ich die Anführungszeichen einzeln per copy&paste aus der Zusammenfassung in den gewünschten Text transportieren muss. Mach ich was falsch, oder ist das ein Bug? U.A.w.G. Mit herzlichem Dank im Voraus --Φ (Diskussion) 20:19, 28. Sep. 2020 (CEST)Beantworten
Mmmh. „noch einmal ins Bearbetungsfenster gehe“ – Schreibst du dort etwas rein, oder ist sicher dass du da auch angekommen wärst?
Das Dings von uns, das unter dem Bearbeitungsfeld ist, merkt sich in welchem HTML-Eingabefeld der Cursor zuletzt war, technisch: was zuletzt den Fokus hatte, und fügt dann auch in genau dieses Feld das hinein, was von der Werkzeugleiste aus gefordert wird.
Wenn das Bearbeitungsfeld keinen „Fokus“ hat, insbesondere wenn der Cursor dort nicht steht, dann hatte ZuQ zuletzt den Fokus; genauso falls durch andere Werkzeuge das einfache HTML-Eingabefeld deaktiviert oder versteckt würde.
Gibt es gleichzeitig noch andere Werkzeugleisten, die auch sowas Ähnliches machen würden?
Versuche mal, im Bearbeitungsfeld etwas zu selektieren=markieren, etwa ein Wort. Wenn das gelingt und keine Syntaxhervorhebungs-Werkzeuge aktiv sind, dann hat das auch den aktuellen Fokus.
Außerdem bräuchte dieser Fehlerbericht noch: Skin, Desktop/Mobil, Browser-Familie.
Danke für deine Bemühungen. Ich weiß nicht, ob ich alles verstehe, was du schreibst.
Ich spreche von der Bearbeitungsleiste, die unter dem Bearbeitungsfenster erscheint: ''K'' '''F''' [[Seite]] [www] Datei:mini <nowiki> --~~~~ Dahinter kommen dann die Sonderzeichen.
Die reguläre Leiste oberhalb des Bearbeitungsfelds funktioniert einwandfrei.
Der Fehler tritt auch auf, wenn ich unmittelbar davor ins Bearbeitungsfeld geschrieben habe - hab ich gerade ausprobiert.
Ich arbeite mit einem Standgerät und surfe mit Firefox. Wie erfahre ih meinen Skin?
Beide Leisten fügen dort ein, wo der Fokus vor dem Klick war. Klick ich in die Zusammenfassungszeile und dann in einer der beiden Bearbeitungsleisten, dann wird in der Zusammenfassungszeile eingefügt. Klick ich ins Bearbeitungsfenster, dann fügen die beiden eben dort ein. Eventuell ist dein Problem, dass der initiale Fokus nicht im Bearbeitungsfenster, sondern in der Zusammenfassung ist. --Wurgl (Diskussion) 15:59, 29. Sep. 2020 (CEST)Beantworten
Mit „reguläre“ meine ich die Klassische Bearbeitungswerkzeugleiste. Mein Skin ist anscheinend Monobook. Ergibt das für dich irgendeinen Sinn? Grüße --Φ (Diskussion) 17:47, 29. Sep. 2020 (CEST)Beantworten
Mindestens sind das die Infos, die benötigt werden, um die Situation bei dir möglichst exakt nachzustellen.
Ich kann es nicht reproduzieren.
Falls es ein generelles Problem wäre, müssten sich bald mehr Leute melden.
Ich kann mir nur vorstellen, dass bei dir irgendeine Software aktiv ist, die das echte Wikitext-Bearbeitungsfeld versteckt. Syntaxhervorhebung ist dafür bekannt. Oder irgendeine Browserversion läuft schräg, was bei Firefox aber sehr selten wäre. Oder es gäbe ein spukendes Add-On nur bei dir.
Ich schätze dich mit Verlaub nicht so ein, dass du leicht mit der Fehlerkonsole zurechtkämst. Dort würden möglicherweise aufschlussreiche Fehlermeldungen sichtbar, aber auch Hunderte harmloser informativer Nachrichten. Insbesondere könnte man bei Auftreten des Problems aber die momentane HTML-Struktur inspizieren und analysieren; jedoch erfordert das eine ziemlich präzise Kenntnis von dem was da stehen müssste, um verdächtige Abweichungen vom Normalzustand zu erkennen.
Was noch nicht restlos aus deiner Schilderung hervorging: Kannst du generell niemals in das Wikitext-Bearbeitungsfeld einfügen, oder nur dann nicht mehr, nachdem du einmal im Bearbeitungskommentar drin warst? Oder meist geht es erwartungsgemß, und ohne ersichtlichen Grund landet urplötzlich alles im Kommentarfeld?
Danke für deine Bemühungen. Ich KANN ja im Brearbeitungsfeld arbeiten, nur wenn ich die untere Bearbeitungsleiste betätige, bewirkt das eine Änderung in der ZuQ-Zeile, falls ich in der vorher was geschrieben hatte.
Hallo Φ und PerfektesChaos, dasselbe Problem hatte ich vor einiger Zeit (wann, wo erinnere ich nicht mehr) schon einmal geschildert und war von Dir, PerfektesChaos, beantwortet worden. Es ging um die Fokussierung an unerwünschtem Ort.
Testbericht bei wikEd 0.9.155 und (damit verknüpftem) Syntaxhighlight:
Nach ersten Bearbeiten-Aufruf kann ich mittels beider (!) editMenus (siehe Nebenbemerkung im Thread Doppeltes Eingabefeld für Zusammenfassungszeile eins drüber) den Text im Bearbeitungsfenster bearbeiten (bspw. typographische Anführungszeichen setzen). Nachdem ich Preview geklickt habe, ist das nicht mehr möglich, auch wenn der Cursor nochmals ins Bearbeitungsfenster geklickt wird.
Abwahl von Syntaxhighlight bei aktiviertem wikEd hilft nicht.
Abwahl von wikEd hilft.
Syntaxhighlight allein ist unschädlich, zeigt aber ohne wikEd auch keine farblichen Hervorhebungen an.
WikEd verhindert also die Funktion des EditMenus im Bearbeitungsfeld. Und da wikEd wie eins drüber erwähnt ein Waisenkind geworden ist, können wir das Verhalten unter die nicht anbetungswürdigen Mysterien verbuchen. WikEd bringt auch die Bearbeiten-Werkzeugleiste zum Verschwinden, ein weiterer Nachteil bei vielen Vorteilen: Love it or leave it.
Danke für deine Antwort, Wi-luc-ky. Ich hab jetzt den Haken bei wikEd, der unter Einstellungen/Helferlein gesetzt war, entfernt. Das Problem besteht aber fort. Nie rozumiem. --Φ (Diskussion) 14:46, 2. Okt. 2020 (CEST)Beantworten
"Gadgets aufräumen und modernisieren" als Wunsch an das Projekt Technische Wünsche?
Letzter Kommentar: vor 3 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Nach der berechtigten Tirade von PerfektesChaos auf der Kurier-Disk zum Zustand vieler Gadgets hat Benutzer:Aschmidt in der MP-Disk vorgeschlagen, das Sichten, Aufräumen und Modernisieren dieser Gadgets als Wunsch an das Projekt Technische Wünsche heranzutragen. Nun bin ich leider viel zu weit weg von der Technik hier, um beurteilen zu können, ob das eine gute Idee wäre. Deshalb meine Frage an dieser Stelle: Wäre so ein Projekt sinnvoll, und hätte es Aussicht auf Erfolg? --Tkarcher (Diskussion) 20:37, 2. Okt. 2020 (CEST)Beantworten
Nein, das ist absolut keine umsetzbare Idee.
Das Management der eigenen Gadgets ist eine Community-Aufgabe der deWP und bedarf weitreichender Insider-Kenntnisse.
WMDE setzt externe Entwickler dran, und die benötigen eine ganz exakte Aufgabenstellung und Funktionsbeschreibung, und könnten damit genau ein einzelnes Gadget umschreiben oder sonstwas. Aber sie können nicht die Aufgabenstellung (den „Kundenwunsch“) entwickeln, geschweige denn als Externe den hiesigen Gadgetbestand irgendwie weiterentwickeln und pflegen, grad so wie es die hiesige Community brauchen würde.
WMDE entwickelt außerdem Werkzeuge, die potenziell auf allen Wikis der WMF einsetzbar wären.
Wie überfordert WMDE schon damit ist, zeigt sich derzeit am jämmerlichen Debakel um die automatisierte Lösung der Bearbeitungskonflikte, die zwangsweise allen IP aufgedrückt wurde und wird. Hier hatte man als Externe grundlegende Kenntnisse nicht gehabt, nämlich dass BK am häufigsten in Diskussionen um aktuelle Angelegenheiten auftreten werden, jedoch nur für triviale kleine Änderungen an Artikeln programmiert und erprobt. Bis heute funktioniert das nicht brauchbar, wurde aber viel zu früh als angeblich erfolgreich gelöst verkündet und zwangsweise als Standardeinstellung konfiguriert, wo IP nicht mal entrinnen können.
Bevor man eine solche Aufgabe delegieren kann, muss ganz exakt erarbeitet werden, was man eigentlich haben will. „Die sollen das da mal für uns irgendwie hinbringen“ ist keine durch Außenstehende lösbare Aufgabe.
Ein „Sichten und Aufräumen“ ist gleich gar nicht an Externe delegierbar, denn das ist ja gerade die Zielvorstellung der Community, die sie zuvor selbst erarbeiten müsste. Und „Aufräumen“ heißt Gadgets abschalten und nicht mehr anbieten, und das gibt vorhersehbar jeweils einen Sh-Proteststurm. Wofür es auch keinen Anlass gäbe, denn das was Community-Gadget ist wurde bereits (fast durchgängig durch mich) modernisiert, oder es ist bekannt wodurch es zu ersetzen wäre, oder wird irgendwann unrettbar eingehen; ist aber bis dahin mindestens auf dem Stand von 2011. Der Zustand aller Community-Gadgets und deren Prognose ist zumindest mir sehr exakt bekannt.
Jemand der nicht selbst mit einem Tool/Gadget/Helferlein arbeitet oder wenigstens mit der vom Tool/Gadget/Helferlein abgedeckten Problematik vertraut ist, wird nix Sinnvolles auf die Reihe bekommen. Und mit einer ganzen Palette von Tools sind Leute von außerhalb einfach restlos überfordert. --Wurgl (Diskussion) 16:47, 9. Okt. 2020 (CEST)Beantworten
Meldungen und Mitteilungen
Letzter Kommentar: vor 3 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Oben im Kopf der Seite sind neben meinem Benutzernamen die Symbole für meine Meldungen (Glocke) und meine Mitteilungen (leerer Bildschirm - oder was immer das ist) zu sehen. Seit Kurzem werden bei beiden Symbolen die Mitteilungen aufgeklappt, nur wenn ich bei der Glocke ganz unten auf den Klöppel klicke, was allerdings schwer zu erwischen ist, dann werden die Meldungen angezeigt. (Windows 10, Firefox 81.0.1 (64 bit), Benutzeroberfläche Vector, Legacy-Vector deaktiviert). Wenn ich auf die alte Vector-Oberfläche zurückschalte, funktioniert es; ist allso offenbar ein Bug in der neuen Oberfläche. --TheRunnerUp22:30, 3. Okt. 2020 (CEST)Beantworten
Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
wäre es auch möglich das Umbruch tool "<br>" so einzustellen,
daß nicht automatisch zum Anfang der nächsten Zeile gesprungen und eine leere Zeile angefügt wird
ähnlich wie bei manchen Zeitungen, die beim copieren von ihren Seiten zwangsweise die url mitliefern
bekommt mensch so mehr geliefert wie sinnvoll ist
Hallo, <br> ist nicht irgendein Tool, das wir irgendwie einstellen könnten, sondern ein weltweit verwendetes HTML-Element, das überall den gleichen Effekt hat und auch haben muss. Abgesehen davon verstehe ich das Anliegen nicht, der Sinn und Zweck von <br> ist ja gerade, einen Zeilenumbruch zu erzwingen. -- hgzh10:34, 6. Okt. 2020 (CEST)Beantworten